3

Identification field is of 16 bits in Ipv4 header. This means we can have $2^16$ unique datagrams from a single host at a time. Also each datagram can have a total length of $2^16$ bytes.

So can the sender send only $2^32$ or 4GB of data at a time ? If he sends more data, will the identification number wrap around ?

Improve this question
1
  • 1
    Most routers today are configured to drop IP fragments to prevent attacks, so fragmentation really isn't much used anymore. Routers are required to fragment IPv4 packets that are too large for the next interface, unless the DF bit is set, but they are not required to forward fragments, and administrators commonly configure routers to drop packet fragments. Routers do not fragment IPv6 packets, which is expressly forbidden by the IPv6 standard.
    – Ron Maupin ♦
    Dec 20, 2017 at 16:28

1 Answer 1

Reset to default
9

the rfc6864 - Updated Specification of the IPv4 ID Field precisely address this issue.

Extract from this rfc:

  1. Introduction

In IPv4, the Identification (ID) field is a 16-bit value that is
unique for every datagram for a given source address, destination
address, and protocol, such that it does not repeat within the
maximum datagram lifetime (MDL) [RFC791] [RFC1122]. As currently
specified, all datagrams between a source and destination of a given
protocol must have unique IPv4 ID values over a period of this MDL,
which is typically interpreted as two minutes and is related to the
recommended reassembly timeout [RFC1122]. This uniqueness is
currently specified as for all datagrams, regardless of fragmentation settings.

Uniqueness of the IPv4 ID is commonly violated by high-speed devices; if strictly enforced, it would limit the speed of a single protocol between two IP endpoints to 6.4 Mbps for typical MTUs of 1500 bytes (assuming a 2-minute MDL, using the analysis presented in [RFC4963]). It is common for a single connection to operate far in excess of these rates, which strongly indicates that the uniqueness of the IPv4 ID as specified is already moot. Further, some sources have been generating non-varying IPv4 IDs for many years (e.g., cellphones), which resulted in support for such in RObust Header Compression (ROHC) [RFC5225].

and

4.1. IPv4 ID Used Only for Fragmentation

Although RFC 1122 suggests that the IPv4 ID field has other uses,
including datagram de-duplication, such uses are already not
interoperable with known implementations of sources that do not vary
their ID. This document thus defines this field's value only for
fragmentation and reassembly:

>> The IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly.

Datagram de-duplication can still be accomplished using hash-based duplicate detection for cases where the ID field is absent (IPv6 unfragmented datagrams), which can also be applied to IPv4 atomic datagrams without utilizing the ID field [RFC6621].

(emphasis mine)

Improve this answer
4
  • In second part, it is written ID field should be used only for fragmentation. As in Ipv4, host can optionally fragment, what if I send 5GB data and fragment every datagram ? Even in this case there will be a problem right?
    – Zephyr
    Dec 20, 2017 at 9:58
  • I just now read that in ipv6 the fragment header has an identification number of 32 bits with a wrap around counter for each node/source address. It seems that ipv6 solved this problem.
    – Zephyr
    Dec 20, 2017 at 10:09
  • If you send lots of fragmented (or fragmentable data that later gets fragmented) data and the network reorders your fragments then you run the risk of incorrect reassembly. rfc6864 tells vendors to avoid this by rate-limiting fragmentable data but whether vendors take any notice of this I do not know.
    – Peter Green
    Dec 20, 2017 at 10:55
  • Nowadays most packets are non-fragmentable (thanks to path MTU discovery) and most networks try very hard to avoid re-ordering packets. So this isn't too much of an issue in practice.
    – Peter Green
    Dec 20, 2017 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.