Subject: ICMPv6 too big with a "too small" MTU

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 22 Apr 2002 17:05:53 +0900

I have a question wrt RFC 1981 (path MTU discovery for IPv6).  The RFC
says in Section 4. as follows:

      Note: A node may receive a Packet Too Big message reporting a
      next-hop MTU that is less than the IPv6 minimum link MTU.  In that
      case, the node is not required to reduce the size of subsequent
      packets sent on the path to less than the IPv6 minimun link MTU,
      but rather must include a Fragment header in those packets [IPv6-
      SPEC].

RFC 2460 has a related text (in Section 5):

   In response to an IPv6 packet that is sent to an IPv4 destination
   (i.e., a packet that undergoes translation from IPv6 to IPv4), the
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments. ...

In my understanding, the only "translating router" that needs the
indication of the fragment header is an SIIT (or similar) translation
router.  In fact, neither NAT-PT (RFC 2766) nor TCP-relay (RFC 3142)
needs the indication.

So my questions are:

- is my understanding correct?
- if so, is it allowed for a host not implementing SIIT client side to
  ignore the requirement to insert the fragment header upon receiving
  an ICMPv6 too big message with an MTU less than 1280?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Rob Austein <[email-masked]>
Date: Mon, 22 Apr 2002 12:59:27 -0400

Er, NAT-PT is basicly a supserset of SIIT, so anything one needs to do
for SIIT one also needs to do for NAT-PT.

Or am I misunderstanding something?

---

From: Steve Deering <[email-masked]>
Date: Mon, 22 Apr 2002 14:44:17 -0700

>- is my understanding correct?

Perhaps.  That depends on how generous your "(or similar)" qualifier is.
:-)

>  an ICMPv6 too big message with an MTU less than 1280?

No, because there may be other things similar to SIIT (either already
invented or to-be-invented), that require the same originator behavior.

The spec is clear what to do when you get a Packet Too Big message
reporting an MTU less than 1280, and I think it would be unwise for
nodes to employ heuristics to determine whether or not to comply.

Steve

---

From: [email-masked]
Date: Tue, 23 Apr 2002 09:18:53 +0900

>Or am I misunderstanding something?

	NAT-PT gateway can do fragmentation/reassembly on its own as it can
	have (per-flow) state information.  SIIT gateway can't, as it is
	supposed to be stateless (oops, this word again).

itojun

---

From: Rob Austein <[email-masked]>
Date: Mon, 22 Apr 2002 22:52:22 -0400

Well, I don't think it's worth getting into a discussion about whether
NAT-PT is required to have per-flow state or SIIT is forbidden from
having per-flow state, so I'll just observe that, unless there's also
port mapping going on, NAT-PT mostly just deals with addresses.  There
is an address mapping table, but it's not per-flow.  The only
exceptions to this are for application protocols that need ALGs.

In the case of the NAT-PT implementation I did a few years ago, we
didn't need port mapping (v4 edge site, v6 network core), so we didn't
keep per-flow state in the NAT-PT core at all, and the ALG stuff was
handled in separate per-application-protococol modules that hooked in
via connection hijacking (so-called "transparent proxy", not that I
like with the name).  The ALGs had to fetch the address mapping data
out of the NAT-PT core, but that's trivial.

Anyway, the point of the above is just that most traffic through this
engine (SMTP, HTTP, SSH, TFTP, NTP, ...) was following the SIIT rules,
except for using a different mapping algorithm between the IPv4 and
IPv6 addresses.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 23 Apr 2002 14:44:40 +0900

>>>>> On Mon, 22 Apr 2002 14:44:17 -0700, 
>>>>> Steve Deering <[email-masked]> said:

> Perhaps.  That depends on how generous your "(or similar)" qualifier is.

Indeed...by the word I primarily meant a translation router that
cannot assign a unique IPv4 ID for a given IPv6 address.  An SIIT
translator cannot do this, because the translated IPv4 (source)
address is derived from the original IPv6 address.  A TCP relay can do
this, because it uses an IPv4 address of its own for the IPv4 side.
As for NAT-PT, I thought it belonged to the latter group, but I may be
wrong.

> nodes to employ heuristics to determine whether or not to comply.

I agree with the last sentence ("it would be unwise..."), but please
let me ask a question from a practical point of view, just out of
curiosity:

Is there an existing translation router (other than an SIIT
translator) that may return an ICMPv6 too big message with an MTU less
than 1280?

Is there an implementation that does not support the SIIT client
function but is compliant to the exceptional case of RFC 1981?

Thanks,

					JINMEI, Tatuya