Subject: PMTUD and MTU < 1280

From: Karl Auer <[email-masked]>
Date: Mon, 18 Jul 2011 22:25:30 +1000

I'm puzzled by something in RFC1981, which discusses PMTUD and IPv6.

It contains these two paragraphs towards the end of Section 4:

   A node MUST NOT reduce its estimate of the Path MTU below the IPv6
   minimum link MTU.

      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].

What does that mean - "insert a Fragment header"? And it may not be
*required* to reduce the size of subsequent packets, but does that mean
it *can* if it wants to? And isn't inserting a whole new header a bit
counterproductive if someone is telling your your packets are too big
already? All in all I have this strong feeling I'm missing something
obvious. Any clues gratefully received.

Regards, K.

PS: [IPv6-SPEC]" refers to RFC1883, "Internet Protocol, Version 6 (IPv6)
Specification". I've read it again, especially the section on the
Fragment header, but am none the wiser.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

---

From: Philip Homburg <[email-masked]>
Date: Mon, 18 Jul 2011 14:46:38 +0200

>obvious. Any clues gratefully received.

I think that there was a tunneling protocol that would need the fragment ID 
in the fragment header to do fragmentation on the lower layer or something
like that. 

It never made much sense to me.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 18 Jul 2011 14:07:10 +0000

>       but rather must include a Fragment header in those packets [IPv6-

I've recently submitted an erratum to section 5 of RFC 2460, which
contains a similar requirement.  The requirement makes it impossible to
serve IPv6 services in a stateless fashion, so it's clearly bogus.
(Technically, you could always include the Fragment header, but that
would be an ugly kludge.)

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Jul 2011 15:39:33 -0700

> obvious. Any clues gratefully received.

The motivation for the fragment header insertion was to be able to 
support stateless IPv6->IPv4 translators (with multi-path routing), such 
as RFC 2765.

Such a translator normally sets DF (don't fragment) in the IPv4 packets. 
But should the IPv4 path MTU drop below 1300 (meaning that a translated 
1280 byte IPv6 packet wouldn't fit), then DF can't be set. In that case 
a unique IP ID field is needed. The fragment header contains a unique ID 
which will be used by the translator.

I hope that helps clarify the motivation,
     Erik

---

From: Florian Weimer <[email-masked]>
Date: Tue, 19 Jul 2011 09:00:21 +0000

* Erik Nordmark:

> support stateless IPv6->IPv4 translators (with multi-path routing),
> such as RFC 2765.
>
> Such a translator normally sets DF (don't fragment) in the IPv4
> packets. But should the IPv4 path MTU drop below 1300 (meaning that a
> translated 1280 byte IPv6 packet wouldn't fit),

Stateless gateways cannot perform path MTU discovery, so they don't know
about path MTU, and need to send packets with DF=0.

> then DF can't be set. In that case a unique IP ID field is needed. The
> fragment header contains a unique ID which will be used by the
> translator.

Why wouldn't the translator be able to pull a random ID out of thin air?
How would it generate a unique 16 bit IP ID field from a unique 32 bit
IP ID field?  It can't just discard the upper 16 bits and pretend that
they aren't required to ensure uniqueness.

---

From: Karl Auer <[email-masked]>
Date: Tue, 19 Jul 2011 21:26:47 +1000

> I hope that helps clarify the motivation,

Thanks Erik. I've read the explanation in RFC 2765, and sort of see the
motivation, but it doesn't help me understand exactly what the node
should be doing. That is, the "why" is slightly clearer, but the "what"
is not.

What, exactly, is a node supposed to do when it receives a PTB < 1280
after it has sent an ordinary packet?

a) fragment at 1280, regardless of the returned PMTU value

b) fragment so as to produce fragments of sizes equal to or smaller than
the returned PMTU value, but don't "remember" the returned PMTU value

c) create a new packet that is identical to the original packet but has
a fragment header inserted (i.e., forms a fragment sequence one fragment
long, with More-Fragments=0 in the fragment header)

d) fail to send the packet

e) something else...?

Only b) seems remotely useful, but it makes a mockery of the idea that a
PMTU of 1280 is required for IPv6.

Regards, K.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 19 Jul 2011 11:46:33 +0000

> PMTU of 1280 is required for IPv6.

b) seems impossible to implement because ICMP messages cannot be
reliably mapped to individual packets.  Thats why d) isn't an option
either (trivial DoS vector).  c) is required by the IPv6 RFC, but
this is broken.  a) is consistent with optional PMTUD, so it seems
the sanest choice.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Jul 2011 08:15:09 -0700

On 7/19/11 4:26 AM, Karl Auer wrote:

> What, exactly, is a node supposed to do when it receives a PTB<  1280

Correct; fragment as if the path mtu was 1280.
But in addition, insert a fragment header even for packets that don't 
require fragmentation.

    Erik

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Jul 2011 08:18:40 -0700

> about path MTU, and need to send packets with DF=0.

It is the end hosts that perform pmtu discovery; the translator just 
maps from IPv6 to IPv4 and vice versa. Look at RFC 2765 for the details.

> Why wouldn't the translator be able to pull a random ID out of thin air?

Then different fragmented datagrams between the same source and dest 
traveling through different translators could get the same ID, resulting 
in a risk of (persistent) incorrect reassembly.

> they aren't required to ensure uniqueness.

Sure it can; the assumption is that for each <source, dest, protocol> 
the fragment IDs are assigned sequentially or otherwise can be truncated 
to 16 bits. (I haven't checked what is in RFC on this point though.)

    Erik

---

From: Philip Homburg <[email-masked]>
Date: Tue, 19 Jul 2011 17:51:05 +0200

>in a risk of (persistent) incorrect reassembly.

How can it be persistently incorrect?

If translators generate random numbers the chance of collission depends on
the number of packets being assembled at the same time. So that should be
in the order of 1 in 10000 or so. Of course, this already requires a lot of
reordering.

Then the data will also be covered by a TCP or UDP checksum.

>to 16 bits. (I haven't checked what is in RFC on this point though.)

RFC-2460 doesn't seem to require sequential. For IPv4 it is good security
practice to make it random.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Jul 2011 09:36:05 -0700

> How can it be persistently incorrect?

Depends whether it is truly random, or pseudo-random, or random initial 
value plus an monotonic increment.

>> Sure it can; the assumption is that for each<source, dest, protocol>

RFC 2460 doesn't use MUST/SHOULD/MAY RFC 2119 language, hence it is a 
bit hard to gauge the strength of its text.
RFC 2460 does contain this text:
       * "recently" means within the maximum likely lifetime of a packet,
         including transit time from source to destination and time spent
         awaiting reassembly with other fragments of the same packet.
         However, it is not required that a source node know the maximum
         packet lifetime.  Rather, it is assumed that the requirement can
         be met by maintaining the Identification value as a simple, 32-
         bit, "wrap-around" counter, incremented each time a packet must
         be fragmented

   Erik

---

From: Philip Homburg <[email-masked]>
Date: Tue, 19 Jul 2011 19:32:15 +0200

>value plus an monotonic increment.

Truly random sounds a bit expensive for a translator. Yes, pseudo-random
is what you want. And any kind of counter, no matter how it is initialized,
doesn't count as random.

>         bit, "wrap-around" counter, incremented each time a packet must

I guess the most fun can be had if a host implements a counter, but then
accidentally writes out the counter as a little endian value. 

But I guess that is easy to solve.

Harder to solve would be the case where the IPv6 host is actually a busy
server, say a DNS server, that doesn't want to keep any state and just has
the link MTU set to 1280.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jul 2011 13:02:45 +1200

> But in addition, insert a fragment header even for packets that don't

It's always been my understanding that an interface sending IPv6 packets
MUST implement some (unspecified) form of framentation and reassembly
*below layer 3* if the link MTU is less than 1280. In other words a
PTB for a packet of length 1280 is an unrecoverable violation.

For example, if you're tunneling IPv6 over an IPv4 network whose PMTU (to
the other end of the tunnel) is, to take a random example, 576, the tunnel
end points could use IPv4 fragmentation and reassembly to provide a 1280 MTU
for the IPv6 traffic.

Of course this doesn't cover the NAT64 case; so what? NAT breaks many things.
We just have to rely on the real world, where the layer 2 link MTU is pretty
much always 1500 today.

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Jul 2011 22:28:03 -0700

> end points could use IPv4 fragmentation and reassembly to provide a 1280 MTU

That would be true for tunneling IPv6 over IPv4.
But the topic was the wording in RFC 2460 that was added to make it 
feasible to build (stateless) translators between IPv6 and IPv4.

> We just have to rely on the real world, where the layer 2 link MTU is pretty

We do have language in RFC 2460 to handle this particular case.

    Erik

---

From: Philip Homburg <[email-masked]>
Date: Wed, 20 Jul 2011 10:09:18 +0200

>feasible to build (stateless) translators between IPv6 and IPv4.

Personally, I think it is just bad design to require extra complexity in
every IPv6 stack in the world, just to accodate a transition technology
that essentially hasn't been used in the last 15 years, that provides
no benefit to hosts that allocate fragment IDs randomly (as is good
security practice for IPv4) and provides marginal benefits for hosts
that allocate IDs sequentially.

I would suggest that the stateless translator protocols be updated to not
use this feature and allocate a random 16-bit ID themselves. And schedule 
the feature to be remove from the IPv6 standard.