search

eqvinox / icmpext-clat-source

IETF draft: CLAT original-IPv6-source ICMP extension
0 stars 0 forks source link

What to do about actual source IPv6->IPv4 source translation? #3

Open furry13 opened 2 weeks ago

furry13 commented 2 weeks ago

RFC6145, Section 5.2 says:

In addition, all ICMP packets MUST have the Type translated and, for ICMP error messages, the included IP header also MUST be translated. Note that the IPv6 addresses in the IPv6 header may not be IPv4- translatable addresses and there will be no corresponding IPv4 addresses representing this IPv6 address. In this case, the translator can do stateful translation. A mechanism by which the translator can instead do stateless translation of this address is left for future work."

So the behaviour is basically undefined. While our draft says what extensions to add, it all might be useless if the translator (CLAT) can not actually translate the packet header.

Off top of my head:

  1. As PR #2 I sent already suggests updating RFC6145, we can add to the draft:
  1. Have a separate small draft doing just that.

It's important to ensure ICMPv6 packets from non-translatable sources are going through clat, as otherwise PMTUD can be broken (note that RFC4884 extensions can not be used for Packet too Big)

mstojens commented 2 weeks ago

Just calling out that RFC 6145 has been obsoleted by RFC 7915, so we should update 7915 instead of 6145.

The 7915 text that will need updating is different in that the quoted 6145 text is no longer present. See 7915 Section 5.2, after Figure 6:

For extensions not defined in [RFC4884], the translator passes the extensions as opaque bit strings and any IPv6 address literals contained therein will not be translated to IPv4 address literals; this may cause problems with processing of those ICMP extensions.

furry13 commented 2 weeks ago

Just calling out that RFC 6145 has been obsoleted by RFC 7915, so we should update 7915 instead of 6145.

Yes, see #4 ;)

The 7915 text that will need updating is different in that the quoted 6145 text is no longer present.

I'm sure I've fixed all references to 6145... Which text are you referring to?

For extensions not defined in [RFC4884] translator passes the extensions as opaque bit strings

Interesting, thanks for pointing this out.