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

Thu Jan 27 14:03:19 UTC 2011

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_Googl
> >>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