In message <20110615022008.0816818c...@mercury.lcs.mit.edu>, Noel Chiappa write s: > > From: Keith Moore <mo...@network-heretics.com> > > > As I understand it, the breakage mostly happens when the traffic > > doesn't take exactly the same path as IPv4 would, but rather when the > > traffic moves between the IPv4 world and the IPv6 world (or vice versa) > > via a relay router that's advertising a route to a network that it > > can't actually get traffic to. > > Though of course there are other sources of breakage: ISPs that filter > > protocol 41 ... and NATs, > > Keith, I'm not sure that relay routers advertising incorrectly are the main > problem (although none of the studies I've looked at are really comprehensive > in terms of data on _all_ causes of 6to4 failure, especially on failures on > the path _from_ the 6to4 host, which are obviously sort of impossible to > detect at servers). > > First, RFC-3068 does say: > > "Any 6to4 relay router corresponding to this specification must > include a monitoring function, to check that the 6to4 relay function > is operational. The router must stop injecting the route leading to > the 6to4 anycast prefix immediately if it detects that the relay > function is not operational." > > So if the 6to4 relay is operating properly, it shouldn't be advertising into > the IPv4 world (i.e. using the anycast address) unless it has 'good' IPv6 > connectivity, or into the IPv6 world (i.e. advertising the 6to4 block) unless > it has 'good' IPv4 connectivity. (Advertising only the 6to4 variants of those > pieces of the IPv4 space which it definitely has routes to is not allowed by > the spec; reasonably, as it would add the size of the IPv4 routing table to > the IPv6 routing table.) > > I'm not sure how exactly various boxes measure 'good' connectivity (and of > course a poor implementation might not do a good job of this), but in > _theory_ it shouldn't be the worst part of the problem. > > > Second, while I don't know about failures on the '4to6_host->relay_router' > (i.e. outbound) part of the path, when I read: > > http://www.potaroo.net/ispcol/2010-12/6to4fail.html > > it looked into failures on the 'relay_router->4to6_host' (i.e. inbound) path, > and there, of the failures which were not due to a problem in the relay > router itself, many were caused by failures on the inbound path between the > relay router and the 4to6_host, failures which may well be not the fault of > the ISP: > > - roughly 25% because of the presence of a NAT between the relay router and > the 4to6 host (so that the host did not know its public IPv4 address, and > probably didn't have a way to get packets to itself even if it did)
Presumable non-RFC 1918 internal addresses being NAT'd as RFC 1918 address are already verboten. > - roughly 75% because of the presence of some device between the relay router > and the 4to6 host that filtered _inbound_ protocol 41 (so that the host canno > t > get any return 6to4 traffic) > > While we don't know exactly what share of the overall 6to4 'problem' these tw > o > cause, we can guess that it's likely quite substantial: 'paranoid' firewalls > are common, and NAT boxes are basically ubiquitous (anyone with IP service at > home, and a wireless laptop - which is a lot of people - will have one). And making 6to4 historic fixes these without breaking 6to4 for those that it works for how? draft-andrews-v6ops-6to4-router-option-02.txt provides a mechanism which allows network operators for signal that 6to4 should not be used in both of the above cases. Similarly testing that you can reach the 6to4 relay router before adding a route pointing to it or advertising a 6to4 prefix is a good backup without the option however no all 6to4 relays have machine listening on the all zeros address. HE for example listens on 2002:c058:6301::1 so you can't just ping it. A I-D saying how to test if a 6to4 relay is up may be needed. Mark > Noel > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
