Iljitsch van Beijnum wrote:
> On 25 okt 2003, at 2:51, Fred Templin wrote: > >>> So one approach would be something like having a router >>> advertisement option that asserts "trust us; the L2 can in fact >>> support 9k" resulting in individual hosts deciding to send out an >>> option with their NS/NA saying "I can support receiving 9k". >> > > Right, that's what I was talking about. > >> Agree with the hosts sending ND messages saying: >> "I can support receiving 9K" but not necessarily with the >> rotuer saying "trust us; the L2 can in fact support 9k". The >> router should be advertising the lowest-common-denominator >> for all nodes on the link. > > > It's already doing that today. The "L2 can do 9k" indication should go > into a new message (option).
>> Nodes that can accept more than the lowest-common denominator >> should negotiate a larger MTU with their neighbors - even if the >> value they negotiate is larger than what is being sent in the MTU >> option in RA's. > > > Yes, but they must be aware of what the layer 2 equipment can handle. > If I hook up two boxes that can do 9000 bytes over ethernet, but the > switch is 1500 bytes only, I had better make sure those two boxes > stick to 1500.
Yes, I know. By "negotiate a larger MTU" I mean not only an initial indication of how much the *neighbor* can handle but also ongoing and continuous attention to how much the *L2 media* can handle.
>> (Similarly, nodes that prefer smaller than the LCD >> should negotiate a smaller MTU - even though they still need to >> support the LCD for broadcast/multicast.) > > > The good thing is that if we allow hosts to discover the maximum > usable MTU between them, we can now use the regular RA MTU option to > broadcast a much smaller MTU for this type of traffic.
But, if there are many routers on the link, what do you do if they aren't all broadcasting a consistent smaller MTU? RFC 2461 says to accept the most recently heard MTU - is that good enough?
>>> This still has the operational issue of what happens when >>> I need extra ports in my office and I get a cheap 4-port hub; neither >>> the IT department nor my hosts knows that this box is present and it >>> might not support jumboframes. One way to cope with this particular >>> topology, >>> but no other topologies of varying frame size switches, would be >>> for the host to exchange a 9k packet with the router before >>> deciding that it should declare itself 9k capable. >> > > Who says the router can handle the maximum size packets on a link? In > a SOHO environment it's not unusual to have some pretty fast boxes > with gigabit ethernet that support 9000 bytes, but since the hookup to > the internet is only a few megabits, the router has 100 Mpbs or even > 10 Mbps ethernet, with no support for jumboframes. > > But an exchange using the advertised packet sizes between the two > hosts wanting to use larger packets wouldn't be a bad idea.
Agreed.
>> You could use something like an IPv6 NS message that is artificially >> inflated in size for this as we have discussed in the past. But, it's >> not >> a once-and-done deal; if you're going to be probing the MTU you need >> to do it periodically so that L2 path changes don't result in black >> holes. > > > ND times out pretty quickly, right? Then this happens pretty much > automatically.
> >> General comment - it would be nice if folks would reveiw and comment >> on my drafts: >> http://www.ietf.org/internet-drafts/draft-templin-ndiscmtu-00.txt > > > Well, you don't waste many words. This must be the shortest draft I've > ever seen.
Economy and effectiveness in written expression are ideals I continue to strive for.
> You only consider the situation where the per-neighbor MTU is smaller > than the "official" link MTU as defined by the relevant "IPv6 over > ..." RFC or the MTU option in router advertisements. > > However, the situation where some hosts have the ability to use larger > packets than others and/or the official MTU could also easily be > addressed by the same mechanism. However, in that case there is the > additional complication that devices operating at lower layers (so > that they're unable to participate in IP layer mechanisms) may > restrict the maximum packet size. Now hopefully at some point layer 2 > mechanisms to deal with this will become available, but in the mean > time we need to solve this in IP. (I can imagine adding information > about the MTU to the ethernet autonegotiation protocol.) > > The way I see it, we can't touch the existing RA MTU option, because > that would lead to trouble with hosts that don't understand the new > way of handling the MTU. So the current RA MTU option would continue > to be used to advertise the minimum MRU (maximum receive unit) that > all hosts on the link must support. This value must be somewhere > between 1280 bytes and the value listed in the IP over RFC.
Agreed.
> Then there would be a new RA option that would function as the > "maximum MTU": hosts are not allowed to transmit packets larger than > this. This value must be equal to or higher than the IP over RFC value > if it's present. There could be a bit in this option that indicates > "if lower layers tell you it's ok to use this value" or "forget what > lower layers tell you, this value is the correct one".
I'm afraid I'm not bought into this one as being necessary (yet). We know from our physical/logical point of attachment what the largest possible MTU for the attached L2 media is - this is a given. So, to supply a maximum MTU that is larger than the attached L2 media can support in a single packet is saying that we expect the sender to do L2 fragmentation locally. Is this what you are saying, and is this really desireable? (Maybe; I'm willing to be convinced.)
> Finally there would be the per-neighbor MTU preference/capability > option. If the advertised neighbor MTU is smaller than the link MRU > this indicates that the neighbor is still able to receive packets upto > the size of the link MRU, but it prefers to receive smaller packets. > If the neighbor MTU is larger than the link MRU the neighbor is > capable of and willing to receive packets larger than the link MRU. In > that case, if the local system has a similar capability and > willingness, it may send packets of a size that is the minimum of the > local interface MTU, the link MMTU and the MTU advertised by the neighbor.
Sure.
> And if we're going to do this anyway, we may want to provide for a way > for routers to tell hosts what the largest packet size is that it can > forward. For instance, a simple IPv6-capable ADSL router obviously > supports a 1500 byte MTU on its ethernet interface, but if it uses a > tunnel for IPv6 connectivity it can't forward IPv6 packets that are > larger than 1480 bytes. So advertising this 1480 byte limit in a RA > option saves hosts from hitting PMTUD on the first hop all the time. > Also, if there is more than one router on the link and they support > different maximum routable packet sizes, the host can select the > router that supports the largest packets.
Right - this goes along with a question I asked above.
> Back to your draft. I would suggest making the draft a self-contained > set of new capabilities rather than going for updates of RFC 2461. > This should make both the technical and political aspects much less > painful. > > (Adding a new ND option type is an obvious IANA cosideration, BTW.)
OK.
Fred [EMAIL PROTECTED]
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
