[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6to4 connectivity test
On 2/02/2008, at 8:37 AM, james woodyatt wrote:
On Feb 1, 2008, at 10:35, Christian Huitema wrote:
OK. So, what would we changed in 6to4 if we optimized for host-
based or CPE-based deployment? Do we trust that we will get enough
6to4 gateways deployed to sustain growth, or do we need to add a
"gateway discovery service" similar to the Teredo spec?
A standard method of discovering whether the 6to4 relay at the
anycast address is functioning properly would be a fine idea.
At the moment, some very large ISP's are now hindering transition to
IPv6 by forwarding 6to4 packets to relays that are black-holing them
rather than forwarding them. (This was not the case when AirPort
Extreme shipped.) These ISP's have no plans to deploy 6to4 relays
in their own IPv6-capable networks, nor do they have any plan to
forward 6to4 traffic to relays that will carry it for them. This is
making some large content providers *remove* their AAAA records when
they discover that customers behind 6to4 routers, e.g. AirPort
Extreme, are unable to receive service because their applications do
not fall back to IPv4 when IPv6 connectivity is broken.
Search the Apple discussion boards for IPv6, and you will see that a
lot of people are turning off IPv6 entirely on their computers to
work around the connectivity issues involved here.
Yup, I wrote an email here some time ago about this: "6to4 and
'campus' networks".
My comments were more in relation to end hosts turning on 6to4 when
they had non-RFC1918 addresses, but it still applies in the case of
CPE turning on 6to4 in a similar situation (perhaps the CPE is behind
NAT, or a firewall of some kind, or has a broken relay, etc.).
Applications /do/ fall back in my experience, however they take a long
time to do so - I think my Mac did it in around 90 seconds or so when
I last looked. Obviously, way past the user getting impatient, and
declaring it 'broken'.
I'd be happy to follow it up, I've had a few thoughts about how this
could work since then, and some thoughts about how it's painful. I'll
write more when it's not 3am, however.
Some things to leave you with for now;
- 6to4 relays for the forward and reverse path between two hosts are
likely to be different
- Teredo gets around problems by testing the relay bidirectionally
when talking to any new host (no asymmetric relaying in Teredo of
course)
- Any initial test needs to make sure that the following are both
reachable bidirectionally, so we are sure we are not behind a stateful
firewall, or NAT, etc.:
o Host reachable through the magic (192.88.99.1) relay
o 6to4 host that is not in 2002:c058:6301::/48 (192.88.99.1)
- If we are amending some parts of 6to4, should we consider optionally
doing Teredo-like tricks for discovering relays closer to the non-6to4
host? (ie. look at the IPv4 src addr in incoming packet, and use that
for reaching that host in the future). Can we trigger that by doing an
ICMPv6 echo request (as Teredo does), which would also verify that the
selected relay is working.
Cheers,
--
Nathan Ward