On Mon, 8 Mar 2010 17:05:35 +0100 Rémi Després <[email protected]> wrote:
> > Le 8 mars 2010 à 16:43, Ole Troan a écrit : > > > 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. > > Only every IPv6-enabled link where it is not known, by some exterior means, > that larger MTUs will work for all possible e2e paths. > > In my understanding, we MUST prefer a 100% reliable connectivity to a 15.6% > gain in MTU size (1480 instead of 1280, working in typical cases but not in > all). > 100% reliable connectivity on the Internet doesn't exist, regardless of whether the protocol is IPv4 or IPv6, or MTUs are large or small. Hosts need to be able to cope with packet loss, whether it be TCP acks, PMTUD feedback etc. PMTUD has it's issues, which is why methods defined in http://tools.ietf.org/rfc/rfc4821.txt exist, that don't rely on routers sending back next link MTU information. The Linux kernel has had an implementation of it for at least two years. > Now, if one could prove that there is no more blackhole possibility with 1480 > than with 1280, I would be glad to withdraw my proposed amendment. > Do you have evidence to support your view? Sure it's possible, but from my experience of running a 6to4 tunnel for quite a number of years with a local/initial MTU of 1472 bytes for years (1492 being because of PPPoE's 1492 MTU) without any issues that have ended up being because of broken PMTUD. > But the available proof is rather that blackholes are possible with 1480, and > not with 1280. (I have not been aware of this for long, but being now well > aware, I believe there is no real choice.) > Your right about 1280. However, following that logic, the IPv4 Internet should have an MTU of no greater than 576 bytes, because blackholes are possible with MTU's larger than that. Yet the common MTU on the IPv4 Internet is 1500. Sure there are occasional work arounds like MSS hacks having to be put in place, however they're a reasonable trade off verses having packet per second forwarding rates go up by around 3 times. > Like others, I am not enthusiastic about this, and will work improve the > future, but let's be consistent in the present, and make IPv6 reliable. > > Cheers, > RD > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
