Pass CompTIA N10-008 Exam in First Attempt Easily

Module 1 - Introducing Reference Models and Protocols

1. 1.0 Introducing Reference Models and Protocols

Here in Module One, we're going to be checking out a couple of reference models. Those are ways that we can conceptually talk about all the hardware, protocols, and services in our network. Specifically, we're going to be checking out the famous—or some people would say the infamous—OSI model. We're going to follow that up with a look at a reference model that many people prefer.

That's the TCP-IP model. Then for the remainder of the module, we're going to get to know some of the more popular protocols in our network, and we're going to understand how a basic communication gets set up between a couple of our network devices. Now, let's dive into our first topic the seven layer OSI model.

2. 1.1 OSI Model

The network has so many different pieces and parts. We've got devices, we've got protocols, and they act differently. It can become really challenging for IT professionals to take a look at a device or a protocol and really understand how it's going to interact with the other network components. Fortunately, we can use a reference model to give us a frame of reference for how one device is going to interact with another device or one protocol is going to interact with another protocol. and in this video we're going to talk about one of the more popular reference models out there. It's the OSI Model. The open systems interconnection model It's made up of seven layers. We're going to discuss each layer from one to seven. And when we're done, we'll have a better idea of how one device or one protocol can interact with another device or protocol, because each layer has specific jobs.

But before we get started with the different layers, here's a big disclaimer. Some people think that after they understand the seven layers, every single protocol and every single device has to fit neatly into one and only one layer. That's just not reality. This is a reference model, a red one. It's a reference model, not a reference model. It is not to be regarded as the be-all and end-all, where everything will be neatly classified. It's just a reference model to help. Now, let's get started with each of these seven layers. beginning with layer one, the physical layer.

It's at layer one where we're concerned with getting bits on the wire, ones and zeros. Something that we might see at Layer One as an example would be cabling. Like, here's a fibre optic cable. We can use light to represent those binary zeros and ones. By the way, I mentioned that we're sending bits at the physical layer. Something else I want you to know from this video is the name we give data at different layers of the OSI model. Down at the physical layer, data is referred to as bits, and that is a protocol data unit. There's a term for your notes: a PDU.

A PDU is what we call data at different layers of the OSI model. So in your notes, I want you to know that data we refer to as bits is down at layer one. Let's move up to the data link layer. In the datalink layer, we're going to make decisions in an Ethernet network based on Mac addresses. Now, if you take a look at a network interface card that you might have in your computer, there's going to be a burned-in Media Access Control address on this card. It distinguishes it from every other card in the world. And those Mac addresses—that's just an example of something that lives here at the data link layer. and a device that lives at this layer is an Ethernet switch.

This Ethernet switch has different ports on the front of it. And it's going to be connected through network cabling. Layer one: It's going to connect out to your devices, each of which has a Mac address. And the switch is going to learn whatMac address lives off of each port. And it's going to make forwarding decisions based on this table that it constructs internally. It's going to learn the topology—sort of—of your network. It's going to know what Mac addresses are connected to what ports. So at layer two in your notes, I want you to know that we refer to data as frames. So layer one bit at a time. Layer two, frames And a switch is a typical component we see at layer two. Let's move up to layer three, which is the network layer.

At the network layer, this is where we find routers. And here is a really, really small router. But this router, it can make forwarding decisions basednot on physical Mac addresses, but it can makeforwarding decisions based on logical IP addresses. Those are addresses that we get to assign. I can assign an IP address to this network card, and it's going to be able to interconnect different networks that live in different IP address spaces. So at the network layer, that's where we find routers. What do we call data at the network layer? It goes by a couple of names. You might hear it called Packets, ortechnically it could also be called datagrams. So datagrams or packets By the way, the term "packets" is likely to be used fairly generically to refer to data anywhere.

And I'm okay with that. We do use that term somewhat generically, but technically packets live at layer three. Now let's move up to layer four, the transport layer. The transport layer is concerned with network connections. And we have two basic types. We have connection-oriented notes, also known as reliable connections. and we've got connectionless or unreliable connections. And the two big protocols I want you to know here at layer four are TCP, which is the Transmission Control Protocol. That is your reliable, that'syour connection oriented, that protocol. So, if a packet is dropped, the drop will be detected and the packet will be retransmitted. The other protocol I want you to know at layer 4 is called UDP, User Datagram Protocol.

That is your connection list or your unreliable protocol. If you drop a packet with UDP, that packet is just gone. So those are the two protocols I want you to know at layer four. And what do we call data here at layer four? Segments. So to review, we have bits, frames, packets, and segments, and here is a memory aid for you in order to remember the protocol. Data units, the PDUs for these first four layers of the OSI model, which are the only layers to have a specific name for data, by the way, But as a memory aid, I want you to think of the acrostic. Bacon frying produces salivation. very true statement. Bacon frying produces salivation. The B in bacon reminds us of the B in bits. The F in frying reminds us of the F in frames. The PN reminds us of the PN packets, and the S in salivation reminds us of the S in segments. So bacon-frying produces salivation.

That's a great memory aid for you to help you know what we call data at different layers of the OSI model. Now let's move up to layer five of the USL model. Here we have the session layer. This layer is concerned with setting up, maintaining, and tearing down sessions. The first example of a protocol that lives at the session layer is SIP. That's called the session initiation protocol, and it can be used to set up a voice call or a video call, maintain that call, and then tear the call down when we're done. Moving up to layer six, we have the presentation layer.

This is all about how we present our data. In other words, how it's formatted As an example, think of a graphic image. Maybe it's in JPEG format. Maybe it's in PNG format. Those different formats for the same image would be examples of things that would happen here at the presentation layer. It's how we format data in ASCII, where we have just plain text. That's at the presentation layer. Now let's move up to the 7th and final layer, and that is the application layer. Here are our applications. Now, we're not talking about Microsoft Word here. We're talking about the protocols that give us network functionality. As a couple of examples, if you're going to a website, you're going to http://, and it's not a secure website; it's just http. It's not HTTPS. Then Https is the application you're using here at layer seven.

And it's going to use TCP port 80. Remember TCP; it lives down here at layer 4, but the application is HTTP. If you were using a secure version of HTTP, you're going to enter your credit card information. You're going to be using HTTP as your application, and that's going to be using port 443—specifically, TCP port 443—down here at the transport layer. Now we've got these seven layers. But how do we memories all this? Well, I've got a couple of acrostics for you—a couple of memory AIDS. First, let's memories it from the bottom up, from layer one through layer seven. And, by the way, some people are perplexed about this. The numbering starts at the bottom. This is layer one, two, three, and so on. It's like a big high-rise building.

You go in on the ground floor, or floor number one. Then you go up to floor number two and up to floor number three. It's just like a high-rise building. Think of it like that. But to memories these different layers, here's the alphabet to go from the bottom up. And here it is. Please do not throw the sausage pizza away. Again, that's please do not throw sausage pizza away. The P in please reminds us of the P in physical the and do resemble the D in date length, then and do not resemble the NN network, and so on. Please do not throw the sausage pizza away. If you want to memories this from the top down, I've got another memory aid for you. And that appears to be all that people require for data processing. Again, that's all people who remind us of the application. All people seem to need data processing. And that's a look at the OSL model. And once we understand what's happening in each layer, we can better understand how network devices like this router, the switch, and this network interface card work together.

3. 1.2 TCP:IP Model

We know that the OSI model, or the Open Systems Interconnect model, takes network functions, devices, and protocols and categories them into seven different layers. However, when the OSI model was first developed, it was not obvious that we would be running primarily TCP/IP protocols today. There were other contenders besides just having IP addresses on our devices, which we just assume we have today. But now it's clear that, yes, we are going to be an IP based world. So there's a different model you may want to reference, and it's called the TCP/IP model. Or some literature might refer to it as the DoD or the Department of Defense model.

And the big difference between these two models, as we're going to see, is that the TCPIP model groups together the top three layers of the OSL model, the session, the presentation, and the application layer. The challenge with the TCP/IP model is that different writers will have different takes on it. They'll call some layer's different things. You might have a four-layer TCP/IP model. You might have a five-layer TCP/IP model. Let's look at those different combinations of permutations in this video. Now, commonly, you will see the TCP/IP model group and the physical and data link layers of the USI. model into a single network access layer. The network layer gets renamed as the Internet layer, while the transport layer keeps its name. But the big difference is we take those top three layers—the session, the presentation, and the application layers—and we just lump them together into a somewhat generic application layer.

In some variants of this four-layer TCP IPmodel, the bottom layer may be referred to as the network interface layer or even the link layer rather than the network access layer. Or sometimes you'll have a five-layer variant of the TCP/IP model where we keep the physical and datalink layer names from the OSL model. That's where it can start to be a bit confusing because we could have a four-layer version of the TCP/IP model or a five-layer version. And one other variant you might see of the five-layer version is what we call the data link layer, a network interface layer. So I've given you several different combinations there.

You might want to rematch this video and take some notes so that you can spend some time memorizing the different ways that a TCP/IP model might show up. But at the end of the day, I want you to understand that down at that physical layer, that's still what we're talking about. Things like getting bits on the wire with network cabling or maybe fiber optic cabling at that network interface layer or whatever we're calling it in the TCP/IP model are where we're concerned with Mac addresses and Ethernet switches.

At the Internet layer, that's where our routers live. That's where we're concerned with IP addressing at the transport layer. So that's where we have TCP and UDP as a couple of examples. And the application layer is kind of grouping together all the things that make that application possible: how we're formatting our data, how we're setting up, maintaining, and tearing down sessions, as well as the applications themselves, like DNS, HTTP, or SMTP, as just a few examples.

4. 1.3 IP, ICMP, UDP, and TCP

In this video, we're going to discuss some popular protocols and where they fit into our reference models. Specifically, we're going to be focusing on the network and the transport layers of the OSI model. And remember that if we were instead talking about the TCP IP model, that network layer would instead be called the Internet layer, but the transport layer is still called the Transport Layer in the TCP IP model. Now let's zoom in on that network layer. And a couple of popular protocols that we find at this network layer are IP (Internet Protocol) and ICMP (Internet Control Message Protocol). And as a metaphor, I want you to think of IP. IP, like this flatbed truck, will be able to carry upper-layer protocols such as UDP User Datagram Protocol and TCP Transmission Control Protocol on top of it.

By the way, both TCP and UDP live at the transport layer. Specifically, IP can encapsulate In other words, it can wrap up those upper-layer protocols and send them across a network inside an IP packet. And an IP packet has IP addressing. It might be using IP version four or IP version six. And a piece of hardware that lives here at the network layer where IP addresses reside is a router. And a router can make forwarding decisions based on a Layer 3 address, like an IP address. And also at layer three, we have ICMP, or Internet Control Message Protocol. And a really common use of ICMP is to do something called a ping. A ping allows us to see if our network device is reachable by another network device, which could be on our local network or on the Internet.

As an example, consider this basic topology. We've got a PC connected to a layer 2 Ethernet switch, remembering that a layer 2 Ethernet switch makes forwarding decisions not based on IP addresses but based on physical Mac addresses that are burned into a network interface card by the manufacturer. And the device shown at the bottom of this topology is a router, which is going to make forwarding decisions based on layer three IP addresses. But back to our discussion of ICMP. Let's say that our PC is, for some reason, not able to get out to the Internet. Well, one of the first things we might do if we're troubleshooting an issue like that is to see if we can ping. In other words, can we reach our default gateway, the router that gets us out to the rest of the world? And the good news is, most operating systems have a built-in utility called Ping that lets us send out ICMP messages to our default gateway's IP address to see if it's reachable, or any other IP address, for that matter. After all, if we cannot get to our default gateway, we certainly cannot get to anything beyond our default gateway. And this ping feature is going to use a couple of ICMP messages. First, the PC is going to send out an ICMP echo request to the router's IP address. And if the router successfully receives that ICMP message, it's going to let the PC know that it received the ICMP echo request.

So in response, it sends an ICMP echo reply. And when the PC gets that ICMP echo reply, it's going to show us that the ping was successful, and it's also going to show us the round-trip time for that ping. And it's going to give us a good idea of how much delay we have between our PC and whatever device we're doing a ping to, such as our default gateway. And that could be very valuable when it comes to troubleshooting. In fact, let's go out to my terminal and demonstrate this on a live interface. Here we are in the terminal application for my computer, which is running macOS. But the same command would work in Microsoft Windows, and it would work in Linux. I wouldn't do a ping to my default gateway IP address of 170 216 one one.I simply say "ping space 170 216 one one" and press Enter, and we have some successful pings. I'm going to do a Control C to break out of that. And notice we've been sending these 64-bit ICMP packets. Here. We see the reference to ICMP; we see the round trip time, and all these are very small round trip times.

All of these are less than half of a millisecond. And that's because my default gateway is on my local network segment. And we can see that there was no packet loss. And now let's move up to layer four, the transport layer. And a couple of major protocols that we have at the transport layer are UDP (User Datagram Protocol) and TCP (Transmission Control Protocol). And one of the distinguishing characteristics between these protocols has to do with their reliability. Specifically, UDP is not considered to be reliable. When we send a UDP segment, we hope it gets to its destination, but we have no guarantee or confirmation that it actually makes it. And that might sound like a bad thing, but there are times when UDP is preferable to TCP.

For example, if you have voiceover IP or VoIP in your network, you might have a phone much like what we see here on screen. This is an IP phone and has an Ethernet connection in the back. And your voice conversation is going to be flowing over an IP network. Now, interestingly, your voice is being carried inside of UDP because if we were to use TCP, that would be extra overhead. The header is much larger in a TCP segment as compared to UDP. And even though UDP is not going to tell us if we drop a packet, we probably wouldn't want to retransmit any dropped packets anyway. That would cause too much delay in our voice conversation, and dropping an individual voice packet every now and then has a minimal impact on voice quality.

Now, unlike UDP, TCP is considered to be a reliable protocol. Or you might hear it called a connection-oriented protocol because it sets up a connection between the two devices that are speaking. And with TCP, if we do drop a segment, then that segment can be retransmitted to help prevent our data from being corrupted. So let's consider how a TCP connection gets set up. It's going to use a process called the three-way handshake, and then we'll see how data is exchanged. First, though, let's consider this three-way handshake. Let's say that the laptop on the screen on the left wants to talk to the server on the screen, which is on the right. In order to do that using TCP, it's going to set up a TCP connection beginning with a synchronisation message. It's going to send what we call a "send packet over" to the server; syn is short for "synchronization." The synchronisation message is saying, Hey, I'd like to set up a conversation with you. And if the server is willing to do that, the server is going to say, well, I want to be able to talk to you too. So the server needs to send its own synchronisation or send message, and it needs to acknowledge the send message sent from the laptop. So the server has a couple of things to send back, a synchronisation or a sin-sing, and I want to talk to you too. And the act was the acknowledgement, saying, "Yes, I acknowledged that I received a synchronisation message from you." And then the third part of this three-way handshake is for that laptop to acknowledge the packet that it got from the server.

That is the three-way handshake that gets a TCP connection set up. Now, let's say that the laptop is going to start sending data over to the server. Now, since TCP is at layer four, remember that the protocol data unit, what we call data at layer four, is a segment. So we're going to send a single segment over to the server. The server gets it, and it's going to acknowledge on the laptop that it received it. So it will send an "act," an "acknowledgement" back saying, "Okay, I'm ready for segment number two." Now, when the laptop gets that, it says, "Well, that segment made it.

All right. Instead of just sitting here waiting for a reply to come back from the server, what if I sent two segments at a time? So I'm going to send segments two and three over to the server, and if the server gets those, it will acknowledge them and say, "I'm ready for segment number four, and we're going to double it again." We say, well, that worked. Instead of sending a window size of two segments, I'm going to double it again. I'm going to send four segments. I'm going to send segments four, five, six, and seven, and you guessed it, the server is going to acknowledge that, saying, "I'm ready for segment number eight." But if something were to happen, or let's say segmentsix got dropped, the server would say, "Acknowledge six." That would tell the laptop that it needed to send segment number six. And when the laptop got that, it would say, "Whoa, I must be sending it too aggressively." Something got dropped. so it can reduce its window size. But the window size otherwise is going to keep doubling each time. It's going to go from one segment to two, four, eight, one, six, thirty two, and so on. And that's a look at some really common protocols that we find at the network and the transport layers: IP and ICMP. at the network layer or the Internet layer if we're using the TCP/IP model. And then up at the transport layer, we had UDP and TCP.

5. 1.4 IP, UDP, and TCP Headers

When we send data across the network, that data gets encapsulated inside various headers. For example, at layer four, we might have TCP or UDP. At layer three, we probably have IP. At layer two, we could have a variety of things. We could have a point-to-point protocol; we could have Ethernet. But in this video, we're going to take a look at the headers we're going to have at layers three and four. And then later in the course, we'll take a look at a layer-two header, specifically an Ethernet header. But let's consider how this works. We have data coming down from layers seven, six, and five.

And then layer four, the transport layer, encapsulates that data, typically using TCP or UDP. Layer three will then encapsulate that segment using IP, typically IP version four or IP version six. And in this video, we're going to consider IPV 4, IPV 6, TCP, and UDP headers. And coming up in a later video, we'll take a look at the pieces and parts that make up an Ethernet header. But in this video, let's consider our layer three and four headers, starting at layer four with a TCP header. And here, for your reference, I have this broken down to its different pieces and parts. And we're going to start off with the source and the destination ports. These are 16-bit fields, and we know that a source port is a port that a client, as an example, is going to select as the return port as it sends traffic off to a destination. Let's say I want to go to a website. Well, I'm going to pick a high port number, maybe it's 50,000. That's my ephemeral port number or my dynamic port number. I've kind of randomly picked that. So there's a path to get back to me. However, I'm going to a web server.

Maybe it's a secure web server that's going to be on TCP port four, four, three. Well, that's going to be the destination port in that case. So the source port comes from the sender. The destination port goes to the other party. And remember, with TCP, we have that three-way handshake. We send a sin and syn synchronisation message to the other side, saying, "Hey, I'd love to set up a conversation with you." Recognize that by performing an act, they are sending a sin of their own by saying, "I want to talk to you too." And then we acknowledge that. That's the three-way handshake. Part one is the sin, part two is the synagogue, and part three is the act. And then we start sending chunks of data, and I send a chunk of data to the destination. It sends me an act requesting the next sequence number. That's the next chunk of data that it wants to receive.

This sequence number is going to be a 32-bit field. And if the send flag is a one, then this sequence number is going to be the first sequence number. Or if it's not set to one, then the sequence number is going to be the accumulated sequence number. whatever we're up to right now. Where, by the way, is that sin, that syn flag? Notice the flag field. That's one of the nine different flags that we might have in that flag field. The acknowledgement number is an act. That's a 32-bit field, and it says there's a next sequence number that we should send the recipient. They might acknowledge the data we just sent and say, "I'm ready for sequence number seven." So we would send that. And that's if the act flag is set to one and that act is the acknowledgement flag. It is also one of the nine flags inside that flag field. The data offset is a four-bit field and it says, "How big is this TCP header?" And the unit of measure here is the number of 32-bit words that we have.

And if we don't have any options, then that value is going to typically be five. We're going to use 532-bit words. But if we do have a bunch of options that we'll talk about in a moment, then the maximum value of that data offset could be 15. Now, the next field is a three-bit field, and currently it's all zeros. It's reserved for future use. I don't know if it'll ever get used or not, but right now it's reserved, and therefore it should always be the three bits in that field. And we've been talking about that flag field. There are actually nine 1-bit flags in this field in this video. We don't need to dive into each one of those nine flags, but I gave you a couple of examples already. The synchronisation message will be indicated by a send flag set to one, and the acknowledgement will be indicated by an act flag set to one. We're going to talk about urgent data in a moment.

There's a flag saying this is urgent data. That's a URG flag. And we know that TCP can grow its window size. It can expand the amount of data it can send before expecting an acknowledgment. That chunk of data that it can send without expecting an acknowledgement is called the window size, and that's specified as a 16-bit field for error checking. We have a checksum. This is a 16-bit field, and it's going to do error checking for both the header and the payload. And I mentioned that urgent flag earlier. Well, there's an urgent pointer field, and this is only going to be populated if that ERG flag is set to one. This is a 16-bit field indicating that this is the last urgent database contained in this segment. and we talked about the options earlier. If I don't have any of the TCP options, then the size of the options field is obviously going to be zero bits, but we could have several options to give more information inside of that TCP header, and it could go all the way up to 320 bits. Now, this is a TCP header. We say that this is a connection-oriented, reliable transport protocol. The reason we say it's reliable is that when I send data to the far side, the far side is going to send me an acknowledgment saying I'm ready for this sequence number that's sent in the acknowledgement number field. So if they're asking for this particular sequence number, I know they got the previous sequence numbers. We don't have that with a UDP header. With a UDP header, we don't have sequence numbers, we don't have acknowledgements, and we don't have sent messages. It's a much smaller header, which makes it more efficient for things like voice and video latency-sensitive traffic.

We still need to have a source and a destination port, just as we did with the TCP header. And when you're memorising those different protocols and what port numbers they use, remember we talked about how they might be using TCP ports, UDP ports, or maybe both. There's a length field to say what the combined length of this header and the data that's being encapsulated is. And, as we also surprised too many people, we have a check sum. And the reason I say some people are surprised by this is that we so often talk about UDP being an unreliable protocol, and suddenly we're doing error checking. We have a checksum. What's going on? Well, we say UDP is unreliable, not because it's not checking the header and the data for errors, which it can with this checksum, but because of its lack of those sequence numbers and acknowledgements.

So if data gets dropped, we won't know it. We don't know that the other side gets it, because they never send us an acknowledgment asking for the next sequence number. That's why it's unreliable, not because we don't do error checking. Having said that, we don't always do error checking.This checksum field is optional with IP version 4, but it's a requirement for IP version 6. Those are the two most popular protocols at the transport layer, TCP and UDP. Let's move down to the network layer now and talk about IP headers, both IP version four and IP version six. First, let's consider the IP version four header. The first piece of the IP version 4 header is a four-bit field that indicates which version of IP is being used. And, as you might expect from an IP version 4 header, this value is always a 4. The next field is a four-bit field called the Internet header length.

And this is how big this header is. And the unit of measure again is the number of 32-bit words in the header. if we don't have any options, much like we talked about with TCP. If we don't have any options, the value here is going to be five, but it could be all the way up to 15 of those 32-bit words if we have lots of options. Next up is the toss bite or the type of service field. This is used for quality of service. We've got eight bits in a byte, and we can use the three left-most bits in this byte to indicate the priority of a packet. If we use the three leftmost bits, we've got values in the range of zero to seven, and that's called IP precedents. We don't use IP precedence much any longer. Instead, we use something called differentiated services code point). That's going to give us 64 possible priority markings that we can use on this packet in the range of zero to 63.

That's going to use the six leftmost bits of the toss byte. What about the other two bits? Bits seven and eight in that toss-bites meal? Well, those can be used as ECN bits. explicit congestion notification bits. That's going to allow a receiver to politely ask the sender to slow down if it's sending data too aggressively, rather than forcing the sender to be less aggressive. In other words, to use a smaller window size. Instead of forcing the sender to do that by dropping traffic, we're just going to ask, "Hey, could you slow down a little bit?" That's what ECN does for us. Next up is the total length, and this is the size of the entire packet of invitations. It's a 16-bit field. We then have an identification field. This is a 16-bit field that can be used when we've taken a big chunk of data and fragmented it into different packets because it's too big to send inside of a single packet. In order to keep this traffic together and identified as being part of the big piece of data that we broke up, we tagged those fragments in the original datagram with the same identification. Next up is the flags field, and we've only got three bits here. And this is used for fragmentation. We can have a DF (do not fragment) bit set. So if a packet comes in to a router interface and the packet size exceeds the interface's maximum transmission unit, it's MTU. If that DF flag or bit is set, we're not going to fragment it.

Instead, we're going to have to drop that packet. Or we could say, "Yes, if I'm too big, fragment me—break me up into smaller pieces and reassemble me later." That's what we're doing with the flag field. The fragment offset says with a 13-bit field that this fragment that's contained in this packet goes where it goes in this original datagram before we did the fragmentation, so we can put all the fragments back together to form that original datagram. Next, we have a TTL field, a time delivery field, and we love the TTL field because we don't have this with layer two switches, and as a result, with a layer to switch, we might have a loop frame that just circulates forever at layer two. We don't have that at Layer Three, thanks to this field. This field says that every time this packet goes through a router, we're going to decrement this value by one until it reaches zero. So let's say my packet has a TTL of eight and it goes through a router hop. Well, now it has a TTL of seven. It goes through another router. It goes down to six and then 54321. And when it hits zero, it's timed out. It's going to be dropped at that point, and that's going to prevent this endlessly circulating loop of packets flowing through a network. Next up is the eight-bit protocol field that says, "What kind of data are we carrying inside of this packet?" We then have a checksum to check the integrity of the header.

That's a 16-bit field, and IP version four addresses are 32-bits in size, and we need to say from whence this packet came, what is the source IP address, and where's it going? What is the destination IP address? These addresses are frequently searched for when performing a packet capture and diagnosing a problem on the network. We might want to look at traffic coming from a specific IP address going to a specific IP address, so we can actually filter based on these addresses sometimes in our packet capture software. And finally, we have options because options are optional. In fact, usually, you will not have IP version 4 options. and if you don't, then that IHL size for the internet header lent is going to have a value of five. It's going to be a 532-bit word notice on screen. I've got five rows above the options row, and each of those rows are 32 bits in length.

So we have 532-bit words even if we don't have any options. If we do have options, then yeah, it can be bigger than five. And finally, in this video, let's consider an IP version six header. It's a much simpler header than IP version four, but the addresses are quite large. The version you can probably guess is that it's going to be a four-bit field saying what version this is. and it's version six. The traffic CLI spy is the IP version six version of the type of service byte discovered in an IP version four packet. Again, we've got eight bits. We can use the six left-most bits for the DSCP value and bits seven and eight for the explicit congestion notification value or the ECN value, which, if both values are set to a one in bits seven and eight, can ask the centre to slow down. In other words, to voluntarily reduce its window size.

Next, we have the flow label. And if we're streaming data, we can say all these packets that are tagged with this flow label all belong to the same stream. The payload length is a 16-bit field, and it says how many bytes are contained inside of this payload. The next header says, All right, we're encapsulating something in this IP version six header. What is the next header you're going to see if you decapsulate this IP version six header? And because IP version six is happening at layer three, normally when you decapsulate it, it's going to be encapsulating some sort of layer four header, which is probably going to be TCP or UDP. And the hop limit is the IPV-6 equivalent of the TTL field in IP version 4.

We have an eight-bit field, and we decrement the value in this field every time we go through a router until we get to zero, at which point that IP version six packet is going to be timed out, and we still have source and destination IP addresses. Of course, this time they're going to be IP versionsix addresses, and they take up a lot more space. They're 128 bits in length. They are four times as big as an IP Version 4 address. And that's a good thing because we have pretty much run out of IP version 4 addresses today. You cannot go to your country's numbering authority and say, "Hey, can you give me a block of IP addresses?" I'd like a Class C address block for IP version four. They're out. There are none to give you. However, we will never, at least in our lifetimes, run out of IP version six addresses. And that's a look at the headers that we're likely to run into at layers three and four. At layer three, we're probably going to be seeing IP version four or IP version six headers. And at layer four, we're probably going to be seeing TCP or UDP headers.

Hide