Subject: minimal MTU value

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 15 Nov 2016 10:19:13 +0900

Hello,

There is some experience with successfully setting MTU to 255 bytes on 
linux machines on Ethernet (and unsuccessful with setting it to 
254bytes). It works fine out of the box.

As such I think on linux the minimal MTU on Ethernet is actually 255 bytes.

I wonder what is the reasoning behind requiring the minmal MTU to be 
1280 bytes?

(on another hand RFC2460 says the minimal MTU is 1280bytes)

Alex

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Nov 2016 06:06:19 +0100

>  I wonder what is the reasoning behind requiring the minmal MTU to be 

=> 1280 = 1024 + 256 (1024 bytes of payload, 256 for headers).

Regards

[email-masked]

PS: I remember this question was already answered... Is there an IPv6 FAQ?

---

From: Geoff Huston <[email-masked]>
Date: Wed, 16 Nov 2016 08:14:00 +1100

> On 15 Nov. 2016, at 4:06 pm, Francis Dupont <[email-masked]> wrote:
> 

My own digging through the mail archives of the time suggested that the MTU was originally
drafted at 1500 and then dropped to 1280 to allow for various levels of IP-in-IP tunnel
mechanisms in the path without requiring complex signalling back to the sender (as IPv6
decided to both cement the IPv4 don't fragment bit to ‘on' and make the fragmentation control fields
optional via the extension header mechanism.) I've found no evidence in the archives of the IETF
lists to suggest any arbitrary division between header and payload, leading to my conclusion
that 1280 was picked simply because it is the result of adding 1024 and 256. By that reasoning,
the selection of any other value could probably have had equal merit!

(The wisdom of this approach to packet size and management of fragmentation in the light
of the problems it has caused in operational networks is an entirely different topic!)

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Nov 2016 06:26:09 +0900

Much of this may not have happened on mailing lists.

When I brought up the issue with Steve Deering at the 1996 SIGCOMM workshop in Stanford, it became clear quickly that an MTU < 1500 was desirable for IPv6, but it wasn’t clear how many layers of tunneling should be accommodated.  I think most people in the room at the time were assuming we would arrive at something around 1400, but choosing that number would be a bike shed, so no time was spent on discussing it.
I wasn’t present when the actual number was divined, but I’m certain the “roundness” (5x256) played a role — this is the closest round number that roughly splits the difference between a payload size of 1024 and the Ethernet MTU of 1500 between tunnels and higher layer headers.
I do remember that I thought “good, conservative choice” when I heard about the result.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Nov 2016 10:26:42 +1300

> the selection of any other value could probably have had equal merit!

True, it was just a round number (in binary terms) that should be construed as
1500-220, i.e. enough for several layers of IPv6-in-IPv6 encapsulation
within one Ethernet packet.

Clearly there was a desire to set it as high as possible, to reduce the probability
of fragmentation for short messages.

> of the problems it has caused in operational networks is an entirely different topic!)

Sure, but it was based on the knowledge and experience that people had
at that time.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 15 Nov 2016 22:08:17 +0000

On 15 Nov 2016, at 21:26, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

Geoff,

It would be good to get a few words to add to RFC6434-bis on those issues, as was raised in part in 6man in Berlin by yourself and Mark Andrews, and your blog at https://labs.apnic.net/?p=813 was very interesting. Could one of you perhaps provide something succinct, which would help us update section 5.6?

Many thanks,
Tim

---

From: Bob Hinden <[email-masked]>
Date: Wed, 16 Nov 2016 07:20:15 +0900

Brian,

> of fragmentation for short messages.

That what I remember as well.  For background the predecessor of IPv6, Simple IP didn’t support any fragmentation.  The thinking was that fragmentation was harmful and better to avoid it as much as possible.

Bob

---

From: [email-masked]
Date: Wed, 16 Nov 2016 08:46:56 +0900

> That what I remember as well.  For background the predecessor of IPv6, Simple IP didn’t support any fragmentation.  The thinking was that fragmentation was harmful and better to avoid it as much as…

Nothing changed there then. ;-)

Ole