In your letter dated Fri, 27 Jan 2012 16:18:28 -0300 you wrote: >Hi, Philip, > >On 01/27/2012 02:36 PM, Philip Homburg wrote: >>> (For IPv6, I suggest that you talk with davem@, which noted that we >>> would not even want such a scheme for the IPv6 (i.e., 32-bit long) >>> fragment ID). >> >> For avoiding collissions, a single global counter is optimal. To avoid traff >ic >> analysis, a counter per destination is proposed. But how do you initialize >> that counter? From a random number. >> >> So any system that is too busy to keep destination cache entries for a long >> time will effectively send fragments with a random number. > >There are always tradeoffs in the IP-ID generation algorithms. If you >don't like any of the forementioned approaches, you may have a set of >counters (say, 1024, 2048, or 65K, if you will), using an approach >similar to that of algorithm 2 in my flowlabel I-D.
I'm not really keeping track of flowlabel stuff. Do you have a more specific reference? draft-gont-6man-flowlabel-security-02 doesn't seem to have an algorithm 2. And I couldn't find any other flowlabel draft with your name on it. >Note, however, that if you cannot maintain a destinations cache, you may >also have issues with PMTUD, etc. > >I'd argue that the scenario that you're describing, while not uncommon, >probably does not apply for the general case. So it would not be unfair >to have, at least for those scenarios, some specialized policy such as >the one described above. PMTUD is just a mess. For IPv4, either you have an mtu of 1500 or you use mss clamping. Relying on pmtud gives a bad user experience. For IPv6, the situation is not any better. But there is new option, servers may simply set their mtu to 1280 and no more pmtu problems. PMTU blackhole detection is surprisingly uncommon. IPv6 also lacks NAT, so either CPEs will have to do mss clamping on the fly or lots of servers will end up with just setting the mtu to 1280. >> Then you also need those packets to >> either suffer the loss of a fragment (all at the same time) or you need >> sufficient reordering that 256 packets somehow overlap during fragmentation. > >Not sure what you mean. As long as one packet gets lost, the IP ID space >will get trashed. If another packet reuses the same ID, then it's very >likely that the reassembly process will fail, and it may be even >possible that some of the legitimate fragments remain in the fragment >reassembly buffer, trashing the IP ID space. With random IDs, every packet that arrives has a 1/65536 chance of colliding with a packet that is awaiting reassembly. Total chance depends on the reassembly timeout and the packets rate. Needless to say this only applies to IPv4 hosts that are behind a link smaller than 1280. >> So, as far as I can tell, the risk that something goes wrong if you don't se >nd >> the fragment header is something very close to zero. The chance that sending >> the fragment header is actually beneficial is also very small. > >So... you're essentially relying on guesswork because: > >a) You consider that requiring the translator to send an ICMPv6 PTB is >way too much, (which is already a requirement for PMTUD), and, I don't particularly care about the translators. >b) You consider that processing atomic fragments as described in >draft-gont-6man-ipv6-atomic-fragment is... what? One option is that hosts behind such translators will have mss clamping because PMTU doesn't work anyhow. This is very likely, because you need that on the current IPv4 network. Most likely many servers will just break PMTU for this case, which requires translators to just insert a random ID and forward the packet. Effectively changing the protocol. However, there is a small chance that server operators will actually follow the RFC and start always including fragment headers. And that's not only very annoying, but also an enormous waste of resources. Effectively, we are saying that it was an enormous mistake to not include fragmentation in the IPv6 header and that we removed it from the routers. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
