One of my sole regrets as a father is that I didn’t see that onesie until my daughter was just a little too old to wear them anymore. If “Baby #2” happens, then one of the very first things I’m going to do is buy one of these; it always makes me chuckle. “Mostly IP” is a great description of both babies and our next exam topic: IP Operations. (Have you ever seen someone begin discussing family planning as a segue into technical certification exam topics?) Here are the actual exam blueprint topics:
1.1.d Explain IP operations
1.1.d (i) ICMP unreachable, redirect
1.1.d (ii) IPv4 options, IPv6 extension headers
1.1.d (iii) IPv4 and IPv6 fragmentation
1.1.d (iv) TTL
I started off my last post by saying that it felt like a bit of a catch-all topic where Cisco put all of the topics that didn’t really fit anywhere else. When I first saw a topic named “Explain IP Operations”, I thought this was going to end up being more of the same. It quickly became clear though, that this topic is actually very focused. This isn’t a topic about the whole TCP/IP protocol suite, it’s specifically focused on IP, the layer 3 protocol itself, with a special focus on information about its header and some of interactions between IP and certain ICMP messages.
So, before I dive into the weeds there, a brief overview of ICMP is in order. ICMP messages are broken down initially into types and code. Those familiar with the concept of breaking animals into different families/genus/species will find the idea of type and code easy to digest. If ICMP is the “family” in this analogy, then each different ICMP message type can be thought of as a genus, with the specific codes being like different individual species. Some ICMP message types are overwhelmingly familiar to us, like type 0 (echo reply) and type 8 (echo request). Others, such as those covered in this exam topic, might be slightly less so.
When we begin talking about ICMP unreachable messages, we are talking about ICMP message type 3. Within ICMP messages with type 3, there are 16 different codes. The basic idea is that the ICMP message being type 3 indicates the fact that a destination is unreachable, then the specific code value indicates why that destination is unreachable. I will note that I always knew that unreachable messages existed, but never really grasped the concept that there were indeed multiple types of unreachable messages. Though, technically, saying “different types of unreachables” is probably a bad choice of wording, since ICMP unreachables are all one specific ICMP message type within ICMP nomenclature. Perhaps it would be better to say that there are different “varieties” of ICMP unreachable messages, each expressed with different codes, all of ICMP type 3. It’s good to know that ICMP carries the ability to explicitly state whether the issue exists with a host, network, protocol, port, fragmentataion need, source routing, etc. issue as the cause. There’s no guarantee that every application or operating system will implement these types correctly, but it’s good to know that the different codes exist, as it can help point you in the right direction before you even begin your troubleshooting. Below are the 16 defined ICMP Unreachable codes.
It continues to blow my mind to realize how many routing and switching concepts exist where I realize “I’ve heard of that, and can kinda guess what it does…” but in reality, I’ve never worked with that particular thing in the past or knew when it should occur. ICMP redirects are one such concept. From the name, we can probably gather that something is being told “hey, go there instead.” Indeed that is the case. ICMP Redirects are ICMP message type 5. To demonstrate how redirects work, take the example topology shown below. R1, R2 and R3 are all connected via a shared LAN segment. Let’s assume that R1 only has a single, default route that tells it to hand off all traffic to R2, and that R2 has more exact routing tables, including a route to a remote LAN behind R4, for which it needs to route the traffic through R3.
If R1 receives a packet destined for a prefix behind R4, it will send that packet to R2 since that is what its default route tells him to do. Does that make sense though? Not really… R2 is just going to end up sending that packet right back out the same G 0/0 interface that it received the packet from in order to hand it off to R3. Since R1 and R3 are on the same shared LAN, wouldn’t it make more sense for R1 to send that traffic directly to R3 instead of passing it to R2 first? That’s exactly what an ICMP redirect helps accomplish. While R2 DOES indeed pass the packet back out that same interface to R3 it will also send a redirect packet to R1 that essentially tells R1 “Hey, I’ll go ahead and route this packet for you, but just so you know, there’s a better path to this network through R3.” The sending of such redirects is a behavior that is on by default, and can be turned off with the interface no ip redirects command. You can view networks for which you have received a redirect message with the show ip redirects command.
IPv4 options and IPv6 extension headers exist to accomplish many of the same functions, but the way they are implemented is quite different. IPv4 options are described in a 4-bit field called the Internet Header Length or IHL field that exists in the IPv4 packet. This IHL describes, in a roundabout way, how many 32-bit words in the “options” field are going to exist. It accomplishes this by giving the final value of the size of the entire IP header, in increments of 32-bits. This is incredibly counter-intuitive, so bare with me for a moment. Let’s start with an example of an IP header with zero options. You might first expect the IHL field to be “0”, but again, the IHL tells you the length of the entire L3 packet header. From that information, a router can deduce how many options are contained in the packet. An IP header without any options will be 20 bytes long. For such a packet, the IHL field will express the length of the IP header as 20 bytes. Remember though, that these are expressed in 32-bit “words.” How many 32-bit words are in 20 bytes? Let’s first convert bytes to bits, 20*8 = 160. Now, we can more easily discover that an IP packet with no options is 5 “words” (32-bit units) long, because 160/32 = 5. So an IP packet with no options has an IHL value of 5. When you start adding options, the header length grows in size. The maximum IP header length is 60 bytes, which is 15 of these 32-bit words. So the greatest value you would see in this IHL field is 15. (15 is also the highest value that can be expressed in a 4-bit field) To make this even more messy, these options aren’t 32-bits long, so any time there aren’t enough options to land on one of these 32-bit boundaries, the packet’s “options” field will be padded so that the field can still be 32-bits long. Ironically, the fact that this is a little hard to wrap your head around is also true for routers themselves. It’s difficult for routers to process IPv4 packets efficiently when packet headers are of varying lengths. That is one of the beautiful things about IPv6 design. Before we cross that bridge though, let’s talk about some of the values that we can potentially see in that Options field. Like with ICMP messages, IP options are broken down into categories and subcategories. Most options will be defined by a three different fields: type, length and data. Within the type field, which is a “sub-field” of the options field in the IP header, the 8-bit field is broken down into three sub-sub-fields. (Yes, I’m serious.) The first bit of the “type” field is the “copied” bit. A 1 in this field indicates that this packet is a part of a fragment, and that the values in this option should be copied for use with all of the other fragments that accompany this one. The next two bits of the type field are the option class bits. This will either be set to 0, which is used for control options, and 2, which is used for debugging options. Finally, the last 5 bits of the type field describe the option number, which essentially defines what the option is. The next field within the option field is the length field, which is 8-bits long, and defines how long the entire option is. It essentially explains how much data in the “data” field is actual information, and how much of that information if just padding so that the field ends on one of those 32-bit boundaries. Obviously, “data” is the last of these three fields in the option. Again, the list of these options is so long, and rather than defining every single one, I’ll link a chart below.
IPv6 Extension Headers
One of the big reasons that people have been slow to adopt IPv6 is that we’ve grown accustomed to IPv4, and moving away from something that we’re so familiar with is a little hard to swallow at times. But “newer” doesn’t always mean more complicated. Extension headers are a huge example of that. After describing the messy way that options are implemented in IPv4, IPv6 extension headers are a welcome change. First of all, IPv6 L3 headers are 40 bytes. Always. Period. The name “extension header” essentially comes from the fact that there are additional headers added to an IPv6 packet, rather than trying to cram a ton of information in, as IPv4 is wont to do. Every IPv6 header contains a field that is literally called the “next header” field. That next header might be TCP, UDP or ICMP, in which case, it is evident that there are no more L3 options that need to be called out. Or they could be relevant L3 information, in which case, the next header in the original IPv6 header will point to a header that contains the relevant information. It’s as simple as this: the IPv6 “Next Header” field essentially tells you that the next header either contains options, or that it contains the next layer’s data. Whew, that’s far easier! One thing of note is the fact that the IPv6 packet header does not contain a checksum. This is because checksums are already performed by other protocols, such as TCP and UDP, and it doesn’t make sense to run these checksums at every single layer of the stack. Below are some common IPv6 Extension headers.
IPv4 and IPv6 Fragmentation
For starters, we know that IP packets usually have a default MTU of 1500 bytes. Note that that is the IP packet – we’re talking layer 3 here. Since IP usually gets encapsulated inside of Ethernet (though it could potentially be any of a multitude of L2 protocols), remember that the layer 2 frame is actually a little bit bigger than 1500 bytes. Conversely, since the IP header is included in the 1500 bytes, remember that upper-layer data units are actually slightly smaller than 1500 bytes. For instance, an IP packet with a 20-byte header can carry up to 1480 bytes of data from a TCP segment, including the TCP header. It is also important to note that fragmentation happens here at layer 3. For me, I always assumed that it happened at layer 4, because it involves the re-ordering of packets, which is a concept that TCP takes care of. It makes sense that this is an L3 concept now though, especially considering that UDP packets might need to be fragmented as well as TCP packets. Also, routers aren’t really looking at L4 information as they route packets. They sure do pay a whole heck of a lot of attention to the L3 headers though.
When a router sees an IPv4 packet with a length greater than its allowed MTU (usually 1500 bytes), it first checks the DF bit in the IP header. If “Do not Fragment” is set, the router will drop the packet and return an ICMP unreachable message type 3 code 4. If the DF bit is set to 0, the router will begin the fragmentation process, creating two or more entirely new IP packets to forward. These newly created packets will each be the length of the MTU minus the size of the IP header. Fragmented packets have the More Fragments flag set to 1, with the obvous exception of the final packet. Fragmented packets also have a fragmentation offset field, and a newly recomputed checksum value. The fragmentation offset essentially enumerates how much of the data has been transmitted so far, in units of 8-byte blocks. This is how the data ultimately gets resequenced, as the “amount of data transmitted so far” will start at zero and increase until a packet arrives without the More Fragments flag set. Since 1500 is the most common MTU, let’s use an example with that value. Say a TCP segment shows up that is 9000 bytes in length. It’s tempting to think that it will be broken into 6 new packets of 1500 bytes each, but remember that each of these packets needs a new IP header. So it will actually get broken into 7 packets, the first 6 of which each contain 1480 bytes of the the orignial packet, and the final one containing 120 bytes of it, which, combined with its new IP header will be 140 bytes in size. The first of these packets will have a fragment offset of 0, the second will have a fragment offset that shows that 1480 bytes have been transmitted – but remember that it expresses this in units of 8-byte blocks. 1480/8 = 185. So the second packet will have a fragment offset value of 185. The third one will have a fragment offset of 370, and on and on up to the last one, which will have a fragment offset value of 1110, and will have a 0 in the more fragments field. The receiver can now reassemble the packets and can tell if it has missed any of them.
IPv6 routers handle fragmentation very differently: they don’t. Fragmentation is a sender requirement now. Rules of IPv6 simply state that the host is responsible for first discovering the MTU and then performing fragmentation as necessary. An IPv6 host discovers the MTU through a process called Path MTU Discovery, or PMTU. For starters, every IPv6 host is required to support a minimum MTU of 1280 bytes, So all hosts can safely use that value. If an IPv6 host needs to fragment a packet that it wants to send, it simply adds an extension header that gives the details of the fragment. IPv6 uses the same ID and fragment offset concepts that IPv4 uses.
TTL (and Hop Limit)
TTL is basically a loop avoidance method. The IPv6 implementation is essentially the same as in IPv4, but it has been renamed to Hop Limit instead to more accurately reflect its function. TTL and hop limit operate very simply – each time the router receives a packet that it needs to forward, it first checks to make sure that this value has not reached 0. If it has, it discards the packet and sends back an ICMP type 11 code 0 message to inform the sender that the TTL has expired for IPv4 or an ICMPv6 Tpe 3 code 0 “hop limit exceeded” message in IPv6. If TTL/limit has not been decremented to 0, the router decrements the field by 1 and forwards it on. Technically, TTL was originally intended to decrement by the amount of time that a router was processing a packet for, so it if took a router 5 seconds to forward, it could decrement the TTL by 5. Modern networks don’t see that kind of delays though, so TTL is usually used more as a hop count, and IPv6 networks have essentially eliminated that concept altogether by using a hop limit instead of TTL field.
Credit: Charts obtained from www.iana.org