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