WEBVTT 00:00:01.040 --> 00:00:06.520 Let's take a look at the lower layers of the OSI stack. So far, 00:00:06.530 --> 00:00:10.090 we've talked about things like application, 00:00:10.090 --> 00:00:14.440 presentation, and session, but now we're going to actually change 00:00:14.440 --> 00:00:18.180 direction a bit and look at how do we actually format the 00:00:18.180 --> 00:00:21.150 communication to go across that physical media? 00:00:21.750 --> 00:00:24.520 The first layer of this is the transport layer. 00:00:25.570 --> 00:00:28.570 There are two main protocols, or you could call them 00:00:28.570 --> 00:00:32.090 languages, that we use at the transport layer, 00:00:32.350 --> 00:00:34.510 TCP and UDP. 00:00:35.220 --> 00:00:38.530 And depending on whether or not it's TCP or UDP, 00:00:38.540 --> 00:00:41.080 we may call our communications to this point, 00:00:41.080 --> 00:00:43.010 either a packet or a stream. 00:00:43.750 --> 00:00:47.870 So, now, the transport layer worries about making sure the 00:00:47.870 --> 00:00:51.060 traffic gets all the way to the destination, 00:00:51.190 --> 00:00:53.690 especially if it's TCP, for example. 00:00:53.840 --> 00:00:58.610 So we put on a transport header to make sure that hopefully that traffic 00:00:58.610 --> 00:01:02.170 does get there, and an acknowledgement can come back. 00:01:02.690 --> 00:01:06.580 If we looked at how TCP sets up a communication, 00:01:06.780 --> 00:01:10.960 let's say we have two devices, Host A and Host B. 00:01:12.030 --> 00:01:19.000 Host A wants to send traffic to Host B, so it sends what we call a SYN, that is 00:01:19.000 --> 00:01:25.290 to synchronize a request, basically it's like saying hello, and a random number, 00:01:25.290 --> 00:01:34.210 in this case I chose 3200. Host B gets that traffic, that SYN request from Host 00:01:34.210 --> 00:01:40.210 A, and being very polite, it acknowledges that and sends back traffic and 00:01:40.220 --> 00:01:46.940 increments that random number up to 3201. But it then also sends its own SYN 00:01:46.940 --> 00:01:55.260 packet with a random number, in this case I chose 4800. Host A responds back to 00:01:55.260 --> 00:02:02.140 that request for a SYN from Host B by acknowledging that it received that SYN 00:02:02.140 --> 00:02:03.000 request. 00:02:03.660 --> 00:02:08.009 This is the same as we all do as people. We see a 00:02:08.009 --> 00:02:10.000 friend, we say, hi how are you? 00:02:10.639 --> 00:02:14.390 That friend replies back, oh, good, thanks, and you? 00:02:14.390 --> 00:02:17.650 To which we reply, yeah, fine. 00:02:18.250 --> 00:02:23.430 What did we do? We proved that we can both send and receive to each 00:02:23.430 --> 00:02:28.960 other, and that is called, therefore, a three‑way handshake. Now 00:02:28.960 --> 00:02:33.430 that that communication session has been set up, the data can be 00:02:33.430 --> 00:02:38.250 sent back and forth, and we then see the same as when a person is 00:02:38.250 --> 00:02:39.350 talking on the phone. 00:02:39.680 --> 00:02:45.520 Mm‑hmm, yeah, okay, yeah, okay, mm‑hmm. We acknowledge continuously that 00:02:45.520 --> 00:02:49.530 we're hearing what the other person is saying so that they know we're still 00:02:49.530 --> 00:02:55.550 there and didn't just get disconnected or drop off. Eventually, we run out of 00:02:55.550 --> 00:03:02.960 things to say, so either side can send a FIN packet, I'm finished, with then 00:03:02.960 --> 00:03:09.700 the number, in this case I chose 3890. Host B gets that and acknowledges, 00:03:09.700 --> 00:03:16.480 yeah, okay, yeah, I see you're done. But, host B will then later, when it's 00:03:16.480 --> 00:03:21.780 processed its data correctly, will send its own FIN packet because it doesn't 00:03:21.780 --> 00:03:26.480 want Host A to leave until it's sure it's got everything organized and 00:03:26.480 --> 00:03:31.420 structured properly. So then it sends its own FIN packet and resends that 00:03:31.420 --> 00:03:36.470 acknowledgment, to which Host A acknowledges, yeah, I got your FIN, and we do 00:03:36.470 --> 00:03:42.090 what's called a graceful close, we shut down this communication. So we can 00:03:42.090 --> 00:03:45.240 see that TCP is a very well‑mannered, 00:03:45.240 --> 00:03:52.190 very structured type of communications. When we move down to the network 00:03:52.190 --> 00:03:56.090 layer, this is really the heartbeat of communications. 00:03:56.090 --> 00:04:01.510 This is where most of the work happens. At the network layer, we 00:04:01.510 --> 00:04:04.200 have a number of protocols we use all the time, 00:04:04.220 --> 00:04:08.960 the most common being Internet Protocol, IP, but others, 00:04:08.960 --> 00:04:13.460 such as ICMP and IGMP for, for example, 00:04:13.460 --> 00:04:19.839 group broadcasts. When we communicate using IP, there's two 00:04:19.839 --> 00:04:23.150 different versions we're using today. 00:04:23.760 --> 00:04:25.420 Internet protocol v4. 00:04:26.520 --> 00:04:33.250 Internet Protocol v4 has a 32‑bit IP address. Well, to actually tell 00:04:33.250 --> 00:04:38.960 somebody your address is 10101100 and so on, is kind of monotonous 00:04:38.960 --> 00:04:41.130 and probably prone to a lot of errors. 00:04:41.490 --> 00:04:45.790 So instead, we break it into octets, so we would call it 00:04:45.790 --> 00:04:55.050 172.16.254.2, each of those 8‑bit pieces we say what its 00:04:55.050 --> 00:04:57.900 number would be in a decimal notation. 00:04:58.540 --> 00:05:03.300 The problem with IPv4 is that we've kind of run out of IPv4 00:05:03.300 --> 00:05:08.980 addresses, and IPv4 was built for communication, 00:05:08.980 --> 00:05:13.960 not for security. It's very easy to spoof, alter, or even 00:05:13.960 --> 00:05:20.680 lose traffic on IPv4. A person can alter to make traffic look 00:05:20.680 --> 00:05:22.460 like it came from somebody else. 00:05:22.920 --> 00:05:27.290 That's because it was built for a very fast and functional process. 00:05:28.670 --> 00:05:34.430 So, a number of years ago, the late 90s, they developed IPv6. 00:05:34.880 --> 00:05:43.130 IPv6 was developed to address many of the shortfalls in IPv4. It 00:05:43.140 --> 00:05:49.560 greatly expanded the size of the IP address to 128 bits, 00:05:49.790 --> 00:05:53.240 which is a phenomenally huge number. 00:05:53.640 --> 00:05:58.670 It means, basically, the number of IP addresses available is 2 to the 00:05:58.670 --> 00:06:04.000 power of 128, and remember, every time you add 1 bit, you actually 00:06:04.000 --> 00:06:07.720 double the number of possible IP addresses. 00:06:08.170 --> 00:06:15.580 So, if I went from a 32‑bit address, such as IPv4, to a 33, that would 00:06:15.580 --> 00:06:21.870 already be twice the size of today's IPv4 address space. 00:06:21.910 --> 00:06:25.580 We've gone to 128, which is massive. 00:06:25.600 --> 00:06:27.790 Whenever I'm going to send traffic, 00:06:27.790 --> 00:06:31.510 I put on a header. We talked about headers before, and we 00:06:31.510 --> 00:06:36.110 show you what the IPv6 header would look like. You see at the 00:06:36.110 --> 00:06:39.800 top will be the version number, it would show 6 in there, 00:06:40.310 --> 00:06:45.010 the traffic class, the flow label, and the load of the pay length, 00:06:45.240 --> 00:06:48.820 the location of the next header, and the hop limit, or as we 00:06:48.820 --> 00:06:53.870 used to call it in IPv4, the time to live, so that when a 00:06:53.880 --> 00:06:56.710 packet gets lost on the internet, 00:06:56.870 --> 00:07:01.190 it doesn't just sail forever looking for a home. Once it's 00:07:01.190 --> 00:07:06.900 basically used up its book of tickets, and every time it moves 00:07:06.900 --> 00:07:11.730 from one router to another, it has to use one of those tickets, 00:07:11.740 --> 00:07:14.710 and by the time it's gone, say 30 spaces, 00:07:14.900 --> 00:07:17.790 then it'll actually just be dropped, it ran out of 00:07:17.790 --> 00:07:19.990 money to continue riding the internet. 00:07:20.450 --> 00:07:24.790 And that has saved us from the problem of having billions of lost and 00:07:24.790 --> 00:07:30.290 lonely IP packets continuously looking for a place to go. And then there 00:07:30.290 --> 00:07:34.990 would be the 128‑bit address of the person sending the traffic and 00:07:35.060 --> 00:07:38.930 the128‑bit address of the person receiving it. 00:07:39.880 --> 00:07:45.070 One of the things that was done with IPv6 was to develop Internet 00:07:45.070 --> 00:07:50.680 Protocol Security, or IPsec, and this was to address the weaknesses of 00:07:50.680 --> 00:07:58.660 IPv4 of spoofing and alteration of packets. At the data link layer, we 00:07:58.660 --> 00:08:03.270 prepare things to go over the physical media, whether that physical media 00:08:03.270 --> 00:08:08.060 is copper or wireless, and this is where we can use a protocol such as 00:08:08.060 --> 00:08:09.470 point‑to‑point protocol, 00:08:09.610 --> 00:08:13.310 something we used to use when we had dial‑up modems, for example, though 00:08:13.310 --> 00:08:17.840 there are still many tens of thousands of modems in use today, in fact. 00:08:18.950 --> 00:08:21.650 Here, we see a number of different protocols, 00:08:21.660 --> 00:08:26.310 the ones related to wireless communications, such as Wired Equivalent Privacy, 00:08:26.840 --> 00:08:32.340 Wi‑Fi‑Protected Access, and then Wi‑Fi‑Protected Access 2 and 3, and 00:08:32.340 --> 00:08:35.280 of course, Hardware types of encryption as well. 00:08:35.799 --> 00:08:41.580 When I encrypt the data that I'm sending at the data link level, I 00:08:41.580 --> 00:08:46.090 encrypt everything except that data link header that says, what's 00:08:46.090 --> 00:08:49.330 the next destination across the network? 00:08:50.320 --> 00:08:54.420 We said that the physical layer is how we actually connect devices together, 00:08:54.430 --> 00:08:59.410 whether it's wired, wireless, or fiber, for example.