Hi Fred,
2013/6/27 Templin, Fred L <fred.l.temp...@boeing.com> > 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 > fred.l.temp...@boeing.com > > > Just my 0.02$ > > Antonios > > 2013/6/27 Brian E Carpenter <brian.e.carpen...@gmail.com> > 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 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
