Tim Riker wrote:
> Has there been talk of having 6to4 gateways transform icmp6 traffic
> to/from icmp with ipv6 encapsulated in the ipv4 icmp payload?
>
> (instead of icmp6 inside protocol type 41 ipv4 packets)
> 
> This could be identified by the icmp6 header in the payload on the
> return to unpack.
> 
> This would allow mtr/traceroute6 and the like to see the ipv4 hops and
> greatly assist in debugging 6to4 traffic.

I like the idea on the first view, but it isn't going to help a lot as...

The problematic 6to4-relays/hops will then need to have this feature,
and as they are problematic they are most likely not monitored either at
the moment. Before this feature is documented, before those hosts are
upgraded to support it, I hope that 6to4 is long long gone....

There is another issue with this proposal, and that is that 6to4 relays
at the moment can support quite high rates (and some vendor C products
are said to do it in hardware) but with this added they would have to
add checking+decoding+changing of those packets, which is not always
good for performance. Don't forget that in some (broken IMHO) networks
6to4 relays/hops might just appear in the middle of a network, one can't
recognize that 6to4 would be involved then.

The big problem with debugging 6to4 (and Teredo) is the anycast factor,
which has effect on both IPv4 and IPv6 routing of packets, and thus
making quadruple (IPv4 (back+forth) + IPv6 (back+forth)) debugging
necessary in case of problems; the problem there again is that you need
to be able to find all the parties involved, and actually have access to
all the nodes that change IPv4->IPv6 and IPv6->IPv4; horrible mess, not
easily solvable.

Hopefully at least server operators are smart enough to server from
native IPv6 addresses. Then users who have native (or non-6to4/Teredo)
connectivity at least don't have the hassle that 6to4 brings along.

6to4 is cool for just 'plugging in and go' and that works great, but the
moment that one of the relays affecting your path is doing something
weird it is very very hard to fix them. This proposal would help
debugging but you still would need a traceroute from both sides and then
hope that all the bad hops also support it... not quickly going to
happen unfortunately :(

Greets,
 Jeroen

Attachment: signature.asc
Description: OpenPGP digital signature

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to