On Fri, 22 Jul 2005 14:20:37 +0930 Mark Smith <[EMAIL PROTECTED]> wrote:
> Hi, > > On Fri, 22 Jul 2005 10:32:48 +0900 (JST) > Ryota Hirose <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > >From: Iljitsch van Beijnum <[EMAIL PROTECTED]> > > >Date: Thu, 21 Jul 2005 10:19:56 +0200 > > > > > My common sense tells me that the authors of RFC 2464 didn't consider > > > the case where the MTU would legitimately be larger than 1500 bytes. > > > They did consider the case where router advertisements contain an MTU > > > that is apparently incorrect, because it's larger than the standard > > > allows. > > > > > > Yes, your idea is a realistic, and also equal to almost current > > implementations, I think. > > > > BTW, suppose following netowrk. > > > > Internet > > | > > ROUTER > > | > > | 100BASE-TX / MTU=1500 > > | > > GbE-SWITCH > > | | > > | | 1000BASE-T / MTU=9018 > > | | > > HOST1 HOST2 > > > > HOST1, HOST2 and GbE-SWITCH support 1000BASE-T and Jumbo Frames, but > > ROUTER has only 100BASE-TX interfaces and doesn't support Jumbo > > Frames. In this network, ROUTER will send RA. If the MTU option, > > which value is 1500, is included in RA, HOST1 and HOST2 will accept > > it, and are disabled Jumbo Frames. So, if we want to use Jumbo > > Frambes between HOSTs, (1) HOSTs must neglect MTU option, (2) ROUTER > > must send RA without MTU option, (3) or ROUTER must send RA with MTU > > option which value is 9018, illegal MTU for ROUTER itself. > > > > (2) RA without MTU option is always valid. But (1) neglect MTU > > option, or (3) MTU option with illegal value for sender itself, are > > acceptable? > > > > I'd think not, probably in either (1) or (3), as an interface MTU value > implies that the other devices attached to the same segment / link can > also receive (and process) the MTU sized frames. > > To support differing MTU values on a single link/segment, each node > would have to somehow keep track of the Maximum Receive Unit value of > its link/segment neighbours. PPP supports doing this, and is able to do > it because a level of layer 2 parameter negotiation goes on before the > link is brought up. It is also simple to do because there is only one > neighbour. > > For this sort of thing to be supported on a multi-access media, such as > an ethernet, I'd think some sort of similar, per neighbour, layer 2 > parameter negotiation of discovery protocol would have to be developed. > 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. > A solution for your specific scenario would be to have some way of > specifying differing MTUs for onlink and offlink destinations, possibly > in the RAs from the router, such that offlink traffic, which goes via > the router, uses a MTU smaller than or equal to the MRU MTU of the > router's interface. It may be worth developing something like this if > your scenario is common enough. Initially I though it may not be, > however, thinking about it a bit more I could see this set up might be > fairly typical for residential broadband scenarios in the future. > A ND RA option, indicating the "router-MRU" or "offlink-MTU" value might be necessary and useful also. Necessary if nodes don't issue ND NSes for routers if they have already learnt the router's Link layer address via the RA. It may also be useful to have an onlink-MRU option as well, to allow for local traffic targetted at the router's onlink interface address(es), which may be used for administrative access to the router, although probably not necessary for the amount of onlink traffic a router receives. Useful if the router only has one other link, e.g., a link to the Internet, and the MTU of that link is smaller than the onlink MTU, a good example being a PPPoE 1492 MTU on a ADSL link. The router could annouce the other link's MTU as the offlink-MTU (assuming it is smaller than the LAN interface's MTU), which could avoid a PMTUD cycle for every new offlink connection that encounters the smaller 2nd hop MTU. 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. Thanks, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
