[CCing int area again] On 3-aug-2007, at 2:13, Templin, Fred L wrote:
I don't think "unless RFC4821" is reasonable either; perhaps "unless they make measures to react to silent failure, by RFC4821, or some other means, e.g., application timeout and retry with other MTUs".
I like the spirit of your text, but the problem I have with it is that it doesn't say how the application can discern loss due to an MTU restriction from loss due to, e.g., congestion.
I strongly disagree here. PMTUD isn't something that should happen in applications. It's easy to get it wrong, and applications tend to stick around for a LONG time.
Applications that use UDP or other transports that can't implement RFC 4821 should clear the DF bit in IPv4 so that fragmentation can happen as needed. Anything else will cause breakage.
For *-in-IPv4 tunnels, the choke point will come in routers in the middle of the network that have to support decapsulating tunnel endpoints. They may need to support reassembly for *many* such tunnels, and so they need to place a conservative and convenient upper bound on MRU - say, 2KB.
I think I get why we've been disagreeing on MRU issues: it seems what you mean when you say "MRU" is "maximum size of packets that can be reassembled". The MRU is generally dictated by hardware limitations and as such not all that interesting. But the maximum packet size that a tunnel endpoint is willing to reassemble is a very important choice. Limiting this to 1500 bytes or some such will probably come back to haunt us as jumboframe capability becomes more common. (Note that the tunnel egress device may not support jumboframes for other interfaces, but if the tunnel ingress point does, it's likely that large packets will come in as fragments.)
The IEEE isn't the only arbiter of link specs, but if you're picking an IEEE spec, you need to pick 1500, which means you probably want something like 1200 for the reasons you cite (reasonable levels of recursion).
1200 is too small for IPv6-in-(foo)-in-IPv4 tunnels; IPv6 will refuse to run over any link that can't do at least 1280.
1200 or 1280 is way too conservative. Trying to reserve room for IPsec tunnels is a no-win game IMO, and IPsec users don't care about performance anyway. For anything else ~ 1450 as a "shouldn't be subject to too much fragmentation" packet size used by UDP apps should be workable.
Because it's not a BCP; it's an update to a standards-track doc, not an operational recommendation (which is what I think of BCPs as being). Perhaps 2003bis should encompass 6-in-6, etc. as well.
The 2KB MRU is an operational recommendation, so maybe that should go as a 1pg BCP? In terms of the tunnel encapsulation requirements, why couldn't we just write up a brief spec and say: "This document updates RFC2003 (et al)"? (Then again, maybe we could get by with just tucking the 2KB MRU into the spec also...)
Note that EDNS0 often advertises a 4096 byte packet size. If we aren't going to allow a full 9000 byte "standard" jumboframe or larger, I'd shoot for around 4.5 kilobytes. If you're going to fragment anyway you may as well get to send packets of at least a somewhat decent size, 2048 is hardly enough to bother with. BTW, on FreeBSD and MacOS X:
> sysctl -a | grep dgram net.local.dgram.maxdgram: 2048 net.local.dgram.recvspace: 4096 net.inet.udp.maxdgram: 9216 net.inet.raw.maxdgram: 8192 _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
