Hi, Fred,
On 7/1/2013 1:27 PM, Templin, Fred L wrote:
...
On 7/1/2013 8:34 AM, Templin, Fred L wrote:
OK, but IPv4 also has a limit of minMRU=576. So, we have:
IPv4 minMTU = 576 (*)
IPv4 minMRU = 576
IPv6 minMTU = 1280
IPv6 minMRU = 1500
(*) Even though the specs say that IPv4 minMTU = 68, everyone
seems to be saying that for practical purposes it is now 576.
There needs to be a difference between the minMTU and the minMRU; if
not, then IP-in-IP tunnels will never succeed without a separate
fragmentation and reassembly layer - and although SEAL provides
that,
we
currently do not require anything like that for X-in-X
encapsulation.
With IPv4, there is no difference between minMTU and minMRU.
Tunnels over IPv4 therefore set DF=0 to allow for in the
network fragmentation if necessary.
But then that's useless. Let's say you already send just 576, and set
DF=1, and that packet encounters an IPv4 tunnel. You add 20 bytes of
header, resulting in 596.
At the tunnel ingress, you can't fragment the inner packet because DF=1
- and why shouldn't it be set? You're using the minMTU.
At that ingress, you can't fragment the outer packet because you would
need the egress to reassemble something that is 596 -- larger than the
egress ever expected to reassembly (minMRU).
So you drop the packet and send an ICMP too-big back to the source, who
drops it because they're already sending minMTU packets and doesn't
think it should have to drop the MTU below that.
AFAICT, you now have broken the path completely.
For IPv6-within-IPv4 at least, most of these "transition mechanism"
tunnels assume a minMRU of 1500 even though the IPv4 specs say that
the MRU is 576. Sure, that is broken but it seems to have become the
IPv6 transition mechanism "best practice".
I was giving an example of IPv4-in-IPv4, to demonstrate that when minMTU
== minMRU then tunnels are not possible.
With IPv6, minMTU is smaller than minMRU but that does not
guarantee that a packet sent by the ingress can be received
by the egress without fragmentation.
No, but it does guarantee that the packet can traverse a tunnel and
still make it to its destination.
Right, but remember that the IPv6 minMRU is only 1500 bytes.
So, we can't assume an unlimited reassembly buffer on the
tunnel egress.
Agreed.
The difference between minMTU and minMRU is the amount of accumulated
headers you can accommodate by tunneling. At 1500-1280, that's 5 levels
of nested IPv6 tunnels, or more than a few IPsec tunnel-mode tunnels if
needed.
I addressed this point on the IPv6 list, but think for a moment
what this means. It means that the fist tunnel ingress would have
to configure a 1280 MTU, the second tunnel ingress would need to
configure a 1320 MTU (to accept encapsulated packets from the first),
the third tunnel ingress would need to configure a 1360 MTU (to
accept encapsulated packets from the second), etc. up to 5 levels
of nesting. I don't know about you, but I can imagine many situations
where it is not possible for a single operator to lay hands on every
tunnel ingress so as to carefully set each MTU in this way (I gave
one example on the IPv6 list).
We agree, but the punchline is that:
a) minMRU *MUST* be larger than minMTU, or else there cannot be tunnels
how much larger depends on how much nesting you expect;
IPv6 allows 5 levels if plain nesting and around 2 of IPsec.
The former seems fine, but the latter is tight. I would not
at all be surprised if future networking ended up experiencing
more than 2 levels of IPsec tunnel.
b) we CANNOT deprecate fragmentation
if we do, we are deprecating tunneling
That's not as much as I'd like, but it's at least non-zero.
I think the maximum acceptable level of nesting is somewhere
between 5 and 10 before the nesting would be declared "recursive"
(i.e., a routing loop). SEAL allows up to 8 levels of nesting.
It's "recursive" when it's recursive, and there's strictly no way to
determine that because an address can have different meanings at
different layers. The only solution would be to have each layer insert a
"thumbprint" and look for cycles in that, but that approach would
consume the encapsulation budget more quickly.
Two levels of tunnel are required to allow revisitation, where a single
machine can emulate multiple virtual routers (without requiring OS
virtualization such as VMware). More levels are needed to support other
kinds of abstraction; my own work used up to 4 levels for
non-demonstration purposes (we demo'd 16).
> RFC2473 acknowledges
this by using fragmentation at the ingress as a limiting
condition for when the MTU within the tunnel becomes too
small. This can happen for example if there is a 1280 MTU
link within the tunnel, if there are nested encapsulations
within the tunnel, etc.
Yes, but if minMRU == minMTU, then the number of encapsulations
supported is zero.
Right. That's why IPv6-in-IPv4 transition mechanisms cheat and
assume 1500 when the specs say they can only assume 576.
Agreed. That's why we need *realistic* numbers for that, not merely
those that reflect what's implemented (e.g., for IPv4).
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
