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