What's the current state of major access networks in North America ipv6 delivery status?

Thu Jan 27 14:53:29 UTC 2011

On Jan 27, 2011, at 6:08 AM, Carlos Martinez-Cagnazzo wrote:

> I agree with you, but, will it happen? The same fixed boundary
> behaviour that makes the /64 so convenient for LAN addressing ends up
> making the same /64 very convenient for ISPs as well. They associate
> the /64 with the "single public IP" they issue to customers nowadays.
> 
Most are not. I don't know where you are getting your information.

> Again, I would *love* to be wrong on this one. Seriously. This is an
> argument I sincerely hope to lose, but after being in the ISP business
> for more than 10 years, I wouldn't expect my local ISPs at least to
> issue anything shorter than a /64 to customers.
> 
Then embrace victory. You are wrong. One of the largest residential
broadband providers in the world just told you that you are wrong.
(John is running IPv6 for Comcast. He speaks with a pretty authoritative
voice on the topic.) I talk to a lot of these providers on a pretty
regular basis. I talked to groups of them about IPv6 in 30 countries
on 6 continents last year. I have yet to encounter a single provider
that thinks a single /64 is the be-all-end-all for residential services
in IPv6.

> And... the argument for this will have a commercial background as
> well. They will perceive customers who want multiple subnets as
> customers who can pay more. They will make customers who want multiple
> subnets go through hops to get a shorter prefix. Justifications and
> such. Very few people will do it.
> 
If they do, that will be a radical change from the current state of
the environment, possibly brought about by people telling them
that is what they expect.

Owen

> warm regards
> 
> Carlos
> 
> On Thu, Jan 27, 2011 at 11:58 AM, Brzozowski, John
> <John_Brzozowski at cable.comcast.com> wrote:
>> I am definitely *NOT* an advocate of NAT66 nor am I an advocate of further
>> subneting a /64 into longer prefixes.
>> 
>> Where additional IPv6 prefixes are required a prefix shorter than a /64
>> should be delegated.
>> 
>> John
>> =========================================
>> John Jason Brzozowski
>> Comcast Cable
>> e) mailto:john_brzozowski at cable.comcast.com
>> o) 609-377-6594
>> m) 484-962-0060
>> w) http://www.comcast6.net
>> =========================================
>> 
>> 
>> 
>> 
>> On 1/27/11 7:56 AM, "Carlos Martinez-Cagnazzo" <carlosm3011 at gmail.com>
>> wrote:
>> 
>>> Reading this thread, and building on many comments to a previous one,
>>> I definitely see the need for subnetting a /64 arising sooner than
>>> later.
>>> 
>>> It might not be perfect, It might be ugly, but it will happen. And, if
>>> you ask me, I would rather subnet a /64 than end up with a ipv6
>>> version of NAT, a much worse alternative.
>>> 
>>> cheers,
>>> 
>>> Carlos
>>> 
>>> On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John
>>> <John_Brzozowski at cable.comcast.com> wrote:
>>>> In order to deploy /56 to end users would require an IPv6 /24 be
>>>> dedicated
>>>> to 6rd, /48s would require a dedicated IPv6 /16.  This assumes an
>>>> operator
>>>> wants/needs to provide IPv6 via 6rd to end users where their IPv4
>>>> address
>>>> is fully unique.  There is quite a bit of IPv6 address space that does
>>>> not
>>>> gets utilized in this model.
>>>> 
>>>> The routers we are using as part of the trials only support /64 as such
>>>> we
>>>> are using an IPv6 /32.
>>>> 
>>>> It is also important that operators plan for the ability to delegate
>>>> prefixes that are shorter than a /64.  There are several cases that we
>>>> have seen where the router can only make use of a /64.  This is better
>>>> than nothing when referring to legacy devices that have been able to
>>>> introduce some support for IPv6 and would have otherwise been IPv4 only
>>>> devices.
>>>> 
>>>> John
>>>> =========================================
>>>> John Jason Brzozowski
>>>> Comcast Cable
>>>> e) mailto:john_brzozowski at cable.comcast.com
>>>> o) 609-377-6594
>>>> m) 484-962-0060
>>>> w) http://www.comcast6.net
>>>> =========================================
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 1/26/11 5:02 PM, "Owen DeLong" <owen at delong.com> wrote:
>>>> 
>>>>> 
>>>>> On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote:
>>>>> 
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>> 
>>>>>> 
>>>>>> Is anyone tracking the major consumer/business class access networks
>>>>>> delivery of ipv6 in North America?
>>>>>> 
>>>>>> I'm on ATT DSL. It looks like they want to use 6rd? I've only briefly
>>>>>> looked into 6rd. Is this a dead end path/giant hack?
>>>>>> 
>>>>>> 
>>>>>> https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo
>>>>>> gl
>>>>>> econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0
>>>>>> 
>>>>> It's a fairly ugly way to deliver IPv6, but, as transition technologies
>>>>> go, it's the least dead-end of the options.
>>>>> 
>>>>> It at least provides essentially native dual stack environment. The
>>>>> only difference is that your IPv6 access is via a tunnel. You'll
>>>>> probably
>>>>> be limited to a /56 or less over 6rd, unfortunately, but, because of the
>>>>> awful way 6rd consumes addresses, handing out /48s would be
>>>>> utterly impractical. Free.fr stuck their customers with /60s, which is
>>>>> hopefully a very temporary situation.
>>>>> 
>>>>>> 
>>>>>> I spoke with impulse.net last year, which appears to serve large
>>>>>> portions of the AT&T cable plant in Southern California. They were
>>>>>> willing to offer native ipv6. Not sure how (one /64, a /48) etc.
>>>>>> 
>>>>> You should definitely push your providers to give you a /48 if
>>>>> possible. If /56 or worse /60 or worst of all, /64 become widespread
>>>>> trends, it may significantly impact, delay, or even prevent innovations
>>>>> in the end-user networking/consumer electronics markets.
>>>>> 
>>>>> Owen
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> --
>>> =========================
>>> Carlos M. Martinez-Cagnazzo
>>> http://www.labs.lacnic.net
>>> =========================
>> 
>> 
> 
> 
> 
> -- 
> --
> =========================
> Carlos M. Martinez-Cagnazzo
> http://www.labs.lacnic.net
> =========================