Iljitsch van Beijnum wrote: > [to our little ad hoc group AND internet area list] ... >> + Finally, could we also say that tunnel decapsulators SHOULD >> + configure a minMRU of 2048 to account for encapsulations >> + that might extend a 1500 byte ULP out to the IEEE 802.as >> + maximum frame size? > > Not sure what you mean here. Obviously people should be prepared to > receive the largest possible packets supported by the hardware > configuration in use. That means 1500 bytes for ethernet, or whatever > jumboframe size is in effect. Trying to receive more than the hardware > will do is an exercise in futility...
RFC1122 already requires that they be able to receive and reassemble to
the size of the largest packet of their directly attached interfaces.
> However, we CAN recommend that people make their tunnel MRUs equal to
> the size of the largest physical interface MRU - encapsulation size,
Which physical interface? If directly attached, then that's already
required by 1122, since a tunnel endpoint acts as a host (it sources
and/or sinks packets). If some other interface, e.g., along the path of
a tunnel, that cannot be required any more than for any other host -
that is the purpose of PMTUD to discover anyway. I doubt we can or
should require PMTUD for tunnel hosts, since tunnel encapsulation
protocols are not necessarily amenable to RFC4821.
> even if the tunnel MTU is smaller than that. But I would recommend
> making the tunnel MTU equal to that MRU rather than use the IPv6-in-IPv4
> tunneling practice of a 1280 byte MTU to accommodate multiple levels of
> encapsulation.
Any guess of a specific size is likely to be incorrect. Some tunneling
mechanisms use quite a bit of space (e.g., IPsec tunnel mode), and the
number of levels of encapsulation that might occur - especially as we
move forward with more VPN and overlays - will be hard to predict.
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
