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