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.
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@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@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@isc.org