Hi equi, Thanks for bringing this up. It definitely sounds useful in a mixed version environment, but I think there's a little bit more needed in this document, because there are two important cases to consider: - There's already an RFC4884 extension header - There is not yet an RFC4884 extension header
For example, RFC6145 mentions that if there's an existing extension header, the length field must be adjusted to consider the difference in IP header size. In this case, a translator that wants to add this extension can simply append the object to the translated packet and update the checksum in the existing extension header. If there is no pre-existing extension header, the translator needs to add an extension header and extension object, and set the length, as described in RFC4884. I think it's important to include these details because I don't think RFC4884 anticipated the possibility that these extensions would be additive - it assumes that the node that generates the ICMP message adds all of the extensions - so referring to that base RFC isn't quite enough to communicate the full procedure needed. Bill On Thu, Mar 21, 2024 at 8:50 PM David Lamparter <[email protected]> wrote: > Hi all, > > > the Subject:, draft name and title essentially all give it away: this > is proposing a new ICMP multi-part extension to stick the original > pre-translation IPv6 source addres into, when translating that to IPv4 > (e.g. in a CLAT.) > > This is intended for debugging/tracing purposes only, specifically to > make traceroute give useful results when tracing through a 464 setup. > (It might also be valuable for Packet Too Big.) > > This being a -00 there's a whole bunch of TODOs left, but the point > should be there and it's really simple. > > Cheers, > > -equi (David) > > ----- Forwarded message from [email protected] ----- > Subject: New Version Notification for > draft-equinox-intarea-icmpext-xlat-source-00.txt > Date: Thu, 21 Mar 2024 20:33:39 -0700 > > (...snip...) > > Name: draft-equinox-intarea-icmpext-xlat-source > Revision: 00 > Title: ICMP Extensions for IP/ICMP translators (XLATs) > Date: 2024-03-21 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/archive/id/draft-equinox-intarea-icmpext-xlat-source-00.txt > Status: > https://datatracker.ietf.org/doc/draft-equinox-intarea-icmpext-xlat-source/ > HTML: > https://www.ietf.org/archive/id/draft-equinox-intarea-icmpext-xlat-source-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-equinox-intarea-icmpext-xlat-source > > > Abstract: > > This document suggests the creation of an ICMP Multi-part Extension > to carry the original IPv6 source address of ICMPv6 messages > translated to ICMP by stateless (RFC6145) or stateful (RFC 6146) > protocol translators. > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
