Re: [6bed4-devel] Comments and thoughts on bed64
zeroconfig IPv6 tunnel
Status: Beta
Brought to you by:
vanrein
From: <ebi...@xm...> - 2012-07-23 14:50:15
|
Timothy Baldwin <tim...@fa...> writes: > On 15/06/12 08:35, Eric W. Biederman wrote: >> - Well known vs providered assigned addresses: >> >> Automatic tunnel like 6to4 and Teredo without a well defined place of >> where do you look to find the problems and who do you blame have been >> undebuggable. 6rd on the other hand works well enough it is being >> rolled out by several vendors in production deployment, because they >> can isolate all of the bits within their own networks. > It's easy to know who to blame for a broken Teredo relay - the ISP > providing (non-Teredo) IPv6 connectivity, a particular IPv6 host will > use the same Teredo relay for connection to all Teredo clients.. If the > IPv6 ISP isn't operating a relay they can solve the problem by running > one. Teredo does however have other problems. I stopped and took a good hard look at Teredo, and not running a Teredo relay does not appear to be the only reason Teredo fails. If the data from http://www.potaroo.net/ispcol/2011-04/teredo.html is at all representative. Teredo not only gives up early when it has preconceived notions that it is behind a sucky NAT that it can't work with, but Teredo also fails to setup tunnels to the local Teredo relay. > Also almost all the references broken 6to4 relays I can find refer to > de-encapsulating IPv4 anycast relays, and I scanned all 110 web sites in > the Alexa top 1000 that have a IPv6 address on the domain from a 6to4 > address and found no 6to4 blackholes. Richard Barnes also found the same > with World IPv6 day participants, > https://labs.ripe.net/Members/rbarnes/world-ipv6-day-asymmetric-6to4-measurements. > This would suggest that ISPs that provide IPv6 service make sure 6to4 > works, but many that don't provide IPv6 don't care about 6to4. That seems reasonable. 6to4 isn't totally beautiful but on a good day 6to4 works. There are failure modes where 6to4 mysteriously works in only one direction but those failure modes seem to be rare. It used to be common to have to go half way around the world to get a 6to4 relay, and that was also very strange. I expect poking at router servers and looking glass servers could explain why you don't have a local 6to4 router just like they roughly can explain just about any routing problem. >> Therefore I suggest 6bed4 learn from history and be designed to be >> used only with the gateway providers ivp6 addresses and to be >> primarily used with unicast ipv4 addresses going to those gateways. > A public profile with well known addresses will become increasingly > useful as the IPv6 transition progresses, providing reliable IPv6 > connectivity between hosts on a IPv4 only ISP and hosts on a IPv6 ISP > that runs a 6bed4 router. > > I so suggest the problems be fixed: > > If a flag is set (such as setting the IP version to 4) the 6bed4 router > should rewrite the beginning of the IPv6 source address to it's own > unicast prefix when de-encapsulating. A traceroute implementation could > use this to trace though a 6bed4 router from a 6bed4 client. Simply using not replying with a 6bed4 ipv6 address in icmp errors achieves this without a flag. > 6bed4 routers should include their unicast IPv4 address and a nonce > specific to the client in all IPv4 packets they send. If 6bed4 routers > receive a IPv4 encapsulated IPv6 packet with a correct nonce they should > de-encapsulate and forward it even if IPv4 source address doesn't > match. Including a nonce specific to a client requires keeping client specific state which limits scalability, and reliability. > The clients could then locate a router near the remote end by sending a > ICMPv6 Echo Request and recording the unicast IPv4 address in the > response. The Teredo trick of using an Echo Request to find the closest router is very clever. Having looked at that idea in some detail now a much less clever and much more effective technique is to simply send a request to setup a tunnel to the destination ipv6 address. It works or it doesn't and it is unaffected by unrelated policy like allowing icmp echo requests. > With the majority of traffic kept away from routers discovered using > IPv4 anycast, the performance problem of routers discovered by Ipv4 > anycast diminishes, this however leaves the problem of completely broken > 6bed4 routers. This could be worked around by a client by using a > unicast address of a working router. If any NAT is cone or > port-preserving, or the router is running a local profile service based > on the unicast address the 6bed4 address will be correct; otherwise the > client will need to scan for the correct port. > > Or would a social solution to the problems of broken routers be more > practical? Anycast DNS does work. Perhaps better measurements of the > number of broken de-encapsulating 6to4 relays are needed? I think a social solution to broken routers is more acceptable. Hey your router is causing a black hole. I am going to filter you in BGP, go get your act together. >> I expect that in many deployments most of the traffic wil be destined >> for real ipv6 addresses so that skipping the 6bed4 router will be a >> false optimization. > > Or in many deployments, such a typical broadband network, skipping the > 6bed4 router is only beneficial if the hosts are on same link. If someone cares and deploys a 6bed4 router semi-locally I expect that is true. On the flip side I would prefer that someone would actually deploy native ipv6 instead. Largely the time for tunnels is past. It looks to me like 6bed4 will be the solution for people on hold out ISPs. Eric |