[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6to4 considered a bad thing
On Feb 1, 2008, at 3:48 PM, james woodyatt wrote:
Teredo went one step further. Public gateways can easily be abused.
So Teredo introduced a discovery mechanism to find out the best
gateway on a destination by destination basis. That mechanism is
little more than a ping, and could easily be ported to 6to4. We
could assume that 6to4 routers maintain a "routing cache"
associating specific "native IPv6" destinations with the "closest
6to4 gateway". Given a new IPv6 destination, the 6to4 router will
send a ping through the public server, note the IPv4 address from
which the ping comes back, and send the rest of the traffic through
This assumes the "ping" packets will pass through the same firewalls
as the packets that trigger them. If they don't produce a timely
response, what happens? Remember, at this point, there is a human
being sitting at a console watching a stalled progress bar and
waiting for a connection to go through. The connection they're
attempting is IPv6 because their host has a global IPv6 address
assigned (with a 2002:aabb:ccdd:xxxx:/64 prefix) and they got an
answer to a request for AAAA records.
Their host can connect to other hosts in 2002::/16 just fine. It's
only the non-2002::/16 address that are unreachable. So, how many
non-6to4 destinations do we have to "ping" before we decide to stop
advertising an IPv6 default route for those 2002:aabb:ccdd:xxxx::/64
Could requiring that anycasted 6to4 relays respond to an ICMP echo on
their v6 address, then sending a ping to 2002:c058:6301:: help? That
would at least prove connectivity to 18.104.22.168, and that something
there is listening.
That works for our relay, anyway:
$ ping6 2002:c058:6301::
PING6(56=40+8+8 bytes) 2002:451f:630e:1::1 --> 2002:c058:6301::
16 bytes from 2002:c058:6301::, icmp_seq=0 hlim=64 time=6.398 ms
And this proves at the very least that:
v6 6to4 address selection on my system came up with the right IP
I can reach 22.214.171.124 over v4
6to4 made it through my router/firewall
The 6to4 relay at 126.96.36.199 is decapsulating/encapsulating packets
It doesn't prove that the 6to4 relay actually has v6 connectivity, but
I think that's getting beyond the scope of this problem.
If that helps, maybe this gives additional ammo for an updated 6to4
anycast RFC that includes an ICMP echo requirement.