Subject: Re: one data point regarding native IPv6 support

From: [email-masked] (Noel Chiappa)
Date: Tue, 14 Jun 2011 22:20:08 -0400 (EDT)

> From: Keith Moore <[email-masked]>

    > 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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Jun 2011 13:01:29 +1000

In message <[email-masked]>, Noel Chiappa write
> 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.
 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Wed, 15 Jun 2011 14:12:47 +0000

>From Noel analysis, it seems that a lot of the issues could be mitigated by a simple connectivity test. Have the 6to4 router perform a simple ping test through the tentative 6to4 relay, towards some well-known IPv6 host. Or an HTTP test, if we fear that ICMPv6 might be somehow tampered with.  If the test succeed, then it shows that the path to that 6to4 relay is clear of firewalls and other obstructions. If the path is not clear, pick another 6to4 relay, or do not enable 6to4.

Of course, this does not solve the problem of intermittent failures on the IPv4 path to the relay, e.g. due to congestion. 

It also does not solve the problem of routers advertising an IPv6 route to 2002::/16 and then failing to deliver the IPv4 packets. But this "return" problem is easily solved by IPv6 ISP deploying their own 6to4 routers, and thus avoiding dependencies on a "generic" path to 2002::/16.

-- Christian Huitema

---

From: Mark Andrews <[email-masked]>
Date: Thu, 16 Jun 2011 10:00:24 +1000

In message <[email-masked]
eploy.ntdev.microsoft.com>, Christian Huitema writes:
> >From Noel analysis, it seems that a lot of the issues could be mitigated by=
>  a simple connectivity test. Have the 6to4 router perform a simple ping tes=
> t through the tentative 6to4 relay, towards some well-known IPv6 host. Or a=
> n HTTP test, if we fear that ICMPv6 might be somehow tampered with.  If the=
>  test succeed, then it shows that the path to that 6to4 relay is clear of f=
> irewalls and other obstructions. If the path is not clear, pick another 6to=
> 4 relay, or do not enable 6to4.
> 
> Of course, this does not solve the problem of intermittent failures on the =
> IPv4 path to the relay, e.g. due to congestion.

But happy-eyeballs does mostly solve that problem.  If the path is
congested and dropping packets then the IPv6 connect will likely
not succeed before the IPv4 connect succeeds.  happy-eyeballs also
deals with relay routers that are topologically bad for the destination
machines which are dual stack.

> It also does not solve the problem of routers advertising an IPv6 route to =
> 2002::/16 and then failing to deliver the IPv4 packets. But this "return" p=
> roblem is easily solved by IPv6 ISP deploying their own 6to4 routers, and t=
> hus avoiding dependencies on a "generic" path to 2002::/16.
> 
> -- Christian Huitema