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.
(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.
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.
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".
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.
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.)
Iljitsch van Beijnum
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
