RE: draft-bonica-6man-frag-deprecate

["Templin, Fred L" <[e-mail]>]

Hi,

> a. Tiny fragments (smaller than 1280 bytes) should not be accepted (unless they are atomic fragments or > the last fragment of a datagram).

I disagree that all fragments less than 1280 bytes should be classified
as "tiny fragments". For nested tunnels, for example, the first tunnel
ingress may wish to fragment to a smaller size (e.g. 1024 bytes) so that
subsequent tunnel ingresses do not have to fragment further. I think a
"tiny fragment" is simply an initial fragment that does not include all
extension headers plus upper layer headers.

On the other hand, SEAL fragments cannot be smaller than 256bytes
so there is no possible way to create a truly tiny SEAL first fragment.
SEAL also requires the sender to include all upper layer headers in
the first fragment unless they absolutely cannot fit due to a size
restriction.

> b. RFC 5722 should be updated so as only the overlapping fragments to be dropped, not all the ones
> already received, or the ones that follow (as it is the recommendation now). This is already
> implemented by FreeBSD and seems to me the most proper way for handling overlapping fragments.

SEAL has a strategy for dealing with overlapping fragments. It would
be interesting to hear whether it meets your understanding of how best
to handle overlaps because we can still make changes now if something
doesn't look right.

> We should also never forget that the rest of IPvt6Extension headers can result in datagrams much
> bigger than 1280 bytes, 1500 bytes, or even more. So, if you want to deprecate fragmentation in IPv6,
> you should also deprecate or at least change the extension headers usage in IPv6. Which actually means,
> redesign IPv6.

I agree that excessively-long extension headers are problematic
in any case - especially if the length of the extension headers
exceeds the effective path MTU. That needs to be fixed no matter
what frag/reass scheme is applied.

Thanks - Fred
[e-mail]
 
> Just my 0.02$

Antonios

2013/6/27 Brian E Carpenter <[e-mail]>
Cutting to the chase, and assuming that the next version
will have more analysis and observational evidence, I'm thinking
something like the following:

3.  Recommendation

   This memo deprecates IPv6 fragmentation and the IPv6 fragment header.
   Application and transport layer protocols SHOULD support effective
   PMTU discovery [RFC4821], since ICMP-based PMTU discovery [RFC1981]
   is unreliable. Any application or transport layer protocol that
   cannot support effective PMTU discovery MUST NOT in any circumstances
   send IPv6 packets that exceed the IPv6 minimum MTU of 1280 bytes.

   IPv6 stacks and forwarding nodes SHOULD continue to support inbound
   fragmented IPv6 packets as specified in [RFC2460]. However, this
   requirement exceeds the capability of some types of forwarding node
   such as firewalls and load balancers. Therefore implementers and
   operators need to be aware that on many paths through the Internet,
   IPv6 fragmentation will fail. Legacy applications and transport layer
   protocols that do not conform to the previous paragraph can expect
   connectivity failures as a result.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------