What's the current state of major access networks in North America ipv6 delivery status?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America? 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? https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleco... 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. I see that FiOS did a trial in April 2010 http://newscenter.verizon.com/press-releases/verizon/2010/verizon-begins-tes... (it mentions special CPE). What about verizon DSL? Comcast is currently conducting trials: http://comcast6.net/ (anyone participated in this?) How about TimeWarnerCable? They don't seem to have any sort of v6 offering, on wholesale or retail services. Am I missing anyone in the DSL/Cable/FTTH market? As for wireless broadband providers, there is satellite and 3g/4g/LTE. I haven't looked at the satellite providers. I know Verizon is offering dual stack on their LTE service, according to a thread a couple weeks ago. T-mobile is offering it on the small subset of phones that have v6 capable baseband. For grins and giggles, how does North America stack up against other regions, when it comes to access network ipv6 delivery. Thanks. - -- Charles N Wyble (charles@knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQJd/AAoJEMvvG/TyLEAtIx4P/1ehNtwotF30HZf4BqeWlJ7C gGmp33VkvwPdh8qUT4scHT/Wcql2V/ijhEJk7t0Tu9F98ig51c3euLuJ9iUhgP8v RdX9Ty8uAThs2EL/sT3aEVlrbiEOtkjW5zFQzWv3So7aPFeO9u5uBa9XO2eeOFG4 nI1ztpPzq3obGGLZWixIJ3ukOvKnb1ilKk74h9kjvnRA89wE1nS8ZvulWdWovAZ6 CaiU54SARQFlqtZ5PsrPrAi1LEz5lXP3Pp3kvphjp019XmyPvtgFwqwX6WoMbBgQ hHulUEnTX9A/3S/Llzz/eQRcWDX+KtqfF/khNBglsr6Y8tBgvJ360YI7dmn9J2hS 1QmnkiwTKlSkvbBM9HVbC/no7nB/J4ybOTVV004ciY6WWTRnCNGtgnoUWO4+qJVK E0996B2egOmhkUJs8AR+VYsguEVbSc12wbxZYrfjTjh7yE87q92okw/mUVi5OOVL t+ysZpV6yifR6/0T26VTJnJ/Ha6tjOE8SmA6lSKdKac5GTPkFBRqzkqsgGmF3lQq NAYMaVKmmq58j5e3eA8btGNf/u4wzJv9JJFXx3aij7pCE29yAfSrMfNV8r6ayAvL lDXQH3AP6LpV6EPb2vAUPq95iw+Fvl5PN80PYdyxVwpphQRutYQYvPZBh9/RfFOi LL5HLupKb900MQX/ZMjY =tE8q -----END PGP SIGNATURE-----
On Jan 26, 2011, at 1:52 PM, Charles N Wyble wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America?
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?
https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleco...
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.
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.
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
In message <BACEA722-744B-4773-89EF-03FBB933E1E4@delong.com>, Owen DeLong write s:
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 = https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Google= conf-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.
This comes from using a single 6rd prefix for all the clients. Those saying this is the way to do this really havn't thought about what they are going to have to do once they can't get enough IPv4 addresses to give a public one to each customer that needs a IPv4 addresses and also needs 6rd. The "simple" solution of a signgle prefix doesn't work. 6rd doesn't have to consume space badly and it shouldn't consume space badly if done right. DHCP servers don't hand out the same router to each client. They hand out the same router to all clients on the same subnet. ISP's are capable of configuring their DHCP servers to do that. Configuring them to hand out a 6rd prefix on a per subnet basis is no harder. Just ask for a /48 for each IPv4 address you intend to support 6rd on. For each block IPv4 block you get from RIR you specify a matching 6rd prefix. This prefix is stable for the life of the IPv4 block's allocation. When you get a new IPv4 block you add the 6rd prefix to the configuration system. If you are using RFC 1918 addresses to connect to your customers and NATing that you request enough /48's to cover the amout of RFC 1918 space you are using. If you are re-using space in multiple places then 6rd becomes a little more complicated as the prefixes need to differ for each re-uses. Note the naive single 6rd prefix doesn't work in this situation so ISPs doing this will need do something more complicated. Also give that address space will almost certainly need to be re-used while 6rd is also in use I fail to see the objection to doing it sensibly from the get go. Down the track I can see 6rd prefixes being allocated on request being just one more thing that the consumer can request via a web form. This will allow the ISP to recover the space being used by 6rd.
=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
On 01/26/2011 11:02 PM, Owen DeLong wrote:
Free.fr stuck their customers with /60s, which is hopefully a very temporary situation.
Stuck with /64 in practice, which will evolve into /60 when the IPv6 support in their Freebox will be better. I don't think that we'll get anything more than /60 before the next decade... At least, they have been able to provide pseudo-native IPv6 for years. If anyone asks, performances of IPv6 over Free's 6rd are almost the same than IPv4's. -- Rémy Sanchez
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. 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 ========================================= 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/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
Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America?
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?
https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googl econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0
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.
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.
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
Reading this thread, and building on many comments to a previous one, I definitely see the need for subnetting a /64 arising sooner than later. It might not be perfect, It might be ugly, but it will happen. And, if you ask me, I would rather subnet a /64 than end up with a ipv6 version of NAT, a much worse alternative. cheers, Carlos On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John <John_Brzozowski@cable.comcast.com> wrote:
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.
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 ========================================= 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/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
Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America?
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?
https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googl econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0
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.
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.
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
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
On Thu, 27 Jan 2011, Carlos Martinez-Cagnazzo wrote:
Reading this thread, and building on many comments to a previous one, I definitely see the need for subnetting a /64 arising sooner than later.
It might not be perfect, It might be ugly, but it will happen. And, if you ask me, I would rather subnet a /64 than end up with a ipv6 version of NAT, a much worse alternative.
Maybe not NAT but some kind of proxy ND and/or a migration from routing firewalls to bridging firewalls. If the broadband provider is only providing a single /64, it's not likely they're gonna be willing to add routes to your gateway. Antonio Querubin e-mail/xmpp: tony@lava.net
I guess I won't need to add routes to my gateway, only subnetting on the inside will probably do for the time being (a hub/spoke topology, routing only between directly-connected subnets). And many ISPs allow you to buy your own CPE. Using an AirPort Extreme (or other home router with similar features) in bridged mode would do the trick, i guess. :-) cheers, Carlos On Thu, Jan 27, 2011 at 11:11 AM, Antonio Querubin <tony@lava.net> wrote:
On Thu, 27 Jan 2011, Carlos Martinez-Cagnazzo wrote:
Reading this thread, and building on many comments to a previous one, I definitely see the need for subnetting a /64 arising sooner than later.
It might not be perfect, It might be ugly, but it will happen. And, if you ask me, I would rather subnet a /64 than end up with a ipv6 version of NAT, a much worse alternative.
Maybe not NAT but some kind of proxy ND and/or a migration from routing firewalls to bridging firewalls. If the broadband provider is only providing a single /64, it's not likely they're gonna be willing to add routes to your gateway.
Antonio Querubin e-mail/xmpp: tony@lava.net
On Jan 27, 2011, at 5:11 AM, Antonio Querubin wrote:
On Thu, 27 Jan 2011, Carlos Martinez-Cagnazzo wrote:
Reading this thread, and building on many comments to a previous one, I definitely see the need for subnetting a /64 arising sooner than later.
Why?
It might not be perfect, It might be ugly, but it will happen. And, if you ask me, I would rather subnet a /64 than end up with a ipv6 version of NAT, a much worse alternative.
You should be able to do that today if you're so inclined, but, you lose some features.
Maybe not NAT but some kind of proxy ND and/or a migration from routing firewalls to bridging firewalls. If the broadband provider is only providing a single /64, it's not likely they're gonna be willing to add routes to your gateway.
If they're routing a /64 to your gateway, you're all set. If they're not, then, how are you getting the /64 in the first place? None of the providers I've talked to are using single /64s for any other reason that CPE limitations. The worst case I'm aware of today is Free.FR who is limiting their customers to a /64 today due to CPE problems, but, has allocated /60 per customer and plans to make /60s available as soon as the CPE can support it. Owen
On Thu, 27 Jan 2011, Owen DeLong wrote:
If they're routing a /64 to your gateway, you're all set. If they're not, then, how are you getting the /64 in the first place?
Bridged ethernet across the broadband provider network to the ISP router. Each customer gets a single /64 vlan to their residence. If the customer now wants more than one subnet, the ISP must now route additional prefixes to a customer's gateway. The customer can't just setup a router to break up the single /64 without the ISP carrying a route entry or the customer doing some kind of IPv6 NAT or proxy ND. If the ISP wont route additional prefixes, then the customer is forced to do the latter.
On 1/27/2011 7:56 PM, Antonio Querubin wrote:
If the ISP wont route additional prefixes, then the customer is forced to do the latter.
If the ISP wont route additional prefixes, they don't support IPv6. Jack
On Jan 27, 2011, at 5:56 PM, Antonio Querubin wrote:
On Thu, 27 Jan 2011, Owen DeLong wrote:
If they're routing a /64 to your gateway, you're all set. If they're not, then, how are you getting the /64 in the first place?
Bridged ethernet across the broadband provider network to the ISP router. Each customer gets a single /64 vlan to their residence. If the customer now wants more than one subnet, the ISP must now route additional prefixes to a customer's gateway. The customer can't just setup a router to break up the single /64 without the ISP carrying a route entry or the customer doing some kind of IPv6 NAT or proxy ND. If the ISP wont route additional prefixes, then the customer is forced to do the latter.
If you need more than one prefix, then, they should route you a /48 instead of a /64. If they won't, I strongly encourage you to switch providers, or, get a free tunnel from http://tunnelbroker.net and use that. Owen
On Thu, 27 Jan 2011, Antonio Querubin wrote:
Bridged ethernet across the broadband provider network to the ISP router. Each customer gets a single /64 vlan to their residence. If the customer now wants more than one subnet, the ISP must now route additional prefixes to a customer's gateway. The customer can't just setup a router to break up the single /64 without the ISP carrying a route entry or the customer doing some kind of IPv6 NAT or proxy ND. If the ISP wont route additional prefixes, then the customer is forced to do the latter.
You do NOT want to keep state for all the devices in the customer residence. Your ND table will be enormous. We already have problems with ARP on our larger residential aggregation routers, I don't even want to think about what it'd look like with 10+ devices in peoples homes in those /64:s, each perhaps using multiple IPs. Your ND traffic will be enormous. It's much cleaner to require a CPE at he customer prem, run LL only between CPE and PE, DHCPv6-PD a /56 or larger, and now you're done with it. No need to keep state for customer home devices, you just have to handle the CPE. Minimal TCAM usage, minimal state handling. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Fri, 28 Jan 2011, Mikael Abrahamsson wrote:
You do NOT want to keep state for all the devices in the customer residence. Your ND table will be enormous.
We already have problems with ARP on our larger residential aggregation routers, I don't even want to think about what it'd look like with 10+ devices in peoples homes in those /64:s, each perhaps using multiple IPs. Your ND traffic will be enormous.
I wonder how many ISPs actually have so many IPv6 customers that they actually have these problems. Or is this mainly a limitation with a particular vendor's equipment? Antonio Querubin e-mail/xmpp: tony@lava.net
On Thu, 27 Jan 2011, Antonio Querubin wrote:
I wonder how many ISPs actually have so many IPv6 customers that they actually have these problems. Or is this mainly a limitation with a particular vendor's equipment?
If you want to buy some equipment that can handle hundreds of thousands of ND:s instead of one that might handle thousands, you're free to do so. Also your L2 transport need to scale as well, including needing to handle tens of MAC addresses per customer (I live in a household of 2 adults, we have approximately 10-15 devices that talk IP, and this is not becoming fewer over time). It's your money (or your employers). -- Mikael Abrahamsson email: swmike@swm.pp.se
On 1/28/2011 5:34 AM, Mikael Abrahamsson wrote:
If you want to buy some equipment that can handle hundreds of thousands of ND:s instead of one that might handle thousands, you're free to do so. Also your L2 transport need to scale as well, including needing to handle tens of MAC addresses per customer (I live in a household of 2 adults, we have approximately 10-15 devices that talk IP, and this is not becoming fewer over time).
It's your money (or your employers).
IPv4, standard termination routers (7206VXR), DHCP, no router CPE required, no request limitations. We'll have equivalent in IPv6 with DHCPv6, except we route prefixes for routers, but that won't effect the mac tables. Router 1: 1233 Router 2: 1012 Router 3: 2198 and so on (just random routers). I don't see these numbers as being an issue. The router choice of the ISP is often a factor of number of customers, throughput, and desired feature sets/flexibility; which is why we run multiple processor based routers. I can handle more customers on a hardware based platform, but I also get much better support for the 100s of thousands of ND/ARP tables and run the risk of hardware not supporting a feature I need. Customers are often likely to get a router for their location, especially if you aren't providing wireless in the stock CPE; though I do have a few regions which issue stock CPE with wireless, fully bridged (no routing). Customer's choice. Jack
On Fri, 28 Jan 2011, Jack Bates wrote:
IPv4, standard termination routers (7206VXR), DHCP, no router CPE required, no request limitations. We'll have equivalent in IPv6 with DHCPv6, except we route prefixes for routers, but that won't effect the mac tables.
Router 1: 1233 Router 2: 1012 Router 3: 2198
and so on (just random routers). I don't see these numbers as being an issue.
It simply isn't an issue for us here either. It's not like we're immediately trading an ARP table for a ND table that's hundreds of times larger than the ARP table. Customers just don't change things that quickly. And I would think aggregation equipment vendors who have been eating their own dog food understand that too. Antonio Querubin e-mail/xmpp: tony@lava.net
On 1/28/2011 12:41 AM, Mikael Abrahamsson wrote:
It's much cleaner to require a CPE at he customer prem, run LL only between CPE and PE, DHCPv6-PD a /56 or larger, and now you're done with it. No need to keep state for customer home devices, you just have to handle the CPE.
Except now you require a user to have a routed CPE. I'm up for classic stateful DHCPv6 IA_TA addressing + DHCPv6-PD. Best of both worlds, and in a proper setup, any address not assigned is null routed. Jack
I am definitely *NOT* an advocate of NAT66 nor am I an advocate of further subneting a /64 into longer prefixes. Where additional IPv6 prefixes are required a prefix shorter than a /64 should be delegated. 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 7:56 AM, "Carlos Martinez-Cagnazzo" <carlosm3011@gmail.com> wrote:
Reading this thread, and building on many comments to a previous one, I definitely see the need for subnetting a /64 arising sooner than later.
It might not be perfect, It might be ugly, but it will happen. And, if you ask me, I would rather subnet a /64 than end up with a ipv6 version of NAT, a much worse alternative.
cheers,
Carlos
On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John <John_Brzozowski@cable.comcast.com> wrote:
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.
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 ========================================= 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/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
Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America?
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?
https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo gl econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0
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.
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.
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
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
I agree with you, but, will it happen? The same fixed boundary behaviour that makes the /64 so convenient for LAN addressing ends up making the same /64 very convenient for ISPs as well. They associate the /64 with the "single public IP" they issue to customers nowadays. Again, I would *love* to be wrong on this one. Seriously. This is an argument I sincerely hope to lose, but after being in the ISP business for more than 10 years, I wouldn't expect my local ISPs at least to issue anything shorter than a /64 to customers. And... the argument for this will have a commercial background as well. They will perceive customers who want multiple subnets as customers who can pay more. They will make customers who want multiple subnets go through hops to get a shorter prefix. Justifications and such. Very few people will do it. warm regards Carlos On Thu, Jan 27, 2011 at 11:58 AM, Brzozowski, John <John_Brzozowski@cable.comcast.com> wrote:
I am definitely *NOT* an advocate of NAT66 nor am I an advocate of further subneting a /64 into longer prefixes.
Where additional IPv6 prefixes are required a prefix shorter than a /64 should be delegated.
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 7:56 AM, "Carlos Martinez-Cagnazzo" <carlosm3011@gmail.com> wrote:
Reading this thread, and building on many comments to a previous one, I definitely see the need for subnetting a /64 arising sooner than later.
It might not be perfect, It might be ugly, but it will happen. And, if you ask me, I would rather subnet a /64 than end up with a ipv6 version of NAT, a much worse alternative.
cheers,
Carlos
On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John <John_Brzozowski@cable.comcast.com> wrote:
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.
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 ========================================= 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/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
Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America?
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?
https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo gl econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0
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.
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.
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
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
On Jan 27, 2011, at 6:08 AM, Carlos Martinez-Cagnazzo wrote:
I agree with you, but, will it happen? The same fixed boundary behaviour that makes the /64 so convenient for LAN addressing ends up making the same /64 very convenient for ISPs as well. They associate the /64 with the "single public IP" they issue to customers nowadays.
Most are not. I don't know where you are getting your information.
Again, I would *love* to be wrong on this one. Seriously. This is an argument I sincerely hope to lose, but after being in the ISP business for more than 10 years, I wouldn't expect my local ISPs at least to issue anything shorter than a /64 to customers.
Then embrace victory. You are wrong. One of the largest residential broadband providers in the world just told you that you are wrong. (John is running IPv6 for Comcast. He speaks with a pretty authoritative voice on the topic.) I talk to a lot of these providers on a pretty regular basis. I talked to groups of them about IPv6 in 30 countries on 6 continents last year. I have yet to encounter a single provider that thinks a single /64 is the be-all-end-all for residential services in IPv6.
And... the argument for this will have a commercial background as well. They will perceive customers who want multiple subnets as customers who can pay more. They will make customers who want multiple subnets go through hops to get a shorter prefix. Justifications and such. Very few people will do it.
If they do, that will be a radical change from the current state of the environment, possibly brought about by people telling them that is what they expect. Owen
warm regards
Carlos
On Thu, Jan 27, 2011 at 11:58 AM, Brzozowski, John <John_Brzozowski@cable.comcast.com> wrote:
I am definitely *NOT* an advocate of NAT66 nor am I an advocate of further subneting a /64 into longer prefixes.
Where additional IPv6 prefixes are required a prefix shorter than a /64 should be delegated.
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 7:56 AM, "Carlos Martinez-Cagnazzo" <carlosm3011@gmail.com> wrote:
Reading this thread, and building on many comments to a previous one, I definitely see the need for subnetting a /64 arising sooner than later.
It might not be perfect, It might be ugly, but it will happen. And, if you ask me, I would rather subnet a /64 than end up with a ipv6 version of NAT, a much worse alternative.
cheers,
Carlos
On Thu, Jan 27, 2011 at 9:57 AM, Brzozowski, John <John_Brzozowski@cable.comcast.com> wrote:
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.
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 ========================================= 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/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
Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America?
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?
https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Goo gl econf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0
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.
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.
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
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
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
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. "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.
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_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
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: 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
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
On Wed, Jan 26, 2011 at 16:52, Charles N Wyble <charles@knownelement.com>wrote: (SNIP) Comcast is currently conducting trials:
http://comcast6.net/ (anyone participated in this?)
Yes, I am in one of their trials now. For the trial I am in (Residential cable, 6RD) they shipped me a Cisco/Linksys running OpenWRT/LuCI. Mostly been working great ... /TJ
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 01:52 PM, Charles N Wyble wrote:
Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America?
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?
https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleco...
Found an article talking about at&t v6 support http://www.networkworld.com/news/2010/102710-att-ipv6.html?page=3 Also found http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQKEzAAoJEMvvG/TyLEAt45cP/0g+8lNUb1z6Ew/tWgGPEYWu u7wemSTjs27yxKXIbdfWzcWizvX3THHFNW6oRlRIdaH3z+Ttkzb/ne5wEDw9lcgV vnW0n/QjKQOWFaZ+chgEpplEVPth5jww/B/o9taeS7MXonbhQipTeTo3/U7am0GB MCZXngLllOhPZmmjhqsssiLX94wjc5uvqSdAExTt7aXQ7+SaVzpFghXTZgWAG9eE X9JpFeLhJMNPed1MOzxOn7WTsqDu2sHyszoyrZwGyjyQ/JZFDFfdhE3qQPRe97tv ZOmlfPYFjJRjQ4MlY7iX+BI/CTRAeM+59oslpX8h7VeGY4zmlNGw8dhR1yvB400h w+/GubudSnL50XppUslKWbl03v+4dTQYMy3dotwH2OM8ovcJMn596rLW8j+3zV7t zcOuLSLFlqY6QZYy8tp705qzYesLWvHJJlpbXryyOGoz/5SJyTvfkDywOgyNeXz4 siU2a+JaAxlJsrBc9YsabCY8C60zFQxKBwANXWhvP7TZiFtt+SaNLp/Eahh9NoAO Zygs4FekumT9TFeNsAnPlHFFCl9v6fU0Yxc8u0ffYa2+hW6f/2My4tY0n07PNd8l DUUO7h9GtLpfEgTk2eLavY8HZcb1RtA4cvMe8n1J2GOVCwpGfOD0xl1Y3AX6v+rk JuGqPIfyQ8GiNtj7KzRV =LASk -----END PGP SIGNATURE-----
This is all hearsay, but I learned from a shared vendor that AT&T is putting pressure on them to complete their IPv6 support, so that the vendor is moving up completion from Q4 to Q2. This was a sales person talking, so who knows. Frank -----Original Message----- From: Charles N Wyble [mailto:charles@knownelement.com] Sent: Wednesday, January 26, 2011 4:33 PM To: nanog@nanog.org Subject: Re: What's the current state of major access networks in North America ipv6 delivery status? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 01:52 PM, Charles N Wyble wrote:
Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America?
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?
https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleco nf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0
Found an article talking about at&t v6 support http://www.networkworld.com/news/2010/102710-att-ipv6.html?page=3 Also found http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQKEzAAoJEMvvG/TyLEAt45cP/0g+8lNUb1z6Ew/tWgGPEYWu u7wemSTjs27yxKXIbdfWzcWizvX3THHFNW6oRlRIdaH3z+Ttkzb/ne5wEDw9lcgV vnW0n/QjKQOWFaZ+chgEpplEVPth5jww/B/o9taeS7MXonbhQipTeTo3/U7am0GB MCZXngLllOhPZmmjhqsssiLX94wjc5uvqSdAExTt7aXQ7+SaVzpFghXTZgWAG9eE X9JpFeLhJMNPed1MOzxOn7WTsqDu2sHyszoyrZwGyjyQ/JZFDFfdhE3qQPRe97tv ZOmlfPYFjJRjQ4MlY7iX+BI/CTRAeM+59oslpX8h7VeGY4zmlNGw8dhR1yvB400h w+/GubudSnL50XppUslKWbl03v+4dTQYMy3dotwH2OM8ovcJMn596rLW8j+3zV7t zcOuLSLFlqY6QZYy8tp705qzYesLWvHJJlpbXryyOGoz/5SJyTvfkDywOgyNeXz4 siU2a+JaAxlJsrBc9YsabCY8C60zFQxKBwANXWhvP7TZiFtt+SaNLp/Eahh9NoAO Zygs4FekumT9TFeNsAnPlHFFCl9v6fU0Yxc8u0ffYa2+hW6f/2My4tY0n07PNd8l DUUO7h9GtLpfEgTk2eLavY8HZcb1RtA4cvMe8n1J2GOVCwpGfOD0xl1Y3AX6v+rk JuGqPIfyQ8GiNtj7KzRV =LASk -----END PGP SIGNATURE-----
On Wed, 26 Jan 2011, Charles N Wyble wrote:
How about TimeWarnerCable? They don't seem to have any sort of v6 offering, on wholesale or retail services.
TW Cable has no IPv6 offering. However, TW Telecom provides IPv6 connectivity upon request. By default they only provide a /56 if you need multiple subnets and you have to provide further justification to get a /48. Antonio Querubin e-mail/xmpp: tony@lava.net
All the leading MSOs are actively working towards IPv6 trials and deployments, they're just at different stages. Comcast, as we all can see, is publicly leading, but there are others who are not too far behind. Frank -----Original Message----- From: Antonio Querubin [mailto:tony@lava.net] Sent: Wednesday, January 26, 2011 5:09 PM To: Charles N Wyble Cc: nanog@nanog.org Subject: Re: What's the current state of major access networks in North America ipv6 delivery status? On Wed, 26 Jan 2011, Charles N Wyble wrote:
How about TimeWarnerCable? They don't seem to have any sort of v6 offering, on wholesale or retail services.
TW Cable has no IPv6 offering. However, TW Telecom provides IPv6 connectivity upon request. By default they only provide a /56 if you need multiple subnets and you have to provide further justification to get a /48. Antonio Querubin e-mail/xmpp: tony@lava.net
All the leading MSOs are actively working towards IPv6 trials and deployments, they're just at different stages. Comcast, as we all can see, is publicly leading, but there are others who are not too far behind.
See "U.S. cable companies embrace IPv6" http://www.networkworld.com/news/2010/102810-cable-ipv6.html Thomas
-----Original Message----- From: Antonio Querubin [mailto:tony@lava.net] Sent: Wednesday, January 26, 2011 6:09 PM To: Charles N Wyble Cc: nanog@nanog.org Subject: Re: What's the current state of major access networks in North America ipv6 delivery status?
On Wed, 26 Jan 2011, Charles N Wyble wrote:
How about TimeWarnerCable? They don't seem to have any sort of v6 offering, on wholesale or retail services.
TW Cable has no IPv6 offering.
Time Warner Cable turned up its first commercial customer using native IPv6 over our fiber access product last year, and we expect to begin residential IPv6 trials this spring. We, along with other MSOs, have been working with CableLabs, NCTA and the SCTE in a multi-industry effort to adopt IPv6, and are hopeful that companies in the CE and vendor communities begin to offer new equipment and provide firmware upgrades that ensure the devices in our customers' homes support IPv6. Lee Howard
On Fri, 28 Jan 2011, Lee Howard wrote:
Time Warner Cable turned up its first commercial customer using native IPv6 over our fiber access product last year, and we expect to begin residential IPv6 trials this spring. We, along with other MSOs, have been working with CableLabs, NCTA and the SCTE in a multi-industry effort to adopt IPv6, and are hopeful that companies in the CE and vendor communities begin to offer new equipment and provide firmware upgrades that ensure the devices in our customers' homes support IPv6.
When I queried the local TWC reps on behalf of a business client who has TWC Business Class service about 2 weeks ago, the response I received was "it's not available yet... you need to convert to IPv4..." Are Business Class customers considered residential or commercial? Antonio Querubin e-mail/xmpp: tony@lava.net
Two good lists are here: http://www.sixxs.net/faq/connectivity/?faq=native http://www.sixxs.net/wiki/IPv6_Enabled_Service_Providers Frank -----Original Message----- From: Charles N Wyble [mailto:charles@knownelement.com] Sent: Wednesday, January 26, 2011 3:52 PM To: nanog@nanog.org Subject: What's the current state of major access networks in North America ipv6 delivery status? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is anyone tracking the major consumer/business class access networks delivery of ipv6 in North America? 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? https://sites.google.com/site/ipv6implementors/2010/agenda/05_Chase_Googleco nf-BroadbandtransitiontoIPv6using6rd.pdf?attredirects=0 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. I see that FiOS did a trial in April 2010 http://newscenter.verizon.com/press-releases/verizon/2010/verizon-begins-tes ting-ipv6.html (it mentions special CPE). What about verizon DSL? Comcast is currently conducting trials: http://comcast6.net/ (anyone participated in this?) How about TimeWarnerCable? They don't seem to have any sort of v6 offering, on wholesale or retail services. Am I missing anyone in the DSL/Cable/FTTH market? As for wireless broadband providers, there is satellite and 3g/4g/LTE. I haven't looked at the satellite providers. I know Verizon is offering dual stack on their LTE service, according to a thread a couple weeks ago. T-mobile is offering it on the small subset of phones that have v6 capable baseband. For grins and giggles, how does North America stack up against other regions, when it comes to access network ipv6 delivery. Thanks. - -- Charles N Wyble (charles@knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNQJd/AAoJEMvvG/TyLEAtIx4P/1ehNtwotF30HZf4BqeWlJ7C gGmp33VkvwPdh8qUT4scHT/Wcql2V/ijhEJk7t0Tu9F98ig51c3euLuJ9iUhgP8v RdX9Ty8uAThs2EL/sT3aEVlrbiEOtkjW5zFQzWv3So7aPFeO9u5uBa9XO2eeOFG4 nI1ztpPzq3obGGLZWixIJ3ukOvKnb1ilKk74h9kjvnRA89wE1nS8ZvulWdWovAZ6 CaiU54SARQFlqtZ5PsrPrAi1LEz5lXP3Pp3kvphjp019XmyPvtgFwqwX6WoMbBgQ hHulUEnTX9A/3S/Llzz/eQRcWDX+KtqfF/khNBglsr6Y8tBgvJ360YI7dmn9J2hS 1QmnkiwTKlSkvbBM9HVbC/no7nB/J4ybOTVV004ciY6WWTRnCNGtgnoUWO4+qJVK E0996B2egOmhkUJs8AR+VYsguEVbSc12wbxZYrfjTjh7yE87q92okw/mUVi5OOVL t+ysZpV6yifR6/0T26VTJnJ/Ha6tjOE8SmA6lSKdKac5GTPkFBRqzkqsgGmF3lQq NAYMaVKmmq58j5e3eA8btGNf/u4wzJv9JJFXx3aij7pCE29yAfSrMfNV8r6ayAvL lDXQH3AP6LpV6EPb2vAUPq95iw+Fvl5PN80PYdyxVwpphQRutYQYvPZBh9/RfFOi LL5HLupKb900MQX/ZMjY =tE8q -----END PGP SIGNATURE-----
On Jan 26, 2011, at 4:52 PM, Charles N Wyble <charles@knownelement.com> wrote:
Comcast is currently conducting trials: http://comcast6.net/ (anyone participated in this?)
Yes, and other than the fact that their 6rd implementation only gives me a /64, I've been really happy with it. My wife doesn't even know that her iOS devices and win7 box are dual stacked :)
On Jan 28, 2011, at 4:07 PM, John Payne wrote:
On Jan 26, 2011, at 4:52 PM, Charles N Wyble <charles@knownelement.com> wrote:
Comcast is currently conducting trials: http://comcast6.net/ (anyone participated in this?)
Yes, and other than the fact that their 6rd implementation only gives me a /64, I've been really happy with it. My wife doesn't even know that her iOS devices and win7 box are dual stacked :)
If you have CPE that will accept more than a /64 via DHCPv6, they will be glad to have you trial more. However, as yet none of the CPE seems to support that. Owen
participants (15)
-
Antonio Querubin -
Brzozowski, John -
Carlos Martinez-Cagnazzo -
Carlos Martinez-Cagnazzo -
Charles N Wyble -
Frank Bulk -
Jack Bates -
John Payne -
Lee Howard -
Mark Andrews -
Mikael Abrahamsson -
Owen DeLong -
Rémy Sanchez -
Thomas Narten -
TJ