CCIE Study Notes

For the final part of this section, I would like to discuss the IPv4 and IPv6 headers. It's not technically "addressing," but since I have so much IPv6 information here, I'd like to put it at the end to wrap things up. All of the diagrams so far have been created by me (using Paint). I do this so that I am diagramming the idea that I am explaining. It helps with reinforcement. However, I am going to screen capture the IPv4 and IPv6 headers diagrams and focus on the difference. I'm taking a chance, but betting that these headers don't show up in a drag-and-drop scenario.

Here are diagrams of the headers (from Implementing IPv6 Networks by Cisco Press):

** IPv4 Header **

** IPv6 Header **

I liked these diagrams more than most others I've seen for several reasons. The first reason is because the way they are displayed is equivalent. They are both 32 bits across. And they also show the length of the header. This is the first thing to note about the difference. The IPv4 header is normally 20 bytes (shown as "octets" in the diagram). BUT - an IPv4 header can have options (and padding). This means that the actual IPv4 header could have a variable length (but is at least 20 bytes). The IPv6 header will ALWAYS be 40 bytes.

So how do you know where the IPv4 header ends? Well, it has to have a length field (Hd Len - sometimes shown as IHL) to tell you. In IPv6, you don't need that because it will ALWAYS be 40 bytes. In case you've forgotten - the Hd Len field has a minimum value of 5 and you multiply the value by 32 to get the number of bits.

The TTL field is now the Hop Limit. The "Total Length" field is now "Payload Length" (since you already know the header is 40 bytes, the Payload Length tells you where the end of the packet would be located). The "Type of Service" (Precedence and ToS bits) are now found in the "Traffic Class" section. And the "Protocol" field (which told you the next section in the packet) is now the Next Header. More on Next Headers in a bit.

There is only ONE new field in IPv6 - the "Flow Label" field. The IETF RFC 6437 covers IPv6 Flow Label Specifications. Yeah, they have an entire document on a 20 bit field in an IPv6 header. The document is only 15 pages long (including the Appendix) and has a few surprises. You should read it. It gives you a little insight into how these things come about. You see the problems this is trying to solve and what other problems it may create. The section on Covert Channel Risk is very interesting and may surprise you. For those that like math, the Appendix covers an example 20-bit hash function.

I know that not all people in the Security field have Networking experience. But, I can tell you that in more than a decade of configure, maintain and troubleshoot in the Route/Switch world, I have never thought of packets in the way they are displayed above. Here is how I see and think of a packet:

** IPv4 **

** IPv6 **

Yes, it's a wireshark screen capture. If you've used Wireshark before, this is familiar. If not, you can Download Wireshark and take a sample of your own traffic. You will see these same sections in your trace file. Note that Wireshark adds some analysis information to the displayed packet (I lined through some of it in the images above).

In the IP section of the IPv4 packet, you can see (at the first red arrow) where they show the header length 0101 which is 20 bytes; (5) is the actual decimal value. The interesting part of doing this on your own system is that as you click on each part of the IP header, the corresponding bytes of the actual packet are highlighted in the bottom pane. In case you can't see it clearly, the second red arrow points to the "Protocol" field. In this case, the value is 6 - which corresponds to TCP.

Looking at the IPv6 packet, you can see that it's quite streamlined. Again, you may be able to see this more clearly on your own system in Wireshark. The red arrow in this image points to the "Next Header" field - which happens to have a value of 17 - which corresponds to UDP.

Other than looking at it displayed in Wireshark, you can look at the IANA Protocol Numbers assignment page to find the values for each protocol. In IPv4, these are the values that will be in the Protocol field. In IPv6, this will be the values that will be in the "Next Header" field.

Cisco has a White Paper which covers IPv6 Extension Headers. Table 1 [IPv6 Extension Headers and their Recommended Order in a Packet] may be really important to know. When there are steps or a certain order of things, a red light should go off in your head and you should look at it closely.

I don't like the graphic above (in the white paper) which has Next Header = EH1 since the value will not be 1 (or EH1). The value in the block will be the "code" for that header type/protocol. The table itself can be a bit confusing too. The columns "Header Type" and "Next Header Code" are not very intuitive. It should be read: "If the next header type is X Header Type, the Next Header Code you would see is #." If you flip back and forth between the IANA page and this table, you will see that each code is basically the protocol number for each of these header types. Some of these may be new to you (60, 43, 44) but, most of them should already be in your head from use and prior training. The protocol numbers for AH and ESP should already be familiar. TCP and UDP protocol numbers should already be familiar. So the order is the part you need to remember. Look at the list and make up a phrase to help you. Mine is: Bull Hockey DR FAE DM. Imagine that your dentist (Dr. Fae DM) just told you a lie. Yes, there are two Destination Options. Makes sense that the one with Routing Options would be just before the Routing Header. Other than the order, the only important requirement is that the Hop-by-Hop Options be the first Extension Header after the basic header.

And with that, I am going to put this section to bed. I believe I can say that I have this part covered. There was previously a weakness in the topic of IPv6. Hopefully working on this section has helped shore up that topic.