Remi, >>>>> -----Original Message----- >>>>> From: Rémi Després [mailto:[email protected]] >>>>> Sent: Friday, March 05, 2010 6:34 AM > >>>>> Fred, Ole, Brian, >>>>> >>>>> Until PMTUD is made reliable in IPv6 (btw an important objective), all >>>>> IPv6-enabled hosts should have >>>>> their MTU set to 1280 to avoid IPv6 blackholes. >>>>> This could in principle apply only to IPv6 packets that leave customer >>>>> sites, but as long as hosts >>>>> have only one MTU parameter, it has to apply to all packets. >>>>> Since typical hosts have longer default MTUs than 1280, advertising >>>>> MTU=1280 on links that offer >>>>> paths to the global Internet appears to be the only available tool at >>>>> hand. >>>>> >>>>> The proposal is then to replace: >>>>> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined >>>>> automatically or configured >>>>> directly, on the LAN side by setting the MTU option in Router >>>>> Advertisements [RFC4861] messages to >>>>> the 6rd Tunnel MTU." >>>>> by: >>>>> "As long as the path MTU discovery has not been made reliable, a 6rd CE >>>>> SHOULD advertise on the LAN >>>>> side, in the MTU option of Router Advertisements [RFC4861], an MTU of >>>>> 1280 octets . This is to >>>>> prevent that longer packets that could have traversed the local 6rd >>>>> domain may be discarded, because >>>>> of their size, further in the Internet because of their size. Note that >>>>> this may cause all hosts >>>>> attached to the link to use a reduced MTU even for link-local >>>>> communications, IPv6 and IPv4." >>>>> >>>> The 1280 would be disappointing; I'm sure we can do better. >>>> >>> As has been said before, in theory there is no difference between theory >>> and practice, but in practice, there is. >>> >>> Right now today a number of ISPs are planning to deploy 6RD, and we have >>> already seen clear evidence from 6to4 deployment that setting the MTU to >>> 1280 is a necessary evil at the moment. So I think this advice should be >>> in the specification, as a SHOULD. Otherwise we'd be misleading those >>> ISPs. >>> >> I don't think that the evidence from 6to4 is directly applicable to 6rd as >> the administrative domain of deployment is quite different between the two. >> Absent working automatic mechanisms, MTU is very much a administratively >> controlled item today. Since a given 6rd deployment is limited to one (or >> perhaps a few) administrative domain(s), the MTU problem is generally more >> tractable than with 6to4 which typically has no readily assignable >> responsible party to address a problem when it occurs. >> >> We do have evidence that 6rd works fine with a 1480 MTU over an IPv4-enabled >> link with MTU of 1500. > > Hi Mark, > > I certainly don't contest this where 6rd is deployed today (being as you well > know a happy user of Free's implementation ;-) ). > > But the point is that if one of my outgoing packets leaves Free's network and > reaches another network where the MTU is 1280, which is permitted, it will be > discarded. > If PMTUD cannot be relied on, this can create a blackhole. > > (Clearly paths to Google and to the IETF have MTUs at least 1480, which is > fine, but the recommended solution must work for all IPv6 servers. Note that, > as long as PMTU is considered unreliable, both Google and the IETF should > also better send IPv6 packets with an assumed 1280 path MTU. > >> Some bugs, not necessarily 6rd-specific, have been uncovered in the process, >> and fixed. That's a good thing. > > >> Let's not throw in the towel until the game is truly over. > > Be sure I will not throw the towel and continue to fight for IPv6 to be > reliably usable (first), and with more and more efficiency (next).
but you are making an argument that _every_ IPv6 link should be a maximum of 1280 bytes. I don't think that is something 6rd should prescribe. cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
