In message <c96781bf.804fb%john_brzozow...@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_brzozow...@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" <ma...@isc.org> wrote: > > > > >In message <c966c429.7fd46%john_brzozow...@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_brzozow...@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" <o...@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: ma...@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
