On Tue, Jul 26, 2005 at 08:41:39PM +1200, Perry Lorier wrote: > > > I'd like to suggest a two phased development approach, based on whether > > layer 2 can be assumed to fully support the larger MTUs or not (I think > > the following is also probably a summary of the couple of threads of > > discussion in the emails of the last couple of days) : > > > > (1) Making the assumption that layer 2 can support larger, non-standard > > MTUs (as it has been engineered to by a network designer), develop > > mechanisms that allow nodes to announce their non-standard, larger MTU > > support. If a pair of nodes find they both support larger MTUs/MRUs, > > then they'll take advantage of it for unicast traffic. If the unicast > > communcations fails because layer 2 doesn't support the MTU/MRUs it is > > supposed to, then layer 2 is broken and it is up to network admin to > > fix it. > > It's difficult to say what MTU L2 should support. If you have a GigE > link then you might assume 9k MTU's (which varient of 9k?), and the > remote end also might have GigE, but there is a 100mbit switch in the > middle preventing communication between both ends to use 9k MTU's. > > You can barely assume 1500 as people tend to tunnel things, you can get > technologies like vlans, 802.1x or mpls eating heavily into your mtu. > You should assume 1280 bytes and hope that you can raise it.
You can't really assume 1500 on L3, but PMTU discovery should work there. On L2 I thought you generally had 1500 despite vlans and 1x. > More and more end users aren't qualified network admins, they are people > who plug device A into device B and expect everything to "just work". > Given how many PMTU failures you see on the production internet today, > assuming even qualified network admins have the time and resources to > debug current MTU mismatches seems unlikely let alone future ones. > > Any system which requires admin intervention to work IMHO will be a > dismal failure. > > > In all other cases (eg. multicast, unicast without these announcements), > > the MTU used will be the either the link layer MTU standard or the link > > MTU value as announced in RAs (i.e., along the lines that this MTU value > > has been announced because the link layer technology doesn't have a > > standard value e.g. token ring. There is a corner case that needs to be > > covered where a larger than standard MTU has been annnounced for a > > technology that does have a fixed MTU e.g. 1500 byte ethernet, and a > > sub-set of nodes only support the standard size). > > For multicast it seems wise to just "give up" and use 1280. Even if you > can determine the MTU of all nodes in a multicast group, there are no > assurances that it is going to remain stable and changes are much harder > to deal with than the unicast case. Maybe allow an admin to tune this > higher if they want to. PMTU discovery does work for IPv6 multicast (you're supposed to get packet too big ICMP messages) and at least implementations I'm familiar with do indeed support it. It is less stable since the PMTU might change when people join or leave the group. With respect to L2 it's not an issue as long as the hosts interface is configured to a common L2 MTU. Supporting different MTUs for different hosts on the same link sounds rather scary IMO. > > These mechasims only come into play if non-standard MTU support has been > > enabled (in some mechanism specific manner, which may be via a new RA > > option, or even just configuring larger, non-standard MTUs on the > > interfaces that are capable of larger frames). The out-of-the-box > > plug-and-play IPv6 functionality that exists today will be preserved if > > these mechanisms aren't enabled, by all nodes using the link standard MTU > > or RA announced MTU. > > > > I think this solution would be relatively quick and simple to develop, > > and is applicable to any networks that have been specifically designed > > to support larger, non-standard MTUs. > > > > (2) Develop mechansisms that can dynamically discover MTU/MRU sizes, > > limitations and variations over time, including within intermediary > > layer 2 devices e.g., switches. It seems that some solutions have > > already started to be developed in this area, including the email > > discussion between Iljitsch and Perry, Matt Mathis in > > draft-ietf-pmtud-method-04.txt and Fred Templin in > > draft-templin-ipvlx-02.txt. > > > > If the above phased approach is followed, I think it would be useful to > > allow any ND or other options developed for phase 1 to be re-used for a > > phase 2 solution if they can. > > > > Any thoughts on this approach ? > > If some options can be found for ND which significantly improve the > situation in (1), then by all means :) I personally think that we > should resign ourselves to the fact that a single L2 segment having the > same MTU is less likely to occur in future, rather than more likely so > any attempts to try and find a unified MTU for a link is unlikely to be > profitable. My personal perhaps naïve thinking is that the administrator should configure all hosts on the link to a common MTU, and ND RAs would have been a fine tool for that. But according to 2464 it seems it must be configured in some other way. Stig > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
