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

From: "Bound, Jim" <[email-masked]>
Date: Sat, 25 Oct 2003 00:19:17 -0400

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.

/jim

> -----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
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Sat, 25 Oct 2003 08:36:34 +0300 (EEST)

> 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...?

-- 
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: Fred Templin <[email-masked]>
Date: Mon, 27 Oct 2003 10:43:04 -0800

Thanks Jim,

Fred
[email-masked]