Hi Stephen, On Fri, 22 Jul 2005 13:20:40 -0500 "Stephen Sprunk" <[EMAIL PROTECTED]> wrote:
> Thus spake "Mark Smith" <[EMAIL PROTECTED]> > > Thinking about this a bit more, this could probably be fairly easy to > > achieve by creating a "onlink-MRU" or "interface-MRU" option for ND > > Neighbour Advertisements. There'd need to be some logic in how a > > sending node selects the size of the packets that it sends to a > > neighbour, based on comparing the values of its own local interface > > MTU, the link's MTU as announced in the RA(s) and the target > > neighbours announced onlink-MRU, if it announces one. > ... > > If there aren't any big holes in what I'm suggesting, I'm willing to > > spend some time co-authoring an Internet draft on this. > > The hole is that there may be an L2 device in the middle which has a lower > MTU than the end hosts. The neighbor MTU is an upper bound, but it's not > guaranteed to work -- you need to probe to see what really works. > I agree that probing would be nice to have, however I don't think not having it is a "black" hole. When a larger than standard MTU is used (e.g., 9K jumbos over GigE verses the 802.3 standard of 1500), the operator has made a conscious decision to increase the MTU, and therefore needs to take responsibility for ensuring that intermediary layer 2 devices support the increased MTU. People who want use jumbo frames on GigE interfaces know usually that they have to also have jumbo frame capable switches.. If we make the assumption that the intermediary link layer devices support the largest node MTU/MRU on the segment, I think the problem becomes a lot simpler, and then the issues to solve are : (a) how to ensure large MTU/MRU capable end nodes use them when communicating between each other. (b) how to ensure end-nodes with smaller MTU/MRUs are not sent too large frames by the large MTU/MRU capable end-nodes. I think either of these issues could be solved by using a ND NS/NA MRU type option, and, because RAs can carry a link-layer address, negating the need for a node to perform a ND NS/NA transaction with the router, at least initially, have an RA also possibly carry an MRU indication. For multicast, the link standard MTU or the link RA announced MTU would be used. For nodes that don't implement this "MRU" option, they'll use the link standard MTU to communicate with their neighbours and vice-versa, as per IPv6 operation today. I do agree this is in some respects a half-way step - it would be better if a method of probing could take place within the link to cope with a diversity of MTU/MRU capabilities and limitations, including those of intermediarly layer 2 devices. Still, I think if the above allows people to mix and match differing speed and MTU nodes on a layer 2 infrastructure that is known to support the largest-possible node MTU/MRU, it could be beneficial. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
