On 7/1/2013 2:50 PM, Templin, Fred L wrote:
Hi Joe,
-----Original Message-----
From: Joe Touch [mailto:[email protected]]
Sent: Monday, July 01, 2013 2:34 PM
To: Templin, Fred L
Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area
Subject: Re: [Int-area] New Version Notification for draft-bonica-
intarea-gre-mtu-00.txt
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.
SEAL helps with the DPI because it makes sure that the ULP headers
appear in the first fragment
You can't know that unless you parse the IPv6 header chain. And adding
SEAL inbetween IPv6 and the inner IPv6 adds one more step to that chain.
Either way, DPI has to follow the chain step-by-step, vs. in a single
leap as with IPv4.
- there is no possible way to construct
a "runt" first fragment with SEAL. SEAL also takes care of the
overlapping fragments attack vector. There is a growing laundry list
of other complaints about IP fragmentation (e.g., Identification field
length and ID setting strategy) that do not apply to SEAL.
Yes, but support for (vs not interfering with) DPI isn't one of them.
Further, we *have* fragmentation now. Getting rid of it would be
premature until SEAL is required and widely deployed.
SEAL is compatible with IP fragmentation, so we can transition
to SEAL without having to first decommission IP fragmentation.
So, maybe the document should advocate "SEAL transition" rather
than "IP fragmentation deprecation".
You can talk to Ron about that. But AFAICT that won't solve the overall
problems his draft is seeking to address (whether they can or should be
addressed is debatable, IMO).
...
Right. That's why IPv6-in-IPv4 transition mechanisms cheat and
assume 1500 when the specs say they can only assume 576.
...
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.
I think there is way too much deployed base out there now
that boldly assumes 1500 that it would be impossible to put
them back in the bottle now.
Then your table should have said IPv4 has a minMRU of 1500, but it
doesn't. That's widely deployed, but cannot be assumed. Esp. on
low-powered/low-mem devices.
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.
There are too many compelling reasons to migrate away from IP
fragmentation and move toward SEAL. Maybe also look at some of
the discussion on the IPv6 list so we can avoid duplication.
I agree that SEAL is better than IP at fragmentation, but it's still a
network fragmentation layer when used for IP tunnels. It doesn't solve
the issues that some are concerned about recently.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
