Subject: [v6ops] RFC 2464 - MTU >1500

From: Daniel Roesen <[email-masked]>
Date: Thu, 3 Feb 2011 23:43:51 +0100

Hi,

while discussing using IPv6 MTU >1500 in DS-Lite context on DOCSIS
access networks (to avoid fragmentation), we stumbled across the
following in RFC2464 (IPv6 over Ethernet):

---------------------------------------------------------------------
2. Maximum Transmission Unit

   The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500
   octets.  This size may be reduced by a Router Advertisement [DISC]
   containing an MTU option which specifies a smaller MTU, or by manual
   configuration of each node.  If a Router Advertisement received on an
   Ethernet interface has an MTU option specifying an MTU larger than
   1500, or larger than a manually configured value, that MTU option may
   be logged to system management but must be otherwise ignored.

   For purposes of this document, information received from DHCP is
   considered "manually configured" and the term Ethernet includes
   CSMA/CD and full-duplex subnetworks based on ISO/IEC 8802-3, with
   various data rates.
---------------------------------------------------------------------
Source: http://tools.ietf.org/html/rfc2464

The IPv6 DOCSIS scenario calls for RAs from the CMTS, without advertised
prefix, with M=1 to enforce stateful DHCPv6 by customers to obtain
IPv6 address/prefix delegation.

As far as I read the text above, CPE routers connected to a CMTS
advertising MTU >1500 in the RAs are supposed to ignored that value and
fall back to 1500. Is that understanding correct? If so, what's the
underlying reason for that? A router advertising itself on a link can't
be trusted to know that a link has a higher than default MTU!? Or is it
about making sure there won't be SLAAC on >1500 MTU links in order to
cater for non-"jumbo" capable hosts?

Given that we enforce DHCPv6 anyway, we might advertise a higher MTU in
DHCPv6 replies. As I understand the RFC, that would be considered
"manual configuration" and legit.

Does anyone see potential operational problem with such a "two-stage",
inconsistent MTU advertisement (first via RA, then ultimately via
DHCPv6 with higher MTU)?

Given that there is no SLAAC happening, that _should_ be safe, as any
new endpoint coming alive will do DHCPv6 and is supposed to actually use
the MTU value received there, correct?

What is supposed to happen when a CPE device is being connected not
supporting MTU >1500 but receiving such MTU in DHCPv6 reply? My guess
is, that the interface shouldn't/wouldn't come operational.

Any suggested reading appreciated.

Any suggestions for approaches to selectively use higher than 1500
octet MTU to some endpoints (specifically DS-Lite B4s) also very
welcome. :-)

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: james woodyatt <[email-masked]>
Date: Thu, 03 Feb 2011 16:03:46 -0800

On Feb 3, 2011, at 14:43, Daniel Roesen wrote:
> 
> [...] A router advertising itself on a link can't be trusted to know that a link has a higher than default MTU!? [...]

I would suggest that <http://tools.ietf.org/html/draft-van-beijnum-multi-mtu> is a document worth reviewing for insight into the relevant issues here.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 3 Feb 2011 21:03:31 -0600

Just as an FYI - there is no MTU "option" in DHCPv6 ... so, I'm not sure
what you're talking about when saying "we might advertise a higher MTU
in DHCPv6 replies" and "we might advertise a higher MTU in DHCPv6
replies".

Perhaps there's a draft I've missed regarding an MTU option for DHCPv6? 

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtm
l

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Daniel Roesen
Sent: Thursday, February 03, 2011 5:44 PM
To: [email-masked]
Subject: [v6ops] RFC 2464 - MTU >1500

Hi,

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Erik Kline <[email-masked]>
Date: Fri, 4 Feb 2011 17:50:42 +0900

I thought that if there were no MTU option in the RA the node is
responsible for figuring out the MTU of the link.  It would seem to me
that you just need to /not/ send an MTU option?

Maybe I'm confused though.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 04 Feb 2011 08:42:49 -0500

Erik Kline <[email-masked]> writes:

> responsible for figuring out the MTU of the link.

I would word that slightly differently. Every link type has a default
MTU. The IPoverFoo document for a particular link type defines the
value.

The MTU option in an RA can be used to override the default, in cases
where the default value is somehow not optimal.

Thomas

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 7 Feb 2011 22:11:19 +0100

> in DHCPv6 replies" and "we might advertise a higher MTU in DHCPv6

Good point, thanks. I've let myself trick into thinking there is one,

>    For purposes of this document, information received from DHCP is
[...]

So, RA MTU >1500 options are supposed to get ignored, DHCPv6 interface
MTU option does not exist.

How can we inform endpoints of MTU >1500 in an automated fashion?

Best regards,
Daniel

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 7 Feb 2011 22:18:26 +0100

> where the default value is somehow not optimal.

Except that the IPoverEthernet RFC says to ignore MTU >1500 when received
in RAs. So on Ethernet, RA MTU option may only decrease MTU, not increase
compared to default.

The reasoning behind that is beyond me.

Looking at
https://datatracker.ietf.org/doc/draft-ietf-ipngwg-trans-ethernet/history/,
that paragraph was never substantially changed in the I-D process, just
the paragraph referring to DHCP="manual" added.

Matt, any chance of clarification?

Best regards,
Daniel

---

From: Matt Crawford <[email-masked]>
Date: Mon, 07 Feb 2011 15:53:29 -0600

(If this gets bounced from v6ops for my non-membership in the list, please repost.)

> Matt, any chance of clarification?

The text was nearly the same in RFC 1972. I have the nroff source of all drafts of both the i-d's, but I don't have all my email from 15 years ago so I cannot say who raised and/or endorsed this point. 

Reaching back almost six years, there was a relevant discussion on this question. I think the same text answers here ...

Begin forwarded message:

> From: Hugh LaMaster <[email-masked]>
> Date: July 20, 2005 7:15:52 PM CDT
> To: Matt Crawford <[email-masked]>
> Subject: IPv6 and Jumbo Frames on Ethernet
> Reply-To: Hugh LaMaster <[email-masked]>
> 
> Hi,
> 
> There is an ongoing discussion on the "[email-masked]"
> mailing list wrt jumbo frames.  Is it your opinion that
> RFC2464 prohibits (that is, if something is supposed
> to be strictly in compliance with RFC2464) the IPv6
> MTU from being greater than 1500 Bytes?  That is one
> interpretation.  I don't read it that way myself, but,
> apparently whoever implemented the FreeBSD IPv6 code
> interprets it that way also-- that the RFC prohibits
> IPv6 MTU > 1500.
> 
> Regards,
> Hugh LaMaster
> NASA ARC/NAS/NREN
> 

Begin forwarded message:

> From: Matt Crawford <[email-masked]>
> Date: July 20, 2005 8:52:48 PM CDT
> To: Hugh LaMaster <[email-masked]>
> Subject: Re: IPv6 and Jumbo Frames on Ethernet
> 
>> There is an ongoing discussion on the "[email-masked]"
>> mailing list wrt jumbo frames.  Is it your opinion that
>> RFC2464 prohibits (that is, if something is supposed
>> to be strictly in compliance with RFC2464) the IPv6
>> MTU from being greater than 1500 Bytes?  That is one
>> interpretation.  I don't read it that way myself, but,
>> apparently whoever implemented the FreeBSD IPv6 code
>> interprets it that way also-- that the RFC prohibits
>> IPv6 MTU > 1500.
> 
> Hm.  It is only supposed to mean that Router Advertisements cannot increase the MTU above whatever it was otherwise believed to be, and that in the absence of configuration information (including DHCP), it is presumed to be 1500.
> 
> I'd have to agree that it could have been a bit clearer.
> 
>                Matt Crawford   <[email-masked]>
>                FNAL/CD/CCF/Wide Area Systems
>                +1 630 840 3461
> 

Begin forwarded message:

> From: Hugh LaMaster <[email-masked]>
> Date: July 21, 2005 1:15:45 PM CDT
> To: Matt Crawford <[email-masked]>
> Subject: Re: IPv6 and Jumbo Frames on Ethernet
> Reply-To: Hugh LaMaster <[email-masked]>
> 
> Matt Crawford wrote:
> 
>> Hm.  It is only supposed to mean that Router Advertisements cannot
>> increase the MTU above whatever it was otherwise believed to be, and
>> that in the absence of configuration information (including DHCP), it is
>> presumed to be 1500.
> 
> Do you mind if I repost this statement to the mailing list?
> 
> Regards,
> Hugh LaMaster
> 

Begin forwarded message:

> From: Matt Crawford <[email-masked]>
> Date: July 21, 2005 2:04:05 PM CDT
> To: Hugh LaMaster <[email-masked]>
> Subject: Re: IPv6 and Jumbo Frames on Ethernet
> 
> 
> On Jul 21, 2005, at 13:15, Hugh LaMaster wrote:
> 
>>> Hm.  It is only supposed to mean that Router Advertisements cannot
>>> increase the MTU above whatever it was otherwise believed to be, and
>>> that in the absence of configuration information (including DHCP), it is
>>> presumed to be 1500.
>> 
>> Do you mind if I repost this statement to the mailing list?
> 
> No.  Please include the admission that perhaps it could have been clearer.  Remember the old "We'll fix it in Draft" mantra that used to be the ipngwg refrain?
> 
>          Matt
>

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 8 Feb 2011 08:47:10 +0100

Hi Matt,

first of all, thanks for chiming in.

On Mon, Feb 07, 2011 at 03:53:29PM -0600, Matt Crawford wrote:
> Reaching back almost six years, there was a relevant discussion on
> this question. I think the same text answers here ...

Well, the only thing that conversation clarifies is the intention to not
raise the MTU via RAs. What isn't explained is the reason why this is
considered an absolute no-go.

If a router (emitting RAs) says that a link is running at MTU 2345, then
there's no point in allowing endpoints to run with MTU 1500 as PMTUD
will be broken anyway (the router will use MTU 2345 on his interface
towards the Ethernet, so won't see a reason to return ICMP packet too
big to any IP packet >1500).

So in fact, to my understand, either

a) RAs shouldn't be allowed to carry MTU >1500 on Ethernet
or
b) endpoints MUST accept RA MTU >1500 and either be capable of
participating in a MTU>1500 LAN or consider the link inoperational.

Best regards,
Daniel

---

From: Thomas Narten <[email-masked]>
Date: Thu, 10 Feb 2011 20:34:14 -0500

What RFC 2464 says is:

To me, that pretty clearly means you can't bump the MTU above 1500 via
an RA.

This was almost certainly done because 1500 *is* the MTU of Ethernets.

Rightly or wrongly, Jumbo frames have never been standardized.

Indeed, the IETF and the IEEE had an exchange of some sort over this
very issue, and the IETF decided not to bless or standardize jumbo
frames. I'm pretty sure there are some documents or statements about
that, but can't find them right off.

Thomas

---

From: Jack Bates <[email-masked]>
Date: Thu, 10 Feb 2011 20:39:25 -0600

> that, but can't find them right off.

To not standardize and to purposely attempt to block and disrupt current 
practices are two different things. Also, it is MORE accurate to say 
that 1500 is the MTU of IP over Ethernet. I don't have a single Ethernet 
which communicates at 1500 bytes.

Jack

---

From: "George Bonser" <[email-masked]>
Date: Thu, 10 Feb 2011 21:17:20 -0800

> which communicates at 1500 bytes.

We run everything internally at 9000 MTU.  Modern PMTUD as is deployed
these days by default on Windows and Solaris and which you can turn on
with a sysctl with Linux works really well.  The MTU 9000 makes a huge
difference, particularly if you have any NAS or are doing logging over
the network.

One of our collocation providers recently changed their peering switch
to support jumbos.  That doesn't mean peers need to use 9000, just means
they can if they wish, but the switch will support frames that large.
All of our MetroE connections save one are "jumbo clean".  But it
doesn't break anything out on the internet,  we send a SYN and when the
other end replies, they have their MSS which is the maximum segment size
so we won't try to send a packet larger than that no matter what the MTU
is set to.

And the obligatory links to the usual documents:

http://staff.psc.edu/mathis/MTU/
http://63.196.71.246/~phil/jumbo.html
http://staff.psc.edu/rreddy/networking/mtu.html

---

From: "George Bonser" <[email-masked]>
Date: Thu, 10 Feb 2011 21:24:11 -0800

Sorry, folks, I mistook this mailbox for the ipv6-ops mailbox.  Sorry to
bother you.

> Of George Bonser
> Sent: Thursday, February 10, 2011 9:17 PM
> To: Jack Bates; Thomas Narten
> Cc: [email-masked]; Matt Crawford
> Subject: Re: [v6ops] RFC 2464 - MTU >1500
> 
> >

---

From: Matt Crawford <[email-masked]>
Date: Fri, 11 Feb 2011 09:40:05 -0600

The last internet-draft for V6 over Ethernet predates the proposal of gigabit ethernet, and the publication of RFC2464 predates the ratification of IEEE 802.3ab. I believe Jumbo Frames came after the latter.

The right thing would seem to be one of:

A. Let it stand, and demand use of DHCPv6 (or manual configuration) to set an MTU > 1500.

B. Supersede 2464 with a new specification

C. Update 2464 with an RFC on MTU alone.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Feb 2011 08:18:34 -0800

Hi Matt, 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Matt Crawford
> Sent: Friday, February 11, 2011 7:40 AM
> To: [email-masked]
> The last internet-draft for V6 over Ethernet predates the 
> proposal of gigabit ethernet, and the publication of RFC2464 
> predates the ratification of IEEE 802.3ab. I believe Jumbo 
> Frames came after the latter.
> 

The MTU is not necessarily the same as the Maximum
Receive Unit (MRU). So for instance, if a host sets an
MTU of 1500 on an Ethernet interface, but it configures
a receive buffer large enough to receive unfragmented
packets of up to 2K, what should it do if it receives
a UDP packet larger than 1500?

I say keep it - why throw away good data? But, others
may have a different opinion.

The point being, if there were a new document to talk
about MTU it might also want to discuss MRU.

Thanks - Fred
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Fri, 11 Feb 2011 08:39:09 -0800

> C. Update 2464 with an RFC on MTU alone.

</chair>

I think the right thing to do is (C), an update to 2464 and the various RFCs that refer to a magic numbers 1500 or 1280, indicating that IPv6 MTU *in*all*cases* follows the same rules as IPv4, which is to say that it uses defaults appropriate to the characteristics of the link layer and is subject to local configuration, DHCP configuration, TCP MSS negotiation, and Path MTU. The number "1280" is important in a world where IPv6 is primarily carried in tunnels, and 1500 is important to Ethernets below 1 Gig. But we are in the process of making IPv6 native, and have link layer MTUs as small as 128 without a means to link fragments of higher layer protocols together (so the rule trying to impose that on link layer protocols is broken) and as high as 18,000 (Token thing).

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Feb 2011 08:56:24 -0800

Hi Fred, 

> On Behalf Of Fred Baker
> Sent: Friday, February 11, 2011 8:39 AM
> To: Matt Crawford
> Cc: [email-masked]
> I think the right thing to do is (C), an update to 2464 and 
> the various RFCs that refer to a magic numbers 1500 or 1280, 
> indicating that IPv6 MTU *in*all*cases* follows the same 
> rules as IPv4, which is to say that it uses defaults 
> appropriate to the characteristics of the link layer and is 
> subject to local configuration, DHCP configuration, TCP MSS 
> negotiation, and Path MTU. The number "1280" is important in 
> a world where IPv6 is primarily carried in tunnels,

Not if the tunnel has a way of figuring out how large
the subnetwork can support, which might be considerably
larger than 1280.

Thanks - Fred

> and 1500 
> is important to Ethernets below 1 Gig. But we are in the 
> process of making IPv6 native, and have link layer MTUs as 
> small as 128 without a means to link fragments of higher 
> layer protocols together (so the rule trying to impose that 
> on link layer protocols is broken) and as high as 18,000 
> (Token thing).

---

From: Fred Baker <[email-masked]>
Date: Fri, 11 Feb 2011 09:10:14 -0800

> the subnetwork can support, which might be considerably

Which takes you back to the previous clause...

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Feb 2011 09:23:02 -0800

Hi Fred, 

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Friday, February 11, 2011 9:10 AM
> To: Templin, Fred L
> Cc: Matt Crawford; [email-masked]

But then, not all tunnels are equal when it comes to the
means available at their disposal to determine the MTU.
Some have no recourse but to select a "safe" static value,
and 1280 is as small as they are permitted to go.

RFC4213 mandates that there be a "configuration knob"
for selecting static MTUs larger than 1280, but tunneling
mechanisms that don't have a means of determining dynamic
MTUs are taking risks when they set larger values.  

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Fri, 11 Feb 2011 09:44:19 -0800

> and 1280 is as small as they are permitted to go.

Well, yes, and that is generally a good thing. But hosts are also told that they can ignore any indications of a path MTU smaller than 1280. From RFC 2460:

   IPv6 requires that every link in the internet have an MTU of 1280
   octets or greater.  On any link that cannot convey a 1280-octet
   packet in one piece, link-specific fragmentation and reassembly must
   be provided at a layer below IPv6.

IEEE 802 didn't ask us about that when they designed IEEE 802.15.4. Link-specific fragmentation and reassembly is specifically something that IEEE LAN technologies don't do, and all the bleating we might produce doesn't have much effect on them.

> MTUs are taking risks when they set larger values.  

Tunnels must have their MTU configurable. That's a good thing. But I don't see the "risk" in having an MTU *larger* than common traffic - a larger MTU doesn't inhibit the traffic in any way. The only risk I see is that traffic may or may not take advantage of it.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Feb 2011 10:05:49 -0800

Hi Fred, 

> Sent: Friday, February 11, 2011 9:44 AM
> To: Templin, Fred L
> Well, yes, and that is generally a good thing. But hosts are 
> also told that they can ignore any indications of a path MTU 
> smaller than 1280. From RFC 2460:
> 
> IEEE 802 didn't ask us about that when they designed IEEE 
> 802.15.4. Link-specific fragmentation and reassembly is 
> specifically something that IEEE LAN technologies don't do, 
> and all the bleating we might produce doesn't have much 
> effect on them.

Right; links like that are challenging for some types of
tunnels, but can be handled by others. I believe those
sorts of links typically show up in edge networks and
not so much in transit networks, however? 
 
> Tunnels must have their MTU configurable. That's a good 
> thing. But I don't see the "risk" in having an MTU *larger* 
> than common traffic - a larger MTU doesn't inhibit the 
> traffic in any way. The only risk I see is that traffic may 
> or may not take advantage of it.

Tunnels over IPv4 that set larger than 1280 need to worry
about IP fragmentation issues (RFC4459, RFC4963) and/or
loss of ICMPv4 PTBs (RFC2923, RFC5927).

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Fri, 11 Feb 2011 10:19:34 -0800

What's your point?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Feb 2011 11:42:17 -0800

> What's your point?

Are you asking whether I'm trying to achieve a specific
objective? Because I'm not - I'm just going with the
flow of the discussion as it is evolving.

That said, the discussion seems to be trending toward a
consideration of what types of links we might want to
run IPv6 over. Personally, I think the answer is "all
of them" - but as you have noted there are links that
can't do 1280 natively. For example, some links have
such low data rates and/or such high BERs that
time-on-the-wire would make it prohibitive to send
1280 packets all in one piece.

So, we need to find some way to convey 1280 IPv6 packets
over those sorts of links since IPv6 does not permit
in-the-network fragmentation. So, there needs to be some
segmentation/reassembly at a layer below IPv6. There are
many different ways to do that, however, and it may or
may not be possible to pick just one size that fits all.

That's all - Fred

---

From: Fred Baker <[email-masked]>
Date: Fri, 11 Feb 2011 11:53:30 -0800

On Feb 11, 2011, at 11:42 AM, Templin, Fred L wrote:

> segmentation/reassembly at a layer below IPv6. 

I think you would generally be told that's 6lowpan.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Feb 2011 12:57:18 -0800

Hi Fred, 

> Sent: Friday, February 11, 2011 11:54 AM
> To: Templin, Fred L

OK, but there are many different link types other than
just IEEE 802.15.4 that don't support 1280 natively.
They can either use a link-specific adaptation (many
do), or they can use something that is ubiquitously
available and link-agnostic.

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Fri, 11 Feb 2011 13:02:41 -0800

I frankly think it would be more sensible to accept that the MTU might sometimes be less than 1280.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Feb 2011 13:44:56 -0800

> Sent: Friday, February 11, 2011 1:03 PM
> To: Templin, Fred L

So...change the specs to allow IPv6 to operate over
links that support less than 1280 natively?

What would you like to name as the new IPv6
MinMTU - 576? 68? Something else?

Fred

---

From: Fred Baker <[email-masked]>
Date: Fri, 11 Feb 2011 14:03:18 -0800

My suggestion: an IPv6 MTU should be at least the size of an IPv6 header. Not that I would recommend anyone set their MTU to that, but my observation of pompous statements about what else it should be are rooted in fantasy. Pick any number larger than that size and give me a technical argument for it - I think you'll find it difficult without making assumptions about the network. The reason for the magic size 576, for example, had something to do with the size of disk blocks on common media, and as a result with the size of a buffer on equipment of the day. Having been a builder of "routers of the day", I'd note that the router I worked on put 90 data bytes in a buffer (but they were designed to chain).

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Feb 2011 14:13:15 -0800

Hi Fred, 

> Sent: Friday, February 11, 2011 2:03 PM
> To: Templin, Fred L
> My suggestion: an IPv6 MTU should be at least the size of an 
> IPv6 header. Not that I would recommend anyone set their MTU 
> to that, but my observation of pompous statements about what 
> else it should be are rooted in fantasy. Pick any number 
> larger than that size and give me a technical argument for it 
> - I think you'll find it difficult without making assumptions 
> about the network. The reason for the magic size 576, for 
> example, had something to do with the size of disk blocks on 
> common media, and as a result with the size of a buffer on 
> equipment of the day. Having been a builder of "routers of 
> the day", I'd note that the router I worked on put 90 data 
> bytes in a buffer (but they were designed to chain).

I'm not sure I quite get from this whether you are
advocating a reduction in the IPv6 MinMTU to allow
MTUs smaller than 1280. Are you? Is it possible we
could actually find some common ground to agree on?

BTW, this has nothing whatsoever to do with advocating
for tunnels, which I am specifically not doing.

Thanks - Fred

---

From: Keith Moore <[email-masked]>
Date: Fri, 11 Feb 2011 17:53:55 -0500

In general, I think it's extremely late to talk about changing the IPv6 minimum MTU.   

Even if you were going to relax that restriction and found a way to do it without breaking compatibility with widely deployed code, the IPv6 header is just too big to be used with very small packets.   For those, it makes sense to have an adaptation layer with a small header, and maybe FEC to deal with dropped fragments.

Keith

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Feb 2011 15:03:40 -0800

> From: Keith Moore [mailto:[email-masked]] 
> Sent: Friday, February 11, 2011 2:54 PM
> To: Fred Baker
> Cc: Templin, Fred L; [email-masked]; Matt Crawford

Too late? Maybe. Worth discussing? Hmm...  

> Even if you were going to relax that restriction and found a 
> way to do it without breaking compatibility with widely 
> deployed code, the IPv6 header is just too big to be used 
> with very small packets.

Well, the 68 in IPv4 came from a maximally-large IPv4
header (60 bytes) plus 8 bytes for the minimum-sized
fragment.

> For those, it makes sense to have 
> an adaptation layer with a small header, and maybe FEC to 
> deal with dropped fragments.

FEC and/or ARQ - which is what many of the wireless
links I deal with do. Still - how long are the end
systems willing to wait for a 1280 IPv6 packet to
finally make it through a constrained link?

Fred

> > I frankly think it would be more sensible to accept that 
> the MTU might sometimes be less than 1280.
> >

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 12 Feb 2011 01:54:46 +0100 (CET)

> so we won't try to send a packet larger than that no matter what the MTU

For TCP yes, for all the other protos, not so much. There you need PMTUD 
working properly.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Feb 2011 14:21:11 +1300

> For TCP yes, for all the other protos, not so much. There you need PMTUD

For TCP, no. This is exactly the failure mode that I (oh, the irony, says
the co-author of RFC 3056) experienced when running 6to4 a couple of years
ago. It's entirely possible to conduct a successful SYN-SYN/ACK exchange
and end up with the MSS being greater than the path MTU, even if the client's
link MTU is set to 1280 while the server's is set to 1500.

   Brian

---

From: "George Bonser" <[email-masked]>
Date: Fri, 11 Feb 2011 18:07:45 -0800

> For TCP yes, for all the other protos, not so much. There you need

Yes, and as modern PMTUD doesn't require ICMP, it works much better than
the old way.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 12 Feb 2011 03:35:40 +0100 (CET)

> Yes, and as modern PMTUD doesn't require ICMP, it works much better than 

Care to elaborate on that? What "modern PMTUD" are you referring to that 
doesn't require any ICMP involvement?

---

From: "George Bonser" <[email-masked]>
Date: Fri, 11 Feb 2011 21:46:19 -0800

http://www.ietf.org/rfc/rfc4821.txt

On by default with Windows and Solaris.  Need to set
net.ipv4.tcp_mtu_probing=1 or 2 for linux depending on the behavior you
want.

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Friday, February 11, 2011 6:36 PM
> To: George Bonser
> Cc: [email-masked]
> Subject: RE: [v6ops] RFC 2464 - MTU >1500
>

---

From: "George Bonser" <[email-masked]>
Date: Fri, 11 Feb 2011 21:57:24 -0800

Note: while that sysctl is in the ipv4 path, it is effective for both v4
and v6, it is for general TCP of both protocols.

> Sent: Friday, February 11, 2011 9:46 PM
> To: Mikael Abrahamsson
> Cc: [email-masked]
> > > Yes, and as modern PMTUD doesn't require ICMP, it works much
better
> > than

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 14 Feb 2011 08:59:25 -0800

Hi George,

Yes, RFC4821 is a way end systems can protect against
PMTUD brokenness. However, it does not excuse routers
from returning the required ICMP PTBs, and it requires
that links be consistent about the size of packets
they will accommodate - both of which can present
challenges to in-the-network tunnels.

Thanks - Fred

> On Behalf Of George Bonser
> > > Yes, and as modern PMTUD doesn't require ICMP, it works 
> much better
> > than
> > > the old way.
> >