[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
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.


 >> 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.


 > 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.


 > 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.)



IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6