Hello, and welcome back to CS615 System Administration! This is week 5, segment 3, and following our analysis of the IPv4 packet and the concept of classless inter-domain routing or CIDR subnetting, it's time to now take a look at our Big Hero IPv6, coming to rescue us from IP exhaustion. So to refresh our memory, let's --- look real quick at this illustration from a previous video, showing the structure of the IPv4 packet, where we identified the various segments based on a single TCP packet captured using tcpdump(8) while talking to the Stevens CS web server. We had called out the 32-bit source and destination addresses and looked at how a subnet mask can be used to divide the address into a network- and a host portion. So now what does this look like when using IPv6? --- For that, we'd like to repeat the previous packet capture, only this time we'll make a request to a website that has an IPv6 address. Note that you do of course need to be on an IPv6 enabled system to repeat this exercise: your home ISP may or may not offer you an IPv6 address, and your local Wifi access point may be configured to be IPv4 only. - Unfortunately, it's 2021 and Amazon _still_ does not enable IPv6 by default on all your resources, but at least since 2017, you at least _can_ actually get native IPv6 addresses in AWS and don't need to use a tunnel broker, so hooray for progress. Anyway, so if you want to ensure your new AWS instances come up with both IPv4 and IPv6 enabled -- also known as being "dualstack" -- you can follow the steps I outlined here in this blog post. With that, your instances should then get a routable IPv6 address, so we can then start our packet capture: --- Ok, so we again start out with tcpdump, this time looking for packets communicating with www.yahoo.com. We make our curl request, as before... ...and then read the first packet we captured from the file. Now the first few bytes are going to be the same, since this is on the data link layer, using the same MAC address as we did before. But then, the next field describing the type of the protocol the MAC frame wraps is no longer IP, but now the value for IPv6. The bytes starting after that and going up to about here are is the IPv6 header with the remainder as the TCP payload. Let's look at our IP addresses on the xennet0 interface and what www.yahoo.com resolves to, so we can compare that output to what we find in the tcpdump packet. Ok, there we go. --- Now let's compare to what we did for IPv4. Here's the structure of the IPv6 header, which looks similar, but a bit simpler than the IPv4 header, don't you think? Let's look at the fields. - First, we have a 4-bit version field, which --- is set to '6', no surprise. Next, - we have the Traffic Class, which, similar to in IPv4 includes the DSCP and ECN bits, all zero here. --- After that comes a 20 bit _flow label_. A "flow" is really just a group of packets that belong together, such as, say, a TCP session. By having this identifier, we can later more easily trace a full request across the network. Anyway, so this flow label is generated randomly, and --- the first 32 bits here are represented in the above 8 hex bytes. --- Next comes the payload length, 28 hex or 40 decimal since we have no additional IPv6 headers here. --- Then we specify the protocol of the payload -- TCP, in this case -- --- and add a "hop-limit", effectively the TTL we recall from the IPv4 header, with a default value of 64 just like in IPv4 as well. And that's really it. The remaining 256 bits are used for --- the source address and the --- destination address, highlighted here in the tcpdump output in hex. Ok, so now do we have to go back to the tedious task of converting these hex characters into an IP address as we did for IPv4? Take a look... --- Turns out, we don't! IPv6 addresses _are_ in hex. So we see our actual IP address here literally in the tcpdump packet, which is rather convenient. Now let's again compare to IPv4: --- As we observed in our last video, IPv4 addresses are 32-bit numbers, and as we've seen, IPv6 addresses are a bit larger. --- Specifically, IPv6 addresses are 128-bit numbers. Why we ended up with 128 bits and what problems IPv6 was intended to solve is something we'll cover in our next video, but for now let's focus merely on the structure of the address. And so having 128 bits makes for a rather unwieldy, long address. If we used the dotted decimal notation, we'd end up with 16 octets. So instead, --- we use 8 16-bit fields that we convert to hex and separate by a colon, so that our really long bit string here becomes --- this hexadecimal string. But since strings like this can still be a bit large, we have a few ways of shortening them. --- For starters, any leading zeros can be left out, but in addition --- if we have successive fields of zeros, then we can leave those out completely, but note that we can only do this once, meaning that if we had had double zeros on the left and on the right you have to decide which ones you want to compress. So for example, if you had --- an address like this, then you could _either_ compress it like this, by eliding the two left-most zero bit fields... or --- we can compress it like this, eliding the three right-most zero bit fields. But note that we can _NOT_ --- compress both sides, since now it's impossible to determine how many fields should be filled in on the left or right. - But do note that --- either of the two compressions -- right only - or left only are valid and represent the same address, - as does the uncompressed version of the string. --- Ok, so in addition to the compression of the string, there are a few additional things you want to consider when it comes to written IPv6 addresses: - Just like in IPv4, where we have 127.0.0.1 on the loopback device, we also have an IPv6 loopback address: ::1 Note that this really is not a special case at all: it's merely an address with 127 leading zero bits, translating to 7 words of all zeros, which we compressed. The bigger difference here is that the loopback device in IPv4 actually got an entire class A network, not just that one address, but we'll get back to that in a future video. - If your system is dualstack configured and your socket allows both IPv4 and IPv6 addresses, you may encounter so-called "IPv4-mapped" addresses, where the 32 bit IPv4 address in dotted decimal format is stuffed into an IPv6 address with the special prefix of all zeros, ffff. Next, although not strictly _part_ of the IP address, we have to consider how applications handle specifying a port in addition to an address. - In IPv4, we use the :port notation to specify an IP address / port pair, but since IPv6 addresses use the colon as a separator, we can't do that. For that reason, we - use a new syntax where we use brackets around the IPv6 address, followed by a colon and the port. --- Finally, we need to point out that different IPv6 addresses have different implicit _scopes_. As you may have noticed when we looked at the output of 'ifconfig', we noticed that each interface has multiple addresses. So far, that's not that unusual, as any interface can have multiple IPv4 addresses, too. But in IPv6, each interface always has a - so-called "link-local" scope address. This link-local address is - generated on the host itself without requiring any specific network knowledge or DHCP help or anything like that. It is an address within the fe80::/10 network with the low 64 bits generated using a standardized algorithm. This address - is only used on this specific link, and - any packets received or sent to or from this address are never forwarded to any other link, meaning you are guaranteed that the packets stay on the interface. Next, - we have so-called "unique local addresses" in the fc00::/7 network - which are used for private IPv6 networks and which - are not globally routed. This is conceptually similar to the - IPv4 RFC1918 IP space that you're familiar with from your local wifi network, your AWS default IPv4 space etc. Lastly, we have the - global addresses. These are the normal addresses you will see and use, such as the one we used in our examples here. They are - globally unique and - can be routed on the public internet. Now as you can see from looking at these bullet points here, we frequently talk about network space in terms of slash notation, just like we did when we talked about IPv4 CIDR subnetting, and that's one of the things where IPv6 really is not that different from IPv4: We _still_ use a bitmask called a "subnet prefix" here, and the slash notation still applies -- the only difference here is that the number after the slash can be a lot larger, since we now have 128 bits to play with. --- So it should come as no surprise that we can use similar tools to calculate and inspect the different subnet prefixes. The 'ipcalc' utility we used in our last video doesn't support IPv6, unfortunately, though, so we are using a different tool, 'sipcalc'. If we specify a /64 subnet length, then we get output like this, illustrating the expanded and compressed forms as well as the subnet prefix, the address scope and the network range, all looking rather similar to our previous IPv4 examples. If we wanted to increase our subnet, we'd use a smaller network prefix, say 48 here, and if we picked a 72 bit prefix, things would look like so. Note, however, that one of the most commonly encountered prefixes will be /64. Why that is is something we'll cover in our next video. --- Alright, so now it's your turn to look around and explore the IPv6 world around you. - Check if you get an IPv6 address, and if so whether your normal network is IPv6 enabled. This can extend to common public networks or your home network. If your home network currently doesn't support IPv6, can you change that? - What about our AWS instances? I already linked the blog post that describes how you can set up your environment to ensure your instances come up dualstack -- if you haven't done so already, please do that now, as we'll be using dualstack networking in our next videos and exercises. - Do some research and find out which popular services and systems are IPv6 enabled. You may assume that all the big players would be, but... are they? Which services are not? Why do you think that is? In our next video, then - we'll talk a bit about internet governance and discuss where IP addresses come from, how they are allocated, and why, exactly, we even _need_ IPv6 at all. 32 bits should have been enough for this little experiment called "the internet", no? Until the next time - thanks for watching! Cheers!