Réseaux d’entreprises

Chapitre III:

La Suite Protocolaire IP

Ecole Supérieur d’Economie Numérique

Dr. Amine DHRAIEF

A.U 2014-2015

Réseaux d'entreprises

Introduction

•

IP is the workhorse protocol of the TCP/IP protocol suite.

– All TCP, UDP and ICMP data gets transmitted as IP datagrams.

IP provides a (i) best-effort, (ii) connectionless (iii) datagram

delivery service.

• By “best-effort” we mean there are no guarantees that an IP

datagram gets to its destination successfully.

– Although IP does not simply drop all traffic unnecessarily, it provides

no guarantees as to the fate of the packets it attempts to deliver.

– When something goes wrong, such as a router temporarily running

out of buffers, IP has a simple error-handling algorithm: throw away

some data (usually the last datagram that arrived).

– Any required reliability must be provided by the upper layers (e.g.,

TCP). IPv4 and IPv6 both use this basic best-effort delivery model.

Introduction

• The term connectionless means that IP does not maintain any

connection stat information about related datagrams within the

network elements (i.e., within the routers); each datagram is

handled independently from all other others.

• This also means that IP datagrams can be delivered out of order. If

a source sends two consecutive datagrams (first A, then B) to the

same destination, each is routed independently and can take

different paths, and B may arrive before A.

• Other things can happen to IP datagrams as well: they may be

duplicated in transit, and they may have their data altered as the

result of errors. Again, some protocol above IP (usually TCP) has to

handle all of these potential problems in order to provide an

error-free delivery abstraction for applications

Introduction

• The IP protocol provides four main functions:

1. Basic unit for data transfer,

2. Addressing,

3. Routing, and

4. Fragmentation of datagrams.

Connectionless, Best–Effort Delivery Service

•

IP encapsulates data handed to it from its upper–layer

software with its headers.

IP delivers data based on a best effort.

• Transmits an encapsulated packet and does not expect a

response.

•

IP receives data handed to it by the datalink.

• Decapsulates a packet (strips its headers off) and hands

the data to its upper–layer software.

Encapsulation

IPv4 Header

• The normal size of the IPv4 header is 20 bytes, unless options are

present (which is rare).

•

In our pictures of headers and datagrams, 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 0–7 first, then bits 8–15, then 16–23, and bits 24–31 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 Header

Version

• The first field (only 4 bits or one nibble wide) is

the Version field. It contains the version number

of the IP datagram: 4 for IPv4 and 6 for IPv6.

– The headers for both IPv4 and IPv6 share the

location of the Version field but no others.

– Thus, the two protocols are not directly

interoperable—a host or router must handle either

IPv4 or IPv6 (or both, called dual stack) separately.

– Although other versions of IP have been proposed

and developed, only versions 4 and 6 have any

significant amount of use.

IPv4 Header

Version

• Version

– Version number of IP protocol

– Current version is Version 4

– Version 6 has different header format

IPv4 Header

Internet Header Length (IHL)

• The Internet Header Length (IHL) field is the

number of 32-bit words in the IPv4 header,

including any options.

– Because this is also a 4-bit field, the IPv4 header is

limited to a maximum of fifteen (15 =1111) 32-bit

words or 60 bytes.

– Later we shall see how this limitation makes some of

the options, such as the Record Route option, nearly

useless today.

– The normal value of this field (when no options are

present) is 5.

IPv4 Header

Internet Header Length (IHL)

• Header Length (in 32 bit words)

– Indicates end of header and beginning of payload

– If no options, Header length = 5

IPv4 Header

Type of Service (TOS)

• Following the header length, the original specification of

IPv4 [RFC0791] specified a Type of Service (ToS) byte.

– Use of these never became widespread, so eventually this 8-

bit field was split into two smaller parts and redefined by a set

of RFCs ([RFC3260] [RFC3168][RFC2474] and others).

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

– These RFCs now apply to both IPv4 and IPv6.

– These fields are used for special processing of the datagram

when it is forwarded.

IPv4 Header

Type of Service (TOS)

• Type of Service (TOS)

– Allows different types of service to be requested

– Initially, meaning was not well defined

– Currently being defined (diffserv)

IPv4 Header

Packet Length (in Bytes)

• 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 in the header

because some lower-layer protocols that carry

IPv4 datagrams do not (accurately) convey the

size of encapsulated datagrams on their own.

IPv4 Header

Packet Length (in Bytes)

• Packet Length (in Bytes)

– Unambiguously specify end of packet

– Max packet size = 216 = 65,535 Bytes

IPv4 Header

• Although it is possible to send a 65,535-byte IP datagram, most

link layers (such as Ethernet) are not able to carry one this large

without fragmenting it into smaller pieces.

• Furthermore, a host is not required to be able to receive an IPv4

datagram larger than 576 bytes.

– Many applications that use the UDP protocol for data transport (e.g.,

DNS, DHCP, etc.) use a limited data size of 512 bytes to avoid the 576-

byte IPv4 limit.

– TCP chooses its own datagram size based on additional information

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

IPv4 Header

• The Identification field helps indentify 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

IPv4 Header

• These three fields for Fragmentation Control

(will come back to them later)

IPv4 Header

Time to Live

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

– This prevents packets from getting caught in the network

forever should an unwanted routing loop occur

IPv4 Header

Time to Live

• Time to Live

– Initially set by sender (up to 255)

– Decremented by each router

– Discard when TTL = 0 to avoid infinite routing loops

IPv4 Header

Protocol

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

IPv4 Header

Protocol

• Protocol

– Value indicates what is in the data field

– Example: TCP or UDP

IPv4 Header

Header Checksum

• The Header Checksum field is calculated over the IPv4 header

only.

– This is important to understand because 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 data-integrity-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”).

– Note that when an IPv4 datagram passes through a router, its header

checksum must change as a result of decrementing the TTL field

IPv4 Header

Header Checksum

• Header Checksum

– Checks for error in the header only

– Bad headers can harm the network

– If error found, packet is simply discarded

IPv4 Header

Header Checksum

• Soit P(X) le polynôme associé à la séquence

de bits à protéger.

• Soit g(x) le polynôme générateur de degré k

• Les calculs sont faits dans le corps Z/2Z

– 1+1=0; X+X=0; X=-X

Les codes polynômiaux

Procédure de codage

• On calcule P’(X) = P(X).Xk

– Ceci équivaut à un décalage de P(X), de k positions

vers la gauche.

• On divise P’(X) par g(x).

– P’(X)=Q(X).g(X)+R(X)

• Le message envoyé est : P’(X) +R(X)

– P’(X)+R(X) = Q(X).g(X) est multiple de g(X)

IPv4 Header

Header Checksum

• Soit M(X) le message reçu.

– On divise M(X) par g(X)

• Si le reste de division est non nul alors

– détection d’une erreur.

• Sinon (reste de division nul)

– il y a une forte probabilité que la transmission est

correcte

IPv4 Header

Header Checksum Example

• Soit la séquence 1101 à envoyer

– g(x) = x3+x+1

– P(x)=x3+x2+1

• P ’(x)=P(x).x3=x6+x5+x3

• R(X) =1

• Message envoyé: P’(X) + R(X) = 1101001

IPv4 Header

Header Checksum Example

X3 +X2

+X +1

=R(X)

IPv4 Header

Header Checksum

• La qualité de la protection dépend du choix du

polynôme générateur g(x)

• g(x) comporte au moins 2 termes alors les erreurs

simples sont détectables

• g(x) a un facteur irréductible de trois termes alors les

erreurs doubles sont détectables

• g(x) est multiple de x+1 alors les erreurs en nombre

impair sont détectables

Application

• on désire protéger le message «110111» par

une clé calculée à l’aide du polynôme

générateur x2 + x + 1.

• Donner la séquence de bit à envoyer ?

Correction

• Au message 110111, on fait correspondre le

polynôme : x5 + x4 + 0x3 + x2 + x1 + x0

• Pour permettre l’addition de la clé au message, on

multiplie le polynôme représentatif du message par

xm où m est le degré du polynôme générateur. Le

dividende devient:

Correction

• Le message envoyé est : P’(X) +R(X)

– P’(X)+R(X) = Q(X).g(X) est multiple de g(X)

• P’(x) + R(x) = 11011111

IPv4 Header

Source and Destination IP Addresses

• 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 violate this rule.

IPv4 Header

Source and Destination IP Addresses

• Source and Destination IP Addresses

– Strings of 32 ones and zeros

DS Field and ECN (Formerly Called the ToS Byte)

•

The third and fourth fields of the IPv4 header are the Differentiated

Services (called DS Field) and ECN fields.

• 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 (possibly with associated special fees imposed by an

ISP).

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

DS Field and ECN (Formerly Called the ToS Byte)

• The pair of ECN bits in the header is used for marking

a datagram with a congestion indicator when passing

through a router that has a significant amount of

internally queued traffic.

– Both bits are set by persistently congested ECN-aware

routers when forwarding packets.

• The use case envisioned for this function is that when

a marked packet is received at the destination, some

protocol (such as TCP) will notice that the packet is

marked and indicate this fact back to the sender,

which would then slow down, thereby easing

congestion before a router is forced to drop traffic

because of overload.

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.

• As a consequence, 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.

IP Options

• Options

– Example: timestamp, record route, source route

IP Fragmentation & Reassembly

• Different media allows for different–sized datagrams to be

transmitted and received.

• Fragmentation allows a datagram that is too large to be

forwarded to the next LAN segment to be broken up into

smaller segments to be reassembled at the destination.

• The fragmentation occurs at the router that cannot

forward it to the next interface.

• Applications should use path MTU discovery to find the

smallest datagram size.

• Do not depend on the router

IP Fragmentation & Reassembly

• Maximum Transmission Unit (MTU)

– Largest IP packet a network will accept

– Arriving IP packet may be larger (max IP packet size = 65,535

bytes)

– Sender or router will split the packet into multiple fragments

• Destination will reassemble the packet

•

IP header fields used to identify and order related

fragments

IP Fragmentation & Reassembly

• Each fragment has IP datagram header

• Header fields

– Identify original datagram

– Indicate where fragment fits

IP Fragmentation & Reassembly

• Identification

– All fragments of a single datagram have the same

identification number

IP Fragmentation & Reassembly

• Flags:

– 1st bit: reserved, must be zero

– 2nd bit: DF -- Do Not Fragment

– 3rd bit: MF -- More Fragments

IP Fragmentation & Reassembly

• Fragment Offset (in units of 8 bytes)

– Used for reassembly of packet

– 1st fragment has offset = 0

IP Fragmentation Example

• Host A wants to send to Host B an IP datagram

of size = 4000 Bytes

IP Fragmentation Example

Fragment Loss

• Receiver

– Collects incoming fragments

– Reassembles when all fragments arrive

– Does not know identity of router that did

fragmentation

– Cannot request missing pieces

• Consequence: Loss of one fragment means

entire datagram lost

ICMP : Internet Control Message Protocol

Basic Ideas

• ICMP is provided within IP which generates

error messages to help IP layers(best effort

delivery)

• Function of ICMP

– a node recognizing a transmission problem (TTL

exceed, destination unreachable, etc.)

generates ICMP messages

– ICMP provides some useful diagnostics about

network operation (ping, traceroute)

Basic Ideas

• For example, every device (such as an

intermediate router) forwarding an IP

datagram first decrements the time to live

(TTL) field in the IP header by one.

• If the resulting TTL is 0, the packet is

discarded and an ICMP Time To Live exceeded

in transit message is sent to the datagram's

source address.

ICMP Encapsulation

Indicate error problems

Contain protocol

indicate ICMP

Type

Code

…….

IP header

IP Data

Frame header

e.g. Ethernet

Frame Data

Overview

• The Internet Control Message Protocol (ICMP) is a

helper protocol that supports IP with facility for

– Error reporting

– Simple queries

• ICMP messages are encapsulated as IP datagrams:

ICMP message format

bit # 0

type

code

checksum

additional information

0x00000000

4 byte header:

• Type (1 byte): type of ICMP message

• Code (1 byte): subtype of ICMP message

• Checksum (2 bytes): similar to IP header checksum. Checksum is calculated

over entire ICMP message

If there is no additional data, there are 4 bytes set to zero.

 each ICMP messages is at least 8 bytes long

ICMP Header

• The ICMP header starts after the IPv4 header

and is identified by protocol number '1'.

• All ICMP packets will have an 8-byte header and

variable-sized data section.

• The first 4 bytes of the header will be consistent.

– The first byte is for the ICMP type.

– The second byte is for the ICMP code.

– The third and fourth bytes are a checksum of the

entire ICMP message.

ICMP Header

• The contents of the remaining 4 bytes of the

header will vary based on the ICMP type and

code.

• ICMP error messages contain a data section

that includes the entire IP header plus the

first 8 bytes of data from the IP packet that

caused the error message. The ICMP packet is

then encapsulated in a new IP packet

ICMP Query message

ICMP Request

ICMP Reply

Host

Host or router

ICMP query:

• Request sent by host to a router or host

• Reply sent back to querying host

Example of a Query:

Echo Request and Reply

• Ping’s are handled directly by the kernel

• Each Ping is translated into an ICMP Echo

Request

• The Ping’ed host responds with an ICMP Echo

Host

Router

Host

router

ICMP Error message

IP datagram

ICMP Error

Message

IP datagram

is discarded

Host

Host or router

ICMP error messages report error conditions

•

• Typically sent when a datagram is discarded

• Error message is often passed from ICMP to the application program

Example: ICMP Port Unreachable

• If, in the destination host, the IP module cannot deliver the

datagram because the indicated protocol module or process

port is not active, the destination host may send a

destination unreachable message to the source host.

• Scenario:

Client

Server

No process

is waiting

at port 80

ICMP Error message

ICMP Message

from IP datagram that triggered the error

IP header

ICMP header

IP header

8 bytes of payload

type

code

checksum

Unused (0x00000000)

•

ICMP error messages include the complete IP header and the first 8 bytes of

the payload (typically: UDP, TCP)

Frequent ICMP Error message

Type Code

Description

0–15 Destination

unreachable

0–3 Redirect

0, 1 Time

exceeded

0, 1 Parameter

problem

Notification that an IP datagram could not

be forwarded and was dropped. The code

field contains an explanation.

Informs about an alternative route for the

datagram and should result in a routing

table update. The code field explains the

reason for the route change.

Sent when the TTL field has reached zero

(Code 0) or when there is a timeout for the

reassembly of segments (Code 1)

Sent when the IP header is invalid (Code 0)

or when an IP header option is missing

(Code 1)

Some subtypes of the “Destination Unreachable”

Code

Description

Reason for Sending

Network

Unreachable

Host

Unreachable

Protocol

Unreachable

Port

Unreachable

Fragmentation

Needed

and DF Bit Set

No routing table entry is available for the

destination network.

Destination host should be directly reachable, but

does not respond to ARP Requests.

The protocol in the protocol field of the IP header

is not supported at the destination.

The transport protocol at the destination host

cannot pass the datagram to an application.

IP datagram must be fragmented, but the DF bit in

the IP header is set.

ICMP type 0/8 echo request/reply

• PING sends icmp type 8 echo request to a

node and expects an icmp type 0 echo reply

• identifier and sequence number are used to

identify datagrams

Type = 0 or 8

code

checksum

identifier

Sequence number

Optional data

ICMP type 3 Destination Unreachable

• Router is unable to deliver datagram, it can

return the ICMP type 3 with failure code

• Internet header plus 64 bits of original

datagram are used to identify the datagram

caused the problem

Type = 3

code

checksum

unused

IP header + 64 bits of original data

ICMP type 4 Source Quench

• Router detected hosts were overload would send this

message to hosts that were the major cause

• The host would then reduce the rate at which

subsequence message are sent

• RFC recommends that router must not generate source

quench, host must still accept the message but need take

no action

Type = 4

code

checksum

Unused (must be 0)

IP header + 64 bits of original data

ICMP type 5 Route Change Request

• Used only by router to suggest a more

suitable route to the originator (also

called ICMP redirect)

Type = 5

code

checksum

IP address of a more suitable router

IP header + 64 bits of original data

PING : ICMP Echo Request/Reply

• PING sends and ICMP echo request to a

remote host, which then return an ICMP

echo reply to the sender

• All TCP/IP node is supposed to implement

ICMP and respond to ICMP echo

PING

PING Command

• Send a single echo request message and wait for a reply

• Another request is sent if the reply is not received within one

second

• Continue until at least one reply is received or stop after time

out

> ping maliwan

maliwan.psu.ac.th is alive

If maliwan down

>ping maliwan

no answer from maliwan.psu.ac.th

PING Command

• Send an echo request message every

seconds and records the time it takes for

each reply

• every echo request contains a unique

sequence number to match reply and

request

• also record round-trip timing

• also do packet lost statistics

PING Example

C:\>ping maliwan.psu.ac.th

Pinging maliwan.psu.ac.th [192.168.100.4] with 32 bytes of data:

Reply from 192.168.100.4: bytes=32 time=3ms TTL=32

Reply from 192.168.100.4: bytes=32 time=4ms TTL=32

Ping statistics for 192.168.100.4:

Approximate round trip times in milli-seconds:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Minimum = 3ms, Maximum = 4ms, Average = 3ms

C:\>_

What we get from PING?

• Timing information

• Connection reliability

• Destination Unreachable (routable)

PING Results

• no respond

no end node, no connection

•

lost packet (significant when > 2-3 %)

transmission error on LAN/WAN, overloading bridge or router

time acknowledge vary

host/network overloading > 100 ms make telnet less

acceptable

• no lost and echo time is reasonably constant

Traceroute Command

• Command to determine the active route to a destination

address

• How?

– Send a UDP message to an unused port on the target

host with ttl = 1

– router decrease ttl to 0, it has to return an ICMP time

exceed massage

– traceroute set ttl = 2 and retransmits, this time go one

more hop

– ttl++ until UDP reach the destination

– the target returns an ICMP service unreachable

because there is no UDP port service

Traceroute Example

C:\>tracert www.psu.ac.th

Tracing route to s1.psu.ac.th [192.168.100.61]

over a maximum of 30 hops:

1 1 ms 1 ms 1 ms cs-gw.cs.psu.ac.th [172.28.80.1]

2 2 ms 2 ms 1 ms esw-cc.psu.ac.th [192.168.99.39]

3 2 ms 3 ms 5 ms cc-atm.psu.ac.th [192.168.0.249]

4 4 ms 2 ms 3 ms tooky.psu.ac.th [192.168.98.11]

5 3 ms 3 ms 3 ms s1.psu.ac.th [192.168.100.61]

Trace complete.

C:\>

• usually probes each hop 3 times

• a lost message or a router that doesn’t respond with

denote with an “ * “

THE END

Réseaux d'entreprises