The Internet Protocol (IP): Forwarding and Addressing in the Internet

 Discussion of network-layer addressing and forwarding thus far has been without

reference to any specific computer network.

 we’ll turn our attention to how addressing and forwarding are done in the Internet.

 We’ll see that Internet addressing and forwarding are important components of the

Internet Protocol (IP).

 There are two versions of IP in use today.

 We’ll first examine the widely deployed IP protocol version 4, which is usually referred

to simply as IPv4

 But before beginning our foray into IP, let’s take a step back and consider the

components that make up the Internet’s network layer.

 As shown in Figure 4.12, the Internet’s network layer has three major components.

Dr. T V Rama krishna Page 1

  The first component is the IP protocol, the topic of this section.

 The second major component is the routing component, which determines the path a

datagram follows from source to destination.

 We mentioned earlier that routing protocols compute the forwarding tables that are

used to forward packets through the network.

 The final component of the network layer is a facility to report errors in datagrams

and respond to requests for certain network-layer information.

 We’ll cover the Internet’s network-layer error- and information-reporting protocol,

the Internet Control Message Protocol (ICMP)

Datagram Format

 Recall that a network-layer packet is referred to as a datagram.

 We begin our study of IP with an overview of the syntax and semantics of the IPv4

datagram.

 You might be thinking that nothing could be drier than the syntax and semantics of a

packet’s bits.

 Nevertheless, the datagram plays a central role in the Internet—every networking

student and professional needs to see it, absorb it, and master it.

 The IPv4 datagram format is shown in Figure 4.13.

 The key fields in the IPv4 datagram are the following:

Dr. T V Rama krishna Page 2

 

• Version number.

 These 4 bits specify the IP protocol version of the datagram.

 By looking at the version number, the router can determine how to interpret the

remainder of the IP datagram.

 Different versions of IP use different datagram formats.

 The datagram format for the current version of IP, IPv4, is shown in Figure 4.13.

 The datagram format for the new version of IP (IPv6)

• Header length.

 Because an IPv4 datagram can contain a variable number of options (which are

included in the IPv4 datagram header), these 4 bits are needed to determine where in

the IP datagram the data actually begins.

Dr. T V Rama krishna Page 3

  Most IP datagrams do not contain options, so the typical IP datagram has a 20-byte

header.

• Type of service.

 The type of service (TOS) bits were included in the IPv4 header to allow different types

of IP datagrams (for example, datagrams particularly requiring low delay, high

throughput, or reliability) to be distinguished from each other.

 For example, it might be useful to distinguish real-time datagrams (such as those used

by an IP telephony application) from non-real-time traffic (for example, FTP).

 The specific level of service to be provided is a policy issue determined by the router’s

administrator

• Datagram length.

 This is the total length of the IP datagram (header plus data), measured in bytes.

 Since this field is 16 bits long, the theoretical maximum size of the IP datagram is

65,535 bytes.

 However, datagrams are rarely larger than 1,500 bytes.

• Identifier, flags, fragmentation offset.

 These three fields have to do with so-called

 IP fragmentation, a topic we will consider in depth shortly.

 Interestingly, the new version of IP, IPv6, does not allow for fragmentation at routers.

• Time-to-live.

 The time-to-live (TTL) field is included to ensure that datagrams do not circulate

forever (due to, for example, a long-lived routing loop) in the network.

Dr. T V Rama krishna Page 4

  This field is decremented by one each time the datagram is processed by a router.

 If the TTL field reaches 0, the datagram must be dropped.

• Protocol.

 This field is used only when an IP datagram reaches its final destination.

 The value of this field indicates the specific transport-layer protocol to which the data

portion of this IP datagram should be passed.

 For example, a value of 6 indicates that the data portion is passed to TCP, while a

value of 17 indicates that the data is passed to UDP.

 Note that the protocol number in the IP datagram has a role that is analogous to the

role of the port number field in the transportlayer segment.

 The protocol number is the glue that binds the network and transport layers together,

whereas the port number is the glue that binds the transport and application layers

together.

 The link-layer frame also has a special field that binds the link layer to the network

layer.

• Header checksum.

 The header checksum aids a router in detecting bit errors in a received IP datagram.

 The header checksum is computed by treating each 2 bytes in the header as a number

and summing these numbers using 1s complement arithmetic.

 The 1s complement of this sum, known as the Internet checksum, is stored in the

checksum field.

Dr. T V Rama krishna Page 5

  A router computes the header checksum for each received IP datagram and detects an

error condition if the checksum carried in the datagram header does not equal the

computed checksum.

 Routers typically discard datagrams for which an error has been detected.

 Note that the checksum must be recomputed and stored again at each router, as the

TTL field, and possibly the options field as well, may change.

 An interesting discussion of fast algorithms for computing the Internet checksum is

[RFC 1071].

 A question often asked at this point is, why does TCP/IP perform error checking at

both the transport and network layers? There are several reasons for this repetition.

 First, note that only the IP header is checksummed at the IP layer, while the TCP/UDP

checksum is computed over the entire TCP/UDP segment.

 Second, TCP/UDP and IP do not necessarily both have to belong to the same protocol

stack.

 TCP can, in principle, run over a different protocol (for example, ATM) and IP can carry

data that will not be passed to TCP/UDP.

• Source and destination IP addresses.

 When a source creates a datagram, it inserts its IP address into the source IP address

field and inserts the address of the ultimate destination into the destination IP

address field.

 Often the source host determines the destination address via a DNS lookup.

Dr. T V Rama krishna Page 6

 • Options.

 The options fields allow an IP header to be extended.

 Header options were meant to be used rarely—hence the decision to save overhead

by not including the information in options fields in every datagram header.

 However, the mere existence of options does complicate matters—since datagram

headers can be of variable length, one cannot determine a priori where the data field

will start.

 Also, since some datagrams may require options processing and others may not, the

amount of time needed to process an IP datagram at a router can vary greatly.

 These considerations become particularly important for IP processing in high-

performance routers and hosts.

 For these reasons and others, IP options were dropped in the IPv6 header.

• Data (payload).

 Finally, we come to the last and most important field—the raison d’être for the

datagram in the first place! In most circumstances, the data field of the IP datagram

contains the transport-layer segment (TCP or UDP) to be delivered to the destination.

 However, the data field can carry other types of data, such as ICMP messages

IP Datagram Fragmentation

 Some protocols can carry big datagrams, whereas other protocols can carry only little

packets.

 For example, Ethernet frames can carry up to 1,500 bytes of data, whereas frames for

some wide-area links can carry no more than 576 bytes.

Dr. T V Rama krishna Page 7

  The maximum amount of data that a link-layer frame can carry is called the maximum

transmission unit (MTU).

 Because each IP datagram is encapsulated within the link-layer frame for transport

from one router to the next router, the MTU of the link-layer protocol places a hard

limit on the length of an IP datagram.

 Having a hard limit on the size of an IP datagram is not much of a problem.

 What is a problem is that each of the links along the route between sender and

destination can use different link-layer protocols, and each of these protocols can

have different MTUs.

 To understand the forwarding issue better, imagine that you are a router that

interconnects several links, each running different link-layer protocols with different

MTUs.

 Suppose you receive an IP datagram from one link.

 You check your forwarding table to determine the outgoing link, and this outgoing link

has an MTU that is smaller than the length of the IP datagram.

 Time to panic—how are you going to squeeze this oversized IP datagram into the

payload field of the link-layer frame?

 The solution is to fragment the data in the IP datagram into two or more smaller IP

datagrams, encapsulate each of these smaller IP datagrams in a separate link-layer

frame; and send these frames over the outgoing link.

 Each of these smaller datagrams is referred to as a fragment.

Dr. T V Rama krishna Page 8

  Fragments need to be reassembled before they reach the transport layer at the

destination.

 Indeed, both TCP and UDP are expecting to receive complete, unfragmented segments

from the network layer.

 The designers of IPv4 felt that reassembling datagrams in the routers would introduce

significant complication into the protocol and put a damper on router performance.

 (If you were a router, would you want to be reassembling fragments on top of

everything else you had to do?) Sticking to the principle of keeping the network core

simple, the designers of IPv4 decided to put the job of datagram reassembly in the end

systems rather than in network routers.

 When a destination host receives a series of datagrams from the same source, it needs

to determine whether any of these datagrams are fragments of some original, larger

datagram.

 If some datagrams are fragments, it must further determine when it has received the

last fragment and how the fragments it has received should be pieced back together

to form the original datagram.

 To allow the destination host to perform these reassembly tasks, the designers of IP

(version 4) put identification, flag, and fragmentation offset fields in the IP datagram

header.

 When a datagram is created, the sending host stamps the datagram with an

identification number as well as source and destination addresses.

Dr. T V Rama krishna Page 9

  Typically, the sending host increments the identification number for each datagram it

sends.

 When a router needs to fragment a datagram, each resulting datagram (that is,

fragment) is stamped with the source address, destination address, and identification

number of the original datagram.

 When the destination receives a series of datagrams from the same sending host, it

can examine the identification numbers of the datagrams to determine which of the

datagrams are actually fragments of the same larger datagram.

 Because IP is an unreliable service, one or more of the fragments may never arrive at

the destination.

 For this reason, in order for the destination host to be absolutely sure it has received

 the last fragment of the original datagram, the last fragment has a flag bit set to 0,

 whereas all the other fragments have this flag bit set to 1.

 Also, in order for the destination host to determine whether a fragment is missing

(and also to be able to reassemble the fragments in their proper order), the offset

field is used to specify where the fragment fits within the original IP datagram.

 Figure 4.14 illustrates an example.

 A datagram of 4,000 bytes (20 bytes of IP header plus 3,980 bytes of IP payload)

arrives at a router and must be forwarded to a link with an MTU of 1,500 bytes.

 This implies that the 3,980 data bytes in the original datagram must be allocated to

three separate fragments (each of which is also an IP datagram).

 Suppose that the original datagram is stamped with an identification number of 777.

Dr. T V Rama krishna Page 10

  The characteristics of the three fragments are shown in Table 4.2.

Dr. T V Rama krishna Page 11

  The values in Table 4.2 reflect the requirement that the amount of original payload

data in all but the last fragment be a multiple of 8 bytes, and that the offset value be

specified in units of 8-byte chunks.

 At the destination, the payload of the datagram is passed to the transport layer only

after the IP layer has fully reconstructed the original IP datagram.

 If one or more of the fragments does not arrive at the destination, the incomplete

datagram is discarded and not passed to the transport layer.

 We have just learned that IP fragmentation plays an important role in gluing together

the many disparate link-layer technologies.

 But fragmentation also has its costs.

 First, it complicates routers and end systems, which need to be designed to

accommodate datagram fragmentation and reassembly.

 Second, fragmentation can be used to create lethal DoS attacks, whereby the attacker

sends a series of bizarre and unexpected fragments.

 A classic example is the Jolt2 attack, where the attacker sends a stream of small

fragments to the target host, none of which has an offset of

 zero.

 The target can collapse as it attempts to rebuild datagrams out of the degenerate

packets.

 Another class of exploits sends overlapping IP fragments, that is, fragments whose

offset values are set so that the fragments do not align properly.

 Vulnerable operating systems, not knowing what to do with overlapping fragments,

Dr. T V Rama krishna Page 12

  As we’ll see at the end of this section, a new version of the IP protocol, IPv6, does

away with fragmentation altogether, thereby streamlining IP packet processing and

making IP less vulnerable to attack.

Dr. T V Rama krishna Page 13