• Telecommunications Consulting

    Telecommunications Consulting

    Consulting Services from Network Design to Project Management Read More
  • Internetworking Training Experts

    Internetworking Training Experts

    Click on Training and then Courses. Read More
  • Wireshark Experts

    Wireshark Experts

    Packet analysis expertise is critical in today's networks, and being able to use the best packet analyzer application is a skill we can help you and your team attain. Read More
  • Are you a Network Scientist?

    Are you a Network Scientist?

    Online Learning, Instructor Led in person or Web-based delivery. Check out our online school. Read More
  • Online Certification Training

    Online Certification Training

    Find out about our Network Self Certification Program for Rural Service Providers here! Read More
  • IPv6 Experts

    IPv6 Experts

    Along with other Internet regions, ARIN is out of IPv4 Addresses. Are you IPv6 fluent? Are you IPv6 ready? Read More
  • Enabling the IoT with Wireless

    Enabling the IoT with Wireless

    Without wireless, we cannot have the Internet of Things. Read More
  • MPLS Book for iPad and iPhone

    MPLS Book for iPad and iPhone

    Get Mr. Walding's book here! Read More
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

Welcome to CellStream, Inc. - Telecom Consulting and Training!

Welcome to our home on the Internet, where we can not only share information, but also interact with each other. If you are a visitor to the site, there are a number of things to view: our FAQ'sNetworking and Computing Tips, our CellStream Blog, and other fun reading can all be found in the drop down menus above.  The Training menu provides access to our courses, our course calendar, and learning services.  The Consulting Menu provides information on our consulting services and a place to meet our consulting and teaching team.  Registered CellStream folks and our clients will log in using their private credentials to access projects, calendars and discussions.

Thanks for visiting! We always welcome comments and suggestions.

What exactly is the purpose of the IP ID field?  This is actually a great question.  While many have tried to answer the question in various articles on the Internet, I thought the question deserved a clear answer to the question.  RFC 6864 updated RFC’s 791, 1122, and 2003 to clarify the definition of the IPv4 ID field:

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. 

Here is a graphical representation of the IPv4 header:

Screen Shot 2016 03 28 at 1.30.21 PM

IP ID Field in Fragmentation

The first answer defining the IP ID field has to do with IP packet fragmentation.   RFC 6864 clarifies that the primary purpose of the ID Field is in support of fragmentation and reassembly.  In IPv4, datagram size is limited by the Total Length field with is 16 bits.  Thus 2^16 is 65535 bytes.  However, we know that Ethernet, for example, uses a maximum transmission unit size of 1500 bytes.  Usually the IP protocol stack will set the size of the IP packets to fit into their Ethernet interfaces.  However, what if that packet now goes into a tunnel interface (adding additional headers) or into an interface that has a less than 1500 byte MTU?  The answer is the original IP packet must be fragmented into two packets.  The first packet is a maximum size and the second is whatever is left over.  These two fragments travel the entire rest of their journey to the destination where they are reassembled.

But what if there were more than 2 fragments?  And how does the eventual receiver perform the reassembly accurately?  

The answer is to use the second 32 bit word of the IPv4 header:

Screen Shot 2016 03 28 at 1.41.35 PM

The M bit as shown is the More Fragments Flag.

The D bit as shown is the Do not Fragment Flag.

The result of the fragmentation process is shown below:

Screen Shot 2016 03 28 at 1.45.26 PM

On the left we see a “normal” 1500 byte IP packet (20 bytes of IPv4 header plus 1480 bytes of payload.  If that packet has to enter either a tunnel or an interface with a smaller MTU (the example shows  1300 bytes), 2 fragments are created.  The first fragment is 1300 bytes with a 20 byte IPv4 header plus a 1280 byte payload.  Also, we see an ID of 1000 being placed into the IP ID Field, followed by the ‘more’ flag being set, followed by the offset of 0 bytes (really meaning this is the first packet of the fragmented packets).

The left over 200 bytes of the original IPv4 packet now are carried in the second fragment.  The second fragment shares the same IP ID field: 1000.  The receiver of the fragments knows that this fragment and the prior fragment below together.  Note also the more flag is set to 0, meaning no more fragments.  The offset is set to 160 - this means that its payload is offset by 160 x 8 (or 1280)  bytes from the prior fragment.  Therefore, if you received this packet you would know this fragment belonged to the prior fragment, and be able to unpack the payloads and reassemble them in the right order.  Even if these packets were received out of order, you would be able to perform reassembly.

We can also mark IPv4 packets with the Do Not fragment flag.  If this bit is set to 1, then nodes in the path that encounter the need to fragment, the packet can be discarded.

What about IPv6?

Well, IPv6 requires something called Path MTU Discovery, to minimize fragmentation (if not eliminate it completely).  Simply stated, this means that sending hosts must adjust packet sizes to fit in the smallest MTU on a given path to a destination.  They ‘discover’ the size thanks to the ICMP error message system.

Also, IPv6 no longer has fragmentation support in the standard header!  Instead, there is an extension header that contains the fragmentation information:

Screen Shot 2016 03 28 at 2.07.55 PM

You can see that the main difference is the size of the IP ID field!  Other than that, it works the same way.

Other Uses for the IP ID field

There have been a number of other IP ID implementations other than fragmentation and reassembly.  Per RFC 6864:

  • The field has been proposed as a way to detect and remove duplicate datagrams, e.g., at congested routers (noted in Section of [RFC1122]) or in network accelerators. 

  • It has similarly been proposed for use at end hosts to reduce the impact of duplication on higher-layer protocols (e.g., additional processing in TCP or the need for application-layer duplicate suppression in UDP).  

  • The IPv4 ID field is used in some diagnostic tools to correlate datagrams measured at various locations along a network path.  This is already insufficient in IPv6 because unfragmented datagrams lack an ID, so these tools are already being updated to avoid such reliance on the ID field.
However, all of these methods have been deprecated in RFC 6864 and essentially are no longer allowed.
Therefore there are two types of IP packets we will see on networks that comply with RFC 6864:
  • Atomic datagrams: these are datagrams not yet fragmented and for which must not be fragmented.  (DF==1)&&(MF==0)&&(frag_offset==0).
  • Non-atomic datagrams: these are datagrams either that already have been fragmented or for which fragmentation remains possible.  (DF==0)||(MF==1)||(frag_offset>=0)
We hope this helps clarify the purpose of the IP ID Field. 

Comments powered by CComment

Our Latest Content

  • Packet Capture in Windows using pktmon.exe

    Microsoft has added a packet sniffing/packet capture tool in the latest Windows 10 update.  We have previously discussed using the

    Read More
  • CBRS Certified Professional Installer (CPI) Services

    CellStream is proud to announce, and congratulates, Mr. Andrew Walding on attaining his CBRS Certified Professional Installer certification from Google! 

    Read More
  • CBRS - the new way to allocate Wireless Spectrum

    If you haven't heard by now, there is a new and innovative way to allocate wireless spectrum.  It is called

    Read More
  • Capturing Wi-Fi WLAN Packets in Wireshark on MAC OSx

    Ok all you MAC users, here is the way you capture Wi-Fi/WLAN frames using your MAC and Wireshark. First, MAC

    Read More
  • Windows 10 WLAN/Wi-Fi Commands of Interest

    There are several other articles that we have written on various Windows 10 WLAN/Wi-Fi commands that you can execute to

    Read More
  • 1
  • 2
  • 3
  • 4

Our Most Popular Articles

  • What is the 'arp' command, and how can I use it?

    Let's answer the question.  If you want more details than what we have provided below, check out our chapter on

    Read More
  • Neighbor Discovery (ND) Table in IPv6 Windows, Linux and MAC Machines

    A great question I was asked in class was: "If Neighbor Discovery processes have replaced ARP in ICMPv6, how do

    Read More
  • IPv6 Windows Command Line Examples

    Here are some great Windows command line entries you can make to examine and configure IPv6 (assuming your version of

    Read More
  • T-Shark Usage Examples

    As many of you know, T-Shark is the command line version of Wireshark.  For T-Shark beginners, look first here. For

    Read More
  • Capturing Wi-Fi WLAN Packets on Windows for Free!

    As many of my clients and students know, I have agreat solution for those who want to capture WLAN control

    Read More
  • 1
  • 2
  • 3
  • 4

The nicest thing you can do is use these inks to support us!  Thank you!

Course Mini Calendar

May   2020
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Please use this link:

Find by Tag

4G Networks 5G Networks 6in4 6LoWLAN 6LoWPAN 802.11 802.11ah 802.11ax 802.11ay 802.11az Addressing Analysis Ansible Architecture ARP AToM BGP Bloom's Taxonomy Broadband Cable cat CBRS CellStream Cellular Central Office Cheat Sheet Chrome Cisco Cloud Coloring Rules Computer Consulting CPI Customer Support Data Center Data Networking DHCPv6 DNS Docker Documentation Dublin-Traceroute dumpcap ECMP Ethernet Ethics Field Operations Fragmentation G-MPLS Git GNS3 Google GQUIC Hands-On History Home Network ICMP ICMPv6 IEEE 802.11p IEEE 802.15.4 Interface Control Internet IoT IPsec IPv4 IPv6 IS-IS L2VPN L3VPN LDP Linux LLN LoL M-BGP MAC MAC OSx Macro Microsoft mininet Monitoring MPLS MTU Multicast Name Resolution Netcat Netmiko NetMon netsh Networking Network Science nmap Npcap NSE Online School OpenFlow OSPF OSPFv2 OSPFv3 OSX OTT Paris-Traceroute Parrot PIM pktmon PMTU Policy POTS POTS to Pipes PPP Profile Programming Project Management Protocol 41 PW3E Python QoS QUIC Remote Desktop Requirements Resume RIP Routing RPL RSVP Rural SAS SDN Security Service Provider Small Business SONET Speed SS7 SSH SSL Subnetting SYSCTL T-Shark TCP TCP/IP Telco Telecom 101 Telecommunications Telephone termshark TLS Tools Traceroute Traffic Engineering Training Travel Tunnel Ubuntu Utility Video Virtualbox Virtualization VoIP VRF VXLAN WEP Wi-Fi Wi-Fi 4 Wi-Fi 5 Wi-Fi 6 Wi-Fi 6/6E Windows Winpcap Wireless Wireless 5G Wireshark Wireshark Tip WLAN WPA2 Zenmap ZigBee

Support us by clicking:

Subscribe to our Newsletter!

Subscribe to our newsletter to learn about upcoming classes, new networking how to's and much more.

Twitter Feed