RE: "RFC 2461bis" issue: MTU handling

[Pekka Savola <pekkas@netcore.fi>]

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: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On 
> > Behalf Of Fred Templin
> > Sent: Friday, October 24, 2003 9:06 PM
> > To: Iljitsch van Beijnum
> > Cc: ipv6@ietf.org
> > 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
> > 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
> > --------------------------------------------------------------------
> > 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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


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