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

Fri Jan 28 07:42:36 UTC 2011

In message <C96781BF.804FB%john_brzozowski at cable.comcast.com>, "Brzozowski, Joh
n" writes:
> 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.

I'm not trying to trivialize the issue.   I think that being able
to have the same prefix layout for ULA and PA addresses is useful.
I also think homes having /48 are useful.

There was also the claim that 6rd *required* a /16 to deliver to
deliver /48's to the customers.  That claim is demonstrable false.
It is not a protocol requirement.  It is the result of a choice
being made to deploy a single 6rd domain covering all of IPv4 space.

There are alternatives and they should be presented.
* 6rd domain covering the whole of IPv4 space.
* 6rd domain per /8 or similar block the ISP has addresses in.
* 6rd domain per block allocated from the RIR's rounded up to the closest
  power of 2.
* 6rd domain per pop.
* 6rd enabled at client request (may require putting the client in a
  appropriate address pool).

Each of these has tradeoffs in complexity, delegated prefix size
and address wastage.  I was aiming for a relatively low level of
complexity with the 6rd per RIR allocation and a /48 delegated
prefixes.  That the 6rd domains would just be a table that is
referred to when generating the final configurations for the DHCP
servers as it is a property of the IPv4 address to be returned and
not the customer.

> "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.
> >>=20
> >> 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.
> >>=20
> >> John
> >>=20
> >>=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
> >>=20
> >>=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
> >>=20
> >>=20
> >>=20
> >>=20
> >> On 1/26/11 5:02 PM, "Owen DeLong" <owen at delong.com> wrote:
> >>=20
> >> >
> >> >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
> >>=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
> >> >
> >> >
> >>=20
> >>=20
> >--=20
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org