> 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. 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. > 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. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
