On Fri, 6 May 2016, David Lang wrote:
On Fri, 6 May 2016, Jonathan Morton wrote:
On 6 May, 2016, at 22:14, David Lang <[email protected]> wrote:
On Fri, 6 May 2016, Jonathan Morton wrote:
On 6 May, 2016, at 21:50, David Lang <[email protected]> wrote:
what IP id are you referring to? I don't remember any such field in the
packet header.
It’s the third halfword.
half a word is hardly enough to be unique across the Internet, anything
that small would lead to lots of attackes that inserted garbage data into
threads.
It doesn’t need to be globally unique. It merely identifies, in
conjunction with src/dst address pair (so 80 bits in total), a particular
sequence of fragments to be reassembled into the original packet. If the
fourth halfword is zero (or has only the Don’t Fragment bit set), the IP ID
field has no meaning. Hence the entire second word can be considered
fragmentation related.
I agree that it’s not a very robust mechanism; it breaks under extensive
packet reordering at high packet rates (circumstances which are probably
showing up in iperf tests against flow-isolating AQMs). It would be better
not to have fragmentation at the IP layer at all. But it’s not as bad as
you say; it does work for low packet rates, which is all it was intended
for.
Here’s my preferred reference diagram:
https://nmap.org/book/tcpip-ref.html
rfc-6864 shows that this field is not used the way you think it is in
practice (if it was, nobody would have been able to exceed 6.4Mbps)
Given all the things that can cause fragmentation on virtually every packet
(tunnels/vpns), and the fact that having this be unique would restrict all
traffice between a given source and destination to 6.4Mbps, I am extremely
doubtful that it is used the way that rfc-6864 suggests (after all it's a
recent RFC, 2013)
I know that I've looked at packet dumps that have shown fragmented data and
seen the port numbers in the fragment headers.
I'd bet that in practice firewalls/etc ignore the IP ID field.
from rfc-6864
Many current devices support fragmentation that ignores the IPv4
Don't Fragment (DF) bit. Such devices already transit traffic from
sources that reuse the ID. If fragments of different datagrams
reusing the same ID (within the source address/destination
address/protocol tuple) arrive at the destination interleaved,
fragmentation would fail and traffic would be dropped. Either such
interleaving is uncommon or traffic from such devices is not widely
traversing these DF-ignoring devices, because significant occurrence
of reassembly errors has not been reported. DF-ignoring devices do
not comply with existing standards, and it is not feasible to update
the standards to allow them as compliant.
They ignore the possibility that the OS reassembly is doing something different
than they are thinking.
David Lang
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
