Re: one data point regarding native IPv6 support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



    > From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>

    > 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)

- 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 cannot
get any return 6to4 traffic)

While we don't know exactly what share of the overall 6to4 'problem' these two
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).

	Noel
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]