Hi Mark, Further comments below.
Le 8 mars 2010 à 15:51, Mark Townsley a écrit : > On 3/5/10 9:37 PM, Brian E Carpenter wrote: >> On 2010-03-06 05:52, Templin, Fred L wrote: >> >>> 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). Cheers, RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
