Jeroen Massar wrote:
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....
It's a valiant idea, but I think 6to4 and similar solutions will be here
longer than you think. :(
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.
Yes, see my other email reply too. I think the source ipv4 needs to be
set the the relay that does the conversion. This should work in the
middle of a native v6 route provided both 6to4 relays are icmp-6to4 capable.
I'd like to hear from some hardware implementers on the difficulty of
implementing this as well as any other proposals to get ipv4 hops
visible in ipv6 debugging tools.
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.
if they relays were icmp-6to4 capable, then this needs is greatly
reduced. from an endpoint you would see ::a.b.c.d relays along the way.
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.
"avoid 6to4 at all costs" does not seem sensible as it's already
implemented widely.
6to4 is cool for just 'plugging in and go' and that works great, but the
where "works great" == "sometimes might actually work"
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 :(
Thanx for the comments!
--
Tim Riker - http://Rikers.org/ - [email protected]
Embedded Linux Technologist - http://eLinux.org/
BZFlag maintainer - http://BZFlag.org/ - for fun!
☛ ¿ǝʇʇǝnbı̣ʇǝu pooƃ ǝɹnʇɐuƃıs ɹnoʎ uı 8-ɟʇn sı ☚
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
