Cutting to the chase...
On 7/1/2013 2:18 PM, Templin, Fred L wrote:
If we deprecate IP fragmentation but then at the same time replace
it with SEAL we will still have the functionality that we need.
That's replacing fragmentation with fragmentation. The only reason to
want to get rid of fragmentation is to simplify endpoints and/or
simplify forwarding that does DPI. SEAL won't help either of those.
Further, we *have* fragmentation now. Getting rid of it would be
premature until SEAL is required and widely deployed.
> >> > 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).
>
Right, but what I am ultimately after is an unlimited tunnel
MTU (I think you were on board with this idea from earlier
discussion). The only difference is that I want fragmentation
and reassembly out to 1500 bytes only, and then let the bigger
packets go through unfragmented as long as they fit. "Take care
of the smalls, and let the bigs take care of themselves."
We don't disagree on IPv6. My claim is that for IPv4 it is *necessary*
that endpoints support MTUs lower than 567 to allow IPv4 fragmentation
to support IPv4-in-IPv4 tunnels, including IPsec.
There are two solutions, of course - deploying SEAL would be the other.
But I would expect that fixing incorrect implementations of an existing
standard would be a lot easier than getting new code deployed for
something that isn't yet standard.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
