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 2461So, 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 --------------------------------------------------------------------
