Erik Nordmark wrote:
Such a capability would enhance a layer 3 neighbor MTU management capability, but it isn't required. Operators can simply have routers annouce an upper limit on the MTU that may be used on a subnet. This doesn't impede the best case scenario where all the switches support a good sized MTU. Since the number of switches per subnet is typically much smaller than the number of hosts per subnet, getting all switches to support jumboframes is significantly simpler than getting all hosts to do the same.
Ah - now I get where you are going with this. From my "host perspective" it is the switches lack of support which is the main problem - but you are right that the inverse problem also exists.
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".
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. This might be constrained by the link with the smallest MTU, the node with the smallest receive buffer, etc.
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. (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.)
Note that this is different than the default MTU being 9k - since not all hosts support the larger MTU everybody would still need to use the default 1500 MTU for sending broadcast and multicast packets on the link.
Yes - this follows from the LCD discussion above.
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.
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.
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 http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-01.txt
Fred [EMAIL PROTECTED]
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
