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

Brzozowski, John John_Brzozowski at Cable.Comcast.com
Fri Jan 28 06:07:00 UTC 2011


Mark,

Thanks for the insight, however, from an operators point of view one of
the benefits of 6rd is the simplified deployment model.  The statement
below regarding how to explicitly provision 6rd CEs is some what
inaccurate.  This provisioning for some deployments of 6rd could carry
some complexities which should not be trivialized.

"This really shouldn't be to hard for the provisioning systems to handle."

There is an assumption being made that the entire DHCP infrastructure can
support the transmission of 6rd DHCP options and can make those decisions
per CE or subscriber.

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 9:03 AM, "Mark Andrews" <marka at isc.org> wrote:

>
>In message <C966C429.7FD46%john_brzozowski at cable.comcast.com>,
>"Brzozowski, John" wri
>tes:
>> 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.
>
>No it doesn't require /16 to deploy 6rd with /48's.  It does however
>require the ISP to do more than say "this is our 6rd prefix" and
>shove all 32 bits of IPv4 address into the delegated prefix.  The
>moment the ISP needs to re-use IPv4 addresses for customers the
>simple "this is our 6rd prefix" fails to work.
>
>If an ISP has 34/8 and 35.0/9 then it needs two blocks of IPv6
>addresses on a /24 and one a /25, which would be used like this:
>
>    [P1 24 bits][low 24 bits][subnet 16 bits][host 64 bits]
>    [P2 25 bits][low 23 bits][subnet 16 bits][host 64 bits]
>
>The 6rd routers for P1 know that P1 means the top 8 bits are 34.
>The 6rd routers for P2 know that P2 means the top 9 bits are 35.0.
>
>The DHCP server for subnets in 34/8 are configured to hand out 6rd
>prefix info for P1 (6rdPrefixLen=24, IPv4MaskLen=8).  Similarly
>35.0/9 and P2 (6rdPrefixLen=25, IPv4Masklen=9).  This really shouldn't
>be to hard for the provisioning systems to handle.
>
>If the ISP was using 10/8 twice to connect to its customers then
>it would need two /24's (P1 and P2).  P1 and P2 would both have
>6rdPrefixLen=24, IPv4MaskLen=8.
>
>See RFC 5969 (RFC 5569 describes what Free originally did).
>
>> 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
>> 
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>3D=
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> 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
>> 
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>>3D=
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> 
>> 
>> 
>> 
>> 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
>> >>=20
>> >>=20
>> >> Is anyone tracking the major consumer/business class access networks
>> >> delivery of ipv6 in North America?
>> >>=20
>> >> 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?
>> >>=20
>> >>=20
>> 
>>>>https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo
>>>>gl
>> >>econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=3D0
>> >>=20
>> >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.
>> >
>> >>=20
>> >> 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.
>> >>=20
>> >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
>> >
>> >
>> 
>> 
>-- 
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org





More information about the NANOG mailing list