Chapter 5

Internet Protocol
TCP/IP Illustrated. Volume 1

Agenda
Introduction
IPv4 and IPv6 Headers
IPv6 Extension Headers
IP Forwarding
Mobile IP
Host Processing of IP Datagrams
Attacks Involving IP

Introduction
IP is the workhorse protocol of the TCP/IP protocol suite
All TCP, UDP, ICMP, and IGMP data gets transmitted as IP datagrams
IP provides a best-effort, connection-less datagram delivery service
It does not guarantee that an IP datagram gets to its destination
successfully. Any required reliability must be provided by the upper
layers (e.g. TCP)
IP does not maintain any connection state information about related
datagrams within the network elements; each datagram is handled
independently from all other
Some protocol above IP has to handle all the potential problems to
provide error-free delivery abstraction for applications

IP Header fields
The normal size of the IPv4 header is 20 bytes, unless options are present (which is
rare).
The IPv6 header is twice as large but never has any options. It may have extension
headers, which provide similar capabilities.
The most significant bit is numbered 0 at the left, and the least significant bit of a
32-bit value is numbered 31 on the right.
The 4 bytes in a 32-bit value are transmitted in the following order: bits 07 first,
then bits 815, then 1623, and bits 2431 last.
This is called big endian byte ordering, which is the byte ordering required for all
binary integers in the TCP/IP headers as they traverse a network.
It is also called network byte order.
Computer CPUs that store binary integers in other formats, such as the little endian
format used by most PCs, must convert the header values into network byte order
for transmission and back again for reception.

IPv4 Headers

IPv6 Headers

 The first 6 bits are now called the Differentiated Services Field (DS
Field), and the last 2 bits are the Explicit Congestion Notification
(ECN) field or indicator bits.
The Total Length field is the total length of the IPv4 datagram in
bytes. Using this field and the IHL field, we know where the data
portion of the datagram starts, and its length.
Because this is a 16-bit field, the maximum size of an IPv4
datagram (including header) is 65,535 bytes
The Total Length field is required because some lower-layer
protocols that carry IPv4 datagrams do not convey the size of
encapsulated datagrams on their own
Ethernet pads small frames to be a min. length (64 bytes). If the
TL field were not provided, the IPv4 implementation would not
know how much of a 46-byte Ethernet frame was really an IP
datagram, as opposed to padding.

 When an IPv4 datagram is fragmented into multiple smaller

fragments, each of which itself is an independent IP datagram, the
Total Length field reflects the length of the particular fragment.
Fragmentation is described in detail along with UDP in Chapter 10.
In IPv6, fragmentation is not supported by the header, and the
length is instead given by the Payload Length field. This field
measures the length of the IPv6 datagram not including the length
of the header; extension headers, however, are included in the
Payload Length field.
As with IPv4, the 16-bit size of the field limits its maximum value to
65,535. With IPv6, however, it is the payload length that is limited
to 64KB, not the entire datagram.
In addition, IPv6 supports a jumbogram option that provides for the
possibility, at least theoretically, of single packets with payloads as
large as 4GB (4,294,967,295 bytes)!

 The Identification field helps identify each datagram

sent by an IPv4 host.
To ensure that the fragments of one datagram are not
confused with those of another, the sending host
normally increments an internal counter by 1 each time
a datagram is sent (from one of its IP addresses) and
copies the value of the counter into the IPv4
Identification field.
This field is most important for implementing
fragmentation, so we explore it further in Chapter 10.
In IPv6, this field shows up in the Fragmentation
extension header, as we discuss in the coming Section

 The Time-to-Live field, or TTL, sets an upper limit on the

number of routers through which a datagram can pass.
It is initialized by the sender to some value (64 is
recommended [RFC1122], although 128 or 255 is not
uncommon) and decremented by 1 by every router that
forwards the datagram.
When this field reaches 0, the datagram is thrown away,
and the sender is notified with an ICMP message (see
Chapter 8).
This prevents packets from getting caught in the
network forever should an unwanted routing loop occur

 The Protocol field in the IPv4 header contains a number indicating the type
of data found in the payload portion of the datagram.
The most common values are 17 (for UDP) and 6 (for TCP). This provides a
demultiplexing feature so that the IP protocol can be used to carry
payloads of more than one protocol type.
Although this field originally specified the transport-layer protocol the
datagram is encapsulating, it is now understood to identify the
encapsulated protocol, which may or not be a transport protocol. For
example, other encapsulations are possible, such as IPv4-in-IPv4 (value 4).
The official list of the possible values of the Protocol field is given in the
assigned numbers page [AN].
The Next Header field in the IPv6 header generalizes the Protocol field
from IPv4. It is used to indicate the type of header following the IPv6
header.
This field may contain any values defined for the IPv4 Protocol field, or any
of the values associated with the IPv6 extension headers

 The Header Checksum field is calculated over the IPv4 header

only. It means that the payload of the IPv4 datagram (e.g., TCP or
UDP data) is not checked for correctness by the IP protocol.
To help ensure that the payload portion of an IP datagram has
been correctly delivered, other protocols must cover any
important data that follows the header with their own dataintegrity-checking mechanisms.
We shall see that almost all protocols encapsulated in IP (ICMP,
IGMP, UDP, and TCP) have a checksum in their own headers to
cover their header and data and also to cover certain parts of the
IP header they deem important (a form of layering violation).
Perhaps surprisingly, the IPv6 header does not have any
checksum field.

 Every IP datagram contains the Source IP Address of the sender of

the datagram and the Destination IP Address of where the
datagram is destined.
These are 32-bit values for IPv4 and 128-bit values for IPv6, and
they usually identify a single interface on a computer, although
multicast and broadcast addresses (see Chapter 2) violate this
rule.
While a 32-bit address can accommodate a seemingly large
number of Internet entities (4.5 billion), there is widespread
agreement that this number is inadequate, a primary motivation
for moving to IPv6.
The 128-bit address of IPv6 can accommodate a huge number of
Internet entities.
As was restated in [H05], IPv6 has 3.4 1038 (340 undecillion)
addresses.

The Internet Checksum

The Internet checksum is a 16-bit mathematical sum used to
determine, with reasonably high probability, whether a received
message or portion of a message matches the one sent.
Note that the Internet checksum algorithm is not the same as the
common cyclic redundancy check (CRC) [PB61], which offers
stronger protection
When an IPv4 datagram is received, a checksum is computed
across the whole header, including the value of the Checksum field
itself.
Assuming there are no errors, the computed checksum value is
always 0. Note that for any nontrivial packet or header, the value
of the Checksum field in the packet can never be FFFF.

 If it were, the sum (prior to the final ones complement

operation at the sender) would have to have been 0.
No sum can ever be 0 using ones complement addition
unless all the bytes are 0something that never
happens with any legitimate IPv4 header.
When the header is found to be bad (the computed
checksum is nonzero), the IPv4 implementation discards
the received datagram.
No error message is generated. It is up to the higher
layers to somehow detect the missing datagram and
retransmit if necessary.

DS Field
Differentiated Services (called DiffServ) is a framework and set of standards aimed at
supporting differentiated classes of service (i.e., beyond just best-effort) on the
Internet
IP datagrams that are marked in certain ways (by having some of these bits set
according to predefined patterns) may be forwarded differently (e.g., with higher
priority) than other datagrams.
Doing so can lead to increased or decreased queuing delay in the network and other
special effects.
A number is placed in the DS Field termed the Differentiated Services Code Point
(DSCP).
A code point refers to a particular predefined arrangement of bits with agreed-upon
meaning.
Typically, datagrams have a DSCP assigned to them when they are given to the
network infrastructure that remains unmodified during delivery. However, policies
(such as how many high-priority packets are allowed to be sent in a period of time)
may cause a DSCP in a datagram to be changed during delivery

IP Options
IP supports a number of options that may be selected on a per-datagram basis.
Most of these options were introduced in [RFC0791] at the time IPv4 was being
designed, when the Internet was considerably smaller and when threats from malicious
users were less of a concern. many of the options are no longer practical or desirable
because of the limited size of the IPv4 header or concerns regarding security.
With IPv6, most of the options have been removed or altered and are not an integral
part of the basic IPv6 header. Instead, they are placed after the IPv6 header in one or
more extension headers.
An IP router that receives a datagram containing options is usually supposed to perform
special processing on the datagram. In some cases IPv6 routers process extension
headers, but many headers are designed to be processed only by end hosts.
In some routers, datagrams with options or extensions are not forwarded as fast as
ordinary datagrams.
We briefly discuss the IPv4 options as background and then look at how IPv6
implements extension headers and options. Table 5-4 shows most of the IPv4 options
that have been standardized over the years.

Currently, all options in Table 5-4

use option class 0 (control) except
Timestamp and Traceroute, which
are both class 2 (debugging and
measurement). Classes 1 and 3 are
reserved.

IPv6 Extension Headers

Special functions such as those provided by options in IPv4 can
be enabled by adding extension headers to the IPv6 header
The IPv6 extension headers are added only when needed.
In choosing IPv6 header to be a fixed size, and requiring that
extension headers be processed only by end hosts, the
designers have made the design and construction of highperformance routers easier because the demands on packet
processing at routers can be simpler than IPv4.
Extension headers, along with headers of higher-layer
protocols such as TCP or UDP are chained together with the
IPv6 header to form a cascade of headers

 The Next Header

field in each
header indicates
the type of the
subsequent
header, which
could be an IPv6
extension header
or some other
type.
The value of 59
indicates the end
of the header
chain.

 The order of the extension headers is given as a recommendation, except for

Hop-by-Hop Options, which is mandatory, so an implementation must be
prepared to process extension headers in the order they are received

IPv6 Options
IPv6 provides a more flexible and extensible way of
incorporating extensions and options as compared to IPv4.
Options, if present, are grouped into either Hop-by-Hop
Options (those relevant to every router along a datagrams
path) or Destination Options (those relevant only to the
recipient).
Hop-by-Hop Options (called HOPOPTs) are the only ones that
need to be processed by every router a packet encounters.
The format for encoding options within the Hop-by-Hop and
Destination Options extension headers is common

 The 1st byte indicates the type of option and includes 3 subfields
The 1st subfield gives the action to be taken by an IPv6 node attempting to
process the option that does not recognize the 5-bit option Type subfield
If an unknown option were included in a datagram destined for a multicast
destination, a large number of nodes could conceivably generate traffic back
to the source.
This can be avoided by use of the 11-bit pattern for the Action subfield.
A newly specified option can be carried in datagrams and simply ignored by
those routers that do not understand it, helping to promote incremental
deployment of new options.
The Change bit field is set to 1 when the option data may be modified as the
datagram is forwarded

Routing Header
The IPv6 Routing header provides a mechanism for the
sender of an IPv6 datagram to control, the path the
datagram takes through the network.
At present, two different versions of the routing
extension header have been specified, called type 0
(RH0) and type 2 (RH2).
RH0 has been deprecated because of security concerns
[RFC5095], and RH2 is defined in conjunction with
Mobile IP

Fragment Header
The Fragment header is used by an IPv6 source when
sending a datagram larger than the path MTU of the
datagrams intended destination
In IPv6, only the sender of the datagram is permitted to
perform fragmentation, and in such cases a Fragment
header is added.
The Fragment header includes the same information as
is found in the IPv4 header, but the Identification field is
32 bits instead of the 16 that are used for IPv4.

 Reserved field and 2-bit Res field are both zero and ignored by receivers.
The Fragment Offset field indicates where the data that follows the Fragment
header is located, as a positive offset in 8-byte units, relative to the fragmentable
part of the original IPv6 datagram.
The M bit field, if set to 1, indicates that more fragments are contained in the
datagram. A value of 0 indicates that the fragment contains the last bytes of the
original datagram.
The datagram consists of 2 parts: the unfragmentable part and the fragmentable
part
The unfragmentable part includes the IPv6 header & any included extension
headers required to be processed by intermediate nodes to the destination.
The fragmentable part constitutes the remainder of the datagram

IP Forwarding
IP forwarding is simple, especially for a host. If the
destination is directly connected to the host (e.g., a
point-to-point link) or on a shared network (e.g.,
Ethernet), the IP datagram is sent directly to the
destinationa router is not required
Otherwise, the host sends the datagram to a single
router (called the default router) and lets the router
deliver the datagram to its destination
The difference between host and router is: a host never
forwards datagrams it does not originate, whereas
routers do

 The IP protocol can receive a datagram either from

another protocol on the same machine or from a
network interface
The IP layer has some info in memory (routing table or
forwarding table), which it searches each time it
receives a datagram to send
When a datagram is received from a network interface,
IP checks if the dest IP addr is one of its ownor some
other addr for which it should receive traffic, such as an
IP broadcast or multicast addr.
If so, the datagram is delivered to the protocol module
specified by the Protocol field in the IPv4 header or Next
Header field in IPv6 header
If the datagram is not for one of the IP addr used locally,
then 1) if the IP layer was configured as a router, the

Forwarding Table
Each entry in the routing/forwarding table contains the
following fields:
Destination: This contains a 32-bit field (or 128-bit field for
IPv6) used for matching the result of a masking operation.
Mask: This contains a 32-bit field (128-bit field for IPv6)
applied as a bitwise AND mask to the destination IP address
of a datagram being looked up in the forwarding table
Next-hop: This contains the 32-bit IPv4 address or 128-bit
IPv6 address of the next IP entity (router or host) to which the
datagram should be sent
Interface: This contains an identifier used by the IP layer to
reference the network interface that should be used to send
the datagram to its next hop

IP Forwarding Actions
Direct delivery: All systems are using the same network
prefix

Destination

Mask

Gateway (Next
Hop)

Interface

0.0.0.0

0.0.0.0

10.0.0.1

10.0.0.100

10.0.0.0

255.255.255.1
28

10.0.0.100

10.0.0.100

Indirect Delivery

The lower-layer addr determine which machines receive the frame containing the datagram on a per-hop basis

E.g. Our Windows host has an IP datagram to send to the host ftp.uu.net, whose IPv4 addr is 192.48.96.9

First, the Windows machine searches its forwarding table but does not find a matching prefix on the local network.

It uses its default route entry (which matches every destination, but with no 1 bits at all).

The default entry indicates that the appropriate next-hope gateway is 10.0.0.1.

 The forwarding table at R1 indicates that address

translation should be performed for traffic. The router
has a private addr on one side (10.0.0.1) and a public
Destinatio
Mask (70.231.132.85).
Gateway
Interface
Note
addr
on
the
other
n
0.0.0.0
10.0.0.0

0.0.0.0

70.231.159.2 70.231.159.
54
85

255.255.255.1 10.0.0.100
10.0.0.1
performs 28
Network Address Translation

NAT
NAT

R1
(NAT) on the
datagram to make it routable on the Internet.
The NAT operation results in the datagram having the
new source addr 70.231.159.85.

Mobile IP
Mobile IP is based on the idea that a host has a home
network but may visit other networks from time to time.
When away from home, the host keeps the IP address it
would ordinarily use at home, but some special routing
and forwarding tricks are used to make the host appear
to be on the network, as though it is attached to its
home network.
The scheme depends on a special type of router called a
home agent that helps provide routing for mobile
nodes.

Host Processing of IP
Datagrams
Hosts must consider Source IP Address and Destination
IP Address of the packets they forward.
Applications such as Web browsers may attempt to
make connections to a named host or server that can
have multiple addresses.
The client system making such connections may also
have multiple addresses.
Whether a received unicast datagram matches one of a
hosts IP Addresses and should be processed, the
decision depends on the host model of the receiving
system

Host Models
There are 2 host models, the strong host model and the
weak host model.
In the strong host model, a datagram is accepted for
delivery to the local protocol stack only if the IP address
contained in the Destination IP Address field matches
one of the configured on the interface upon which the
datagram arrived.
It is opposite for weak host model, a datagram carrying
a destination addr matching any of the local addresses
may arrive on any interface & is processed by the
receiving protocol stack.
The same goes for sending behavior

 The reason of using the strong host model relates to a security concern.
If a malicious user injects a packets destined for 203.0.113.2, and the
Internet routes such a packet to B, applications running on B may be
tricked to believe they received local traffic originating from A.
This can have negative consequences if such applications make access
control decisions based on the source IP.
The host model, can be configured in some OS.
In Windows (Vista & later), strong host behavior is the default. In Linux,
the IP behavior defaults to the weak host model.
Windows commands to configure weak host receive and send behavior:
C:\> netsh interface ipvX set interface <ifname>
weakhostreceive=Yabled
C:\> netsh interface ipvX set interface <ifname>
weakhostsend=Yabled
X = 4 or 6; Y = en or dis; ifname = interface name

Address Selection
When a host sends an IP datagram, it must decide
which on its IP addresses to place in the Source IP
Address field, and which destination addr to use for a
particular destination host if it has multiple addresses.
The IP addresses used in the Source IP and Dest IP Addr
fields are selected using a set of procedures called
source address selection and destination address
selection.
[RFC3484] gives the rules for selecting IPv6 default
addresses; IPv4-only hosts do not ordinarily have such
complex issues

 The default rules in [RFC3484] prefer source/destination address

pairs where the addresses are of the same scope, to prefer smaller
over larger scopes, to avoid using temp addresses when other
addresses are available, & to otherwise prefer pairs with the longest
common prefix. Global addresses are preferred over temp addresses.
The selection of default addresses is controlled by a policy table,
present (at least conceptually) in each host. It is a longest-matchingprefix lookup table, similar to a forwarding table used with IP routing.
For an address A, a lookup in this table produces a precedence value
for A, P(A), and a label for A, L(A). A higher precedence value
indicates greater preference. The labels are used for grouping of
similar address types. For example if L(S) = L(D), the algorithm
prefers to use the pair (S,D) as a source/destination pair. If no other
policy is specified, [RFC3484] suggests that the policy values from
Table 5-10 be used

Attacks Involving IP
Simple attacks involve trying to get a router to crash or perform poorly
because one or more of the IP header fields are not valid
Routers today ignore or strip IP options, and the bugs in basic packet
processing have been fixed.
Without authentication or encryption, IP spoofing attacks are possible
In the earlier days, this involved fabricating the source IP addr.
A remote attackers computer would appear to be a host on the local
network requesting some sort of service.
There are several approaches to limit its damage, including ingress
filtering, whereby an ISP checks the source addresses of its customers
traffic to ensure that datagrams contain source address from an
assigned IP prefix.

 Other possibilities include spoofing the source address

and/or Routing header entries to make packets appear
as if they have come from other places.
These attacks are avoided by configuring packetfiltering firewall to take into account the contents of
Routing headers.
Simply filtering out all packets containing extension
headers & options in IPv6 would severely restrict its use.