Address Resolution Protocol

The Address Resolution Protocol (ARP) is a computer networking protocol for determining a network host's
Link Layer or hardware address when only its Internet Layer (IP) or Network Layer address is known. This
function is critical in local area networking as well as for routing internetworking traffic across gateways
(routers) based on IP addresses when the next-hop router must be determined.

Consider a LAN where machines using IPv4 over Ethernet wish to communicate. A sender wishes to send a
message to some other machine on the LAN and knows a destination IPv4 address. The destination IPv4
address is hopefully associated with some appropriate network interface belonging to the recipient machine,
and is present on the LAN. But in order for communication to succeed, the sending machine first needs to
discover the ethernet MAC address of the intended recipient network interface. This requirement comes
about because Ethernet hardware does not (necessarily) understand IPv4 protocols or IPv4 addresses in the
sense that Ethernet hardware 'listens out for' relevant Ethernet MAC addresses but does not 'listen out for'
IPv4 addresses. (An impractical alternative would be to have all units listen to every Ethernet packet and
inspect the contents for relevant IPv4 addresses, discarding the packets that are intended for other devices,
but this would be very inefficient.) So before sending an IPv4 packet, the sender sends a broadcast message
onto the LAN using ARP in order to discover the Ethernet MAC address of some interface that is listening
for that desired target IPv4 address. Some appropriate unit replies that it has a network interface with a
certain MAC address that is associated with the IPv4 address in question. The original would-be sender now
has the information needed and can go ahead and send its IPv4 packet to the destination inserting it into an
Ethernet frame with the correct destination MAC address for the appropriate recipient. The sender's
operating system also stores the newly discovered MAC address in a table ('caches' the result). This table of
mappings from IPv4 addresses to MAC addresses is retained and consulted again and again, so the ARP
discovery procedure only has to be performed one time, when a packet is sent to a 'new' destination IPv4
address. When a host goes down on a network, there is no message sent to inform the other hosts. They will
continue to send messages to that MAC address and because Ethernet doesn't have guaranteed delivery, they
will have no way of knowing that the address associated with that host is no longer correct. A timer is set
when information is entered in to the ARP cache and it will be discarded when the time is up to prevent the
storing of invalid information. A new ARP request will be sent to the stored MAC address to verify that it is
in fact still connected.

Packet structure

The Address Resolution Protocol uses a simple message format that contains one address resolution
request or response. The size of the ARP message depends on the upper layer and lower layer address sizes,
which are given by the type of networking protocol (usually IPv4) in use and the type of hardware or virtual
link layer that the upper layer protocol is running on. The message header specifies these types, as well as
the size of addresses of each. The message header is completed with the operation code for request (1) and
reply (2). The payload of the packet consists of four addresses, the hardware and protocol address of the
sender and receiver hosts.

The principal packet structure of ARP packets is shown in the following table which illustrates the case of
IPv4 networks running on Ethernet. In this scenario, the packet has 48-bit fields for the sender hardware
address (SHA) and target hardware address (THA), and 32-bit fields for the corresponding sender and target
protocol addresses (SPA and TPA). Thus, the ARP packet size in this case is 28 bytes.

Hardware type (HTYPE)

This field specifies the Link Layer protocol type. Example: Ethernet is 1.

Protocol type (PTYPE)

This field specifies the upper layer protocol for which the ARP request is intended. For IPv4, this has
the value 0x0800. The permitted PTYPE values share a numbering space with those for Ethertype
Hardware length (HLEN)
Length (in octets) of a hardware address. Ethernet addresses size is 6.
Protocol length (PLEN)
Length (in octets) of addresses used in the upper layer protocol. (The upper layer protocol specified
in PTYPE.) IPv4 address size is 4.
Operation
Specifies the operation that the sender is performing: 1 for request, 2 for reply.
Sender hardware address (SHA)
Hardware (MAC) address of the sender.
Sender protocol address (SPA)
Upper layer protocol address of the sender.
Target hardware address (THA)
Hardware address of the intended receiver. This field is ignored in requests.
Target protocol address (TPA)
Upper layer protocol address of the intended receiver.

ARP protocol parameter values have been standardized and are maintained by IANA

(The Internet Assigned Numbers Authority (IANA) is the entity that oversees global IP address
allocation, autonomous system number allocation, root zone management in the Domain Name System
(DNS), media types, and other Internet Protocol-related symbols and numbers. IANA is operated by the
Internet Corporation for Assigned Names and Numbers, also known as ICANN.)
ARP probe
An ARP probe is an ARP request constructed with an all-zero sender IP address. The term is used in the
IPv4 Address Conflict Detection specification . Before beginning to use an IPv4 address (whether received
from manual configuration, DHCP, or some other means), a host implementing this specification must test
to see if the address is already in use, by broadcasting ARP probe packets.

ARP announcements
ARP may also be used as a simple announcement protocol. This is useful for updating other hosts' mapping
of a hardware address when the sender's IP address or MAC address has changed. Such an announcement,
also called a gratuitous ARP message, is usually broadcast as an ARP request containing the sender's
protocol address (SPA) in the target field (TPA=SPA), with the target hardware address (THA) set to zero.
An alternative is to broadcast an ARP reply with the sender's hardware and protocol addresses (SHA and
SPA) duplicated in the target fields (TPA=SPA, THA=SHA).

ARP mediation
ARP mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are
used on multiple connected circuits, e.g., ATM on one end and Ethernet on the others.
Inverse ARP and Reverse ARP
Inverse Address Resolution Protocol (Inverse ARP or InARP) is used to obtain Network
Layer addresses (for example, IP addresses) of other nodes from Data Link Layer (Layer 2) addresses. It is
primarily used in Frame Relay (DLCI) and ATM networks, in which Layer 2 addresses of virtual circuits are
sometimes obtained from Layer 2 signaling, and the corresponding Layer 3 addresses must be available
before those virtual circuits can be used.

Since ARP translates Layer 3 addresses to Layer 2 addresses, InARP may be described as its inverse. In
addition, InARP is implemented as a protocol extension to ARP: it uses the same packet format as ARP, but
different operation codes

Reverse Address Resolution Protocol (Reverse ARP or RARP), like InARP, translates Layer
2 addresses to Layer 3 addresses. However, in InARP the requesting station queries the Layer 3 address of
another node, whereas RARP is used to obtain the Layer 3 address of the requesting station itself for address
configuration purposes. RARP is obsolete; it was replaced by BOOTP, which was later superseded by the
Dynamic Host Configuration Protocol (DHCP).

Fig . Reverse
Address Resolution Protocol
RARP (Reverse Address Resolution Protocol) is a protocol by which a physical machine in a local area
network can request to learn its IP address from a gateway server's Address Resolution Protocol (ARP) table
or cache. A network administrator creates a table in a local area network's gateway router that maps the
physical machine (or Media Access Control - MAC address) addresses to corresponding Internet Protocol
addresses. When a new machine is set up, its RARP client program requests from the RARP server on the
router to be sent its IP address. Assuming that an entry has been set up in the router table, the RARP server
will return the IP address to the machine which can store it for future use.

RARP is a separate protocol at the data-link level. For example, if the medium used is Ethernet, then RARP
packets will have an Ethertype (still to be assigned) different from that of ARP. This recognizes that ARP
and RARP are two fundamentally different operations, not supported equally by all hosts. The impact on
existing systems is minimized; existing ARP servers will not be confused by RARP packets. It makes RARP
a general facility that can be used for mapping hardware addresses to any higher level protocol address.

This approach provides the simplest implementation for RARP client hosts, but also provides the most
difficulties for RARP server hosts. However, these difficulties should not be insurmountable.
RARP is available for Ethernet, Fiber Distributed-Data Interface, and Token Ring LANs. ARP (Address
Resolution Protocol) performs the opposite function as the RARP: mapping of an IP address to a physical
machine address.

8 16 32 bit
Hardware type Protocol type
HLen Plen Operation

Sender Hardware Address

Sender Protocol Address

Target Hardware Address

Target Protocol Address

Fig. Header structure RARP

Hardware type

Type Description
1 Ethernet.
2 Experimental Ethernet.
3 Amateur Radio AX.25.
4 Proteon ProNET Token Ring.
5 Chaos.
6 IEEE 802.
7 ARCNET.
8 Hyperchannel.
9 Lanstar.
10 Autonet Short Address.
11 LocalTalk.
12 LocalNet (IBM PCNet or SYTEK LocalNET).
13 Ultra link.
14 SMDS.
15 Frame Relay.
16 ATM, Asynchronous Transmission Mode.
17 HDLC.
18 Fibre Channel.
19 ATM, Asynchronous Transmission Mode.
20 Serial Line.
21 ATM, Asynchronous Transmission Mode.
22 MIL-STD-188-220.
23 Metricom.
24 IEEE 1394.1995.
25 MAPOS.
26 Twinaxial.
27 EUI-64.
28 HIPARP.

Protocol type
Protocol Description
0x800 IP.
 Hardware address length
Length of the hardware address in bytes.

 Protocol address length

Length of the protocol address in bytes.

 Operation
The values are as follows:

Opcode Description
1 ARP request
2 ARP response
3 RARP request.
4 RARP response
5 Dynamic RARP request
6 Dynamic RARP reply
7 Dynamic RARP error
8 InARP request
9 InARP reply

Internet Protocol
The Internet Protocol (IP) is the principal communications protocol used for relaying datagrams (packets)
across an internetwork using the Internet Protocol Suite. Responsible for routing packets across network
boundaries, it is the primary protocol that establishes the Internet.

IP is the primary protocol in the Internet Layer of the Internet Protocol Suite and has the task of delivering
datagrams from the source host to the destination host solely based on their addresses. For this purpose, IP
defines addressing methods and structures for datagram encapsulation.

Historically, IP was the connectionless datagram service in the original Transmission Control Program
introduced by Vint Cerf and Bob Kahn in 1974, the other being the connection-oriented Transmission
Control Protocol (TCP). The Internet Protocol Suite is therefore often referred to as TCP/IP.

The first major version of IP, now referred to as Internet Protocol Version 4 (IPv4) is the dominant protocol
of the Internet, although the successor, Internet Protocol Version 6 (IPv6) is in active, growing deployment
worldwide.

Services provided by IP

The Internet Protocol is responsible for addressing hosts and routing datagrams (packets) from a source host
to the destination host across one or more IP networks. For this purpose the Internet Protocol defines an
addressing system that has two functions. Addresses identify hosts and provide a logical location service.
Each packet is tagged with a header that contains the meta-data for the purpose of delivery. This process of
tagging is also called encapsulation.

IP is a connectionless protocol and does not need circuit setup prior to transmission
Reliability

The design principles of the Internet protocols assume that the network infrastructure is inherently unreliable
at any single network element or transmission medium and that it is dynamic in terms of availability of links
and nodes. No central monitoring or performance measurement facility exists that tracks or maintains the
state of the network. For the benefit of reducing network complexity, the intelligence in the network is
purposely mostly located in the end nodes of each data transmission, cf. end-to-end principle. Routers in the
transmission path simply forward packets to the next known local gateway matching the routing prefix for
the destination address.

As a consequence of this design, the Internet Protocol only provides best effort delivery and its service can
also be characterized as unreliable. In network architectural language it is a connection-less protocol, in
contrast to so-called connection-oriented modes of transmission. The lack of reliability allows any of the
following fault events to occur:

• data corruption
• lost data packets
• duplicate arrival
• out-of-order packet delivery; meaning, if packet 'A' is sent before packet 'B', packet 'B' may arrive
before packet 'A'. Since routing is dynamic and there is no memory in the network about the path of
prior packets, it is possible that the first packet sent takes a longer path to its destination.

The only assistance that the Internet Protocol provides in Version 4 (IPv4) is to ensure that the IP packet
header is error-free through computation of a checksum at the routing nodes. This has the side-effect of
discarding packets with bad headers on the spot. In this case no notification is required to be sent to either
end node, although a facility exists in the Internet Control Message Protocol (ICMP) to do so.

IPv6, on the other hand, has abandoned the use of IP header checksums for the benefit of rapid forwarding
through routing elements in the network.

The resolution or correction of any of these reliability issues is the responsibility of an upper layer protocol.
For example, to ensure in-order delivery the upper layer may have to cache data until it can be passed to the
application.

In addition to issues of reliability, this dynamic nature and the diversity of the Internet and its components
provide no guarantee that any particular path is actually capable of, or suitable for, performing the data
transmission requested, even if the path is available and reliable. One of the technical constraints is the size
of data packets allowed on a given link. An application must assure that it uses proper transmission
characteristics. Some of this responsibility lies also in the upper layer protocols between application and IP.
Facilities exist to examine the maximum transmission unit (MTU) size of the local link, as well as for the
entire projected path to the destination when using IPv6. The IPv4 internetworking layer has the capability
to automatically fragment the original datagram into smaller units for transmission. In this case, IP does
provide re-ordering of fragments delivered out-of-order.[1]

Transmission Control Protocol (TCP) is an example of a protocol that will adjust its segment size to be
smaller than the MTU. User Datagram Protocol (UDP) and Internet Control Message Protocol (ICMP)
disregard MTU size thereby forcing IP to fragment oversized datagrams
IP addressing and routing

Perhaps the most complex aspects of IP are IP addressing and routing. Addressing refers to how end hosts
become assigned IP addresses and how subnetworks of IP host addresses are divided and grouped together.
IP routing is performed by all hosts, but most importantly by internetwork routers, which typically use either
interior gateway protocols (IGPs) or external gateway protocols (EGPs) to help make IP datagram
forwarding decisions across IP connected networks.

Version history

In May 1974, the Institute of Electrical and Electronic Engineers (IEEE) published a paper entitled "A
Protocol for Packet Network Interconnection."[3] The paper's authors, Vint Cerf and Bob Kahn, described an
internetworking protocol for sharing resources using packet-switching among the nodes. A central control
component of this model was the "Transmission Control Program" (TCP) that incorporated both connection-
oriented links and datagram services between hosts. The monolithic Transmission Control Program was later
divided into a modular architecture consisting of the Transmission Control Protocol at the connection-
oriented layer and the Internet Protocol at the internetworking (datagram) layer. The model became known
informally as TCP/IP, although formally it was henceforth referenced as the Internet Protocol Suite.

The Internet Protocol is one of the determining elements that define the Internet. The dominant
internetworking protocol in the Internet Layer in use today is IPv4; with number 4 assigned as the formal
protocol version number carried in every IP datagram. IPv4 is described in RFC 791 (1981).

The successor to IPv4 is IPv6. Its most prominent modification from version 4 is the addressing system.
IPv4 uses 32-bit addresses (c. 4 billion, or 4.3×109
, addresses) while IPv6 uses 128-bit addresses (c. 340 undecillion, or 3.4×1038
addresses). Although adoption of IPv6 has been slow, as of June 2008, all United States government systems
have demonstrated basic infrastructure support for IPv6 (if only at the backbone level).[4]

Version numbers 0 through 3 were development versions of IPv4 used between 1977 and 1979.[citation needed]
Version number 5 was used by the Internet Stream Protocol, an experimental streaming protocol. Version
numbers 6 through 9 were proposed for various protocol models designed to replace IPv4: SIPP (Simple
Internet Protocol Plus, known now as IPv6), TP/IX (RFC 1475), PIP (RFC 1621) and TUBA (TCP and UDP
with Bigger Addresses, RFC 1347). Version number 6 was eventually chosen as the official assignment for
the successor Internet protocol, subsequently standardized as IPv6.

A humorous Request for Comments that made an IPv9 protocol center of its storyline was published on
April 1, 1994 by the IETF.[5] It was intended as an April Fool's Day joke. Other protocol proposals named
"IPv9" and "IPv8" have also briefly surfaced, though these came with little or no support from the wider
industry and academia.

Fig. Internet Protocol Suite in operation between two hosts connected via two routers and the corresponding
layers used at each hop

Sample encapsulation of application data from UDP to a Link protocol frame

IPv4
Internet Protocol version 4 (IPv4) is the fourth revision in the development of the Internet Protocol (IP)
and it is the first version of the protocol to be widely deployed. Together with IPv6, it is at the core of
standards-based internetworking methods of the Internet. IPv4 is still by far the most widely deployed
Internet Layer protocol. As of 2011, IPv6 deployment is still in its infancy.

IPv4 is described in IETF publication RFC 791 (September 1981), replacing an earlier definition (RFC 760,
January 1980).

IPv4 is a connectionless protocol for use on packet-switched Link Layer networks (e.g., Ethernet). It
operates on a best effort delivery model, in that it does not guarantee delivery, nor does it assure proper
sequencing or avoidance of duplicate delivery. These aspects, including data integrity, are addressed by an
upper layer transport protocol (e.g., Transmission Control Protocol).

IPv4 Header

Fig . IPv4 header

An IP packet consists of a header section and a data section.

Header

The IPv4 packet header consists of 14 fields, of which 13 are required. The 14th field is optional (red
background in table) and aptly named: options. The fields in the header are packed with the most significant
byte first (big endian), and for the diagram and discussion, the most significant bits are considered to come
first (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

Version
The first header field in an IP packet is the four-bit version field. For IPv4, this has a value of 4
(hence the name IPv4).
Internet Header Length (IHL)
The second field (4 bits) is the Internet Header Length (IHL) telling the number of 32-bit words in
the header. Since an IPv4 header may contain a variable number of options, this field specifies the
size of the header (this also coincides with the offset to the data). The minimum value for this field is
 5 (RFC 791), which is a length of 5×32 = 160 bits = 20 bytes. Being a 4-bit value, the maximum
length is 15 words (15×32 bits) or 480 bits = 60 bytes.
Differentiated Services Code Point (DSCP)
Originally defined as the Type of Service field, this field is now defined by RFC 2474 for
Differentiated services (DiffServ). New technologies are emerging that require real-time data
streaming and therefore will make use of the DSCP field. An example is Voice over IP (VoIP) that is
used for interactive data voice exchange.
Explicit Congestion Notification (ECN)
Defined in RFC 3168 and allows end-to-end notification of network congestion without dropping
packets. ECN is an optional feature that is only used when both endpoints support it and are willing
to use it. It is only effective when supported by the underlying network.
Total Length
This 16-bit field defines the entire datagram size, including header and data, in bytes. The minimum-
length datagram is 20 bytes (20-byte header + 0 bytes data) and the maximum is 65,535 — the
maximum value of a 16-bit word. The minimum size datagram that any host is required to be able to
handle is 576 bytes, but most modern hosts handle much larger packets. Sometimes subnetworks
impose further restrictions on the size, in which case datagrams must be fragmented. Fragmentation
is handled in either the host or packet switch in IPv4 (see Fragmentation and reassembly).
Identification
This field is an identification field and is primarily used for uniquely identifying fragments of an
original IP datagram. Some experimental work has suggested using the ID field for other purposes,
such as for adding packet-tracing information to datagrams in order to help trace back datagrams
with spoofed source addresses.[5]
Flags
A three-bit field follows and is used to control or identify fragments. They are (in order, from high
order to low order):

• bit 0: Reserved; must be zero.[note 1]

• bit 1: Don't Fragment (DF)
• bit 2: More Fragments (MF)

If the DF flag is set and fragmentation is required to route the packet then the packet will be dropped.
This can be used when sending packets to a host that does not have sufficient resources to handle
fragmentation.
When a packet is fragmented all fragments have the MF flag set except the last fragment, which does
not have the MF flag set. The MF flag is also not set on packets that are not fragmented — an
unfragmented packet is its own last fragment.
Fragment Offset
The fragment offset field, measured in units of eight-byte blocks, is 13 bits long and specifies the
offset of a particular fragment relative to the beginning of the original unfragmented IP datagram.
The first fragment has an offset of zero. This allows a maximum offset of (213 – 1) × 8 = 65,528
bytes which would exceed the maximum IP packet length of 65,535 bytes with the header length
included (65,528 + 20 = 65,548 bytes).
Time To Live (TTL)
An eight-bit time to live field helps prevent datagrams from persisting (e.g. going in circles) on an
internet. This field limits a datagram's lifetime. It is specified in seconds, but time intervals less than
1 second are rounded up to 1. In latencies typical in practice, it has come to be a hop count field.
Each router that a datagram crosses decrements the TTL field by one. When the TTL field hits zero,
the packet is no longer forwarded by a packet switch and is discarded. Typically, an ICMP message
(specifically the time exceeded) is sent back to the sender that it has been discarded. The reception of
these ICMP messages is at the heart of how traceroute works.
Protocol
This field defines the protocol used in the data portion of the IP datagram. The Internet Assigned
Numbers Authority maintains a list of IP protocol numbers which was originally defined in RFC
790.
Header Checksum
The 16-bit checksum field is used for error-checking of the header. At each hop, the checksum of the
header must be compared to the value of this field. If a header checksum is found to be mismatched,
then the packet is discarded. Note that errors in the data field are up to the encapsulated protocol to
handle — indeed, both UDP and TCP have checksum fields.
Since the TTL field is decremented on each hop and fragmentation is possible at each hop then at
each hop the checksum will have to be recomputed. The method used to compute the checksum is
defined within RFC 1071:
The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in
the header. For purposes of computing the checksum, the value of the checksum field is zero.
In other words, all 16-bit words are summed together using one's complement (with the checksum
field set to zero). The sum is then one's complemented and this final value is inserted as the
checksum field.
For example, use Hex 45000030442240008006442e8c7c19acae241e2b (20 bytes IP header):
4500 + 0030 + 4422 + 4000 + 8006 + 0000 + 8c7c + 19ac + ae24 + 1e2b = 2BBCF
2 + BBCF = BBD1 = 1011101111010001, the 1'S of sum = 0100010000101110 = 442E
To validate a header's checksum the same algorithm may be used - the checksum of the header with
the checksum field filled in should be a word containing all zeros (value 0).
Source address
An IPv4 address is a group of four octets for a total of 32 bits. The value for this field is determined
by taking the binary value of each octet and concatenating them together to make a single 32-bit
value.
For example, the address 10.9.8.7 would be 00001010000010010000100000000111.
This address is the address of the sender of the packet. Note that this address may not be the "true"
sender of the packet due to network address translation. Instead, the source address will be translated
by the NATing machine to its own address. Thus, reply packets sent by the receiver are routed to the
NATing machine, which translates the destination address to the original sender's address.
Destination address
Identical to the source address field but indicates the receiver of the packet.
Options
Additional header fields may follow the destination address field, but these are not often used. Note
that the value in the IHL field must include enough extra 32-bit words to hold all the options (plus
any padding needed to ensure that the header contains an integral number of 32-bit words). The list
of options may be terminated with an EOL (End of Options List, 0x00) option; this is only necessary
if the end of the options would not otherwise coincide with the end of the header

• Note: If the Header Length is greater than 5, i.e. it is between 6-15, it means that the Options field is
present and must be considered.
 • Note: the Copied, Option Class, and Option Number are sometimes referred to as a single eight-bit
field - the Option Type.

The use of the LSRR and SSRR options (Loose and Strict Source and Record Route) is discouraged
because they create security concerns; many routers block packets containing these options

Data

The data field is not a part of the header and, consequently, is not included in the checksum field. The
format of the data field is specified in the protocol header field and can be any one of the transport layer
protocols.

Some of the common protocols are listed below including their value used in the protocol field

Fragmentation and reassembly

The Internet Protocol is the facility in the Internet architecture that enables different networks to exchange
traffic and route traffic across one another. The design accommodates networks of diverse physical nature; it
is independent of the underlying transmission technology used in the Link Layer. Link Layer networks of
different hardware design usually vary not only in transmission speed, but also in the structure and size of
valid framing methods, characterized by the maximum transmission unit (MTU) parameter. To fulfill the
role of IP to traverse networks, it was necessary to implement a mechanism to automatically adjust the size
of transmission units to adapt to the underlying technology. This introduced the need for fragmentation of IP
datagrams. In IPv4, this function was placed at the Internet Layer, and is performed in IPv4 routers, which
thus only require this layer as highest one implemented in their design.

In contrast, the next generation of the Internet Protocol, namely IPv6, does not require routers to perform
fragmentation; instead, hosts must determine the path maximum transmission unit in advance of
transmission and send conforming datagrams.
Fragmentation

When a device receives an IP packet it examines the destination address and determines the outgoing
interface to use. This interface has an associated MTU that dictates the maximum data size for its payload. If
the data size is bigger than the MTU then the device must fragment the data.

The device then segments the data into segments where each segment is less-than-or-equal-to the MTU less
the IP header size (20 bytes minimum; 60 bytes maximum). Each segment is then put into its own IP packet
with the following changes:

• The total length field is adjusted to the segment size

• The more fragments (MF) flag is set for all segments except the last one, which is set to 0
• The fragment offset field is set accordingly based on the offset of the segment in the original data
payload. This is measured in units of eight-byte blocks.
• The header checksum field is recomputed.

For example, for an IP header of length 20 bytes and an Ethernet MTU of 1,500 bytes the fragment offsets
would be: 0, (1480/8) = 185, (2960/8) = 370, (4440/8) = 555, (5920/8) = 740, etc.

By some chance if a packet changes link layer protocols or the MTU reduces then these fragments would be
fragmented again.

For example, if a 4,500-byte data payload is inserted into an IP packet with no options (thus total length is
4,520 bytes) and is transmitted over a link with an MTU of 2,500 bytes then it will be broken up into two
fragments:

Indeed, the amount of data has been preserved — 1480 + 1000 + 1480 + 540 = 4500 — and the last
fragment offset (495) * 8 (bytes) plus data — 3960 + 540 = 4500 — is also the total length.

Note that fragments 3 & 4 were derived from the original fragment 2. When a device must fragment the last
fragment then it must set the flag for all but the last fragment it creates (fragment 4 in this case). Last
fragment would be set to 0 value.
Reassembly

When a receiver detects an IP packet where either of the following is true:

• "more fragments" flag set

• "fragment offset" field is non-zero

then the receiver knows the packet is a fragment. The receiver then stores the data with the identification
field, fragment offset, and the more fragments flag. When the receiver receives a fragment with the more
fragments flag set to 0 then it knows the length of the original data payload since the fragment offset
multiplied by 8 (bytes) plus the data length is equivalent to the original data payload size.

Using the example above, when the receiver receives fragment 4 the fragment offset (495 or 3960 bytes) and
the data length (540 bytes) added together yield 4500 — the original data length.

Once it has all the fragments then it can reassemble the data in proper order (by using the fragment offsets)
and pass it up the stack for further processing.

Assistive protocols

The Internet Protocol is the protocol that defines and enables internetworking at the Internet Layer and thus
forms the Internet. It uses a logical addressing system. IP addresses are not tied in any permanent manner to
hardware identifications and, indeed, a network interface can have multiple IP addresses. Hosts and routers
need additional mechanisms to identify the relationship between device interfaces and IP addresses, in order
to properly deliver an IP packet to the destination host on a link. The Address Resolution Protocol (ARP)
perform this IP address to hardware address (MAC address) translation for IPv4. In addition the reverse
correlation is often necessary, for example, when an IP host is booted or connected to a network it needs to
determine its IP address, unless an address is preconfigured by an administrator. Protocols for such inverse
correlations exist in the Internet Protocol Suite. Currently used methods are Dynamic Host Configuration
Protocol (DHCP), Bootstrap Protocol (BOOTP) and, infrequently, inverse ARP.

Addressing

IPv4 uses 32-bit (four-byte) addresses, which limits the address space to 4,294,967,296 (232) possible unique
addresses. However, some are reserved for special purposes such as private networks (~18 million
addresses) or multicast addresses (~270 million addresses). This reduces the number of addresses that can
potentially be allocated for routing on the public Internet. As addresses are being incrementally delegated to
end users, an IPv4 address shortage has been developing. However, network addressing architecture
redesign via classful network design, Classless Inter-Domain Routing, and network address translation
(NAT) have contributed to delay significantly the inevitable exhaustion.

This limitation has stimulated the development of IPv6, which is currently in the early stages of deployment,
and is the only long-term solution.
IP Routing
IP Routing is an umbrella term for the set of protocols that determine the path that data follows in order to
travel across multiple networks from its source to its destination. Data is routed from its source to its
destination through a series of routers, and across multiple networks. The IP Routing protocols enable
routers to build up a forwarding table that correlates final destinations with next hop addresses.

These protocols include:

• BGP (Border Gateway Protocol)

• IS-IS (Intermediate System - Intermediate System)
• OSPF (Open Shortest Path First)
• RIP (Routing Information Protocol)

When an IP packet is to be forwarded, a router uses its forwarding table to determine the next hop for the
packet's destination (based on the destination IP address in the IP packet header), and forwards the packet
appropriately. The next router then repeats this process using its own forwarding table, and so on until the
packet reaches its destination. At each stage, the IP address in the packet header is sufficient information to
determine the next hop; no additional protocol headers are required.

The Internet, for the purpose of routing, is divided into Autonomous Systems (ASs). An AS is a group of
routers that are under the control of a single administration and exchange routing information using a
common routing protocol. For example, a corporate intranet or an ISP network can usually be regarded as an
individual AS. The Internet can be visualized as a partial mesh of ASs. An AS can be classified as one of the
following three types.

• A Stub AS has a single connection to one other AS. Any data sent to, or received from, a destination
outside the AS must travel over that connection. A small campus network is an example of a stub
AS.

• A Transit AS has multiple connections to one or more ASs, which permits data that is not destined
for a node within that AS to travel through it. An ISP network is an example of a transit AS.

• A Multihomed AS also has multiple connections to one or more ASs, but it does not permit data
received over one of these connections to be forwarded out of the AS again. In other words, it does
not provide a transit service to other ASs. A Multihomed AS is similar to a Stub AS, except that the
ingress and egress points for data traveling to or from the AS can be chosen from one of a number of
connections, depending on which connection offers the shortest route to the eventual destination. A
large enterprise network would normally be a multihomed AS.

An Interior Gateway Protocol (IGP) calculates routes within a single AS. The IGP enables nodes on
different networks within an AS to send data to one another. The IGP also enables data to be forwarded
across an AS from ingress to egress, when the AS is providing transit services.

Routes are distributed between ASs by an Exterior Gateway Protocol (EGP). The EGP enables routers
within an AS to choose the best point of egress from the AS for the data they are trying to route.

The EGP and the IGPs running within each AS cooperate to route data across the Internet. The EGP
determines the ASs that data must cross in order to reach its destination, and the IGP determines the path
within each AS that data must follow to get from the point of ingress (or the point of origin) to the point of
egress (or the final destination).

The diagram below illustrates the different types of AS in a network. OSPF, IS-IS and RIP are IGPs used
within the individual ASs; BGP is the EGP used between ASs.