WEBVTT 0:00:03.100000 --> 0:00:08.220000 All right, so we've already talked about this, how to write IPv6 addresses 0:00:08.220000 --> 0:00:10.120000 so we can skip that. 0:00:10.120000 --> 0:00:15.940000 Now, just like in the world of IPv4, in IPv4, there were different categories 0:00:15.940000 --> 0:00:19.940000 or different uses for different types of addresses. 0:00:19.940000 --> 0:00:23.100000 For example, link local address. 0:00:23.100000 --> 0:00:30.740000 Now, in IPv4, the equivalent of this was something called an epipa, an 0:00:30.740000 --> 0:00:38.320000 address, which stood for automatically provisioned IP address. 0:00:38.320000 --> 0:00:44.120000 Now, in the world of IPv4, an epipa address typically started with 169 0:00:44.120000 --> 0:00:53.820000 .254.something, these were dynamically derived, but 169.254 was your epipa 0:00:53.820000 --> 0:00:58.280000 address. Now, in IPv4, when you saw that, that was a bad thing. 0:00:58.280000 --> 0:00:59.840000 You didn't want to see that. 0:00:59.840000 --> 0:01:05.740000 169.254 typically meant, hey, my device tried to do DHCP, it sent out 0:01:05.740000 --> 0:01:08.760000 as DHCP discover, and we didn't get anything back. 0:01:08.760000 --> 0:01:09.760000 We never got an offer back. 0:01:09.760000 --> 0:01:13.540000 The DHCP server is either down or unreachable or something happened. 0:01:13.540000 --> 0:01:18.380000 So instead of just giving up and not having any IP address at all, we 0:01:18.380000 --> 0:01:22.480000 automatically provisioned ourselves with an IP address starting with 169 0:01:22.480000 --> 0:01:27.900000 .254, and then we just dynamically generated the last two bytes. 0:01:27.900000 --> 0:01:34.080000 So that was a bad thing, because that is supposed to be a link local address. 0:01:34.080000 --> 0:01:39.000000 In other words, routers really should not route packets coming from or 0:01:39.000000 --> 0:01:45.020000 going to 169.254, because there's no manageability of that. 0:01:45.020000 --> 0:01:46.900000 That's not an assigned network. 0:01:46.900000 --> 0:01:50.000000 It's not like, oh, this link over here is the only link that's got 169 0:01:50.000000 --> 0:01:55.840000 .254 on it. No, 169.254 could show up anywhere in the network, because 0:01:55.840000 --> 0:01:59.300000 we don't know when hosts are going to fail DHCP and when they're going 0:01:59.300000 --> 0:02:00.320000 to be successful. 0:02:00.320000 --> 0:02:02.560000 So it's not really routable. 0:02:02.560000 --> 0:02:07.740000 So if you have a 169.254 address, the idea is, okay, maybe on your link, 0:02:07.740000 --> 0:02:10.160000 everybody in your link is having DHCP problems. 0:02:10.160000 --> 0:02:12.260000 Nobody was able to get DHCP. 0:02:12.260000 --> 0:02:16.260000 So on your link, on your VLAN, everybody ended up automatically provisioning 0:02:16.260000 --> 0:02:18.360000 themselves with 169.254. 0:02:18.360000 --> 0:02:20.340000 So at least you can talk to each other. 0:02:20.340000 --> 0:02:23.020000 You can talk on your local link with other devices, but you're not supposed 0:02:23.020000 --> 0:02:27.300000 to be able to be routed beyond your local link unless you have a legitimate 0:02:27.300000 --> 0:02:32.540000 IP network that you got via DHCP or that was statically assigned. 0:02:32.540000 --> 0:02:36.280000 So in IPV4, the APIPA address is a link local address, but it's a bad 0:02:36.280000 --> 0:02:38.180000 thing. That's something you need to troubleshoot. 0:02:38.180000 --> 0:02:41.640000 You need to figure out what happened with DHCP. 0:02:41.640000 --> 0:02:47.200000 Well, in IPV6, every network interface card, whether it be on a smartphone, 0:02:47.200000 --> 0:02:51.680000 a tablet, or a server, comes up with a link local address by default, 0:02:51.680000 --> 0:02:56.680000 it has to. So in IPV6, link local addresses are recognized as beginning 0:02:56.680000 --> 0:03:04.040000 with FE80. And so just like I described with IPV4, when a packet is created 0:03:04.040000 --> 0:03:09.340000 with a link local address as the source and or the destination, that is 0:03:09.340000 --> 0:03:14.100000 not routable. Now the router's interface itself has a link local address 0:03:14.100000 --> 0:03:18.680000 as well. So a lot of times in IPV6, you will address packets to your router 0:03:18.680000 --> 0:03:21.700000 going to his link local address. 0:03:21.700000 --> 0:03:27.840000 Like there's a lot of under the hood mechanics of how IPV6 boots up, how 0:03:27.840000 --> 0:03:32.680000 it learns of addresses, how it does like there's no ARP in IPV6 that does 0:03:32.680000 --> 0:03:37.320000 not exist, but the equivalent of ARP can use link local addresses, but 0:03:37.320000 --> 0:03:40.140000 it is not a routable address. 0:03:40.140000 --> 0:03:44.140000 I can't send a packet to you on a completely different BLAN or a completely 0:03:44.140000 --> 0:03:48.540000 different network that's across the router to your link local address. 0:03:48.540000 --> 0:03:49.620000 I just, I can't do it. 0:03:49.620000 --> 0:03:53.880000 It's only for talking devices on my own local link. 0:03:53.880000 --> 0:03:55.160000 And this is mandatory. 0:03:55.160000 --> 0:03:56.760000 It's got to be there. 0:03:56.760000 --> 0:04:01.980000 So whenever you enable IPV6 on an interface, only just demonstrate this 0:04:01.980000 --> 0:04:04.860000 here real quick. 0:04:04.860000 --> 0:04:10.400000 So not this. I don't care about that, but here. 0:04:10.400000 --> 0:04:18.780000 So for example, if I go onto my Ubuntu device, okay, and I say IF config, 0:04:18.780000 --> 0:04:25.200000 you'll see that it's already by default running IP version six, and it 0:04:25.200000 --> 0:04:27.640000 came up with a link local address for itself. 0:04:27.640000 --> 0:04:32.300000 So your Windows laptop, your Mac laptop, if you look on your NIC card, 0:04:32.300000 --> 0:04:33.660000 chances are pretty good. 0:04:33.660000 --> 0:04:35.200000 It's running IPV6. 0:04:35.200000 --> 0:04:39.160000 And even if it doesn't have a globally routable address, and we'll talk 0:04:39.160000 --> 0:04:43.680000 about that in just a second at minimum, it does have a link local address. 0:04:43.680000 --> 0:04:54.520000 Now, we'll also see that if I go onto a router, nope, don't want putty. 0:04:54.520000 --> 0:05:00.960000 You want secure CRT. 0:05:00.960000 --> 0:05:11.500000 All right. So if I go onto a router, and I go to do show IP interface 0:05:11.500000 --> 0:05:17.120000 brief, let's say I go to interface gigabit zero slash zero. 0:05:17.120000 --> 0:05:25.480000 So there's two ways a link local address can be automatically enabled 0:05:25.480000 --> 0:05:26.780000 on your interface. 0:05:26.780000 --> 0:05:31.580000 One thing you could do is you could just give yourself a real IPV6 address. 0:05:31.580000 --> 0:05:41.640000 Okay. So I've just given myself a globally routable IPV6 address. 0:05:41.640000 --> 0:05:51.320000 Now if I do show IPV6 interface brief, you'll see not only does it have 0:05:51.320000 --> 0:05:54.840000 that address I configured, it also dynamically gave itself a link local 0:05:54.840000 --> 0:05:58.800000 address. The moment it said, oh, he wants to do IPV6 here. 0:05:58.800000 --> 0:06:02.240000 It said, I need to derive a link local address for myself. 0:06:02.240000 --> 0:06:09.500000 Another way you could do it is go to an interface and just say IPV6 enable. 0:06:09.500000 --> 0:06:14.060000 This means, hey, I'm not going to give you a global address. 0:06:14.060000 --> 0:06:15.960000 I just want you to have a link local address. 0:06:15.960000 --> 0:06:20.260000 And now if we look at interface gigabit zero slash one, we see just that. 0:06:20.260000 --> 0:06:23.540000 He doesn't have any global address, but he does have a link local address 0:06:23.540000 --> 0:06:28.920000 because I did the command IPV6 enable on him. 0:06:28.920000 --> 0:06:34.920000 Global unit cast addresses. 0:06:34.920000 --> 0:06:40.080000 So technically if we think of the 128 bits, the make up our IPV6 address, 0:06:40.080000 --> 0:06:44.820000 any IPV6 address were the very first three bits going from left to right 0:06:44.820000 --> 0:06:49.460000 are this pattern right there, zero zero one, and then we don't care what 0:06:49.460000 --> 0:06:56.500000 the remaining bits are, then that is a global unit cast address. 0:06:56.500000 --> 0:07:00.220000 Technically, if we think about our first nibble as being the first four 0:07:00.220000 --> 0:07:03.540000 bits, that gives us two possible patterns, right? 0:07:03.540000 --> 0:07:08.380000 Zero zero one zero and zero zero one one, which means our very first hexadecimal 0:07:08.380000 --> 0:07:11.280000 character could be either a two or a three. 0:07:11.280000 --> 0:07:15.560000 Well, the internet assigned numbers authority has said three is reserved 0:07:15.560000 --> 0:07:18.280000 for future use. Can't use that. 0:07:18.280000 --> 0:07:22.580000 So all globally routable IPV6 addresses right now and for the foreseeable 0:07:22.580000 --> 0:07:25.980000 future are going to start with the number two. 0:07:25.980000 --> 0:07:32.640000 And like I said, most likely they will have a slash 64 as their subnet 0:07:32.640000 --> 0:07:41.620000 mask. In the world of IPV4, we had private and public networks, private 0:07:41.620000 --> 0:07:46.660000 networks were like the 10 network, the 172 16, the 192 168. 0:07:46.660000 --> 0:07:50.140000 Well in the world of IPV6, it's a lot easier. 0:07:50.140000 --> 0:07:52.000000 Anything with FC. 0:07:52.000000 --> 0:07:56.960000 FC is your private, what we now call unique local addresses. 0:07:56.960000 --> 0:08:01.580000 Also just so you know, technically FD is also private. 0:08:01.580000 --> 0:08:06.940000 If you ever see FC or FD, that is a unique local. 0:08:06.940000 --> 0:08:10.840000 Originally when they first came out, they were called site local. 0:08:10.840000 --> 0:08:14.940000 So if you're reading some older documentation, you might see that as well. 0:08:14.940000 --> 0:08:16.720000 They both mean the exact same thing. 0:08:16.720000 --> 0:08:19.120000 These are addresses that are not globally routable. 0:08:19.120000 --> 0:08:26.300000 You can't send them to the internet FC and FD. 0:08:26.300000 --> 0:08:30.620000 Multicast addresses in the world of IP version four, you had to remember 0:08:30.620000 --> 0:08:34.920000 the class D address space in the world of IP version four. 0:08:34.920000 --> 0:08:42.240000 You had to remember that multicast being class D start out with 224 dot 0:08:42.240000 --> 0:08:46.740000 anything going up to 239 dot anything. 0:08:46.740000 --> 0:08:50.300000 You had to remember that range IPV6, it's a lot simpler. 0:08:50.300000 --> 0:08:54.800000 Any address beginning with FF, that is multicast. 0:08:54.800000 --> 0:08:58.440000 FF has been reserved for multicast addresses. 0:08:58.440000 --> 0:09:07.660000 Also knows here that it says IPV6 nodes and an IPV6 node is anything running 0:09:07.660000 --> 0:09:12.540000 IPV6, smartphone, tablet, router, switch, PC, whatever. 0:09:12.540000 --> 0:09:16.960000 Listen to several IPV6 multicast groups by default and you should recognize 0:09:16.960000 --> 0:09:19.780000 these. In the next slide, I'm going to show you two very common ones. 0:09:19.780000 --> 0:09:21.800000 You should be able to recognize. 0:09:21.800000 --> 0:09:25.380000 This is the all IPV6 host address. 0:09:25.380000 --> 0:09:27.180000 Now here's an interesting thing. 0:09:27.180000 --> 0:09:32.280000 In IPV6, they said, we're not going to do broadcast anymore. 0:09:32.280000 --> 0:09:33.240000 So think about this. 0:09:33.240000 --> 0:09:40.720000 In the world of IPV4, let's say that we had a switch right here and we 0:09:40.720000 --> 0:09:43.360000 had several devices on that switch. 0:09:43.360000 --> 0:09:44.220000 Maybe here's the router. 0:09:44.220000 --> 0:09:47.120000 Here's the default gateway that everybody's going to use. 0:09:47.120000 --> 0:09:51.000000 Then we have some PCs connected to this. 0:09:51.000000 --> 0:09:55.540000 This was all in VLAN, whatever. 0:09:55.540000 --> 0:10:03.120000 Maybe VLAN 2. Let's say maybe we assign the 2.2.2.0 slash 24 subnet to 0:10:03.120000 --> 0:10:04.640000 everything that VLAN. 0:10:04.640000 --> 0:10:11.860000 Now, if this host right here wanted to send a broadcast to everybody, 0:10:11.860000 --> 0:10:18.360000 most likely what he would do is send it to this address. 0:10:18.360000 --> 0:10:24.940000 That's what we call the general broadcast address. 0:10:24.940000 --> 0:10:26.660000 You send a packet to that. 0:10:26.660000 --> 0:10:28.740000 It's supposed to go to everyone. 0:10:28.740000 --> 0:10:34.260000 Now we know in reality, everyone really means everybody on this side of 0:10:34.260000 --> 0:10:37.520000 the router, because routers do not forward broadcast. 0:10:37.520000 --> 0:10:40.760000 If I send a packet to that, it's not going to go to every conceivable 0:10:40.760000 --> 0:10:44.420000 network in my company once it gets to the router. 0:10:44.420000 --> 0:10:47.120000 The router will process it and then he'll drop it. 0:10:47.120000 --> 0:10:48.400000 It won't go any further than him. 0:10:48.400000 --> 0:10:51.300000 It's really for broadcasting on your own local network, but we call it 0:10:51.300000 --> 0:10:52.940000 the general broadcast. 0:10:52.940000 --> 0:10:58.240000 But there was also another way to send a packet to everybody on my network, 0:10:58.240000 --> 0:11:01.840000 which was what's called the directed broadcast, which means I'm going 0:11:01.840000 --> 0:11:04.380000 to send a packet to my network address. 0:11:04.380000 --> 0:11:09.160000 Then I'm just going to fill in the host bits with all ones. 0:11:09.160000 --> 0:11:14.040000 That's called the directed broadcast, where you're using the network bits 0:11:14.040000 --> 0:11:17.460000 and the host bits are all just set to once. 0:11:17.460000 --> 0:11:18.820000 That's the directed broadcast. 0:11:18.820000 --> 0:11:21.560000 It does the exact same thing as this. 0:11:21.560000 --> 0:11:25.060000 Everybody on your wire will see it, including the router. 0:11:25.060000 --> 0:11:26.560000 Now that's not as common. 0:11:26.560000 --> 0:11:32.420000 Most protocols that use broadcasts like DHCP, ARP, they use the general 0:11:32.420000 --> 0:11:35.680000 broadcast. It's probably pretty rare that you'll see anything creating 0:11:35.680000 --> 0:11:38.980000 a packet going to the directed broadcast. 0:11:38.980000 --> 0:11:41.580000 What does this have to do with IPv6? 0:11:41.580000 --> 0:11:45.000000 Well when IPv6 came out, they said, no more broadcasts. 0:11:45.000000 --> 0:11:48.480000 There's no equivalent of this in IPv6. 0:11:48.480000 --> 0:11:51.620000 Well, yes and no, because guess what? 0:11:51.620000 --> 0:11:57.320000 If I send a packet in IPv6 to this multicast address, this is the all 0:11:57.320000 --> 0:12:02.520000 IPv6 host address, which means that all IPv6 hosts have to be listening 0:12:02.520000 --> 0:12:03.780000 to it. So guess what? 0:12:03.780000 --> 0:12:05.420000 It's going to do the exact same thing. 0:12:05.420000 --> 0:12:10.060000 Every host in my VLAN, including my router, is listening automatically 0:12:10.060000 --> 0:12:11.920000 to that multicast address. 0:12:11.920000 --> 0:12:16.140000 It's the same effect as if I was sending a broadcast. 0:12:16.140000 --> 0:12:19.600000 So yeah, they got kind of tricky by saying, oh, there's no broadcast anymore. 0:12:19.600000 --> 0:12:24.620000 Well, yeah, that's true, but sending a packet to FF02 colon colon one 0:12:24.620000 --> 0:12:28.420000 for all intents and purposes, you're sending a broadcast. 0:12:28.420000 --> 0:12:31.480000 Yeah, technically we call them multicast because it starts out with FF. 0:12:31.480000 --> 0:12:36.800000 But hey, if I have a multicast that everybody's listening to, if I send 0:12:36.800000 --> 0:12:40.100000 a packet to that, it's going to get to everybody, which is kind of like 0:12:40.100000 --> 0:12:41.600000 what a broadcast does. 0:12:41.600000 --> 0:12:45.880000 And then there's another special multicast address that only routers listen 0:12:45.880000 --> 0:12:51.800000 to, which is called the all IPv6 routers address. 0:12:51.800000 --> 0:12:57.500000 So if a host like a laptop or a PC needs to discover its router, if it 0:12:57.500000 --> 0:13:01.160000 doesn't know if a router exists, it says, hey, is there a router out there? 0:13:01.160000 --> 0:13:05.060000 It'll start by sending it to this FF02 colon colon two. 0:13:05.060000 --> 0:13:08.500000 And if there's an IPV6 router on your segment, it has to be listening 0:13:08.500000 --> 0:13:14.380000 to that. And notice it says this is used with IPV6 slack. 0:13:14.380000 --> 0:13:15.700000 You need to know what that term is. 0:13:15.700000 --> 0:13:19.100000 That's the stateless automatic address configuration. 0:13:19.100000 --> 0:13:23.600000 This is something that IPV6 can do that IPV4 could not do. 0:13:23.600000 --> 0:13:28.340000 In the world of IPV4, your host, let's just say your laptop, there was 0:13:28.340000 --> 0:13:32.700000 really only two ways your laptop could get an IPV4 address. 0:13:32.700000 --> 0:13:37.160000 You could go into it, go into the control panel or system preferences, 0:13:37.160000 --> 0:13:41.160000 go to your nip card and you could statically assign an IPV4 address and 0:13:41.160000 --> 0:13:45.880000 subnet mask. Not advisable unless you're dealing with like a server, something 0:13:45.880000 --> 0:13:48.300000 that never moved that had a static address. 0:13:48.300000 --> 0:13:49.500000 But you could do that. 0:13:49.500000 --> 0:13:54.240000 The other alternative was using DHCP, right, which is what most mobile 0:13:54.240000 --> 0:13:57.460000 hosts like laptops and smartphones and tablets used. 0:13:57.460000 --> 0:13:58.720000 DHCP. That was it. 0:13:58.720000 --> 0:14:00.740000 Those were your two alternatives. 0:14:00.740000 --> 0:14:03.140000 In IPV6, you do have those two methods. 0:14:03.140000 --> 0:14:05.860000 You can statically assign an IPV6 address. 0:14:05.860000 --> 0:14:10.000000 There is DHCP version six, so you should know how that works. 0:14:10.000000 --> 0:14:13.920000 But there's a third alternative as well called stateless automatic address 0:14:13.920000 --> 0:14:17.760000 configuration. It's actually pretty cool the way it works. 0:14:17.760000 --> 0:14:20.640000 So imagine that this is my laptop here. 0:14:20.640000 --> 0:14:23.960000 He's probably connected to a switch and we'll just say the switch is a 0:14:23.960000 --> 0:14:28.080000 layer two switch for all intents and purposes and a switch is connected 0:14:28.080000 --> 0:14:31.240000 to a router. Okay. 0:14:31.240000 --> 0:14:34.660000 Well, in stateless automatic address configuration, first thing that happens 0:14:34.660000 --> 0:14:39.180000 is that host, when I bring up his nip card, let's say the host comes online, 0:14:39.180000 --> 0:14:42.380000 he's going to give himself an FE80 address, right? 0:14:42.380000 --> 0:14:45.040000 He's going to give himself a link local address. 0:14:45.040000 --> 0:14:50.000000 Then he's going to send out a special type of ICMP message. 0:14:50.000000 --> 0:14:52.680000 Remember ICMP? Most people think of that as ping. 0:14:52.680000 --> 0:15:00.620000 Well, there's ICMP before which uses IPV4 addresses and ICMP V6, which 0:15:00.620000 --> 0:15:03.080000 uses IPV6 addresses. 0:15:03.080000 --> 0:15:08.760000 Now, in ICMP V4, we had the echo request, echo response that was for ping. 0:15:08.760000 --> 0:15:11.220000 We also had ICMP redirects. 0:15:11.220000 --> 0:15:14.820000 We had ICMP host unreachable. 0:15:14.820000 --> 0:15:18.380000 We had all kinds of ICMP message types. 0:15:18.380000 --> 0:15:22.980000 Well, in ICMP V6, that still exists, right? 0:15:22.980000 --> 0:15:29.500000 IPV6 ping, you're doing ICMP V6, echo request and echo response. 0:15:29.500000 --> 0:15:34.900000 There's ICMP V6 redirects and host unreachable messages. 0:15:34.900000 --> 0:15:41.220000 And there are four new types of ICMP messages that only exist in ICMP 0:15:41.220000 --> 0:16:01.760000 V6. They are the neighbor solicitation and neighbor advertisement. 0:16:01.760000 --> 0:16:07.660000 These are the replacements for ARP. 0:16:07.660000 --> 0:16:12.760000 If I need to find, if I know that a host I'm trying to reach like my router 0:16:12.760000 --> 0:16:17.020000 is on the same network as me, the same prefix as me, and I need to discover 0:16:17.020000 --> 0:16:21.980000 his MAC address, I will send him a neighbor solicitation message. 0:16:21.980000 --> 0:16:25.620000 He will send back to me a neighbor advertisement message. 0:16:25.620000 --> 0:16:27.480000 So that's the replacement for ARP. 0:16:27.480000 --> 0:16:36.680000 And then we also have router solicitation. 0:16:36.680000 --> 0:16:41.620000 And router advertisement. 0:16:41.620000 --> 0:16:46.560000 And this is what's used in stateless automatic address configuration in 0:16:46.560000 --> 0:16:54.140000 Slack. So once I've got my link local address, I will send a router solicitation. 0:16:54.140000 --> 0:16:57.280000 And I will send it to this address. 0:16:57.280000 --> 0:16:59.660000 Because I don't know if there's a router out there or not. 0:16:59.660000 --> 0:17:03.940000 I'm assuming there is, but if there is one, I know he's listening to FF02 0:17:03.940000 --> 0:17:05.100000 colon colon two. 0:17:05.100000 --> 0:17:08.360000 So I'll send my router solicitation to him and say, hey, if there's a 0:17:08.360000 --> 0:17:13.580000 router out there, tell me about yourself and tell me what global prefix 0:17:13.580000 --> 0:17:19.000000 beginning with two is on this wire because I need an address for myself. 0:17:19.000000 --> 0:17:23.940000 The router will send back to me a router advertisement. 0:17:23.940000 --> 0:17:26.320000 And that's where he'll say, hey, let me tell you about myself. 0:17:26.320000 --> 0:17:29.200000 Let me tell you about my link local address, what I've got. 0:17:29.200000 --> 0:17:32.800000 Let me tell you about my global address. 0:17:32.800000 --> 0:17:34.160000 Whatever that is. 0:17:34.160000 --> 0:17:40.580000 Oh, and by the way, the prefix that we're using on this wire is this. 0:17:40.580000 --> 0:17:44.400000 That's the prefix we're using. 0:17:44.400000 --> 0:17:48.680000 Now that host has got a third way to learn of the prefix. 0:17:48.680000 --> 0:17:50.420000 He now knows what the global prefix is. 0:17:50.420000 --> 0:17:52.300000 He can assign that to his NIC card. 0:17:52.300000 --> 0:17:55.360000 And the remaining 64 bits is interface ID. 0:17:55.360000 --> 0:17:58.700000 He can dynamically come up with himself. 0:17:58.700000 --> 0:18:02.640000 So that's a method that has no equivalent in the world of IPV 4. 0:18:02.640000 --> 0:18:05.560000 We call this stateless automatic address configuration. 0:18:05.560000 --> 0:18:10.340000 This exchange of router solicitation and router advertisement, which allows 0:18:10.340000 --> 0:18:14.020000 hosts to dynamically configure themselves. 0:18:14.020000 --> 0:18:22.180000 Now, the reason we call this stateless is because DHCP V6 is state full. 0:18:22.180000 --> 0:18:23.460000 What do we mean by that? 0:18:23.460000 --> 0:18:27.060000 Well, just like in the world of IPV 4, if I reach out to a DHCP server 0:18:27.060000 --> 0:18:31.540000 with a discover message and he sends me an offer, once that four step 0:18:31.540000 --> 0:18:35.240000 process is done, that server knows me. 0:18:35.240000 --> 0:18:36.640000 He's got a record of me. 0:18:36.640000 --> 0:18:42.760000 He knows that he has allocated to me the IPV 4 address of 2.2.2.2.2 for 0:18:42.760000 --> 0:18:46.180000 whatever the lease is, maybe for 24 hours. 0:18:46.180000 --> 0:18:49.460000 So I could go to that DHCP server and I could see all the IP addresses 0:18:49.460000 --> 0:18:52.780000 he's assigned to everybody and how long they're good for. 0:18:52.780000 --> 0:18:55.140000 We have state information about that. 0:18:55.140000 --> 0:18:57.200000 That's called a stateful address. 0:18:57.200000 --> 0:19:02.660000 In Slack, the router has no idea, once this process happens with router 0:19:02.660000 --> 0:19:06.020000 solicitation, router advertisement, the router doesn't keep a record of 0:19:06.020000 --> 0:19:10.140000 that. He doesn't remember that he gave me that prefix. 0:19:10.140000 --> 0:19:12.680000 He doesn't know what address I've been given. 0:19:12.680000 --> 0:19:14.660000 And there's no lifetime on this. 0:19:14.660000 --> 0:19:19.000000 Once I do Slack, that addresses good for as long as I'm connected to that 0:19:19.000000 --> 0:19:22.340000 network. If I'm connected to that network for the next week, I will still 0:19:22.340000 --> 0:19:26.700000 use that address that I dynamically derived via the Slack process. 0:19:26.700000 --> 0:19:28.240000 And no one's keeping track of it. 0:19:28.240000 --> 0:19:28.880000 There's no state. 0:19:28.880000 --> 0:19:33.060000 So that's why we call it stateless address configuration or automatic 0:19:33.060000 --> 0:19:35.340000 address configuration. 0:19:35.340000 --> 0:19:38.500000 Now, what about the interface ID? 0:19:38.500000 --> 0:19:40.520000 I just got a global prefix. 0:19:40.520000 --> 0:19:42.860000 How do I dynamically come up with interface ID? 0:19:42.860000 --> 0:19:45.680000 And that brings us to our next section. 0:19:45.680000 --> 0:19:52.380000 In IPV 4, if I statically configured an IPV 4 address on my laptop, I 0:19:52.380000 --> 0:19:57.400000 had to statically type in both the prefix and the interface ID or in IPV 0:19:57.400000 --> 0:20:00.460000 4, we said the network bits and the host bits, right? 0:20:00.460000 --> 0:20:03.860000 I couldn't go into my laptop and I couldn't say, hey, your network is 0:20:03.860000 --> 0:20:08.360000 2020, figure out for yourself what the last eight bits are going to be 0:20:08.360000 --> 0:20:09.500000 for your host bits. 0:20:09.500000 --> 0:20:10.640000 That didn't work. 0:20:10.640000 --> 0:20:13.380000 If I statically configured an address on something, I had to give it the 0:20:13.380000 --> 0:20:17.500000 whole 32-bit address and then manually give it the mask so it knew where 0:20:17.500000 --> 0:20:18.780000 the dividing line was. 0:20:18.780000 --> 0:20:23.340000 I could use DHCP, but even with DHCP, what did I get from the server? 0:20:23.340000 --> 0:20:27.460000 I got the whole 32-bit address and a subnet mask. 0:20:27.460000 --> 0:20:32.520000 Well, in IPV 6, like with stateless automatic address configuration, I'm 0:20:32.520000 --> 0:20:37.000000 getting the prefix and I have to come up with myself what the last 64 0:20:37.000000 --> 0:20:39.960000 bits are of the interface ID. 0:20:39.960000 --> 0:20:44.920000 Now, originally the way that this worked was using something called EUI 0:20:44.920000 --> 0:20:51.520000 64. So EUI 64 worked this way and you definitely want to know this. 0:20:51.520000 --> 0:20:53.520000 It was based on your MAC address. 0:20:53.520000 --> 0:21:00.420000 So let's say that I figured out that my prefix was this. 0:21:00.420000 --> 0:21:08.260000 All right, that's my global prefix. 0:21:08.260000 --> 0:21:13.060000 Either I got that via DHCP, I got that via Slack, or maybe I went into 0:21:13.060000 --> 0:21:17.880000 my network interface card and I said, IPV 6 network is this, and then 0:21:17.880000 --> 0:21:21.500000 I told it EUI 64. 0:21:21.500000 --> 0:21:25.720000 All right, this is the indicator that my system needs to dynamically derive 0:21:25.720000 --> 0:21:31.880000 via the EUI 64 process, the last 64 bits of its interface ID. 0:21:31.880000 --> 0:21:33.460000 So here's how it's going to do it. 0:21:33.460000 --> 0:21:36.280000 It's going to look around and say, okay, what's my net card? 0:21:36.280000 --> 0:21:38.060000 What's the MAC address on there? 0:21:38.060000 --> 0:21:47.860000 Maybe my MAC address is 002111222. 0:21:47.860000 --> 0:21:53.200000 All right, so there's my 48-bit MAC. 0:21:53.200000 --> 0:21:58.600000 The EUI 64 process says, okay, we need to expand this to a 64-bit number 0:21:58.600000 --> 0:22:01.000000 so we can shove it into our interface ID. 0:22:01.000000 --> 0:22:01.720000 So here's what we're going to do. 0:22:01.720000 --> 0:22:04.460000 We're going to cut that MAC address right in half. 0:22:04.460000 --> 0:22:11.780000 All right, and we're going to say 002 colon 11. 0:22:11.780000 --> 0:22:13.480000 So there's the first half. 0:22:13.480000 --> 0:22:17.860000 And then we're going to have a colon right here. 0:22:17.860000 --> 0:22:22.420000 Then we're going to say 11 colon 2222. 0:22:22.420000 --> 0:22:25.800000 All right, now we're missing 16 bits. 0:22:25.800000 --> 0:22:29.700000 To expand from 48 to 64 bits, that's a difference of 16. 0:22:29.700000 --> 0:22:33.660000 So we got to shove 16 bits in the middle here to expand this. 0:22:33.660000 --> 0:22:35.020000 How do we do that? 0:22:35.020000 --> 0:22:37.920000 Well, EUI 64 says, here's what we're going to do. 0:22:37.920000 --> 0:22:42.300000 We're going to put F, F, so that's two nibbles, right? 0:22:42.300000 --> 0:22:45.880000 That's eight bits, F, E. 0:22:45.880000 --> 0:22:47.420000 There's another eight bits. 0:22:47.420000 --> 0:22:50.920000 So now we've just added a 16 -bit pattern in the middle. 0:22:50.920000 --> 0:23:02.680000 So now we've got 002 colon 11FF colon F. 0:23:02.680000 --> 0:23:05.620000 E 11 colon 2222. 0:23:05.620000 --> 0:23:07.680000 But we're not quite done yet. 0:23:07.680000 --> 0:23:08.900000 We're almost done. 0:23:08.900000 --> 0:23:13.940000 So now we've taken our 48-bit MAC address and we've expanded it to a 64 0:23:13.940000 --> 0:23:17.460000 -bit interface ID by putting this pattern of FF FE in the middle. 0:23:17.460000 --> 0:23:20.240000 Now, don't ask me, why do they choose that pattern? 0:23:20.240000 --> 0:23:23.380000 Why not A123? I have no idea. 0:23:23.380000 --> 0:23:24.520000 It is what it is. 0:23:24.520000 --> 0:23:25.900000 You just have to memorize that. 0:23:25.900000 --> 0:23:28.740000 Now, here's one other thing that's like, huh, why do they do that? 0:23:28.740000 --> 0:23:30.400000 I can't really explain it. 0:23:30.400000 --> 0:23:31.180000 I've Googled it. 0:23:31.180000 --> 0:23:34.980000 I've never found anybody who explained in plain English why they did this. 0:23:34.980000 --> 0:23:37.700000 So just another freaky little thing they did and we just have to know 0:23:37.700000 --> 0:23:40.900000 what it is. So here's what we do. 0:23:40.900000 --> 0:23:46.140000 We take our first byte, which is 000, 000, so I'm expanding it into binary 0:23:46.140000 --> 0:23:50.980000 now. 000, 000. So that's our first two zeros. 0:23:50.980000 --> 0:23:52.080000 And here's what we do. 0:23:52.080000 --> 0:23:53.040000 You're going to say, what? 0:23:53.040000 --> 0:23:54.380000 I'm going to say, oh, live with it. 0:23:54.380000 --> 0:23:55.060000 It's just the way it is. 0:23:55.060000 --> 0:23:59.140000 And now we're going to take this bit right there. 0:23:59.140000 --> 0:24:02.660000 Whatever that bit is, flip it to its opposite. 0:24:02.660000 --> 0:24:04.980000 So if it's zero, flip it to a one. 0:24:04.980000 --> 0:24:10.720000 If it was a one, flip it to a zero, which ends up giving us 000, 000, 0:24:10.720000 --> 0:24:17.860000 000, 000, 10. So now our final interface ID is not 0002. 0:24:17.860000 --> 0:24:24.480000 It ends up being 0202, 102, 11FF FE11, 222. 0:24:24.480000 --> 0:24:29.180000 Because we had to flip that bit that was in this nibble right there. 0:24:29.180000 --> 0:24:32.540000 Take a look at that nibble, flip that bit. 0:24:32.540000 --> 0:24:38.860000 And that gives us our EUI64 interface ID based on the MAC address. 0:24:38.860000 --> 0:24:49.000000 All right, and we've already talked about this, the neighbor discovery 0:24:49.000000 --> 0:24:53.260000 protocol. So I didn't actually give it this name, but I did tell you that 0:24:53.260000 --> 0:24:57.620000 with ICMP, there were four new ICMP message types. 0:24:57.620000 --> 0:24:58.920000 So we talked about those. 0:24:58.920000 --> 0:25:04.520000 Those four message types taken together as a group is what we call the 0:25:04.520000 --> 0:25:07.560000 neighbor discovery process, NDP. 0:25:07.560000 --> 0:25:11.840000 So if you ever get a question on what is comprised of the neighbor discovery 0:25:11.840000 --> 0:25:16.520000 protocol, you know, oh, those are four ICMPB six messages. 0:25:16.520000 --> 0:25:18.060000 And these are the messages right here. 0:25:18.060000 --> 0:25:21.840000 Neighbor solicitation, neighbor advertisement, that's the replacement 0:25:21.840000 --> 0:25:26.260000 for ARP. Router solicitation, router advertisement, that is brand spanking 0:25:26.260000 --> 0:25:31.860000 new. That's what we use for Slack. 0:25:31.860000 --> 0:25:40.460000 All right, and that concludes this video refresher on an intro on IPv6 0:25:40.460000 --> 0:25:43.260000 and addressing types and all that good stuff. 0:25:43.260000 --> 0:25:45.300000 I hope you found this video informative.