Brian E Carpenter wrote:
On 2009-03-01 08:13, 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...
... 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.
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!
--
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
--------------------------------------------------------------------
