Re: "RFC 2461bis" issue: MTU handling

[Fred Templin <ftemplin@iprg.nokia.com>]

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
ftemplin@iprg.nokia.com

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
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------