Carlos,
On 2/18/2014 6:53 PM, Carlos Pignataro (cpignata) wrote:
Joe,
On Feb 18, 2014, at 1:08 PM, Joe Touch <[email protected]> wrote:
On 2/18/2014 9:27 AM, Templin, Fred L wrote:
Hi Joe,
You seem to be talking past me - maybe it was because I wrote too much.
The fragmentation story for tunnels is very simple as follows:
Yes, IMO they are, and here's mine:
- if a tunnel CAN transit a packet, it MUST try
i.e., the MTU of a tunnel that uses IPv6 encapsulation
is 65535 - encapsulation headers
Where is this specified (other than stated by you in your email with
2119 language)?
Nowhere, and it need not be specified. It's basically the definition of
an MTU.
This defeats the purpose of a configurable MTU, and
frankly shows requirements that do not exist and are not met in real life.
Take for example RFC 1812, Section 3.3.4., "MTU":
The MTU of each logical interface MUST be configurable within the
range of legal MTUs for the interface.
RFC1812 is a spec for routers (gateways), not for tunnels. A tunnel is a
link, where two or more links interconnect at a gateway.
I.e., the *link* has an MTU, which is defined as the largest message
that can traverse the link. It's not defined as the largest message that
can traverse the link without fragmentation inside the link.
The context of the above requirement is the configurable value within
the router. Sure, the router operator can override the link MTU by
setting an *interface* MTU <= link MTU.
However, when we specify a tunnel technology, we are talking about the
link MTU, not the interface MTU.
Many Link Layer protocols define a maximum frame size that may be
sent. In such cases, a router MUST NOT allow an MTU to be set which
would allow sending of frames larger than those allowed by the Link
Layer protocol. However, a router SHOULD be willing to receive a
packet as large as the maximum frame size even if that is larger than
the MTU.
The above basically says, in other words, "routers MUST NOT set the
interface MTU larger than the link MTU, and routers SHOULD receive
packets larger than the interface MTU as long as it is no larger than
the link MTU".
Again, for tunnels, we're talking about the link MTU.
Apologies as I have said the following on this list more than once,
but to reiterate: if you consider a tunnel as a logical link, the "link
max frame size" is 64k - tunnel encap. But that does *not* mean that's
the MTU, nor that packets larger than the tunnel MTU need to be
the interface MTU...
fragmented after encap because they fit this max link size.
max link size = tunnel MTU.
It does mean that the egress MUST be capable of reassembling any packet
no larger than the tunnel MTU.
So the *tunnel MTU* is 64K.
Yes, at the router, the *interface MTU* may override this to a lower
value as a configuration parameter.
If the MTU is configured on an ethernet link to be 500 B, but the
you configure an interface MTU, not a link MTU
physical media can (capable) send larger sizes, what happens with a
1000B packet?
at the router, that depends on the interface MTU - if it's 500B, then
the packet would be dropped by the router and an ICMP PTB sent upstream.
note that this router MUST be able to reassemble (at the "link layer",
i.e., the added IP header) fragments that transit a 1000B IP packet,
even if the interface MTU is 500B.
- if a tunnel CANNOT transit a packet, it rejects it
i.e., anything larger than "65535 - encap headers"
Everything else mistakes MSS (maximum) for PSS (preferred).
Preferredis the min of the MSS's. An IPv6 tunnel limits MSS only insofar as
packets larger than 65535-headers cannot traverse it.
Similarly, where is "preferred" specified?
I was introducing that term.
And these are segment sizes and not MTUs?
Nope; I mistyped, and meant MTU and PTU, but I think the concept is
equally applicable to transport layer segments (MSS and PSS).
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
