[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "RFC 2461bis" issue: MTU handling
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
>>> 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
>>> 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.
>> 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
>> 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
> ND times out pretty quickly, right? Then this happens pretty much
>> General comment - it would be nice if folks would reveiw and comment
>> on my drafts:
> 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.
> 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
> 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.
> 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
> (Adding a new ND option type is an obvious IANA cosideration, BTW.)
IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6