On 3. Jan 2012, at 05:04 , Fernando Gont wrote: >> 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?
More than knowing all the fragment offsets upfront with the first packet for almost all implementations? Seriously? Who implements packet size randomizations for fragments to avoid that? >> 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, Yeah and so do other BSDs derived from KAME... ( http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/ip6_output.c#rev1.397 ) > OpenSolaris implemented the scheme that is > descrivbed in the I-D I published... what's the big deal about it? ... but the above was not about the Identification field. -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
