Perhaps this wheel has been invented before? This sounds like MTU discovery. RFC 1063 ??
Mark Smith wrote: > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
