ipv4: use zero IPID for atomic datagrams on connected sockets

ip_select_ident_segs() uses the per-socket private generator
for connected sockets, even for packets with IP_DF set.

This was historically done to work around buggy Windows95/2000
VJ header compression implementations, dropping every other
packet in a TCP stream when the IP ID field did not change.

RFC 6864 section 4.2 states that "Originating sources MAY set the
IPv4 ID field of atomic datagrams to any value".

Packets with IP_DF set and skb->ignore_df cleared can not be
fragmented, neither locally (ip_fragment() refuses to do so)
nor by routers on the path.

Set their IPID to zero, like we already do for unconnected sockets
and in ip_build_and_send_pkt(). FreeBSD also does the same by
default (net.inet.ip.rfc6864 = 1).

For GSO packets, segments get IP IDs 0, 1, ..., n-1 from GSO/TSO.
This does not hurt GRO on receivers, because TCP already forces
a PSH flag on every TSO packet since commit 051ba67447de
("tcp: force a PSH flag on TSO packets"), so GRO already flushes
at TSO packet boundaries.

Connected sockets still use their private generator for packets
without IP_DF, or with skb->ignore_df set. Update the inet_id
kernel-doc accordingly.

This avoids an atomic operation on a shared cache line for
connected UDP sockets using IP_PMTUDISC_DO/IP_PMTUDISC_PROBE,
and TCP no longer touches inet->inet_id in the fast path.

Minor side effects: IP IDs can no longer be used to distinguish
network duplicates from TCP retransmits, or to correlate packet
captures taken at different points. OS fingerprints will also change.

Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20261001155633.2562504-1-edumazet@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

0 files changed, 0 insertions, 0 deletions