>There is a problem case related to tunneling (whether RFC 2893 or RFC 2473, or
>even RFC 2002 enhanced to propagate ICMP errors from the inside of the
>tunnel back to the sender).
>
>RFC 2893 specifies in section 3.4 how to construct an ICMPv6 error
>from an ICMPv4 error. When doing this you need to avoid creating
>an ICMPv6 error in response to an ICMPv6 error and the spec doesn't say
>anything about this. (And RFC 2473 has similar text in section 8.)

        yes, I understand this portion.  Assuming that we are doing IPv6-over-
        IPv4 tunnel, which IPv4 errors do we need to translate into IPv6?
        as far as I understand there's none.  For IPv6, IPv4 tunnels are
        invisible entity outside the packet (just like L2 encapsulations like
        ethernet) and errors on IPv4 layer will be seen to IPv6 layer
        as loss of packets (just like all L2 failures).
        I should have sent more comments earlier to these RFCs.

        Which ICMPv4 do you translate into ICMPv6 on Solaris? (or "would you
        translate")

        Couple of analysis (all IMHO):

        ICMP6 too big messages are not directly converted from ICMPv4 too big,
        either.  B gets ICMPv4 too big from somewhere between B and C for
        encapsulated packet, B would adjust tunnel MTU, and B originates
        ICMPv6 too big toward A.
                A -- B === C -- D

        ICMPv4 time exceeded does not need to be translated, as TTL field on
        outer IPv4 header has nothing to do with hoplimit value on inner IPv6
        header.  B decides IPv4 TTL on its behalf and use that value (RFC2893
        p13), and the tunnel between B and C is a 1-hop path for inner IPv6
        packet.  There's real need to tell time exceeded to A, as there's
        nothing A can do.  The packets will be silently lost just like other
        L2 failures.
        RFC2783 recommends to translate it from IPv4 to IPv6 (p27),
        which I don't really think it useful as there's nothing A can do.

itojun
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to