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

Reply via email to