ICND1 100-105

ICND1 100-105

The IPv6 Pakcet Header. ICMPv6 and Neighbor Discovery (ND)

Before we see the future, let's see the present and that is the IPv4 packet header. The reason why we want to discuss this is because some of the fields are preserved and some are changed.

IPv4 Packet Header

Version becomes version 6, okay. Type of service, or ToS, well that's a quality of service field, we still need quality of service, so we'll see a version of that in IP version 6. But some of the interesting things that will change are time to live. Time to Live, or TTL, was originally envisioned as a number of seconds. It never really worked out that way, so instead what we're going to find is a router hop count. It's hop count. It's a hop count in v4, but now it's renamed to being hop count. Protocol is still important. Remember, protocol helps us figure out which transport layer protocol we're handing off to. But something that is very surprising is, we no longer want to do a checksum. It takes time to do a checksum. A small amount of time, but magnify that small amount of time by billions of calculations, one per packet, we don't do that anymore.

Also at layer 2, there are checksums going on at layer 2 and they are much better than what was happening at layer 3. So we just have redundancy with IP version 4 when it comes to the checksums at the different layers.So yeah, they really noticed that and decided, let's take it out of there, not necessary.

So what remains with IP version 6?

IPv6 Packet Header

Well as we already said we have our version. It's going to be 6. It's no longer called Type of Service field. It's called traffic class, identifying that traffic for classification purposes. So we want to allow this traffic because it's voice traffic to have a priority over data traffic, but that feels all about discriminating each packet. Flow label, this is new. We didn't have this with IP version 4, but we have the ability with IP version 6 to perform special functions on flows of packets. So what is a flow, first of all?

It's a unidirectional traffic stream. So if we are talking bidirectionally, we would have one flow one way and another flow the other way.

So we can perform special handling on a flow of traffic, so multiple packets that belong to the same flow. Payload length. Now, the payload is what we're carrying. So what would we be carrying here? Well everything from the upper layers above layer 3 of the OSI model. Notice, we don't have any information about the header here. We had that with IP version 4. Why? Because our header for IP version 6, the main header that every packet will receive, is the same size no matter what. So we only have to worry about what are we carrying. How big is that? Now the next header field is very, very similar to something in IP version 4. In IP version 4, we called it the protocol field, but here we call it the next header field, so what is this pointing to?

It's pointing to the protocol that we decapsulate to or de-encapsulate, whichever you call it, they're both accurate and so really it takes on the same function, it takes on the same function. Usually, when I think about the protocol field in v4, it's a transport layer protocol. It's not always a transport layer protocol in actuality nor is next header and it's a little less targeted at the transport layer. It says, you know what, I don't care, just whatever you want to decapsulate into, please identify that right here. Oh, and then I spilled the beans on this one already - hop limit. Hop limit. That is the time to live field re-envisioned and envisioned in the way that it will be used and then I just see, uff, I see some pretty big source and destination addresses that seems pretty bulky.

Well our earlier discussion, we indicated that IP version 6 addresses were 128 bits long. We're dealing with 128 bits here for source address and destination address, that's why it is so big and bulky. The addresses are simply bigger.

That right there are the main fields of the IP version 6 header that every packet will have. After that, we end up in some variable areas, where we'll have variable length information. These are known as our extension header information. Only if required, will we have this extension header information. For example, if we're applying security, Internet Protocol Security, or IPSec, that information wouldn't be in here. If we're applying other features and services and components, that information would be in here. But just a normal packet without anything added to it, will just find those initial fields of 40 octets. So it's fair to say that for IP version 6, our average header is a fixed length of 40 octets, but if we apply any special features or services after that, it will grow variably in size and then after that, we have our data portion. What's the data portion? The payload. Everything else from the higher levels in the OSI model or the TCP/IP stack is added on and carried along with it.


Let's focus on the next header field at the moment. What did we say the next header would point to? Typically, an upper layer protocol, TCP; User Datagram Protocol, or UDP; Internet Control Message Protocol, or ICMP. Now when we refer to IP version 4 ICMP had a protocol ID of 1, it was 1. What's the purpose of ICMP with IP version 4?

Well it does a number of things. It's not a one-trick pony and we have to understand that. We have the echo-echo reply, but it also has some incredibly important functions, okay. And these unspoken functions like ICMP unreachable when we don't have the ability to send to a destination or ICMP time exceeded where we have a TTL that was decremented to zero by the unfortunate router that got a dying packet. It's not just about pinging and we even have things like ICMP redirects when you send to the wrong layer 3 device. And what's amazing about ICMP is, instead of it being just copied or like some of the other technologies in v4, just deprecated and undone not seen here, instead double down, we use this protocol for everything we possibly can.

It's used for everything and there is no exception for IP version 6, but we have ICMP version 6 now and our protocol number is 58, 58 for ICMP version 6. And when the packet is carrying a next header value of 58, well then we expect the data, the packet to be an ICMP version 6 packet and inside that packet, there will be information related to the type of packet it is. And then codes identifying more detailed information about this particular packet and the overall data. What is being carried here in this ICMP message? So it does everything that IP version 4 does, but it also does more. There are certain features that we get with IP version 6 that we didn't have with IP version 4 such as router discovery, neighbor discovery and ICMP is responsible for these discovery mechanisms with IP version 6.

Neighbor discovery

What we said is really a huge punch line for your understanding of v6. In my opinion, understanding IPv6 is not about understanding the size of the address and the communication modalities. It's this right here.

  • Neighbor discovery
    • Determines the link layer address of a neighbor
    • Finds neighbor routers on link
    • Queries for duplicate addresses
    • Is achieved by using ICMPv6 with IPv6 multicast

It's this unglorious thing that we call Neighbor Discovery. I'll tell you this, we don't have Address Resolution Protocol, or ARP, anymore for v6, no ARP, but the need for something that accomplishes the same function remains and so what accomplishes the same function is ICMP ND, Neighbor Discovery. So we ask ICMP to take on some extra work here.

So it's important to note folks, that we are not stating that Media Access Control, or MAC addresses aren't used with IPv6. No we just said ARP was not used. ARP is a function of IP version 4, but we sill have MAC addresses and IPv6 IP addresses and we still have to make the association between them with IP version 6. ARP is not used for that, Neighbor Discovery is used for that and it uses ICMP version 6 as we already mentioned.

It helps us do something that we've talked also. You remember Enhanced User Interface or EUI-64? And even link-local addresses? We have to validate that these are unique when we self-assign them. Even link local has to be careful because it wants to use that EUI-64 approach, but it still has the conundrum of not being a 1000% sure that it's unique. So what does it do, it basically says, hey, is it okay if I use this? And so we query for duplicate addresses. That is Neighbor Discovery also. Hey, isn't that great? We're taking on some extra functions and some functions that we hinted at. Some functions that we hinted at. And IPv6 as we know, had been prepared for multicast and this uses multicast communication. Why don't we use broadcast communication for ICMPv6?

We don't have broadcast with IP version 6 at all! It's a waste of resources. It's just blurting out information on the wire. No, no, no. So broadcasts are gone and the majority of broadcasting functionality that was used as IP version 4, well they changed that functionality and use multicast now. So we're more streamlined now. We're using specific addresses to accomplish specific functions.