[IPv6]Re: Comments on draft-ietf-6man-icmpv6-reflection

[Erik Auerswald <[e-mail]>]

Hi Ron,

On Fri, Apr 25, 2025 at 05:00:40PM +0000, Ron Bonica wrote:
> [...]
> I have also done some research with a popular platform. I found that:
> 
>   * It complies with RFC 792 and 4443 regarding the number of bytes
>     in the invoking packet field.
>   * It does not modify the invoking packet field.

It would be great if others could look into this, and report their
findings, too.  It can be as simple as starting Wireshark and then
traceroute on an Internet-connected laptop (that's what I did).

> However, your finding that a LINUX-based NAT box modifies the invoking
> packet field is significant. Given this finding, I don't think that the
> Destination Unreachable or Traceroute options are viable. This leaves us
> only with the solution described in draft-ietf-6man-icmpv6-reflection.

Payload addresses translated by NAT seem to be common enough for STUN
[RFC8489] to have added an additional attribute XOR-MAPPED-ADDRESS to
avoid problems with the original MAPPED-ADDRESS attribute.  The latter
could be translated by NAT.  Section 14.2 of RFC 8489[1] ends with the
following paragraph:

   Note: XOR-MAPPED-ADDRESS and MAPPED-ADDRESS differ only in their
   encoding of the transport address.  The former encodes the transport
   address by XOR'ing it with the magic cookie.  The latter encodes it
   directly in binary.  RFC 3489 originally specified only MAPPED-
   ADDRESS.  However, deployment experience found that some NATs rewrite
   the 32-bit binary payloads containing the NAT's public IP address,
   such as STUN's MAPPED-ADDRESS attribute, in the well-meaning but
   misguided attempt to provide a generic Application Layer Gateway
   (ALG) function.  Such behavior interferes with the operation of STUN
   and also causes failure of STUN's message-integrity checking.

The XOR-MAPPED-ADDRESS attribute was added to STUN in RFC 5389 from 2008,
as noted in section 19 of that RFC[2].

[1]: https://www.rfc-editor.org/rfc/rfc8489#section-14.2
[2]: https://www.rfc-editor.org/rfc/rfc5389#section-19

Best regards,
Erik