So to make this more real, next I'm going to go through some specific examples of encapsulation so you can see how it actually works in practice. I'm going to start off by showing you some Ethernet headers. Here, we have some real Ethernet headers. If you look up the RFCs and the specifications, these are the formats that you're going to find. You see a bunch of headers here. You can see there's destination. MAC address, source MAC address, and you can see some other stuff too. So there's actually three different kinds of headers here. The first one is plain old vanilla Ethernet. It's basic Ethernet as it was defined in the original specification. The next one down, you can see there's additional header inserted there. There's an 802.1q header. So this is VLAN-enabled Ethernet as defined by the IEEE specification 802.1q. Then we see tags stacking in the last one. We see a header with multiple 802.1q tags. This is for extended VLANs. We did this because we don't want to just have 4,096 VLANs the specification with 802.1AD allows for many more VLANs because we can stack these tags. So the Ethernet header has a set of fields. There's a set of fields for the source destination MAC address. There is a field for the Preamble. This is a 56-bit pattern used to synchronize clocks end to end. Because we're operating directly atop layer one we need to do this. There's also a protocol ID. This is set to 8100 to signify that this is a VLAN-enabled frame for the VLAN packets. For traditional Ethernet, you set to 8100, you set to whatever is contained in the data. Also, no free to show on queue. You also have another Ether type, that's a little bit further in the package that define what is actually in the data packet, and the data part of the packet. There is another set of fields contained in the 802.1q header. There's a priority control point which defines the priority of this packet. So you can mark your Ethernet packets as being really important. Like voice traffic or video traffic. Stuff you don't want to drop because that's a real-time connection or, you can mark them as not so important. Like background traffic if you're doing a big transfer. If you need to drop some packets that's okay because you can re-transmit. That's not real-time. There's a DEI field which indicates if the frame can be dropped during congestion. There's a VLAN identifier which knows the VLAN ID and so on. So you see what we do is, we take our data and Ethernet and we encapsulate it with a series of headers that's used to process it at the Ethernet layer. At layer two. You're not going to see anything in this header about IP functions like IP destinations or how do you process at layer three because this is the layer two header. That stuff is contained in the IP header which I'll talk about next. So Ethernet is a layer two protocol and that's a protocol that's used to provide point-to-point transport in local area networks. Now, in the early days of the internet that was enough. People would build their own local area networks and things worked fine. Then, what started happening is, these networks started plugging together and we had problems. Because one guy would have one layer two protocol, this was before Ethernet really took over, as someone else would have another layer two protocol. One guy would be doing wireless, someone else would be doing optical and they weren't plugged together. So what the founders of the internet decided to do which is clever was, they said, "We're just going to have another layer. We're going to solve this by having another layer on top. It's going to be called the Internet Protocol, and we have to have translations for all these layer two protocols into IP, but, that's fine. It will just handle this through encapsulation. There's all these layer two protocols, it will take our data, it will encapsulate it into layer three packet, input that over layer two." Later on they added layers four and so on. So IPV4 header looks like this. There's a set of fields. IP was designed a long time ago. It was developed back in the 70's. Back then, a set of design decisions were made which really made sense at the time. But, nowadays they make a little bit less sense because the internet has evolved and changed. So in practice, some of these fields I'm going to point out are used, they're widely used. But, there's also some fields that aren't used so much anymore. I'll tell you why as I go through this. The first field is the version number, and it's pretty smart that they put this in because this allowed for evolution of IP. They realized early on that we're going to have the Internet Protocol, but we might want to change it later. We might want to have new versions of IP. So let's make that very first set of bits define the version number. So then it's very easy for Router to take a packet and very quickly figure out, this is version four, I should process it this way or, this is version six, I should process it this other way. So they made IP extensible or evolutionary by having this version number in there. Another thing they did is, they decided that, unlike Ethernet, the header can be variable size. This has been a little bit controversial. Because having variable size headers is great in some ways because you can make IP do all cool stuff. If you look at the IP header in detail, and I'll talk about this in a little bit, you can have all sorts of functions embedded in. You can stick in extra commands and things like that which is pretty neat. But, the downside is it makes it harder to build Router hardware to process that because it's not like you're reading in a fixed set of bits into some buffer and then processing it right away. You have to read this header length field first, figure out how long the header is, then next round go in and index into each of the fields. So IP was not designed to be processed by high-speed hardware which made a lot of sense back in the 70's when it was developed. Companies weren't building high-speed hardware for that. But, that's how that was designed. There's also something called the "DHCP, " which is a deserve marking. This is for quality-of-service priority. What this field does is it denotes how important the IP packet is. You can mark it as being high priority or low priority. It was smart to put this in. This gives a way to allow you to build networks where you can give certain packets higher-priority or lower priority. But the problem is, it's not very secure. There's nothing stopping users from saying, "Yeah, all my packets are high priority, let's tell them all to have high bits." So what happened is, operators just stopped using this field. They tend to scrub it at their boundaries because they don't want people injecting packets in. So DHCP tends to be used within network sometimes, but it's not used across networks. It's not transitive. When you build networks, you should be careful to scrub DHCP bits because otherwise other providers could fool you and make their traffic traverse with a higher priority over your network. There's also something called the ECN field. What this is used is for routers to have a way to tell users that they're getting congested. This was a problem in the Internet, because people are sending data, and they are sending data and they're overloading routers. In the early Internet, there wasn't any way to kind of get feed back and to slow it down, and so what routers would do is they get overloaded and they just drop packets. But inter-hosts didn't really know what that meant. Is like you text somebody and they don't respond and you wonder what does that mean. It'd be nice if they told you, "I'm busy right now." Or, "I'm mad at you," but they're not doing that. That's kind of what routers would do in the internet, is you send them a bunch of packets and they get lost and it's not clear was the router overloaded or was that inter-host on the other side dropping packets or do they just not want to respond or what's going? So that's the idea behind this field, was to give routers way to communicate and let inter-host know that they're overloaded and that the host should slow down so it doesn't overload it. Unfortunately, there wasn't really an incentive for router vendors to really implement this functionality. Because, if you think about it, why would a vendor implement support for this? There's inter-host. The inter-host don't react to it anyway. So a vendor could go out and start implementing this function get it deployed, but there's no host that support it. Similarly, Apple and Microsoft aren't going to have like suddenly support this function, because there's no routers that support it. You need everybody to sit down and agree that we should support this function before can be used. But achieving consensus across a large number of parties is actually a really hard problem as we see with IPV6. So maybe someday EC, will get used, but that's unclear at this point. There's also a Total Length Field which denotes the total length of the IP Header plus the user data. So, you know how long the entire packet is? Then there's a set of fields which are associated with fragmentation. So this is another annoying thing about IP. In the early days of the Internet, there are these different Layer two networks. They had different maximum transmission sizes that they can support. There'd be a Layer two network and it would be, I'm a wireless network. I can only support Little tiny packets, and then there'll be optical networks that could support huge packets. So, you're an inter host and you're sitting there and you're trying to decide, how big of a packet should I send into the network? Well, you don't know, because you don't know the Layer two technologies used at each hop. So the designers of IP, had to deal with this. They had to figure out some way to allow hosts to send packets that might be too big. So, they could have said, "We're just going to define a minimum size you have to support for packets in Layer twos. But, that would force Layer two providers to change their designs". So they said, "okay, we'll make it so IP packets can be fragmented". So you can send a packet that's too big into the internet, and intermediate routers have the right to chop it up into pieces, and send those pieces to the destination where there'll be reassembled. This introduces a bunch of complexity, unfortunately. Now you need fields for denoting the fragment offset of the packet, which fragment is it, some flags to denote how it's been fragmented, whether there's more fragments coming along or maybe you don't want it to be fragmented, the routers just drop it, there's the fragment number. So this complicates the protocol. But it was one solution to the problem. There's also field for the Checksum. A checksum is like a arithmetic computation over the packet to determine if any bits get flipped or if the packet gets corrupted. A checksum is like the addition of all the bits basically in the packet. So you can add up all the bits some of them and put them in this field. So that way, if there's corruption of the packet, some of the ones get changed to zeros, you might detect it with the checksum, because it checksum will match the contents of the packet. When routers forward packets, they check the checksum against the packet and if it's corrupted, they drop the packet. There's also the source and destination IP address. Then there's a set of options that are supported. This is another thing that was really controversial about IP over the years, is that IP supports all of these different functions. I know if you've ever kind of worked with somebody where they, you're working on a project and there's something you need to get done, certain objective you have to meet and they have all these ideas like it wouldn't be cool if we did this or this and they have all these ideas about other things they could add in, but you need to get the project done within a certain period of time. So you say, "Okay, well, we can do those a stretch goals or whatever". That can happen with IP, where there's a set of core functions that they needed. Then there are all these other ideas about cool things they could do in the protocol. So they decided to keep those and put those in as options. So there's all sorts of weird stuff that IP can do. You can do source routing with IP. You can say, okay, here's a data packet when it tried to traverse this router, and this router, and this router, you can tell it how to be routed and there's even loose source route. So you can say, write it however you want but definitely goes through this Way-point and this Way-point. There's ways to Quick-start connections, you can ramp-up speeds faster. You can send special alerts from routers, there's a huge list of these IP options. Router vendors got this huge list, and they're like well, we could implement support for all these, but do people really need these things? So, they stop supporting a lot of them. Another thing is a lot of these options had security issues, because routers would implement them in software. So if a packet came in with an option, it would bump it up to the CPU as opposed to being processing and processed in hardware. So that would slow things down and you can denial-of-service attack routers because he's just in huge numbers of packets with the options. So that was bad. A source routing routing, is something you want inter hosted to be able to source route packets because they can just say well, there's a firewall right here, will just form my packets around that firewall. So options are not widely used. They're typically disabled and good network operators should probably just scrub options before packets enter their network. Okay, so that's Options. Then there's also a protocol ID because when you get an IPv4 packet, you have to let the operating system know what to do with it. What kind of protocols on top of it. Is it TCP or UDP or SCTP? The kernel has to know which part of the networking code to call with a packet. So there is a protocol ID to identify the protocol that's on top of IP. Then there's a time to live field. So the time to live field, denotes the number of IP level hops at the Package traversed. And if the time to live field indicates the packet has to traverse too many hops, it'll drop the packet. This is a safety mechanism in case the IP packet goes in a loop over and over. If it goes for too long, it'll be dropped. Okay. So this is an overview of IPV4. So what we do, is we take data and we put an IPV4 header, and then pass that down the stack. We put that in Ethernet frame if we need to.
