Réseaux d entreprises

Transcription

1 Réseaux d entreprises Chapitre III: La Suite Protocolaire IP Ecole Supérieur d Economie Numérique Dr. Amine DHRAIEF A.U Réseaux d'entreprises 1

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

3 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 3

4 Introduction The IP protocol provides four main functions: 1. Basic unit for data transfer, 2. Addressing, 3. Routing, and 4. Fragmentation of datagrams. 4

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

6 Encapsulation 6

7 IPv4 Header 7

8 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 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 8

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

10 IPv4 Header Version Version Version number of IP protocol Current version is Version 4 Version 6 has different header format 10

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

12 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 12

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

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

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

16 IPv4 Header Packet Length (in Bytes) Packet Length (in Bytes) Unambiguously specify end of packet Max packet size = 2 16 = 65,535 Bytes 16

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

18 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 18

19 IPv4 Header These three fields for Fragmentation Control (will come back to them later) 19

20 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 20

21 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 21

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

23 IPv4 Header Protocol Protocol Value indicates what is in the data field Example: TCP or UDP 23

24 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 24

25 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 25

26 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 26

27 Les codes polynômiaux Procédure de codage On calcule P (X) = P(X).X k 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) 27

28 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 28

29 IPv4 Header Header Checksum Example Soit la séquence 1101 à envoyer g(x) = x 3 +x+1 P(x)=x 3 +x 2 +1 P (x)=p(x).x 3 =x 6 +x 5 +x 3 R(X) =1 Message envoyé: P (X) + R(X) =

30 IPv4 Header Header Checksum Example X 6 X 5 X 3 X 3 X 1 X 6 X 4 X 3 X 3 +X 2 +X +1 X 5 X 4 X 5 X 3 X 2 X 4 X 3 X 2 X 4 X 2 X X 3 X X 3 X 1 1 =R(X) 30

31 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 31

32 Application on désire protéger le message «110111» par une clé calculée à l aide du polynôme générateur x 2 + x + 1. Donner la séquence de bit à envoyer? 32

33 Correction Au message , on fait correspondre le polynôme : x 5 + x 4 + 0x 3 + x 2 + x 1 + x 0 Pour permettre l addition de la clé au message, on multiplie le polynôme représentatif du message par x m où m est le degré du polynôme générateur. Le dividende devient: 33

34 Correction 34

35 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) =

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

37 IPv4 Header Source and Destination IP Addresses Source and Destination IP Addresses Strings of 32 ones and zeros 37

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

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

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

41 IP Options Options Example: timestamp, record route, source route 41

42 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 42

43 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 43

44 IP Fragmentation & Reassembly Each fragment has IP datagram header Header fields Identify original datagram Indicate where fragment fits 44

45 IP Fragmentation & Reassembly Identification All fragments of a single datagram have the same identification number 45

46 IP Fragmentation & Reassembly Flags: 1st bit: reserved, must be zero 2nd bit: DF -- Do Not Fragment 3rd bit: MF -- More Fragments 46

47 IP Fragmentation & Reassembly Fragment Offset (in units of 8 bytes) Used for reassembly of packet 1st fragment has offset = 0 47

48 IP Fragmentation Example Host A wants to send to Host B an IP datagram of size = 4000 Bytes 48

49 IP Fragmentation Example 49

50 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 50

51 ICMP : Internet Control Message Protocol 51

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

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

54 ICMP Encapsulation Indicate error problems Contain protocol indicate ICMP Type Code. IP header IP Data Frame header e.g. Ethernet Frame Data 54

55 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: 55

56 ICMP message format bit # type code checksum additional information or 0x 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 56

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

58 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 58

59 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 59

60 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 Reply Host or Router Host or router 60

61 ICMP Error message IP datagram IP datagram is discarded ICMP Error Message 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 61

62 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 62

63 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 (0x ) ICMP error messages include the complete IP header and the first 8 bytes of the payload (typically: UDP, TCP) 63

64 Frequent ICMP Error message Type Code Description Destination unreachable Notification that an IP datagram could not be forwarded and was dropped. The code field contains an explanation Redirect 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. 11 0, 1 Time exceeded 12 0, 1 Parameter problem 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) 64

65 Some subtypes of the Destination Unreachable Code Description Reason for Sending 0 Network Unreachable 1 Host Unreachable 2 Protocol Unreachable 3 Port Unreachable 4 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. 65

66 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 66

67 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 67

68 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 68

69 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 69

70 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 Reply 70

71 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 71

72 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 72

73 PING Example C:\>ping maliwan.psu.ac.th Pinging maliwan.psu.ac.th [ ] with 32 bytes of data: Reply from : bytes=32 time=3ms TTL=32 Reply from : bytes=32 time=3ms TTL=32 Reply from : bytes=32 time=3ms TTL=32 Reply from : bytes=32 time=4ms TTL=32 Ping statistics for : Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 4ms, Average = 3ms C:\>_ 73

74 What we get from PING? Timing information Connection reliability Destination Unreachable (routable) 74

75 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 75

76 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 76

77 Traceroute Example C:\>tracert Tracing route to s1.psu.ac.th [ ] over a maximum of 30 hops: 1 1 ms 1 ms ms cs-gw.cs.psu.ac.th [ ] 2 ms 2 ms 1 ms esw-cc.psu.ac.th [ ] 3 2 ms 3 ms 5 ms cc-atm.psu.ac.th [ ] 4 4 ms 2 ms ms tooky.psu.ac.th [ ] 5 3 ms 3 ms 3 ms s1.psu.ac.th [ ] Trace complete. C:\> usually probes each hop 3 times a lost message or a router that doesn t respond with denote with an * 77

78 THE END Réseaux d'entreprises 78