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
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
be limited to a /56 or less over 6rd, unfortunately, but, because of
=20 probably 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