Tải bản đầy đủ
6 Simple IP routing control mechanisms: time- to- live ( ttl) and hop limit fields

6 Simple IP routing control mechanisms: time- to- live ( ttl) and hop limit fields

Tải bản đầy đủ

178

WANs, routers and the Internet protocol (IP)

routing algorithms. For this reason, the Internet protocol provides a field called time-to-live
(TTL) in IP version 4 and an equivalent field in IPv6 called hop limit. If the TTL or hop limit
is exceeded, then the packet should be discarded by any router which subsequently receives
it. This at least prevents the packet from trekking endlessly through the network.
Enough of the background! Let’s now get down to describing the Internet protocol (IP)
itself.

5.7 Internet protocol version 4 (IPv4)
Internet protocol version 4 (IPv4) is a network layer protocol for packet-switched datagram
communication. Figure 5.6 illustrates the standardised format of an Internet protocol datagram
(IP datagram or IP packet) conforming to IPv4, as defined in RFC 791.11
Internet protocol version 4 (IPv4) is quite a straightforward packet-switching protocol.
In some ways it is similar to the ITU-T packet-switching protocol, recommendation X.25,
which we met in Chapter 3. But the fact that it is a connectionless, protocol rather than a
connection-oriented protocol makes it different. We shall explain IP in detail by considering
the contents, meaning and use of the various IP-header fields (Figure 5.6). But if you need any
extra assistance on exact details of the protocol operation or precise field codings, RFCs 791
(Internet protocol version 4) and 1812 (Requirements for IPv4 routers) provide the definitive
documentation.

IP Version 4 (IPv4) header format
RFC 791, in line with most other IP-suite protocol documentation, specifies the protocol
headers and packet formats in terms of words of data rather than in terms of single octets 12 .

Figure 5.6
11

IP datagram structure showing IP-header fields and IP data.

Though IP does not correspond exactly to OSI layer 3, it nonetheless can be considered approximately
equivalent.
12
An octet is the same as a byte — i.e., 8 bits. The name octet rather than byte is commonly used in protocol
specifications.

Internet protocol version 4 (IPv4)

179

In the case of the IPv4 itself, RFC 791 specifies the packet or datagram format in terms of a
number of 4 octet (i.e., 32-bit) words.
The IP header is always transmitted in the non-canonical format. In other words, the
header fields are always sent most significant bit (MSB) first. Thus transmission generally
commences at the left-hand corner of the illustrated packet format (as shown in Figure 5.6)
and continues line-by-line (i.e., word-by-word) until reaching the bottom right-hand corner
of the packet header. But the transmission order of bits in the IP data (i.e., user data) field
(whether transmitted in canonical or non-canonical format) is not specified.

IP Version field
The version field of the IPv4-header indicates the format of the Internet header. The value is
set to binary ‘0100’ [decimal value 4] for IP version 4. The only other allowed values are 5
(IP version 5 was an experimental stream protocol (also called ST2 and ST2+ which was not
widely deployed) and 6 (IP version 6, which is currently commencing large-scale deployment).

IHL (Internet header length) field
The Internet header length (IHL) field indicates the length of the packet header in 32 bit words.
The minimum value of this field is 5 words (5 × 4 octets), but with additional options, the
header could be much longer, as is apparent from Figure 5.6. If necessary, padding can be
used to fill out any remaining empty final portion of the final 4-octet word of the options field.

Type of service (TOS) field
The type of service (TOS) field (Figure 5.7a) is intended to indicate the relative priority to be
afforded to the forwarding of the particular packet. The intention is that intermediate routers
along the packet’s path handle packets not on a simple first-in-first-out (FIFO) basis but instead

Figure 5.7

Type of Service (TOS) and options fields of the IPv4 header.

180

WANs, routers and the Internet protocol (IP)

Table 5.2

IP Precedence field determines relative priority for packet processing and forwarding

IP Precedence Value decimal (binary in brackets)
TOS bits 0, 1 and 2
7
6
5
4
3
2
1
0

Table 5.3

Meaning

(111)
(110)
(101)
(100)
(011)
(010)
(001)
(000)

Network Control
Internetwork Control
CRITIC/ECP (critical/exceptional)
Flash Override
Flash
Immediate
Priority
Routine

Delay, throughput and reliability — bits (D-, T- and R-bits) of the type of service (TOS) field

TOS bit
D-bit (TOS bit 3)
T-bit (TOS bit 4)
R-bit (TOS bit 5)
TOS bit 6
TOS bit 7

Meaning
Delay
Throughput
Reliability
Reserved for future use
Reserved for future use

Binary value‘0’
Normal
Normal
Normal
Always
Always

Delay
Throughput
Reliability
set to ‘0’
set to ‘0’

Binary value‘1’
Low Delay
High Throughput
High Reliability
Not used
Not used

will process them in an order more appropriate to their relative priorities. The first three bits
of the TOS-field (bits 0, 1 and 2) contain the IP precedence indication (Table 5.2). This sets a
relative priority for the packet’s processing and forwarding through the network. In addition,
the TOS-field includes the D (delay), T (throughput) and R (reliability) bits (Table 5.3) which
define additional specific needs of the communication. At most, two of the D, T, and/or R-bits
in the TOS-field should be set. An alternative use of the TOS-field is to support differentiated
services (DiffServ) — as we shall discuss later in the chapter.
It is not mandatory that the type of service (TOS) field should be processed by all routers.
In the case that a router does not interpret or process this field, all packets must be processed
normally (i.e., with equal precedence).

Total length of IPv4 datagram and the relationship to the path maximum
transmission unit (PMTU)
The total length field indicates the total length of an IP datagram (i.e., IP packet) including
the IP header. The value is coded in binary and represents the total number of octets. The
maximum value is 65 535. All hosts and routers which support IPv4 must be able to accept
IP datagrams of at least 576 octets length without requiring fragmentation. The value 576
corresponds nominally to 512 octets of data plus a 64-octet header.
By first discovering the maximum transmission unit (MTU) length (i.e., the maximum IPdata field length — see Table 5.4) that can be carried by all the links of a given end-toend path, a host or source router can ensure that fragmentation will not be necessary. This
process is called path MTU (PMTU) discovery. Fragmentation is avoided by sending packets
corresponding to a packet length equal to or shorter than the PMTU. A standard method for
PMTU discovery for IPv4 is defined in RFC 1191 (and for IPv6 in RFC 1981). A more
pragmatic approach assumes that the PMTU is the lower of the first hop MTU and 576 octets
(the recommended minimum MTU of an IPv4 router).

Internet protocol version 4 (IPv4)
Table 5.4

Path maximum transmission unit (PMTU) size for common types of networks

Network type

Maximum message
transmission unit

Minimum IP MTU
Standard IP MTU
X.25
IEEE 802.3/802.2 Ethernet LAN
X.25
PPP (Point-to-Point Protocol)
FDDI (Fibre Distributed Data Interface)
4 Mbit/s Token Ring LAN (IEEE 802.5)
ATM (Asynchronous Transfer Mode)
16 Mbit/s Token Ring
Maximum IP MTU

Table 5.5
Flag bits
Bit meaning
Binary value ‘0’
Binary value ‘1’

181

Specification

68 octets (= 68 bytes)
576 octets
576 octets
1492 octets
1500 octets
1500 octets
4352 octets
4464 octets
9180 octets
17914 octets
65535 octets

RFC
RFC
RFC
RFC
RFC
RFC
RFC
RFC
RFC
RFC
RFC

791
791
877
1042
1356
1661
1390
1042
1626 & RFC 2225
1191
791

Fragmentation flag field of IPv4 header

0

1

2

Reserved
Always set to ‘0’
Not used

DF — Do not Fragment
May be fragmented
May not be fragmented

MF — More Fragment
No more fragments follow
More fragments follow

Fragmentation-related fields
The second 4-octet word of the IPv4 header (octets 5–8) contains information regarding
the fragmentation of the communication, i.e., whether the packet is entire (unfragmented) or
only a single fragment of a larger message. The fragmentation flags (Figure 5.6 and Table 5.5)
indicate whether the packet is or may be fragmented. Typically, the use of path MTU discovery
is employed to try to avoid fragmentation, and the flags are then set to ‘010’.
In the case that fragmentation is undertaken, the fragment identification field is used to
mark all the fragments of an original packet with a common ‘packet number’. In addition,
flag bit 2 (MF-bit) indicates whether more fragments will follow, or whether the current
fragment is the last. The fragment offset is used during reassembly. It indicates where the
fragment belongs in the original packet. The first fragment has offset value 0. Subsequent
ones indicate the position of the fragment in multiples of 8 octets (64 bits) from the start of
the original packet.

Time-to-live (TTL) field
The time-to-live (TTL) field contains an integer binary value corresponding to the duration of
time in seconds for which the packet is still allowed to ‘live’. Each time the packet header
is processed by a router, the value in the TTL field must be checked, and be reduced by
at least 1 second. As soon as the TTL value reduces 0, the packet must be destroyed. In
practice, although the TTL field is nominally the lifetime in seconds, in reality it reflects the
maximum number of hops allowed to be traversed before a packet is considered to be ‘lost’
and undeliverable (and therefore ripe to be destroyed). A common initial default value setting
for the TTL field is 64 (possible values are 0–255 seconds). Such a value would allow for
the safe traversal of a path comprising around 20 routers (with a ‘safety margin’ to spare).

182

WANs, routers and the Internet protocol (IP)
Table 5.6

Protocol field values (IANA protocol numbers) and their meanings

Protocol field value
(possible range 0–255)

Protocol used at next higher layer
(i.e., content type of IP data field)

1
2
4
6
7
8
9

ICMP — Internet Control Message Protocol
IGMP — Internet Group Management Protocol
IP in IP encapsulation (RFC 2003)
TCP — Transmission Control Protocol
CBT — Core Based Trees
EGP — Exterior Gateway Protocol
IGP — Interior Gateway Protocol
(e.g., Cisco’s IGRP Interior Gateway Routing
Protocol)
UDP — User Datagram Protocol
RDP — Reliable Data Protocol
IRTP — Internet Reliable Transaction Protocol
NETBLT — Bulk Transfer Data Protocol
IDPR — Inter-Domain Policy Routing Protocol
SDRP — Source Demand Routing Protocol
IDRP — Inter-Domain Routing Protocol
RSVP — Resource ReSerVation Protocol
GRE — Generic Routing Encapsulation
MHRP — Mobile Host Routing Protocol
NARP — NBMA Address Resolution Protocol
ISO-IP — ISO Internet Protocol
VMTP — Versatile Message Transaction Protocol
EIGRP — Extended Interior Gateway Routing
Protocol (Cisco)
OSPF — Open Shortest Path First
MTP — Multicast Transport Protocol
MICP — Mobile Interworking Control Protocol
ETHERIP — Ethernet-within-IP encapsulation
ENCAP — Encapsulation header / private encryption
PIM — Protocol Independent Multicast
IP Comp — IP Payload Compression Protocol
Novell IPX-in-IP
VRRP — Virtual Router Redundancy Protocol
L2TP — Layer 2 Tunnelling Protocol

10
27
28
30
35
42
45
46
47
48
54
80
81
88
89
92
95
97
98
103
108
111
112
115

Note: For an up-to-date and complete listing refer to www.iana.org/assignments/protocol-numbers.

Protocol field
The protocol field indicates the format of the data held in the packet’s IP data field (see
Figure 5.6). This is the protocol used at the next higher layer of the communication. During
the data-transfer phase between two hosts communicating end-to-end across an IP network,
the next higher layer protocol will typically be either TCP (transmission control protocol)
(protocol value = 6) or UDP (user datagram protocol)(protocol value = 10). But a much
wider range of protocols may be contained in the packet as is apparent from Table 5.6.
Most of these protocols transfer internal network control, routing information, security, management and monitoring information between different network devices. Official protocol
field values are assigned following application to the Internet assigned numbers authority
(IANA) and a current list of all allocated protocol numbers can be viewed on their website
at www.iana.org.

Internet protocol version 4 (IPv4)

183

Header checksum
The header checksum has an equivalent role to the frame check sequence (FCS) we discussed
in Chapter 3, but uses a different (simpler) error detection algorithm. As for most IP-suite
protocols (including IP itself), the frame check algorithm is the 16-bit one’s complement of
the one’s complement sum of all 16-bit words in the header. For purposes of calculating the
checksum, the checksum field is assumed to be all 0s.

Source and destination addresses
The source and destination IP address fields usually indicate the original source and ultimate
destination of the IP packet. The format (for IP versions up to IPv4) is a 32-bit value, usually
written in the form d.d.d.d where each d is a decimal value between 0 and 255 representing
one of the four 8-bit octets of the number. We explain the numbering structure in more detail
later in the chapter.
The source address may not contain an address assigned as a multicast or broadcast group
address. The destination address may not contain the unspecified address (0.0.0.0) and should
only contain the loopback address (0.0.0.1) when used for test purposes.
The destination IP address field does not always contain the address of the ultimate destination. In the case of packets which follow paths controlled by source routing, the destination
IP address field will contain the IP address of the next intermediate point along the way.

IP Packet options
The IP packet header may (but need not) include the IP options fields. When included, IP
options are indicated by a corresponding increase in the value of the IHL (Internet header
length) field. The format of the IP options fields conforms to that illustrated in Figure 5.7b. In
cases where the option field does not exactly fill exactly the last 4-octet word of the header,
padding is used to fill the remaining space.
The copied flag in the options field header indicates that the option is copied into all
fragments (if the packet has been fragmented).
The possible options are security; source routing; timestamping; route recording and router
alerting, and the coding of the various options fields according to these options can be seen
in Table 5.7.
The security option field indicates the security level (unclassified, confidential, restricted,
secret, top secret, etc.) of the IP packet contents, the compartmentation, handling restrictions
and closed user group or TCC (transmission control code) information. The terminology reflects
the initial use of the Internet protocol for government and military communication. Most
recently, the security option field is used to carry authentication and encryption information
to ensure that only the intended recipient can decode the packet contents. IPv4 routers are
expected to support the security options.
Strict source and route records (SSRR) or loose source and route records (LSRR) are composed of a series of Internet addresses. These occupy the IP options data field (if the option
number field is set to one of the values 3, 7 or 9: see Table 5.7). The list of consecutive
IP addresses which appear in a source route record specify the precise route the packet is
to take through the network. As each destination in turn of a source-routed path is reached,
the destination IP address in the packet header is amended to the next indicated destination
in the list. Similarly, a route record (option number = 7) records the actual route taken by a
packet. This option is valuable to network administrators who are trying the trace the cause

184

WANs, routers and the Internet protocol (IP)
Table 5.7

Option number
value (0–31)

IP Packet options and coding of the IP packet header options field
Option

0

End of Option List

1

No operation

2

Option
length

Option
class value
(values 1 &
3 reserved)

Copy flag

0 = control

Not used

0 = control

Not used

0 = control

0=
1=
0=
1=
Not used

Security

Option length field
omitted, total option
fields only 1 octet
Option length field
omitted, total option
fields only 1 octet
11

3

Loose Source Routing

Variable

0 = control

4

Internet Timestamp

Variable

7

Variable

8

Route Record (traces
route taken)
Stream ID

2 = debug &
measurement
0 = control

4

0 = control

9

Strict Source Routing

Variable

0 = control

20

Router Alert

4

0 = control

Not used
0=
1=
0=
1=
0=
1=

of network performance problems in IP networks or the Internet. It is important to note that
source routing and route recording options may not be supported by all routers along the path.
The stream ID was used in certain experimental networks. The value is carried transparently
by networks which do not support the stream concept.
The timestamp is a right-justified 32-bit timestamp in milliseconds since midnight UT
(universal time). Routers may (but need not) support this option.

5.8 ICMP (Internet control message protocol)
The Internet protocol (IP) is an unreliable protocol since delivery of packets and end-toend user-information is not guaranteed. The problem lies in the fact that IP packets may
be submitted to a router network, without checking whether the destination is ready and
able to receive them and without even checking whether the destination address exists. IP is
a connectionless protocol.13 ICMP (Internet control message protocol) is designed to report
such delivery problems. But while ICMP reports most of the errors and delivery problems
which can be encountered by IP datagrams (packets) or fragments, and while it is an ‘integral part’ of the Internet Protocol, it nonetheless does not make IP reliable and delivery
of packets remains unguaranteed. The problem is that the delivery of the ICMP messages
themselves (which are carried by IP) cannot be guaranteed. In the case of network congestion, for example, the time-to-live value could expire, whereupon an ICMP message would
be destroyed.
An ICMP message is generated when a packet cannot reach its destination; when no
buffering is available at a gateway or destination host; or when the destination host could
13

See Chapter 3.

ICMP (Internet control message protocol)

Figure 5.8

185

Internet Control Message Protocol version 4 (ICMPv4): protocol format.

be reached via a shorter route. The ICMP message is generated in the format illustrated in
Figure 5.8, this field being packed into the IP data field of an IP packet (Figure 5.6). The
destination and source addresses of the original IP packet (the one which encountered the
problem) are reversed, so that the ICMP message is returned to the original source.
So that the source host can identify which packet encountered the problem, the ICMP
information field (Figure 5.8) is usually filled with the IP-header of the original packet plus
at least 64 bits (8 octets) of the original IP data (i.e., user data).
The coding of the various fields in the ICMP protocol is documented in Table 5.8. As you
will see from Table 5.8, ICMP has a number of uses other than merely reporting destination
unreachable, time exceeded or other IP parameter errors. It can also be used to acquire status
information about the network.
Table 5.8

Internet control message protocol version 4 (ICMPv4): messages and coding

ICMP Type
value (0–255)

ICMP Type meaning

ICMP code
value (0–255)

0

Echo message (e.g.,
PING request)
Destination
unreachable

0

3

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

ICMP Code meaning and ICMP
information field content
ICMP-info field gives identifier
and sequence number
Network unreachable
Host unreachable
Protocol unreachable
Port unreachable
Fragmentation needed and DF set
Source route failed
Destination network unknown
Destination host unknown
Source host isolated
Communication to network
prohibited
Communication to host
prohibited
Network unreachable for Type of
Service
Host unreachable for Type of
Service
Communication administratively
prohibited
Host Precedence violation
(continued overleaf )