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

[Mark Andrews <marka () isc org>]

In message <C96781BF.804FB%john_brzozowski () 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 () 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 () isc org> wrote:
>
> > In message <C966C429.7FD46%john_brzozowski () 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 () 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 () 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 () isc org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka () isc org