Comcast's 6to4 Relays

Mailman List Mirror (Read Only)
1

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

2

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

3

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

4

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.

5

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

6

John,

7

>
+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...

8

Butch,

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

9

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.

10

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

11

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. :wink:

Matt

12

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.

13

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

14

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

15

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

16

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

17

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

18

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

19

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

20

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. :slight_smile:

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