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

[Antonios Atlasis <[e-mail]>]

Hi Fred,


2013/6/27 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.
>


Actually, I was not talking only about SEAL, but generally. If this is the
case, the minimum acceptable size of fragments could be discussed/adjusted
accordingly, but as it is, OS accept as small as 56 bytes fragments!



>
> > 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.
>

Again, generally speaking (and not just for SEAL) RFC 5722 "allows" the
abuse of its recommended policy for launching DoS attacks (a single
overlapping fragment will result in discarding a whole datagram). On the
contrary, if  only the overlapping fragment is discarded, at least DoS will
be slightly more difficult.


>
> > 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.
>
>
I agree

Thank you too

Antonios



> 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
> --------------------------------------------------------------------
>
>