Folks, Since deploying our 6to4 relays, Comcast has observed a substantial reduction in the latency associated with the use of 6to4. As such we are contemplating further opening our relays for use by others. The availability of our 6to4 relays should improve the experience of others using 6to4 as a means to access content and services over IPv6. We have been open about our IPv6 activities and wanted to follow suit by reaching out to the community and soliciting feedback before moving forward. As always we wish to continue to advocate and support the universal deployment of IPv6. Please send any comments or questions to the list or if you wish to me directly. 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 04/19/2011 13:44, Brzozowski, John wrote:
Folks,
Since deploying our 6to4 relays, Comcast has observed a substantial reduction in the latency associated with the use of 6to4. As such we are contemplating further opening our relays for use by others. The availability of our 6to4 relays should improve the experience of others using 6to4 as a means to access content and services over IPv6.
We have been open about our IPv6 activities and wanted to follow suit by reaching out to the community and soliciting feedback before moving forward. As always we wish to continue to advocate and support the universal deployment of IPv6.
Please send any comments or questions to the list or if you wish to me directly.
Presumably you(pl.) are aware of the following 2 drafts, which are in WGLC now, and seem likely to be adopted (at least in some form): http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic At minimum one would hope that you're heeding the warnings in the first. Another view (one that I personally hold) is that any effort you might be putting into making 6to4 work better would be better placed in deploying real IPv6 instead; and that the world would be a better place generally if all of the so-called "transition mechanisms" just went away. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
On Apr 19, 2011, at 5:50 PM, Doug Barton wrote:
At minimum one would hope that you're heeding the warnings in the first. Another view (one that I personally hold) is that any effort you might be putting into making 6to4 work better would be better placed in deploying real IPv6 instead; and that the world would be a better place generally if all of the so-called "transition mechanisms" just went away.
I certainly feel that the lawful-intercept requirements and data retention necessary in a CGN/6to4 environment likely mean the barrier is high enough to suggest moving to IPv6, but the CPE situation is still mostly missing. - Jared
On Tue, 19 Apr 2011, Doug Barton wrote:
Another view (one that I personally hold) is that any effort you might be putting into making 6to4 work better would be better placed in deploying real IPv6 instead; and that the world would be a better place generally if all of the so-called "transition mechanisms" just went away.
I am all for getting fewer people to use 6to4, especially without them actually making a decision to use it, but giving more people access to high quality (I hope they are) 6to4 relays is seldom a downside. The drafts you mention make special notes that operators should NOT start to shut down relays, first of all we need to get fewer people to use 6to4, THEN we start to remove the relays. Starting at the relay end is bad, mmkay. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Apr 19, 2011 2:56 PM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
On Tue, 19 Apr 2011, Doug Barton wrote:
Another view (one that I personally hold) is that any effort you might be
putting into making 6to4 work better would be better placed in deploying real IPv6 instead; and that the world would be a better place generally if all of the so-called "transition mechanisms" just went away.
I am all for getting fewer people to use 6to4, especially without them
actually making a decision to use it, but giving more people access to high quality (I hope they are) 6to4 relays is seldom a downside.
The drafts you mention make special notes that operators should NOT start
to shut down relays, first of all we need to get fewer people to use 6to4, THEN we start to remove the relays. Starting at the relay end is bad, mmkay.
+1. 6to4 is very bad and should be off my default, but unfortunately many end users unwittingly have it on and this may provide them some relief. More ipv6 leadership from the Comcast camp. Keep it up. Cb
-- Mikael Abrahamsson email: swmike@swm.pp.se
On Tue, 2011-04-19 at 16:47 -0700, Cameron Byrne wrote:
On Apr 19, 2011 2:56 PM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
+1. 6to4 is very bad and should be off my default, but unfortunately many end users unwittingly have it on and this may provide them some relief.
So am I to understand that services like Toredo client (which is what I PRESUME is being discussed) is on automatically in some Windows desktop systems? The drafts I saw posted earlier were discussing what is essentially toredo services (anycast tunnel) at least. If this is on by default, then that is only bad (in my opinion) IF there is no native IPv6 support on the LAN side of these networks. Maybe I am missing something, but this is my take.
More ipv6 leadership from the Comcast camp. Keep it up.
Seems to me that if Comcast has "announced IPv6 support" and it is not NATIVE IPV6 support, then that is certainly a problem. Either way, there certainly IS a place in networks for Toredo services, since SO MANY devices for the CPE end of the connectivity equation still have zero support for IPv6. It's not the best solution for sure, but the fact remains that most networks will be dual-stacked at least initially at the core, but the endpoints (customer networks) are outside of our administrative control and often are behind devices that we do not control/own. Maybe I'm missing something... -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * * NOTE MY NEW NUMBER: 702-537-0979 * ********************************************************************
Butch, On Tue, Apr 19, 2011 at 8:52 PM, Butch Evans <butche@butchevans.com> wrote:
The drafts I saw posted earlier were discussing what is essentially toredo services (anycast tunnel) at least.
6to4 is significantly different from Teredo, since it: a) it does not hurt web deployments using DNS records for their resources (src/dst addr selection, and more) b) it works from behind a NAT,
If this is on by default, then that is only bad (in my opinion) IF there is no native IPv6 support on the LAN side of these networks. Maybe I am missing something, but this is my take.
In the case of 6to4, this is only true if your source/destination address selection works properly. Teredo adds extra safety to really make it a ipv4->ipv6 connection mechanism of last resort.
Either way, there certainly IS a place in networks for Toredo services, since SO MANY devices for the CPE end of the connectivity equation still have zero support for IPv6.
I must point you to Geoff Hustons most recent ISP posting: http://www.potaroo.net/ispcol/2011-04/teredo.html It gives a very good picture of the Teredo support out in the wild. It also makes it abundantly clear that Teredo is not a reliable auto-tunneling mechanism (if such a mechanism ever can exist): 6to4 looks like flawlessness in comparison with Teredo when it comes to connection success ratios. Yet, virtually nobody has so far been complaining over issues caused by Teredo being active on their hosts. And there are some situations where it is OK that only 2 out of 3 connections succeed, if it means your system can work better: Notably, peer-to-peer applications can make use of this to establish connections in a cloud, using DHT instead of DNS for peer propagation, and Teredo relays as the rendezvous mechanism. I would, however, not want to rely on this for calls in Skype, for example. My (current) personal opinion on the situation is that application developers who do not want to use the last-resort NAT-"trespassing" method of establishing connectivity that Teredo supplies, must decide in their code not to use it. Some peer-to-peer applications have been known for years to come with a "Enable IPv6"-button, because it improved the applications performance to do so. So, in a world where some applications will enable it, other applications will have to *not use it*, else the applications will end-up in a race-condition on whether the protocol is enabled or not.
It's not the best solution for sure, but the fact remains that most networks will be dual-stacked at least initially at the core, but the endpoints (customer networks) are outside of our administrative control and often are behind devices that we do not control/own. Maybe I'm missing something...
AFAIK, there's ongoing work in IETF to address this. I think one of the wg's is "softwire", http://tools.ietf.org/wg/softwire/ , but I have not followed this at all. Regards, Martin
On 20/04/2011, at 11:43 AM, Martin Millnert wrote:
Either way, there certainly IS a place in networks for Toredo services, since SO MANY devices for the CPE end of the connectivity equation still have zero support for IPv6.
If you are prepared to tolerate a connection failure rate in the order of 37% or so, then I could agree with you, but that's a pretty impressive failure rate!
I must point you to Geoff Hustons most recent ISP posting: http://www.potaroo.net/ispcol/2011-04/teredo.html
...
And there are some situations where it is OK that only 2 out of 3 connections succeed, if it means your system can work better: Notably, peer-to-peer applications can make use of this to establish connections in a cloud, using DHT instead of DNS for peer propagation, and Teredo relays as the rendezvous mechanism.
In my opinion any service that runs at a 37% failure rate of connections is a disservice. The peer-to-peer folk can tolerate its miserable reliability and lousy performance because of the massive redundancy in the peer-to-peer environment that means that that a peer-to-peer player can just ignore the connections that fail. But do we need to head to use applications that build in huge margins of oversupply in their communications model just to tolerate the unreliability of Teredo? Geoff
On Apr 19, 2011, at 5:52 PM, Butch Evans wrote:
+1. 6to4 is very bad and should be off my default, but unfortunately many end users unwittingly have it on and this may provide them some relief.
So am I to understand that services like Toredo client (which is what I PRESUME is being discussed) is on automatically in some Windows desktop systems?
No. 6to4 is RFC 3056/3068, and Teredo is a proprietary Microsoft technology documented in RFC 4380 with its updates. John and Cameron are talking about 6to4.
Hi All, Can anybody point me to a documented case where a bug in Cisco IOS has taken a whole network down ? Regards and thanks in advance Eric Parsonage
Hi Eric, You might want to read up on : http://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experimen t The cisco case involved : http://www.cisco.com/en/US/products/products_security_advisory09186a0080b441 1f.shtml Short detail from the Cisco site: This vulnerability affects Cisco IOS XR devices running affected software versions and configured with the BGP routing feature. The vulnerability manifests itself when a BGP peer announces a prefix with a specific, valid but unrecognized transitive attribute. On receipt of this prefix, the Cisco IOS XR device will corrupt the attribute before sending it to the neighboring devices. Neighboring devices that receive this corrupted update may reset the BGP peering session. Could you provide insight in why you are specifically looking for a Cisco IOS bug that has taken down a network ? Regards, Erik Bais
Dear Eric,
Can anybody point me to a documented case where a bug in Cisco IOS has taken a whole network down ?
The ripe experiment is really a great one. A "little" bit older one, but bigger - took down the whole internet: 1) http://markmail.org/message/nmlyif7oycohcr22 2) http://www.atm.tut.fi/list-archive/nanog/msg04507.html Kind regards, Ingo Flaschberger
Doug, I am aware of the drafts you cited earlier, as Mikael mentions below the existence of the same will not result in 6to4 being turned off automatically or immediately. This process will likely take years. Please note the goal here is not to make 6to4 great, like many others we hope to see 6to4 use diminish over time. Thanks, 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 4/19/11 5:55 PM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
On Tue, 19 Apr 2011, Doug Barton wrote:
Another view (one that I personally hold) is that any effort you might be putting into making 6to4 work better would be better placed in deploying real IPv6 instead; and that the world would be a better place generally if all of the so-called "transition mechanisms" just went away.
I am all for getting fewer people to use 6to4, especially without them actually making a decision to use it, but giving more people access to high quality (I hope they are) 6to4 relays is seldom a downside.
The drafts you mention make special notes that operators should NOT start to shut down relays, first of all we need to get fewer people to use 6to4, THEN we start to remove the relays. Starting at the relay end is bad, mmkay.
-- Mikael Abrahamsson email: swmike@swm.pp.se
On 04/20/2011 10:54, Brzozowski, John wrote:
Doug,
I am aware of the drafts you cited earlier, as Mikael mentions below the existence of the same will not result in 6to4 being turned off automatically or immediately. This process will likely take years.
I was going to let this go, but after so many responses in the same vein I feel compelled to clarify. *I personally* believe that the answer to 6to4 is to just turn it off. These things have long tails because we insist that they do, not because they have to. *However,* I am realistic enough to know that it isn't going to happen, regardless of how disappointed I may be about that. :)
Please note the goal here is not to make 6to4 great, like many others we hope to see 6to4 use diminish over time.
"Hope is not a plan." Meanwhile, my main goal in posting was to make sure that to the extent that you(Comcast) intend to make changes to your 6to4 infrastructure that you take into account the current thinking about that, and I'm very pleased to hear that you have. best regards, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
On Apr 20, 2011, at 11:25 AM, Doug Barton wrote:
On 04/20/2011 10:54, Brzozowski, John wrote:
Doug,
I am aware of the drafts you cited earlier, as Mikael mentions below the existence of the same will not result in 6to4 being turned off automatically or immediately. This process will likely take years.
I was going to let this go, but after so many responses in the same vein I feel compelled to clarify. *I personally* believe that the answer to 6to4 is to just turn it off. These things have long tails because we insist that they do, not because they have to. *However,* I am realistic enough to know that it isn't going to happen, regardless of how disappointed I may be about that. :)
Turnning off the servers will not reduce the brokenness of 6to4, it will increase it. The best way to get rid of 6to4 is to deploy native IPv6. The best way to improve 6to4 behavior until that time is to deploy more, not less 6to4 relays. Hurricane Electric has proven this. Comcast has proven this. Every provider that has deployed more 6to4 relays has proven this.
Please note the goal here is not to make 6to4 great, like many others we hope to see 6to4 use diminish over time.
"Hope is not a plan." Meanwhile, my main goal in posting was to make sure that to the extent that you(Comcast) intend to make changes to your 6to4 infrastructure that you take into account the current thinking about that, and I'm very pleased to hear that you have.
The best way to make 6to4 diminish has always been and still remains: Deploy Native IPv6 Now. That's a plan and a necessity at this point, but, execution is still somewhat lagging. Owen
On Apr 20, 2011, at 3:50 03PM, Owen DeLong wrote:
On Apr 20, 2011, at 11:25 AM, Doug Barton wrote:
On 04/20/2011 10:54, Brzozowski, John wrote:
Doug,
I am aware of the drafts you cited earlier, as Mikael mentions below the existence of the same will not result in 6to4 being turned off automatically or immediately. This process will likely take years.
I was going to let this go, but after so many responses in the same vein I feel compelled to clarify. *I personally* believe that the answer to 6to4 is to just turn it off. These things have long tails because we insist that they do, not because they have to. *However,* I am realistic enough to know that it isn't going to happen, regardless of how disappointed I may be about that. :)
Turnning off the servers will not reduce the brokenness of 6to4, it will increase it.
The best way to get rid of 6to4 is to deploy native IPv6. The best way to improve 6to4 behavior until that time is to deploy more, not less 6to4 relays. Hurricane Electric has proven this. Comcast has proven this. Every provider that has deployed more 6to4 relays has proven this.
Please note the goal here is not to make 6to4 great, like many others we hope to see 6to4 use diminish over time.
"Hope is not a plan." Meanwhile, my main goal in posting was to make sure that to the extent that you(Comcast) intend to make changes to your 6to4 infrastructure that you take into account the current thinking about that, and I'm very pleased to hear that you have.
The best way to make 6to4 diminish has always been and still remains:
Deploy Native IPv6 Now.
That's a plan and a necessity at this point, but, execution is still somewhat lagging.
Of course, Comcast *is* deploying native IPv6; see, for example, http://mailman.nanog.org/pipermail/nanog/2011-January/031624.html It just takes a while -- and a non-trivial number of zorkmids -- to do things like replacing all of the non-v6 CPE. --Steve Bellovin, https://www.cs.columbia.edu/~smb
The best way to make 6to4 diminish has always been and still remains:
Deploy Native IPv6 Now.
That's a plan and a necessity at this point, but, execution is still somewhat lagging.
Of course, Comcast *is* deploying native IPv6; see, for example, http://mailman.nanog.org/pipermail/nanog/2011-January/031624.html It just takes a while -- and a non-trivial number of zorkmids -- to do things like replacing all of the non-v6 CPE.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Comcast was not the target of my comment... The networks saying Comcast shouldn't help the rest of the net by providing open 6to4 relays were the ones I was referring to. I again applaud Comcast's leadership on IPv6 to the end user, even if they haven't gotten it to me yet. ;-) Owen
On 04/20/2011 04:44 PM, Owen DeLong wrote:
The best way to make 6to4 diminish has always been and still remains:
Deploy Native IPv6 Now.
That's a plan and a necessity at this point, but, execution is still somewhat lagging.
Of course, Comcast *is* deploying native IPv6; see, for example, http://mailman.nanog.org/pipermail/nanog/2011-January/031624.html It just takes a while -- and a non-trivial number of zorkmids -- to do things like replacing all of the non-v6 CPE.
--Steve Bellovin, https://www.cs.columbia.edu/~smb Comcast was not the target of my comment... The networks saying Comcast shouldn't help the rest of the net by providing open 6to4 relays were the ones I was referring to.
I again applaud Comcast's leadership on IPv6 to the end user, even if they haven't gotten it to me yet. ;-)
They already have if you can run either 6rd or 6to4 and are a Comcast customer, even if you didn't happen to know they had. (Though they do plan to turn off the 6rd hack they were using this summer; their native trial and 6to4 work well enough to not need yet another transition mechanism). Their kind offer is to extend availability of their 6to4 relays to others who aren't even Comcast customers... (Says this reasonably happy participant in Comcast's IPv6 trial; my unhappiness is the state of CPE firmware, not with how well Comcast's end of things work; I plan to ditch commercial firmware on my home router for OpenWRT momentarily...) - Jim
Sent from my iPad On Apr 20, 2011, at 4:26 PM, Jim Gettys <jg@freedesktop.org> wrote:
On 04/20/2011 04:44 PM, Owen DeLong wrote:
The best way to make 6to4 diminish has always been and still remains:
Deploy Native IPv6 Now.
That's a plan and a necessity at this point, but, execution is still somewhat lagging.
Of course, Comcast *is* deploying native IPv6; see, for example, http://mailman.nanog.org/pipermail/nanog/2011-January/031624.html It just takes a while -- and a non-trivial number of zorkmids -- to do things like replacing all of the non-v6 CPE.
--Steve Bellovin, https://www.cs.columbia.edu/~smb Comcast was not the target of my comment... The networks saying Comcast shouldn't help the rest of the net by providing open 6to4 relays were the ones I was referring to.
I again applaud Comcast's leadership on IPv6 to the end user, even if they haven't gotten it to me yet. ;-)
They already have if you can run either 6rd or 6to4 and are a Comcast customer, even if you didn't happen to know they had. (Though they do plan to turn off the 6rd hack they were using this summer; their native trial and 6to4 work well enough to not need yet another transition mechanism).
I'm already running IPv6 over 6in4 tunnels to my cool routers. 6rd is not an improvement. I'm looking forward to the day when Comcast can deliver straight native IPv6 to me.
Their kind offer is to extend availability of their 6to4 relays to others who aren't even Comcast customers...
(Says this reasonably happy participant in Comcast's IPv6 trial; my unhappiness is the state of CPE firmware, not with how well Comcast's end of things work; I plan to ditch commercial firmware on my home router for OpenWRT momentarily...) - Jim
lol... The commercial JunOS on my home gateway seems to be working OK. Owen
On 04/20/2011 12:50, Owen DeLong wrote:
Turnning off the servers will not reduce the brokenness of 6to4, it will increase it.
Depends on your definitions of "increase" and "broken." If all the relays disappeared tomorrow then the failure rate would be 100%, sure. But that would mean a single, (more or less) instant, deterministic failure that any modern OS ought to be able to handle intelligently; rather than the myriad of ways that 6to4 can half-succeed now. To me, that's a win. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Sent from my iPad On Apr 20, 2011, at 4:09 PM, Doug Barton <dougb@dougbarton.us> wrote:
On 04/20/2011 12:50, Owen DeLong wrote:
Turnning off the servers will not reduce the brokenness of 6to4, it will increase it.
Depends on your definitions of "increase" and "broken." If all the relays disappeared tomorrow then the failure rate would be 100%, sure. But that would mean a single, (more or less) instant, deterministic failure that any modern OS ought to be able to handle intelligently; rather than the myriad of ways that 6to4 can half-succeed now. To me, that's a win.
Uh, no. It would, indeed, be a single deterministic failure. However, most OS are coded that if there isn't native, they'll try 6to4 if it's turned on. Many OS have it turned on by default. As such, it would simply be a 100% failure, not one that was automatically dealt with in a rational or useful manner. It would require manual intervention on a large number of hosts. To me, that's not a win. That's a loss. The success rate for 6to4 today in most environments is close to 90%. There are many environments in widespread use today (hotel networks and airports come to mind) where IPv4 does not enjoy that level of success. Owen
On Wed, Apr 20, 2011 at 16:09, Doug Barton <dougb@dougbarton.us> wrote:
On 04/20/2011 12:50, Owen DeLong wrote:
Turnning off the servers will not reduce the brokenness of 6to4, it will increase it.
Depends on your definitions of "increase" and "broken." If all the relays disappeared tomorrow then the failure rate would be 100%, sure. But that would mean a single, (more or less) instant, deterministic failure that any modern OS ought to be able to handle intelligently; rather than the myriad of ways that 6to4 can half-succeed now. To me, that's a win.
While I can appreciate that 6to4 is far from perfect, and can create broken situations - I will also admit to using 6to4 on more than an occasional basis ... whether that be because: - my aircard gets a public IPv4 address, and thus 6to4 spins up automatically - my Linksys CPE, out of the box, does 6to4 (SLAAC-advertising a prefix) - thus all of my home PCs do it as well (Win*, Ubuntu, etc.) I find 6to4 to be far superior to no IPv6 connectivity, far easier than launching a TSP client (which I also have, just in case) ... and, in fact, to largely "just work" for all of my machines. More relays will do nothing but make this better, and as native IPv6 becomes available I will happily (and automatically!) move to that instead. /TJ ... also a happy Comcast 6RD-beta user right now, so technically I am not using 6to4 at home *right now* (but will be using 6to4 again after June 30th, when the 6RD trial ends).
John, On Tue, Apr 19, 2011 at 4:44 PM, Brzozowski, John <John_Brzozowski@cable.comcast.com> wrote:
Folks,
Since deploying our 6to4 relays, Comcast has observed a substantial reduction in the latency associated with the use of 6to4. As such we are contemplating further opening our relays for use by others. The availability of our 6to4 relays should improve the experience of others using 6to4 as a means to access content and services over IPv6.
I think it is a correct and welcome move on the north american internet market and that it will improve 6to4 performance there as 6to4 is phased out. Regards, Martin
Mr. John, I thank you for asking the advice of the community. As our colleagues suggest, having 6to4 relays inside the network helps to reduce the latency. Opening up your generous services to a larger Internet community by advertising the 192.88.99.0/24 BGP prefix outside the network could have extreme and unintended consequences. To give you an idea, a lot of the Internet in India depends on the service of the Tata companies, with international routing coming from Tata Communications AS 6453. Announcing 192.88.99.0/24 to 6453 as a customer, I would worry about its treatment as BGP best-path, in place of closer 6to4 relays. As you understand, these circuits are very far away, and also very full. This is not something I would recommend. Sincerely, Bhoomi Jain At 19 Apr 2011 22:51:24 +0200 (CEST) from "Brzozowski, John" <John_Brzozowski@Cable.Comcast.com>:
Folks, Since deploying our 6to4 relays, Comcast has observed a substantial reduction in the latency associated with the use of 6to4. As such we are contemplating further opening our relays for use by others. The availability of our 6to4 relays should improve the experience of others using 6to4 as a means to access content and services over IPv6. We have been open about our IPv6 activities and wanted to follow suit by reaching out to the community and soliciting feedback before moving forward. As always we wish to continue to advocate and support the universal deployment of IPv6. Please send any comments or questions to the list or if you wish to me directly. 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 Tue, Apr 19, 2011 at 7:26 PM, Bhoomi Jain <bhoomij@india.com> wrote:
Mr. John,
I thank you for asking the advice of the community.
As our colleagues suggest, having 6to4 relays inside the network helps to reduce the latency. Opening up your generous services to a larger Internet community by advertising the 192.88.99.0/24 BGP prefix outside the network could have extreme and unintended consequences.
To give you an idea, a lot of the Internet in India depends on the service of the Tata companies, with international routing coming from Tata Communications AS 6453. Announcing 192.88.99.0/24 to 6453 as a customer, I would worry about its treatment as BGP best-path, in place of closer 6to4 relays. As you understand, these circuits are very far away, and also very full. This is not something I would recommend.
Sincerely, Bhoomi Jain
On the contrary; I think Comcast announcing their 6to4 relays through TATA could be just the incentive the Internet needs to kick the 6to4 habit completely, and decide once and for all the only sane option is dual-stack native. ;-) Matt
On Wed, 20 Apr 2011, Bhoomi Jain wrote:
To give you an idea, a lot of the Internet in India depends on the service of the Tata companies, with international routing coming from Tata Communications AS 6453. Announcing 192.88.99.0/24 to 6453 as a customer, I would worry about its treatment as BGP best-path, in place of closer 6to4 relays. As you understand, these circuits are very far away, and also very full. This is not something I would recommend.
Perhaps you should try convincing Tata to setup their own 6to4 relay so they can provide a better experience for their own customers who, for whatever reason, may not be able to get or use native IPv6 for quite some time. -- Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
The better solution to that problem is to get additional 6to4 relays deployed closer to India. Perhaps encouraging Tata to take some leadership in that area, for example. I do not believe that the opening of the Comcast relays will harm BGP best path selection for the 6to4 prefix except in rather broken and/or pathological cases of BGP best path selection. Those cases should be relatively easy to identify and correct locally without preventing Comcast from significantly improving the 6to4 situation for the areas they serve by opening their relays. I applaud John for his leadership in this area and I think the IPv6 work being done by Comcast sets a good example for the community. As a Comcast customer, praising Comcast does not come easy to me, but, in this area, they are doing excellent things and should be commended. Owen Sent from my iPad On Apr 19, 2011, at 10:26 PM, Bhoomi Jain <bhoomij@india.com> wrote:
Mr. John,
I thank you for asking the advice of the community.
As our colleagues suggest, having 6to4 relays inside the network helps to reduce the latency. Opening up your generous services to a larger Internet community by advertising the 192.88.99.0/24 BGP prefix outside the network could have extreme and unintended consequences.
To give you an idea, a lot of the Internet in India depends on the service of the Tata companies, with international routing coming from Tata Communications AS 6453. Announcing 192.88.99.0/24 to 6453 as a customer, I would worry about its treatment as BGP best-path, in place of closer 6to4 relays. As you understand, these circuits are very far away, and also very full. This is not something I would recommend.
Sincerely, Bhoomi Jain
At 19 Apr 2011 22:51:24 +0200 (CEST) from "Brzozowski, John" <John_Brzozowski@Cable.Comcast.com>:
Folks, Since deploying our 6to4 relays, Comcast has observed a substantial reduction in the latency associated with the use of 6to4. As such we are contemplating further opening our relays for use by others. The availability of our 6to4 relays should improve the experience of others using 6to4 as a means to access content and services over IPv6. We have been open about our IPv6 activities and wanted to follow suit by reaching out to the community and soliciting feedback before moving forward. As always we wish to continue to advocate and support the universal deployment of IPv6. Please send any comments or questions to the list or if you wish to me directly. 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] =========================================
Mr. Delong, I am simply trying to explain that running a 6to4 on your network is a good idea, however advertising the anycast prefix to other networks has some risk, especially if you're experiencing problems with your Internet peerings. Hopefully Comcast will upgrade its capacity soon. I appreciate Mr. John's continued leadership and contribution to the IPv6. Sincerely, Bhoomi Jain At 20 Apr 2011 14:51:48 +0200 (CEST) from Owen DeLong <owen@delong.com>:
The better solution to that problem is to get additional 6to4 relays deployed closer to India. Perhaps encouraging Tata to take some leadership in that area, for example. I do not believe that the opening of the Comcast relays will harm BGP best path selection for the 6to4 prefix except in rather broken and/or pathological cases of BGP best path selection. Those cases should be relatively easy to identify and correct locally without preventing Comcast from significantly improving the 6to4 situation for the areas they serve by opening their relays. I applaud John for his leadership in this area and I think the IPv6 work being done by Comcast sets a good example for the community. As a Comcast customer, praising Comcast does not come easy to me, but, in this area, they are doing excellent things and should be commended. Owen
Sent from my iPad On Apr 19, 2011, at 10:26 PM, Bhoomi Jain <bhoomij@india.com> wrote:
Mr. John,
I thank you for asking the advice of the community.
As our colleagues suggest, having 6to4 relays inside the network helps to reduce the latency. Opening up your generous services to a larger Internet community by advertising the 192.88.99.0/24 BGP prefix outside the network could have extreme and unintended consequences.
To give you an idea, a lot of the Internet in India depends on the service of the Tata companies, with international routing coming from Tata Communications AS 6453. Announcing 192.88.99.0/24 to 6453 as a customer, I would worry about its treatment as BGP best-path, in place of closer 6to4 relays. As you understand, these circuits are very far away, and also very full. This is not something I would recommend.
Sincerely, Bhoomi Jain
At 19 Apr 2011 22:51:24 +0200 (CEST) from "Brzozowski, John" <John_Brzozowski@[Cable.Comcast.com]>:
Folks, Since deploying our 6to4 relays, Comcast has observed a substantial reduction in the latency associated with the use of 6to4. As such we are contemplating further opening our relays for use by others. The availability of our 6to4 relays should improve the experience of others using 6to4 as a means to access content and services over IPv6. We have been open about our IPv6 activities and wanted to follow suit by reaching out to the community and soliciting feedback before moving forward. As always we wish to continue to advocate and support the universal deployment of IPv6. Please send any comments or questions to the list or if you wish to me directly. 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]] =========================================
1. Yes. 2. Perhaps, but, it's minimal internal risk and the risk it poses to others can be mitigated by those others installing appropriate services on their own networks. 3. We agree here as well. Owen On Apr 20, 2011, at 9:33 AM, Bhoomi Jain wrote:
Mr. Delong,
I am simply trying to explain that running a 6to4 on your network is a good idea, however advertising the anycast prefix to other networks has some risk, especially if you're experiencing problems with your Internet peerings. Hopefully Comcast will upgrade its capacity soon. I appreciate Mr. John's continued leadership and contribution to the IPv6.
Sincerely, Bhoomi Jain
At 20 Apr 2011 14:51:48 +0200 (CEST) from Owen DeLong <owen@delong.com>:
The better solution to that problem is to get additional 6to4 relays deployed closer to India. Perhaps encouraging Tata to take some leadership in that area, for example. I do not believe that the opening of the Comcast relays will harm BGP best path selection for the 6to4 prefix except in rather broken and/or pathological cases of BGP best path selection. Those cases should be relatively easy to identify and correct locally without preventing Comcast from significantly improving the 6to4 situation for the areas they serve by opening their relays. I applaud John for his leadership in this area and I think the IPv6 work being done by Comcast sets a good example for the community. As a Comcast customer, praising Comcast does not come easy to me, but, in this area, they are doing excellent things and should be commended. Owen
Sent from my iPad On Apr 19, 2011, at 10:26 PM, Bhoomi Jain <bhoomij@india.com> wrote:
Mr. John,
I thank you for asking the advice of the community.
As our colleagues suggest, having 6to4 relays inside the network helps to reduce the latency. Opening up your generous services to a larger Internet community by advertising the 192.88.99.0/24 BGP prefix outside the network could have extreme and unintended consequences.
To give you an idea, a lot of the Internet in India depends on the service of the Tata companies, with international routing coming from Tata Communications AS 6453. Announcing 192.88.99.0/24 to 6453 as a customer, I would worry about its treatment as BGP best-path, in place of closer 6to4 relays. As you understand, these circuits are very far away, and also very full. This is not something I would recommend.
Sincerely, Bhoomi Jain
At 19 Apr 2011 22:51:24 +0200 (CEST) from "Brzozowski, John" <John_Brzozowski@[Cable.Comcast.com]>:
Folks, Since deploying our 6to4 relays, Comcast has observed a substantial reduction in the latency associated with the use of 6to4. As such we are contemplating further opening our relays for use by others. The availability of our 6to4 relays should improve the experience of others using 6to4 as a means to access content and services over IPv6. We have been open about our IPv6 activities and wanted to follow suit by reaching out to the community and soliciting feedback before moving forward. As always we wish to continue to advocate and support the universal deployment of IPv6. Please send any comments or questions to the list or if you wish to me directly. 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]] =========================================
participants (20)
-
Antonio Querubin -
Bhoomi Jain -
Brzozowski, John -
Butch Evans -
Cameron Byrne -
Doug Barton -
Eric Parsonage -
Erik Bais -
Fred Baker -
Geoff Huston -
Ingo Flaschberger -
Jared Mauch -
Jim Gettys -
Martin Millnert -
Matthew Petach -
Mikael Abrahamsson -
Owen DeLong -
Randy Bush -
Steven Bellovin -
TJ