Hi, all, Iljitsch van Beijnum wrote: > On 2-aug-2007, at 13:57, Iljitsch van Beijnum wrote: > > [...] > > Looks I wasn't done yet... Sorry for the bandwidth use, I should really > optimize my Maximum Message Unit. > > Thinking about tunneling/MTU/PMTUD: > > There is a recommendation floating around that suggests setting the > outer tunnel header DF bit to the value of the inner header DF bit. The > trouble with this is that it only works if: > > A. RFC 4821 is used, which is generally something the tunnel operator > can't know (also note that RFC 4821 capability is per transport, so even > if TCP has it other transports are likely to still fail on PMTUD black > holes), or > B. Packet too big messages generated for the outer tunnel header are > translated into packet too big messages relating to the inner tunnel > header, something that I don't think can be done in all cases with IPv4 > because not enough of the original packet is returned > > So for IPv4, I don't think copying the DF bit makes sense. This leaves > two options: > > 1. Do PMTUD for the tunnel > 2. Don't do PMTUD for the tunnel
How can a tunnel do PMTUD if it is:
a) unidirectional
b) uses IP or IPsec as encapsulation (4821 describes methods
for connection-oriented protocols, e.g., TCP and SCTP)
Overall, conventional PMTUD (via ICMP response) SHOULD be supported at
tunnel endpoints, but even if it is, there's no reason to expect that
tunnels will receive ICMPs any more than endpoints. (i.e., they tend to
be dropped by firewalls, etc.)
4821-PMTUD cannot be supported at most tunnel endpoints, AFAICT.
IMO,
tunnel endpoints MUST either:
1. set outer DF=0 and allow fragmentation (including at the
tunnel source
2. set outer DF=1 when their payload fits, or
drop the payload (when it doesn't) and send ICMPs back at
that time
Receipt of a too-big at the tunnel source should not be expected to be
translated to be sent to the original packet's source; it MAY be if
there is enough header to do so. The primary benefit of receiving such
messages is for subsequent packets; the tunnel source would decrease its
MTU, and then **other** packets from that source (or any other source)
would correct the actions above (#1 would make smaller fragments, #2
would generate ICMPs back to the source).
These rules apply equally to IPv4 and IPv6; in neither case should
tunnels fragment the encapsulated packet, IMO. Tunnels act like links,
and tunnel endpoints act like hosts - to the tunneled packet. Tunnels
should be transparent (and thus undetectable) to the packets that they
transit.
> An interesting question in this regard is what the maximum packet size
> should be for applications/transports that can't adjust their packet
> size dynamically and/or don't implement RFC 4821. For IPv6, the obvious
> answer is 1280, but maybe this is a bit too conservative for a general
> recommendation. I know that 1450 is often recommended for use with
> streaming video, but in practice this becomes 1478 with IP and RTP
> headers. (1498 for IPv6...) For IPv4, this leaves enough room for an
> extra IP header (20 bytes) OR a PPPoE header (8 bytes), but not for both
> or for GRE encapsulation (at least 24 bytes).
>
> Some choices and the extra headers they allow for:
>
> 1492: PPPoE
> 1480: PPPoE / IPv4
> 1476: PPPoE / IPv4 / IPv4 + GRE
> 1472: PPPoE + IPv4 / IPv4 + GRE
> 1460: PPPoE + IPv4 / IPv4 + GRE / 2 x IPv4 / IPv6
> 1452: PPPoE + 2 x IPv4 / 2 x IPv4 + GRE / PPPoE + IPv6
There are many other cases - notably IPsec tunnels, which consume even
more bytes. Tunnel endpoints may employ header compression which may
somewhat compensate for size inflation too. IMO, it's not useful to
guess these sizes or expected layerings, as the use of layered VPNs and
overlays is likely to increase over time.
Joe
--
----------------------------------------------------------------------
Joe Touch Sr. Network Engineer, USAF TSAT Space Segment
Postel Center Director & Research Assoc. Prof., USC/ISI
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
