WEBVTT 0:00:08.280000 --> 0:00:12.960000 Now, the next piece of this is the IPV6 extension headers. 0:00:12.960000 --> 0:00:20.760000 Basically what they're doing here is, and we could go really, really long 0:00:20.760000 --> 0:00:25.400000 time into what all the currently defined extension headers are and so 0:00:25.400000 --> 0:00:28.300000 on. And I really considered putting all that in here. 0:00:28.300000 --> 0:00:30.400000 And at the end of the day, I don't think it's really going to help you 0:00:30.400000 --> 0:00:36.080000 with learning and implementing and running IPV6. 0:00:36.080000 --> 0:00:39.860000 I wanted this to be more of an implementation in a practical course rather 0:00:39.860000 --> 0:00:42.640000 than to memorize all the facts. 0:00:42.640000 --> 0:00:45.660000 Google's out there, there's tons of resources. 0:00:45.660000 --> 0:00:50.860000 If you want to look up and find what all the currently defined extension 0:00:50.860000 --> 0:00:55.520000 headers are for IPV6. 0:00:55.520000 --> 0:00:56.580000 I'll give you a couple. 0:00:56.580000 --> 0:01:00.780000 There's mobility headers, there's fragmentation headers like I talked 0:01:00.780000 --> 0:01:07.340000 about earlier. What I really wanted you to understand is the structure. 0:01:07.340000 --> 0:01:12.580000 Now as you can see over on the far right there, we're saying 40 octets 0:01:12.580000 --> 0:01:18.580000 and as I already mentioned, it becomes 40 bytes for the header now. 0:01:18.580000 --> 0:01:22.240000 So that's just showing you the original header like we saw in the previous 0:01:22.240000 --> 0:01:24.940000 slide in that top section. 0:01:24.940000 --> 0:01:30.700000 But notice here we have the next header field is pointing to extension 0:01:30.700000 --> 0:01:37.100000 header one. Now each type of extension header has its own unique identifier. 0:01:37.100000 --> 0:01:41.800000 So when it says next header is EH1, it's already going to know what type 0:01:41.800000 --> 0:01:44.160000 of extension header that is. 0:01:44.160000 --> 0:01:49.080000 And again, if you really want to get into the nuts and bolts of the protocol, 0:01:49.080000 --> 0:01:57.900000 there's FCs. These are the extension headers and this is the order they 0:01:57.900000 --> 0:01:59.960000 should be in in the packet. 0:01:59.960000 --> 0:02:02.660000 You know, all that kind of really fun nitty gritty detail. 0:02:02.660000 --> 0:02:04.140000 That's your thing. 0:02:04.140000 --> 0:02:06.140000 It's certainly stuff out there. 0:02:06.140000 --> 0:02:10.760000 If you want to know some resources, you can either email me or maybe I'll 0:02:10.760000 --> 0:02:14.220000 throw up some good documents on a slide at the end of the whole course 0:02:14.220000 --> 0:02:19.200000 here. But or maybe I'll just put a document with the course material. 0:02:19.200000 --> 0:02:23.100000 But we'll see if we can get something for you or if you can't find that 0:02:23.100000 --> 0:02:26.840000 anywhere, feel free to just go back to the first video, grab my email 0:02:26.840000 --> 0:02:31.560000 and email me. But again, I don't think it's the end of the day that's 0:02:31.560000 --> 0:02:35.780000 really going to help you for most of what you need to do with IPV6. 0:02:35.780000 --> 0:02:39.960000 We're going to focus on the more practical stuff, at least that's my plan. 0:02:39.960000 --> 0:02:42.540000 So but I wanted you to understand how it works. 0:02:42.540000 --> 0:02:46.360000 So the main header points to extension header one. 0:02:46.360000 --> 0:02:50.400000 Extension header one also has a next header field. 0:02:50.400000 --> 0:02:54.920000 So every extension header has a next header field. 0:02:54.920000 --> 0:02:59.620000 And as you can see in there, in this example here, it's pointing to EH2, 0:02:59.620000 --> 0:03:04.240000 extension header two, that points to extension header three, and then 0:03:04.240000 --> 0:03:09.180000 extension header three ultimately points to the upper layer protocol, 0:03:09.180000 --> 0:03:14.260000 which would be your UDP, your TCP, your OSPF, your EIGRP, whatever the 0:03:14.260000 --> 0:03:18.860000 typical layer four header would be. 0:03:18.860000 --> 0:03:24.180000 Okay. So if there's no extension headers at all, then of course the next 0:03:24.180000 --> 0:03:31.880000 header in the main overall IPV6 header would point directly to the upper 0:03:31.880000 --> 0:03:34.420000 layer header. Okay. 0:03:34.420000 --> 0:03:37.640000 The whole point of the extension headers was basically this. 0:03:37.640000 --> 0:03:39.740000 And yes, some have been defined. 0:03:39.740000 --> 0:03:45.140000 Like I said, you can look them up and you can look at what order they're 0:03:45.140000 --> 0:03:47.060000 supposed to be in and all that fun stuff. 0:03:47.060000 --> 0:03:48.880000 So some of them have already been done. 0:03:48.880000 --> 0:03:55.660000 Yes. But the main idea, the main goal was to give IPV6 a little bit of 0:03:55.660000 --> 0:04:00.340000 future proof. You know, I think when they were designing IPV6 and you 0:04:00.340000 --> 0:04:03.060000 know, they didn't invite me to the committee or anything. 0:04:03.060000 --> 0:04:06.240000 But I mean, they should have, but they didn't. 0:04:06.240000 --> 0:04:07.080000 No, I'm just kidding. 0:04:07.080000 --> 0:04:09.760000 But in any case, the point is this. 0:04:09.760000 --> 0:04:14.400000 When they were developing this, I think they've already, you know, nobody 0:04:14.400000 --> 0:04:17.620000 that works on this stuff and most people who work in this field, you know, 0:04:17.620000 --> 0:04:19.600000 we're generally not stupid. 0:04:19.600000 --> 0:04:24.480000 So they look at this and say, this is going to be a big hassle. 0:04:24.480000 --> 0:04:30.900000 Just flat out. Moving from IPV4 to IPV6, no matter how you cut it with 0:04:30.900000 --> 0:04:35.640000 the internet the way it is and everything going on, this is major. 0:04:35.640000 --> 0:04:39.100000 This is not, you know, and I've heard people say this in the past and 0:04:39.100000 --> 0:04:42.760000 I just laugh, you know, oh, they're going to pick a date and they're just 0:04:42.760000 --> 0:04:44.460000 going to switch the internet over. 0:04:44.460000 --> 0:04:46.780000 Yeah, because that's how it works. 0:04:46.780000 --> 0:04:50.300000 Not, you know, no, not happening. 0:04:50.300000 --> 0:04:53.340000 Like I said, we're going to run dual stack. 0:04:53.340000 --> 0:04:57.820000 We're going to be running IPV4 right next to IPV6 for a really, really, 0:04:57.820000 --> 0:05:01.140000 really long time. 0:05:01.140000 --> 0:05:02.000000 I'm not going to like this. 0:05:02.000000 --> 0:05:04.060000 I'm not going to take estimates. 0:05:04.060000 --> 0:05:08.340000 I'm guessing probably for the rest of my career, maybe yours, I think 0:05:08.340000 --> 0:05:10.040000 it's going to be a long time. 0:05:10.040000 --> 0:05:12.020000 But nonetheless. 0:05:12.020000 --> 0:05:15.940000 The fact of the matter is they looked at all of this and they said, you 0:05:15.940000 --> 0:05:17.740000 know what, I don't think we want to do this. 0:05:17.740000 --> 0:05:21.380000 I don't think we want IPV7 or whatever we're going to call it. 0:05:21.380000 --> 0:05:24.980000 I don't think we want that anytime real soon. 0:05:24.980000 --> 0:05:28.680000 I think once in all of our lifetimes is going to be enough for this. 0:05:28.680000 --> 0:05:35.520000 So what they did, and I think, at least I hope wisely, so is they sort 0:05:35.520000 --> 0:05:43.440000 of looked at our best to future proof this. 0:05:43.440000 --> 0:05:46.820000 Let's look back at what happened with IPV4. 0:05:46.820000 --> 0:05:49.120000 Let's try to learn from history. 0:05:49.120000 --> 0:05:52.080000 Let's try not to make the same mistakes. 0:05:52.080000 --> 0:05:55.820000 From what I understand, and again, I wasn't there, but from what I understand, 0:05:55.820000 --> 0:05:58.800000 there was a lot of discussion of going to 64-bit addresses. 0:05:58.800000 --> 0:06:01.880000 And you know, somebody said, you know what, how about let's just not? 0:06:01.880000 --> 0:06:04.720000 Let's just go right to 128. 0:06:04.720000 --> 0:06:08.560000 And if this was all being developed today on more modern equipment with 0:06:08.560000 --> 0:06:12.300000 better CPUs, I don't know, today maybe they'd even say let's go to a 256 0:06:12.300000 --> 0:06:14.300000 -bit address. I don't know. 0:06:14.300000 --> 0:06:18.660000 Some of its CPU, some of it is at the end of the day we are still humans 0:06:18.660000 --> 0:06:22.280000 and we need to be able to type these addresses in places. 0:06:22.280000 --> 0:06:27.260000 So regardless, they tried to future proof it. 0:06:27.260000 --> 0:06:29.260000 As best as you can see what's coming. 0:06:29.260000 --> 0:06:33.260000 I mean, something had happened tomorrow that none of us see coming. 0:06:33.260000 --> 0:06:38.900000 And that's why, again, I won't be one of the people who says, oh yeah, 0:06:38.900000 --> 0:06:42.020000 this is a business that has way more address based than you'll ever need. 0:06:42.020000 --> 0:06:43.400000 You won't hear me say that. 0:06:43.400000 --> 0:06:47.920000 No way. Because who knows what's out there tomorrow, right? 0:06:47.920000 --> 0:06:50.200000 So I'm not going to say that. 0:06:50.200000 --> 0:06:55.000000 But in the interest of doing the best they could, they created these extension 0:06:55.000000 --> 0:07:01.900000 headers. And the idea is if tomorrow some technology comes along that 0:07:01.900000 --> 0:07:07.520000 needs a new header, it needs a new way to tell the other side something. 0:07:07.520000 --> 0:07:12.780000 Well, all we have to do is redefine a new extension header. 0:07:12.780000 --> 0:07:17.360000 Okay, extension header 37 is going to be for this new thing. 0:07:17.360000 --> 0:07:18.760000 Whatever that is. 0:07:18.760000 --> 0:07:24.500000 Now, will all of us have to update all of our code and newer versions 0:07:24.500000 --> 0:07:28.260000 of operating systems and so on to support and understand what that new 0:07:28.260000 --> 0:07:29.780000 extension header means? 0:07:29.780000 --> 0:07:31.080000 Well, of course. 0:07:31.080000 --> 0:07:33.960000 You know, we're not going to magically know what new extension headers 0:07:33.960000 --> 0:07:36.280000 are that nobody's ever heard of before. 0:07:36.280000 --> 0:07:41.460000 But the important point is we're not rewriting the entire protocol. 0:07:41.460000 --> 0:07:43.020000 We're not redesigning everything. 0:07:43.020000 --> 0:07:44.080000 We're not changing everything. 0:07:44.080000 --> 0:07:48.020000 We're not having to come out with IPv7 just to support some new thing 0:07:48.020000 --> 0:07:51.380000 that comes out. At least we hope not. 0:07:51.380000 --> 0:07:55.220000 Okay. Again, it seems like a really sound idea. 0:07:55.220000 --> 0:07:57.800000 Only time will tell if it's actually enough. 0:07:57.800000 --> 0:07:59.280000 You know, who knows? 0:07:59.280000 --> 0:08:02.120000 Maybe whatever is coming out tomorrow next week, next month, next year 0:08:02.120000 --> 0:08:06.820000 says, you know, what the extension headers aren't enough. 0:08:06.820000 --> 0:08:09.120000 Now, we're getting into a whole bunch of philosophical discussions. 0:08:09.120000 --> 0:08:11.280000 So let's just move on. 0:08:11.280000 --> 0:08:13.560000 The RFC for this, by the way, is 2460. 0:08:13.560000 --> 0:08:16.640000 I want to put it on there for you so you can look this up and see what's 0:08:16.640000 --> 0:08:18.220000 been defined and so on.