Pv4

From Wikipedia, the free encyclopedia

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).

Internet Protocol Suite

Application Layer

BGP · DHCP · DNS · FTP · HTTP ·IMAP · IRC · LDAP · MG

CP · NNTP ·NTP · POP · RIP · RPC · RTP · SIP ·SMTP · SNM

P · SSH · Telnet ·TLS/SSL · XMPP ·

(more)

Transport Layer

TCP · UDP · DCCP · SCTP · RSVP ·ECN ·

(more)

Internet Layer

IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP ·IPsec ·

(more)

Link Layer

ARP/InARP · NDP · OSPF ·Tunnels (L2TP) · PPP · Media

Access Control (Ethernet, DSL, ISDN, FDDI) ·(more)

v · d · e
 Contents
 [hide]

1 Addressing

o 1.1 Address representations

o 1.2 Allocation

o 1.3 Special-use addresses

o 1.4 Private networks

 1.4.1 Virtual private

networks

o 1.5 Link-local addressing

o 1.6 Localhost

o 1.7 Addresses ending in 0 or 255

o 1.8 Address resolution

2 Address space exhaustion

3 Network address translation

4 Packet structure

o 4.1 Header

o 4.2 Data

5 Fragmentation and reassembly

o 5.1 Fragmentation

o 5.2 Reassembly

6 Assistive protocols

7 See also

8 Notes

9 References

10 External links

[edit]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.

[edit]Address representations
IPv4 addresses may simply be written in any notation expressing a 32-bit integer value, but for human
convenience, they are most often written in dot-decimal notation, which consists of the four octets of the
address expressed separately in decimal and separated by periods.

The following table shows several representation formats:

Notation Value Conversion from dot-decimal

Dot-decimal notation 192.0.2.235 N/A

Dotted Hexadecimal[1] 0xC0.0x00.0x02.0xEB Each octet is individually converted to hexadecimal form

Dotted Octal[1] 0300.0000.0002.0353 Each octet is individually converted into octal

Hexadecimal 0xC00002EB Concatenation of the octets from the dotted hexadecimal

Decimal 3221226219 The 32-bit number expressed in decimal

Octal 030000001353 The 32-bit number expressed in octal

Additionally, in dotted format, each octet can be of any of the different bases. For
example,192.0x00.0002.235 is a valid (though unconventional) equivalent to the above addresses.

[edit]Allocation

Originally, an IP address was divided into two parts, the network identifier represented in the most significant
(highest order) octet of the address and the host identifier using the rest of the address. The latter was
therefore also called the rest field. This enabled the creation of a maximum of 256 networks. This was quickly
found to be inadequate.
To overcome this limit, the high order octet of the addresses was redefined to create a set of classesof
networks, in a system which later became known as classful networking. The system defined five classes,
Class A, B, C, D, and E. The Classes A, B, and C had different bit lengths for the new network identification.
The rest of an address was used as previously to identify a host within a network, which meant that each
network class had a different capacity to address hosts. Class D was allocated for multicast addressing and
Class E was reserved for future applications.

Starting around 1985, methods were devised to allow IP networks to be subdivided. The concept of
thevariable-length subnet mask (VLSM) was introduced which allowed flexible subdivision into varying network
sizes.[2][3]

Around 1993, this system of classes was officially replaced with Classless Inter-Domain Routing(CIDR), and
the class-based scheme was dubbed classful, by contrast.

CIDR was designed to permit repartitioning of any address space so that smaller or larger blocks of addresses
could be allocated to users. The hierarchical structure created by CIDR is managed by theInternet Assigned
Numbers Authority (IANA) and the regional Internet registries (RIRs). Each RIR maintains a publicly-
searchable WHOIS database that provides information about IP address assignments.

[edit]Special-use addresses
Main article:  Reserved IP addresses#Reserved IPv4 addresses

Reserved address blocks

CIDR address
Description Reference
block

0.0.0.0/8 Current network (only valid as source address) RFC 1700

10.0.0.0/8 Private network RFC 1918

127.0.0.0/8 Loopback RFC 5735

169.254.0.0/16 Link-Local RFC 3927

172.16.0.0/12 Private network RFC 1918

192.0.0.0/24 Reserved (IANA) RFC 5735

192.0.2.0/24 TEST-NET-1, Documentation and example code RFC 5735

192.88.99.0/24 IPv6 to IPv4 relay RFC 3068

192.168.0.0/16 Private network RFC 1918

198.18.0.0/15 Network benchmark tests RFC 2544

198.51.100.0/24 TEST-NET-2, Documentation and examples RFC 5737

203.0.113.0/24 TEST-NET-3, Documentation and examples RFC 5737

224.0.0.0/4 Multicasts (former Class D network) RFC 3171

240.0.0.0/4 Reserved (former Class E network) RFC 1700

255.255.255.255 Broadcast RFC 919

[edit]Private networks
Of the approximately four billion addresses allowed in IPv4, three ranges of address are reserved for use
in private networks. These ranges are not routable outside of private networks and private machines cannot
directly communicate with public networks. They can, however, do so throughnetwork address translation.

The following are the three ranges reserved for private networks (RFC 1918):

Number of
Name Address range Classful description Largest CIDRblock
addresses

24-bit
10.0.0.0–10.255.255.255 16777216 Single Class A 10.0.0.0/8
block
20-bit 172.16.0.0– Contiguous range of 16 Class B
1048576 172.16.0.0/12
block 172.31.255.255 blocks

16-bit 192.168.0.0– Contiguous range of 256 Class C

65536 192.168.0.0/16
block 192.168.255.255 blocks

[edit]Virtual private networks

Packets with a private destination address are ignored by all public routers. Therefore, it is not possible to
communicate directly between two private networks (e.g., two branch offices) via the public Internet. This
requires the use of IP tunnels or a virtual private network (VPN).

VPNs establish tunneling connections across the public network such that the endpoints of the tunnel function
as routers for packets from the private network. In this routing function the host encapsulates packets in a
protocol layer with packet headers acceptable in the public network so that they may be delivered to the
opposing tunnel end point where the additional protocol layer is removed and the packet is delivered locally to
its intended destination.

Optionally, encapsulated packets may be encrypted to secure the data while it travels over the public network.

[edit]Link-local addressing
Main article:  Link-local address

RFC 5735 defines an address block, 169.254.0.0/16, for the special use in link-local addressing. These
addresses are only valid on the link, such as a local network segment or point-to-point connection, that a host
is connected to. These addresses are not routable and like private addresses cannot be the source or
destination of packets traversing the Internet. Link-local addresses are primarily used for address
autoconfiguration (Zeroconf) when a host cannot obtain an IP address from a DHCP server or other internal
configuration methods.

When the address block was reserved, no standards existed for mechanisms of address autoconfiguration.
Filling the void, Microsoft created an implementation called Automatic Private IP Addressing (APIPA). Due to
Microsoft's market power, APIPA has been deployed on millions of machines and has, thus, become a de
facto standard in the industry. Many years later, the IETFdefined a formal standard for this functionality, RFC
3927, entitled Dynamic Configuration of IPv4 Link-Local Addresses.

[edit]Localhost

Main article:  localhost

The address range 127.0.0.0–127.255.255.255 (127.0.0.0/8 in CIDR notation) is reserved

for localhostcommunication. Addresses within this range should never appear outside a host computer and
packets sent to this address are returned as incoming packets on the same virtual network device (known
as loopback).

[edit]Addresses ending in 0 or 255

Main article:  IPv4 subnetting reference

It is a common misunderstanding that addresses ending with an octet of 0 or 255 can never be assigned to
hosts. (See also Subnet - all zeros or all ones.) This is only true of networks with subnet masks of at least 24
bits — Class C networks in the old classful addressing scheme, or in CIDR, networks with masks
of /24 to /32 (or 255.255.255.0–255.255.255.255).

In classful addressing (now obsolete with the advent of CIDR), there are only three possible subnet masks:
Class A, 255.0.0.0 or /8; Class B, 255.255.0.0 or /16; and Class C, 255.255.255.0 or /24. For example, in the
subnet 192.168.5.0/255.255.255.0 (or 192.168.5.0/24) the identifier 192.168.5.0 refers to the entire subnet, so
it cannot also refer to an individual device in that subnet.

A broadcast address is an address that allows information to be sent to all machines on a given subnet, rather
than a specific machine. Generally, the broadcast address is found by obtaining the bit complement of the
subnet mask and performing a bitwise OR operation with the network identifier. In other words, the broadcast
address is the last address in the range belonging to the subnet. In our example, the broadcast address would
be 192.168.5.255, so to avoid confusion this address also cannot be assigned to a host. On a Class A, B, or C
subnet, the broadcast address always ends in 255.

However, this does not mean that every addresses ending in 255 cannot be used as a host address. For
example, in the case of a Class B subnet 192.168.0.0/255.255.0.0 (or 192.168.0.0/16), equivalent to the
address range 192.168.0.0–192.168.255.255, the broadcast address is 192.168.255.255. However, one can
assign 192.168.1.255, 192.168.2.255, etc. (though this can cause confusion). Also, 192.168.0.0 is the network
identifier and so cannot be assigned[why?][citation needed], but 192.168.1.0, 192.168.2.0, etc. can be assigned (though
this can also cause confusion).

With the advent of CIDR, broadcast addresses do not necessarily end with 255. For example, a CIDR subnet
203.0.113.16/28 would have a broadcast address of 203.0.113.31.

In general, the first and last addresses in a subnet are used as the network identifier and broadcast address,
respectively. All other addresses in the subnet can be assigned to hosts on that subnet.

[edit]Address resolution
Main article:  Domain Name System

Hosts on the Internet are usually known not by IP addresses, but by names (e.g., en.wikipedia.org,
www.whitehouse.gov, www.freebsd.org, www.berkeley.edu). The routing of IP packets across the Internet is
not directed by such names, but by the numeric IP addresses assigned to such domain names. This requires
translating (or resolving) domain names to addresses.

The Domain Name System (DNS) provides such a system for converting names to addresses and addresses
to names. Much like CIDR addressing, the DNS naming is also hierarchical and allows for subdelegation of
name spaces to other DNS servers.

The domain name system is often described in analogy to the telephone system directory information systems
in which subscriber names are translated to telephone numbers.

[edit]Address space exhaustion

Main article:  IPv4 address exhaustion

Since the 1980s it has been apparent that the number of available IPv4 addresses is being exhausted at a rate
that was not initially anticipated in the design of the network. [4] This was the motivation for the introduction
of classful networks, for the creation of Classless Inter-Domain Routing (CIDR) methods, and finally for the
redesign of the Internet Protocol, based on a larger address format (IPv6).

Several market forces have driven the acceleration of IPv4 address exhaustion:

 Rapidly growing number of Internet users

 Always-on devices — ADSL modems, cable modems

 Mobile devices — laptop computers, PDAs, mobile phones

A variety of technologies introduced during the growth of the Internet may be applied to mitigate IPv4 address
exhaustion, such as:

 Network address translation (NAT)

 Use of private networks

 Dynamic Host Configuration Protocol (DHCP)

 Name-based virtual hosting

 Tighter control by Regional Internet Registries on the allocation of addresses to Local Internet
Registries

 Network renumbering to reclaim large blocks of address space allocated in the early days of the
Internet

Various address allocation and depletion models constructed and published during several years prior to
exhaustion predicted top-level exhaustion of the address pool at IANA for early 2011, and the first regional
registry depletion later in the same year.[5] IANA allocated the last two /8 address blocks available via the RIR
request procedures to APNIC on 31 January 2011, leaving five blocks unused. By policy, each of these five is
allocated to the five regional registries, respectively.

The accepted and standardized solution is the migration to IPv6. The address size was increased in IPv6 from
32 bits in IPv4 to 128 bits, providing a vastly increased address space that allows improved route aggregation
across the Internet and offers large subnetwork allocations of a minimum of 2 64 host addresses to end-users.
Migration to IPv6 is in progress but completion is expected to take considerable time.

[edit]Network address translation

Main article:  Network address translation

The rapid pace of allocation of the IPv4 addresses and the resulting shortage of address space since the early
1990s led to several methods of more efficient use. One method was the introduction of network address
translation (NAT). NAT devices masquerade an entire, private network 'behind' a single public IP address,
permitting the use of private addresses within the private network. Most mass-market consumer Internet
access providers rely on this technique.

[edit]Packet structure

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

[edit]Header

The IPv4 packet header consists of 14 fields, of which 13 are required. The 14 th 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, for example.

bit
offse 0–3 4–7 8–13 14-15 16–18 19–31
t

Explicit
Header Differentiated Services
0 Version Congestion Total Length
Length Code Point
Notification

32 Identification Flags Fragment Offset

64 Time to Live Protocol Header Checksum

 96 Source IP Address

128 Destination IP Address

160 Options ( if Header Length > 5 )

160  
or Data
192+  

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 forDifferentiated
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 bytes — the
maximum value of a 16-bit word. The minimum size datagram that any host isrequired 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 (seeFragmentation
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.[6]

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 (2 13 – 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 countfield.
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, anICMP 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.

De
sti
 nat
ion
ad
dr
es
s 

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. The possible options that
can be put in the header are as follows:

Co

Op
Cl

Op
Nu
 Op
Le

Op
Da

 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
considere
d.

 Note: the
Copied,
Option
Class,
 and
Option
Number
are
sometime
s referred
to as a
single
eight-bit
field -
the Optio
n 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. [citation needed]
[edit]Data

The data field is n

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

Some of the
common protocols
are listed below
including their val
used in the protoc
field:
See List of IP
protocol
numbers for a
complete list.
[edit]Fragmen
ation and
reassembly

Main article: IP
fragmentation

The Internet
Protocol is the
facility in the
Internet architectu
that enables
different networks
exchange traffic a
route traffic acros
one another. The
design
accommodates
networks of divers
physical nature; it
independent of th
underlying
transmission
technology used i
the Link Layer. Lin
Layer networks of
different hardware
design usually var
not only in
transmission spee
but also in the
structure and size
valid framing
methods,
characterized by
the maximum
transmission
unit(MTU)
parameter. To fulf
the role of IP to
traverse networks
was necessary to
implement a
mechanism to
automatically adju
the size of
transmission units
to adapt to the
underlying
technology. This
introduced the ne
for fragmentation 
IP datagrams. In
IPv4, this function
was placed at
the Internet Layer
and is performed
IPv4 routers, whic
thus only require
this layer as highe
one implemented
their design.

In contrast, the ne
generation of the
Internet Protocol,
namely IPv6, doe
not require routers
to perform
fragmentation;
instead, hosts mu
determine the pat
maximum
transmission unit
advance of
transmission and
send conforming
datagrams.

[edit]Fragmen
ation
When a device
receives an IP
packet it examine
the destination
address and
determines the
outgoing interface
use. This interface
has an associated
MTU that dictates
the maximum data
size for its payloa
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 th
MTU less the IP
header size (20
bytes minimum; 6
bytes maximum).
Each segment is
then put into its ow
IP packet with the
following changes

 The total
length field is
adjusted to th
segment size

 The more
fragments (M
flag is set for
segments
except the las
one, which is
set to 0

 The fragment
offset field is
accordingly
based on the
offset of the
segment in th
original data
payload. This
measured in
units of eight-
byte blocks.

 The header
checksum fie
is recomputed

For example, for a

IP header of lengt
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, et

By some chance i
packet changes li
layer protocols or
the MTU reduces
then these
fragments would b
fragmented again

For example, if a
4,500-byte data
payload is inserte
into an IP packet
with no options
(thus total length i
4,520 bytes) and
transmitted over a
link with an MTU o
2,500 bytes then i
will be broken up
into two fragments
Now, let's say the
MTU drops to 1,5
bytes. Each
fragment will
individually be spl
up into two more
fragments each:
Indeed, the amou
of data has been
preserved — 1480
+ 1000 + 1480 +
540 = 4500 — an
the last fragment
offset (495) * 8
(bytes) plus data —
3960 + 540 = 450
— is also the tota
length.

Note that fragmen

3 & 4 were derive
from the original
fragment 2. When
device must
fragment the last
fragment then it
must set the flag f
all but the last
fragment it create
(fragment 4 in this
case). Last
fragment would be
set to 0 value.

[edit]Reassem
bly
When a receiver
detects an IP pac
where either of th
following is true:

 "more
fragments" fla
set
 "fragment
offset" field is
non-zero

then the receiver

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

Using the exampl

above, when the
receiver receives
fragment 4 the
fragment offset (4
or 3960 bytes) an
the data length (5
bytes) added
together yield 450
— the original dat
length.

Once it has all the

fragments then it
can reassemble th
data in proper ord
(by using the
fragment offsets)
and pass it up the
stack for further
processing.

[edit]Assistive
protocols

The Internet
Protocol is the
protocol that defin
and
enables internetw
king at the Interne
Layer and thus
forms the Internet
uses a logical
addressing system
IP addresses are
not tied in any
permanent manne
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 orde
to properly deliver
an IP packet to th
destination host o
a link. The Addres
Resolution
Protocol (ARP)
perform this IP
address to
hardware address
(MAC address)
translation for IPv
In addition the
reverse correlatio
is often necessary
for example, when
an IP host is boot
or connected to a
network it needs t
determine its IP
address, unless a
address is
preconfigured by
administrator.
Protocols for such
inverse correlation
exist in the Interne
Protocol Suite.
Currently used
methods
are Dynamic Host
Configuration
Protocol (DHCP),
ootstrap
Protocol(BOOTP)
and,
infrequently, inver
ARP.