Networking 101 Alan Hicks 2007.07.31 TOC ========== 0. License 1. About this "Class" 1.1 Terms 1.2 Binary Arithmetic 2. Five Layers at a Glance 2.1 Physical Layer 2.2 Data-Link Layer 2.3 Network Layer 2.4 Transport Layer 2.5 Application Layer 3. Physical Layer 3.1 802.3 Cabling 3.2 Voltage Transmission 3.3 Repeaters 3.4 Hubs 4. Data-Link Layer 4.1 MAC Addressing 4.2 Bridges 4.3 Switches 5. Network Layer 5.1 IP Addressing 5.2 Subnetting 5.3 Route Determination 5.4 ICMP 5.5 ARP 6. Transport Layer 6.1 TCP 6.1.1 Ports 6.1.2 Flags 6.1.3 Connection Initialization 6.1.4 Connection Termination 6.2 UDP 6.2.1 Ports 7. Application Layer 7.1 DNS 7.2 DHCP 8. Packet Crafting 8.1 Application Data 8.2 Transport Wrap 8.3 Network Wrap 8.4 Data-Link Wrap 8.5 All Together Now 9. A Day in the TTL of a Packet 9.1 Traversing the Subnet for Fun and Profit 9.2 TCP - SYN to FIN 0. License ========== Copyright (c) 2007, Alan Hicks, Lizella GA Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections. http://www.gnu.org/licenses/fdl.txt 1. About this "Class" ===================== This "Class" started out in April of 2007 when I noticed that quite a lot of people in the Slackware community didn't know much at all about TCP/IP. This shocked me quite a bit, as everyone used the Internet heavily, but not everyone knew much about the underlying protocols that they used everyday. Many of these people were guys that I respected for knowing lots of things that I have never had the time or inclination to learn. So I held an impromptu "class" in the #slackware channel of irc.oftc.net to explain some of this. Many people thanked me for it, and it was logged and saved by several who then referred it to others. However, I was never terribly satisfied with it, as I felt the order was somewhat jumbled up as I spoke on topics as they came up, rather than building upon earlier, simpler facts. Just the same, you'll probably have to read through this twice to make sense of anything. In some respects, networking is a closed loop. You can't grasp the whole picture of early concepts without understanding how they apply to later topics. Here, I try to setup the most basic foundation in hopes that you'll understand everything I intend to get across. 1.1 Terms ========= In this "class" you'll see quite a few terms that may not be in your vocabulary. I'll try to define a few of them up front. node (n.) - Any single device on a network. A node can be a computer, a network-enabled printer, a router, a managed switch, or something else. bit bucket (n.) - That place where discarded bits are thrown. copper (n.) - For purposes of this document, we are only talking about Cat-5 and similar networking cables that send a signal down pairs of copper wires. Many other methods of transmitting data are possible, including fiber-opics, radio waves, even pidgeons (for very low bandwidth purposes only of course)! Cat-5 and it's derivatives are the most common physical media for transmitting data however, so canonically, copper means Cat-5 and similar cables. TTL (n.) - Time to Live. In networking, this often isn't in seconds, but rather in nodes to traverse before dying. LAN (n.) - Local Area Network. If you don't know what this is already, then this class may be a bit above your head. You need to go back and take remedial courses. canonnical (adj.) - The usual way. 1.2 Binary Arithmetic ===================== So you can count to five on your fingers? Good for you. I can count to 31 on just one hand. The secret is binary math. As you probably already know, computers deal exclusively with 1s and 0s. There is no number "2" in a computer, nor a number "3". Every number, every letter, every pixel, every process is expressed as a string of seemingly random 1s and 0s. How we determine what a particular string of 1s and 0s means is what this section is all about. Back to my example of counting to 31 on one hand. To achieve this incredibly stupid and mundane feat, I need only look at my fingers as bits in a computer. If the finger is down, that finger is a "0". If it is up, that finger is a "1". Decimal Binary 0 00000 1 00001 2 00010 3 00011 4 00100 5 00101 6 00110 7 00111 8 01000 9 01001 10 01010 11 01011 12 01100 13 01101 14 01110 15 01111 16 10000 .. ..... 31 11111 Those of you who are particularly smart are thinking "Hmmm.... binary means two, right? What are the powers of 2?" Power Decimal Binary 0 1 00000001 1 2 00000010 2 4 00000100 3 8 00001000 4 16 00010000 5 32 00100000 6 64 01000000 7 128 10000000 We could go further out to the nth power, but this is as far as we need to go for most practical purposes. Here you can easily see what I call the "Staircase of Two". Each power of 2 shifts the "1" to the left just a single bit. Compare the above "base 2" table to the more familiar "base 10" table. Power Decimal Base Ten 0 1 00000001 1 10 00000010 2 100 00000100 .. ... ........ 7 10000000 10000000 Here you can easily see the "ones place", the "tens place", the "hundreds place" and so on. In binary, we have the same thing, except that we have a "ones place", a "twos place", a "fours place", an "eights place" and so on. Looking back at the binary table, you can see that by adding these together, we can quickly create any number we choose. Let's assume we want to find the binary value of 47. To do this easily, we simply find the largest power of two that's smaller than 47, and put a "1" in that power's place. Then we subtract that value, and continue on down the line. So what's the largest power of 2 that's not larger than 47? 32 is smaller, and 64 and above are too big, so we know that the first "1" in our binary number will be in the sixth spot from the right (never forget that the first place is the power of zero. Computers start counting at zero, and you should too). 47 - 32 = 15 Our binary number looks something like this now. 001????? What's the largest power of 2 that's not larger than 15? Well, the next "place" in binary is 16, but that's too large, so we'll put a "0" there. 0010???? 8 works! So there will be a "1" in the fourth place from the right. 15 - 8 = 7 00101??? 7 - 4 = 3 001011?? 3 - 2 = 1 0010111? 1 - 1 = 0 00101111 Decimal 47 is Binary 00101111. That wasn't so bad was it? Working in reverse is even easier. What's the value of 11011001? To figure this out, we simply find the decimal value for each "1" and ignore the values for each "0". 11011001 = 128 + 64 + 16 + 8 + 1 = 201 An alternative way to look at this is to say that "11011001" has 1 128, 1 64, 0 32s, and so on. 1101001 = (1 * 128) + (1 * 64) + (0 * 32) + (1 * 16) + (1 * 8) + (0 * 4) + (0 * 2) + (1 * 1) You can also look at the decimal (base 10) number the very same way. 201 = (2 * 100) + (0 * 10) + (1 * 1) Now that you know binary, not only can you count to 31 on one hand, but you can also understand concepts like IP addressing and subnetting. 2. Five Layers at a Glance ========================== The TCP/IP suite makes use of five different layers to get its job done. You can think of the layers in much the same way that you think of a stack of blocks. At the bottom is the physical layer, and at the top is the application layer. Things start at the top and slowly work their way down the layers to create a network frame. Each of these layers will be briefly explained now; we will go into more depth in later sections. 2.1 Physical Layer ================== The lowermost layer in our stack of blocks is the physical layer. This layer consists of basically any physical part of your network. "Physical" is a bit of a misnomer though, as it includes non-physical transmission media such as light or radio signals. Basically anything that is capable of actually transmitting data is part of the physical layer. This includes network cards, copper wires, fiber-optic cable, radio waves, and even infra-red light. The physical layer turns the digital packet into some form of anaolgue signal that can be transmitted to another node on the network. 2.2 Data-Link Layer =================== The Data-Link Layer is the first layer of the TCP/IP stack that actually crafts part of the packet. This layer is also responsible for determining what machine will receive a packet on any given network-layer subnet. 2.3 Network Layer ================= The Network Layer is responsible for addressing hosts that may or may not be on your particular LAN. It is the only protocol that understands routing and can address packets to machines not on your LAN. 2.4 Transport Layer =================== The Transport Layer is responsible for communicating between the Network layer and the Application layer. It is responsible for determining what application a givin packet will reach. It is also the only layer that can garauntee data transmission. 2.5 Application Layer ===================== The Application Layer is responsible for formatting the data that will be transmitted to a remote host. It includes most of the higher order protocols you may be familiar with such as DHCP, DNS, and HTTP. 3. Physical Layer ================= As we discussed, the physical layer is responsible for transforming digital signals. How this happens depends on the transmission media of course. Fiber-optic cables send light signals of course. Copper wires transmit data in voltage fluctuations. Radio communications send the signal along a certain radio frequency. We'll only discuss the most common (copper) below. 3.1 802.3 Cabling ================= 802.3 is the IEEE spec that defines ethernet. The most common transmission media for Internet traffic is copper cable. Ethernet has reached speeds of 10, 100, 1000, and even 10000 megabits per second (Mbps). Cabling has changed over time from incredibly thick coax cable to thin twisted pair copper which is prevalent today. A typical cable consists for four pairs of copper with each pair twisted about itself. This twists generates a small electromagnetic shield around the cable that helps prevent interference and increases the amount of data that can be sent through the wire in a given period of time. A typical Cat5e cable is terminated in an RJ-45 connecter that looks like an oversized phone jack. Inside the cable you will find 4 different colored pairs of wire. In 10/100 Mbps ethernet, only pairs 1 and 2 transmit data. Pairs 3 and 4 are left vacant, but can be used to power a remote node using Power of Etherner (PoE). Pair 1: Orange / Orange-white Pair 2: Green / Green-white Pair 3: Blue / Blue-white Pair 4: Brown / Brown-white Unfortuantely, how these pairs are wired is a little counter-intuitive, and depends on whether you are using an intermediate hub or switch, or if you are connecting two Network Interface Cards (NICs) directly. The typical way of terminating these cables is known as 568B. A 568B termination looks a bit like this. RJ-45 Terminator =========================== || Orange-white --------|| || Orange --------|| =============|| Green-white --------|| Cat5e Cable || Blue --------|| =============|| Blue-white --------|| || Green --------|| || Brown-white --------|| || Brown --------|| =========================== If both ends of the cable are terminated in this fasion, then the cable is called a patch cable. However, if only one end is terminated in the following fasion, then the cable is known as a crossover cable and can connect two computers without an intervening switch or hub. RJ-45 Terminator =========================== || Green-white --------|| || Green --------|| =============|| Orange-white --------|| Cat5e Cable || Brown --------|| =============|| Brown-white --------|| || Orange --------|| || Blue-white --------|| || Blue --------|| =========================== Those of you who are ahead of the class are wondering why this isn't necessary if the cable is to be plugged into a hub or switch. The reason is that certain pairs of wire are for sending data and others are for receiving data. A hub or switch has these reversed. Here's a standard cable for a 10/100Mb ethernet connection with the pairs marked according to whether they are to transmit or receive data. NIC Hub or Switch =================== ================= || Output -----|| 1 1 ||---- Input || || Output -----|| 2 2 ||---- Input || || Input -----|| 3 3 ||---- Output || || Unused -----|| 4 4 ||---- Unused || || Unusued -----|| 5 5 ||---- Unused || || Input -----|| 6 6 ||---- Output || || Unused -----|| 7 7 ||---- Unused || || Unused -----|| 8 8 ||---- Unused || =================== ================= Here, you would want to use a patch cable, as the NIC's Output lines up with the hub's input and vice-versa. A crossover cable simply handles this for you if the two interface ports have the same pin setup. Consider this example: NIC 1 NIC 2 =================== ================= || Output -----|| 1 1 ||---- Output || || Output -----|| 2 2 ||---- Output || || Input -----|| 3 3 ||---- Ipnut || || Unused -----|| 4 4 ||---- Unused || || Unusued -----|| 5 5 ||---- Unused || || Input -----|| 6 6 ||---- Input || || Unused -----|| 7 7 ||---- Unused || || Unused -----|| 8 8 ||---- Unused || =================== ================= If we were to connect a patch cable between these two NICs, no data could flow through as each NIC would attempt to transmit and receive on the same pairs. But by connecting a cross-over cable: NIC 1 NIC 2 =================== ================= || Output -----|| 1 3 ||---- Output || || Output -----|| 2 6 ||---- Output || || Input -----|| 3 1 ||---- Ipnut || || Unused -----|| 4 4 ||---- Unused || || Unusued -----|| 5 5 ||---- Unused || || Input -----|| 6 2 ||---- Input || || Unused -----|| 7 7 ||---- Unused || || Unused -----|| 8 8 ||---- Unused || =================== ================= ... everything flows smoothly. 3.2 Voltage Transmission ======================== So now that we know what each cable is for, and how to wire up a cable, how does a NIC actually transmit data? To understand this, we have to answer the age old question: "What is digital anyway?" A google search will return all kinds of definitons for "digital", but none of them are very clear unless you already understand "digital". Here is my simpler definition. "Digital" is just a way of interpreting an anaolgue signal. Your copper cable always carries a voltage, and as this voltage changes, the remote NIC interprets this change as either a 1 or a 0. Let's assuming your NIC is capable of procucing voltages between 1 and 5 volts and that above 3 Volts is considered a "1" and below 3 Volts is considered a "0". Voltage always changes on a curve that resembled a sine wave (yes, you should have paid attention in your high school Trig class). Another one of my insanely ugly ASCII-art graphs follows 5 | . . . 4.5 | . . . . V 4 | . . . . o 3.5 | . . . . l 3 | =========================================================== t 2.5 | . . . s 2 | . . . 1.5 | . . . 1 | . . . ------------------------------------------------------------- | 0 | | 1 | | 1 | | 0 | This should clearly show how changing voltage, even though the change is analogue, can be interpreted as ones and zeros digitally. 3.3 Repeaters ============= A repeater is really a simple device that takes a signal in and amplifies it. Repeaters are necessary to send data along particularly long cables because the signal tends to degrade at distances longer than 100 meters. So if you wanted to ensure the integrity of a transmission between two nodes that were 200 meters apart, you would use two 100 meter long cables and connect them to a repeater in the middle. Simple, yes? 3.4 Hubs ======== Hubs are devices with lots and lots of ethernet ports and basically "split" a cable so that a single packet reaches multiple nodes. A hub's singular function is to accept signals on any of its interfaces, and propogate those signals down all of its other ports. Basically, a hub is nothing more than a multi-port repeater. Use of a hub allows one node to contact multiple other nodes. Today, however, hubs have fallen out of favor due to the prevalence of switches (we will discuss switches below) for a variety of reasons. The main problem with a hub, is that only one node may send data at a time, and each node is reponsible for collision detection. Collisions occur when more than 1 node attempts to send data at a time. Most hubs are capable of disconnecting a node that is producing more than its fair share of collisions, preventing a single mis-behaving machine from bringing down the entire network, but this is still far from an ideal solution. Hubs are considered "dumb" devices, because they replicate data unneccessarily. Only the single machine that a packet is destined for needs to receive the packet, but a hub has no way of knowing what that machine is, or even where it is located. Thus, a hub just "spams" each signal it receives to every machine it can reach. I am reminded of a joke told by the famous country comedian and Grand Ole Opry star Minnie Pearl that is perhaps the best analogy to the way a hub works that I can think of. "I was going down to the store here in Nashville the other day and this city slicker laughed as I walked by. He turned around to his friend and says 'She don't look very country to me.' His friend he laughed and said 'Yeah, I bet she couldn't tell a goose from a gander.' I tried to ignore them, but I just couldn't help myself so I walked over and promptly told them 'Well now in Grinder's Switch we don't worry about that, we just put 'em all in a pen together and let 'em figure it out for themselves." This is precisely how a hub works. A gander (male goose) wants to talk to the female of the species, so he goes over to Minnie Pearl and honks at her. She doesn't know who he wants to speak with and really doesn't care, so she tosses him in a pen with all the other geese. Every single goose (whether a goose or a gander) gets to hear our gander honk, and every other one ignores our gander unless it happens to be the goose our gander wants to talk to. Looking back on it, maybe that isn't the best analogy of a hub? :^) 4. Data-Link Layer ================== This is the layer where things actually get interesting. The Data-Link Layer is responsible for sending packets "somewhere", even if "somewhere" isn't their final destination. 4.1 MAC Addressing ================== Every NIC, every switch, every modem, every device that connects to a network has a Media Access Control (MAC) Address that is set by the device's manufacturer and is generally unchangeable. This address uniquely identifies a single device on a network segment, allowing us to address data for that particular device. In an ethernet frame, we include two of these, a destination MAC address, and the source MAC address. When you send a packet, the packet is tagged with your MAC address as the "source MAC", and you will set the "destination MAC" to the address of the node you wish to reach, or to your router's MAC address if the final node isn't on your subnet. This will all make more sense when we look at the Network Layer. 4.2 Bridges =========== Bridges were designed as a way of limiting collisions on a network using hubs to connect many different machines by "partitioning" the network. A bridge is basically a dedicated computer with more than one NIC that sits between two or more hubs. A bridge works like a hub, but with one exception. A bridge has "brains" and can "remember" what machines are on either "side" of it. When it receives a packet, it consults its memory to see if the destination MAC is on the same interface that the source MAC was on. If so, it discards the packet. However, if they are on different interfaces, it propogates the packet only along the proper interface. A couple of diagrams may help explain. ======================= ======================= | Hub A |--------------------| Hub B | ======================= ======================= | | | | | | | | ========== ========== ========== ========== | Node 1 | | Node 2 | | Node 3 | | Node 4 | ========== ========== ========== ========== In this example, if Node 1 sends a packet to Node 2, the packet traverses both hubs, so nodes 2, 3, and 4 will all see the packet. Only node 2 will act on it, and the others will ignore it. Obviously, this is less efficient since every single node has to do collision detection for three other nodes. ======================= ========== ======================= | Hub A |-----| Bridge |-----| Hub B | ======================= ========== ======================= | | | | | | | | ========== ========== ========== ========== | Node 1 | | Node 2 | | Node 3 | | Node 4 | ========== ========== ========== ========== In this example network, if Node 1 sends a packet to Node 2, both Node 2 and the bridge see the packet. Node 2 accepts the packet, and the bridge silently drops the packet to the bit bucket. Now suppose Node 1 sends a packet to Node 3. Node 2 and the bridge will see the packet. Node 2 will drop the packet in its bit bucket, but the bridge will send the packet over to Hub B where both Node 3 and Node 4 will see it. Node 3 will act on the packet and Node 4 will ignore it. This is much more efficient as each node only has to do collision detection for two other devices (the other node on its hub, and the bridge). You can see how this improves things if you have dozens or hundreds of nodes on a hub network. Today however, bridges have lost their role as performance enhancers due to the prevalence of switches, and you'll soon find out exactly why. Bridges are primarily used today as specialized devices such as transparent firewalls or data filters, but that is a discussion for a future class. 4.3 Switches ============ At first glance, switches are indistinquishable from hubs. They look identical, but the magic is all on the inside. Whereas hubs operate entirely on the physical layer, a switch steps up to the data-link layer and functions more like a bridge than a hub. If you recall from the earlier example, every node on a hub has to do collision detection and prevention with every other node on the hub and any other hubs that are directly attached to it. If a node is attached to a switch on the other hand, it only has to avoid collisions with the switch itself. How is this possible? Well, that's where the magic comes in. Imagine if you will, that every single port on a hub was a bridge. This bridge would only send any given packet directly to the single machine the packet is destined to. This is exactly how a switch operates. By "memorizing" the MAC addresses of all devices attached to it, a switch is capable of looking at a packet's destination, and sending the packet out only the single port that the destination node is attached to. This means that on a switch, a machine will only see packets that are intended for it. Not only does this prevent collisions, but it also increases overall throughput as multiple machines may send packets at the same time. Another ugly diagram. ================================================================= | Switch A | ================================================================= | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | ===== ===== ===== ===== ===== ===== | | | | | | | | | | | | ========== ========== ========== ========== ========== ========== | Node A | | Node B | | Node C | | Node D | | Node E | | Node F | ========== ========== ========== ========== ========== ========== This is a typical 6-port switch with 6 nodes attached to it. Say that Node A wants to send a packet to Node B. The switch receives the packet on port 1, looks at its ARP table, and determines that the packet is destined for Node B, which it knows is on port 2. The packet is sent out port 2, and only out port 2. Nodes C, D, E, and F never see the packet and in fact, will never even know it existed. Moreover, Node C can send Node D a packet at the same time without fear of collision, since the packets don't travel on the same physical link. It's important to remember that switches are *not* security devices, but rather performance devices. It is possible to flood a switch's ARP table and make it either crash, or convert to working as a hub depending on the make and model. You should never rely on a switch as a way of preventing disclosure of information. 5. Network Layer ================ This is without a doubt the funnest, and most difficult layer to truely learn. Without this layer, no machine could address any other machine without knowing its MAC address, and those machines would have to be on connected hubs, bridges, and switches. The Network Layer is responsible for determining the final destination of a packet and determining just how to get there from here. 5.1 IP Addressing ================= Alright, so you all know what an IP address is don't you? Everyone has one these days. In fact, some of us have lots of them. They're those funny little numbers like 207.69.188.185. What do they mean? Why can't I just use whatever numbers I want there? And why do they only go up to 255? Simply put, an IP address is a 32-bit binary number. It's a string of 1s and 0s 32 digits long. For various reasons, we split that 32-bit number up into 4 8-bit numbers. Let me use a common example. 192.168.1.100 is a common IP address on many private networks as it's one of the most easily remembered default IP addresses for a private LAN. (We'll discuss private IP ranges later. For now, play along.) What does the computer see when we send a packet to this address? To answer that question we need to know something about binary arithmetic. If you boldy skipped section 1.2, shame on you! Go back and read it now before proceeding further, as I won't explain it again. 192.168.001.100 = 11000000.10101000.00000001.01100110 In reality, the dots don't exist. They are only there to help us work with four 8-bit numbers instead of 1 big 32-bit number. In reality, the computer just sees "11000000101010000000000101100110". So now you know what an IP address is. Just like with the MAC address, every packet has a Destination IP Address and a Source IP Address. 5.2 Subnetting ============== Subnetting today is properly called "Classless Inter-Domain Routing" and is formally described in the RFCs 1518 and 1519. Subnetting is a way of determined what IP addresses are on our network. Basically, it tells us what nodes we can talk to directly without communicating through a router of some sort. You've probably seen subnets like 255.255.255.0 or heard of them talked about as 192.168.1.0/24, but what do those numbers mean? A subnet mask (or just a net mask for short) is a bit mask that basically tells the computer not to look at certain numbers. To understand this, we have to look at those numbers in binary. 255.255.255.0 = 11111111.11111111.11111111.00000000 192.168.1.100 = 11000000.10101000.00000001.01100110 In this example, a node (be that a computer, a managed switch, a router, or something else) can look at these two numbers and self to itself "looks like all numbers that begin 192.168.1 are on the same subnet". Another way of looking writing this is 192.168.1.100/24. The /n tells us how many bits is in the bitmask. In this case, 24. /24 = 11111111.11111111.11111111.00000000 192.168.1.100 = 11000000.10101000.00000001.01100110 A helpful little table here should help you understand the basics. Subnet Bitmask Value =============== ======= =================================== 255.255.255.255 /32 11111111.11111111.11111111.11111111 255.255.255.254 /31 11111111.11111111.11111111.11111110 255.255.255.252 /30 11111111.11111111.11111111.11111100 255.255.255.248 /29 11111111.11111111.11111111.11111000 255.255.255.240 /28 11111111.11111111.11111111.11110000 255.255.255.224 /27 11111111.11111111.11111111.11100000 255.255.255.192 /26 11111111.11111111.11111111.11000000 255.255.255.128 /25 11111111.11111111.11111111.10000000 255.255.255.0 /24 11111111.11111111.11111111.00000000 255.255.0.0 /16 11111111.11111111.00000000.00000000 255.0.0.0 /8 11111111.00000000.00000000.00000000 0.0.0.0 /0 00000000.00000000.00000000.00000000 This is a table of the most common subnets you will run across from the smallest (/32, a single node) to the widest (/0, everything). The number of address on a given subnet is easily found using the following formula. max_addr = 2^(32 - bit_mask) So, if your bitmask is /32... max_addr = 2^(32 - 32) = 2^0 = 1 If it's /24... max_addr = 2$(32 - 24) = 2^8 = 256 But what IP addresses are included in one of those subnets? It's easy to figure out that 192.168.1.0/24 means all addresses from 192.168.1.0 to 192.168.1.255, but what about some obscure ones like 172.16.25.208/29? To determine this, we'll have to simply count up from 0. A /29 subnet has 8 IP Addresses, meaning that there is exactly 32 /29 subnets inside a /24 subnet. Let me make another table. Subnet Min IP Max IP ====== ====== ====== 172.16.25.0/29 172.16.25.0 172.16.25.7 172.16.25.8/29 172.16.25.8 172.16.25.15 172.16.25.16/29 172.16.25.16 172.16.25.23 ..... 172.16.25.208/29 172.16.25.208 172.16.25.215 ..... An alternative way of looking at this is to split the subnets one at a time. Here we start with a known /24 and break it down into two /25s. Whichever /25 contains our IP address will be broken down into two /26s and so on until we reach the final /29. Subnet Min IP Max IP ====== ====== ====== 172.16.25.0/24 172.16.25.0 172.16.25.255 ... 172.16.25.0/25 172.16.25.0 172.16.25.127 172.16.25.128/25 172.16.25.128 172.16.25.255 ... 172.16.25.128/26 172.16.25.128 172.16.25.191 172.16.25.192/26 172.16.25.192 172.16.25.255 ... 172.16.25.192/27 172.16.25.192 172.16.25.223 172.16.25.224/27 172.16.25.224 172.16.25.255 ... 172.16.25.192/28 172.16.25.192 172.16.25.207 172.16.25.208/28 172.16.25.208 172.16.25.223 ... 172.16.25.208/29 172.16.25.208 172.16.25.215 ... Simple, right? Well, it used to be even simpler when we only had three netmasks. Years ago, when the Internet was young, there were only three subnets. These were believed to be sufficient at the time, because the Internet was mostly private, very small, and no one dreamed that so many people would be on it today. (Technically, there were others as well, but they were restricted to specialty uses such as multi-cast. We will not discuss them further.) Class Network Addresses ===== ======= ========= A 255.0.0.0 16,777,216 B 255.255.0.0 65,536 C 255.255.255.0 256 If an organization needed 300 IP addresses, they were given 65,536. If they needed 100,000, they were given 16,777,216. Clearly this was very wasteful, and created shortages. To address this, subnetting was invented, allowing organizations such as ISPs to get only as many IPs as they needed (or pretty close to it). If I need 300 IP addresses, I don't need a /16. A /25 includes 512 IP Addresses, and that's more than enough without waisting the other 65,024. Today, you'll still hear this terminology from time to time. People often refer to any /24 subnet as a "Class C" network for example. 5.3 Route Determination ======================= Finally! Things have gotten interesting. At last we have come to that part of networking that allows us to send information in the form of packets to places that we've never seen. Subnetting tells us what IP Addresses we should be able to communicate with without going through a router, but what about other IP Addresses? Every computer has a routing table, though it looks different depending on your operating system. Here's what my routing table currently looks like on Slackware Linux 12.0. root@robin:~# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 This should be fairly self-explainitory. When a packet is sent out to an IP Address, the kernel begins checking the Destination IP Address against the "Destination" column of the routing table until it finds a match. The last row "0.0.0.0" is a catch-all. Whenever it finds a match, it acts on it based on the rules in the other columns. Let's try an example. My computer (robin, 192.168.1.73) wishes to send a packet to another (solitude, 192.168.1.197). It forms a packet and sets the Destination IP Address to 192.168.1.197. The kernel checks its routing table and finds a match. Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 The first thing it checks for is the use of a "Gateway" (or router). In this case, Gateway has the value of 0.0.0.0. Next, it looks at "Genmask", which tells the kernel the subnet mask for that "Destination", in this case 255.255.255.0. The next field is "Flags" and has the value "U", telling the kernel that this route is "up". Of the rest of the columns, only "Iface" is of any concern to us right now. (For more information, check the man page for route(8).) This tells the kernel what interface to send the packet out, in this case, eth0. Now, another example. Suppose robin wants to talk to www.google.com which it learns has an IP address of 72.14.207.99. The kernel begins to check the routing table and find no match until it reached the catch-all. Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 In this example, the "Flags" are "UG". According to the man page for route(8), this means that the route is up, and tells the kernel to use the "Gateway" 192.168.1.254. The packet will also leave interface eth0. Simple enough? Let's look at the routing table of the router that robin is using. root@sanctuary:~# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 68.101.44.224 0.0.0.0 255.255.255.224 U 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 68.101.44.225 0.0.0.0 UG 0 0 0 eth1 Note that the first route is a /27 network containing 16 IP addresses. The second is a typical /24 private network. robin, solitude, sanctuary, and a host of other machines are on the 192.168.1.0/24 subnet. Meanwhile, sanctuary's default gateway is located on the 68.101.44.224/27 subnet. That packet robin sends to google will be received by sanctuary on eth0. Since sanctuary doesn't know anything about the 72.14.207.99 IP Address, the packet is caught by sanctuary's catch-all route and sent to its router, 68.101.44.225. That address is in turn matched by the 68.101.44.224 "Destination" and sent of "Iface" eth1. It's important to note that no packet is transmitted to an IP Address. IP Addresses are merely used to determine the route that a packet must take to reach its eventual destination. Packets are instead transmitted to MAC Addresses. This will all make sense later when we put everything together. 5.4 ICMP ======== ICMP is formally described in RFC 792. Internet Control Message Protocol, or ICMP for short, is mostly used to transmit error messages between machines. For example, if a router can't seem to find a node you're attempting to communicate with, you may see an "ICMP Destination Unreachable" error message. ICMP is used to transmit the most basic of information between nodes, and is highly specialized to this task to the point that it cannot carry arbitrary data in the way that TCP or UDP can (more on these later). Each ICMP packet is given a certain "type" that specifies its use. Certain types may have a (sometimes optional) data section that can carry some small amount of arbitrary data. The most common intentional use of ICMP by a user is the ping(8) program. ping generates an ICMP type 8 packet. Type 8 is known as the "Echo Request". When a machine receives such a packet, it replies to it with an ICMP type 0 "Echo Reply" packet. Another common way of using ICMP is the traceroute(8) command. This works by generating UDP packets with very short Time To Live (TTL) values. If a router sees a packet with a TTL value of 0, it will send out an ICMP type 11 "Time Exceeded" packet. Since every router that handles a packet must decriment the TTL value by 1, this creates an easy method of seeing what routers (and how many) two nodes are communicating through. By far the most common uses of ICMP packets however, are those you never see. ICMP will send error messages telling a sending node that no more bandwidth is available. It will tell the sending node to redirect a message to a different route. In short, ICMP is the often unseen little janitor of the TCP/IP Suite that keeps everything clean and tidy and informs everyone when the floor is wet and slippery. 5.5 ARP ======= ARP is formally described in RFC 826. ARP is a protocol used to resolve hardware addresses from network addresses. Canonically, this means that if you know a node's IP Address, you'll use ARP to discover its MAC Address. Simple, right? ARP packets are non-routable, so they will only tell you the MAC Addresses of nodes on your LAN. A typical ARP dialogue looks like this. robin: "Hey! Who out there is 192.168.1.197?" solitude: "Huh? Oh that's me! I'm 00:B0:D0:23:62:F2." And now robin knows that 192.168.1.197 maps to 00:B0:D0:23:62:F2. That's really all there is to it. We'll show some actual examples later which will help you better visulalize this. 6. Transport Layer ================== The Transport Layer is every bit as simple and complex as the network layer. It is responsible for communicating the wishes of the Application Layer with the Network Layer, and in some cases, is responsible for ensuring that data arrives at its destination. You might think of the Transport Layer as a postman. He accepts letters (data) from you, and passes them off to be routed to their final destination. If you have to be certain the letter arrives at its destination, you can send it certified mail and get reasonable confirmation that it was indeed delivered. 6.1 TCP ======= TCP is formally described in RFC 793. Transmission Control Protocol is the most widely used protocol in the transport layer, and the only thing in the entire TCP/IP suite that garauntees delivery of packets by using some fairly ingenious techniques. To start, TCP marks every packet with a sequence identification number. In the event that some packets are received out of order, the receiving node can re-arrange them correctly. Also, TCP requires an acknowledgement of receipt for every packet, so the sending node knows without doubt if a packet was received. Finally, TCP includes a rudimentary checksum to verify that the data sent has not been changed en route. TCP is known as a "connection oriented" protocol, because it sends all data in the framework of an open connection, rather than simply firing the data off like every other protocol and hoping the destination node receives it. 6.1.1 Ports =========== Ports are a way of communicating with the Application Layer. TCP has 65,536 total ports. Every TCP packet has a Source Port and a Destination Port. When a TCP packet is received, the kernel looks at the port number (1 - 65,536) and determines what application to send the data to based on this information. 6.1.2 Flags =========== TCP makes use of a number of "Flags" to specify the type of TCP packet in much the same way that ICMP does. Unlike ICMP, a TCP packet can have multiple flags set at the same time. In this document, we're only going to discuss the four most common. SYN - Synchronize and prepare for a connection ACK - Acknowledge that a packet has been received (and which one) FIN - Finished sending data RST - Reset connection immediately 6.1.3 Connection Initialization =============================== The three-way handshake is used to initiate a TCP connection. It's responsible for ensuring that both end nodes are available and are ready for data to be transmitted. Let's assume that robin decides to get some files from solitude on a TCP connection. First, robin sends a packet to solitude telling him that robin is trying to initiate a TCP connection with a SYN packet. As soon as solitude receives this packet, he knows that robin wants to talk to him and acknowledges it with a SYN-ACK packet. Finally, when robin receives this packet, he replies with an ACK to solitude. This packet is sometimes called the SYN-ACK-ACK packet, but it's really just an ACK packet. Anyhow, this lets both nodes know that everything is ready to roll. It all goes something like this. robin to solitude - SYN solitude to robin - SYN-ACK robin to solitude - ACK At this point, they are ready to transmit information. Robin can send TCP packets without any flags and solitude will reply to each packet with an ACK so robin knows the data was received. If for whatever reason, robin doesn't see an ACK packet for some data it sent, it will resend that packet. 6.1.4 Connection Termination ============================ So now that we know how to initiate a TCP connection, how do we stop one? The answer is the four-way handshake. To stop a TCP connection gracefully, both sides must agree that all data transmission has finished. When each node has completed all the transmission it intends to do, it will send a FIN packet. This is responded to by an ACK. Once both nodes have sent FIN and ACK packets, the connection is over. The reason that both nodes must agree that a transmission is over is simple. One node may no longer wish to send data, but the other still has lots to transmit. When one node has finished a connection but the other hasn't, the connection is called "half-open". Here's an example. Going back to robin and solitude, robin has requested a rather large file be sent to him. Once this file has begun transmission, robin decides that he no longer wishes to send anymore requests and gives solitude a FIN packet. solitude ACKs the FIN, but continues to send that large file until that is complete before sending its own FIN. Here we will begin with the three-way handshake, begin transmitting data, and end with a four-way handshake. Sender Receiver Flags Content ====== ======== ===== ======= (three-way handshake) robin solitude SYN solitude robin SYN-ACK robin solitude ACK (begin data transmission) robin solitude Give me BIG_FILE solitude robin ACK soliude robin BIG_FILE part 1 robin solitude ACK soliude robin BIG_FILE part 2 robin solitude ACK soliude robin BIG_FILE part 3 robin solitude ACK soliude robin BIG_FILE part 4 robin solitude ACK (begin four-way handshake) robin solitude FIN solitude robin ACK (half-open connection) soliude robin BIG_FILE part 5 robin solitude ACK soliude robin BIG_FILE part 6 robin solitude ACK soliude robin BIG_FILE part 7 robin solitude ACK soliude robin BIG_FILE part 8 robin solitude ACK (complete four-way handshake) solitude robin FIN robin solitude ACK (connection tore down) There is one other way to tear down a TCP connection, and that is the deadly RST packet! When one node sends the other node an RST packet, everything is over. Both nodes immediately cease transmiting data and close the connection. 6.2 UDP ======= UDP is formally described in RFC 768. UDP is, quite simply, the retarded cousin of TCP. UDP's one and only focus is to communicate between the Network Layer and the Application Layer. At first glance, it looks a lot like TCP, but unlike it's genious cousin, UDP can't work on connections. Rather, UDP simply "fires and forgets". This is actually preferred for many forms of transmission. Since UDP doesn't clutter up things witk sequence numbers, flags, handshakes, and acknowledgements, it can transmit data a lot faster than TCP. For anything that needs to function in real-time, like a video game or streaming audio, it's preferable to loose some data or have it arrive out of order rather than waiting for out of sequence information to be resent. 6.2.1 Ports =========== UDP ports work exactly the same way that TCP ports do. They are simply placeholders that tell the kernel what application to hand the data off to. It's important to note though, that UDP and TCP ports are exclusive. UDP port 80 and TCP port 80 are entirely different and may go to different applications. 7. Application Layer ==================== The Application Layer is responsible for talking to the Transport Layer, and finally talking to the kernel or any user-land applications that make network requests. We won't go into much detail here, as there are literally hundreds of common protocols, thousands of uncommon ones, and untold millions of network applications. There are however, two notable protocols that bare mentioning here as they allow are responsible for setting things up for the Network Layer. 7.1 DNS ======= As we all know, computers work with numbers, and in networking, those numbers usually take the form of IP Addresses. But human beings aren't good at remembering long strings of numbers, otherwise we'd not call computers by names. The Domain Name System (or Service) is what allows us to turn domain names like solitude.ctsmacon.com into IP Addresses like 192.168.1.197. DNS will play a key roll in some of the examples we will use in later sections. 7.2 DHCP ======== The Dynamic Host Control Protocol is an ingenious method of assigning IP Addresses to nodes. Instead of requiring a person to input an IP Address for a machine, DHCP will instead assign that, along with a lot of other helpful network information for him. DHCP operates by sending a UDP packet to the broadcast address 255.255.255.255. Unless a machine is acting as a DHCP server, the packet will be silently dropped. But, a DHCP server will reply with another packet that includes all the information that machine needs to setup basic network services: IP Address, Subnet Mask, Routers, DNS Servers, and optionally much much more. 8. Packet Crafting ================== So now that we know about all the different layers and all the different things that play a part in networking, let's build an actual packet, hand-crafted with love. For our purposes, we're going to skip DNS and assume we know the IP Addresses. This is a data packet being crafted by robin.ctsmacon.com (192.168.1.197) destined for the webserver at www.google.com (72.14.207.99). 8.1 Application Data ==================== All packets begin at the Application Layer. In this case, our application is Firefox. I've just opened it on my laptop, and am in the process of making a request for http://www.google.com/. Since I'm making an HTTP connection (that's what that whole http:// thing is all about after all), Firefox knows that I'm making a TCP connection to port 80 at 72.14.207.99. But first, it has to form the data portion of the packet. This data portion is referred to as the packet's "payload". Every other portion of a packet is designed to get the payload to its destination and has no meaning outside of that. At this point, our packet is nothing but a payload and looks like this: | Payload | 8.2 Transport Wrapping ====================== Here things become interesting. This is the first layer that will add information to the payload and begin forming something more than just raw data. Here, we add a number of fields. This adding of fields is known as "wrapping" because of the way it encapsulates higher layers in lower layers. I won't go into details on all of the possible fields, but pretty much everything is shown below. | Src Port | Dst Port | | Sequence Num | | Acknowledgement Num | | Data Offset | Reserved | Flags | Window | | Checksum | Urgent Pointer | | Options | | Payload | Source Port - 16 bits Destination Port - 16 bits Sequence Number - 32 bits Acknowledgement Number - 32 bits Data Offset - 4 bits Reserved - 4 bits Flags - 8 bits Window - 16 bits Checksum - 16 bits Urgent Pointer - 16 bits Options - 32 bits (if present) Notice how I have divided up the lines into discrete 32-bit segments? This is perhaps the easiest way to look at the actual data of a packet, in binary 32-bit words. Each line is one word. Here we've added the "Source Port", "Destination Port", "Sequence Number", "Acknowledgement Number", "Data Offset", "Reserved", "Flags", "Window", "Checksum", "Urgent Pointer and "Options" fields. We haven't previously discussed several of these fields, so now's the time to do just that. Data Offset - This is the size of the TCP Header in 32-bit chunks (or words). This lets us know exactly where the header ends and the Payload begins. Reserved - These bits aren't currently used and should always be 0. Flags - Each bit represents a different flag: SYN, ACK, FIN, ACK, and others. Window - this is basically the most data that the destination node can receive at a time. Checksum - this is just a basic error-checking routine similar to the parity bit in ASCII. Urgent Pointer - this is largely unused and we won't muddy the waters by discussing it now. Options - Another mostly unused field that we will ignore in this discussion. 8.3 Network Wrapping ==================== Now we get to add actual routing information to the packet. | Version | Header Length | Type of Service | Total Length | | Identification Number | Flags | Fragment Offset | | TTL | Protocol | Header Checksum | | Src Addr | | Dst Addr | | Options | | TCP Header | | Payload | Version - 4 bits Header Length - 4 bits Type of Service - 8 bits Total Length - 16 bits Identification Number - 16 bits Flags - 3 bits Fragment Offset - 13 bits TTL - 8 bits Protocol - 8 bits Header Checksum - 16 bits Source Address - 32 bits Destination Address - 32 bits Options - 32 bits The first thing you'll notice is that rather than repeat everything we just did in "Transport Wrapping", we just referred to it as the "TCP Header". Now let's discuss those parts of the IP Header. Version - Either 4 or 6 for IPv4 or IPv6. In this document, we only discuss IPv4. Just know that the version can also be 6. Header Length - This is basically identical to the Data Offset we saw in Transport Wrapping. It is the entire length of the IP Header. Type of Service - This was originally intended to specify a preference for fast transport or higher reliability. It is now almost entirely unused. Total Length - The total length of the packet. Header Length tells us where the IP Header ends. Total Length tells us where the entire packet ends. Identification Number - This is used for identifying IP fragments. Fragments are created when a node can't deal with the entire packet at once, so the packet is split (fragmented) into smaller packets and each is given an Identification Number. Otherwise, this is set to 0. Flags - Used to enforce or deny fragmentation. Fragment Offset - If the packet is a fragment, this is the number of bytes that have been handled by previous fragments. TTL - the number of intermediary routers allowed to handle the packet before failing. This field gets decrimented each time a router handles it. Protocol - What Transport Layer protocol we are using. In this particular example, it's TCP, but it could be UDP as well. This is necessary so the receiving node (or any firewalls in between) don't confuse the Transport Layer's header. Header Checksum - Similar to the TCP Checksum, except that this has to be recalculated at each point because the TTL value has changed. Source Address - The IP Address of the original sending node. Destination Address - The IP Address of the final receiving node. Options - Again, a variable length field that can contain a lot of optional data. Now things are starting to look like a packet! 8.4 Data-Link Wrapping ====================== Now we get to the final step of adding information to the packet. | Dst MAC | | Src MAC | | IP Header | | TCP Header | | Payload | | Checksum | Destination Mac - 48 bits Source Mac - 48 bits Checksum - 32 bits This is all pretty self-explainatory. The only part we haven't discussed previously is "Checksum". Checksum - a standard cyclic redundancy check to check for errors. This is very similar to an md5sum in many ways. At this point, the packet is ready for transmission on the physical layer. 8.5 All Together Now ==================== Now that we've lovingly crafted a packet by hand, let's fill in the values for this packet, and see how it fairs out in the real world. Here, we're going to assume that barnowl.lizella.net (64.178.249.164) wishes to serve an HTTP document to cardinal.lizella.net (208.62.162.112). We'll just call the payload "Payload" rather than create a fictional web page to include there. :^) Some of the other data will be fictionalized as well, such as Data Offset and Total Length. In no cases is any fictional data important to the understanding of the concepts discussed here As much as possible, I'll use binary values to show information. To start, we'll just look at the transport headers and add on other headers. | Src Port | Dst Port | | Sequence Number | | Acknowledgement Number | | Data Offset | Reserved | Flags | Window | | Checksum | Urgent Pointer | | Options | | Payload | 00000000010100000011001101011001 00000000000000000000000000000001 00000000000000000000000000000000 01010000000000000000000000000000 00100100101011010000000000000000 |---------Payload--------------| Type Binary (0 - 15) Explaination ---- ---------------- ------------ Source Port 0000000001010000 80 Destination Port 0011001101011001 13145 Sequence Number 0000000000000000 1 0000000000000001 Acknowledgement Num 0000000000000000 0 0000000000000000 Data Offset 0101 5 Reserved 0000 (Not Used Here) Flags 00000000 (No Flags Set) Window 0000000000000000 (Not described here) Checksum 0010010010101101 (Made up checksum) Urgent Pointer 0000000000000000 (Not Used Here) Options (Not Included) (Not Used Here) As you can see, this packet is leaving port 80, going to port 13,145, and is the first packet in the sequence. Since there are no flags set, we know this isn't a SYN, ACK, FIN, RST, or any other special TCP packet. This is just a plain old packet that sends data in a connection that has already been set up. Since this isn't an ACK packet, the Acknowledgement Number is set to "0". As you can clearly see, there are 5 32-bit "words" before we reach the payload, so our Data Offset is set to "5". Easy isnt't it? The Checksum was simply made up by me. Now that we've got the Transport layer finished, it's time to add on the Network Layer. | Version | Header Length | Type of Service | Total Length | | Identification Number | Flags | Fragment Offset | | TTL | Protocol | Header Checksum | | Src Addr | | Dst Addr | | Options | | TCP Header | | Payload | 01000101000000000010110010010100 00000000000000000000000000000000 01000000000001100010100000101000 01000001101100101111100110100100 11010000001111101010001001110000 |----------TCP Header----------| |------------Payload-----------| Type Binary (0 - 15) Explaination ---- ---------------- ------------ Version 0100 4 Header Length 0101 5 Type of Service 0000000 (Not Used) Total Length 00010110010010100 11412 Identification 00000000000000000 (Not Used) Flags 000 (No Flags) Fragment Offset 0000000000000 (Not Used) TTL 00100000 32 Protocol 00000110 5 (TCP) Header Checksum 0010100000101000 (Made up checksum) Source Addr 0100000110110010 64.178.249.164 1111100110100100 Destination Addr 1101000000111110 208.62.162.112 1010001001110000 Options (Not Included) (Not Used Here) Last but not least, we'll wrap the packet at the Data-Link Layer. | Dst MAC | | Src MAC | | IP Header | | TCP Header | | Payload | | Checksum | 00000000000000101110001100000111 01000110001000000000000010100000 11001100110110110001101000011010 |----------IP Header-----------| |----------TCP Header----------| |-----------Payload------------| 10100100011101010010110000110101 Type Binary (0 - 15) Explaination ---- ---------------- ------------ Destination Mac 0000000000110000 00:30:88:01:df:c8 1000100000000001 1101111111001000 Source Mac 0000000010100000 00:a0:cc:db:1a:1a 1100110011011011 0001101000011010 Checksum 1010010001110101 (Made up checksum) 0010110000110101 In this case, the Destination MAC Address is the MAC Address of barnowl's router and the Source MAC Address is the MAC Address of barnowl himself. Always remember that these two values change everytime you traverse a subnet. So, what does the entire packet look like? 00000000001100001000100000000001 11011111110010000000000010100000 11001100110110110001101000011010 01000101000000000010110010010100 00000000000000000000000000000000 01000000000001100010100000101000 01000001101100101111100110100100 11010000001111101010001001110000 00000000010100000011001101011001 00000000000000000000000000000001 00000000000000000000000000000000 01010000000000000000000000000000 00100100101011010000000000000000 |---------Payload--------------| 10100100011101010010110000110101 Or.... - Destination MAC Address - Source MAC Address - Version - Header Length - Type of Service - Total Length - Identification - Flags - Fragment Offset - TTL - Transport-Layer Protocol - TCP Header Checksum - Source Addr - Destination Address - Options - Source Port - Destination Port - Sequence Number - Acknowledgement Number - Data Offset - Reserved - Flags - Window - Checksum - Urgent Pointer - Options - Payload - Data-Link Layer Checksum 9. A Day in the TTL of a Packet =============================== Well, we've constructed packets and we've learned what everything does. Now it's time to look at sets of packets. 9.1 Traversing the Subnet for Fun and Profit ============================================ I've told you that a packet changes; well, now it's time to learn just how it changes. To start with, everytime a packet crosses a router, it gets an entirely new Data-Link Layer header. This is necessary because every piece of information changes to facilitate transmisison to the next hop in its route. Here's an example traceroute to show all the routers a packet must traverse to reach its final destination. (Note that this is different for any two end-points.) alan@barnowl:~$ traceroute cardinal.lizella.net traceroute to cardinal.lizella.net (208.62.162.112), 30 hops max, 38 byte packets 1 ip-64-178-249-129.pstel.net (64.178.249.129) 10.995 ms 10.719 ms 10.061 ms 2 ip-64-178-248-1.pstel.net (64.178.248.1) 11.065 ms 17.416 ms 11.568 ms 3 12.124.234.201 (12.124.234.201) 28.803 ms 28.021 ms 27.323 ms 4 tbr1.wswdc.ip.att.net (12.122.113.22) 52.084 ms 49.295 ms 48.048 ms 5 12.122.16.13 (12.122.16.13) 48.053 ms 48.754 ms 46.608 ms 6 cr1.attga.ip.att.net (12.122.1.173) 46.302 ms 48.079 ms 48.281 ms 7 tbr1.attga.ip.att.net (12.122.17.2) 48.547 ms 47.749 ms 48.046 ms 8 12.122.96.17 (12.122.96.17) 91.512 ms 92.027 ms 50.797 ms 9 192.205.34.190 (192.205.34.190) 46.791 ms 66.366 ms 46.293 ms 10 AXR01AEP-1-0-0.bellsouth.net (65.83.236.49) 47.392 ms 48.306 ms 48.727 ms 11 axr00aep-so-1-0-0.bellsouth.net (65.83.238.38) 54.673 ms 54.511 ms 56.307 ms 12 axr01mgm-so-1-0-0.bellsouth.net (65.83.236.39) 55.511 ms 54.668 ms 61.301 ms 13 axr00mgm-ge-0-0-0.bellsouth.net (65.83.238.26) 53.960 ms 55.394 ms 54.176 ms 14 ixc00bhm-pos-5-0-0.bellsouth.net (65.83.239.83) 55.427 ms 54.033 ms 54.917 ms 15 her01bhm-ge-0-3-0.bellsouth.net (205.152.92.181) 54.133 ms 54.531 ms 54.634 ms 16 74.253.159.234 (74.253.159.234) 54.458 ms 55.880 ms 60.577 ms 17 cardinal.lizella.net (208.62.162.112) 55.187 ms 56.556 ms 55.906 ms Here we can see that we'll have to make 17 hops to reach our destination. I'm only going to detail one of these hops in addition to those fields in the packet header that are prone to change. We're going back to the example of barnowl.lizella.net serving part of an HTTP document to cardinal.lizella.net. Here's our packet again. 00000000001100001000100000000001 11011111110010000000000010100000 11001100110110110001101000011010 01000101000000000010110010010100 00000000000000000000000000000000 01000000000001100010100000101000 01000001101100101111100110100100 11010000001111101010001001110000 |--------TCP Header------------| |---------Payload--------------| 10100100011101010010110000110101 When barnowl's router receives this packet, the first thing it does is strip the Data-Link Layer away. Everything in this layer will be replaced. 01000101000000000010110010010100 00000000000000000000000000000000 01000000000001100010100000101000 01000001101100101111100110100100 11010000001111101010001001110000 |----------TCP Header----------| |------------Payload-----------| At this point, the router 64.178.249.129 will decriment the TTL value by 1 and re-value the Header Checksum. (Again, I'm filling in random values for the checksum.) 01000101000000000010110010010100 00000000000000000000000000000000 00111111000001100010101100010111 01000001101100101111100110100100 11010000001111101010001001110000 |----------TCP Header----------| |------------Payload-----------| The TTL has been decrimented from 01000000 to 00111111 (63). Now it's time for a routing decision. Just like barnowl determined that cardinal wasn't on its LAN (or any network that it knew anything about), the router must make the same decision, consulting its routing table to decide where to forward the packet next. Once it has decided, it's time to re-wrap the packet at the Data-Link Layer, however, everything has changed. The packet is now being sent out from a different Source MAC Address and is being sent to a different Destination MAC Address. (Since I cannot determine either of these addresses, I am making up values for them.) New Dst MAC Addr: 00:02:43:d7:a6:20 New Src MAC Addr: 00:ca:10:08:46:8e 00000000000000100100001111010111 10100110001000000000000011001010 00010000000010000100011010001110 01000101000000000010110010010100 00000000000000000000000000000000 00111111000001100010101100010111 01000001101100101111100110100100 11010000001111101010001001110000 |-----------TCP Header---------| |------------Payload-----------| 10110110001000100000010100000001 This continues until the packet reaches its final destination (or until the TTL value drops to 0 and the packet is discarded). 9.2 TCP from SYN to FIN ======================= I thought it would be of benefit to show an actual TCP connection from start to finish. Here, I have striped the Data-Link Header for clarity. The IP Header has been left in, but largely stripped of extraneous data. In addition, we won't be looking at any of the packets in this connection in binary form, and rather than entering IP Addresses for the nodes involved, we'll simply use the short form of their host-name. Let's assume robin.lizella.net (IP Addr 192.168.1.1) wants to retrieve a web page from barnowl.lizella.net (IP Addr 192.168.1.254). Naturally, the first thing it needs to do is initiate a three-way handshake. robin -> cardinal Src Port 3560 Dst Port 80 Flags SYN Seq Num 0 Ack Num 0 cardinal -> robin Src Port 80 Dst Port 3560 Flags SYN/ACK Seq Num 0 Ack Num 0 robin -> cardinal Src Port 3560 Dst Port 80 Flags ACK Seq Num 0 Ack Num 0 At this point, the three-way handshake has been initialized and we're ready for the first packets with any real data in them to be transmitted. robin -> cardinal Src Port 3560 Dst Port 80 Flags None Seq Num 1 Ack Num 0 Payload "Give me index.html" cardinal -> robin Src Port 80 Dst Port 3560 Flags ACK Seq Num 0 Ack Num 1 robin has asked for the document "index.html" and cardinal has responded with an acknowledgement. Next, cardinal will begin to send the page. cardinal -> robin Src Port 80 Dst Port 3560 Flags None Seq Num 1000 Ack Num 0 Payload "Part 0 of index.html." robin -> cardinal Src Port 3560 Dst Port 80 Flags ACK Seq Num 0 Ack Num 1000 cardinal -> robin Src Port 80 Dst Port 3560 Flags None Seq Num 1001 Ack Num 0 Payload "Part 1 of index.html." robin -> cardinal Src Port 3560 Dst Port 80 Flags ACK Seq Num 0 Ack Num 1001 cardinal has sent the first 2 parts of the page (remember, computers always start counting at 0 and you should too!) and robin has acknowledged both of those parts. Now, robin decides that it's ready to terminate the connection. robin -> cardinal Src Port 3560 Dst Port 80 Flags FIN Seq Num 0 Ack Num 0 cardinal -> robin Src Port 80 Dst Port 3560 Flags FIN/ACK Seq Num 0 Ack Num 0 robin has sent a FIN packet to cardinal, asking cardinal to tear-down the connection gracefully. cardinal has in turn acknowledged this termination request, but isn't yet finished sending the web page. (If robin wanted cardinal to immediately drop what it was doing and tear down the connection, he would have sent an RST packet instead.) cardinal -> robin Src Port 80 Dst Port 3560 Flags None Seq Num 1002 Ack Num 0 Payload "Part 2 of index.html." robin -> cardinal Src Port 3560 Dst Port 80 Flags ACK Seq Num 0 Ack Num 1002 cardinal -> robin Src Port 80 Dst Port 3560 Flags None Seq Num 1003 Ack Num 0 Payload "Part 3 of index.html." robin -> cardinal Src Port 3560 Dst Port 80 Flags ACK Seq Num 0 Ack Num 1003 Now that cardinal has completed sending all its data, it will let robin know that it too is closing the connection. cardinal -> robin Src Port 80 Dst Port 3560 Flags FIN Seq Num 0 Ack Num 0 robin -> cardinal Src Port 3560 Dst Port 80 Flags FIN/ACK Seq Num 0 Ack Num 0 And now the connection is completely torn down.