Subject: 6to4 and icmp6

From: Tim Riker <[email-masked]>
Date: Fri, 27 Feb 2009 16:55:44 -0700

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.

Feel free to forward the idea to anyone interested.
-- 
Tim Riker - http://Rikers.org/ - [email-masked]
Embedded Linux Technologist - http://eLinux.org/
BZFlag maintainer - http://BZFlag.org/ - for fun!
☛ ¿ǝʇʇǝnbı̣ʇǝu pooƃ ǝɹnʇɐuƃıs ɹnoʎ uı 8-ɟʇn sı ☚

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 28 Feb 2009 20:13:53 +0100

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 01 Mar 2009 09:28:49 +1300

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

... I don't see how it will help at all with black holes, which
seem to be a 'feature' of 6to4 using anycast. If your outbound
packets reach a relay and then you receive no return packets,
no amount of ICMP munging is going to help, as far as I can see.
All you know is that there's probably no return path from
the remote target.

    Brian

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

---

From: Tim Riker <[email-masked]>
Date: Sat, 28 Feb 2009 14:03:02 -0700

> All you know is that there's probably no return path from

I've been thinking more about this. I think that the source IPv4 in the 
converted icmp-6to4 packets would need to be the IPv4 address of the 
router that does the conversion. This would insure that on the return 
trip only this "icmp-6to4" capable router would get the packets to 
transform back into icmp6 packets.

Using that method an ipv6 native host could traceroute to an ipv6 native 
host even when the routes go through one or more 6to4 legs along the way.

I'm not convinced that 6to4 will go away nearly as soon as is hoped. It 
can achieve more optimal routing than native 6to4 until the majority of 
Internet traffic is ipv6 native. This will be a long road.

I do think it's worth implementing this type of feature. So many 
operating systems can do 6to4 natively now. I think 6to4 needs to be 
more reliable in order to encourage general adoption of ipv6. It allows 
demand for native ipv6 to build even when an ISP does not yet support it.

If the user experience is that "when I enable ipv6 (meaning 6to4) I find 
unreachable hosts all over the place" then that user is likely to resist 
any move to 6to4 by his isp, company, etc.

There are some issues with migration though. If one 6to4 relay does this 
new transform, and the next relay that converts it back is not icmp-6to4 
capable, then the route will stop there. This may be better or worse 
than what you would get today.

Note: not all OSes would need to have icmp-6to4 built in for it to be 
useful. If an ISP gets a report of black holes in 6to4 from a user 
running a non icmp-6to4 capable os, the ISP could still fire up a 
compliant OS and test the same route. Indeed, during any Internet wide 
upgrade, I would expect that some OSes would include a runtime 
configurable flag to use the old 6to4-icmp6 or the new icmp-6to4 
protocols, or perhaps even send both for debugging. Alternate between 
the two? I'm open to suggestions.

The core of the matter is that:

1) current 6to4 black holes are bad for ipv6 adoption
2) current suboptimal 6in4 routes are bad for ipv6 adoption

working icmp-6to4 debugging tools would greatly improve both of these.

Thank you for the comments!

---

From: Tim Riker <[email-masked]>
Date: Sat, 28 Feb 2009 14:15:14 -0700

> 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. :(

> 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.

> all the nodes that change IPv4->IPv6 and IPv6->IPv4; horrible mess, not

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.

> 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"

> hope that all the bad hops also support it... not quickly going to

Thanx for the comments!