Hi, Bjoern, On 01/02/2012 07:10 PM, Bjoern A. Zeeb wrote: > Contrary to how a lot of people seem to read RFC 2460, especially the last > paragraph of section 5 (also subject to Florian's Errata 2843), I basically > read (in) the past: > > 4.5 "The Fragment header is used by an IPv6 source to send a packet larger > than would fit in the path MTU to its destination." > > ``You shall not add a fragment header unless you really need to''.
Well, it's supposedly (specs-wise) also used to help translating devices in the fragmentation of packets... > The only way you must add a fragment header for a packet size below 1280 is > when it is a packet going to a v4 destination (i.e. say through NAT64 these > days). How you can track this (if you can) and how you get that information > is beyond the scope of 2460 but you need to know to be able to. Otherwise > you shall not. That's not what the specs state. The specs say that if you receive an ICMPv6 PTB advertising an MTU <= you need not fragment, but should include a fragment header. > This is the reason ipfw originally dropped what people now seem to call > "atomic fragments". Well, it's a useful short-hand for "packets that hace a fragment offset of zero and for which the M bit is not set".. ;-) > When I PR started to look at the PR I consulted briefly with Bob and the > outcome of the short exchange for me was: > > - the "atomic frags" do not seem to hurt in this particular filtering case > and could possibly be allowed. Atomic fragments could be safely processed as if they were not fragmented traffic at all... see the I-D we published... > While I still feel that these "atomic frags" should be sent to the packet > shredder on first sight it seemed to match reality (and especially > operational impact) better. However I left a sysctl for individuals to > control their preference. ANy comments regarding processing them as non-fragmented traffic, as noted in draft-gont-6man-ipv6-atomic-fragments ? > Another thing on the "atomic frags" I was (partly) shown was that they seemed > to have a length in the 50 octets size which would even be way below other > minimums. So I am really not feeling too confident that it's not just silly > stacks or software bugs and it would really be thrilling if people could > figure > out OS and version and reason why some systems send them. Well I'm certainly am after that. However, the point is that we need not over-engineer this one: these atomic fraggments could be safely processed without running into the typical IP fragmentation issues... > On the entire "fragmentation related security issues" topic, I feel we are > seriously heading into wrong directions to just more complications rather than > simplifications. > > The idea of having the fragment offset to stay compatible the way things > worked > in IPv4 certainly was a great idea and has later proven to be a PITA. What > I'd > really like to have is a silly fragment counter 1..n, so no overlapping > possible > (and not just not allowed on paper anymore as that does not remove that code > to check from the stacks), simple handling of duplicate fragments, and no > "atomic frags" allowed. That makes a bunch of IP fragmentation attacks (mostly DoS) trivial... -- we should have learnt the leason from IPv4, shouldn't we? > Luckily the fragment header still has a lot of spare space that could allow > to indicate which scheme is used and dropping a packet unless a bit is set > (not being set indicating the old scheme) is really easy to implement, esp. > after a transition period and ripping the old code out would be as well > then;-) > I 'd really not want to add even more complicated house keeping and stuff > long term. You're already in a complicated position as a result of predictable I-Ds OpenBSD randomized them, OpenSolaris implemented the scheme that is descrivbed in the I-D I published... what's the big deal about it? Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
