Re: "RFC 2461bis" issue: MTU handling

[Fred Templin]

Thanks Pekka,

However, I believe protocol designers/implementors would appreciate
the flexibility afforded by a new option type.
Fred
[EMAIL PROTECTED]
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 PROTECTED] [mailto:[EMAIL PROTECTED] On 
Behalf Of Fred Templin
Sent: Friday, October 24, 2003 9:06 PM
To: Iljitsch van Beijnum
Cc: [EMAIL PROTECTED]
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 PROTECTED]
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 PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
       



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

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

 



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