RES 302 : Réseaux IP (Internet Protocol)

Transcription

1 Alberto Blanc Maître de conférences au département RSM alberto.blanc@telecom-bretagne.eu Jean-Pierre Le Narzul Maître de conférences au département RSM jp.lenarzul@telecom-bretagne.eu Nicolas Montavont Maître de conférences au département RSM nicolas.montavont@telecom-bretagne.eu RES 302 : Réseaux IP (Internet Protocol) UV1 MAJ RES : Protocoles et architectures des réseaux Notes de cours Automne 2012 Responsables du module: Alberto Blanc, Nicolas Montavont

2 Disclaimer These notes are a first draft and are provided as-is. Their goal is to be starting point, they cannot substitute note-taking during lectures nor they constitute a textbook. They do not cover all the material that will be covered during class. For a complete textbook the reader is strongly encouraged to refer to one (or more) of the following textbooks: Kurose and Ross [16], Tannenbaum [38], Bonaventure [4] (this textbook is freely available online at Toutain [40] (in French). For the sake of simplicity and, above all, to make this text (and class) easily understandable, we will not give all the details and we will not mention all the possible cases and exceptions. The reader who happens to be already familiar with any specific topic covered in this class might, therefore, be surprised by some of the statements that will be made during this class. Once more, the interested reader, is encouraged to consult one of the textbooks referenced above. 2

3 1 Application and Transport Layers 1.1 Introduction We will use a top-down approach for RES 302, starting from the application layer of the ISO-OSI reference model and ending with layer 2 (we will not cover they physical layer). Due to time limitations, we will not cover all the details of the different layers and the corresponding protocols. We will, nonetheless, strive to offer a fairly complete and coherent view of the main issues present and each layer and how they have been addressed in the Internet. Note that, while the seven ISO-OSI layer are often used as a reference model, the TCP/IP protocol suite uses only five layers: physical, data link, network, transport and application. The first four layers have almost the same role as in the ISO-OSI model, while application layer corresponds to the application, presentation and session layers of the ISO-OSI model. Note as well that the definitions and the functions assigned to each layer in the ISO-OSI are useful mainly to have a well organized and coherent views of the different elements of a computer network; they should not be interpreted as inviolable rules. As a first motivating example, we will consider Internet browsing. Nowadays we are all familiar with web-browser and the so-called World Wide Web. We will start by describing what happens when a user types a URL (Uniform Resource Locator) in the address bar of web-browser and presses enter. In this first chapter we will focus on the Application and Transport layers. 1.2 Behind the Scenes of a Web-Browser-Web-Server connection Most of us use web-browser (Firefox, Internet Explorer, Chrome, etc.) several times a day. We are used to typing an address into the address bar of the browser and expect that it will show the corresponding web-page. This seemingly simple operation requires, in almost all cases, quite a few exchanges between the end-node, the DNS server, and the web-server itself, just to name the main elements. Suppose we type in the address bar. In so doing we are requesting the following: 1. use the Hyper Text Transfer Protocol (HTTP); 2. connect to the machine whose name is rammus.labo4g.enstb.fr on port 80; 3

4 3. retrieve the index.html object. The string is often called a Uniform Resource Locator (URL) as it (uniquely) identifies a specific resource in the Internet. URLs can have more complicated forms (e.g., usernames, addresses), but these are outside the scope of these notes. It is sometimes the case that slightly different URLs correspond to the same object. For example, if the part is missing, the web-browser will use HTTP by default. Similarly, if the port number :80 is missing, the web-browser will try connect to port number 80 by default as that is the port number reserved for HTTP. Finally, if the URL does not contain a specific object at its end (index.html in the example above), the web server will return the object which has been defined as the default. In this case the default object is indeed index.html so that rammus.labo4g.enstb.fr is equivalent to This why we can use URLs like telecom-bretagne.eu, metropole.rennes.fr, meteofrance.fr, where we specify only the host name and nothing else A Very Brief Overview of HTTP HTTP is a text-based application layer protocol which is typically used by web-browsers to communicate with web-servers. It can be used as a simple request-response protocol, in which case the client (i.e., web-browser, also called user agent) sends requests to the server which is going to reply to each request either with a positive response or with a negative one, in the case of an error (e.g., the requested resource does not exist). HTTP uses a TCP connection (see section 1.3) to send requests and receive responses. Each request consists of one request line followed by one or more optional headers. The request line and each header end with two special ASCII characters: <CR> (carriage return) and <LF> (line feed). In other words HTTP uses a new line to separate different elements of the request. Obviously the header themselves cannot contain the <CR><LF> sequence as this would be interpreted as the end of the header.the request itself ends with an empty line, that is a line containing only <CR><LF> and no other characters (not even spaces). This implies that the server will wait until it receives the empty line before responding. HTTP version 1.0 [3] allows requests containing only the request line and no headers, as can be seen in the following exchange, obtained using the telnet program. Using telnet (HTTP 1.0) 1 user@ machinename :~ $ telnet rammus.labo4g.enstb.fr 80 2 Trying Connected to rammus. labo4g. enstb.fr. 4 Escape character is ^]. 5 GET 6 <html ><body ><h1 >It works! </h1 > </ body > </ html > 7 Connection closed by foreign host. The command telnet hostname portnumber can be used to open a TCP connection 4

5 with the host whose name is hostname using the port number portnumber. The telent program will simply display all the characters it receives from the server and it will send all the characters typed by the user to the server. Therefore it can be used to emulate a client using a text-based protocol, like HTTP, given that in this case all the information exchanged between the client and the sender consists in printable characters. Note that only the characters highlighted in darker gray are what the user typed, the rest is the output of telnet: lines 2, 3, and 4 explain what telnet itself is doing; line 6 is the message received from the server (i.e., the HTML document) and line 7 let us know that the server closed the connection. This is because with HTTP/1.0 a TCP connection is used for only one request/response. We can obtain the same response from the server if we specify the name of the file which corresponds to the default object: Using telnet specifying the requested object (HTTP 1.0) 1 user@ machinename :~ $ telnet rammus.labo4g.enstb.fr 80 2 Trying Connected to rammus. labo4g. enstb.fr. 4 Escape character is ^]. 5 GET /index.html 6 <html ><body ><h1 >It works! </h1 > </ body > </ html > 7 Connection closed by foreign host. This is because the web server running on rammus.labo4g.enstb.fr has been configured to use the file index.html as the default object, which is to be returned when the client does not specify one. We can use HTTP version 1.1 [11] by specifying the protocol version in the request: 5

6 Using telnet specifying the requested object (HTTP 1.0) 1 user@ machinename :~ $ telnet rammus.labo4g.enstb.fr 80 2 Trying Connected to rammus. labo4g. enstb.fr. 4 Escape character is ^]. 5 GET /index.html HTTP/1.1 6 Host: rammus.labo4g.enstb.fr 7 8 HTTP / OK 9 Date : Wed, 25 Jul : 46: 53 GMT 10 Server : Apache / ( Ubuntu ) PHP / ubuntu Last - Modified : Thu, 02 Feb : 08: 20 GMT 12 ETag : "2 a815a -2d -4 b7fe3e33c900 " 13 Accept - Ranges : bytes 14 Content - Length : Vary : Accept - Encoding 16 Content - Type : text / html <html ><body ><h1 >It works! </h1 > </ body > </ html > In this case we must use the Host header, specifying the name of the machine we have used in the URL. For reasons which will shortly be explained, this is the only way for the web-server to know the first part of the URL typed by the user. In the case of HTTP/1.1 the server also sends several headers (200 OK, Date, Server, etc.) before sending the actual object. Each header is on a single line and starts with the name of the header followed by a colon ( : ) and then the header itself. Finally a blank line separates the last header from the html file. Just like a blank line signals the end of the request (after the Host header). One of the headers (Content-Length) gives the size of the object (the html file in this case). This way the client knows when it has received the whole message. In HTTP/1.1 this is needed because the same TCP connection can be used to exchange multiple requests/responses while in HTTP/1.0 the TCP connection was used for a single exchange. As the typical web-page does contain several objects (like images, and other embedded content), it is more efficient to use a single TCP connection for multiple objects. This way it is possible to avoid the extra delay caused by the connection establishment (see section 1.3 below). As previously mentioned, HTTP is a text-based protocol in the sense that all the messages in the protocol are represented as strings of printable 1 ASCII characters, with new lines delimiting each field and with empty lines delimiting messages and separating the headers from the content of the message itself. Therefore, after the TCP connection has been established, a web-browser uses this connection to send the the bytes corresponding to the ASCII codes of the characters of the request message. Similarly, a web-server waits for incoming bytes and will interpret them as the ASCII codes of the characters 1 The ASCII codes between 0x20 and 0x7E corresponding (roughly) to the characters normally used in English texts. 6

7 representing the request The Client-Server Model HTTP uses the client-server model which, as the name implies, assigns different roles to the two end-nodes involved in the exchange. The server offers one (or more) service(s) and must be ready to accept incoming connection request from the client(s). This implies that the server process (see section 1.3) must be up and running before the client can access the corresponding service. 2 Often the server is a machine which exclusively dedicated to offering one or more services. Depending on the circumstances and the expected server load, more services can be offered by the same physical machine. For example, a web-server can be hosted on the same machine as a file server (offering a shared disk and/or other file-related services like FTP). If the expected load is important, it is often the case that a single machine will be dedicated to a single service. As servers are often dedicated, and fairly powerful, machines, the term server is sometime used to indicate such a machine, as opposed to a desktop or a laptop computer. These servers are typically located with other servers in a room and are not meant to be used directly (with a keyboard and a monitor). In a networking context, though, the term server can simply refer to the machine where there is a running process ready to accept incoming connections. The term can also refer to the process itself (e.g., the web-server process ). In this case a certain machine can be a server and a client at the same time. The term client is used mainly in a networking context and it indicates the machine or the process using the service offered by another machine. Note that it is possible to have the server and client processes running on the same machine. This is often done during the development phase of a project but can also be used in a production environment. 1.3 An Overview of TCP As mentioned in the previous section, a web-browser and a web-server communicate using a TCP connection. The Transmission Control Protocol (TCP) is a transport-layer protocol widely used in the Internet. Most measurement studies have consistently shown that it carries the overwhelming majority of the Internet traffic: between 83% and 91% of the packets and between 91% and 97% of the data [18, 14, 13]. It is therefore one of the key elements of the Internet. TCP is typically implemented in the Operating System (OS) kernel (see Figure 1.1). User space programs can access the services offered by TCP using the socket interface. 3 2 While this might be trivial, you will see during the programming exercises that it is essential to start the server process before the client one. 3 You will use this interface in the programming exercises and, indirectly, in the the project. 7

8 Application Layer TCP UDP... IP Link Layer Physical Layer User Space Kernel Space Figure 1.1: Typical networking stack implementation What TCP Offers to the Applications TCP offers a reliable service carrying an ordered byte stream between two processes (in both directions. A process is an instance of a computer programming running on a specific system (see Section below for more details). TCP uses acknowledgments to ensure that the data sent from the sender have been correctly received by the destination. These acknowledgments allow TCP to use an unreliable network layer (IP), which can loose, duplicate and re-order packets. TCP numbers each byte sent from the source so that it can assure that each byte will be delivered in the right order and exactly once. As TCP offers a byte-stream service, the sender cannot make any assumptions about message boundaries: if, for example, the sending application sends two messages (by calling the send system call), the receiving application might receive both messages in a single receive call, or in multiple ones. 4 In other words, TCP does not guarantee that message boundaries will be respected, where by message we mean whatever is sent with a single send call. This is why HTTP uses the <CR><LF> sequence to separate one header from the following one: even if the receiving application receives one byte at a time, it will be able to detect these two bytes one after the other and it will conclude that it has completely received one header. TCP is a connection-oriented protocol in the sense that the two end-nodes need to exchange a few signaling messages (notably to synchronize the sequence numbers in both directions) before they can start exchanging data. Similarly when they wish to terminate the connection they are supposed to send signaling messages indicating that they want to close the connection. As a TCP connection is a full-duplex connection, carrying data in both directions, one can think that each connection is actually made up of two half-connections, one in each direction. As these two half-connections are independent, one can be closed before the other. As shown in Figure 1.2, only the end-nodes are involved in a TCP connection. All the intermediate systems (like the IP routers shown in the figure) do not touch the TCP header and the data it contains. Routers implementing Network Address Translation (NAT, see the chapter about IP ) are one notable exception as they can modify the TCP header as well as the TCP payload. There are other exceptions like, for example, 4 The send and recv system calls can be replaced by the write and read system calls respectively, as these are basically equivalent and differ only in the presence of more flags in the send and recv calls. 8

9 end node (client) HTTP Protocol end node (server) Webbrowser Webserver TCP TCP Protocol TCP IP IP Protocol Router 1 IP Router N IP IP Protocol IP Ethernet Ethernet Protocol Eth. PPP Eth. Eth. Ethernet Protocol Ethernet Figure 1.2: HTTP and the ISO-OSI layers. HTTP proxies, but these are outside the scope of RES 302. It is important to stress that, as suggested in Figure 1.2, the TCP layer in each end-node is not aware of all the intermediate nodes traversed by the packets used to carry the TCP messages. As far as TCP is concerned there is no difference whatsoever whether the two end-nodes are directly connected (for example by an Ethernet segment) or whether they are on different continents, with many routers between them. Due to space constraints, Figure 1.2 shows only two routers, but, as suggested above, the number of routers between the two end-nodes can vary (with 0 being a possible case). IP routers are often represented as in Figure 1.2 only with layers 1, 2, and 3 (in this case layer 1 and 2 are represented by the same box) to emphasize that routers operate at layer 3 and do not consider the upper layer headers. (As layer 3 uses the services of layer 2, which, in turn, uses the services of layer 1, the presence of layer 3 implies the presence of layers 1 and 2 as well.) In reality IP routers do have an implementation of the higher layers, including TCP, which are used to handle connections terminating on the router itself. Such connections are typically used for configuration, management and monitoring purposes and are not directly involved in the main activity of the routers, namely forwarding packets Transport Layer Ports As mentioned in the previous section, TCP enables processes (typically running on different computers) to communicate with each other. Given that the same two process might wish using more than one connection between them, TCP need a mechanism to distinguish these connections. Furthermore, it is often the case that multiple processes are running on the same machine and that each one of them can open one or more 9

10 end-node 1 end-node 2 end-node 3 web-browser port number web-server web-browser IP address: IP address: IP address: Figure 1.3: Multiple TCP connections and the corresponding ports. TCP connections. In this case as well, TCP needs a mechanism to distinguish different communication end-points on the same machine. One possible solution is to use a network-wide unique address for each transport layer end-point, independent of the network layer address. TCP, instead, uses the network layer (IP) address as a part of the transport layer address. On each end-node different communication end-point is identified by a locally unique port number, which is an integer in the range (so that it can be represented using two bytes). To make sure that each end-point has a unique network-wide address, TCP combines IP addresses and port numbers: each TCP end-point is uniquely identified by the IP address of the host computer and a port number. As IP addresses are unique, this is enough to guarantee that transport layer addresses are unique as well. One advantage of this solution is that the local Operating System (OS) can choose the port number and does not need to worry about the port numbers used on different machines. The downside is that transport layer addresses use network layer addresses which is a violation of the layering principle. A TCP connection is uniquely identified by four elements: 1. the source IP address; 2. the source port; 3. the destination IP address; 4. the destination port. As a TCP connection can carry data in both directions, which end-point is called source and which destination is immaterial, the roles can be switched and the TCP connection is still the same one. Figure 1.3 shows an example with three connections; all of them use port 80 on the machine running the web-server, this is not a problem as the IP address and/or the port 10

11 number is different at the other end-point. Note that both end-node 1 and end-node 3 use the same port number (37650), but, as the IP addresses of the two nodes are different, it is possible to distinguish between the two connections. Whenever a process wishes to establish a TCP connection with another process it needs to know the IP address and the port number corresponding to the remote process. One option is for the user to specify these values explicitly. For example, we could have used the command telnet instead of telnet rammus.labo4g.enst.fr 80 in the previous section. This is because is the IP address of the machine whose name is rammus.labo4g.enst.fr. As people can usually remember names more easily than numbers, the Domain Name System (DNS, see section 1.4) can convert a name into the corresponding IP address. Most programs, including web-browsers, can handle both IP addresses directly or names and can automatically distinguish between the two. If we want we can also type in the address bar of a web-browser, instead of rammus.labo4g.enst.fr. If we type a name instead, the program will use the DNS to obtain the corresponding IP address. 5 As previously mentioned, if the user does not specify the port number when using a web-browser, the web-browser will try connecting to port number 80 by default. This is an example of a well-known port, that is a series of ports which are typically associated with a given service. Other examples are: port 23 for telnet (remote terminal), port 22 for ssh (secure remote terminal), port 25 for the Simple Mail Transfer Protocol (SMTP, used for s). All the well-known ports are in the range The Internet Assigned Numbers Authority 6 (IANA) is responsible for assigning and maintaining the list of well known ports, as described in RFC 6335 [7]. Well-known ports are also called system ports. The ports between 1024 and are called registered or user ports. IANA can also assign these ports but it uses a simpler and less stringent procedure than one used for system ports. Finally the ports between and are called dynamic or ephemeral ports and are typically dynamically assigned by the OS when a new TCP connection is established. To summarize, whenever a process wishes to open a TCP connection with another process it must specify the IP address and the port number of the remote process. For example, suppose that the remote process is on port 35. The connection can be established only if the remote process is already listening on port 35. This is true if it has previously notified the operating system that it wants to receive (and handle) all the connection requests addressed to that port. To achieve this goal the process must use a few different system calls: first the socket system call to create a new socket, then the bind system call to specify the port number it want to listen on, and finally the listen system call to block until a new connection request arrives. Clearly, only one process at a time can be listening on a given port. In our example, if there is already a process listening on port 35 the OS will return an error whenever a different process tries to bind to that port. On most systems (Unix, 5 In the case of Python programs, the socket library can directly handle both IP addresses and names. Therefore in your programs you will be able to use indifferently IP addresses and/or names

12 Linux, Windows, Mac), only processes running with administrative privileges (i.e., root in Unix/Linux/Mac) can bind to system ports Computer Processes Computer programs and OS processes are related but different concepts. 7 A computer program can roughly be described as a series of instructions operating on a set of variables. These days the instructions are typically written in a high-level language like Java, C/C++, Python, etc., and they are converted to machine code, which can be directly executed by a certain processor, by a compiler and/or an interpreter. Consider the following trivial Python script: Sample Python Script: add.py 1 #!/usr/bin/env python import sys 4 5 print "This is a simple program which adds two numbers " 6 message = u Type two numbers (put a space between them and press enter) \n 7 while True: 8 inputstring = raw_input(message) 9 inputstring = inputstring.decode(sys.stdin.encoding) 10 fields = inputstring.split() 11 a = int(fields[0]) 12 b = int(fields[1]) 13 print "the answer is: ", a + b which just prompts the user for two numbers and then prints their sum. This operation is repeated forever as the looping condition is always true. This program contains a few variables, including a and b, which always contain the last two numbers given by the user. Whenever this program is executed, for example by typing python add.py in a shell (sometimes called terminal ), the OS will execute the python command by loading into memory the executable code and executing the first instruction. Eventually the interpreter will read the add.py file and execute each instruction in it, storing the corresponding variables in memory. When the OS executes the python command it creates a new process, that is a new instance of a running program. Roughly speaking, a process is alway associated with at least three things: the executable code (the machine code instructions), the data section (where the variables are stored), and the instruction pointer which points to the current instruction and which is updated each time a new instruction is executed. You can think about the instruction pointer as something roughly equivalent to the highlighted line shown by most debuggers when you execute a program step-by-step. Most modern OSs can execute multiple programs at the same time, even if the computer has a single CPU. This is achieved by time multiplexing: time is divided in 7 Threads are yet another related concept, which is outside the scope of RES 302, just be aware of the fact that threads and processes are not the same thing. 12

13 slots (typically a small fraction of a second), in each slot the OS schedules a different process by instructing the CPU to executed the instruction specified by the instruction pointer of the process in the question. During each slot the CPU executes the instructions of a single process. At the end of each slot an interrupt (controlled by a timer), gives control back to the OS which selects the process which will run next. Clearly, it is possible to execute more than once a program and it is possible to start a new instance before the previous one has terminated. For example, by using two different shells, it is possible to have two instances of the add.py script shown above. Each instance will have its own variable a with potentially different values (the same is obviously true for the variable b as well). This because the two instances correspond to two different processes with two separate memory areas for storing variables. Each process has a unique identifier (typically called process ID ) so that it can be distinguished from all the others. It is possible to use the fork system call to create a new process by cloning an existing process. The only difference between the two cloned processes is the return value of the fork call: 0 for the newly created process (often called the child process) and a positive number corresponding to the process identifier of the child process for the original process (often called, unsurprisingly, the parent process). In the case of error the cloning process does not take place and the parent process receives a negative return value from the fork. It is useful to mention that, while the parent and child process do not share any memory (so that variables can take different values in each process), they do share open files (including sockets as these are just a special case of a file). 8 These are just the main points related to processes. This section is meant as a very general and high-level introduction to what processes are as they are fundamental actors in computer networks (being the origin and destination of end-to-end transport layer connections). As we do not need to cover all the details in order to understand their role in computer networks, we will not dwell any further on this topic. The interested reader is referred to any standard OS textbook (e.g., Abraham et al. [37], Tanenbaum [39] ) where one can find all the many aspects that were not covered in this short introduction. 1.4 The Domain Name System (DNS) As we will see in the chapter about IP, in an IP network, each interface has a unique IP address, so that it can be distinguished from all the other interfaces in the network. As mentioned in section 1.3.1, TCP uses IP addresses in order to specify the end-points of a TCP connection, and the same is true for the User Datagram Protocol (UDP) (which is another transport-layer protocol). As already observed in section 1.3.2, it is easier for users to remember names rather than IP addresses (which are a sequence of numbers). The Domain Name System (DNS) addresses this problem by mapping names to IP addresses. DNS can also answer so-called reverse lookup queries by returning the name(s) associated with a given IP address. 8 You should remember this when you use the fork system call in the first set of programming exercises. 13

14 While IP and TCP go back to the very beginning of the Internet (in the 1970 s), DNS was not introduced until 1987 ([19, 20]). One of the first solution to the name-ip address mapping problem was actually based on storing the mapping information in a file on each host. Traces of this solution are still in use today as several operating systems use the hosts file where one can specify mappings between names and IP addresses. This file is examined before any DNS query is made, so that its mapping have the highest priority and can override the normal mapping stored in the DNS. Clearly a solution based on every machine having a configuration file with all the mapping information is not scalable, not to mention that is far from easy to manage and to update it. The modern DNS can be described as a distributed data-base, where by distributed we mean that there is no single node with all the information, rather each node contains only a subset of the information and knows where to look for the missing parts. Given the scale of the Internet, it is not feasible to have a flat naming space, that is a naming scheme where all the names have no hierarchy and are on the same level. In such a scheme it would be very hard to add new names as one would need to find a name which has not yet been used. It would also be really hard to distribute the content of the mapping information between several nodes, as there would be no obvious ways of determining which node is responsible for each specific name. In contrast, in a hierarchical solution, especially in a tree-based one, it is very easy to distribute the mapping information among several nodes and it is also easy to determine which servers are responsible for storing that information (this greatly simplifies the query part). 9 The name space used in the Internet is indeed based on a tree structure, with each level in the tree corresponding to a different (sub)domain. Dots separate each level in the name, with the top level domain (TLD) being the rightmost one, and with all the subdomains to its left. For example in the name the top level domain is eu which, being a TLD, is a child of the root of the naming space; telecom-bretagne is a subdomain and www is a leaf in the tree as it is the leftmost part of the name. Normally leaves correspond to individual computers. The height of the tree is not limited to three as in this example, for example the name rammus.labo4g.enstb.fr has two subdomains. Figure 1.4 shows a (very tiny) subset of the Internet name space, where the root of the tree is represented by a dot. The in-add.arp subtree represents the inverse mapping between IP addresses and names. For example to obtain the name corresponding to the , one would ask the DNS to resolve the name in-addr.arp, where the order of each byte of the IP address is reversed. The fully qualified name of a leaf is the name which contains the leaf itself and all the subdomains between the leaf and the root of the tree. 10 Each fully qualified name has to be unique across the Internet. Thanks to the tree structure, the uniqueness of each 9 To increase reliability, several servers contain the same mapping information, according to RFC 1034 [19] (section 4.1) each mapping has to be stored on at least two servers. 10 absolute name and complete name are equivalent terms to fully qualified name. 14

15 . arpa com nz fr de eu in-addr 192 cnn google lefigaro enstb lemonde telecom-bretagne 108 www maps labo4g rsm www intranet rennes rammus forge chuao Figure 1.4: The graphical representation of a subset of the Internet name space fully qualified name is guaranteed if no two children of a node have the same name. For example, in Figure 1.4 there are two nodes with the www name but as they have different parents (cnn and telecom-bretagne) they correspond to two different fully qualified names. Thanks to the tree structure it is possible to divide the mapping information among several servers in such a way that the name itself indicates which servers to contact. In theory it is enough for each node in the tree to know the IP address of the server responsible for each child. Suppose we would like to find the IP address corresponding to the name First we need to find the IP address of the server responsible for the.eu domain. This is done by asking one of the root servers, whose IP addresses are well known. Once we know the IP address of the server responsible for the.eu domain we can contact it and ask the IP address of the server responsible for the telecom-bretagne subdomain. With this information we can finally contact the server responsible for the telecom-bretagne subdomain to obtain the IP address corresponding to the name In theory, whenever a host 11 needs to find the IP address corresponding, it could use a similar procedure to query all the servers himself. In reality, each IP host knows the IP address of one or more local DNS servers. 12 Where by local we mean the network distance, in terms of hops, between the host and the DNS server is small. Most Internet Service Providers (ISP) and quite a few institutions (universities, research centers) and most large business/companies have their own DNS servers. One important advantage of such a solution is that each server can cache the responses it receives so that, if several 11 End-nodes in the Internet are often called hosts. 12 The IP address(es) is (are) either configured by hand or are obtained using DHCP (see the chapter about IP ) or a similar protocol. 15

16 s 1 root server local server s 2 local server 5.fr server client (end node) s 3 client (end node) 7 lemonde.fr server (a) A recursive query. (b) A mixed query. Figure 1.5: Different DNS query types. messages are exchanged. The numbers represent the order in which hosts ask for the same name, it will be able to respond to the query without contacting all the servers responsible for each (sub)domain. Note that this is useful even when different queries share just part of the name. For example, several users at Telecom Bretagne will probably ask to resolve names ending in.fr. (To resolve a name means to find the IP address corresponding to a given name.) In this case the DNS server at Telecom Bretagne can store in its cache the IP address of the DNS server responsible for the.fr domain so that it can contact it directly without first contacting one of the root servers. Each time a DNS server sends a reply (either to an end-node or to another server), it indicates for how long the response should be cached (the Time To Live, which should not be confused wit the Time To Live field in the IP header). DNS is also the name of the protocol used to query DNS servers. Typically this protocol uses UDP but it can also use TCP. For the purposes of RES 302 it suffices to know that DNS is a request-response protocol, with a common header for requests and responses. Until 2010, it supported names using exclusively the Latin alphabet (excluding letters with diacritical marks like accents). Since 2010, the DNS does support other alphabets (RFC 5890 [15]). DNS supports two different query types: iterative and recursive. In a recursive query each server asks the following one to resolve the name, as shown in Figure 1.5(a). Suppose that the client asked the local server to resolve the name rammus.labo4g.enstb.fr the client contacts the local server, which already has in its cache the IP address of the server responsible for the.fr domain, which is s 1. The local server then contacts s 1. Instead of telling which server to contact next, s 1 contacts the next server (s 2 ) directly, in this case s 2 is the server responsible for the enstb.fr domain. Similarly, s 2 contacts s 3 (the server responsible for labo4f.enstb.fr). The response then follows the same path in the reverse direction. One of the problems with recursive queries is that each server is forced to store a certain amount of state information for each pending query so that it can match the 16

17 response to the requests and forward them correctly. Another problem is that the a server accepting recursive queries must process more packets (compare Figures 1.5(a) and 1.5(b)). According to RFC 1035 [20], support for recursive queries is optional. One of the flags in the header of each DNS packet indicates whether the request is recursive or not. Each of the servers in Figure 1.5 can decide (at least in theory) whether to use a recursive or iterative query. In an iterative query, if the server does not know the IP address corresponding to the name, it replies with the IP address of the next server to contact. Iterative and recursive queries can coexist in a DNS request as shown in Figure 1.5(b), which is actually the typical case. The request from the client to the local server is recursive, while the local server uses iterative queries to resolve the name. In this case the client asked for the IP address of Because of the problems mentioned above, the typical (and properly configured) DNS server accepts recursive queries only from a limited and well identified set of IP addresses (for example, in the case of an ISP, the IP addresses of its customers). So far we have talked about DNS servers and subdomains, without detailing the relationship between them. This is because the relationship is a matter decided by the administrator of each subdomain. There are only two requirements: one is to have a server (actually at least two for redundancy reasons) in charge of each non-leaf node of the tree corresponding to the Internet naming space, the other is for each server corresponding to a non-leaf node to know the IP address of all the servers responsible for its children. It is often the case that the same server is in charge of multiple subdomains. For example, the DNS servers at Telecom Bretagne are responsible for the subdomains telecom-bretagne.eu, enstb.fr and enst-bretagne.fr. The DNS servers in charge of the.eu and.fr know the IP addresses of these servers. Finally it is worth mentioning that the system does use the DNS as well. Whenever an server has a message to send, for example to firstname.lastname@telecombretagne.eu it asks its local DNS server the IP address of the mail server responsible for the telecom-bretagne.eu domain. The querying mechanism is the same described above, with the only difference being that the DNS request specifies that it is about an domain and not a hostname. 17

18 2 Addressing in General 2.1 Introduction The goal of this chapter is to present in a general way the problems associated with addressing in computer networks and the interactions between addressing and routing. These problems present themselves at different layers, notably at layers 2 and 3. By definition, there are multiple nodes in a computer network and one needs a way to distinguish each one. One, if not the main one, function of an address is to uniquely identify a node or, in the case of TCP/IP and IEEE 802 networks, a specific interface. We have already seen in the previous chapter how TCP uses a combination of IP addresses and port numbers to uniquely identify communication end-points. Without such unambiguous addresses it would not be possible to establish a communication with the desired end-node. Also in the previous chapter, we have seen how names can be used to identify an end-node instead of its IP address and how DNS provides the mapping between the names and the IP addresses. One could say that names are the addresses at the application layer. It is indeed the case that each layer of the ISO-OSI model uses its own addresses, which are independent of the addresses used at the other layers. The notable exception being the transport layer in the TCP/IP protocol suite, as it uses a combination of layer 3 addresses and port numbers. Clearly the consequence of this violation is that TCP is intimately linked to IP and it cannot be used with other layer 3 protocols without important modifications. This limitation turned out to be irrelevant in practice as IP is without any doubt the most widely used layer 3 protocol today. Yet it is a limitation. Compare this with the total independence between IP and layer 2 protocols: IP can be used with many different layer 2 protocols. Of course one always needs, at the very least, a way to find the layer 2 address corresponding to an IP address but this is addressed by specific protocols (for example ARP in the case of IP and IEEE 802 networks, see the chapter about IP ). Just like postal addresses, addresses in a computer network can also be used to identify the location of a node, and we are going to consider only this solution in RES 302. While this might seem as a natural solution, one should be aware of its consequences. 2.2 Intermediate Nodes and Routing As we have already observed, there are always multiple nodes in a computer network and the network itself must interconnect all these nodes. One possible, but obviously lousy, solution is to use a fully mesh, where each node has a direct link with all the other nodes in the network. Obviously, the problem with this solution is that the number of 18

19 (a) A full mesh. (b) A more realistic network. (Circles correspond to end-node and squares to intermediate nodes.) Figure 2.1: Different network topologies. links grows as the square of the number of nodes. Figure 2.1 shows the full mesh and a more realistic topology, where squares represent intermediate nodes. The role of the intermediate nodes is to route each packet towards its destination. Note that such nodes are not only present at layer 3, where they are called routers or gateways, they can also be present at layer 2, where they are called switches. Sometime the term layer 3 switch is used to indicate a router but its usage is fairly rare. Throughout RES 302, whenever we use the term switch we refer to a layer 2 device. Similarly a router will be a layer 3 device, with the exception of this chapter where we will use router as an equivalent of intermediate system. Similarly we are going to use the term packet to represent layer 3 as well as layer 2 messages, which are more appropriately called frames The Routing Table As the role of intermediate systems is to route packets, they need to know where to send each packet so that it will reach its destination. This information is stored in what is typically called (somewhat inappropriately) the routing table, whose name should rather be forwarding table as it is used to forward packets. 1 We are going to consider a simple example in order to better explain what a routing table is. Figure 2.2 shows a simple network with p hosts connected to the intermediate 1 This distinction is somewhat beyond the scope of RES 302 but the main idea is as follows: routers do have a routing table as well, which contains all the routing information known by the router: for example a router might be aware of multiple paths for reaching a certain node but, in this case, it selects only one rout and this route is inserted in the forwarding table. 19

20 s 1 d 1 s 2. i 1 i 2 i 0 i 0 X 1 X 2 i p i 1 i 2 i q d 2. s p d q Figure 2.2: A simple dumbbell network. node X 1 and q hosts connected to intermediate system X 2. (This topology is called a dumbbell and it is often used in network simulations as it is the simplest topology with a bottleneck link: if there is enough traffic between the nodes on the left ( sources ) and those on the right ( destinations ) the link between X 1 and X 2 can be a bottleneck and experience congestion.) Whenever r 1 receives a packet it must decide on which output interface (labeled i 0,..., i n ) to send it. The same is true for X 2. For the moment we are assuming that, like in Figure 2.2, there is only one host connected on each interface, therefore it is enough to specify the output interface. In the case of multiple access networks, like Ethernet, this is not always the case. In the context of Figure 2.2, it is therefore enough for X 1 and X 2 to have a mapping associating an address with the appropriate output interface, for example the table of X 1 might look something like this: Destination Address Output Interface s 1 i 1 s 2 i 3 s 4 i 4 d 2 i 0 d 5 i 0 Where, for the sake of simplicity, we have used the name of each node as its address. Clearly, one possible solution, is to store all the p + q different addresses in the routing table of X 1 and X 2. 2 In this case there are no constraints on the location of each address, for this reason this solution can be described as a flat address space. Another solution is to organize the addresses in such a way that all the addresses on the left of the figure share the same prefix (i.e., the first part of their address), just like in the telephone network. In this case there are constraints on where a certain address can be used. This 2 For the sake of simplicity we are momentarily assuming that X 1 and X 2 do not have addresses. 20

21 solution is often called hierarchical addressing as there is a hierarchy in the address (a prefix and the rest). Also all the addresses with the same prefix can be grouped together and can be represented only by their prefix, something which cannot not be done with flat addressing. We will further discuss flat and hierarchical addressing in the next section. It is worth mentioning that intermediate systems have to search for a match in the routing table for every packet they route. Therefore its size can have a significant impact on the forwarding performance, in terms of time needed to forward a packet. These days it is common to have links operating at a few Gbit/s, in this case a router can receive more than a million packets per second on each link and for each one of these packets it needs to find a match in the routing table to determine the output interface. 2.3 Different Ways of Organizing Addresses In this section we are going to describe several different ways of organizing an address space. In order to better explain some of the ideas, we will present a few example using IP version 4 (in short IPv4) addresses. An IPv4 address is a 32 bit number which is typically represented in dotted decimal notation: each one of the 4 bytes in the address is represented as a decimal number (between 0 and 255) and each byte is separated by a dot (e.g., ) Flat Address Space When there are no constraints on where addresses can be used the resulting address space can be described as flat as there are no boundaries and no address is different from another (in the sense that they all have the same properties). One advantage of this solution is that assigning addresses is very simple: whenever a new address is needed one only needs to make sure the a certain address is not already in use. The downside of this solution is that the size of the routing table grows linearly with the number of nodes in the network as the routing table need to store an entry for each node in the network. It is therefore impossible to use such a solution in a large network, such as the Internet. At the same time the lack of constraints in the addressing plan can be an important advantage. As we will see shortly, while hierarchical addressing can have significantly smaller routing table, it does introduce strict constraints on how addresses can be used in the network. Ethernet networks do use a flat address space. As you have seen in RES 301, the uniqueness of each address is guaranteed by the network interface manufacturer. Learning bridges, which are the Ethernet intermediate systems, exploit the fact that Ethernet networks have a limited size by using flooding to forward packets for which there is no match in the switching table. 3 Flooding means forwarding a packet on all the output interfaces, except the one on which it was received. As the name implies a packet can end up being forwarded to every node in the network, at the same time this guarantees 3 In the case of layer 2 devices, like bridges and switches, the routing table is actually called switching table. 21

22 that the packet will be delivered to the destination! The combination of flooding and of the learning algorithm allows the size of the switching table to be manageable. Basically it grows linearly with the number of end-nodes which are actually sending data at any given time, as opposed to the total number of end-nodes in the network. These are just a few of the main ideas behind learning bridges, see RES 301 for more details Hierarchical Addressing If we used flat addressing in the network depicted in Figure 2.2, the routing table of X 1 would have the p entries corresponding to all the machines on the right, yet for all these entries the output interface is the same, as the rout is the same. If we assign addresses in such a way that all the addresses of the nodes d 1, d 2,..., d q share the same prefix, we could then reduce the size of the routing table by replacing the q different entries with only one, with the prefix in the address column and i 0 in the output interface part. In packet switched networks, like IP and IEEE 802 networks, every packet needs to include, at the very least, the destination address, as every packet is treated independently and must contain all the information needed to route it to the destination. Typically the source address is included as well, so that the receiver knows who has sent the packet and, in the case of errors, the intermediate nodes (and the receiver) can notify the source. Each router handling the packet must read the destination address and use it to find a match in the routing table. In order to efficiently implement this operation the address length is typically fixed as it would be too time consuming to parse a packet with a variable address length. Therefore it is reasonable to assume that, in a given network, all the addresses have the same fixed length. While it is possible, at least in theory, to use names as addresses at layers 2 and 3, numbers are used instead as computers (including intermediate nodes) can handle them faster and more efficiently than names. In the remainder of the chapter we are going to assume that addresses are binary numbers with n bits. In the case of IPv4 n = 32, for IPv6 n = 128 and for IEEE 802 networks n = 48. Just like in telephone numbers, the prefix corresponds to the most significant digits. A prefix of length k (0 k < n) is the set of the 2 n k addresses whose first k bits have the same value. Note that k = 0 is a special case corresponding to the whole address space, this is useful in the longest prefix match algorithm, as discussed below. We use Greek letters to denote prefixes: α k is a prefix of length k. As there are 2 k different prefixes of length k we use the notation α k,j, with j [1, 2 k ], to indicate a specific prefix. Fixed Prefix Length Recall the the idea behind hierarchical addressing and prefixes is that the intermediate nodes know only about prefixes and not about individual addresses, leading to smaller routing tables. For the sake of simplicity, in Figure 2.2 each end-node has its own link to the closest intermediate system. If we make the assumption that, like in IP and IEEE 802 networks, each interface must have its own address, we would need 2 p different prefixes for the s i nodes (and the corresponding interface at X 1 ) and 2 q prefixes for 22

23 the d j nodes. Thus we need a prefix of at least h min log 2 2 (p + q + 1) bits, where x is the smallest integer grater than x. We need p + q + 1 prefixes because we also need two addresses for the i 0 interface of X 1 and X 2. Any longer prefix would work as well, i.e., any prefix length such that h min k n 2 would work. As we need at least two addresses in each prefix (one for each interface), the longest possible prefix length is n 2. If we chose k = h min we have larger prefixes, so that we could handle, for example, multiple access networks, where it is possible to have multiple nodes connected to the same network and not just two as in Figure 2.2. In other words, there is a trade-off between the length of the prefix (k) and the number of addresses in it. Note that we use the term longer when talking about the length of a prefix, while we use the term larger to refer to its size, i.e., the number of addresses belonging to the prefix. The longer a prefix is, the smaller its size. One possible solution is to use a variable prefix length, in order to better fit the characteristics of each network. At the same time a variable prefix length increases the complexity at each intermediate node: whenever it routes a packet it needs to determine the prefix of its destination address, so that it can search for it in the routing table. Furthermore the intermediate node might need to be capable of determining the length of the prefix of each address (this is not needed in the case of the longest prefix match, discussed below). From the point of view of optimizing the routing of packets, it is best to use a fixed prefix length. But, as we have observed above, this introduces the problem of choosing the appropriate prefix length. Until the mid 1990s, the Internet adopted a compromise using three different prefix lengths: 1, 2 and 3 bytes. If a network uses only one prefix length, there is no need to specify anything else than the prefix length k: the address space is divided in 2 k groups, each one with 2 n k addresses. If we have multiple prefix lengths, like in the Internet, we also need to specify how each prefix length is allocated in the address space. Figure 2.3 shows how the IPv4 address space was divided before Half of the address space (all the addresses starting with a 0) is allocated to the prefixes of length eight. As the most significant bit is set to 0, there are 2 7 = 128 different prefixes of length eight, and each one has 2 32 addresses in it. Half of the remaining address space (a quarter of the total) is allocated to the prefixes of length 16: there are 2 14 = such prefixes each with 2 16 = addresses (the first two bits of each prefix in this group are 10, hence there are only 2 14 such prefixes). The remaining quarter of the address space is divided between the prefixes of length 24, the multicast addresses (see section 2.5) and addresses reserved for future use. The prefixes of length 24 take half of this remaining space, corresponding to an eighth of the total. There are 2 21 (24 3 as the first three bits are set to 110) such prefixes, each with 2 8 = 256 addresses. Each of the these address blocks is also called a class, with class A being the class of the prefixes of length eight, class B for length 16 and so on (as shown in the figure). By definition the Internet is a network of networks: an inter-network. Each prefix was meant to be allocated to a different network, hence the bits corresponding to the prefix in the address are often called the network part of the address, while the remaining bits, meant to distinguish each host in a network, are called the host part, as shown in Figure 2.3. There two constraints on how prefixes can be attributed to networks: 23

24 32 bits Class A 0 network host B 10 network host C 110 network host D 1110 multicast group ID E 1111 reserved for future use Address Range from to from to from to from to from to Figure 2.3: The IPv4 address space before first, all the hosts in the same network must be able to exchange packets directly at layer 2, second, all the interfaces of a router must belong to different networks. This implies that routers are only involved in exchanges between hosts on different networks, this is not surprising, given that the role of a router is exactly to connect different networks. Not that this implies that even point-to-point links need their own prefix even though only two addresses are used. It is worth underlining the fact that all the prefixes (i.e., network addresses) used in IPv4 before 1994 do not overlap, that is the intersection between two different prefixes is always empty. In other words, the whole address space was divided in a given number of non-overlapping blocks of different sizes. Furthermore, looking at the first byte, it was possible to determine the length of the prefix, and, therefore, to which block each address belonged. Whenever a router received a packet it would examine the first byte of the destination address, determine the prefix length, extract the prefix and search for it in its routing table. It is easy to compute the worst case size of a routing table: the worst case is when all the prefixes have been allocated, corresponding to a total of = different entries in each routing table. Clearly this is a worst case and it is still a significant improvement over a flat address space, as this would have required 2 32 entries in each routing table! Yet it is far from trivial given that, as we have already mentioned, that routers have to search for a match in this table every time they route a packet. One could even say that using a fixed prefix length is basically equivalent to a flat address space using shorter addresses: as we have just seen, in the worst case, routers do need to store a route for each prefix. In some cases, it is possible to reduce the size of the routing table by using a special entry called default route: whenever the destination address of a packet does not match any of the entries in the routing table, it is forwarded along the default route. In IP networks the address is used to indicate the default route as this address is 24

25 131.33/16 i i 3 4 i /16 r / / /24 i 1 i 4 i /16 r 3 i 2 i 2 r 3 5 i 1 i 2 i 1 i 5 i 4 i 3 r i 2 i 6 6 i 1 103/ / /16 i 4 r 4 i 3 i 5 i 1 i 2 i 3 i 2 r 5 i / /16 57/8 Figure 2.4: A simple network where prefix aggregation is possible. reserved and cannot be assigned to an interface. As an example, consider the network shown in Figure 2.4, where the number after the slash is the length of the prefix (e.g., /16), this notation is often used, even though, in the case of the Internet before 1994, this is not needed as the length of the prefix is uniquely determined by the value of the first byte of the address. Note that this network is obviously not a realistic representation of the Internet, except at the very beginning when it was an experimental network connecting a few institutions in the US. Table 2.1 shows the routing table of r 2, it easy to notice that several prefixes correspond to the same output interface in the table. One could even say that, as far as r 2 is concerned all the prefixes routed through the same interface are basically equivalent and could potentially be represented by only one entry in the routing table. We will see that with a variable prefix length we can indeed merge multiple prefixes and reduce the size of the routing tables. Note that all the routing tables in the network of Figure 2.4 have the same size (11) as each one of them must contain all the prefixes present in the network. 4 Finally, note that, in Figure 2.4, there are dotted clouds even on the point-to-point links between routers, this is to underline the fact that, in IP networks, each link must have its own prefix, even though only two addresses are used. For the sake of simplicity these prefixes are not shown in the figure but one should not forget their existence. The solution based on three different fixed prefix lengths was a reasonable compromise when the Internet started as a research project in the mid 1970s but, as it grew into a worldwide network, its limitations became an obstacle to its growth. One of the main problem was the uneven distribution of the address block (prefix) sizes. Half of the address space was allocated to a few very large networks (class A) and one eighth of the 4 In this case the default route cannot offer any significant reduction in the size of the routing tables, therefore we will ignore this option for the time being. 25

26 Destination Prefix Output Interface i i i i i i i i 2 57 i i i i 3 Table 2.1: The routing table of r 2 in the network shown in Figure 2.4, in the case of fixed prefix length. address space was allocated to a lot of very small networks (class C). The result was that class B addresses were the most widely used and there was very little demand for class C addresses. This is because, with the widespread adoption of local area networks (mainly Ethernet) most layer 2 networks had at most a few thousands machines and most of them had more than 256 machines. Another important problem, again a consequence of the fixed-size address blocks, was that the size of the routing table kept growing linearly with the number of prefixes being allocated. Note that, if the allocated prefixes grow exponentially, so does the size of the routing table. Variable Prefix Length One possible solution to this problem is to aggregate multiple networks (prefixes) in larger ones, so that multiple entries in the routing tables can be replaced by only one. In 1994 the Internet switched to Classless Interdomain Routing (CIDR) removing the three fixed prefix lengths and using a variable prefix length instead [31, 12]. A variable prefix length means the the address space is not divided anymore in blocks of a fixed size, instead it can be divided in an arbitrary number of blocks of different sizes, with certain blocks strictly contained in other ones. Even in an network as simple as the one shown in Figure 2.4 it is possible to aggregate several prefixes and use a single (shorter) prefix to represent them. Consider, for example, the four networks connected to r 1, as they are only connected to r 1, and as they obviously share a common (shorter) prefix, namely 131/8, they can be advertised to the rest of the network using this shorter prefix. It is important to note that two conditions must be satisfied for the aggregation to be possible: first, the networks must be close to each other in the network, second, they must share a common prefix. The three networks 26

27 connected to r 6, and the two connected to r 4 meet only the first condition. The alter reader might have already noticed that it is actually possible to use the /11 prefix given that the four (longer) prefixes: /16, /16, /16 and /16 have exactly the same values in the first 11 bits. This shows how it is always possible to use a shorter prefix: obviously if a set of addresses have the same values for the first k bits they also have the same values for the first i bits i k. Note that, typically, when writing prefixes in decimal notation, the part after the prefix is set to 0 but this it not always the case and can lead to confusion: for example the /11, /11, /11 are three of the many different ways of writing exactly the same prefix, as the first 11 bits are the same in each case, only the bits after the eleventh one are different. By observing all the networks connected to r 1 and r 2, we can see that they all share the 131/8 prefix. Note that this is the longest prefix they share as the networks connected to r 2 have values larger than 128 in the second byte, while those connected to r 1 have values smaller than 128 in the second byte. It is therefore possible to use the 131/8 prefix to characterize all the networks connected to r 1 and r 2. More precisely, using a variable prefix length like in CIDR, it is possible to replace six entries (131.33/16, /16, /16, /16, /16, /16) with just one (131/8) in the routing tables of r 3, r 4, r 5, and r 6. One can also reduce the number of entries in the routing table of r 2, by replacing the four entries for the network connected to r 1 (131.33/16, /16, /16, /16) with only one using the prefix /11. In the network shown in Figure 2.4, there are other networks whose prefixes could be aggregated, given that these networks are close to each other: the two connected to r 4 and the three connected to r 6. This is not possible, though, as the prefixes allocated to these networks are not contiguous and do not have a common prefix, other than the prefix of length 1 for 195 and 151, which is not very useful as it is too short and it is also shared by the networks connected to r 1 and r 2. Changing the prefix allocated to these networks is the only solution, if we want to be able to aggregate them. This operation is also called renumbering as it changes the numerical addresses of all the machines involved. It can be a fairly complicated operation given that, at the very least, it is necessary to reconfigure all the routers involved and some other devices like configuration servers (see the chapter about IP ). Yet, in certain cases, the the benefits outweigh the costs and such operations do take place in the Internet. As we will see in section 2.4.1, IP prefixes are now allocated on a regional basis, with each region corresponding, roughly to a continent. All the prefixes allocated to a region are administered by the regional registry, whose role is to assign sub-prefixes to large Internet Service Providers (ISP), which in turn, will allocate sub-sub-prefixes to theirs customers, which can be other (smaller) ISPs and/or edge networks. Note that we have used the terms sub-prefix and sub-sub-prefix only to emphasis the fact that, once a certain prefix has been assigned to an entity, this entity can further divide the prefix it has received in a any way it wants and allocate parts of it to its customers. In the remainder of this chapter we will always use the term prefix, with the understanding that each prefix can be part of a shorter prefix and, likewise, it can contain several longer prefixes. 27

28 ISP B using prefix α k1,1 ISP A using prefix β k2,2 n 2 : α k1 4,2 i 2 i n 13 : r 1 10 α k1 4,9 i 2 r 9 i 1 n 15 : β k2 3,6 i 2 r 8 i 1 n 14 : β k2 3,5 n 1 : α k1 4,1 i 4 i 3 i 2 r 1 i 1 n 3 : α k1 4,3 n 12 : β k2 3,4 n 11 : β k2 3,3 i 2 i 1 r 7 n 4 : α k1 4,4 i 4 i r 3 i 2 i 2 r 1 i 5 3 i 5 i 2 i 1 i 4 r 6 i 6 i 1 i 3 i 2 n 10 : β k2 3,2 n 5 : α k1 4,5 n 6 : α k1 4,6 i 4 r 4 i 3 i 5 i 1 i 2 i 3 i 2 r 5 i 1 n 7 : α k1 4,7 n 8 : α k1 4,8 n 9 : β k2 3,1 Figure 2.5: A simple network with two ISPs: the one on the left of the dotted line uses the prefix α k1,1, the one on the right of the line uses the β k2,2 prefix. Figure 2.5 shows a network similar to the one in Figure 2.4, the main difference being that a few networks and routers have been added. Suppose that there are two different ISPs in the network: one on the left of the dotted line (A) and one on the right (B), the α k1,1 (i.e., the first prefix of length k 1 ) has been allocated to the operator on the left and the β k2,2 has been allocated to the operator on the right, the fact that the second operator uses the second prefix among all those of length k 2 guarantees that, even if k 1 = k 2, the two prefixes used by each ISP are indeed different. Each network has been labeled n i with i = 1, 2,..., 15, so that we can refer to a specific network using this name. ISP A has 9 networks, while ISP B has 6, therefore A needs to allocate at least 4 bits do identify each network, while B needs only 3. In other words, A needs to allocate sub-prefixes of length at least k 1 4 to each one of its 9 networks, as log 2 9 = 4, and B needs to allocate sub-prefixes of length at least k 2 3 to each one of its 6 networks, as log 2 6 = 3. If they adopt this solution, each one of A s networks can have up to 2 n (k 1 4) machines and each one of B s networks can have up to 2 n (k 2 3) machines. Recall that n is the total address length, and that the notation α k1 4,i corresponds to the i-th (sub)prefix of length k 1 4. If, for some reason, any of these networks has more machines than these limits, the only solution is to split it into two or more smaller networks. Another solution could be to merge some smaller networks, provided they existed, in order to reduce the total number of networks so that we could use a shorter sub-prefix, but this solution works only if we can reduce the total number of networks to a smaller power of 2. 28

29 Clearly there is a compromise between the number of networks (i.e., sub-prefixes) and the number of machines on each network. With the solution proposed above, A can add up to = 16 9 = 7 networks without changing the prefix lengths. Similarly, B can add up to = 8 6 = 2 networks. If, for some reason, A or B have reason to believe that the number of networks will grow more, they can use a longer sub-prefix for each network. The price they have to pay in this case is that there are fewer addresses in each sub-prefix. Longest Prefix Match When using flat addressing or a fixed prefix length, each destination address will match, at most, one entry in the routing table. In the case of flat addressing there are complete addresses in the left column of the routing table. In the case of a fixed prefix length there are prefixes but, even in the case of multiple (fixed) prefix length, like in the Internet before 1994, each address belongs to exactly only one prefix therefore there is never more than one matching entry. In the case of variable prefix length, instead, it is possible to have multiple matches. It is therefore essential to specify which entry should the router use in the case of multiple matches. One possible solution, and the one used in the Internet since 1994, is to use the longest prefix match. Whenever an address matches multiple prefixes the router should use the longest one. 5 Note that it is impossible for an address to match two prefixes of the same length, therefore the longest matching prefix is always unique. Thanks to this rule it is possible to specify routes to specific sub-prefix(es). In the network shown in Figure 2.5, there are three links crossing the boundary between the two ISPs, if each router could use only the whole prefixes α k1,1 and β k2, 2, all the traffic from that router to the other ISP would use the same inter-isp link. It is clearly preferable to be able to send part of the traffic on each link. One solution is to use all the shorter sub-prefixes (one for each network) but clearly this is just as undesirable given that it is exactly the solution used with the fixed prefix length. A better solution, instead, is to exploit the longest prefix match algorithm. Consider r 1 : it seems appropriate that it should send the traffic addressed to the networks n 14 and n 15 through r 9 and r 10, and possibly the traffic for n 11 as well. This can be easily accomplished by using just three entries in the routing table of r 1 : one with β k2,1 and i 1 and two with β k2 3,6, βk 2 3, 5 and i 3. This way it is possible to cover the whole β k2,2 prefix with just three entries, instead of 6 as in the case of fixed prefix length. On such a small network the gain might seem negligible but over a network as large as the Internet this can significantly reduce the size of the routing tables. At r 4, instead, we might prefer to route all the traffic for β k2,2 towards r 6 and only the traffic for β k2 3,1 towards r 5. Again this can be accomplished with only two entries, one with β k2,2 and i 3 and one with β k2 3,1 and i 2. We have previously mentioned that at r 1 we might be interested in routing all the traffic for n 15, n 14 and n 11 towards r 10, this can be accomplished, as mentioned above, 5 The prefix of length 0 is used to indicate the default route as it matches any address. 29

30 using one extra entry for each sub-prefix but, as the number of networks in our target groups grows so would the number of entries we need to add to the routing table. A better solution is to use a common sub-prefix for these networks. For example, we could allocate a sub-prefix of length k 2 3 to the three networks and then a sub-sub-prefix of length k 2 5 to each one of the networks. Clearly the sub-sub-prefix of length k 2 5 must belong to the specific sub-prefix of length k 2 3 that we had decided to use for these networks. Each ISP or whatever institution/company running the network can decide to partition the assigned prefix in any way it wants, the only constraint is that each group of addresses has to be a power of 2: no matter what the prefix length is, the number of addresses with the same values in the first k bits is always a power of 2. Note the it is also possible for each router to see different prefixes. For example, in the network shown in Figure 2.5, r 3 would use only the two longer prefixes: α k1,1 associated with the interface i 2 and β k2,2 associated with i 1. While, as mentioned above, r 1 and r 4 can use shorter prefixes as well. Recall that, throughout this chapter, we are assuming that the address size is fixed and equal to n. As an organization cannot use on its network addresses which are outside the prefix it has been allocated, it can use only n k bits to handle any further subdivision. 6 In the case of IP there is also the extra constraint that in each address block (network) it is not possible to use the address with all ones and all zeros in the host part. Clearly the longer the address is, the larger the address space and the easier it is to efficiently allocate different prefixes, sub-prefixes, sub-sub-prefixes and so on. One of the advantages of IPv6 is that it uses addresses with 128 bits, resulting in an extremely large address space allowing a much greater flexibility in allocating prefixes than in IPv4, with potential benefits for the size of the routing tables used in the Internet. 2.4 Routing Table Consistency In the previous section, we have looked at a few specific examples of routing tables, considering one router at a time. Routers do forward packets independently as each router consults only its local routing table whenever it has to forward a packet. It is nonetheless important to underline the fact that, while each router operates independently, the routing tables have to be consistent with each other. Consider the following example using the network shown in Figure 2.5 : whenever r 2 receives a packet for n 15, it forwards it to r 6 ; whenever r 6 receives a packet for n 15, it forwards it to r 4 ; whenever r 6 receives a packet for n 15, it forwards it to r 2, forming a routing loop. In this case, whenever a packet enters in this loop it will never exit (as long as the routing tables are not changed). In the case of IP, the packet will eventually be discarded when the Time To Live (TTL) field reaches zero. This field is initialized to a finite positive value by the sender and decremented by one by each router forwarding the packet. 6 Certain (larger) organization and ISPs in particular often receive multiple prefixes and they can administer each one of them as they prefer. 30

31 In the case of Ethernet, instead, the packet would indeed loop forever as Ethernet does not have a TTL field or any equivalent mechanism. For this reason Ethernet networks use the spanning tree algorithm to make sure that packets are always forwarded along a tree: instead of using all the links in the network, the spanning tree algorithm selects a subset of the links that form a tree covering (spanning) all the nodes and only these links are used to carry traffic. In this case packets will never loop as long as each intermediate node does not forward a packet on the same interface where it was received. This condition can be enforced locally by each node and does not require any global knowledge. In most IP networks, routers use a routing protocol (see the chapter about IP ) to share routing information and to choose loop-free routes. In the, somewhat rare, cases where routing tables are configured by hand, great care must be taken to make sure that there are no loops in the routes and the packets will indeed follow the desired root. Even for small networks this becomes quickly intractable as the number of routes to consider grows with the square of the number of prefixes (networks): for example in the network of Figure 2.5 there are 15 (sub)networks for a total of 225 source-destination pairs IP Prefix Allocation The situation shown in Figure 2.4, with neighboring networks with non-contiguous prefixes was not uncommon in the Internet, where, until 1994, prefixes were often allocated to entities like universities, research centers and companies that could be described as edge networks (or leaf networks ) as they are typically at the edge of the Internet and do not usually interconnect other networks. Furthermore no geographical consideration played a role in how prefixes were assigned, for example the 140.8/16 prefix could have been allocated to an organization in Germany while 140.7/16 and 140.9/16 could have been allocated to organizations in a different country or even on a different continent. While geographical proximity does not necessarily imply network proximity, it is extremely unlikely that networks on different continents will be next to each other network-wise. Since 1994, prefixes are not allocated directly to edge networks, instead the IPv4 address space has been divided in several fairly large blocks (typically /8) which have then been assigned to 4 regional registries: AFRINIC (African Network Information Center) APNIC (Asia Pacific Network Information Centre) ARIN (American Registry for Internet Numbers) (North America) LACNIC (Latin America and Caribbean Network Information Centre) RIPE NCC ( Réseaux IP Européens Network Coordination Centre) (Europe, Middle East, Central Asia) The IANA website has a list 7 of all the prefixes allocated to the different regional registries (and a few large corporations/institutions that had acquired these prefixes before 1994). 7 Available at 31

32 Internet ISP A ISP B ISP C n 1 n 4 ISP D n 7 n 2 n 3 n 5 n 6 Figure 2.6: An example where all the customers of ISP D (i.e., n 5 and n 6 ) have to change their addresses if ISP D changes its own ISP from B to A. The regional registries assign the addresses they have received from IANA to large ISPs and then each ISP allocates them to its own customers, which can be other (usually smaller) ISPs and so on until the final customers. The number of organizations which allocate prefixes between the regional registry and the final customer is not fixed and, in some cases, a institution/company can use directly the prefix it has received from the registry, without any further delegation. In the current scheme, as opposed to what happened before 1994, the ISPs control the addresses and a leaf network typically has to change its addresses if it changes ISP. This problem is compounded in the case where an ISP, which has not received its addresses directly from the regional registry, changes its own ISP forcing its customers to change address as well. Figure 2.6 shows such an example: if ISP D changes its own ISP from B to A, its customers n 5 and n 6 have to change all their addresses as well given that now D will use one of prefixes allocated to A instead of one of the prefixes allocated to B. 2.5 Different Message and Address Types While in RES 302, and throughout this chapter, we consider only unicast addresses and messages (with a few words about the broadcast case), it is useful to briefly mention the definition of the different address (and message) types: Unicast: the message is addressed to a single specific node. Broadcast: the message is addressed to all the nodes in the network (the sender being on the network in question). In the case of IP we talk mainly about limited broadcast where the message is addressed to all the nodes in a subnet (prefix). In the case of limited broadcast is possible, at least in theory, for the sender to be on a different network. Multicast: the message is addressed to a subset of nodes. Typically nodes need to register their interest in receiving the messages addressed to a given multicast 32

33 address. An example is a video-conference with more than two participants (the video-conference corresponds to a unique multicast address and all the participants need to explicitly register in order to receive the packets belonging to the videoconference). Another example is the distribution of a video flow, like a TV channel. Note that the network operator needs to deploy the infrastructure needed to support multicast. Anycast: the message is addressed to any one node belonging to a specific group. An anycast message is supposed to be delivered to only one node, typically the closest one to the group among all those belonging to the group. An example is DNS: when a host needs to resolve a name it could send the request to the anycast address corresponding to the DNS service, instead of sending the request as a unicast message to a specific DNS server. This way there is no need to configure the IP address of a DNS server in each host, furthermore if a new DNS server is deployed closer to the host there is no need to change the configuration of the host. Just like in the multicast case, the network operator needs to deploy the infrastructure needed to support anycast services. The interest reader is referred to RFC 4786 [1] for a discussion on the operation of anycast services. 33

34 3 The Network Layer (IP Protocol) 3.1 Introduction The main goal of the network layer is to deliver packets between end-nodes. In the case of the Internet Protocol (IP), the end-nodes are called hosts and are uniquely identified by a fixed-length address (32 bits in the case of IPv4 and 128 bits in the case of IPv6). As the its name suggests, IP can connect different networks (inter-networking). In an IP network, routers (sometimes called gateways) interconnect these different networks and are in charge of routing packets from the source host to the destination host. As explained in Chapter 2, each router uses its forwarding table to decide to which of its neighboring routers it should forward each packet, until the packet reaches the router directly connected to the destination host. IP routers are also in charge of fragmenting IP packets whenever these are too large to be sent on a certain link. The IP layer in the destination host is in charge or re-assembling all the fragments of an IP packet, before delivering it to the transport layer. The IP layer offers and unreliable service: packets can be lost, duplicated and delivered out of order. It does not offer any congestion or flow control service either. While it is possible to configure additional mechanisms on most routers to offer Quality of Service (QoS) guarantees, this is still fairly rare in the public Internet where routers only offer a best effort service which comes with no QoS guarantees whatsoever. While there are many similarities between IPv4 and IPv6, the two protocols do have several differences; in the interest of simplicity, the rest of the chapter will deal only with IPv The IP Protocol Figure 3.1 shows the IPv4 header, as defined in RFC 791 [27]. It has the following fields: Version (Ver.)(4 bits): the version of the protocol, four in the case of IPv4. IP Header Length (IHL) (4 bits): the length of the header in words of 32 bits. This value corresponds to the offset of the IP payload from the start of the header. Note that padding is used to ensure that the header length is always a multiple of 32 bits. The smallest possible value for this field is 5 (i.e., 20 bytes). Type of Service (8 bits): originally meant to distinguish between different QoS classes. With each class corresponding to different QoS parameters, like delay, throughput, reliability. RFC 2474 [24] and RFC 3168 [30] have the latest format of this field: the first six bits are the Differentiated Services Field, containing the code 34

35 32 bits Ver. IHL Type of Ser. Total Length Identification 0 F L Fragment Offset Time To Live Protocol Header Checksum Source Address Destination Address Options Padding Figure 3.1: The IPv4 header. corresponding to the QoS class of the packet (RFC 2474); the last two bits are used for Explicit Congestion Notification (ECN)(RFC 3168), which can be used to signal to a TCP sender that it should reduce its rate. Routers supporting ECN can set one of the two bits in the case of congestion, this bit will be copied by the destination in the acknowledgments so that the source will be aware of the congestion and reduce its sending rate. Both Differentiated Services and ECN are outside the scope of RES 302 and we will not delve any further into them, the interested reader is referred to RFC 2474, RFC 3168 and related RFCs. For a brief history of the ToS field see section 19 of RFC 2481 [29]. Total Length (16 bits): the total length of the IP packet, including the header. The maximum value is This is the total length, therefore the maximum payload size is smaller and depends on how many options (if any) are used. RFC 791 states that all hosts must accept IP packets of at least 576 octets. Note that this is not the minimum packet size. It just implies that all IP hosts must be capable of receiving (and handling) packets with up to 576 octets. Identification (16 bits): an identifying value for each packet. This value is chosen by the sender and it can be used to identify fragments belonging to the same packet (see below). Flags (3 bits): contains three flags: Bit 0: reserved, must be 0; Bit 1 (F): whether the packet can be fragmented or not (0=May Fragment, 1=Do Not Fragment); Bit 1 (L): whether this packet is the last fragment of a packet which has been fragmented before reaching the destination (0=Last Fragment, 1=More Fragments). 35

36 Fragment Offset (13 bits): the offset from the beginning of the first fragment of the current IP packet. The offset is measured in terms of 8 octets (64 bits). Time to Live (TTL) (8 bits): the sending host must initialize this field with a non-zero value. Every router forwarding the packet decrements its value by one. If it reaches zero, the packet must be discarded. This it to make sure that packets will eventually be destroyed even in the case of routing loops. Recall that it is possible to have routing loops in an IP network. Obviously this is undesirable but can be the result of a mistake in the configuration of a router. Loops can also temporarily appear when routers are propagating new routing information, for example following a topological change due to a link failure or a link recovery. Originally, this field was meant to represent the maximal lifetime of a packet in seconds, hence the Time To Live name. Given the difficulty of accurately measuring the life time in seconds of each packet, this field is now used to express the maximum number of hops that a packet can make (i.e., the maximum number of routers it can traverse). Typically each Operating System has a default value for the TTL of new packets, usually 64, which is the value recommended by IANA 1. Protocol (8 bits): the code indicating the protocol of the payload. Typically this is a layer 4 protocol but not always, for example it is possible to have an IP packet inside another one (this is usually used in IP tunnels ). Initially these codes were specified in a separate RFC ([26]) which has been updated by many other RFCs. Since 2002 IANA maintains an online database with the latest version of all the codes at http: // (see RFC 3232 [34]). Some examples: 6 corresponds to TCP, 17 to UDP and 1 to ICMP (all these values are in decimal notation). Header Checksum (16 bits): the checksum computed on the header only. See RFC 791 (p. 14) for the details of the algorithm. Source Address (32 bits): the address of the source. Destination Address (32 bits): the address of the destination. Options (variable size): as the name suggests, this field is optional (its presence can be deducted by the header length). Options can be used for source routing and timestamping among others. The complete and updated list of valid options is available on the IANA website: IP Fragmentation Figure 3.2 shows an example of packet fragmentation. The Maximum Transmission Unit (MTU) is 9000 bytes on the link between the source and the first router. Therefore the source can send a packet (P 1 ) with 1600 bytes in the payload (the example assumes that no IP options are used in the packet so that the header is 20 bytes). The outgoing 1 See 36

37 MTU 9000 B S Len P Id 341 F 0 L 0 Off. 0 Payload len=1600 MTU 1500 B R1 Len P Id 341 F 0 L 1 Off. 0 Payload len=1480 Len P Id 341 F 0 L 0 Off. 185 Payload len=120 R2 Len Id F L Off. Payload Len Id F L Off. Payload P len=488 P len=488 MTU 512 B Len P Len Id 341 Id F 0 F L 1 L Off. 122 Off. Payload len=488 Payload Len P 7 36 Id 341 F 0 L 1 Off. 183 Payload len=16 P len=120 D Figure 3.2: An example of packet fragmentation in IPv4. link of the first router has an MTU of 1500 bytes, forcing the router to split the packet in two. This operation is permitted as the F flag in the header is 0, indicating that routers can fragment the packet. The first packet (P 2 ) contains the first 1480bytes of the payload and the second packet (P 3 ) the remaining 120. Both packets have the same ID (341) as the original packet, so that the receiver can re-assemble them. The second packet (P 3 ) has the F flag set to 0, indicating that it is the last fragment. The offset field in P 3 is set to 185, indicating that the offset of the first byte in the payload is = 1480, this is because the offset is expressed as a multiple of 8 bytes. The MTU for the link between the second router and the destination is only 512 bytes, forcing the second router to create even more fragments. It divides P 2 into four packets: three (P 4, P 5, P 6,) with a payload of 488 bytes each and one (P 7 ) with a payload of 16. The total length of the first three packets is 508, which is less than the MTU. This is because a packet with a total size equal to the MTU (512 bytes) would have a payload size of 492 bytes, which is not a multiple of 8. The largest multiple of 8 corresponding to an acceptable payload length is 488. (Recall that we are assuming that the are no IP options so that the header size is 20 bytes.) The source has all the information need to reassemble the fragments: all fragments have the same ID, each one carries the offset, indicating the position of the fragment in the original packet. Note that destination combines the ID with the source address, the destination address and the protocol field in order to decide which fragments belong to the same packet. This prevents ambiguities even if different senders choose the same ID at the same time. 37

38 3.2.2 IPv4 addressing As we have already seen in Chapter 2, IP was developed as a mean to connect several existing networks into one larger inter-network. These existing networks were such that all the computers connected to the same network could already communicate directly with each other. Networks used different protocols and the role of IP was to be a network layer protocol shared by all these networks, so that any two computers could communicate with each other using IP, irrespective of the network they belonged to. These networks are sometimes called sub-networks to emphasize the fact that they are all connected in order to form a single, larger, network. It is customary to think about these sub-networks as layer 2 networks, implying that these networks differs only as far as layers 1 and 2 are concerned. A typical example is an Ethernet network: by definition such a network implements only layers 1 and 2. Layers 3 and 4 are provided by IP and companion protocols (TCP and UDP at layer 4). While it is useful to think about this ideal case and while we will only consider this case in RES 302, real networks can be much more complicated and might have multiple layer 3 protocols. For example some of these sub-networks can use Asynchronous Transfer Mode (ATM) networks which is a layer 3 protocol. 2 At the same time, it is always true that all the computers connected to a given sub-network can communicate directly using a certain protocol, which we can call the sub-network protocol, whatever its layer. Therefore IP can use the services offered by the sub-network protocol in order to send and receive data between any two nodes belonging to the sub-network. For example, in the case of an ATM subnetwork, IP can use the ATM protocol to exchange packets directly between any two computers connected to the ATM subnetwork, even though ATM happens to be a layer 3 (and 4) protocol. Similarly, in the case of an Ethernet sub-network, IP can use the services provided by Ethernet to exchange packets directly between any two nodes on the same Ethernet sup-network. The commonly used expression to communicate directly refers to two nodes connected to the same sub-network that can communicate using the sub-network protocol without the intervention of an IP router. In other words there are no IP routers inside each sub-network. Hence the IP packets exchanged between two hosts on the same sub-network will not go through any IP router. This is not surprising, as the role of an IP router is exactly to connect different sub-networks. In this context, it is natural to assign a different IP prefix to each of these (sub)- networks: all the computers on the same network have IP addresses that share the same prefix. As explained in Chapter 2, this was first achieved by using three different prefix lengths with the corresponding address classes. Since 1994 prefixes can be of arbitrary length but the principle is always the same: all the IP hosts on the same sub-network share the same prefix and must be able to communicate directly at layer 2. To be precise the smallest and largest address in each prefix cannot be assigned to specific interfaces: the largest address (with all the bits in the host part set to one) is reserved as the broadcast address and it is meant to represent all the interfaces on a 2 To be precise ATM is a complex set of protocols offering layer 3 and 4 services, but this is outside the scope of RES

39 A B Ethernet 45.26/16 R Ethernet /24 C R Ethernet /24 PPP /30 D R R PPP / ATM 25.45/16 Ethernet / E F Figure 3.3: A simple IP inter-network. certain subnet. Similarly the smallest address (with all the bits in the host part set to zero) is reserved to identify the subnet itself. 3 Therefore if a prefix of length k has been assigned to a subnet, only 2 n k 2 addresses can actually be used (where n is the length of the addresses). This is way the longest possible prefix length in IPv4 is 30 and not 31: a prefix of length 31 has only two addresses and both of them are reserved; a prefix of length 30, instead, as four addresses and two of them can be used. In an IP network, even point-to-point links, which, by definition, connect only two interfaces, must use a prefix of length at most Figure 3.3 shows a simple inter-network, that is a collection of different networks connected using IP routers. The IP protocol is the common language spoken by all the end-nodes in each of the sub-networks. This way any two nodes in the inter-network can exchange data using the IP protocol. Note that this is exactly what the Internet is, the only difference is that the number of sub-networks in the Internet is extremely large. For example, host A can communicate with host B as well with host D by using the IP protocol, even though the former is on the same sub-network while the latter is not. The IP layer in each host will handle the communication correctly. As far as layer 4 is concerned, there is no difference in exchanging data between A and B or A and D. 5 3 As noted in RFC 3021 [33], the address with zeros in the host part is an obsolete form of broadcast address. See RFC 1812 [2] and RFC 922 [21] for more details about these addresses. 4 Actually RFC 3021 [33] introduced prefixes of length 31, but this is outside the scope of RES As you have seen in the socket programming exercises, you only need to specify the IP address (and 39

40 Handling Inter and Intra Sub-Networks Communications While the upper layers (Transport and above) are not aware of the location of the other communication end-point, the IP layer must handle the differences in the communication, depending on whether the destination is on the same IP-subnet or not. If the destination of an IP packet is in the sub-net as the sender, it means that the two nodes can communicate directly at layer 2: the sending node can encapsulate the IP packet in a layer 2 frame whose destination address is the layer 2 address of the destination. Such a frame will reach the destination without going through any IP router. RFC 1122 [5] calls this a local delivery. If the destination is not in the same IP subnet, the packet must go through one or more IP routers in order to reach the destination. In this case the source must send the packet to one of the IP routers connected to its subnet. Obviously any IP subnet must be connected to at least one router in order to be part of an inter-network. All IP nodes know the IP address of at least one router connected to the same subnet. This implies that the address of the node and the address of the router must have the same prefix, so that the node can communicate directly at layer 2 with the router. Therefore the source can encapsulate the IP packet insider a layer frame whose destination address is the layer 2 address of the router. The router will then consult its routing table and forward the packet accordingly. RFC 1122 calls this case remote delivery. If there are multiple routers connected to the same subnet, the source will not always contact the best placed one (i.e., the one closest to the destination). Whenever a host has a packet for a node that is not on the same subnet, it will first forward it to the default gateway. In some cases, it is possible that the default gateway will then forward the packet to one of the other routers in the same subnet, let R d be the first (default) router receiving the packet and let R o be the router best placed to reach the destination among all those connected to the same subnet. In this case it would obviously more efficient for the source to send packets directly to R o, to this end R d can send an ICMP redirect message (see section 3.2.5) telling the source to send the packets directly to R o. In this case the source should store this information in a local cache. Consider, for example, the network shown in Figure 3.3, it is reasonable for D to use either R 1 or R 3 as its default gateway, rather than R 4. Suppose that R 3 is the default gateway for D. In this case, if D has a packet for F, it will forward it R 3 which will then forward it to R 4. In this case R 3 will also send an ICMP redirect message to D, informing it that F is reachable via R 4. 6 One problem with this solution is that ICMP redirect message are not secure. They are nor encrypted and the receiver cannot be sure of the identity of the sender: any host can send a redirect message, potentially intercepting the traffic of other nodes. This is why redirect messages are not often used. So far we have discussed the difference between local and remote destination nodes but we have not yet seen how the source can distinguish between the two cases. This can the port number) corresponding to the other end of the socket, regardless of whether the destination is on the same sub-network or not. 6 See section of the RFC 1122 for a detailed description. 40

41 be easily accomplished by the following algorithm: 1. The source performs a bitwise AND between its own netmask and the destination IP address; 2. The source performs a bitwsie AND between its own netmask and its own IP address. 3. If the results of these two operations are equal the destination is in the same subnet; if they are not, it is in a different subnet. Algorithm 1 The pseudocode presented in RFC 950 to distinguish between local and remote destination addresses. if bitwise and(dg.ip dest, my ip mask) = bitwise and(my ip addr, my ip mask) then send dg locally(dg, dg.ip dest) else send dg locally(dg, gateway to(bitwise and(dg.ip dest, my ip mask))) end if Algorithm 1 shows the pseudocode proposed by RFC 950 [22] (section 2.2) for sending IP packets. As IP packets are sometimes called IP datagrams, the dg in the pseudocode stands for datagram. The last problem to solve is how the source can find the layer 2 address of the destination (in the case of local delivery) or the layer 2 address of the gateway it has decided to use (in the case of remote delivery). Note that in both cases the layer 2 address belongs to a node (end-host or router) connected to the same layer 2 network as the source. In the case of Ethernet network the source can use the Address Resolution Protocol (ARP), which is covered in the next section. What we have described so far is what existing RFC prescribe for end-nodes. That being said, most modern Operating Systems use a slightly different solution: each node has a routing table (just like IP routers) and it uses the longest prefix match algorithm to determine where to send outgoing packets. The details of this solution are outside the scope of RES The Address Resolution Protocol (ARP) As explained in the previous section, nodes (either hosts or routers) can use the Address Resolution Protocol to find the MAC address corresponding to a certain IP address. The basic idea behind the protocol is fairly simple: suppose that two nodes A and B are on the same IP subnet, that their IP addresses are and respectively and that their MAC addresses are m A and m B. If A wants to send an IP packet for B it needs to find B s MAC address, as discussed in the previous section. In this case A sends a broadcast (at layer 2) message asking who has the IP address (ARP calls this the target IP address). This is an ARP request message, which contains 41

42 32 bits Hardware Type Protocol Type Hardware Address Size Protocol Address Size Operation Code Sender Hardware Address Sender Hardware Address (cont.) Sender Protocol Address (cont.) Sender Protocol Address Target Hardware Address Target Hardware Address (cont.) Target Protocol Address Figure 3.4: The Ethernet header and the ARP packet format for Ethernet networks. the target IP address as well as the IP and MAC address of the sending node ( and m A in the example). Given that the ARP request is a broadcast message, all nodes on the layer 2 network receive it. Each node compares the requested IP address with its own and the station which recognizes its own IP address will reply with an ARP reply message, which is a unicast message to the node which sent the ARP request. Obviously the ARP reply contains the MAC address of the destination but it also contains its IP address, as well as the MAC and the IP address of the node that sent the ARP request. In our example, B would receive the ARP request, recognize its IP address ( ) as the target address and send an ARP reply message with its MAC address (m B ). In this case B would also learn A s MAC address, as this information is included in the request, as well as A s IP address. This way B does not need to generate a new ARP request if it has a packet for A. As communications are often bidirectional, it is reasonable to assume that B will send IP packets to A. Figure 3.4 shows the ARP packet format for Ethernet networks, as specified by RFC 826 [25]: Hardware Type (2 bytes): a code indicating the layer 2 protocol used, the value for Ethernet is 1. A first list of the available codes appeared in RFC 1060 [35] but that RFC is now obsolete and the up-to-date list of the codes can be found on the IANA website. 7 Protocol Type (2 bytes): a code indicating the layer 3 protocol used. ARP can be used with protocols other than IP, hence the presence of this field. The codes used are the same as those used in Ethernet frames to indicate the layer 3 protocol. These

43 codes are often called Ethertype and they are administered by the IEEE. 8 The code for IPv4 is 2048 in decimal notation, which corresponds to 800 in hexadecimal notation. Hardware Address Length (1 byte): the length, in bytes, of the hardware (i.e., layer 2 ) addresses. The value for Ethernet network is 6, corresponding to 48 bits. Protocol Address Length (1 byte): the length, in bytes, of the network layer addresses. The value for IP network is obviously 4, corresponding to 32 bits. Operation Code (2 bytes): a code indicating the requested operation. RFC 826 defines only two values: 1 for requests and 2 for replies. Currently (2012), other operation codes have been defined, see the IANA website for details. Sender Hardware Address (length specified in the Hardware Address Length field): the hardware address (MAC address for Ethernet networks) of the sender of the packet. Sender Protocol Address (length specified in the Protocol Address Length field): the protocol address (IP address for IP networks) of the sender of the packet. Target Hardware Address (length specified in the Hardware Address Length field): the hardware address (MAC address for Ethernet networks) of the recipient of the packet. Target Protocol Address (length specified in the Protocol Address Length field): the protocol address (IP address for IP networks) of the recipient of the packet. Note that the ARP packet cannot be encapsulated in an IP packet as the MAC address of the destination is not yet known when an ARP request is sent. Therefore it is encapsulated directly in an Ethernet frame with protocol type set to 2054 in decimal notation, corresponding to 806 in hexadecimal notation. If no machine in the layer 2 network is currently using the target IP address, or if the machine using that address is not turned on, no ARP reply message will be generated. Most Operating Systems will send again a few times an ARP request when they do not receive a response after a certain time. If no responses are received, the Operating System will declare the target IP address as unreachable and generate the corresponding error condition. Hosts can also use the ARP protocol to determine whether an IP address is already in use: if a host sends and ARP request for a certain IP address and if it does not receive any reply, it can conclude that, at least for the time being, that IP address is not in use. The DHCP standard (RFC 2131 [17]) suggests using ARP requests to verify that a certain IP address is not already in use and RFC 5227 [6] clarifies further this mechanism and its parameters (timeouts, number of attempts, etc.). It worth mentioning that in IPv6 ARP has been replaced by a similar protocol, called Neighbor Discovery Protocol (NDP) (see the RFC 4861 [23]). 8 See for an up-to-date list. 43

44 ARP Cache As hosts typically exchange more than a single IP packet, it is useful to store the information obtained thanks to ARP requests and responses in a local cache. RFC 826 suggests storing the relationships between IP and MAC addresses in a table. It also mentions that, as already noted above, the node replying to an ARP request knows the IP and MAC address of the sender and, therefore, it should store this information in its cache. It is often the case that when one uses caches to store information for a later use, one has to address the problem of the validity of the cached information as time goes by. This problem is typically addressed by using timeouts and by removing the information once the timeout has expired. The value of this timeout and, more in general, the cache update mechanism are not specified in RFC 826 and are implementation specific. It is worth mentioning that on several Operating Systems (including Unix-based systems), one can use the arp command to show the local ARP cache and to modify it Dynamic Host Configuration Protocol Based on what discussed in the previous sections, it should be clear that an IP host must be configured, at the very least, with an IP address and the associated netmask (i.e., prefix length) in order to be able to to exchange IP packets with other IP hosts on the same layer 2 network. In order to communicate with IP hosts on other subnets, an IP host needs also to know the IP address of at least one router connected to the same subnet as the host. This router is often called the default gateway. Finally, in order to use the DNS, a host needs to know the IP address of at least one DNS server. One possible solution is to configure all these parameters by hand on each node. Obviously this is a tedious and error prone procedure, which is rarely used. A few protocols have been proposed to address this problem. One of the first attempts was the BOOTP protocol, presented in RFC 951[8], this protocol is aimed mainly at diskless computers that need not only to configure the parameters of the IP stack but also to download an image of the Operating System from a server, hence the name BOOTP, which stands for bootstrap protocol. The most widely used protocol for automatic configuration is the Dynamic Host Configuration Protocol (DHCP), which started as an extension to the BOOTP protocol (see RFC 1531 [9]). RFC 2131 [10] contains the current version of DHCP. DHCP can be used to set several parameters in each hosts, these include, but are not limited to, the following: IP address; netmask (i.e., prefix length); default gateway; IP address(es) of (a) DNS server(s); DNS name of the host; 44

45 domain name for the host (e.g., telecom-bretagne.eu; default IP Time To Live; interface Maximum Transmission Unit (MTU); print server. DHCP is based on a client server model, where one (or more) server(s) contain the configuration information for the hosts in the network. It is possible to differentiate the configuration on a per-host basis. This can be accomplished, for instance, by using the MAC address to identify each host. (In this case the configuration information is associated with the MAC address.) DHCP supports three different methods for allocating IP addresses, in each case the server is in charge of a range of IP addresses and it assigns these addresses to the clients following difference policies: dynamic allocation: the server allocates an IP address to a client for a certain time. The term lease is often used in this case. Clients can request a renewal of the lease at the and of each lease period. In this case it is also possible to have more clients than IP addresses, as long as not all the clients are connected at the same time. (This can be the case for certain ISPs, especially those whose customers use dial-up modems.) automatic allocation: the server allocates the same IP address to the same client. The first time a client requests an address, the server selects an available IP address and stores the MAC address of the client and the corresponding IP address. This way when a previously known client will request again an IP address it receives the same. manual: the network administrator statically assigns IP addresses to MAC addresses. This is usually done by editing a configuration file. One of the advantages of this solution is that only known hosts will be able to obtain an IP address from the DHCP server. At the same time note that this is a very low level of security as it is possible to change the MAC address of a host, therefore a malicious user needs to know only one MAC address of the authorized hosts in order to force the DHCP server to reply. When a host needs to configure its IP interface, it sends a broadcast message, called DHCP DISCOVER, specifying the parameters it needs. Upon receiving this message the server replies with a DHCP OFFER message, offering, as the name suggests, an IP address and the associated parameters requested by the host. It is possible for multiple server to reply, in any case the client will chose only one of these offers and reply with a REQUEST message, addressed to the server it has chosen. This server will then reply with an acknowledgment message ( ACK ). At this point the client is configured and it can start using the network. DHCP is a fairly complex protocol and this section is meant only as a short overview. The interested reader is referred to RFC 2131 [10] for more details. 45

46 32 bits Type Code Checksum Data (variable format) Figure 3.5: ICMP message (the format of the data field depends on the type of message) Internet Control Message Protocol (ICMP) Even though, as previously mentioned, IP is not a reliable protocol, it is still useful for IP nodes to report certain error conditions. For example when an IP packet cannot reach its destination, either because it does not exist or because it is unreachable, or when a packet is discarded because the TTL has expired. IP nodes can use the Internet Control Message Protocol (ICMP) to inform each other of these errors. Routers can also use ICMP to inform hosts that a shorter (more direct) route is available to a certain destination going through a different router. As ICMP is a control protocol used by IP nodes to handle error conditions related to packet forwarding, it is traditionally regarded as a layer 3 protocol, even though ICMP messages are encapsulated inside IP packets, like layer 4 messages. The ping and traceroute programs, available on most Operating Systems, use the ICMP protocol as well, the first to determine whether IP packets can be successfully exchanged between two IP nodes and the second to determine the IP addresses of the routers handling the packets sent between two IP nodes. Figure 3.5 shows the format of a generic ICMP packet: the values of the type and code fields (1 byte each) distinguish the different ICMP messages. Table 3.1 shows some of them. 9 The checksum is calculated using the same algorithm as in IP (see RFC 791 for the details). The format of the data field depends on the type of message. In the case of error messages, like host unreachable or TTL expired, the data field includes the first 64 bytes of the IP packet that caused the error message to be generated. The ping utility The ping program uses ICMP echo request and echo reply message to determine whether IP packets can be successfully exchanged between two IP nodes and, in the case of success it computes the minimum, maximum and average Round Trip Time (RTT) and its standard deviation as well as the packet loss ratio. It is often used to diagnose network problems; if a node does not respond to ping requests it means that there is no IP connectivity between the two hosts. Using different 9 See for a complete list. 46

47 Type Code Description 0 0 Echo reply (ping) Destination network Unreachable 1 Destination host Unreachable 2 Destination protocol unreachable 3 Destination port unreachable 4 Fragmentation required but DF flag set 5 Source route failed 6 Destination network unknown 7 Destination host unknown 0 Redirect Datagram for the Network 1 Redirect Datagram for the Host 8 0 Echo request (ping) 11 0 TTL expired in transit 1 Fragment reassembly time exceeded Table 3.1: The Type and Code values for some of the ICMP messages target nodes, it is sometimes possible to determine where a problem is. For example, if a host cannot ping its own default gateway, it implies that it will not be able to reach computers located on different subnets. Note that, on most operating systems, it is possible to disable ICMP echo replies. Obviously if an IP node has been configured not to generate ICMP replies, it cannot be used as the target of a ping command, but it can still be used as the source. The following is an example of the output generated by the ping utility: Using ping: user@machinename :~$ ping -c 3 pc -df priv.enst - bretagne.fr PING pc -df priv.enst - bretagne.fr ( ): 56 data bytes 64 bytes from : icmp_ seq =0 ttl =56 time =5.115 ms 64 bytes from : icmp_ seq =1 ttl =56 time =4.999 ms 64 bytes from : icmp_ seq =2 ttl =56 time =4.988 ms --- pc - df priv. enst - bretagne. fr ping statistics packets transmitted, 3 packets received, 0.0 packet lossround-trip min/avg/max/stddev = 4.988/5.034/5.115/0.057 ms The ping program sends ICMP echo request messages to the destination specified on the command line. If the user gives a name instead of an IP address, ping uses the DNS to find the corresponding IP address. Figure 3.6 shows the format of an echo reply (and request) ICMP message. The identifier and sequence number are used to match replies to requests. The standard (RFC 792) does not specify what is the difference between the identifier and the sequence number but it does suggest that the Identifier can be used 47

48 32 bits Type Code Checksum Identifier Sequence Number Data (optional) Figure 3.6: ICMP echo request and echo reply message format. S R 1 R 2 R 3 D TTL=1 ICMP TTL expired error message TTL=2 TTL=1 ICMP TTL expired TTL=3 TTL=2 TTL=1 ICMP TTL expired TTL=4 TTL=3 TTL=2 TTL=1 ICMP port unreachable error Figure 3.7: How the traceroute program works between the nodes S and D. like a TCP (or UDP) port to identify a session, while the sequence number can be used to distinguish requests within each session. The data field is optional and, if present, the receiver must copy its content from the request to the reply message. The traceroute utility The traceroute program exploits the fact that IP routers should generate an ICMP TTL expired message whenever they discard a packet. By sending packets with increasing TTL values (starting with 1), traceroute can determine the IP addresses of the routers between the sender and the receiver. Figure 3.7 shows an example of how traceroute works: the source sends a UDP packet to the destination, using a destination port number greater than 33434, with a TTL value of 1. The first router (R 1 in the figure) decrements the TTL by 1 and then generates an ICMP TTL expired error message because the TTL has reached 0. The IP source address of the ICMP message is one of the IP addresses of the router. This 48

49 Sample traceroute output: :~$ traceroute pc -df priv.enst - bretagne.fr traceroute to pc -df priv.enst - bretagne.fr ( ), 64 hops max, 52 byte packets 1 mgs - salsa - i ( ) ms ms ms 2 asr - inside ( ) ms ms ms 3 * * * 4 te1-1 - stbrieuc -rtr noc. renater.fr ( ) ms ms ms 5 te1-1 - lannion -rtr noc. renater.fr ( ) ms ms ms 6 vl857 -pc1 - brest1 -rtr noc. renater.fr ( ) ms ms ms 7 telecom - brest - l3vpn - vl857 -pc1 - brest1 -rtr noc. renater.fr ( ) ms ms ms 8 c vlan36. enst - bretagne. fr ( ) ms ms ms 9 pc -df priv.enst - bretagne.fr ( ) ms ms ms Figure 3.8: Sample traceroute output. way the source knows one of the IP addresses of the first router. Then the source sends another UDP packet to the destination but this time with the TTL set to 2. This way the first router will forward the packet but the second will generate an ICMP TTL expired message. The process is repeated until the source receives an ICMP port unreachable error message, indicating that the destination did receive the packet. Not all routers do generate ICMP TTL expired messages, this is why the traceroute utility waits for 5 seconds before sending another packet with the same TTL value. If it still does not receive any ICMP message after three attempts, it moves to the next TTL value. If, after sending a message with a certain TTL value, traceroute does not receive an ICMP message after a certain time (usually 5 seconds), it uses an asterisks ( * ) to indicate a missing ICMP messages. Figure 3.8 shows a sample output generated by the traceroute utility. Note that the third router is represented by asterisks as traceroute did not receive any ICMP message for the packets it sent with TTL= Network Address Translation As discussed in Section 2.3.2, in the mid 1990s, the Internet switched to Classless Interdomain Routing (CIDR). One of the reasons for this change was the increasing demand for the allocation of IPv4 classes. Recall that, before CIDR, the IPv4 address 49

50 /24 A /24 X B /24 NAT /30 Internet S S Figure 3.9: A NAT example (X is the NAT device). space was divided into a fixed number of prefixes (blocks of consecutive IP addresses) and these prefixes had only three possibly lengths: 8 bits (class A), 16 bits (class B) or 24 bits (class C). Class C prefixes allowed for subnetworks with at most computers, such networks are fairly small and a limited number of institutions and business were interested in them. Class B prefixes, instead, allowed for networks with up to computers, which is enough for most networks. Because of this the demand for class B prefixes was very high, while the demand for Class C prefixes was much lower. CIDR improved this situation by removing the three fixed prefix lengths and introducing a more flexible addressing scheme, which also introduced the possibility of reducing the size of the routing tables by aggregating prefixes. (See Chapter 2 for more details.) At the same time, due to the growing success of the Internet, the demand for IPv4 addresses kept growing, moving forward the day when there would be no unallocated IPv4 prefixes. This motivated the search for solutions limiting the number of allocate IPv4 addresses. One such solution has been widely adopted and it is sometimes credited for the fact that the depletion of the IPv4 address space has been slower than expected. 11 The idea behind this solution is fairly simple: as quite a few networks, mostly with client computers, are connected to the Internet through a single router it is possible to hide the whole network behind that router using a single (public) IP address. This is called Network Address Translation (NAT). Figure 3.9 shows a NAT example: the computers connected to the network on the left of the device X are part of the private network. This network is connected to the Interned only through this device, which is charge of the address translation. Three prefixes have been reserved for private networks (RFC 1918 [32]): /8 (formerly a single class A prefix), /12 (formerly 16 contiguous class B prefixes), 10 Note that we are taking into account the fact that the first and last IP address in a prefix cannot be used, hence the maximum number of computers on a network with a prefix length k is 2 n k 2, where n is the address length. 11 As of the end of 2012, there are still some unallocated IPv4 prefixes but these are allocated with increasingly stricter rules, see, for example, the RIPE website internet-coordination/ipv4-exhaustion. 50

51 /16 (formerly 256 contiguous class C prefixes). These prefixes cannot be used on the public Internet. The private network in the figure uses the prefix. It is obviously possible to use sub-prefixes of these reserved prefixes, the choice is up to the network administrator. As the network in the figure is small, a prefix of length 24 is more than enough. As mentioned above, one of the ideas behind NAT is that most (often all) the computers in the private networks are client computers, as such they will only contact other computers and they will not be contacted. In other words all the connections are outgoing: even in the case of UDP exchanges, the first packet is sent from one computer in the private network to a computer on the Internet and not the other way around. Recall that one of the definitions of client is that a client uses the services offered by a server computer. This is usually accomplished by the client sending a request to the server or by opening a connection with the server. The crucial point is that a server computer must be able to accept incoming requests and/or connections. This important fact is exploited by the NAT. Outgoing packets are straightforward to process: it is enough to overwrite the private IP address (used as the source address) with the public IP address. Incoming packets present one extra challenge: the NAT must decide which machine in the private network is the intended destination. As private IP addresses cannot be used in the Internet, all incoming packets have the public IP address of the NAT as their destination address. The NAT must then decide to which internal machine forward each incoming packet To solve this problem, the NAT takes advantages of the fact that there will always be an outgoing packet first, as long as all the machines on the private network are clients. When the NAT forwards the first outgoing packet of a new exchange (TCP or UDP) it writes in a table the private source address and the source port. It then selects a new (and unique) source port number (called public local port in the following) and writes this value in the table as well. It then overwrites the source port and the source IP address with the public local port and its public IP address. When the NAT forwards other outgoing packets belonging to the same connection it uses the table to determine the value of the public local port and it overwrites the source port and IP source address. Note that the NAT can also decide whether an outgoing packet is the first one of a connection: if there is no line in the table with the same private local port ad private source IP address the packet belongs to a new connection. Otherwise if there is already a line in the table with the same values for the the local source port and source IP address, the packet belongs to an existing connection and the table contains the value of the public local port. As the NAT overwrites port numbers and not only address, a more appropriate term is Network Address and Port Translation (NAPT), but this term is rarely used. Whenever the NAT receives an incoming packet it extracts the source IP address and destination port. It then looks in the table for the line withe the same public local port and overwrites the destination IP address and destination port with the private IP address and private local port in the table. It is important to remark that the NAT must also recompute, and overwrite, the checksum fields of the IP and TCP (or UDP) headers 51

52 Local IP address Local private port Local public port Table 3.2: The Type and Code values for some of the ICMP messages for all the packets it modifies, given that these checksum cover the IP addresses (source and destination) and ports (source and destination). Note that the NAT must chose a unique value for the public port, that is each connection listed in the table must have a different public port. Otherwise it would not be possible to decide the internal destination of incoming packets. To be precise, it is enough for the three-tuple (public local port, public IP address, remote port) to be unique, but in this case the NAT should also store the remote port number and the remote IP address. Another option is to guarantee the uniqueness of the pair (public local port, remote IP address), in this case it would enough for the NAT to store the remote IP address. Consider the example in Figure 3.9, suppose that A wants to open a TCP connection with S 1, for example because S 1 is a web-server. In this case A sends a TCP SYN packet with source address and destination address , source port 8932 and destination port 80. Recall that the source port is chosen, among the ephemeral ports, by the operating system (see Section 1.3.2). The NAT looks in its table to see if there is already a line with address and private local port As this is the first packet of a connection, such a line does not exist and the NAT adds a new line with this information. It also selects a new public port, say Before transmitting the packet, the NAT overwrites the source IP address ( ) with its public IP address ( ) and the source port with the local public port (9758). Assuming that everything is working correctly, the packet reaches S 1, which it is going to reply, sending a packet with source address , destination address , source port 80 and destination port This packet is routed to the public interface of the NAT, which looks in the table for the line with public local port Such a line does exist and it contains the local IP address ( ) and the private local port (8932). Therefore the NAT forwards the packet on the private network, overwriting the destination IP address with and the destination port with Using this mechanism, it is possible for two computers on the private network to establish a communication with the same destination port on a remote computer. For example, B can open as well a TCP connection with the port 80 of S 1. In this case it will send a TCP SYN packet with IP source address , destination address , source port 4586 and destination port 80. The NAT realizes that this is the first packet of a new connection and selects a new (unique) public local port, for example 6857, and it modifies the packet accordingly. This packet is routed to S 2, which replies with a packet with source address , destination address , source port 80 and destination port When the NAT receives this packet, it checks in its table 52

53 and it finds that the local public port correspond to the local private port 4586 on the node. It overwrites the destination address (with ) and the destination port (with 4586) and it forwards the packet to the destination. Table 3.2, shows the content of the NAT table for these two connections as well as a third one, for example between A and S 2. The mechanism described so far works only for outgoing connections. In the case of incoming connections, the NAT cannot use its table to decide to which of the internal computer it should forward the packet. Most NAT implementations do allow the administrator to specify to which internal computer the NAT should forward incoming packets addressed to a certain port. This solution allows having server computers on the private network. But there can be only one server for a given port. As NAT is usually deployed in networks where there are no servers, this is not a problem. A more serious problem with NAT is that it cannot easily cope with application layer protocols that use IP address (and/or port numbers) in their messages. As TCP/IP uses an imperfect layering, TCP (and UDP) communication end-points use IP addresses. Several application layer protocol use IP addresses in their messages as well: notable examples are the File Transfer Protocol (FTP RFC 959 [28])and the Session Initiation Protocol (SIP RFC 3261 [36]). NAT boxes can handle these protocols correctly if they inspect the payload of each packet to determine the application layer protocol and whether it contains IP addresses or port numbers that need to be modified. While this solution is viable, it does increase significantly the complexity of the NAT implementation. Furthermore the deployment of new application layer protocols requires modifying existing NAT implementation whenever such protocols use IP addresses and port numbers. This is not the case for normal IP routers, which do not need to be modified when new application layer protocols are introduced, even if they use IP addresses and port numbers in their messages. Another difference between routers and NAT boxes it that routers do not keep any state information, they simply route each packet independently of all the others. NAT boxes, on the contrary, must keep track of all the ongoing connections. If a router brakes down, other routers will detect the failure and, provided alternate paths exist, traffic will flow again as soon as the routing protocol has converged. If, instead, a NAT box brakes down, all the connections must be restarted. These shortcoming notwithstanding, NAT is a widely used solution, especially in home-networks. Typically a single box implements all the functions of an ADSL (or cable) modem, a NAT/router, a DHCP server and an Ethernet switch. 53

54 Bibliography [1] J. Abley and K. Lindqvist. Operation of Anycast Services. RFC 4786 (Best Current Practice). Dec [2] F. Baker. Requirements for IP Version 4 Routers. RFC 1812 (Proposed Standard). June [3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext Transfer Protocol HTTP/1.0. RFC 1945 (Informational). May [4] Olivier Bonaventure. Computer Networking: Principles, Protocols and Practice. Available at [5] R. Braden. Requirements for Internet Hosts - Communication Layers. RFC 1122 (Standard). Oct [6] S. Cheshire. IPv4 Address Conflict Detection. RFC 5227 (Proposed Standard). July [7] M. Cotton et al. Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry. RFC 6335 (Best Current Practice). Aug [8] W.J. Croft and J. Gilmore. Bootstrap Protocol. RFC 951 (Draft Standard). Sept [9] R. Droms. Dynamic Host Configuration Protocol. RFC 1531 (Proposed Standard). Oct [10] R. Droms. Dynamic Host Configuration Protocol. RFC 2131 (Draft Standard). Mar [11] R. Fielding et al. Hypertext Transfer Protocol HTTP/1.1. RFC 2616 (Draft Standard). June [12] V. Fuller et al. Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. RFC 1519 (Proposed Standard). Sept [13] Wolfgang John, Maurizio Dusi, and K. C. Claffy. Estimating routing symmetry on single links by passive flow measurements. In: Proceedings of the 6th International Wireless Communications and Mobile Computing Conference. IWCMC 10. ACM, 2010, pp [14] Wolfgang John and Sven Tafvelin. Analysis of internet backbone traffic and header anomalies observed. In: Proceedings of the 7th ACM SIGCOMM conference on Internet measurement. IMC 07. ACM, 2007, pp

55 [15] J. Klensin. Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. RFC 5890 (Proposed Standard). Aug [16] James F. Kurose and Keith W. Ross. Computer Networking: A Top-Down Approach. 5th. Addison-Wesley Publishing Company, [17] K. McCloghrie, R. Fox, and E. Decker. IEEE Token Ring MIB. RFC 1231 (Proposed Standard). May [18] S. McCreary and k. claffy. Trends in wide area IP traffic patterns - A view from Ames Internet Exchange. In: ITC Specialist Seminar [19] P.V. Mockapetris. Domain names - concepts and facilities. RFC 1034 (Standard). Nov [20] P.V. Mockapetris. Domain names - implementation and specification. RFC 1035 (Standard). Nov [21] J.C. Mogul. Broadcasting Internet datagrams in the presence of subnets. RFC 922 (Standard). Oct [22] J.C. Mogul and J. Postel. Internet Standard Subnetting Procedure. RFC 950 (Standard). Aug [23] T. Narten et al. Neighbor Discovery for IP version 6 (IPv6). RFC 4861 (Draft Standard). Sept [24] K. Nichols et al. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474 (Proposed Standard). Dec [25] D. Plummer. Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. RFC 826 (Standard). Nov [26] J. Postel. Assigned numbers. RFC 790 (Historic). Sept [27] J. Postel. Internet Protocol. RFC 791 (Standard). Sept [28] J. Postel and J. Reynolds. File Transfer Protocol. RFC 959 (Standard). Oct [29] K. Ramakrishnan and S. Floyd. A Proposal to add Explicit Congestion Notification (ECN) to IP. RFC 2481 (Experimental). Jan [30] K. Ramakrishnan, S. Floyd, and D. Black. The Addition of Explicit Congestion Notification (ECN) to IP. RFC 3168 (Proposed Standard). Sept [31] Y. Rekhter and T. Li. An Architecture for IP Address Allocation with CIDR. RFC 1518 (Historic). Sept [32] Y. Rekhter et al. Address Allocation for Private Internets. RFC 1918 (Best Current Practice). Feb [33] A. Retana et al. Using 31-Bit Prefixes on IPv4 Point-to-Point Links. RFC 3021 (Proposed Standard). Dec [34] J. Reynolds. Assigned Numbers: RFC 1700 is Replaced by an On-line Database. RFC 3232 (Informational). Jan

56 [35] J.K. Reynolds and J. Postel. Assigned numbers. RFC 1060 (Historic). Mar [36] J. Rosenberg et al. SIP: Session Initiation Protocol. RFC 3261 (Proposed Standard). June [37] Abraham Silberschatz, Peter Baer Galvin, and Greg Gagne. Operating System Concepts. 8th. Wiley Publishing, [38] Andrew Tanenbaum. Computer Networks. 4th. Prentice Hall Professional Technical Reference, [39] Andrew S. Tanenbaum. Modern Operating Systems. 3rd. Prentice Hall Press, [40] Laurent Toutain. Réseaux locaux et Internet. 3ème édition. Hermès,

57 Introduction to IP Networks RES 302 RES 302 Alberto Blanc, Jean-Pierre Le Narzul, Nicolas Montavont RSM Department Fall 2012 Course Presentation Main goal: an introduction to IP networks top-down approach (starting from the Application layer) lectures will concentrate mainly on the Application, Transport and Network layers you will have to design and implement a simple session protocol New format this year: one fewer module (this year: 301, 302, 303; until last year: 301, 302, 303, 304) the new 302 vaguely corresponds to the old 302 and 303 a large part of the course dedicated to the project show the importance of standards (interoperability) changes motivated (among other factors) by the comments of the students 2 RES 302

58 Course Overview overview of the TCP/IP protocol suite socket programming (Python) the IP protocol addressing routing Network Address Translation Application Layer Protocols (SIP) 3 RES 302 The project (I) Context: Chat While You Watch application chat with other users watching the same video (movie) streaming video server users choose a video to watch one chatroom for each video (users join the chatroom automatically) client and server need to use a session protocol: basically a signaling protocol (join, leave, get movie list, join movie, etc.) you will have to specify and implement your own we have already developed the application you have to implement only the protocol-specific parts 4 RES 302

59 The project (II) Goal: write the protocol specification and implement it hands-on approach similar to what is done at the Internet Engineering Task Force groups of 4 people up to the students to form the groups (do it as soon as possible) If you have not found a group by Sep 10 write to alberto.blanc@telecom-bretagne.eu so that we can put in touch with each other those without a group groups must be formed by Sep 12 (send an to alberto.blanc@telecom-bretagne.eu with the names) 5 RES 302 Project Goals and Motivations Goals: design and implement a simple communication protocol understand the role (and importance) of standards introduction to network programming Motivations: networks exist to connect end-nodes (which are more numerous than intermediate systems) end-nodes are extremely important more and more communicating devices (objects) understanding their interactions with the network is useful layered model same principles apply to lower level protocols (each protocol uses the services offered by the lower layers) network programming is far from simple it can be a useful and profitable skill 6 RES 302

60 Course Calendar Sep 7 morning C-1 C-2 Introduction & Python programming Sep 7 afternoon TP-1 Python socket programming Sep 10 morning C-3 C-4 IP protocol Sep 10 afternoon TP-2 Twisted framework programming Sep 12 afternoon PC-1 PC-2 IP addressing PC and protocol specification Sep 17 afternoon PC-3 PC-4 IP addressing PC and protocol specification September 21 afternoon PC-5 PC-6 specification presentation, discussion and selection Oct 1 afternoon TP-3 implementation (1/3) Oct 8 afternoon TP-4 implementation (2/3) Oct 15 morning C-5 C-6 TCP, Routing Oct 15 afternoon TP-5 implementation (3/3) Oct 19 morning C-7 C-8 application-layer protocols Oct 19 afternoon PC-7 PC-8 application-layer protocols Oct 26 afternoon PC-9 PC-10 packet analysis Nov 5 afternoon TP-6 project evaluation 7 RES 302 CWW 8 RES 302