Subject: Re: "RFC 2461bis" issue: MTU handling

From: Fred Templin <[email-masked]>
Date: Mon, 27 Oct 2003 10:44:16 -0800

Thanks Pekka,

However, I believe protocol designers/implementors would appreciate
the flexibility afforded by a new option type.

Fred
[email-masked]

Pekka Savola wrote:

>On Sat, 25 Oct 2003, Bound, Jim wrote:
>  
>
>>I believe there is another option.  Develop new spec that does number 3
>>below to add to 2461 and leave 2461 alone.  This would be a spec
>>defining a new option for 2461.
>>    
>>
>
>Or, even define the new interpretation for MTU over NA messages in a 
>separate spec and leave RFC 2461 untouched...?
>
>  
>
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]] On 
>>>Behalf Of Fred Templin
>>>Sent: Friday, October 24, 2003 9:06 PM
>>>To: Iljitsch van Beijnum
>>>Cc: [email-masked]
>>>Subject: Re: "RFC 2461bis" issue: MTU handling
>>>
>>>
>>>I see (at least) three ways for the neighbor-to-neighbor MTU 
>>>negotiation; two were presented in my drafts and the third is 
>>>presented by Iljitsch here. The methods are:
>>>
>>>  1) Change RFC 2461 to allow NA messages to include MTU options:
>>>    Advantages:
>>>      - Unambiguous mechanism for NA's to inform of a 
>>>per-neighbor MTU value
>>>    Disadvantages:
>>>      - Requires modification to RFC 2461
>>>      - May require extra ND messages, since the interpretation of
>>>        MTU options is different for RAs
>>>
>>>  2) No changes to RFC 2461; allow "IPv6-over-foo" documents to
>>>    specify different interpretations of the MTU option in RA's:
>>>    Advantages:
>>>      - No modifications to RFC 2461
>>>    Disadvantages:
>>>      - Ambiguous interpretation of MTU options in RAs, or the
>>>      specified interpretation (MTU for the entire link) is disabled
>>>      - MTU option only available for RAs; not NAs
>>>
>>>  3) Change RFC 2461 to specify a new "NBR_MTU" option  that
>>>    can be sent with either NA's or RAs:
>>>    Advantages:
>>>      -  Unambiguous mechanism to inform of a per-neighbor MTU value
>>>      - Can be used with either NAs or RAs w/o altering the 
>>>interpretation
>>>        of the existing MTU option
>>>      - Maximum efficiency, since it can be used with either 
>>>NAs or RAs
>>>    Disadvantages:
>>>      - Requires modifications to RFC 2461
>>>
>>>So, it should be clear from the above analysis that I support 
>>>Iljitsch's proposal in terms of what should go into RFC 2461. 
>>>It is a sensible approach for a valuable mechanism and I 
>>>think folks should give it the consideration it deserves.
>>>
>>>Fred
>>>[email-masked]
>>>
>>>Iljitsch van Beijnum wrote:
>>>
>>>      
>>>
>>>>I'm not sure this should go into a replacement specification for RFC
>>>>2461, but I'll bring it up anyway:
>>>>
>>>>Currently, routers can advertise an MTU for a link. That's nice. But
>>>>what we really need is a way for hosts to find out the MTU each 
>>>>individual neighbor can handle. 100 Mbps and slower ethernet 
>>>>interfaces can typically handle only the standard 1500 byte 
>>>>        
>>>>
>>>ethernet 
>>>      
>>>
>>>>MTU, while gigabit ethernet interfaces usually support a 
>>>>        
>>>>
>>>much larger MTU.
>>>      
>>>
>>>>However, in most cases hosts with different MTUs are present on the
>>>>same subnet, so simply advertising a larger MTU wouldn't 
>>>>        
>>>>
>>>solve this. 
>>>      
>>>
>>>>(Not that this would work anyway as hosts are instructed to only 
>>>>listen to MTU advertisements where the MTU is between 1280 and 1500 
>>>>(for ethernet).)
>>>>
>>>>But if hosts can tell each other the MTU they support, each 
>>>>        
>>>>
>>>set of two
>>>      
>>>
>>>>hosts is always able to use the largest possible MTU between them. 
>>>>(This would also require a new link MTU option that conveys the 
>>>>maximum MTU the lower layer equipment supports. Switches have their 
>>>>own MTU and even some hubs start doing strange things when a larger 
>>>>than expected MTU is used.)
>>>>
>>>>BTW, some duplication seems to have crept into the document:
>>>>
>>>>   variable MTU   - a link that does not have a 
>>>>        
>>>>
>>>well-defined MTU (e.g.,
>>>      
>>>
>>>>                    IEEE 802.5 token rings).  Many links (e.g.,
>>>>                    Ethernet) have a standard MTU defined 
>>>>        
>>>>
>>>by the link-
>>>      
>>>
>>>>                    layer protocol or by the specific document
>>>>                    describing how to run IP over the link layer.
>>>>
>>>>     variable MTU   - Neighbor Discovery allows routers to 
>>>>        
>>>>
>>>specify a MTU
>>>      
>>>
>>>>                      for the link, which all nodes then 
>>>>        
>>>>
>>>use.  All nodes
>>>      
>>>
>>>>                      on a link must use the same MTU (or Maximum
>>>>                      Receive Unit) in order for multicast to work
>>>>                      properly.  Otherwise when 
>>>>        
>>>>
>>>multicasting a sender,
>>>      
>>>
>>>>                      which can not know which nodes will 
>>>>        
>>>>
>>>receive the
>>>      
>>>
>>>>                      packet, could not determine a minimum 
>>>>        
>>>>
>>>packet size
>>>      
>>>
>>>>                      all receivers can process.
>>>>
>>>>
>>>>--------------------------------------------------------------------
>>>>IETF IPv6 working group mailing list
>>>>[email-masked]
>>>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>>>>--------------------------------------------------------------------
>>>>        
>>>>
>>>
>>>
>>>--------------------------------------------------------------------
>>>IETF IPv6 working group mailing list
>>>[email-masked]
>>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>>>--------------------------------------------------------------------
>>>
>>>      
>>>
>>--------------------------------------------------------------------
>>IETF IPv6 working group mailing list
>>[email-masked]
>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>>--------------------------------------------------------------------
>>
>>    
>>
>
>  
>

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 28 Oct 2003 21:16:14 +1030

On Tue, 28 Oct 2003 11:36:58 +0100 (CET)
Erik Nordmark <[email-masked]> wrote:

> Just to restate what you are saying differently so that others might understand
> it. Today with have a MTU specified in the IPv6 over foo documents.
> We have an MTU option in router advertisements that can be used to
> lower that number - which is useful(?) for the last century problem of
> bridging Ethernet and FDDI together with half-broken fragmenting
> bridges - can get the FDDI attached nodes to use 1500.
> 

A minor note, being able to shrink the MTU on a link via a RA is would be very useful for avoiding packet fragmentation / PMTUD if the majority of traffic originating on that link is going to be encapsulated in a tunnel when going off-link eg VPN using ipsec, gre, etc.

Regards,
Mark.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Oct 2003 10:35:57 +0100 (CET)

> One case in which data packets could be used as probe packets
> is when IPv4 is used as an L2 media for IPv6. In this case, we could
> send IPv6-in-IPv4 encapsulated packets with the DF bit NOT set
> in the IPv4 header expecting that the decapsulator would send us
> some sort of indication if it sensed fragmentation.

Yes, you have that option for the L2 which is known as IPv4.

> But this begs the question of a fundamental design point: do we need
> to support sub-L2 media elements (i.e., the physical elements that sit
> below IPv4) that neither support IPv4 fragmentation nor send IPv4
> "frag needed" messages when they can't forward a packet? Based on
> the 1Gbps/100Mbps Ethernet bridge example, I believe the answer
> to this is "yes" - would you agree?

I think the high-order bit question for those L2s is first how important
the problem is to solve, and then what simplying assumptions we can make.
(such as "does the network admin control all the switches i.e. does s/he
know whether all are jumbo frame capable").

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Oct 2003 11:37:56 +0100 (CET)

> I'm afraid I'm not bought into this one as being necessary (yet). We know
> from our physical/logical point of attachment what the largest possible
> MTU for the attached L2 media is - this is a given.

That isn't true for Ethernet. A node attaching to an Ethernet has
no (standard) way to tell whether the switch it connects to supports 
jumboframes or not.

  Erik

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 23 Oct 2003 16:28:10 +0900 (JST)

> > 	the assumption made in RFC2461 is that the link MTU is constant
> > 	over the link, i guess.  i don't think it is necessary to make
> > 	MTU negotiable between peers, it would complicate too many things.
> What would it complicate?
> Obviously nobody is going to force anyone to implement such an option; 
> it would only be used between consenting hosts.

	you need to have a mechanism if the peer is capable of handling the
	option or not (since it is optional, if i read your comment correctly).
	then, neighbor cache management has to be changed to handle per-peer
	MTU value.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Oct 2003 13:12:43 +0300 (EEST)

On Thu, 23 Oct 2003, Iljitsch van Beijnum wrote:
[...]
> See http://sd.wareonearth.com/~phil/net/jumbo/ for some links 
> surrounding this issue.

Yes, and...?

Even if you don't want a separate physical infrastructure, defining a VLAN
is trivial.

Really, I can't see all that many scenarios where you'd deploy multiple 
nodes on a link with different MTU values and the internal traffic would 
be so high that optimizing the MTU used between these would be worth 
optimizing..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Oct 2003 15:27:25 +0300 (EEST)

On Thu, 23 Oct 2003, Iljitsch van Beijnum wrote:
> On 23 okt 2003, at 12:12, Pekka Savola wrote:
> > Even if you don't want a separate physical infrastructure, defining a 
> > VLAN is trivial.
> 
> Yes, and setting up a new TCP session is even more trivial. But somehow 
> people see the value of writing a 150 page specification to do 
> mobility.

Yes, and...?

You don't set up VLAN's for every session the hosts create.  You do it
once and you're done.