TCP/IP illustrated Vol. 1 The Protocols. Introduction. Summary of Chapter. Layered structure. Network layer. Link layer

Transcription

1 TCP/IP illustrated Vol. 1 The Protocols Chapter 1 - Introduction Introduction Late 1960 s research project. IPv4 described in RFC-791 (1981) Today's most widely used network protocol Open system Definitions and free implementations available Base of worldwide Internet Introduction (c) Jouni Ikonen / Introduction (c) Jouni Ikonen / Summary of Chapter Layered structure Layered structure Internet addresses Domain Name System Encapsulation Demultiplexing Client server model Port numbers Introduction (c) Jouni Ikonen / TCP/IP is combination of different protocols at various layers. TCP is 4-layer system Application (Sovellus) Transport (Kuljetus) Network (Verkko) Link (Linkki) Telnet, FTP, , etc. TCP, UDP IP, ICMP, IGMP device driver and interface card Introduction (c) Jouni Ikonen / Link layer Device driver and network interface card handle hardware details of physically interfacing with the media Network layer Handles movement of packet around in the network Routing of packets IP (Internet Protocol) ICMP (Internet Control Message Protocol) IGMP (Internet Group Management Protocol) Introduction (c) Jouni Ikonen / Introduction (c) Jouni Ikonen / 1

2 Transport layer Provides flow of data between two hosts, for application layer above (TCP and UDP) TCP (Transmission Control Protocol) provides reliable data flow between two hosts. Dividing data to packets, acknowledging of packets, timeouts... UDP (User Datagram Protocol) sends datagrams from a host to another. No guarantees! Application layer Handles details of the particular application Telnet, FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), SNMP (Simple Network Management Protocol)... Introduction (c) Jouni Ikonen / Introduction (c) Jouni Ikonen / Two networks connected with a router User process TCP/IP layering User process User process User process Application FTP Client TCP FTP protocol TCP protocol FTP Server TCP TCP UDP Transport IP Ethernet driver Ethernet IP protocol Ethernet protocol IP Ethernet driver TR driver IP protocol Token Ring protocol Token Ring Introduction (c) Jouni Ikonen / IP Token ring driver ICMP ARP IP Hardware interface IGMP RARP Introduction (c) Jouni Ikonen / Media Network Link Internet addresses Internet addresses Every interface must have a unique Internet Address (IP address) 32-bit address, e.g, types of addresses Unicast Broadcast Multicast Class A Class B Class C Class D Class E bits 24 bits netid hostid bits 16 bits netid hostid 21 bits 8 bits netid hostid 28 bits multicast group ID 28 bits (reserved for future use) Introduction (c) Jouni Ikonen / Introduction (c) Jouni Ikonen / 2

3 Class A B C D E Internet addresses Range Multihomed host has multiple IP addresses (1/interface) Introduction (c) Jouni Ikonen / Private IP addresses The Internet Assigned Numbers Authority (IANA) has reserved the three blocks of the IP address space for private internets (local networks) The Internet Assigned Numbers Authority (IANA) has reserved private IP addresses in the range of for Automatic Private IP Addressing. Introduction (c) Jouni Ikonen / Domain name system A distributed database system that provides mapping between IP addresses and hostnames. Any application can call a standard library function to look up an IP address corresponding given hostname. Encapsulation Each layer adds its own header (and maybe a trailer) to user data which is send through network. User data + application header => TCP segment => IP datagram => Ethernet frame Introduction (c) Jouni Ikonen / Introduction (c) Jouni Ikonen / Demultiplexing When an Ethernet frame is received all the headers are removed in appropriate places. Each protocol looks at certain identifiers in its header to determine which protocol on next upper layer receives data. E.g. IP detect if packet should be given to UDP or TCP. User process ICMP ARP TCP User process IP Ethernet driver Demultiplexing UDP User process IGMP RARP User process demultiplexing based on destination port in TCP or UDP header demultiplexing based on protocol value in IP header demultiplexing based on frame type in Ethernet header Introduction (c) Jouni Ikonen / Incoming frame Introduction (c) Jouni Ikonen / 3

4 Client-server model Server provides some services for clients. Most applications follow this model. Two flavors: Iterative, wait for request, serve it, wait for a next Concurrent, serve multiple request at a time, may fork an own process for all requests Port numbers TCP and UDP identifies applications using 16-bit port numbers. Reserved ports Well known port numbers /etc/services Introduction (c) Jouni Ikonen / Introduction (c) Jouni Ikonen / Programming interfaces sockets (Berkeley sockets) TLI (Transport Layer Interface, also known as XTI) Internet standards Standards published as Request for Comments (RFCs). (All of them are NOT standards). ftp://ftp.funet.fi/rfc rfc-index.txt shows status of the standards: Standard, proposed standard, obsolete, experimental, informational, Internet Official Protocol Standards. May RFC5000 (Check that it is still valid!). ftp://ftp.funet.fi/rfc/rfc5000.txt Introduction (c) Jouni Ikonen / Introduction (c) Jouni Ikonen / Summary Link, Network, Transport and application layers Network layer provides hop-by-hop service (IP) Transport layer provides end-to-end service (UDP and TCP) Internet is a collection of networks DNS mapping between names and addresses Introduction (c) Jouni Ikonen / 4

5 TCP/IP illustrated Vol. 1 The Protocols Chapter 2 - Link Layer Link Layer Purpose for link layer is to send and receive IP datagrams for the IP module ARP requests and replies for the ARP module RARP requests and replies for the RARP module TCP/IP supports many different link layers, depending on the type of networking hardware being used : Ethernet, token ring, FDDI, RS-232 serial lines, and the like Link Layer - (c) Jouni Ikonen / Link Layer - (c) Jouni Ikonen / Ethernet and IEEE 802 Encapsulation Ethernet standard was published 1982 by Digital Equipment Corp., Intel Corp. and Xerox Corp. It defined communication with CSMA/CD (Carrier Sense, Multiple Access with Collision Detection) algorithm. Later IEEE published set of 802-standards (CSMA/CD), (Token Ring), 802 standards use same Logical Link Control (LLC) layer. Link Layer - (c) Jouni Ikonen / destination addr Ethernet Encapsulation (RFC 894) source addr bytes type data CRC type IP datagram type 0806 ARP request /reply 2 28 type 0835 RARP request /reply PAD 18 PAD Link Layer - (c) Jouni Ikonen / IEEE 802.2/802.3 Encapsulation (RFC1042) destination addr MAC LLC SNAP source addr length DSAP SSAP AA AA cntl 03 org code 00 Link Layer - (c) Jouni Ikonen / type data CRC SNAP Sub-Network Access Protocol DSAP Destination Service Access Point SSAP Source Serving Access Point type type type IP datagram ARP request /reply 28 RARP request /reply 28 PAD 10 PAD 10 Encapsulation Both frame formats use 48 bit destination and source addresses 802 length field says how many bytes follow, not including CRC Ethernet type field identifies the type of data that follows 802 type field is same as in Ethernet frames Ethernet Type and Length fields can be distinguish by the value and Ethernet frames have minimum size. Link Layer - (c) Jouni Ikonen / 1

6 Host requirements (RFC1042) CSMA/CD Carrier sense multiple access with collision detection Send frame Retransmission counter N = 0 Every Internet host connected to 10 Mbit/s Ethernet should MUST be able send and receive packets using RFC894 (Ethernet) encapsulation. Should be able to receive RFC 1042 (IEEE 802) packets intermixed with RFC 894 packets. May be able send packets using RFC 1042 encapsulation. Link Layer - (c) Jouni Ikonen / Packet ready? Yes Channel busy? No Transmit Collision detected? No Done Link Layer - (c) Jouni Ikonen / No Yes Transmit jamming signal Increase retransmission counter, N = N +1 Delay R * 51.2 micro seconds Select random integer between R = [0, 2 K ] K = N K = 10 Yes N<=10 No Yes N <15 No Abort Collision detection Serial Interfaces Point in minimum frame size is that sending host realizes that collision has happened during it s transmission. If packet is short the sender might not detect a collision and believe that transmission was successful. Link Layer - (c) Jouni Ikonen / There are two specialized link layers for serial interfaces: SLIP (Serial Line IP) PPP (Point to Point Protocol) CSLIP and PPP can reduce number of bytes/frame transmitted over the link! Many header fields do not change. PPP is more modern and correct many deficiencies of SLIP. Link Layer - (c) Jouni Ikonen / SLIP : Serial Line IP SLIP is simple form of encapsulation for IP datagrams on serial lines Rules for the framing in SLIP : IP datagram is terminated by the special character called END (0xc0) if byte in datagram equals the END character, the 2- byte sequence 0xdb, 0xdc is transmitted instead 0xdb is called SLIP ESC character if byte in datagram equals the ESC character, the 2-byte sequence 0xdb, 0xdd is transmitted instead Link Layer - (c) Jouni Ikonen / Deficiencies in SLIP Each end must know the others IP address. There is no method for one end to inform other of its IP address. There is not type field. If a serial line is used for SLIP, it can t be used for some other protocol at the same time. There is no checksum added by SLIP. Upper layers must detect corrupted messages. Link Layer - (c) Jouni Ikonen / 2

7 SLIP Encapsulation PPP : Point to Point Protocol END c0 1 IP datagram c0 db 1 1 ESC db dc 1 1 ESC db 1 dd 1 END c0 1 Three components A way to encapsulate IP datagrams asynchronous links with 8-bit data and no parity, or bit oriented synchronous links A link control protocol (LCP) to establish, configure, and test the data-link connection A family of network control protocols (NCPs) to differentiate network layer protocols. IP, OSI network layer, DECnet, AppleTalk Link Layer - (c) Jouni Ikonen / Link Layer - (c) Jouni Ikonen / Format of PPP frames PPP frame format flag 7E 1 addr FF 1 control 03 1 protocol 2 protocol protocol c021 2 protocol information up to 1500 bytes IP datagram link control data network control data Link Layer - (c) Jouni Ikonen / CRC 2 flag 7E 1 Begins and ends with flag byte (0x7e) If 0x7e appears in data, byte is transmitted as the 2-byte sequence 0x7d, 0x5e. This is the escape of the flag byte The byte 0x7d is transmitted as the 2-byte sequence 0x7d, 0x5d. This is the escape of the escape byte Link Layer - (c) Jouni Ikonen / Loopback Interface Allows client and server on the same host to communicate with each other using TCP/IP The class A network ID 127 is reserved for the loopback interface Link Layer - (c) Jouni Ikonen / place on IP input queue loopback driver Ethernet Processing of IP datagrams by loopback interface IP output function YES YES destination IP address equal broadcast address or multicast address? NO destination IP address equal interface IP address? no, use ARP to get destination Ethernet address ARP ARP send Link Layer - (c) Jouni Ikonen / IP input function place on IP input queue IP demultiplex based on Ethernet frame type receive Ethernet driver 3

8 Loopback key points Everything sent to the loopback address appears as IP input Datagrams sent to a broadcast address or a multicast address are copied to the loopback interface and sent out on the Ethernet. This is because the definition of broadcasting or multicasting includes the sending host Anything sent to one of the host s own IP MTU : Maximum Transmission Unit There is limit (MTU) on the size of the frame for both Ethernet encapsulation and encapsulation (1500 or 1492) IP performs fragmentation, breaking the datagram up into smaller pieces (fragments) so that every piece is smaller than the MTU Different types of networks have different sizes of MTUs address is sent to the loopback interface Link Layer - (c) Jouni Ikonen / Link Layer - (c) Jouni Ikonen / MTU When two hosts are communicating across multiple networks, each link can have a different MTU The smallest MTU between the two host is called the path MTU How about interaction? NETWORK MTU (bytes) Hyperchannel Mbits/sec token ring Mbits/sec token ring 4464 FDDI 4352 Ethernet 1500 IEEE 802.3/ X Point to point (low level) 296 Link Layer - (c) Jouni Ikonen / 4

9 TCP/IP illustrated Vol. 1 The Protocols Chapter 3 - IP: Internet Protocol IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. Introduction Internet Protocol is the workhorse of the TCP/IP Suite (i.e. all TCP, UDP, ICMP and IGMP packets gets transmitted as IP datagramms) Internet Protocol provides an unreliable, connectionless datagram delivery service best-effort, no guarantees, (-->ICMP), independent handling of datagramms, no ordering of datagrams IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. Summary of Chapter IP Header IP Routing Subnet Addressing Subnet Mask Special Case IP Addresses Ifconfig and Netstat commands IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. 20 bytes 0 4-bit version 4-bit header length IP Header 8-bit TOS 16 bit identification 8-bit TTL 8-bit protocol DATA 16-bit total length 3-bit flags Options (if any) 13-bit fragment offset 16-bit header checksum 32-bit source IP address 32-bit destination IP address 31(32bits) IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. As defined by RFC791 Network byte order IP header values 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 the 32-bit value are transmitted in the order: first bits 0-7, then 8-15, and Previous ordering is called big endian byte ordering, which is the byte ordering required for all binary integers in the TCP/IP headers as they traverse in a network. I.e. this is network byte order. Version: current dominant IP version is 4 (we are looking IPv4 headers!) Header length: number of 32-bit words in the header (including the options). Normal value is 5. TOS - type-of-service: Composed of 3 precedence bits (ignored) (RFC1340) 4 TOS bits (RFC1349) 1 unused bit (which must be zero) IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. 1

10 IP header: TOS TOS => Diffserv 4 TOS bits are for: Minimize delay Maximize throughput Maximize reliability Minimize monetary cost Only one of 4 bits can be turned on. TOS is not supported by all (or most) of TCP/IP implementations. Some routing protocols like OSPF and IS-IS are capable of making routing decisions based on TOS. IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. Differientiated services field RFC 2474 The Addition of Explicit Congestion Notification (ECN) RFC New Terminology and Clarifications for Diffserv. RFC 3260 Renaming of TOS field to DS field IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IP header: more fields Total length: Total length of IP datagram (=> max. IP datagram size is 2 16 ). Identification: uniquely identifies each datagram sent by a host. Normally incremented by one each time datagram is sent. Flags Do not fragment & more fragments TTL time-to-live: upper limit on number of routers which datagram can pass. Protocol: used for demultiplexing protocols What the heck is one s complement? IP header: checksum Header checksum is calculated over IP header. It does not include any data that follows the header. Sending host: Set checksum field to zero. Calculated as 16-bit one s complement sum of the header and places the result to the checksum field. Receiving end calculates the 16-bit one s complement sum of the header. If the result is a ones transmission is treated as successful. IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IP header: the options Options are rarely used and all hosts/routers do not support all the options. Options defined: Security and handling restrictions Record route Timestamp Loose source routing Strict source routing IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IP Routing As a concept : Simple, if the destination is directly connected to a host (P2P, shared network) then the datagram is sent directly to the destination. Otherwise the datagram is send to a default router. IP Layer has a routing table in memory that it searches each time it receives a datagram to send IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. 2

11 IP Routing IP Routing This routing table contains : destination IP address IP address of a next-hop router flags specification of a network interface IP Routing is done on a hop-by-hop basis, i.e it does not know the complete route, it just does know the next hop IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IP Routing performs actions like : Search through the routing table for an entry that matches the complete IP address (router, network interface) Search through the routing table for an entry that matches just the destination network IP address (router, network interface) Search through the routing table for an entry labeled default and sending the datagram to the next-hop IP: Internet Protocol router - (c) Jouni Ikonen / Lappeenranta univ. of Tech. Route command route or route print jumi:~> /sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface localnet * U eth0 default lty-gw.cc.lut.f UG eth0 destination network= bsdi sun Ethernet, Eth hdr IP hdr dest IP = dest Enet = Enet of Delivery of IP datagram from BSDI to SUN IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. Subnet Addressing IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. From bsdi to Internet [ TCP/IP Illustrated Vol. 1, Stevens, AW] A and B class networks have generally more host addresses available than they have hosts ( and ) In subnetting IP addresses host portion is divided into subnet ID and host ID. Class B 16 bit 8 bit 8 bit Netid = Subnet id IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. hostid 3

12 More on subnets All hosts are required to support subnetting (RFC950) Local administrator decides if subnetting is needed Subnetting efficiently reduces the size of routing tables as they are invisible to Internet routers. Subnet division does not have to be on byte boundary IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. [ TCP/IP Illustrated Vol. 1, Stevens, AW] IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. Subnet Mask A host must also know how many bits are used for the subnet ID and host ID This is specified using subnet mask, where 32-bit value contains network ID (1), subnet ID (1) and host ID (0) 16 bit 8 bit 8 bit Class B netid subnetid hostid mask = 0xFFFFFF IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. Subnet mask calculation 16 bit 10 bit 6 bit Class B netid subnetid hostid = 0xFFFFFFc B class IP address, 6 bits reserved for hosts in a subnet. How many hosts? Mathematics 1*2 7 +1*2 6 +0*2 5 +0*2 4 +0*2 3 +0*2 2 +0*2 1 +0*2 0 = 1*128+1*64+0*32+0*16+0*8+0*4+0*2+0*1=192=c0 IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. Subnet comparison example Assume that host address is and subnet mask is If destination address is is the host in the same (sub) network? How about ? (C class address)? Class B Subnet mask = Network IDs equal non equal subnet IDs Class B end of class B network ID end of specified subnet ID IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. Net ID Special Case IP Addresses IP address subnet ID host ID Can appear as Source? destin ation? Description 0 0 OK never this host in this network 0 host ID OK never spesified host in this network 127 anything OK OK loopback address -1-1 never OK limited broadcast (not forwarded) netid -1 never OK net-directed broadcast to netid netid subnetid -1 never OK net-directed broadcast to netid, subnetid netid -1-1 never OK all-subnets-directed broadcast to netid 0 means all bitsip: zero Internet Protocol - (c) Jouni Ikonen / Lappeenranta -1 means univ. of Tech. all bits ones 4

13 Special IP addresses Source address network id 0 can appear only when host is booting up and determining it s IP address. Ifconfig & Netstat Ipconfig and Ifconfig is used to configure and query information of the devices Netstat gives information of devices attached to the networks (i.e addresses, MTU etc.) IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IPv6 New IP Address Space (defined by RFC 4291) New IP Architecture extendibility interoperability with version 4 through tunneling IPv6 IPv6 will use 128-bit addressing instead of 32-bit addressing used in version 4. Therefore IP-address will contain 8 parts instead of 4 and each part has 16-bit value ( ). Then maximum address space would be 4 millions power two. Example address of a host : 1080:0:0:0:8:800:200C:417A If one or more four-digit group is 0000, the zeros may be omitted and replaced with two colons(::) IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IPv6 IPv6 header IPv6 routers do not fragment IP packets Mobile IP Jumbograms optional support for 4 GB Tunneling used to connect IPv6 islands Unicast, multicast and anycast addresses DHCPv6 IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. 5

14 IPv6 Extra RFC 2460: Internet Protocol, Version 6 (IPv6) Specification (obsoletes RFC 1883) (updated by rfc5095) RFC 2461/RFC 4311: Neighbor Discovery for IP Version 6 (IPv6) 4862 (obsoletes RFC 2462): IPv6 Stateless Address Autoconfiguration RFC 4443: Internet Control Message Protocol (ICMPv6) for the IPv6 Specification (obsoletes RFC 2463) (Updated by 4884) RFC 2464: Transmission of IPv6 Packets over Ethernet Networks RFC 4291: Internet Protocol Version 6 (IPv6) Addressing Architecture (obsoletes RFC 3513) [ TCP/IP Illustrated Vol. 1, Stevens, AW] IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. IP: Internet Protocol - (c) Jouni Ikonen / Lappeenranta univ. of Tech. 6

15 TCP/IP illustrated Vol. 1 The Protocols User process TCP/IP layering User process User process User process Application (Sovellus) TCP UDP Transport (Kuljetus) Chapter 4 - ARP: Address Resolution Protocol Chapter 5 - RARP: Reverse Address Resolution Protocol ARP and RARP - (c) Jouni Ikonen / ICMP ARP IP Hardware interface IGMP RARP ARP and RARP - (c) Jouni Ikonen / Media Network (Verkko) Link (Linkki) ARP: Address Resolution Protocol IP addresses can be only used with TCP/IP suite. Data link has its own addressing (like Ethernet and Token Ring) ARP provides mapping between 32-bit IP address and whatever type of address the data link uses. ARP and RARP - (c) Jouni Ikonen / ARP & RARP 32-bit Internet address ARP RARP 48-bit Ethernet address ARP provides dynamic mapping between addresses. RARP (Reverse address resolution protocol) used normally in systems without a disk drive. ARP and RARP - (c) Jouni Ikonen / resolver ARP example ARP request (Ethernet broadcast) ARP Ethernet driver hostname IP address ARP ARP and RARP - (c) Jouni Ikonen / FTP TCP IP ARP Ethernet driver Ethernet driver IP TCP ftp host.lut.fi Establish connection with IP address Send IP datagram to IP address Example Application calls gethostbyname() to convert hostname into 32-bit IP address. Application asks TCP to establish a connection with that IP address. ARP sends an Ethernet frame called an ARP request to every host on the network. Request contains IP address of the destination host and request to respond with hardware address. ARP and RARP - (c) Jouni Ikonen / 1

16 Example (cont.) Destination host s ARP layer receives the broadcast and replies directly to the requesting host with ARP reply (contains host s IP & HW addresses). Now the IP datagram can be send. ARP packet format Ethernet header 28 byte ARP request /reply Ethernet destination address Ethernet source address frame type hard prot hard prot sender sender target target type type size size op Ethernet address IP addr Ethernet address IP addr ARP and RARP - (c) Jouni Ikonen / ARP and RARP - (c) Jouni Ikonen / ARP header fields Frame type specifies data which will follow (e.g. 0x0806 for ARP reply). Hard type specifies hardware type (1 for Ethernet). Prot type specifies the protocol being mapped (0x0800 for IP addresses). Size fields specify used address sizes (Ethernet address 6 bytes and IP 4 bytes). Op field specifies if operation is ARP request, ARP reply, RARP request or RARP reply. ARP cache Hosts maintain ARP caches for efficiency. Normal expiration time 20 minutes C:\>arp -a Interface: on Interface 0x Internet Address Physical Address Type c-ce-0a dynamic e-1c-4d-a2 dynamic f2-98-c1 dynamic ARP and RARP - (c) Jouni Ikonen / ARP and RARP - (c) Jouni Ikonen / Proxy ARP A router answers to ARP request in one of it networks for a host another of its networks. Router relays the packet send to it. Useful if e.g. device supports only 1 MAC address Called also promiscuous ARP and ARP hack ARP and RARP - (c) Jouni Ikonen / Proxy ARP example is at 00:0c:xx:xx:xx: is at 00:0c:xx:xx:xx:00 ARP and RARP - (c) Jouni Ikonen / who has who has

17 ARP live capture Gratuitous ARP Frame 24 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: 00:01:02:f2:98:c1, Dst: ff:ff:ff:ff:ff:ff Address Resolution Protocol (request) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (0x0001) Sender MAC address: 00:01:02:f2:98:c1 (3com_f2:98:c1) Sender IP address: ( ) Target MAC address: 00:00:00:00:00:00 (00:00:00_00:00:00) Target IP address: ( ) ARP and RARP - (c) Jouni Ikonen / Host send an ARP request looking for its own IP address. To detect somebody already using the same IP address. If host changed its hardware address it can update other hosts ARP caches by sending ARP request for its own IP address. ARP and RARP - (c) Jouni Ikonen / RARP: Reverse address resolution protocol Network device without local storage system needs a boot image and IP address also. Device can read it s unique MAC address and send RARP query to receive IP address. RARP packet almost identical ARP (type 0x8035). RARP reply is (normally) unicast RARP server RARP server is system dependent (and complex). It is realized as user process as it has to read and parse disk for IP addresses. It needs a way to receive and send RARP messages (skip transport layer) which is system dependent. RARP messages are not forwarded by the routers. Redundant servers can be needed. (How could collisions be avoided?) ARP and RARP - (c) Jouni Ikonen / ARP and RARP - (c) Jouni Ikonen / 3

18 TCP/IP illustrated Vol. 1 The Protocols Chapter 6 - ICMP: Internet Control Message Protocol ICMP Error messages Conditions that require attention Transmitted within IP datagrams IP datagram IP header ICMP message ICMP - (c) Jouni Ikonen / 20 bytes ICMP - (c) Jouni Ikonen / ICMP message 8-bit type 8-bit code 16-bit checksum (contents depends on type and code) More than 15 different types (Query/Error) codes to further specify the condition checksum covers the entire ICMP message ICMP - (c) Jouni Ikonen / ICMP message types (MT)- ECHO Type Name Reference 0 Echo Reply[RFC792] (Code 0 no code) 8 Echo [RFC792] (Code 0 no code) Also knows as PING sent by a host to test node reachability across a network. Pings are readily traceable using a Sniffer or Network Monitor by viewing ICMP Type 8 (request) and ICMP Type 0 (reply). ICMP - (c) Jouni Ikonen / ICMP - Destination Unreachable Type 3 - Destination Unreachable [RFC792] The destination specified in the datagram is unreachable, generating an ICMP type 3 response. Codes 0 Net Unreachable 1 Host Unreachable 2 Protocol Unreachable 3 Port Unreachable 4 Fragmentation Needed and Don't Fragment was Set 5 Source Route Failed 6 Destination Network Unknown 7 Destination Host Unknown ICMP - Destination Unreachable More codes 8 Source Host Isolated 9 Communication with Destination Network is Administratively Prohibited 10 Communication with Destination Host is Administratively Prohibited 11 Destination Network Unreachable for Type of Service 12 Destination Host Unreachable for Type of Service 13 Communication Administratively Prohibited [RFC1812] 14 Host Precedence Violation [RFC1812] 15 Precedence cutoff in effect [RFC1812] ICMP - (c) Jouni Ikonen / ICMP - (c) Jouni Ikonen / 1

19 Error message ICMP Port Unreachable Error Destination port is unreachable e.g. in FTP type (3) code (3) checksum Unused (must be 0) IP header (including options) + first 8 bytes of original IP datagramm data 8bytes ICMP Source Quench Type 4 [RFC792] Messages are an effort to request to the host to cut back the rate at which it is sending traffic to the Internet destination. The ICMP may be sent when a device does not have buffer space needed to queue the datagrams for output, or if datagrams are arriving too fast to be processed. Code 0 ICMP - (c) Jouni Ikonen / ICMP - (c) Jouni Ikonen / ICMP - Redirect ICMP Redirect example Type 5 [RFC792] Redirect is sent by a router to the source to stimulate more efficient routing, and is also accompanied by a code to further define the cause for the ICMP (network, service, or host). Redirect messages are often not allowed at edge routers to protect against hostile actions to redirect key traffic. Codes 0 Redirect Datagram for the Network (or subnet) 1 Redirect Datagram for the Host 2 Redirect Datagram for the Type of Service and Network 3 Redirect Datagram for the Type of Service and Host T R1 Route redirect S R2 Default router R2 ICMP - (c) Jouni Ikonen / ICMP - (c) Jouni Ikonen / Alternate Host Address Type 6 [Jon Postel, <[email protected]>, September ] Codes 0 Alternate Address for Host ICMP - (c) Jouni Ikonen / ICMP - Router Advertisement Type 9 [RFC1256] Codes 0 Normal router advertisement 16 Does not route common traffic [RFC2002] RFC1256 specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. ftp://ftp.funet.fi/rfc/rfc1256.txt ICMP - (c) Jouni Ikonen / 2

20 ICMP Router solicitation Type 10 [RFC1256] No codes ICMP Time exceeded Type 11 [RFC792] Codes 0 Time to Live exceeded in Transit 1 Fragment Reassembly Time Exceeded ICMP - (c) Jouni Ikonen / ICMP - (c) Jouni Ikonen / ICMP Parameter problem Type 12 [RFC792] Codes 0 Pointer indicates the error 1 Missing a Required Option [RFC1108] 2 Bad Length ICMP - Timestamp Type 13 Timestamp [RFC792] Type 14 Timestamp reply No codes ICMP - (c) Jouni Ikonen / ICMP - (c) Jouni Ikonen / Query messages ICMP Timestamp Request and Reply Allows system to query for the current time Returned value is the number of milliseconds since midnight type (13/14) code (0) checksum ICMP Information Request Type 15 Information Request [RFC792] Type 16 Information Reply No codes identifier sequence number 32-bit originate timestamp 32-bit receive timestamp 20bytes 32-bit transmit timestamp ICMP - (c) Jouni Ikonen / ICMP - (c) Jouni Ikonen / 3

21 ICMP Address Mask Request Type 17 Address Mask Request [RFC950] Type 18 Address Mask Reply No codes Query messages ICMP Address Mask Request and reply To obtain subnetmask at bootstrap time Same kind of system as diskless system using RARP type (17/18) code (0) checksum identifier sequence number 12bytes 32-bit subnetmask ICMP - (c) Jouni Ikonen / ICMP - (c) Jouni Ikonen / More ICMP types, experimental, etc. 30 Traceroute [RFC1393] 31 Datagram Conversion Error [RFC1475] 32 Mobile Host Redirect [David Johnson] 33 IPv6 Where-Are-You [Bill Simpson] 34 IPv6 I-Am-Here [Bill Simpson] 35 Mobile Registration Request [Bill Simpson] 36 Mobile Registration Reply [Bill Simpson] 39 SKIP [Markson] 40 Photuris [RFC2521] ICMP - (c) Jouni Ikonen / 4

22 TCP/IP illustrated Vol. 1 The Protocols Chapter 7 - Ping Program Ping - (c) Jouni Ikonen / Ping Tests whether another host is reachable. Sends an ICMP echo request message to a host, expecting an ICMP echo reply to be returned. However routers can treat ping messages as less important messages and hosts / organizations can block them due security issues. Can also be used to examine the IP record route and timestamp options. Ping - (c) Jouni Ikonen / Format of the Ping message Ping details type (0 or 8) code (0) checksum 8bytes identifier sequence number optional data Echo reply Echo request Ping - (c) Jouni Ikonen / +1 / packet Most TCP/IP implementations support ping server directly in the kernel. Server must echo the identifier and sequence number fields + optional data. Identifier field in the ping message is set to process number of the program (at least in Unix), this allows ping program to distinguish between multiple instances. Ping - (c) Jouni Ikonen / Ping example turgon:~> ping is alive turgon:~> ping -s PING : 56 data bytes 64 bytes from dior.it.lut.fi ( ): icmp_seq=0. time=3. ms 64 bytes from dior.it.lut.fi ( ): icmp_seq=1. time=1. ms 64 bytes from dior.it.lut.fi ( ): icmp_seq=2. time=2. ms 64 bytes from dior.it.lut.fi ( ): icmp_seq=3. time=1. ms ^C PING Statistics packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 1/1/3 Ping - (c) Jouni Ikonen / Live capture Frame 1 (74 bytes on wire, 74 bytes captured) Arrival Time: Sep 22, :00: Time delta from previous packet: seconds Time since reference or first frame: seconds Frame Number: 1 Packet Length: 74 bytes Capture Length: 74 bytes Ethernet II, Src: 00:04:76:8e:a9:f2, Dst: 00:0c:ce:0a:40:00 Destination: 00:0c:ce:0a:40:00 (Cisco_0a:40:00) Source: 00:04:76:8e:a9:f2 (3Com_8e:a9:f2) Type: IP (0x0800) Ping - (c) Jouni Ikonen / 1

23 Live capture More ping details Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) = Differentiated Services Codepoint: Default (0x00) = ECN-Capable Transport (ECT): = ECN-CE: 0 Total Length: 60 Identification: 0x2a0e (10766) Flags: 0x = Don't fragment: Not set Internet Control Message Protocol..0. = More fragments: Not set Type: 8 (Echo (ping) request) Fragment offset: 0 Code: 0 Time to live: 128 Checksum: 0xc244 (correct) Protocol: ICMP (0x01) Identifier: 0x0200 Header checksum: 0xa4e2 (correct) Sequence number: 0x8917 Source: ( ) Data (32 bytes) Destination: ( ) Ping - (c) Jouni Ikonen / Round trip time is calculated by storing send time to optional data field. When reply is received this value is subtracted from current time. Hosts might have different time resolution available and this usually impacts the output format. ARP and DNS query can delay sending of the first ping. Ping - (c) Jouni Ikonen / Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS] [-r count] [-s count] [[-j host-list] [-k host-list]] [-w timeout] destination-list Windows ping Options: -t Ping the specified host until stopped. To see statistics and continue - type Control-Bre To stop - type Control-C. -a Resolve addresses to hostnames. -n count Number of echo requests to send. -l size Send buffer size. -f Set Don't Fragment flag in packet. -i TTL Time To Live. -v TOS Type Of Service. -r count Record route for count hops. -s count Timestamp for count hops. -j host-list Loose source route along host-list. -k host-list Strict source route along host-list. -w timeout Timeout in milliseconds to wait for each reply. Ping - (c) Jouni Ikonen / Windows ping example C:\>ping -n 10 Pinging nic.funet.fi [ ] with 32 bytes of data: Reply from : bytes=32 time=16ms TTL=248 Reply from : bytes=32 time<10ms TTL=248 Reply from : bytes=32 time<10ms TTL=248 (some lines removed) Reply from : bytes=32 time<10ms TTL=248 Ping statistics for : Packets: Sent = 10, Received = 10, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 16ms, Average = 1ms Ping - (c) Jouni Ikonen / IP route record option Format of RR option in IP header Most ping programs offer route record option, which sets RR to outgoing ICMP packet. This causes every router to add its IP address to a list in options list. Not all host support all ICPM options IP options header has only space for 9 addresses ( = 37 bytes / 4 bytes / IP) Ping - (c) Jouni Ikonen / 39 bytes code len ptr IP addr #1 IP addr #2 IP addr #3 IP addr # ptr = 4 ptr = 8 ptr = 12 ptr = 36 Specifies the type of IP option (7 for RR) Total number of bytes in RR option (39) Pointer to next free address slot Ping - (c) Jouni Ikonen / ptr = 40 2

24 RR ping example jumi:~> ping -c 2 -R PING ( ): 56 data bytes 64 bytes from : icmp_seq=0 ttl=63 time=2.0 ms RR: jumi.lut.fi ( ) lty-gw.cc.lut.fi ( ) Adds the interface ( ) of outgoing interface ( ) lty-gw.cc.lut.fi ( ) jumi.lut.fi ( ) 64 bytes from : icmp_seq=1 ttl=63 time=1.9 ms (same route) ping statistics packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 1.9/1.9/2.0 ms Ping - (c) Jouni Ikonen / IP timestamp option 40 bytes code len ptr OF FL Time #1 Time #2 Time #3 Time # Flags: 0 record only timestamps 1 record IP address and timestamp 3 sender initializes list with IP s whose timestamps are requested. 4 bit overflow and 4 bit flags Pointer to next free timestamp slot Total number of bytes in the timestamp option (normally 36 or 40) Specifies the type of IP option (0x44 for the timestamp option) Ping - (c) Jouni Ikonen / Timestamp values Preferred timestamp values are milliseconds since midnight (UTC). If router has no access to global time information it can use any format it wishes, but must set high order bit of the timestamp to indicate the nonstandard time. E.g. devices time can present milliseconds since last reboot. If router can not add timestamp it increments overflow field. Not feasible Very limited size to record both IP and timestamp Recording only timestamps is not useful as routes are not usually guaranteed to be fixed. No control of accuracy of timestamps in each router. There are better ways to measure hop times between routers (Traceroute) Ping - (c) Jouni Ikonen / Ping - (c) Jouni Ikonen / 3

25 TCP/IP illustrated Vol. 1 The Protocols Chapter 8 - Traceroute Program Traceroute program Handy debugging tool. (Traceroute, tracert) Lets user see the route that IP-datagram follow from one host to another. Requires only working UDP module at destination. No special server application required. No guarantees that two consecutive IP will follow same route (but usually they do). Traceroute - (c) Jouni Ikonen / Traceroute - (c) Jouni Ikonen / Traceroute - alternatives(2) Why not to use ICMP s IP record route option (RR), but an other program? Not all routers support the record route option Record route is one way option. Sender has to retrieve route from target somehow. Only space for 9 addresses in IP headers option field. Traceroute - basics(3) Traceroute uses ICMP and the TTL (Time to live) field in IP header. Each router is required to decrement TTL value. When TTL of datagram is 0 it will be discarded. An ICMP time exceeded message is returned to sender (with routers IP address). Traceroute - (c) Jouni Ikonen / Traceroute - (c) Jouni Ikonen / Traceroute - behaviour (4) Traceroute example Send datagrams starting with TTL (time to live) of 1, increasing the TTL by1, to locate each router in the path. An ICMP time exceeded is returned by each router when it discards the UDP datagram. An ICMP port unreachable is generated by the final destination. Final destination is detected by target sending datagram to a very large port number. Traceroute - (c) Jouni Ikonen / jumi:~> traceroute traceroute to nic.funet.fi ( ), 30 hops max, 38 byte packets 1 lty-gw.cc.lut.fi ( ) ms ms ms 2 muuri.cc.lut.fi ( ) ms ms ms 3 lut-gw.cc.lut.fi ( ) ms ms ms 4 lut3-rtr ( ) ms ms ms 5 helsinki0-p3100-lut3.funet.fi ( ) ms ms ms 6 csc0-p1000-helsinki0.funet.fi ( ) ms ms ms 7 csc3-g0000-csc0.funet.fi ( ) ms ms ms 8 nic.funet.fi ( ) ms * ms Traceroute - (c) Jouni Ikonen / 1

26 IP source routing option Strict source routing Sender specifies exact route in that datagram must follow. Max. 9 addresses Loose source routing The sender specifies a list of routers which datagram must traverse, but there can be also other routers. IP source routing option Paths from source to target and vice versa has not to be symmetrical. Can be tested with loose routing by setting target to route which must be traversed and destination to ourselves. Traceroute - (c) Jouni Ikonen / Traceroute - (c) Jouni Ikonen / 2

27 TCP/IP illustrated Vol. 1 The Protocols Chapter 9 - IP Routing IP routing (use of routing table) Routing is one of most important functions of IP. Datagrams to be routed are generated by: local host some other host (and processing host is configured as a router). Routing information between adjacent routers are exchanged by routing protocols, e.g. RIP, BUT now we are interested how a single IP layer makes routing decisions. IP Routing - (c) Jouni Ikonen / IP Routing - (c) Jouni Ikonen / routing daemon routing table updates from adjacent routers route command netstat command UDP TCP Mechanisms vs. policies IP layer Routing table ICMP redirects ICMP forward datagram (if forwarding enabled) IP output: calculate next hop router (if necessary) Source routing Network interfaces IP Routing - (c) Jouni Ikonen / yes Our packet (one of our IP addresses or broadcast addrs) Process IP options IP input queue Routing mechanism Done by the IP-layer. Search through routing table and decide to which interface send packet to. Routing policy Set of rules about which rules go into the routing table Normally done by routing daemon IP Routing - (c) Jouni Ikonen / Routing table Entry has: Flags Destination IP address (host, network, or default) a next-hop router IP address (for an indirect route) a pointer to a local interface to use Routing table is searched for every datagram system generates or forwards. Example routing table The distance to the target Number of references to a route /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface UH eth UH eth U eth UG eth U lo UG eth0 Count of lookups for the route IP Routing - (c) Jouni Ikonen / IP Routing - (c) Jouni Ikonen /

28 U The route is UP Routing table flags G The route is a gateway (router). If not set the destination is directly connected. H The route is to a host, that is, the destination is a complete host address. If not set the route is to a network, and the destination is a network ID D The route was created by redirect M The route was modified by a redirect Example routing table2 C:\>netstat rn (tai route print) Active Routes: Network Destination Netmask Gateway Interface Metric Default Gateway: =========================================================================== Persistent Routes: None IP Routing - (c) Jouni Ikonen / IP Routing - (c) Jouni Ikonen / Routing principles Go trough routing table Search for matching host address Search for matching network address Search for default entry Static routing information can be entered in to the host s configuration files. These can include default gateway. Commands Ifconfig, ipconfig Route, netstat IP Routing - (c) Jouni Ikonen / IP Routing - (c) Jouni Ikonen / What goes to a routing table? 1. Host is not connected to a LAN Only loopback interface 2. Host is connected to single LAN Loopback interface and LAN entry 3. Host is connect to a LAN, which has access to Internet Loopback, LAN entry and normally default 4. Host is connect to a LAN, which has access to Internet and specific routes to other hosts. Host entries, Loopback, LAN entry and normally default IP Routing - (c) Jouni Ikonen / Example: Routing table for A Internet GW F E LAN Eth0 Eth1 A Link B C D IP Routing - (c) Jouni Ikonen /

29 Example: Routing table for A Internet GW F E LAN Eth0 Eth1 A Link B C D /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface UH eth U eth U lo UG eth0 ICPM host & Network Unreachable errors How about if there is no match in the Routing table? If datagram is generated by the processing host the error is returned to the application (host / network unreachable) If datagram is sent by some other host (routed), ICMP host unreachable error is returned to the sender. IP Routing - (c) Jouni Ikonen / IP Routing - (c) Jouni Ikonen / ICMP redirect Host sends a datagram to default router R2 R2 determines that R1 is correct router in the same network and sends datagram to it and ICMP redirect message to host to correct its routing table D R1 Route redirect R2 IP Routing - (c) Jouni Ikonen / S Default router R2 creates a route for each host separately! ICMP route discovery Newer way after statistic routes to use the ICMP router advertisement and solicitation messages. RFC1256 On boot up a host broadcasts (or multicasts) a solicitation message. One or more routers respond with router advertisement messages (with one or more routes). Routers send advertisement messages periodically (randomized period). IP Routing - (c) Jouni Ikonen / ICMP router advertisement type (9) code (0) checksum # of addresses Address entry size (2) router address [1] lifetime preference level [1] (larger value more preferable) router address [2] preference level [3] 8bytes IP Routing - (c) Jouni Ikonen /

30 TCP/IP illustrated Vol. 1 The Protocols Chapter 10 - Dynamic Routing Protocols Dynamic routing protocols Static routing suitable only for small networks. Better choices for static routing? RIP (Routing Information Protocol), OSPF (Open Shortest Path First), BGP (Border Gateway Protocol) Dynamic routing does not change how kernel performs routing at IP layer. Dynamic Routing Protocols - (c) Jouni Ikonen / Dynamic Routing Protocols - (c) Jouni Ikonen / Dynamic routing Dynamic routing protocols are used by routers to exchange routing information Adjacent routers inform each other of what networks each router is currently connected to. Internet is divided into Autonomous Systems (ASs). AS is normally administrated by a single entity (RFC 1930). A unique AS number (or ASN) is allocated to each AS for use in BGP routing. With BGP, AS numbers are important because the ASN uniquely identifies each network on the internet. Dynamic Routing Protocols - (c) Jouni Ikonen / A B C Autonomous systems can be: Multihomed AS is an AS that has connections to multiple AS. A stub AS has connection to a single other AS A transit AS provides connections through itself to separate networks. E.g. an ISP might sell transit service to customer networks. Dynamic Routing Protocols - (c) Jouni Ikonen / D Dynamic routing Each AS can decide routing protocol used in communication between routers in that AS. This is called Interior Gateway Protocol (IGP). E.g., RIP and OSPF Between ASs Exterior Gateway Protocol (EGP) is used and newer Border Gateway Protocol (BGP) are used. Routing software routed Often used in UNIX systems Capable only to RIP Suitable for small or medium size networks gated Supports IGP and EGP Dynamic Routing Protocols - (c) Jouni Ikonen / Dynamic Routing Protocols - (c) Jouni Ikonen / 1

31 RIP: Routing Information Protocol IP header UDP header RIP message 20 bytes 8 bytes Up to 25 routes can be advertised in a RIP message. Multiple messages is often required to send entire routing table. 1 request 2 reply (5 poll) (6 poll entry) RIP message command (1-6) version (1) (0) addresses family (2) (0) 32-bit IP address (0) (0) Metric (1-16) up to 24 more routes, with same format as previous 20 bytes 2 IP 20 bytes Dynamic Routing Protocols - (c) Jouni Ikonen / Dynamic Routing Protocols - (c) Jouni Ikonen / RIP: Operation (1) RIP: Operations (2) Initialization. Send request to each interface asking complete routing tables. Broadcast is used if possible. Request received. Reply with routing table or entries requested. If we do not have route to address requested set metrics to 16 (infinite). Response received. Update routing table. Regular routing updates. Every 30 seconds, all or part of the routers s entire routing table is sent to every neighbor router. Triggered updates. Occur whenever metrics for a route changes. Only changed entries are sent. Dynamic Routing Protocols - (c) Jouni Ikonen / Dynamic Routing Protocols - (c) Jouni Ikonen / RIP Metrics are hop counts from a router to another. If there are multiple paths within the AS from a router to another, the router selects the path with the smallest hop count and ignores the other paths. Hop count is limited to 15 => Limits network size. R1 R2 N1 N2 N3 Dynamic Routing Protocols - (c) Jouni Ikonen / Dynamic Routing Protocols - (c) Jouni Ikonen / 2

32 N2 = 1 hop N1 N2 = 1 hop, N3 = 2 hops N1 R1 R1 N3 = 1 hop N3 = 1 hop N1 = 1 hop R2 N2 N1 = 1 hop R2 N2 N2 = 1 hop Dynamic Routing Protocols - (c) Jouni Ikonen / N3 N3 N2 = 1 hop, N1 = 2 hops Dynamic Routing Protocols - (c) Jouni Ikonen / RIP problems No knowledge of subnet addressing. Long time to stabilize after a change (minutes). Limitation of metrics (max. 15 hops). RIP version 2 Uses message fields that were marked must be zero in version 1. Can interoperate with V.1 if 0 requirement omitted. Allows running multiple instances of RIP on single router Support for exterior gateway protocols. Support for multicasting (besides of broadcast) Dynamic Routing Protocols - (c) Jouni Ikonen / Dynamic Routing Protocols - (c) Jouni Ikonen / OSPF: Open Shortest Path First Overcomes many limitations of RIP. link-state protocol vs. RIP s distance vector protocol. Router does not exchange distances with neighbors, instead of it tests actively the status of link to each of its neighbors and propagates this information to its neighbors. Each router build complete routing table. OSPF Converges faster than RIP. Uses IP directly. Many advanced features: Can calculate set of routes for each IP type-ofservice Dimensionless cost. Can be based on throughput, round trip delay, reliability... Dynamic Routing Protocols - (c) Jouni Ikonen / Dynamic Routing Protocols - (c) Jouni Ikonen / 3

33 OSPF Load balancing on equal cost routes. Supports subnet masks (associated with each advertised route). point-to-point links between routers do no need IP addresses. Simple password scheme (cleartext). multicasting to reduce load on systems not participating on OSPF. Dynamic Routing Protocols - (c) Jouni Ikonen / Link-state algorithm 1. Upon initialization or due to any change in routing information, a router will generate a link-state advertisement (collection of all link-states on that router). 2. All routers will exchange link-states by means of flooding. Each router that receives a link-state updates its link-state database (goto 1). 3. After the database of each router is completed, the router will calculate a Shortest Path (Djikstra) Tree to all destinations. The destinations, the associated cost and the next hop to reach those destinations will form the IP routing table. 4. In case no changes in the OSPF network occur, such as cost of a link or a network being added or deleted, OSPF should be very quiet. Dynamic Routing Protocols - (c) Jouni Ikonen / Frame 1 (94 bytes on wire, 94 bytes captured) Ethernet II, Src: 00:0c:ce:0a:40:00, Dst: 01:00:5e:00:00:05 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Open Shortest Path First OSPF Header OSPF Version: 2 Message Type: Hello Packet (1) Packet Length: 44 Source OSPF Router: ( ) Area ID: (Backbone) Packet Checksum: 0x0000 (none) Auth Type: Cryptographic Auth Key ID: 0 Auth Data Length: 16 Auth Crypto Sequence Number: 0x2c29b543 Auth Data: 3179C1C9E21459BEB97AFED92DD794B6 OSPF Hello Packet Network Mask: Hello Interval: 10 seconds Options: 0x2 (E) Router Priority: 1 Router Dead Interval: 40 seconds Designated Router: Backup Designated Router: BGP: Border Gateway Protocol BGP is EGP for communicating between ASs. Replacement for older EGP. Exchanges reachability information with other systems. Includes full path of ASs which must be traversed to target. Allows policy based routing (political, security, cost ). Dynamic Routing Protocols - (c) Jouni Ikonen / Dynamic Routing Protocols - (c) Jouni Ikonen / BGP Distance vector protocol (like RIP). TCP between routers. keep alive timers to poll neighbors. CIDR: Classless Interdomain Routing As class B addresses are scarce, multiple C addresses are used instead of the B address. routing tables grow. Basic idea is to allocate multiple IP addresses in a way that allows summarization into smaller number of routing entries. Supernetting: aggregation of multiple contiguous prefixes into supernets. Route aggregation. Dynamic Routing Protocols - (c) Jouni Ikonen / Dynamic Routing Protocols - (c) Jouni Ikonen / 4

34 CIDR Requirements: Addresses to be summarized must share the same highorder bits of their addresses. The routing tables and algorithms must be extended to base their routing decisions on a 32-bit IP address and a 32-bit mask. The routing protocols must be extended to carry the 32- bit mask in addition of the 32-bit address (OSPF & RIP-2 can do this). RFC 1518 & RFC 1519 (1993), RFC 4632 (2006) Summary Interior gateway protocol (IGP): RIP & OSPF. Exterior gateway protocol (EGP): BGP. Newer protocols support subnetting and different metrics. CIDR to reduce routing tables (a claim that entries could be reduced to 200). Dynamic Routing Protocols - (c) Jouni Ikonen / Dynamic Routing Protocols - (c) Jouni Ikonen / More to read Christian Huitema: Routing in the Internet, Prentice Hall, 1995 RFC 1058 (RIP), RFC 2328 (OSPF2), RFC 2740 (OSPFv3, IPv6 support), RFC 4271 (BGP 4, 2006) (OSPF) htm#xtocid htm#xtocid54 (BGP). Dynamic Routing Protocols - (c) Jouni Ikonen / 5

35 TCP/IP illustrated Vol. 1 The Protocols Chapter 11 - UDP: User Datagram Protocol UDP Simple datagram-oriented transport layer protocol. RFC 768. Non-stream-oriented protocol. No reliability, no guarantee that datagrams reach their destination, no ordering. When reliability is needed, we should use TCP (?). UDP - (c) Jouni Ikonen / UDP - (c) Jouni Ikonen / UDP Encapsulation IP datagram UDP datagram UDP Header 16-bit source port number 16-bit destination port number 16-bit UDP length 16-bit UDP checksum data (if any) 8 bytes IP header UDP header 20 bytes 8 bytes UDP - (c) Jouni Ikonen / UDP data Minumum UDP datagram 8 bytes Port numbers identify the sending and the receiving process (UDP and TCP are demultiplexed earlier). UDP length field is the length of the UDP header and the UDP data in bytes. UDP checksum covers the UDP header and the UDP data. UDP - (c) Jouni Ikonen / UDP Checksum Checksum is optional in UDP, as in TCP it is mandatory. The length of the UDP datagram can be an odd number of bytes, while the checksum algorithm adds 16-bit words solution is to append a pad byte of 0 to the end, if necessary, just for the checksum computation. UDP include a 12-byte pseudo-header with the UDP datagram just for the checksum computation includes certain fields from the IP header, purpose is to let UDP double-check that the data has arrived at the correct destination. If sender did compute a checksum and the receiver detects a checksum error, the UDP datagram is silently discarded UDP - (c) Jouni Ikonen / Fields used for computation of UDP Checksum zero 8-bit protocol (17) 16-bit source port number 16-bit UDP length 32-bit source IP address 32-bit destination IP address data pad byte (0) UDP - (c) Jouni Ikonen / 16-bit UDP length 16-bit destination port number 16-bit UDP checksum UDP pseudo header UDP header 1

36 IP fragmentation Network normally has upper limit on the size of the frame that can be transmitted. IP datagram IP UDP IP compares the MTU with the datagram size header header and performs fragmentation if necessary. 20 bytes 8 bytes The goal is make fragmentation and reassembly transparent to the transport layer (TCP and IP UDP UDP). header header It s possible to fragment already fragmented datagram (possibly more than once) packet One of the bits in the flags field is called don t fragment bit. UDP - (c) Jouni Ikonen / UDP - (c) Jouni Ikonen / UDP fragmentation UDP data (1473 bytes) IP header 20 bytes packet 20 bytes 8 bytes 1472 bytes 1 byte UDP fragmentation Which packets belong the same UDP datagram? Identifier field from IP header is copied to each fragment. The fragment offset contains the offset of in 8 byte units of the fragment from beginning of the original datagram. If a single fragment is lost the whole datagram must be retransmitted! UDP - (c) Jouni Ikonen / ICMP Unreachable Error (fragmentation required) ICMP unreachable error occurs when a router receives datagram that requires fragmentation, but the don t fragment (DF) flag is turned on in the IP header. This error can be used by a program that needs to determine the smallest MTU in the path to a destination - called the path MTU. UDP - (c) Jouni Ikonen / ICMP Unreachable Error Fragmentation example type(3) code(4) checksum Unused (must be 0) MTU of next-hop network 8 bytes MTU=1500 MTU=1500 MTU=1500 MTU=1500 SLIP bsdi sun netb solaris MTU=552 MTU=? IP header (including options) + first 8 bytes of original IP datagram data fragment fragment ICMP echo request PING Fragmentation should be avoided! Path MTU discovery mechanism can be used. UDP - (c) Jouni Ikonen / If router supports, otherwise 0 UDP - (c) Jouni Ikonen / 2

37 Fragmentation example MTU=1500 MTU=1500 MTU=1500 MTU=1500 SLIP bsdi sun netb solaris ICMP echo request ICMP echo reply MTU=552 ICMP unreachable fragmentation required ICMP echo request MTU=? UDP - (c) Jouni Ikonen / ICMP echo request PING 600 DF Determining the Path MTU using modified Traceroute Send packets with don t fragment bit set. Size of the first packet is equal to the MTU of the outgoing interface. Whenever receive an ICMP can t fragment error, we ll reduce the size of the packet if we have ICMP version that includes the MTU of the outgoing interface, we ll use that value, else we ll try next smallest MTU UDP - (c) Jouni Ikonen / UDP and ARP interaction If more fragments are ready to send before answer for ARP query is received all fragments might generate separate arp queries. This can be seen on wire. Arp (normally) keeps only the last segment buffered for the query, so other ones are thrown away. receiving end should generate ICMP time exceeded in reassembly Whole UPD datagaram must be retransmitted. Getting a fragment IP layer starts timer when a fragment arrives. Normal timer time is seconds When timer goes off the segments are thrown out (and ICMP error is possibly generated) ICMP error is not required if first fragment is not received. Without first fragment ICMP can not inform the sender which process sent the datagram. UDP - (c) Jouni Ikonen / UDP - (c) Jouni Ikonen / Maximum UDP datagram size Theoretically the maximum size of an IP datagram is bytes With an IP header of 20 bytes and a UDP header of 8 bytes, this leaves a maximum of bytes of user data in a UDP datagram Two limits The sockets API provides function to set the size of buffers (default usually 8192 bytes, receiving and writing) Many kernel implementations of TCP/IP limits the size of an IP datagram less than bytes UDP - (c) Jouni Ikonen / Datagram truncation IP s capability to send and receive certain size datagrams does not mean that our applications can do that! How does applications and API s deal with large datagrams? Some APIs discard excess data Some APIs give data with multiple reads Some even set a flag that more data is to be read UDP - (c) Jouni Ikonen / 3

38 ICMP Source Quench Error This error may be generated if system receives datagrams at a rate that is too fast to be processed It s easy to generate these ICMP errors using UDP E.g. send 100 UDP datagrams to a 9.6kbit SLIP link in a fast pace. Sending application might have terminated before receiving error. UDP - (c) Jouni Ikonen / UDP server design A client starts, communicates with a server, and is done. Servers starts and then go to sleep, waiting for a client s request to arrive. UDP server wakes up when a client s datagram arrives. What arrives from client is a UDP datagram IP header contains the source and destination IP addresses. UDP header contains the source and destination UDP port numbers. this feature allows an iterative UDP server to handle multiple clients. Each reply is sent back to the client that sent the request. UDP - (c) Jouni Ikonen / Destination IP address Some applications need to know who the datagram was sent to (destination IP addr). This requires the OS to pass the destination address from the received UDP datagram to the application. Most UDP servers are iterative, so one server can handle all the client requests on a single UDP port. Received UDP datagrams are queued and given in arrival order. Queue can fill up excess messages are thrown away (application is not informed about this). UDP - (c) Jouni Ikonen / UDP - (c) Jouni Ikonen / Restricting local IP address Most UDP servers wildcard their local IP addresses when they create a UDP end point An incoming UDP datagram destined for the server s port will be accepted on any local interface e.g. we can start a UDP server on port 7777 If server specifies one of the host s local IP addresses, as the local IP address for the end point Incoming UDP datagrams will then be passed to this end point only if the destination IP address matches the specified local address. UDP - (c) Jouni Ikonen / Restricting local IP address It is possible to start different server at the same port, each with different local IP address. Application must usually say that it is OK to reuse the port number (SO_REUSEADDR). UDP - (c) Jouni Ikonen / 4

39 Restricting foreign IP address Most implementations allow a UDP end point to restrict the foreign address end point will only receive UDP datagrams from that specific IP address and port number sock -u -s -f this sets the foreign IP address to and the foreign port number to 4444 the server s port number is 5555 UDP - (c) Jouni Ikonen / Multiple recipients per port Most UDP implementations allow only one application associated with IP and port pair. Can not bind: Address already in use With multicasting multiple recipients can listen same port. UDP - (c) Jouni Ikonen / import socket PORT = BUFLEN = 512 UDP Server (Python) server = socket.socket(socket.af_inet, socket.sock_dgram, socket.ipproto_udp) server.bind(('', PORT)) while True: (message, address) = server.recvfrom(buflen) print 'Received packet from %s:%d' % (address[0], address[1]) print 'Data: %s' % message Source: ( ) UDP - (c) Jouni Ikonen / import socket UDP Client (Python) SERVER_ADDRESS = ' ' SERVER_PORT = client = socket.socket(socket.af_inet, socket.sock_dgram, socket.ipproto_udp) for i in range(3): print 'Sending packet %d' % i message = 'This is packet %d' % i client.sendto(message, (SERVER_ADDRESS, SERVER_PORT)) client.close() Source: ( ) UDP - (c) Jouni Ikonen / 5

40 TCP/IP illustrated Vol. 1 The Protocols Chapter 12 - Broadcasting and Multicasting Introduction Broadcast can be defined as a transmission, where a certain host wants to send to every other host (i.e use of ARP/RARP). Multicast can be defined as a transmission, where a certain host wants to send every other host that belong to a certain multicast group. Broadcasting and Multicasting - (c) Jouni Ikonen / Broadcasting and Multicasting - (c) Jouni Ikonen / Broadcasting Four different forms of IP broadcast addresses limited broadcast net-directed broadcast subnet-directed broadcast all-subnets-directed broadcast Broadcasting The limited broadcast address is usage example : during the host configuration process, when the host might not know its subnet mask or IP address. A datagramm with this address is never forwarded by a router Broadcasting and Multicasting - (c) Jouni Ikonen / Broadcasting and Multicasting - (c) Jouni Ikonen / Broadcasting The net-directed broadcast address is netid A datagram with this address must be forwarded by a router (but it also can disable the forwarding) Broadcasting and Multicasting - (c) Jouni Ikonen / Broadcasting The subnet-directed broadcast address has a host ID of all one bits (255) but a specific subnet ID ---> An all-subnets-directed broadcast address requires knowledge of the destination network s subnet mask. Both the subnet ID and host ID are all one bits (255) better to use multicasting instead! Broadcasting and Multicasting - (c) Jouni Ikonen / 1

41 Broadcasting Examples : the way broadcast is handled depends on the type of broadcast address, the application, the TCP/IP implementation and possible configuration switches Ping > unknown host? Ping a subnet address TFTP Broadcasting and Multicasting - (c) Jouni Ikonen / Sending Appl UDP IPv4 Data Link sendto Dest IP: Dest Port: 520 subnet Dest Enet: ff:ff:ff:ff:ff:ff Frame type: 0800 Set SO_BROADCAST option using setsockopt() Protocol =UDP UDP IPv4 Discard = unicast = broadcast Frame type = 0800 Data Link 02:60:8c:2f:4e:00 Receiving Appl Dest IP: Protocol: UDP Broadcasting and Multicasting - (c) Jouni Ikonen / Original picture: Stevens al.: Unix network programming Enet hdr IPv4 hdr Port =520 Protocol =UDP UDP IPv = unicast = broadcast Frame type = 0800 Data Link UDP hdr :60:20:03:f6:42 UDP Data Dest Port: 520 Multicasting IP Multicasting provides 2 services for an application delivery to multiple destinations solicitation of servers by clients i.e use of diskless WS needs to locate a bootstrap server ---> bootp Broadcasting and Multicasting - (c) Jouni Ikonen / Multicasting Multicast group addresses use class D IP address. Multicast group address is a combination of the high-order 4 bits of 1110 and the multicast group ID. The set of hosts listening to a particular IP multicast address is called a host group. Dynamic memberships Broadcasting and Multicasting - (c) Jouni Ikonen / Multicasting Some multicast group addresses are assigned by the IANA. These are called permanent host groups, i.e in a similar manner like UDP and TCP port numbers. Addresses are for applications which never need to multicast further than one hop (MC routers drop these). Multicasting All systems in this subnet All routers on this subnet RIP NTP, Network time protocol Broadcasting and Multicasting - (c) Jouni Ikonen / Broadcasting and Multicasting - (c) Jouni Ikonen / 2

42 From a multicast IP to Ethernet Converting multicast group addresses to Ethernet addresses Class D IP address These 5 bits are not used to form Eth-addr bit Ethernet address Last 23 bits are copied to eth-addr Broadcasting and Multicasting - (c) Jouni Ikonen / a multicast IP to Ethernet example Ethernet addresses 01:00:5e:00:00:00-01:00:5e:7f:ff:ff are multicast addresses. Upper 5 bits of MC IP address are ignored, which means that MC MAC addresses are not unique! Device driver must perform filtering Broadcasting and Multicasting - (c) Jouni Ikonen / Example IP (hex 0e ) 01:00:5e:00:40:20 IP (hex 0e ) 01:00:5e:00:40:20 Sending Appl UDP IPv4 Data Link sendto Dest IP: Dest Port: 123 UDP IPv4 Data Link Port =123 Protocol =UDP Perfect sw filtering based on dest IP Receiving Appl UDP IPv4 123 Frame type = 0800 Data Imperfect hw filtering based on dest Enet Link join receive 01:00:5e: 00:01:01 subnet :60:8c:2f:4e:00 02:60:20:03:f6:42 Dest Enet: 01:00:5e:00:01:01 Frame type: 0800 Enet hdr IPv4 hdr UDP hdr UDP Data Dest Port: 123 Broadcasting and Multicasting - (c) Jouni Ikonen / Dest IP: Protocol: UDP Broadcasting and Multicasting - (c) Jouni Ikonen / Original picture: Stevens al.: Unix network programming Multicasting Multicasting in a single network is simple, but multicasting beyond a single network needs a protocol ---> IGMP Broadcasting and Multicasting - (c) Jouni Ikonen / 3

43 TCP/IP illustrated Vol. 1 The Protocols Chapter 13 : Internet Group Management Protocol Introduction IGMP is used by hosts and routers that support multicasting. It lets all the systems on a physical network to know which hosts currently belong to which multicast group. Also like ICMP, IGMP is transmitted in IP datagrams. Current IGMP version is 3 and it is backwards compatible Internet Group Managment Protocol - (c) Jouni Ikonen / Internet Group Managment Protocol - (c) Jouni Ikonen / IGMPv2 IGMP messages are specified in the IP datagram with a protocol value of 2. IP datagram IP Header IGMP Message 20 bytes 8 bytes IGMP IGMP ( unused ) 16-bit checksum version type 32-bit group address (D) 1 request 2 response Class D IP address Internet Group Managment Protocol - (c) Jouni Ikonen / the maximum time allowed before sending a responding report Querier's Robustness Variable IGMPv3 Membership query message Type = 0x11 Max Resp Code Checksum Group Address Resv(0) S QRV QQIC Number of sources (N) Source Address [1] Source Address [2] Source Address [N] Address to be queried IP unicast addresses Querier's Query Interval The number of addresses Code present in the query Internet Group Managment Protocol - (c) Jouni Ikonen / RCF 1112 Host extensions for IP multicasting. S.E. Deering. Aug (Obsoletes RFC0988, RFC1054) (Updated by RFC2236) (Also STD0005) (Status: STANDARD) RFC 2236 Internet Group Management Protocol, Version 2. W. Fenner. November (Obsoleted by RFC3376) (Updates RFC1112) (Status: PROPOSED STANDARD) RFC 3228 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP). B. Fenner. February Status: BEST CURRENT PRACTICE RFC 3376 Internet Group Management Protocol, Version 3. B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan. October (Obsoletes RFC2236) (Status: PROPOSED STANDARD) (Updated by RFC 4604) IGMP Fundamental to multicasting is the concept of a process joining a multicast group on a given interface on a host. IGMP messages are used by multicast routers to keep track of group memberships on each of the router s physically attached networks. Internet Group Managment Protocol - (c) Jouni Ikonen / Internet Group Managment Protocol - (c) Jouni Ikonen / 1

44 IGMP The following rules apply : A host sends an IGMP report when the first process joins a group (if multiple processes join, only the first one reports) A host does not send a report when process leave a group (not even if being the last one) A multicast router sends IGMP queries at regular intervals to see if any host have any processes belonging to any groups. A host responds to an IGMP query by sending one IGMP report for each group that still contain a process or processes Internet Group Managment Protocol - (c) Jouni Ikonen / IGMP implementation optimizations When host joins a group there is no guarantee that message has been received. Another report is sent 0-10 seconds later. Host does not respond to a query immediately, but schedules replies for a later time. If someone else replies for a group then host cancels scheduled reply. Internet Group Managment Protocol - (c) Jouni Ikonen / IGMP Using those rules, a multicast router keeps a table of which of its interfaces have one or more hosts in a multicast group. IGMP report, TTL = 1, IGMP group address = group address dest IP address = group address src IP address = host s IP address Host IGMP query, TTL = 1, IGMP group address = 0 dest IP address = src IP address = router s IP address MR Internet Group Managment Protocol - (c) Jouni Ikonen / TTL 0 same host TTL 1 same subnet Multicast routers do not generate ICMP time exceeded error, when TTL reaches 0. Each host automatically joins on All-hosts group on all MC-capable interfaces. Membership in this group is never reported. Internet Group Managment Protocol - (c) Jouni Ikonen / Multicast routing protocols Video multicast example Distance Vector Multicasting Routing Protocol (DVMRP) Core Based Trees (CBT) Protocol Independent Multicast (PIM) Multicasrt Extensions to OSPF (MOSPF) Source: wikipedia.com ( ) Internet Group Managment Protocol - (c) Jouni Ikonen / RFC Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches (INFORMATIONAL) Internet Group Managment Protocol - (c) Jouni Ikonen / 2

45 Protocol-Independent Multicast (PIM) is a family of multicast routing protocols that can provide one-to-many and many-to-many distribution of data over the Internet. The "protocol-independent" part refers to the fact that PIM does not include its own topology discovery mechanism, but instead uses routing information supplied by other traditional routing protocols such as Border Gateway Protocol (BGP). There are four variants of PIM: PIM Sparse Mode (PIM-SM) explicitly builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. PIM-SM generally scales fairly well for wide-area usage. See the PIM Internet Standard RFC 4601 PIM Dense Mode (PIM-DM) implicitly builds shortest-path trees by flooding multicast traffic domain wide, and then pruning back branches of the tree where no receivers are present. PIM-DM generally has poor scaling properties. See experimental RFC 3973 Bidirectional PIM explicitly builds shared bi-directional trees. It never builds a shortest path tree, so may have longer end-to-end delays than PIM-SM, but scales well because it needs no source-specific state. see draft-ietf-pim-bidir PIM Source Specific Multicast (PIM-SSM) builds trees that are rooted in just one source, offering a more secure and scalable model for a limited amount of applications (mostly broadcasting of content). In SSM, an IP datagram is transmitted by a source S to an SSM destination address G, and receivers can receive this datagram by subscribing to channel (S,G). See informational RFC 3569 Of the four, PIM-SM has the widest deployment. Source: wikipedia.com ( ) Internet Group Managment Protocol - (c) Jouni Ikonen / 3

46 TCP/IP Illustrated Vol. 1 The Protocols Chapter 14 - DNS: The Domain Name System DNS Distributed database (no one knows all). Map between hostnames and IP addresses. Provide electronic mail routing information. Two library functions to access to the DNS: gethostbyname(3) gethostbyaddr(3) Before DNS (-1983) HOSTS.TXT retrieved DNS: The Domain Name System DNS: The Domain Name System DNS definition DNS Basics unnamed root Original definition RFC 882 and RFC 883 (obsolete) RFC 1034 Domain Names - Concepts and Facilities (standard). Updated by: 1101, 1183, 1348, 1876, 1982, 2065, 2181, 2308, 2535, 4033, 4034, 4035, 4343, 4592 RFC 1035 Domain Names Implementation and Specification (standard). Updated by: 1101, 1183, 1348, 1876, 1982, 1995,1996, 2065, 2136, 2137, 2181, 2308, 2535, 2845, 3425, 3658, 4033, 4034, 4035, 4343 top level domains arpa com edu gov int mil net org in-addr noao tuc sun second level domains sun.tuc.noao.edu generic domains ae... us. zw United Arab Emirates va reston cnri.reston.va.us cnri country domains Zimbabwe DNS: The Domain Name System 33 DNS: The Domain Name System in-addr.arpa IANA Domain names Zone Domain name that ends with period is absolute domain name or fully qualified domain name (FQDN). If domain name does not end with period, it is assumed to need completed. If name consists of two or more labels it might be considered complete (depends on implementation). DNS: The Domain Name System Zone is a subtree of the DNS tree that is administered independently. Zone has multiple name servers Primary (load data from disk) Secondary (Gets data from primary => zone transfer) Maintainer adds info to a zone and servers query each other in regular basis. If DNS server does not know answer it queries root server, which returns name server, which can help further. DNS: The Domain Name System 1

47 DNS Message Format identification number of questions number of authority RRs questions flags number of answer RRs number of additional RRs answers (variable number of resource records) authority (variable number of resource records) additional information (variable number of resource records) 12 bytes flags field QR opcode AA TC RD RA A C R rcode QR : 0 = query; 1 = response 1 4 opcode : 0 = standard query; 1 = inverse query; 2 = server status request, 4 = notify, 5 = server update AA : authoritative answer TC : truncated RD : recursion desired RA : recursion available A : Authentication available C : Checking available R : Reserved bit rcode : return code; 0 = no error; 3 = name error, DNS: The Domain Name System DNS: The Domain Name System Question Portion of DNS Query Message query type query name Query name is the name being looked up sequence of one or more labels begins with 1-byte count (num of bytes to follow) terminated with a byte of 0 6 g e m i n i 3 t u c 4 n o a o 3 e d u 0 Each question has query type Each response has a type Query class is normally 1, meaning Internet address DNS: The Domain Name System query class Resource Record Portion of DNS Response Message type resource data length domain name time-to-live resource data domain name is same format as query name field type specifies one of the RR codes; class is normally 1 (Internet addr) time to live is the number of seconds that the RR can be cached by the client resource data length specifies the amount of resource data (depends on the type) DNS: The Domain Name System class Example ipconfig /all Ethernet adapter Local Area Connection: Name server Name server client telnet mato.cc.lut.fi daytime DNS: The Domain Name System daytime server telnet client Connection-specific DNS Suffix. : pc.lut.fi Description : 3Com EtherLink XL 10/100 PCI For Complete PC Management NIC (3C905C-TX) Physical Address : E-A9-F2 DHCP Enabled : Yes Autoconfiguration Enabled.... : Yes IP Address : Subnet Mask : Default Gateway : DHCP Server : DNS Servers : DNS: The Domain Name System 2

48 Frame 45 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: 00:04:76:8e:a9:f2, Dst: 00:0c:ce:0a:40:00 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: 2853 (2853), Dst Port: domain (53) Domain Name System (query) Transaction ID: 0xe0f3 Flags: 0x0100 (Standard query) = Response: Message is a query = Opcode: Standard query (0) = Truncated: Message is not truncated = Recursion desired: Do query recursively = Z: reserved (0) = Non-authenticated data OK: Non-authenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries mato.cc.lut.fi: type A, class inet Name: mato.cc.lut.fi Type: Host address Class: inet DNS: The Domain Name System Frame 46 (205 bytes on wire, 205 bytes captured) Ethernet II, Src: 00:0c:ce:0a:40:00, Dst: 00:04:76:8e:a9:f2 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Domain Name System (response) Transaction ID: 0xe0f3 Flags: 0x8580 (Standard query response, No error) = Response: Message is a response = Opcode: Standard query (0) = Authoritative: Server is an authority for domain = Truncated: Message is not truncated = Recursion desired: Do query recursively = Recursion available: Server can do recursive queries = Z: reserved (0) = Answer authenticated: Answer/authority portion was not authenticated by the server = Reply code: No error (0) DNS: The Domain Name System Continued Questions: 1 Answer RRs: 2 Authority RRs: 3 Additional RRs: 2 Queries mato.cc.lut.fi: type A, class inet Name: mato.cc.lut.fi Type: Host address Class: inet Answers mato.cc.lut.fi: type CNAME, class inet, cname cc.lut.fi Name: mato.cc.lut.fi Type: Canonical name for an alias Class: inet Time to live: 1 hour Data length: 2 Primary name: cc.lut.fi cc.lut.fi: type A, class inet, addr Name: cc.lut.fi Type: Host address Class: inet Time to live: 1 hour Data length: 4 Addr: Authoritative nameservers cc.lut.fi: type NS, class inet, ns ns-secondary.funet.fi Name: cc.lut.fi Type: Authoritative name server Class: inet Time to live: 4 days Data length: 21 Name server: ns-secondary.funet.fi cc.lut.fi: type NS, class inet, ns ns1.lut.fi Name: cc.lut.fi Type: Authoritative name server Class: inet Time to live: 4 days Data length: 6 Name server: ns1.lut.fi cc.lut.fi: type NS, class inet, ns ns2.lut.fi Name: cc.lut.fi Type: Authoritative name server Class: inet Time to live: 4 days Data length: 6 Name server: ns2.lut.fi DNS: The Domain Name System DNS: The Domain Name System Additional records ns1.lut.fi: type A, class inet, addr Name: ns1.lut.fi Type: Host address Class: inet Time to live: 1 hour Data length: 4 Addr: ns2.lut.fi: type A, class inet, addr Name: ns2.lut.fi Type: Host address Class: inet Time to live: 1 hour Data length: 4 Addr: DNS: The Domain Name System Pointer Queries Give an IP address - return the name. Names are written starting at the bottom of the DNS tree, working upward. E.g. DNS name for the host sun, with IP address of , is in-addr.arpa We have to write 4 bytes of the IP address backward because authority is delegated based on network Ids : 1st byte of a class A address 1st and 2nd bytes of a class B address 1st, 2nd and 3rd bytes of a class C address DNS: The Domain Name System 3

49 Resource Records A (1): IP address (32-bit binary value) NS (2): name server record PTR (12): pointer record used for pointer queries CNAME (5) : canonical name (alias) HINFO (13): host information (CPU/OS) MX (15): mail exchange records AAAA (28): IPv6 address Caching To reduce the DNS traffic on the Internet. Is maintained in the server. Is available to any applications that use the server. DNS: The Domain Name System DNS: The Domain Name System UDP or TCP Port numbers for DNS name servers are : UDP port 53 TCP port 53 DNS primarily uses UDP (both resolver and server must perform timeout and retransmission). If response is truncated (TC bit set) resolver normally allocates new query with TCP. Zone transfers are done with TCP. /etc/resolv.conf aadolf:~> cat /etc/resolv.conf search pc.lut.fi it.lut.fi cc.lut.fi lut.fi nameserver nameserver DNS: The Domain Name System DNS: The Domain Name System jumi:~> host -a lut.fi Trying "lut.fi" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 5 ;; QUESTION SECTION: ;lut.fi. IN ANY ;; ANSWER SECTION: lut.fi IN SOA ns1.lut.fi. hostmaster.lut.fi lut.fi IN NS ns-secondary.funet.fi. lut.fi IN NS ns1.lut.fi. lut.fi IN NS ns2.lut.fi. lut.fi IN MX 20 smtp1.cc.lut.fi. lut.fi IN MX 50 mail.funet.fi. lut.fi IN TXT "Lappeenranta University of Technology, Finland" ;; ADDITIONAL SECTION: ns1.lut.fi IN A ns2.lut.fi IN A smtp1.cc.lut.fi IN A mail.funet.fi IN A mail.funet.fi IN A Received 326 bytes from #53 in 26 ms DNS: The Domain Name System root name server root name server Example: rlogin to a host (6) = PTR? (7) = NS (1) = A? (2) = NS (5) = TCP connection rlogin server (9) = PTR (8) = PTR? (4) = A rlogin client (3) = A? DNS: The Domain Name System (11) = A (10) = A? server s name server clients s name server 4

50 And some more Internatialization (wiki, Ficora) Dynamic DNS Alternative DNS roots Load distribution / Round robin with DNS DNS: The Domain Name System 5

51 TCP/IP Illustrated Vol. 1 The Protocols Chapter 17 - TCP: Transmission Control Protocol Introduction TCP provides a totally different service to the application layer than UDP does. TCP provides a connection-oriented, reliable, byte stream service. Connection-oriented means that two applications using TCP (i.e. client - server) must establish a TCP connection with each other before data can be exchanged. TCP - (c) Jouni Ikonen / TCP - (c) Jouni Ikonen / Introduction Reliability is provided by doing the following : the data is divided to segments use of timer in sending segments use of acknowledgements use of checksums for header and data (detection) use of resequencing of IP datagrams discarding of duplicate IP datagrams use of flow control IP header IP & TCP IP datagram TCP header 20 bytes 20 bytes TCP segment TCP data TCP header is 20 bytes if no options are present! TCP - (c) Jouni Ikonen / TCP - (c) Jouni Ikonen / TCP Header TCP Header URG ACK PSH RST SYN FIN 16-bit source port number 32-bit sequence number 32-bit acknowledgement number Reserved ( 6 bits) 16-bit window size 16-bit TCP checksum 16-bit urgent pointer Options (if any) Data (if any) 4-bit header length 16-bit destination port number 20 bytes Each TCP segment includes the source and destination port number to identify the sender and receiver application. With source and destination IP addresses these uniquely identify each connection. This is sometimes also identified as a socket, rather used as an interface in programming TCP - (c) Jouni Ikonen / TCP - (c) Jouni Ikonen / 1

52 TCP Header Sequence number identifies the byte in the stream of data from the sending TCP to the receiving TCP that the first byte of data in this segment represents. Sequence number is ISN+1! Flags : SYN (when a new connection is established [18]) FIN (when a sender is finished sending data) ACK (the acknowledgement number is valid) ---> SN+1 URG (the urgent pointer is valid [20.8]) RST (reset the connection [18.7]) PSH ( the receiver should pass this data to the application as soon as possible [20.5]) TCP - (c) Jouni Ikonen / TCP Header TCP provides a full-duplex service to the application layer TCP can be described as a sliding window protocol without selective or negative ACK s. The header length gives the length of the header in 32-bit words (limit 60 bytes with options). TCP flow control is provided by each end advertising a window size. The checksum covers the TCP segment (header+data), calculated as for UDP checksum. The urgent pointer is valid if URG flag is set, is a way to send emergency data to the other end. The most common option field is the maximum segment size option, called the MSS. TCP - (c) Jouni Ikonen / 2

53 TCP/IP Illustrated Vol. 1 The Protocols Chapter 18 - TCP Connection Establishment and Termination Introduction TCP is a connection-oriented protocol. Before either end can send data to the other, a connection must be established between them. This establishment differs from a connectionless protocol such as UDP. handshaking procedure to establish a connection an example : telnet host ---> (tcpdump reveals) source > destination : flags TCP2 - (c) Jouni Ikonen / TCP2 - (c) Jouni Ikonen / Introduction Connection establishment protocol : The client sends a SYN segment specifying the port number of the server that the client wants to connect to, and the client s ISN. (1) The server responds with its own SYN segment containing its own ISN. The server also ACKs the client s SYN by ACKing the client s ISN+1. A SYN consumes one sequence number. (2) The client must ACK this SYN from the server by ACKing the server s ISN+1 (3) Introduction Connection termination protocol : takes 4 segments instead of 3 (establishment), because each side must be shut down independently either side can trigger termination by sending FIN segment when it has ended sending of its data, and both sides must ACK the termination of data flow TCP2 - (c) Jouni Ikonen / TCP2 - (c) Jouni Ikonen / Introduction Both protocols can work active open, but here the one that initiated the SYN or FIN was active open and the other passive open. Sending SYN or FIN segments consumes one sequence number Introduction A > B : S : (0) win 4096 <mss 1024> B > A : S : (0) ack win A > B :. ack win A > B : F : (0) ack win B > A :. ack win B > A : F : (0) ack win A > B :. ack win 4096 TCP2 - (c) Jouni Ikonen / TCP2 - (c) Jouni Ikonen / 1

54 Timeout of connection establishment There are several instances, when connection cannot be established (i.e. plug out the cable) A > B : S : (0) win 4096 <mss 1024> A > B : S : (0) win 4096 <mss 1024> A > B : S : (0) win 4096 <mss 1024> Most systems set a time-limit for the establishment, i.e. Berkeley uses 75 seconds TCP2 - (c) Jouni Ikonen / MSS The maximum segment size (mss) is the largest amount of data that sender is willing to receive. Each end tells its MSS in connection establishment, if MSS is not in SYN received --> default 536! In general the larger the better until fragmentation does occur 1024 seen in examples because Berkeley systems use multiples of 512! TCP2 - (c) Jouni Ikonen / TCP Half-close TCP provides the ability for one end of a connection to terminate its output while still receiving data from the other end. Some applications take an advantages of this feature, i.e. rsh command TCP state transition diagram Picture: TCP/IP Illustrated volume 1 TCP2 - (c) Jouni Ikonen / TCP2 - (c) Jouni Ikonen / TCP state transition diagram Notes! What happens when a server does the active close and ends up to 2MSL timeout? * can t bind local address: address already in use What happens when a client does the active close and we know in which port it is allocated * can t bind local address: address already in use What happens when a server is rerun with SO_REUSEADDR option and client is run from other host in most berkeley machines * can bind local address, which is against TCP specification TCP2 - (c) Jouni Ikonen / Reset Segments Reset bit in header is sent by TCP whenever a segment arrives that does not appear correct for the referenced connection a common case for generating a reset is when a connection request arrives and no process is listening on the destination port A > B : S : (0) win 4096 <mss 1024> B > A : R 0:0 (0) ack win 0 TCP2 - (c) Jouni Ikonen / 2

55 Reset Segments Reset bit in header reset can be used to abort a connection (connection was reset by peer) Reset Segments Reset bit in header reset can be used to detect a half-open connection (other end crashed) A > B : S : (0) B > A : S : (0) ack A > B :. ack A > B : P 1:14 (13) ack B > A :. ack A> B : R 14:14 (0) ack A > B : S : (0) B > A : S : (0) ack A > B :. ack A > B : P 1:14 (13) ack B > A :. ack A> B : P 14:28 (13) ack B > A arp-request A > B arp-reply B > A : R : (0) TCP2 - (c) Jouni Ikonen / TCP2 - (c) Jouni Ikonen / Simultaneous open & close It is possible (although not probable) for 2 applications to both perform an active open to each other at the same time Each end must send a SYN, and the SYNs must pass each other on the network. It also requires each end to have a local port number that is well-known. TCP was designed to perform these simultaneous opens and therefore only 1 connection is needed. It is also possible to generate a simultaneous open. Like same manner simultaneous close can be performed. TCP options The TCP header can contain options : in original TCP specification are the end of option list no operation maximum segment size newer RFCs define additional TCP options (i.e) window scale factor timestamp TCP2 - (c) Jouni Ikonen / TCP2 - (c) Jouni Ikonen / TCP options TCP options Every option begins with 1-byte kind that specifies the type of option Some options include len field that is the total length of kind & len bytes no operation option enables the sender to insert pad fields of 4 bytes (this option can be in several places) maximum segment size is set to 512, unless modified TCP2 - (c) Jouni Ikonen / End of options list No operation Maximum segment size Window scale factor Timestamp kind=0 1 byte kind=1 1 byte kind=2 len=4 1 byte 1 byte mss 2 bytes kind=3 len=3 shift count 1 byte 1 byte 1 byte kind=8 len=10 timestamp value 1 byte 1 byte 4 bytes TCP2 - (c) Jouni Ikonen / timestamp echo reply 4 bytes nack rfc 2018? rfc 3517? 3

56 TCP Server design See using netstat -a -n -A inet how TCP server handles port numbers a : all end points in network n : IP address without DNS A : only TCP/UDP end points are reported How to implement restrictions? One client, one local interface, all connections Incoming connection request queue? How does TCP handle these calls while the listening application is busy TCP2 - (c) Jouni Ikonen / 4

57 TCP/IP Illustrated Vol. 1 The Protocols Chapter 19 - TCP Interactive Data Flow TCP Interactive Data Flow 90 % Bulk data (FTP, mail, news,...). 10 % Interactive (telnet, rlogin, ). Different algorithms in TCP for bulk and interactive data: Delayed acknowledgements. Nagle algorithm. TCP Interactive Data Flow - (c) Jouni Ikonen / TCP Interactive Data Flow - (c) Jouni Ikonen / Interactive Input rlogin (as an example): keystrokes normally send in separate packets. 1 keystroke generates a packet of 41 bytes. keystroke display data byte ack echo of data byte ack server echo Delayed Acknowledgments TCP does not normally send ACK as it receives a data segment. It hopes that it will have a data going back in a little while and it can piggyback ACK with it. ACK s can be delayed up to 500 ms, but normally 200 ms used. TCP Interactive Data Flow - (c) Jouni Ikonen / TCP Interactive Data Flow - (c) Jouni Ikonen / Nagle Algorithm [RFC896] Small packets can congest wide are networks. => Solution Nagle Algorithm. Nagle Algorithm: When a TCP connection has outstanding data that has not yet been acknowledged small segments cannot be sent until the outstanding data is acknowledged. Small amounts of data is collected and sent in single segment as ACK arrives. Self clocking (faster ACKs arrive, faster data is sent). Disabling Nagle Algorithm Real time applications need fast packet delivery X mouse movements TCP_NODELAY TCP Interactive Data Flow - (c) Jouni Ikonen / TCP Interactive Data Flow - (c) Jouni Ikonen /

58 Summary Interactive data normally send in small segments. Delayed ACKs used by receiver to see if ACKs can be piggybacked. Nagle used to reduce number of small segments. TCP Interactive Data Flow - (c) Jouni Ikonen /

59 TCP/IP Illustrated Vol. 1 The Protocols Chapter 20 - TCP Bulk Data Flow Introduction TCP uses flow control called a sliding windows protocol sender transmits multiple packets before it stops and waits for an acknowledgement faster data transfer TCP s PUSH flag Slow start Bulk data throughput TCP Bulk Data Flow - (c) Jouni Ikonen / TCP Bulk Data Flow - (c) Jouni Ikonen / Normal Data Flow sender Data Flow PSH 1:1025(1024) ack 1, win 4096 PSH 1025:2049(1024) ack 1, win 4096 PSH 2049:3073(1024) ack 1, win 4096 receiver Creating a connection The sender transmits data segments The receiver acknowledges Terminating a connection ack 2049, win 4096 PSH 3073:4097(1024) ack 1, win 4096 PSH 4097:5121(1024) ack 1, win 4096 ack 4097, win 4096 PSH 5121:6145(1024) ack 1, win 4096 ack 5121, win 4096 PSH 6145:7169(1024) ack 1, win 4096 PSH 7169:8193(1024) ack 1, win 4096 ack 7169, win 4096 FIN 8194:8194(1024) ack 1, win 4096 TCP Bulk Data Flow - (c) Jouni Ikonen / ack 8194, win TCP 4096 Bulk Data Flow - (c) Jouni Ikonen / Fast Sender, Slow Receiver Fast Sender, Slow Receiver sender PSH 1:1025(1024) ack 1, win 4096 PSH 1025:2049(1024) ack 1, win 4096 PSH 2049:3073(1024) ack 1, win 4096 PSH 3073:4097(1024) ack 1, win 4096 ack 4097, win 0 ack 4097, win 4096 PSH 4097:5121(1024) ack 1, win 4096 PSH 5121:6145(1024) ack 1, win 4096 PSH 6145:7169(1024) ack 1, win 4096 FIN,PSH 7169:8193(1024) ack 1, win 4096 ack 8194, win 0 ack 8194, win 4096 TCP Bulk Data Flow - (c) Jouni Ikonen / receiver The sender transmits 4 data segments stops and waits for an ACK. The receiver sends the ACK, but the advertised window is 0. This means the receiver has all the data, but it s all in the receiver s TCP buffers Another ACK is sent later The receiver can now receive another 4096 bytes. This looks like an ACK, but is called a window update. TCP Bulk Data Flow - (c) Jouni Ikonen / 1

60 Sliding Windows offered window (advertised by receiver) usable window sent and acknowledged sent, not acknowledged can send ASAP TCP Bulk Data Flow - (c) Jouni Ikonen / can t send until window moves The window closes : Sliding Windows the left edge advances to the right, data is sent and acknowledged. The window opens : the right end moves to the right, allowing more data to be sent. The window shrinks : the right end moves to the left. The Host Requirements RFC strongly discourages this, but TCP must be able to cope with a peer, that does this. TCP Bulk Data Flow - (c) Jouni Ikonen / Window Size The size of the window offered by the receiver can usually be controlled by the receiving process how many data segments (bytes) receiving application can process PUSH Flag It s a notification from the sender to the receiver for the receiver to pass all the data that it has to the receiving process. Usually set when send buffer empties. This data could consist of whatever is in the segment with the PUSH flag, along with any other data. TCP Bulk Data Flow - (c) Jouni Ikonen / TCP Bulk Data Flow - (c) Jouni Ikonen / Slow Start If there is routers and slower links between the sender and the receiver, problems can arise. It operates by observing that the rate at which new packets should be injected into the network is the rate at which the acknowledges are returned by the other end. Slow Start adds another window to the sender s TCP : the congestion window, called cwnd. TCP Bulk Data Flow - (c) Jouni Ikonen / Slow Start When connection is with host on another network cwnd is initialized to one segment Each time an ACK is received, the cwnd is increased by one segment The sender can transmit up to the minimum of the cwnd and the advertised window. The cwnd is flow control imposed by the sender, while the advertised window is flow control imposed by the receiver. RFC 2581 recommends that slow start should also be used if no data has been sent for more than one RTO (retransmission time out). Otherwise an idle connection can flood the network. TCP Bulk Data Flow - (c) Jouni Ikonen / 2

61 Bulk Data Throughput Interaction of the window size, the windowed flow control, and slow start on the throughput of a TCP connection carrying bulk data. Bandwidth-Delay Product capacity(bits)=bandwidth(bits/sec)*rtt(sec) Congestion can occur when data arrives on a big pipe (a fast LAN) and gets sent out a smaller pipe, or when multiple streams arrive at a router whose output capacity is less than the sum of the inputs. TCP Bulk Data Flow - (c) Jouni Ikonen / Urgent Mode Allow one end to tell the other end that urgent data of some form has been placed into the normal stream of data. The URG-bit is turned on and the 16-bit urgent pointer is set to a positive offset that must be added to the sequence number field in the TCP header to obtain the sequence number of the last byte of the urgent data. Where to use (most commonly) : Telnet/rlogin : interrupt key TCP Bulk Data Flow - (c) Jouni Ikonen / FTP : a file transfer abort Definition difference between BSD & RFC! man tcp tcp_stdurg Enable the strict RFC793 interpretation of the TCP urgent- pointer field. The default is to use the BSD-compatible interpretation of the urgent-pointer, pointing to the first byte after the urgent data. The RFC793 interpretation is to have it point to the last byte of urgent data. Enabling this option may lead to interoperatibility problems. TCP Bulk Data Flow - (c) Jouni Ikonen / 3

62 TCP/IP Illustrated Vol. 1 The Protocols Chapter 21 - TCP Timeout and Retransmission TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission TCP provides reliable transport layer: Acknowledge of received data Timeout Timeout and retransmission policy critical for efficient operation. How to determine timeout timeout interval? How frequently does a retransmission occur? TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission TCP manages four different timers for each connection: A retransmission timer is used when expecting an acknowledgement from the other end (exponential backoff). A persist timer keeps window size information flowing. A keepalive timer detects when other end of an idle connection has crashed. A 2MSL timer measures the time a connection has been in the TIME_WAIT state. Round-Trip Time (RTT) Measurement Measuring RTT is necessary for TCP timeout and transmission. RTT changes over time Measure RTT between sending a byte with a particular sequence number and receiving ACK which covers the sequence number. Only one RTT calculation / connection / time (usually). TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission - (c) Jouni Ikonen / Original TCP RTT Measurement R αr + (1 - α)m Round trip estimator, R Smoothing factor, alpha (recommended value 0.9) Measured round trip time, M RTO = Rβ Recommended retransmission time out, RTO Delay variance factor (recommended value 2) TCP Timeout and Retransmission - (c) Jouni Ikonen / Problems with original RTT Can not keep up with wide fluctuations in RTT => unnecessary retransmissions. Improvements proposed by Jacobson TCP should keep track of variance in measured RTT times. RFC 2988 states that RTO should always be at least 1 second (which it does if 500 ms clock ticks are used). TCP Timeout and Retransmission - (c) Jouni Ikonen /

63 Err = M - A A A+ gerr Improved RTT Difference between measured (M) and current RTT estimator (A), Err Smoothed RTT, A Gain, g (set to 1/8) Improved RTT D D + h ( Err - D) RTO = A +4D Smoothed mean deviation, D The gain for deviation h (set to 1/4). Calculation can be done with integers. TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission - (c) Jouni Ikonen / Karn s Algorithm A problem: A packet is transmitted, a timeout occurs, the RTO is backed off. Packet is retransmitted with the longer RTO, and an acknowledgement is received. Does the ACK belong to first or second transmission. Solution: Do not calculate a new RTO until an ACK is received for a segment that was not retransmitted. This is requirement since RFC RTT estimator calculations Initializations of A=0 and D=3. Initial retransmission timeout is calculated using formula RTO = A+2D = 0 + 2*3 = 6s. Later 4D is used instead of 2D. After first timeout RTO = A + 4D = 0 +4*3 = 12 seconds. Exponential backoff is applied to RTO, which gives 24 seconds as next timeout. Next timeout is calculated using multiplier 4, which gives 4 * 12 seconds = 48 seconds. TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission - (c) Jouni Ikonen / RTT estimator calculations First initialization RTT variables. If a ACK for a data segment arrives after 3 clock ticks our estimators are initialized: A = M =500 ms/tick * 3 ticks = 2 D = A / 2 = 1 RTO = A + 4D = 2 + 4*1 = 6 seconds. RTT estimator calculations When next ACK of timed data segment arrives (now 1 clock tick was counted). Err = M A = = -1.5 A = A + gerr = x 1.5 = D = D +h( Err - D) = *(1.5 1)=1.125 RTO = A + 4D = *1.125 = Fixed point calculations are used in reality A bit different result. TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission - (c) Jouni Ikonen /

64 In RFC2001 (Later written into RFC2581) In RFC2001 (Later written into RFC2581) Congestion Avoidance Assumption: Packet loss indicates congestion. Two indications of packet loss: timeout. duplicate ACKs. Congestion avoidance and slow start are independent algorithms with different objectives. TCP Timeout and Retransmission - (c) Jouni Ikonen / Congestion Avoidance In case of congestion we want slow down the transmission and apply slow start to get things going again. Congestion avoidance and slow start are usually implemented together. Both algorithms require two variables maintained for each connection: Congestion window, cwnd a slow start threshold size, ssthresh TCP Timeout and Retransmission - (c) Jouni Ikonen / In RFC2001 (Later written into RFC2581) In RFC2001 (Later written into RFC2581) TCP Congestion Avoidance & Slow Start Combined Algorithm For a connection initialize cwnd to 1 segment and ssthresh to bytes. Newer send more than the minimum cwnd and the receiver s advertised window. cong. avoid. is flow control by sender. advertised window is flow control by receiver. In case of congestion, one-half of the current window size is saved in ssthresh and if congestion is indicated by timeout cwnd is set to one segment. TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Congestion Avoidance & Slow Start Combined Algorithm When new data is acknowledged by other end, cwnd is increased depending on if slow start or congestion avoidance is performed. If cwnd ssthresh, slow start is performed. This is continued until half way to where congestion occurred, and then congestion control takes over. Slow start sets cwnd at one segment at start, and to be incremented by one segment every time an ACK is received. (exponential window size growth). TCP Timeout and Retransmission - (c) Jouni Ikonen / In RFC2001 (Later written into RFC2581) TCP Congestion Avoidance & Slow Start Combined Algorithm Congestion avoidance dictates that cwnd is incremented by 1/cwnd, each time an non retransmitted ACK is received. TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission - (c) Jouni Ikonen / ( )

65 In RFC2001 (Later written into RFC2581) In RFC2001 (Later written into RFC2581) Fast Retransmit Algorithm Receiving duplicate ACKs Modifications to congestion avoidance algorithm were proposed by Jacobson. TCP SHOULD generate an immediate (duplicate) ack when an out-of-order segment is received. This is to let other end to know that a segment was received out-of-order, and tell what sequence number is expected (RFC 2581). Expect that if less than 3 out-of-order ACKs are received, segments were just not received in order. If three or more duplicate ACKs are received in a row, the TCP sender believes that a segment has been lost. Then TCP performs a retransmission of what seems to be the missing segment, without waiting for a timeout to happen. This can fix losses of single segments 1 st duplicate 2 nd duplicate 3 rd duplicate ACK=1024 ACK=1024 ACK=1024 ACK=1024 1k SeqNo=0 1k SeqNo=1024 1k SeqNo=2048 1k SeqNo=3072 1k SeqNo=4096 1k SeqNo=1024 1k SeqNo=5120 TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission - (c) Jouni Ikonen / In RFC2001 (Later written into RFC2581) Fast Recovery Algorithm Explicit Congestion Notification Done after fast retransmit. When third duplicate ACK is received set sstresh to onehalf the current congestion window, cwnd. Retransmit the missing segment. Set cwnd to ssthresh plus 3 times the segment size. (Actually sstresh + number of segments in receivers buffers). Each time a duplicate ACK arrives, increase cwnd by the segment size and transmit a packet (if allowed by new value of cwnd). When the next ACK arrives that acks new data, set cwnd to ssthresh. This should be the ACK of the retransmitted segment after 1 RTT. TCP Timeout and Retransmission - (c) Jouni Ikonen / ECN - another method for congestion avoidance (RFC 3168) Routers can mark bypassing packets to indicate that route is becoming congested. Is used to give prior notification to hosts to slow down before packets start to be dropped. TCP Timeout and Retransmission - (c) Jouni Ikonen / Explicit Congestion Notification Uses bits 6 and 7 in TOS field in IPv4 header (previously unused). Bit 6 indicates that hosts are ECN aware. Bit 7 congestion experienced (CE), is set when router is congested and endpoints are ECN aware. Receive of CE host trigger congestion avoidance and halve congestion window. Explicit Congestion Notification ECN adds two flags to TCP header: ECN-Echo (ECE) Congestion window reduced (CWR) Use of ECN is negotiated during SYN handshake. Unfortunately all routers do not understand ECN and treat ECN packets as corrupt due to new bits in TOS. TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission - (c) Jouni Ikonen /

66 ICMP Errors How does TCP handle ICMP errors? Most common errors: source quench, host unreachable and network unreachable. In current Berkley-based implementations: A received source quench causes the congestion window, cwnd, to be set to one segment to initialize slow start. Slow start threshold, sstresh is not changed, so window will open all the way. ICMP Errors A received host or network unreachable is ignored as they are considered transient messages. An intermediate router can be down and TCP keeps trying. TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission - (c) Jouni Ikonen / Repacketization When TCP times out and retransmits, it does not have to send identical segments. It can repacket segments to try to increase throughput. This is possible because data is identified by bytes not segments. Notes Congestion avoidance assumes that all packet loss is caused by congestion. If not TCP/IP (as shown in RFC3155) interacts badly with Slow Start with Congestion avoidance, etc. Extra term (e.g. MSS/8) used for cwnd updates in some cases is bad (RFC2525) and forbidden by RFC TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission - (c) Jouni Ikonen / 1k SeqNo=0 ACK=1024 1k SeqNo=1024 1k SeqNo= st duplicate 2 nd duplicate 3 rd duplicate ACK=1024 ACK=1024 ACK=1024 1k SeqNo=3072 1k SeqNo=4096 1k SeqNo=1024 1k SeqNo=5120 TCP Timeout and Retransmission - (c) Jouni Ikonen / TCP Timeout and Retransmission - (c) Jouni Ikonen /

67 TCP/IP Illustrated Vol. 1 The Protocols Chapter 22 - TCP Persist Timer TCP Persist Timer - (c) Jouni Ikonen / Introduction Receiver perform flow control by specifying the amount of data it is willing to accept from the sender : the window size. If window size goes to 0 : the sender stops sending data. ACKs are not reliably transmitted, and if ACK is lost : The receiver waiting to receive data. The sender waiting to receive the window update. To prevent from that deadlock, sender uses a persist timer. TCP Persist Timer - (c) Jouni Ikonen / Persist Timer The sender uses a persist timer that causes it to query the receiver periodically, to find out if the window has been increased. These segments from the sender are called window probes. They are send as long as needed no timeout.. The normal TCP exponential backoff is used to calculate the persist timer The first timeout is calculated as 1.5 sec for typical LAN connection. This is multiplied by 2 for a second timeout value of 3 sec A multiplier of 4 gives value of 6; 8 12; and so on The Persist timer is always bounded between 5 and 60 seconds. TCP Persist Timer - (c) Jouni Ikonen / Persist Timer B > A ack 9217 win A > B 9217:9218(1) ack 1 win B > A ack 9217 win A > B 9217:9218(1) ack 1 win B > A ack 9217 win A > B 9217:9218(1) ack 1 win B > A ack 9217 win A > B 9217:9218(1) ack 1 win B > A ack 9217 win A > B 9217:9218(1) ack 1 win B > A ack 9217 win A > B 9217:9218(1) ack 1 win B > A ack 9217 win A > B 9217:9218(1) ack 1 win B > A ack 9217 win A > B 9217:9218(1) ack 1 win B > A ack 9217 win A > B 9217:9218(1) ack 1 win 4096 TCP Persist Timer - (c) Jouni Ikonen B > A ack 9217 win 0 / Silly window syndrome Windows based flow control schemes can suffer from silly windows syndrome (SWS). In SWS small amounts of data are exchanged instead of full sized segments. Syndorome can be caused receiving or sending end. Avoidance must be performed by both ends. SWS algorithm for receiver Receiver must not advertise small windows. Normal algorithm is that sender: do not advertise larger window than it is currently advertising unless it can be increased with full (MSS) sized segment or by one half of receivers buffer space, whichever is smaller. TCP Persist Timer - (c) Jouni Ikonen / TCP Persist Timer - (c) Jouni Ikonen / 1

68 Receiver SWS Avoidance in the TCP Spec, RFC 1122 The receiver's SWS avoidance algorithm determines when the right window edge may be advanced; For realistic receive buffers (greater than twice the MSS) window advances are announced in increments of MSS. A TCP SHOULD implement a delayed ACK the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment. SWS algorithm for sender Do not transmit unless: Full sized segment can be sent, or We can send at least one-half of the maximum sized window what other end advertised, or We can send everything what we have and either we are not expecting an ACK or the Nagle algorithm is disabled for the connection. TCP Persist Timer - (c) Jouni Ikonen / TCP Persist Timer - (c) Jouni Ikonen / Sender SWS Avoidance in the TCP Spec A TCP SHOULD implement [Nagle 84] to coalesce short segments. However, there MUST be a way for an application to disable the Nagle algorithm on an individual connection. The Nagle algorithm is : If there is unacknowledged data then the sending TCP buffers all user data until the outstanding data has been acknowledged or until the TCP can send a full-sized segment TCP Persist Timer - (c) Jouni Ikonen / 2

69 TCP/IP Illustrated Vol. 1 The Protocols Chapter 23 - TCP Keepalive Timer TCP Keepalive Timer - (c) Jouni Ikonen / Introduction In TCP/IP no data whatsoever flows across an idle connection. We can start client process that establishes TCP connection with a server. Intermediate routers can crash and reboot, but as long as neither hosts at the ends of the connection reboots, the connection remains established. There are times however, when a server wants to know if the client s host has either crashed and is down or crashed and rebooted. The keepalive timer provides this capability TCP Keepalive Timer - (c) Jouni Ikonen / Introduction The keepalive option can cause an otherwise good connection between two process to be terminated because of a temporary loss of connectivity in the network. For server applications that might tie up resources of behalf of a client, and want to know if the client host crashes. Normally set by servers. can also be set by client or by both ends of a connection. TCP Keepalive Timer - (c) Jouni Ikonen / Description If no activity for 2 hours, the server sends keepalive timer probe segment to the client. The client must be in one of four states : The Client host is still up and running, and reachable. The server s TCP will reset the keepalive timer for 2 hours in the future. The client host has crashed and is down/rebooting, the server gets no response to its probe and it times out after 75 seconds. The server sends a total of 10 of these probes, and if not receive response it terminates the connection. TCP Keepalive Timer - (c) Jouni Ikonen / Description The client host has crashed and rebooted. Here the server receive a response to its probe, but it will be a reset, causing the server to terminate the connection. The client host is up and running, but unreachable from the server. This is the same as scenario 2, because TCP can t distinguish between the two. All it can tell is that no replies to its probes. TCP-layer handles keepalive timers (transparent to the application (1)), only errors are reported to the application process (2, 3, 4). TCP Keepalive Timer - (c) Jouni Ikonen / 1

70 TCP/IP Illustrated Vol. 1 The Protocols Chapter 24 - TCP Futures and Performance TCP Futures and Performance - (c) Jouni Ikonen / TCP Futures, today and performance Modifications to the TCP allow maximum throughput at high speeds. path MTU discovery (RFC 1191) window scale option (RFC 1323 Large windows) timestamp option Selective acknowledgements (SACK, RFC2018). Buffer sizes (on the host, max. buffer, application). T/TCP, TCP for Transactions TCPtuning. TCP Futures and Performance - (c) Jouni Ikonen / Path MTU Discovery (TCP) To enable using larger packets than 536 bytes on nonlocal connections => increased throughput. Algorithm: Establish connection with other end. Set don t fragment bit in the IP header Send packet with size of MTU of outgoing interface or the MSS announced by the other end (if not specified default is 536). Path MTU Discovery (TCP) If intermediate router can not handle this it discards the packet and send ICMP error back. Try with smaller packet size. If newer form of ICMP error is used, set packet size to one announced (minus IP and TCP headers) the intermediate router can handle. In case of this ICMP error congestion window should not change, but slow start should be initialized. TCP Futures and Performance - (c) Jouni Ikonen / TCP Futures and Performance - (c) Jouni Ikonen / Long fat pipes Bandwidth delay product capacity (bits) = bandwidth (bits / s) * round trip time (sec). Network with large bandwidth delay product are called long fat networks (LFNs) 5,994,210 bytes to send 5,790 bytes in the pipe 8 ms 1,544,000 bit/s 1 Gbit/s 30 ms latency 1,000,000 bytes TCP Futures and Performance - (c) Jouni Ikonen / Bandwidth-delay product Network Bandwidth (bits/sec) Roundtrip time (ms) Bandwidthdelay product (bytes) Ethernet LAN 10,000, ,750 T1, transcont. 1,544, ,580 T1, satellite 1,544, ,500 T3, transcont. 45,000, ,500 gigabit, transcont. 1,000,000, ,500,000 TCP Futures and Performance - (c) Jouni Ikonen /

71 Problems with long fat pipes (1) TCP window size is 16 bit field (65535 bytes). Larger window required for current networks. Solution: window scale option. Problems with long fat pipes (2) Packet loss can reduce throughput drastically. If one segment lost, fast retransmit and fast recovery algorithms are required to keep the pipe from draining. if more than 1 segment lost, window will be drained. It will take multiple RTTs from slow start to get pipe filled again. Selective ACKs have been proposed as a solution, but no final solution has been presented. TCP Futures and Performance - (c) Jouni Ikonen / TCP Futures and Performance - (c) Jouni Ikonen / Problems with long fat pipes (3) RTT measured only once per window. Better RTT measurements are required for operating on LFN. Solution: Timestamp option allows more segments be timed (including retransmissions). Problems with long fat pipes (4) TCP identifies each byte with 32 bit sequence number. How to prevent a delayed segment from closed connection from appearing on a new connection (same hosts and ports). Problem arises if sequence number N will be reused less than MSL time. E.g., in gigabit Ethernet it takes 34 second to use all sequence numbers. TCP Futures and Performance - (c) Jouni Ikonen / TCP Futures and Performance - (c) Jouni Ikonen / Problems with long fat pipes (4) Solution: Protection against wrapped sequence numbers (PAWS). Uses TCP timestamp option. Window scale option Increases definition of the TCP window from 16 to 32-bits. No changes to TCP header. Option applies a scaling operation to the 16- bit value. TCP maintains real window size internally as a 32-bit value. 1 byte shift count is between 0 and 14 => max. window is 65535*2 14 TCP Futures and Performance - (c) Jouni Ikonen / TCP Futures and Performance - (c) Jouni Ikonen /

72 Window scale option Option can appear only in a SYN segment. Both ends must set to enable the option. Scale factor can be different in each direction. Timestamp option Lets sender to place a timestamp value to every segment. Receiver reflects this value in the acknowledgement allowing sender to calculate an RTT for each received ACK. This improves RTT calculation and is needed for large windows. TCP header size increases from 20 to 32-bytes. TCP Futures and Performance - (c) Jouni Ikonen / TCP Futures and Performance - (c) Jouni Ikonen / Timestamp option Timestamp is a monotonically increasing value (some systems increase it every 500ms). Receiver echoes in value Enabled in SYN packets. Single timestamp value is kept per connection. Timestamp option 1. TCP keeps track of timestamp value to send in next ACK (a variable named tsrecent) and the acknowledgement sequence number from the last ACK that was sent (a variable named lastack). This sequence number is the next sequence number receiver is expecting. TCP Futures and Performance - (c) Jouni Ikonen / TCP Futures and Performance - (c) Jouni Ikonen / Timestamp option 2. When a segment arrives, if the segment contains the byte numbered lastack, then the timestamp value from the segment is saved in tsrecent. 3. Whenever a timestamp option is sent, tsrecent is sent as the timestamp echo reply field and the sequence number field is saved in lastack. TCP Futures and Performance - (c) Jouni Ikonen / Timestamp option The algorithm handles following 2 cases: 1. If ACKs are delayed by the receiver, the timestamp value returned as the echo value will correspond to the earliest segment being acknowledged. 2. If received segment is in-window but out-ofsequence, implying that previous segment has been lost, when that missing segment is received, its timestamp will be echoed, not the timestamp from the out-of-sequence segment. TCP Futures and Performance - (c) Jouni Ikonen /

73 PAWS Protection Against Wrapped Sequence Numbers (PAWS). Needed when sequence numbers are used in less than MSL time. Timestamp option provides PAWS, by checking that timestamp is monotonically growing. This way a segment from a old connection can be recognized. TCP Futures and Performance - (c) Jouni Ikonen / SACK TCP Selective Acknowledgments (SACK, RFC2018): SACKs allow a receiver to acknowledge non-consecutive data. This is particularly helpful on paths with a large Bandwidth-Delay-Product (BDP). While SACK is now supported by most operating systems, it may have to be explicitly turned on by the system administrator. Additional information on commercial and experimental implementations of SACK is available at TCP Futures and Performance - (c) Jouni Ikonen / Alternatives to TCP T/TCP TCP for transactions SCTP- Stream control transmission protocol Stream control transmission protocol RFC 4960 & RFC 3286 SCTP can deliver multiple message streams within a single connection. Better utilization of bandwidth. SCTP allows for transparent multi-homing, where both ends of connection are multi-homed. If one end point fails SCTP can automatically switch from one endpoint to another. TCP Futures and Performance - (c) Jouni Ikonen / TCP Futures and Performance - (c) Jouni Ikonen / Stream control transmission protocol SCTP preservers message boundaries, i.e. it is message oriented (vs. TCP which is stream oriented). SCTP can (if chosen to) provide unordered reliable delivery. Validation and Acknowledgment mechanisms - Protects against flooding attacks and provides notification of duplicated or missing data chunks. Improved error detection suitable for jumbo Ethernet frames. T/TCP A TCP extension for transactions (rfc 1644). Tcp provide a virtual-circuit service. This is however too heavy for some applications. In transactions, overhead of connection establishment and termination should be avoided, latency should be RTT + processing time and server should detect duplicate requests. TCP Futures and Performance - (c) Jouni Ikonen / TCP Futures and Performance - (c) Jouni Ikonen /

74 T/TCP TCP uses 7 segments to open and terminate a connection. T/TCP modifies the 3-way handshake by accelerated open: 1. It assigns a global (in the host) 32-bit connection count (CC) value for each connection it opens. Incremented by 1 each time it is used. TCP Futures and Performance - (c) Jouni Ikonen / T/TCP 2. Every segment send between two hosts include the new T/TCP option named CC. 3. A host maintains a per-host cache of the last CC value received in an acceptable SYN segment from that host. 4. When a CC is received in SYN packet, receiver compares it to value in the cache. If the value is larger than in cache, packet is passed to the application. Otherwise a normal 3-way handshake is used. TCP Futures and Performance - (c) Jouni Ikonen / T/TCP 5. The SYN, ACK segment in response to an initial SYN echoes the received CC value in another new option named CCECHO. 6. The CC value in a non-syn segment detects and rejects any duplicate segments from previous incarnations of the same connection. Accelerated open avoids 3-way handshake unless client or server has rebooted. T/TCP The TIME_WAIT state is shortened by calculating the TIME_WAIT dynamically, based on RTT and is set 8 times retransmission timeout (RTO). Transaction sequence is reduced to 3 segments. 1. Client sends packet with SYN, data, FIN and CC TCP Futures and Performance - (c) Jouni Ikonen / TCP Futures and Performance - (c) Jouni Ikonen / T/TCP 2. Server responds with SYN, data, FIN, ACK, server- CC and CCECHO of client-cc. 3. Client responses server with ACK of server-fin, which acknowledges SYN, data and FIN. Only RTT + processing time to get answer! T/TCP requires only minimal changes to TCP. Alternative is Versatile Message Transaction Protocol (VMTP, rfc 1045), which is a complete transport layer that uses IP. TCP Performance Upper limit on how fast TCP can run is the size of the TCP window and the speed of light. Most performance problems are implementation deficiencies. TCP Futures and Performance - (c) Jouni Ikonen / TCP Futures and Performance - (c) Jouni Ikonen /

75 Summary 5 new TCP features: Path MTU discovery => larger packet sizes Window scale option => LFN timestamp option => LFN Protection against wrapped sequence numbers (PAWS) => LFN improved transaction processing (T/TCP) TCP Futures and Performance - (c) Jouni Ikonen /

76 TCP/IP Illustrated Vol. 1 The Protocols Chapter 25 - Simple Network Management Protocol Introduction As the number of networks grows, along with the diversity of systems (i.e. various vendors), managing all these systems becomes important. Network Management of a TCP/IP internet consists of network management stations (managers) communicating with network elements. The software in the network element that runs the management software is called the agent. Simple Network Management Protocol - (c) Jouni Ikonen / Simple Network Management Protocol - (c) Jouni Ikonen / Introduction The communication can be two way: the manager asking the agent for a specific value OR the agent telling the manager that something important happened. The manager can also set some variables in the agent. TCP/IP network management consists of three pieces : MIB (Management Information Base) (MIB-II RFC1213) SMI (Structure of Management Information) (RFC1155) SNMP (Simple Network Management Protocol) Introduction MIB specifies what variables the network elements maintain. SMI is a set of common structure and an identification scheme used to reference the variables in the MIB. The protocol between the manager and the network element is called SNMP. Although many protocols could be used for transport, UDP is used. Simple Network Management Protocol - (c) Jouni Ikonen / Simple Network Management Protocol - (c) Jouni Ikonen / SNMP versions Version 1 (RFC ) Poor security Version 2 (RFC ) Includes improvements in performance, security and manager-to-manager communications. Introduces GETBULK. Complex, not widely accepted Version 3 (RFC , STD0062) Provides authentication, privacy and access control Best Current Practice (RFC 3584) Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework Simple Network Management Protocol - (c) Jouni Ikonen / SNMP SNMP v1 defines 5 types of messages: get-request ( get a value of one or more variables) get-next-request ( get next value after one or more specified variables ) set-request ( set a value of one or more variables) get-response ( return the value of one or more variables) trap ( notify the manager when something happens on the agent ) SNMP v2 adds: Getbulk request (retrieve sequence of data) inform (an acknowledged trap) Simple Network Management Protocol - (c) Jouni Ikonen / 1

77 SNMP SNMP security SNMP Manager UDP Port 162 Get-Request Get-Response Get-Next-Request Get-Response Set-Request Get-Response SNMP Agent UDP Port 161 v1 & v2 subject to packet sniffing All versions are subject to brute force and dictionary attacks (do not implement challenge-response handshake) Subject to IP spoofing (commonly used over UDP) => By passing of access lists. Write capability is rarely used, but can be misconfigured. Trap Simple Network Management Protocol - (c) Jouni Ikonen / Simple Network Management Protocol - (c) Jouni Ikonen / IP datagram SNMP PDU types & errors UDP datagram SNMP Message IP UDP header header version community (0) PDU type (0-3) Common SNMP header clear text password 0 get-request PDU type (4) identifies query and response Index of variable where error was encountered Reguest ID error status (0-5) get/set header error name valuenamevalue index variables to get/set trap agent specific time enterprise type addr code name value stamp (0-6) trap header Variables PDU type Name get-request get-next request get-response set-request trap error status Name noerror toobig nosuchname badvalue readonly generr SNMP v1 Simple Network Management Protocol - (c) Jouni Ikonen / Simple Network Management Protocol - (c) Jouni Ikonen / SNMP SNMP uses only a few different types of data Integer (i.e MTU Size) OctetString (a string of 0 or more 8-bit bytes) DisplayString (a string of 0 or more 8-bit bytes) Object Identifier (e.g ) Null (variable has no value) IPAddress PhysAddress (i.e. ethernet address) Counter (from 0 to (2^32-1) ) Gauge (a nonnegative integer between counter value) Timeticks (a counter that counts time) Sequence (like in programming) and Sequence of Simple Network Management Protocol - (c) Jouni Ikonen / SNMP An object identifier is a data type specifying an authoritatively named object iso (1) Ccitt (0) Joint-iso-ccitt (2) org (3) dod (6) internet (1) Simple Network Management Protocol - (c) Jouni Ikonen / 2

78 SNMP The Management Information Base (MIB) is the database of information maintained by the agent that the manager can query or set. MIB is divided into many groups, like system (1), interfaces (2), address translation (3), Here we see UDP group more carefully! mgmt (2) mib (1) SNMP Every variable in the MIB must be identified when SNMP is referencing it (to get/set a value). However, only leaf nodes are referenced, which means that SNMP does not manipulate entire rows or columns etc. MIB uses lexicographic ordering (all instances for a given variable appear before all instances of the next variable), and ordering is dependant on the values of the indexes for the table. (column-row) udp (7) udpindatagrams (1) udpnoports (2) udpinerrors (3) udpoutdatagrams (4) udpentry (5) Simple Network Management Protocol - (c) Jouni Ikonen / Simple Network Management Protocol - (c) Jouni Ikonen / SNMP Some SNMP MIB Groups defined more carefully : System (1) consists of 7 simple variables (i.e. sysobjectid) Interface (2) has only one variable, ifnumber but it has a table with 22 columns (i.e ifindex) at (3) is mandatory for all systems, but newer MIB has its own address resolution tables. It consists of a single table of 3 columns (i.e. atnetaddress ) ip (4) defines numerous variables and 3 tables (i.e. ipforwarding), an example of a table is the IP address table. (note! Others, iproutetable and IPNetToMediaTable) icmp (5) consists of 4 general counters and 22 (i/o 11/11) counters for the different ICMP message types tcp (6) has a single table, tcpconntable. Group has many variables (I.e.tcpInSegs) SNMP TRAP messages TRAPs indicate that something has happened on the agent that the manager might want to know 6 specific traps are defined, with seventh one allowing a vendor to implement an enterprise-specific trap (i.e coldstart) In SNMPs formal specification ASN.1 and BER are used for the encoding ASN.1 is a formal language for describing data and properties of the data BER defines the representation of variables Simple Network Management Protocol - (c) Jouni Ikonen / Simple Network Management Protocol - (c) Jouni Ikonen / Example piece of MIB (RFC 1213) ifspeed OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth." ::= { ifentry 5 } man snmpcmd snmpcmd - commmands to communicate with a network entity using SNMP Requests. SEE ALSO: snmpget(1), snmpgetnext(1), snmpset(1), snmpbulkget(1), snmpbulkwalk(1), snmpwalk(1), snmptable(1), snmpnet-stat(1), snmpdelta(1), snmptrap(1), snmpinform(1), snm- pusm(1), snmpstatus(1), snmptest(1), snmp.conf(5). Simple Network Management Protocol - (c) Jouni Ikonen / Simple Network Management Protocol - (c) Jouni Ikonen / 3

79 snmpget snmpget [-Cf] [common arguments] ObjectID [ObjectID]... SNMP application that uses the SNMP GET request to query for information on a network entity. snmpget X.X public system.sysuptime.0 snmpset snmpset [common arguments] ObjectID type value [ObjectID type value] SNMP application that uses the SNMP SET request to set information on a network entity Type: i (INTEGER), u (UNSIGNED), s (STRING) snmpset X.X private system.syscontact.0 s [email protected] Simple Network Management Protocol - (c) Jouni Ikonen / Simple Network Management Protocol - (c) Jouni Ikonen / snmpwalk snmpwalk [options] <hostname>{[community]} [ObjectID] SNMP application that uses SNMP GETNEXT requests to query a network entity Retrieves lots of data, a part of MIB tree (subtree) at once snmpwalk X.X public system system.sysdescr.0 = system.sysobjectid.0 = system.sysuptime.0 = Simple Network Management Protocol - (c) Jouni Ikonen / 4

80 TCP/IP Illustrated Vol. 1 The Protocols Chapter 15 - TFTP: Trivial File Transfer Protocol TFTP Simple file transfer program Used in bootstrapping diskless systems. E.g. manageable switches. Uses UDP => simple => small Fits in ROM RFC 1350 (TFTP v.2) TFTP - (c) Jouni Ikonen / TFTP - (c) Jouni Ikonen / IP Header UDP Header Packet structure opcode filename 0 mode 0 (1=RRQ, 2=WRQ) 20 bytes 8 bytes 2 bytes N bytes 1 N bytes 1 opcode block data (3 = data) number 2 bytes 2 bytes bytes opcode block (4 = ACK) number 2 bytes 2 bytes opcode block (5 = error) number error message 2 bytes 2 bytes N bytes 1 TFTP - (c) Jouni Ikonen / 0 The Protocol Client asks server to read or write a file for the client. filename is terminated with 0 mode is ASCII string of netascii or octet block number is used for acknowledgement stop-and-wait protocol no checksum (UDP has) TFTP - (c) Jouni Ikonen / TFTP Server is contacted in port 69, and new port number is obtained for a file transfer. No security. System admin must restrict TFTP s access to unnecessary files. For general and high-throughput file transfer FTP used. TFTP - (c) Jouni Ikonen / 1

81 TCP/IP Illustrated Vol. 1 The Protocols Chapter 16 - BOOTP: Bootstrap Protocol BOOTP For bootstrapping diskless systems. Uses UDP and usually works in conjunction with TFTP. RFC 951 and RFC Problems with RARP Only IP address returned RARP requests not forwarded by routers. BOOTP - (c) Jouni Ikonen / BOOTP - (c) Jouni Ikonen / Packet structure opcode (1=request, 2 = reply) hardware type (1 = Ethernet) transaction ID hardware address length (6 for Ethernet) hop count IP Header UDP Header IP datagram UDP datagram BOOTP request / reply 20 bytes 8 bytes 300 bytes number of seconds (unused) client IP address your IP address server IP address gateway IP address BOOTP - (c) Jouni Ikonen / BOOTP - (c) Jouni Ikonen / Packet continues... client hardware address (16 bytes) server hostname (64 bytes) boot filename (128 bytes) vendor-specific information (64 bytes) BOOTP - (c) Jouni Ikonen / Packet structure Hop count set to zero by client. Used by proxy server. Transaction ID set by client. Used to match request and reply. Number of seconds can be set by client. Secondary server can respond after some time if primary server does not answer. BOOTP - (c) Jouni Ikonen / 1

82 Packet structure If client knows its IP address, it fills it in, otherwise 0 Client must set HW address easier access for server. Server hostname, optionally filled in by server. boot filename, optionally filled in by server. BOOTP - (c) Jouni Ikonen / Packet structure The vendor specific area, for various extensions. Too small for some current applications gateway IP address is filled in by gateway and hop count is used to indicate that gateway is used. BOOTP - (c) Jouni Ikonen / BOOTP BOOTP server uses port 67 and client ports chosen to make possible server to broadcast response (usually unicast). If multiple clients bootstrapping concurrently and responses are multicast then clients recognize responses from transaction ID field or the returned HW address (which client sent originally). BOOTP - (c) Jouni Ikonen / BOOTP server design BOOTP normally provided in ROM. simple UDP (vs. RARP). How to send reply back to client? modification of ARP cache (ioctl) broadcast BOOTP - (c) Jouni Ikonen / BOOTP through a router Must be supported by router (as BOOTP relay agent). Usually used with diskless routers, otherwise router can be used as a server. Agent listens BOOTP requests, adds gateway address, increments hop count and forwards the request. BOOTP - (c) Jouni Ikonen / Vendor-specific (RFC1533) Vendor specific area can be used to provide: Subnet mask DNS server address time server address printer server address IP address of preferred routers Max. 64 bytes, which is insufficient to current needs. Newer protocol DHCP (Dynamic Host Configuration Protocol) is built on BOOTP to replace BOOTP, with more option space. BOOTP - (c) Jouni Ikonen / 2

83 For bootstrapping Uses UDP Alternative to RARP Requires (in ROM): Summary BOOTP TFTP UDP IP device driver for the local network Easy server implementation BOOTP - (c) Jouni Ikonen / 3

84 TCP/IP illustrated Vol. 1 The Protocols Chapter 27 - FTP: File Transfer Protocol Introduction FTP is the Internet standard for file transfer (RFC 959). RFC 1579 Firewall-Friendly FTP. RFC 2228 FTP Security Extensions RFC 2428 Extensions for IPv6, NAT, and Extended passive mode Sep RFC 3659 Extensions to FTP. P. Hethmon. March To use FTP an account to login on the server or a server that allows anonymous login should be used. FTP supports a limited number of file types and file structures. FTP differs from the other applications that is previously described, since it uses 2 TCP connection to transfer a file. FTP: File Transfer Protocol - (c) Jouni Ikonen / FTP: File Transfer Protocol - (c) Jouni Ikonen / Introduction client Introduction The control connection is established in normal Client-Server - fashion. The server does a passive open in port 21 and waits client to connect. Client does an active open to port 21 to establish the control connection. This connection stays open during the whole time the client communicates with the server. The data connection is created each time a file is transferred between the client and the server. File system User interface User protocol interpreter Used data transfer function control connection data connection server Server protocol interpreter Server data transfer function File system FTP: File Transfer Protocol - (c) Jouni Ikonen / FTP: File Transfer Protocol - (c) Jouni Ikonen / Introduction Introduction Data Representation file type ASCII EBCDIC (when both ends are EBCDIC systems) Image file type Local file type format control nonprint telnet format control fortran carriage control Data Representation structure file structure record structure page structure transmission stream mode block mode compressed mode FTP: File Transfer Protocol - (c) Jouni Ikonen / FTP: File Transfer Protocol - (c) Jouni Ikonen / 1

85 FTP FTP commands and replies are sent in ascii format, however it needs CR, LF pair at the end of each line. Most common commands are list, quit, type, retr (get) and stor (put). The replies are 3-digit numbers in ascii, with an optional message following the number (i.e 200 command OK). FTP Connection management : Three uses for the data connection Sending a file from the client to the server. Sending a file from the server to the client. Sending a listing of files and directories form the server to the client. Data connection procedure (active mode) The creation of the data connection is under control of the client. The client normally chooses an ephemeral port number on the client host for the data connection. The client issues a passive open in this port. The client sends this port number to the server across the control connection using the PORT command. The server receives the port number on the control connection and issues an active open to that port on the client host. The server end of the data connection port is always 20. FTP: File Transfer Protocol - (c) Jouni Ikonen / FTP: File Transfer Protocol - (c) Jouni Ikonen / Active mode FTP example 1027 data Client 1026 cmd PORT 1027 ACK 21 cmd Server 20 data FTP Connection management : Ephemeral port number random short-lived (normally) port number for the data connection. this is sent in PORT command by client. Default data port if the client does not send a PORT command to the server, the server uses the same port number for the data connection that is being used for the control connection (problematic) control and data connections are created to the same port (i.e.1176). when the client does the passive open of the data connection on port 1176, it must specify SO_REUSEADDR option, since that address is already in use by the control connection. the server does the active open of the data connection from the port 20 to port 1176, which the client accepts even though that port is in use. FTP: File Transfer Protocol - (c) Jouni Ikonen / FTP: File Transfer Protocol - (c) Jouni Ikonen / FTP The server does the active open of the data connection, which puts the socket pair in 2MSL on the server. The client sends another LIST command across. Before that the client has performed. Before this the client does a passive open on port 1176 with the SO_REUSEADDR option. The server issues an active open for the data connection from port 20 to port Before this the server must specify the SO_REUSEADDR option. FTP Text file can be transferred as ASCII or image (binary): Using binary transmission enables that the client and server don t have to look at every byte. And fewer bytes are needed to send. Any file transfer can be aborted with the ABOR command. FTP: File Transfer Protocol - (c) Jouni Ikonen / FTP: File Transfer Protocol - (c) Jouni Ikonen / 2

86 FTP passive mode Passive FTP example Firewalls block active mode FTP. In passive mode the FTP client initiates both connections to server. Client Opens two unprivileged ports Contacts server port 21, but does not issue PORT command. Performs PASV command, resulting server open random unprivileged port and send PORT command back to client. Client initiates connection to server to transfer data. FTP: File Transfer Protocol - (c) Jouni Ikonen / 1027 data Client 1026 cmd PASV PORT cmd Server data FTP: File Transfer Protocol - (c) Jouni Ikonen / 3

87 TCP/IP Network address translation And DHCP Network address translation Re-writing the source and/or destination IP addresses and usually also the TCP/UDP port numbers of IP packets as they pass through. Checksums (both IP and TCP/UDP) must also be rewritten to take account of the changes. Enables multiple hosts on a private network to access the Internet using a single public IP address. Can introduce complications in communication between hosts and may have a performance impact. NAT & DHCP - (c) Jouni Ikonen / NAT & DHCP - (c) Jouni Ikonen / Network address translation Popular due IPv4 address shortage. Avoids hassle of registering an IP address. Common feature in home routers. Hides the internal structure of a network. Also known as Network Masquerading, Native Address Translation and IP Masquerading Problems No true end-to-end connectivity (violates a cores principle of the Internet). No initiation of TCP-connection or UDP from outside of the network, unless router supports / participates to sessions (application gateway). Generally NO active FTP. Complicates tunneling protocols (e.g. integrity checksum). NAT & DHCP - (c) Jouni Ikonen / NAT & DHCP - (c) Jouni Ikonen / NAT IP NAT In NAT, generally only the IP addresses are modified: there is a 1:1 correspondence between publicly exposed IP addresses and privately held IP addresses. Incoming packets are routed to their destination IP address on the private network by reference to the incoming source IP address given by the host on the public network. NAT & DHCP - (c) Jouni Ikonen / Local network Router Local addr. Internet addr Internet NAT & DHCP - (c) Jouni Ikonen / IP

88 NAT Static NAT 1 to 1 address mapping Dynamic NAT dynamic pool of public addresses, where private addresses are mapped to as needed. PAT In PAT, both the sender's private IP and port number are modified; the PAT device chooses the port numbers which will be seen by hosts on the public network. In PAT there is generally only one publicly exposed IP address and incoming packets from the public network are routed to their destinations on the private network by reference to a table held within the PAT device which keeps track of public and private port pairs. PAT should be considered a type of NAT rather than a distinct technology NAT & DHCP - (c) Jouni Ikonen / NAT & DHCP - (c) Jouni Ikonen / IP PAT PAT Local network Internet Router Local addr. Internet addr NAT & DHCP - (c) Jouni Ikonen / IP PAT router has 1 (or more) public IP addresses. Ports are issued to as they are needed. Reverse (Destination) NAT network address translation for address of incoming connections. Used often to implement load balancing (e.g. connections arriving to single address are divided to 2 servers. Can provide also failover). NAT & DHCP - (c) Jouni Ikonen / RFCs RFC 3022 Traditional IP Network Address Translator (Traditional NAT) RFC 4008 Standards Track Definitions of Managed Objects for Network Address Translators (NAT) RFC STUN (Simple Traversal of UDP (User Datagram Protocol) through NATs (Network Address Translators)) Dynamic Host Configuration Protocol Protocol to obtain various parameters to operate in an IP network (IP, mask, gateway, ). Based on BOOTP. DHCP RFC Dynamic Host Configuration Protocol RFC Encoding Long Options in the Dynamic Host Configuration Protocol RFC Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four RFC3315 DHCPv6 (also updated in RFC 4361) NAT & DHCP - (c) Jouni Ikonen / NAT & DHCP - (c) Jouni Ikonen / 2

89 DHCP messages (1/2) DHCPDISCOVER - Client broadcast to locate available servers. DHCPOFFER - Server to client in response to DHCPDISCOVER with offer of configuration parameters. DHCPREQUEST - Client message to servers either (a) requesting offered parameters from one server and implicitly declining offers from all others, (b) confirming correctness of previously allocated address after, e.g., system reboot, or (c) extending the lease on a particular network address. DHCPACK - Server to client with configuration parameters, including committed network address. NAT & DHCP - (c) Jouni Ikonen / DHCP messages (2/2) DHCPNAK - Server to client indicating client's notion of network address is incorrect (e.g., client has moved to new subnet) or client's lease as expired DHCPDECLINE - Client to server indicating network address is already in use. DHCPRELEASE - Client to server relinquishing network address and cancelling remaining lease. DHCPINFORM - Client to server, asking only for local configuration parameters; client already has externally configured network address. NAT & DHCP - (c) Jouni Ikonen / Operation client DISCOVERY broadcast OFFER unicast server Problems Unauthorized DHCP servers Can give false router or DNS server Unauthorized clients REQUEST broadcast ACKNOWLEDGE unicast NAT & DHCP - (c) Jouni Ikonen / NAT & DHCP - (c) Jouni Ikonen / 3