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.
Brian
>
> 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
>
>
>
> ------------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
