In message
<20110615022008(_dot_)0816818C172(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu>,
Noel Chiappa write
s:
> From: Keith Moore <moore(_at_)network-heretics(_dot_)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(_at_)ietf(_dot_)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: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf