Editing IPv4 (section)

===Header===
The IPv4 packet header consists of 14 fields, of which 13 are required. The 14th field is optional and aptly named: options. The fields in the header are packed with the most significant byte first ([[network byte order]]), and for the diagram and discussion, the most significant bits are considered to come first ([[MSB0|MSB 0 bit numbering]]). The most significant bit is numbered 0, so the version field is actually found in the four most significant bits of the first byte, for example.
{{APHD|start|title=IPv4 header format}}
{{APHD|0|bits1=4|bits2=4|bits3=6|bits4=2|bits5=16|field1=[[#Version|Version]]|value1=4|field2=[[#IHL|IHL]]|field3=[[#DSCP|DSCP]]|field4=[[#ECN|ECN]]|field5=[[#Total Length|Total Length]]}}
{{APHD|4|bits1=16|bits2=3|bits3=13|field1=[[#Identification|Identification]]|field2=[[#Flags|Flags]]|field3=[[#Fragment offset|Fragment Offset]]}}
{{APHD|8|bits1=8|bits2=8|bits3=16|field1=[[#TTL|Time to Live]]|field2=[[List of IP protocol numbers|Protocol]]|field3=[[#Header Checksum|Header Checksum]]}}
{{APHD|12|bits1=32|field1=[[#Source address|Source address]]}}
{{APHD|16|bits1=32|field1=[[#Destination address|Destination address]]}}
{{APHD|20|bits1=320|background1=linen|field1=([[#Options|Options]]) (if IHL > 5)}}
{{APHD|end}}

;{{APHD|def|name={{vanchor|Version}}|length=4 bits|text=The first header field in an IP [[packet (information technology)|packet]] is the ''Version'' field. For IPv4, this is always equal to {{Mono|4}}.}}
;{{APHD|def|name={{vanchor|Internet Header Length|IHL}}|short=IHL|length=4 bits|text=The IPv4 header is variable in size due to the optional 14th field (''Options''). The IHL field contains the size of the IPv4 header; it has 4 bits that specify the number of 32-bit words in the header. The minimum value for this field is 5,{{Ref RFC|791}} which indicates a length of 5 × 32 bits = 160 bits = 20 bytes. As a 4-bit field, the maximum value is 15; this means that the maximum size of the IPv4 header is 15 × 32 bits = 480 bits = 60 bytes.}}
;{{APHD|def|name=[[Differentiated Services Code Point]]|short={{vanchor|DSCP}}|length=6 bits|text=Originally defined as the [[type of service]] (ToS), this field specifies [[differentiated services]] (DiffServ).{{Ref RFC|2474}} Real-time data streaming makes use of the DSCP field. An example is [[Voice over IP]] (VoIP), which is used for interactive voice services.}}
;{{APHD|def|name=[[Explicit Congestion Notification]]|short={{vanchor|ECN}}|length=2 bits|text=This field allows end-to-end notification of [[network congestion]] without [[packet loss|dropping packets]].{{Ref RFC|3168}} ECN is an optional feature available when both endpoints support it and effective when also supported by the underlying network.}}
;{{APHD|def|name={{vanchor|Total Length}}|length=16 bits|text=This [[16-bit]] field defines the entire packet size in bytes, including header and data. The minimum size is 20 bytes (header without data) and the maximum is 65,535 bytes. All hosts are required to be able to reassemble datagrams of size up to 576 bytes, but most modern hosts handle much larger packets. Links may impose further restrictions on the packet size, in which case datagrams must be [[IP fragmentation|fragmented]]. Fragmentation in IPv4 is performed in either the sending host or in routers. Reassembly is performed at the receiving host.}}
;{{APHD|def|name={{vanchor|Identification}}|length=16 bits|text=This field is an identification field and is primarily used for uniquely identifying the group of fragments of a single IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet-tracing information to help trace datagrams with spoofed source addresses,<ref>{{cite journal|last=Savage|first=Stefan|title=Practical network support for IP traceback|journal=ACM SIGCOMM Computer Communication Review|year=2000|volume=30|issue=4|pages=295–306|doi=10.1145/347057.347560|doi-access=free}}</ref> but any such use is now prohibited.{{Ref RFC|6864}}}}
;{{APHD|def|name=Flags|length=3 bits|text=There are three flags defined within this field.}}
:;{{APHD|def|name=Reserved|short=R|length=1 bit|text=Reserved. Should be set to 0.{{efn|As an [[April Fools']] joke, proposed for use in RFC 3514 as the "[[Evil bit]]"{{Ref RFC|3514}}}}}}
:;{{APHD|def|name=Don't Fragment|short=DF|length=1 bit|text=This field specifies whether the datagram can be fragmented or not. This can be used when sending packets to a host that does not have resources to perform reassembly of fragments. It can also be used for [[path MTU discovery]], either automatically by the host IP software, or manually using diagnostic tools such as [[Ping (networking utility)|ping]] or [[traceroute]]. If the DF flag is set, and fragmentation is required to route the packet, then the packet is dropped.}}
:;{{APHD|def|name=More Fragments|short=MF|length=1 bit|text=For unfragmented packets, the MF flag is cleared. For fragmented packets, all fragments except the last have the MF flag set. The last fragment has a non-zero ''Fragment Offset'' field, so it can still be differentiated from an unfragmented packet.}}
;{{APHD|def|name={{vanchor|Fragment Offset}}|length=13 bits|text=This field specifies the offset of a particular fragment relative to the beginning of the original unfragmented IP datagram. Fragments are specified in units of 8 bytes, which is why fragment lengths are always a multiple of 8; except the last, which may be smaller.<ref>{{Cite web |last=Bhardwaj |first=Rashmi |date=2020-06-04 |title=Fragment Offset - IP With Ease |url=https://ipwithease.com/fragmentation-offset/ |access-date=2022-11-21 |website=ipwithease.com |language=en-US}}</ref>{{Break}}The fragmentation offset value for the first fragment is always 0. The field is 13 bits wide, so the offset value ranges from 0 to 8191 (from (2<sup>0</sup> – 1) to (2<sup>13</sup>&nbsp;– 1)).  Therefore, it allows a maximum fragment offset of  (2<sup>13</sup>&nbsp;– 1) × 8 = 65,528 bytes, with the header length included (65,528 + 20 = 65,548 bytes), supporting fragmentation of packets exceeding the maximum IP length of 65,535 bytes.}}
;{{APHD|def|name=Time to live|short={{vanchor|TTL}}|length=8 bits|text=The [[time to live]] field limits a datagram's lifetime to prevent network failure in the event of a [[routing loop]]. It is specified in seconds, but time intervals less than 1 second are rounded up to 1. In practice, the field is used as a [[hop count]]—when the datagram arrives at a [[router (computing)|router]], the router decrements the TTL field by one. When the TTL field hits zero, the router discards the packet and typically sends an [[ICMP time exceeded]] message to the sender.
:The program ''traceroute'' sends messages with adjusted TTL values and uses these ICMP time exceeded messages to identify the routers traversed by packets from the source to the destination.}}
;{{APHD|def|name={{vanchor|Protocol}}|length=8 bits|text=This field defines the [[transport layer]] protocol used in the data portion of the IP datagram. The [[list of IP protocol numbers]] is maintained by [[Internet Assigned Numbers Authority]] (IANA).{{Ref RFC|3232}}}}
:Some of the common payload protocols include:
:{|class=wikitable
|-
!Protocol Number!!Protocol Name!!Abbreviation
|-
|1||[[Internet Control Message Protocol]]||ICMP
|-
|2||[[Internet Group Management Protocol]]||IGMP
|-
|6||[[Transmission Control Protocol]]||TCP
|-
|17||[[User Datagram Protocol]]||UDP
|-
|41||[[IPv6#Tunneling|IPv6 encapsulation]]||ENCAP
|-
|89||[[Open Shortest Path First]]||OSPF
|-
|132||[[Stream Control Transmission Protocol]]||SCTP
|}
;{{APHD|def|name={{vanchor|Header Checksum}}|length=16 bits|text=The [[IPv4 header checksum]] field is used for error checking of the header. Before sending a packet, the checksum is computed as the 16-bit [[ones' complement]] of the ones' complement sum of all 16-bit words in the header. This includes the ''Header Checksum'' field itself, which is set to zero during computation. The packet is sent with ''Header Checksum'' containing the resulting value. When a packet arrives at a router or its destination, the network device recalculates the checksum value of the header, now including the ''Header Checksum'' field. The result should be zero; if a different result is obtained, the device discards the packet.
:When a packet arrives at a router, the router decreases the ''TTL'' field in the header. Consequently, the router must calculate a new header checksum before sending it out again.
:Errors in the data portion of the packet are handled separately by the encapsulated protocol. Both [[User Datagram Protocol|UDP]] and [[Transmission Control Protocol|TCP]] have separate checksums that apply to their data.}}
;{{APHD|def|name={{vanchor|Source address}}|length=32 bits|text=This field contains the [[IPv4 address]] of the sender of the packet. It may be changed in transit by [[network address translation]] (NAT).}}
;{{APHD|def|name={{vanchor|Destination address}}|length=32 bits|text=This field contains the [[IPv4 address]] of the intended receiver of the packet. It may also be affected by NAT.
:If the destination can be [[Broadcast domain|reached directly]] the packet will be delivered by the underlying [[link layer]], with the help of [[Address Resolution Protocol|ARP]]. If not, the packet needs [[routing]] and will be delivered to [[gateway address]] instead.}}
;{{APHD|def|name={{vanchor|Options}}|length=0 - 320 bits, padded to multiples of 32 bits|text=The ''Options'' field is not often used. Packets containing [[Internet Protocol Options Considerations|some options may be considered as dangerous]] by some routers and be blocked.<ref>{{cite web|url=http://www.faqs.org/faqs/cisco-networking-faq/section-23.html|title=Cisco unofficial FAQ|access-date=2012-05-10}}</ref> The value in the ''IHL'' field must include sufficient extra 32-bit words to hold all options and any padding needed to ensure that the header contains an integral number of 32-bit words. If ''IHL'' is greater than 5 (i.e., it is from 6 to 15) it means that the options field is present and must be considered. The list of options may be terminated with the option EOOL (End of Options List, 0x00); this is only necessary if the end of the options would not otherwise coincide with the end of the header. 
:Since most of the IP options include specifications on how many or which intermediate devices the packet should pass, the IP options are not used for communication over the Internet and IP packets including some of the IP options must be dropped,{{Ref RFC|6274|rsection=3.13}} since they can expose the network topology or network details.}}
{{Further|Internet Protocol Options}}