Computer Networking Full Course | Wireshark, Firewalls & Cyber Security (7 Hours)

0:01In this lesson, we're going to be

0:02talking about what you should expect.

0:04Well, this is a course on TCP IP. So, of

0:07course, we're going to be talking about

0:09TCP IP. We're going to be covering the

0:12protocols in the TCP IP suite. So, we'll

0:15be talking about TCP, UDP, IP, ARP,

0:19RARP, and a lot of application layer

0:22protocols. We're going to be talking

0:24about these protocols in a fair amount

0:26of depth. and we're going to be looking

0:28at them at the protocol level, not at

0:31kind of a highlevel overview where we

0:33discuss what the protocols do. We're

0:35actually going to be looking at the

0:36protocols and how all of the pieces fit

0:39together. We're going to be doing this

0:41in a very hands-on way. And we're going

0:44to be using Wireshark, which is a packet

0:46capture utility, which gives us the

0:49ability to look at the messages that are

0:52actually going out on the wire. So we

0:54can really see in very great detail

0:58what's actually happening and how all of

1:00the protocols are put together and the

1:03information that's actually put into the

1:05various headers that fill up these

1:08protocols and we'll see how they

1:11actually work and operate in a real time

1:15real life setting. As I said earlier,

1:17we'll be talking at protocol level,

1:20meaning we'll be investigating these

1:22protocols, the way they actually operate

1:25and the methods that gets used and the

1:28headers that are actually there. We're

1:30not going to be talking about this from

1:32a slideware perspective where we're just

1:35talking about a higher level view of how

1:39the protocols work and what they're

1:41expected to do. We're actually going to

1:43be looking at the protocols in detail.

1:46We're going to be looking at some

1:47configuration specifics and as I said

1:50earlier, we're going to be looking at

1:51wire level data. We're not going to be

1:54creating things on a piece of paper and

1:57talking about it. We're actually going

1:59to capture live packets and investigate

2:02those. In short, we're going to be

2:05looking at some detailed level

2:08information of the TCP IP suite and the

2:12various protocols that are associated

2:14with it. And we're going to be looking

2:16at live data in most cases so that we

2:19can actually see how it operates. And

2:22that's pretty much what you can expect

2:24from this course.

2:28In this lesson, we're going to be

2:29talking about what you should know. So,

2:31this is kind of the prerequisites, the

2:33things that you should be at least

2:35familiar with before going into all of

2:38the detail that's in this course. From

2:40an operating systems perspective, it

2:43doesn't really much matter what

2:44operating system your preferred platform

2:46is, whether it's Windows or Linux or Mac

2:49OS or maybe something else. The thing is

2:52that TCP IP actually works on a large

2:54number of operating systems. We're going

2:57to be talking about things that you can

2:59actually engage with on pretty much any

3:02operating system. Certainly the major

3:04operating systems like the ones I

3:06mentioned just a minute ago, Windows and

3:09Linux and Mac OS. The different

3:11utilities that we'll be using work under

3:14these operating systems. We'll be

3:17talking about some networking concepts

3:20and it's helpful to understand just the

3:22basics before we get there. not going to

3:25be going into detail about what network

3:28interface cards look like, what cabling

3:30looks like. We'll be referring to those

3:32in kind of a generic sense for the most

3:34part. It's helpful to understand what

3:37those are and kind of how they work and

3:39how they fit together. You don't need to

3:41know a great number of details about

3:44these things, but just understanding

3:46that there's cabling and network

3:48interface cards, and that's how your

3:50computer connects to the network. And in

3:53some cases, you may have a wireless

3:56card. Understanding that that wireless

3:58card uses radio transmissions to connect

4:01to the network and that's how data gets

4:04transmitted. Just understanding that at

4:06a pretty basic level is going to be

4:08helpful as we go through these sets of

4:11videos. So, we'll be using a number of

4:14applications. I'll be walking you

4:17through different utilities and programs

4:19that we can actually use to get into

4:22some detail about the protocols that

4:24we're going to be talking about. But

4:26having just a basic grasp of

4:29applications that use the internet like

4:32your web browser or your email client,

4:35that's really helpful because at least

4:37then you understand how your

4:40applications interact with the network

4:42and how the network has some impact on

4:45the applications that you use. Other

4:48than that though, there's really not an

4:50awful lot to know going into this. We're

4:54going to be talking about TCP IP pretty

4:56much from the bottom up so you can

4:58understand all of the different layers

5:01and how they interoperate with one

5:03another and all of the protocols that

5:05get used for these different

5:07applications. For example, how your web

5:10browser uses HTTP and the different

5:13protocols that HTTP itself relies on.

5:17But just having some general sense of

5:20what networking is and some of the

5:22fundamental concepts of how things get

5:25plugged together and connected is really

5:28kind of helpful as we move forward.

5:32In this lesson, we're going to be

5:33talking about what you will learn. So,

5:36this should be your set of expectations

5:38in terms of the level of information

5:41that you'll be getting as you go through

5:43this set of videos and lessons. We'll be

5:46talking about a lot of different

5:48protocols. Of course, we'll be talking

5:50about the foundation protocols for the

5:53TCP IP suite. We'll be talking about

5:55internet protocol, which is IP. We'll be

5:58talking about the transmission control

6:00protocol, which is TCP. We'll be talking

6:02about the user datagramgram protocol,

6:04the address resolution protocol. We'll

6:07be talking about those as just

6:09foundational fundamental protocols for

6:13how everything else works and how it

6:15goes together. We'll be looking at these

6:18in a great amount of detail. looking at

6:21the bit level in most cases. So, we can

6:24actually see how the different header

6:28fields for these different protocols

6:30actually work and how they interact with

6:33different protocols and how systems

6:36interact with one another using the

6:38different pieces of information in these

6:40header fields. We'll be talking about

6:43application layer protocols as well. So

6:46simple mail transport protocol,

6:48hypertext transport protocol, post

6:50office protocol. Those are email and web

6:53protocols. We'll be looking at those and

6:57how they actually work at the protocol

7:00level. We're not going to be talking

7:02about so here's an email client and

7:05here's how you create an email and how

7:07it gets sent. will actually be looking

7:10at how you would send an email at the

7:13protocol level and the underlying

7:16protocols that work underneath something

7:19like the simple mail transport protocol.

7:22We'll be looking at a number of

7:23utilities. We'll be looking at

7:25Wireshark, which is a way that we

7:27capture packets. We'll be looking at

7:29ping, which is a way to do some network

7:32diagnostics. We'll be looking at a

7:35utility like Netstat, which does network

7:38statistics. As I've said previously,

7:41these different utilities for the most

7:43part work on just about any platform or

7:46operating system you may be running

7:48across. There may be some slight

7:51variations in some case. For example,

7:53we'll be looking at if config. There's a

7:56variation of it for Windows called IP

7:59config. But for the most part, these

8:01foundational utilities like ping and

8:04netstat, for example, run across any

8:07operating system that actually uses TCP

8:10IP for networking. These utilities are

8:13really critical to making a TCP IP

8:16implementation functional and useful.

8:19They're the way that we interact with

8:21the network. They're the way that we

8:23gather information about how the TCP IP

8:27layers are working, how your system is

8:29connected to the internet, whether it's

8:31connected to the internet. We're going

8:33to be using all of these utilities that

8:35I've just mentioned and explaining how

8:38they actually work and operate and the

8:41information that you can get from them.

8:46In this lesson, we're going to be

8:47talking about the history of TCP IP. And

8:50you can't talk about the history of

8:52TCPIP without talking about the history

8:55of the internet or certainly what we

8:58call the internet now. Now back in 1969,

9:02the internet was actually a very small

9:05network that was developed at the

9:08request of the advanced research

9:11projects agency or ARPA and it was

9:14called the ARPANET at that point. So

9:17back in 1967

9:19there was some design discussions that

9:21were held and eventually a company

9:25called Bolt Bannic and Newman in

9:27Massachusetts was contracted by ARPA to

9:32build what was going to be called the

9:34ARPANET.

9:36So the idea was it was going to be used

9:39as a research network to look into the

9:43feasibility of using computer networks

9:46in order to primarily facilitate defense

9:51operations.

9:52In 1969 we get the first node and we can

9:56take a look at a diagram here of the

10:00first hookup here. So we've got the

10:03interface message processor or IMP which

10:06was an early router or the very first

10:08router if you want to call it that and

10:11the first host was a sigma 7 system.

10:15Now eventually by December of 1969 we

10:19end up with a four node arponet and you

10:22can see we've got SRRI, Utah, UCLA and

10:27UCSB. So we've got four nodes on the

10:31internet. The early network protocols

10:35that were used was actually something

10:37called NCP. So we have this host

10:41software and early on it wasn't actually

10:44TCP IP, it was NCP. Arponet hosts start

10:49using network control protocol. The

10:51first host to host protocol. In 1972 we

10:55get the first email which is kind of

10:56interesting. Ray Tomlinson at BBN starts

11:00to send email and that's when the first

11:05at sign was used. But in 1974

11:09is where we actually get to where the

11:12very first specification for TCP is

11:16published. You'll note I only said TCP.

11:20I didn't say TCP IP. At that point there

11:23was no internet protocol. TCP was the

11:27entire protocol and TCP took the

11:30functions that now the IP portion or the

11:34internet protocol portion actually had.

11:36Through the 1970s, TCP kept growing and

11:42in 1978 you can see here TCP was split

11:45into TCP and IP. So they determined that

11:50for better modularity they needed a

11:53whole different protocol. So they

11:54created the internet protocol in 1978.

11:59At that point they were still using NCP

12:02primarily on the ARPANET. In 1981

12:07actually you can see RFC 801 here the

12:10NCP TCP transition plan. So there was

12:14actually a plan to transition between

12:17NCP or the network control protocol and

12:20TCP which is the transmission control

12:23protocol or TCP IP. It wasn't until the

12:26early8s that TCPIP

12:30became the predominant networking

12:33protocol on what was then still a

12:36fledgling internet. It was still called

12:37the Arpanet. And in the early8s there

12:40were several networks that were being

12:42created. In 1981 for example there was

12:46Bitnet and that was a network primarily

12:49of IBM mainframes. There was the

12:52computer science network and there were

12:55several other networks that were being

12:58created around the world. Now eventually

13:01by the mid 80s TCPI IP was the

13:05predominant and de facto networking

13:09protocol on the internet. And it wasn't

13:13actually until the late 1980s that we

13:16really got the internet that we have

13:18today. And that was through the creation

13:21of the NSFnet which would have been in

13:251986.

13:26So the NSF net was created and that had

13:29a faster backbone speed 56k and it was

13:33really kind of an evolutionary process

13:36where all of the networks were folded in

13:39together and we created one large

13:42internet and that was really kind of the

13:44late 1980s early 1990s when that

13:47happened. But by that point, TCP IP had

13:51become the de facto standard on the

13:54internet. And it's really the use of the

13:57sight-to-sight communication and the end

14:00to end communication requirements that

14:03really drove the adoption worldwide of

14:06TCP IP. And that's why we predominantly

14:10use TCP IP on our desktops today rather

14:14than for example the novel IPXSPX suite.

14:18So that's just a brief history of TCP

14:22IP.

14:25In this lesson, we're going to be

14:26talking about using TCP IP. Now, this

14:29one kind of goes without saying perhaps

14:32because it's something that you do every

14:34day. Anytime you connect to the

14:36internet, you're using TCPIP, whether

14:39you realize it or not. Every piece of

14:41communication that goes across the

14:43internet is using the TCP IP protocol

14:47suite or suite of protocols. If I were

14:50to, for example, go to google.com, what

14:54I'm doing is I am issuing a series of

14:58TCP requests in order to get all of the

15:01content on this page to get it back to

15:04me. So, this entire process of just

15:09bringing up Google requires several

15:12pieces of communication that use TCP and

15:16IP. And again, I'm issuing a series of

15:19TCP IP requests or TCP requests. And

15:23we'll eventually get into discussing how

15:26all of these different protocols

15:29interconnect together because it's

15:30really a series of protocols that make

15:33this happen. So what I'm doing here is

15:37I'm actually issuing an HTTP request

15:40that gets encapsulated inside TCP that

15:43gets encapsulated inside of IP that is

15:46then encapsulated inside of Ethernet and

15:49then sent across the wire or in this

15:53particular case it's actually being sent

15:55wirelessly until it hits another

15:58networking device and gets sent out to a

16:01network provider. So there's a series of

16:04protocols here that allow all of this

16:07communication to happen. So I can do

16:10some simple troubleshooting for example

16:13and again this is using TCP IP. So I can

16:18do this program called ping which tells

16:20me that the website infiniteskills.com

16:24is actually up. In this case, I'm using

16:27a protocol called ICMP. And ICMP then

16:31gets encapsulated inside of IP. And

16:34again, we'll talk about encapsulation in

16:37another lesson, but here's another

16:39example of using TCP IP or the protocols

16:43in the TCP IP suite. I could use SSH

16:48which allows me to connect to a remote

16:51system and that again is using TCP IP.

16:56I can bring up my mail program and in

17:00this case I'm using Apple Mail and Apple

17:04Mail is going to use TCP IP as well if I

17:09were to stream music across the internet

17:13for example. So, I can bring up iTunes

17:16and I could bring up the iTunes store.

17:18And this is actually issuing the HTTP

17:22requests that I was mentioning

17:23previously.

17:26And if I were to just grab something,

17:29for example, lay Miss Rob. And if I were

17:34to just stream a little music here,

17:39that again is using the TCP IP protocol

17:42suite. So, anything that you do on the

17:45internet, whether you realize it or not,

17:48is using TCP IP, whether you're gaming,

17:51you're playing Minecraft, for example,

17:54or you're playing Code of Conduct, or

17:57you're playing Halo on your Xbox, as an

18:01example, and you're playing with people

18:03around the world. That again is all

18:05using TCP IP. So just simply knowing how

18:10all of these processes work and how they

18:13interoperate with one another makes

18:15working with networks and

18:17troubleshooting them and understanding

18:19when things are working and when things

18:20aren't working so much easier. So that's

18:24just using TCP IP and again the various

18:28applications that make use of TCP IP.

18:34In this lesson, we're going to be

18:36talking about the OSI model. What's the

18:38OSI model? Well, you can see here a

18:41diagram of the OSI model, which doesn't

18:44really describe what the OSI model is,

18:47but we'll be referring to this diagram

18:49as we go on, and I'll be flipping back

18:52and forth to this. So, what is the OSI

18:55model? OSI stands for open systems

18:58interconnection and it's a seven layer

19:00model that describes an architecture for

19:04communication. It's a standard

19:06communication architecture and it's

19:09really modular which you would expect

19:11from a layered approach. As I said it's

19:13a seven layer model. It was created in

19:15the 1970s as an architecture for

19:18distributed database systems. So you can

19:21see that there are seven layers here and

19:24this model really originated as part of

19:28work that was being done to create this

19:31standard communication architecture in

19:34the 1970s. They were learning from the

19:37work at ARPA around ARPANET and the

19:40creation of the TCP IP protocol suite

19:44and the birth that was happening in the

19:461970s around that and IBM's system

19:49network architecture or SNA.

19:51Observations from those two activities

19:54really went into the creation of this

19:57OSI model. Now the OSI model is protocol

20:00agnostic. It's not tied to one specific

20:02protocol or set of protocols. As a

20:05result, it's pretty easy to lay

20:08different protocols and different

20:09protocol suites on top of the model or

20:11at least fit them into the model. We'll

20:14be going through some of that as we go

20:16forward here. Let me show you the model

20:18again. We're starting from the bottom.

20:20The physical layer is really all about

20:23the physical definitions, not

20:25surprisingly. So, we're talking about

20:27connection types, coax, four pair,

20:29fiber, etc. The physical layer handles

20:32error correction and detection on the

20:35physical medium. So we've got these

20:37things called collisions. When a message

20:41goes out on the wire and somebody else

20:43sends something at the same time, the

20:45two electrical signals are trying to

20:47cross the wire at the same moment and we

20:50end up with this collision and of course

20:52we end up with basically garbage and the

20:56signal would be completely

20:57unintelligible. The physical layer is

21:00responsible for doing error correction

21:03and detection on the physical medium.

21:06Now the data link layer is responsible

21:09for doing the translation from the

21:11digital data to physical signals. So

21:14it's got to do these frames in order to

21:18make sure that the messages are able to

21:22be sent across the physical medium. So

21:26it frames the messages out in a way that

21:29can be transmitted based on what the

21:31physical medium happens to be whether

21:33it's fiber or whether it's coax or

21:36whether it's four pair wire. It also has

21:39physical addressing. So there's an

21:41address that's associated with the data

21:43link layer and we'll talk about that in

21:46subsequent lessons. But what we're

21:48talking about there is the media access

21:50control address or MAC address. Now, it

21:53also handles flow control and access

21:55control and those collisions that I

21:58mentioned before. It's got to be able to

22:00recover from those. So, it uses this

22:03mechanism sometimes called CSMA CD or

22:07carrier sense multiple access collision

22:09detection. Now, that's what Ethernet

22:11uses. So, it senses that there is a

22:14collision and then does the

22:17retransmission based on a random holdoff

22:20timer. So, if the holdoff timer wasn't

22:23random, you'd get people trying to send

22:26messages, getting a collision, backing

22:29off, and then both people trying to

22:30resend at the same time. And of course,

22:32you're going to end up with a collision

22:33again. So, we have this random back off

22:36timer or holdoff timer before people

22:38retransmit after a collision. Now,

22:41different protocols use different ways

22:44of handling this. For example, Apple

22:46talk uses CSMACA or carrier sense

22:49multiple access collision avoidance. So

22:52rather than detecting collisions, they

22:55have mechanisms in the protocol to

22:57actually avoid collisions. Now the

22:59network layer, and we're up to layer

23:01three here. The network layer is

23:03actually responsible for getting

23:05messages back and forth across different

23:09networks. I've got multiple networks

23:11that I'm connecting to and I need to

23:14make sure that I get my messages from my

23:17local network to another network that I

23:20may be connected to somehow. It handles

23:23getting data from one network to

23:24another. And by that I really mean it

23:27does routing. In addition to routing, it

23:30also does some repackaging of the data

23:33because we may have different physical

23:36connections on the other side and

23:38different layer 2 technologies. So the

23:40layer 3 has to kind of bridge that gap

23:44between those two different types of

23:46technologies. So layer 3 is there to get

23:49messages from one network to another

23:51network. As a result of that, we need

23:53another address for that. So we need a

23:55logical address to ensure that we can

23:58get messages from one network to another

24:01network reliably. So we have a logical

24:04address at the network layer. And in

24:07this case, if we go back to the model

24:09diagram, you'll see IP is actually at

24:12the network layer. So IP and the IP

24:16address actually sits at layer 3 at the

24:19network layer. At layer four, we've got

24:21the transport layer. That's where TCP

24:24and UDP actually sit. And the transport

24:28layer handles end to end reliable data

24:30service. In the case of TCP IP, it

24:33handles ports to differentiate traffic.

24:36UDP and TCP both have this concept of

24:39ports. So in addition to an IP address,

24:41you would communicate to a port and that

24:44handles the differentiation between

24:47applications. So every application is

24:50going to have to have a port that it

24:53needs to communicate either with or on

24:56as it's sending messages. So that's how

24:59we handle different communication

25:02streams across the same wire. We have

25:05these layer 4 protocols that have

25:07different ports. So TCP and UDP both

25:10examples of transport layer protocols.

25:14Now we have a session layer on top of

25:16that. That's layer five that controls

25:18specific dialogues between two systems.

25:21So layer five, not surprisingly, does

25:23session management. This one's a little

25:25bit more abstract than lower layers. And

25:27sometimes there's disagreement over

25:29which protocols actually land here in

25:32session 5 because sometimes there's

25:34actually overlap between functionality.

25:37So typically protocols like SSL and TLS

25:41as well as SSH would land in the session

25:44layer. There's also protocols like net

25:47bios for example that typically gets

25:50dumped into the session layer because it

25:52manages the communication between two

25:54systems and there actually is a session

25:56that gets set up as systems are

25:59exchanging files back and forth. Now we

26:01have the presentation layer. It manages

26:03how data is presented. So XML and JPEG

26:06for example would sit in the

26:08presentation layer. Finally, at layer 7,

26:12let me flip back to the OSI model. And

26:15here we have the seven layers here.

26:18HTTP, FTP, SMTP. These are the

26:21application layer protocols. These are

26:24the things that sit the closest to the

26:27user. They do all management of

26:30connections. They handle error control

26:33if they need to. They handle session

26:35establishment. All of those sorts of

26:38things, those get done at the

26:40application layer. And these are things

26:43like web access, email, file transfers,

26:47all of that stuff has some component

26:49that sits at the application layer. So,

26:53one thing I want to point out here is

26:55it's layer to layer. And this may

26:57perhaps seem like it should go without

26:59saying, but it's important to mention

27:01this. One layer speaks to another layer.

27:03So each layer adds a header which

27:06encapsulates the data that came before

27:08it. And each layer is responsible for

27:10peeling that header off when it gets the

27:12data on the other end. Let's go back to

27:14the model here. And we've got for

27:17example a web request. So that web

27:21request is going to originate in the

27:23application layer. And then it's going

27:24to go down to the presentation layer and

27:27session layer. If there's anything that

27:28needs to be done there, for example, if

27:31there's a TLS connection, maybe you

27:33could say that goes through the session

27:35layer, then eventually we're going to

27:36have to add ports to it. So, I have to

27:39add a source port and a destination

27:41port. And the destination port's

27:43probably going to be port 80. Then I add

27:46the IP address at the network layer, and

27:48I add an Ethernet header probably on top

27:50of it, and I send it off. So it goes

27:52through the network and then when it

27:54gets to the other end we actually repeat

27:57the process in reverse. So it comes in

27:59on the physical layer and the data link

28:02header gets pulled off by the data link

28:05layer on the receiving end. The network

28:08header gets pulled off by the network

28:10layer on the receiving end. The

28:12transport layer gets pulled off by the

28:14transport layer on the receiving end.

28:16It's not really an earthshattering

28:19revelation to suggest that the different

28:22layers handle the same data whether

28:25they're on the sending end or the

28:27receiving end. The point though is that

28:29it's really encapsulated. The data gets

28:31all encapsulated and it's really a

28:33series of headers that get extracted on

28:36the receiving end as the data makes its

28:39way back up the stack. In conclusion,

28:42there are seven layers to the OSI model.

28:45That's the physical data link, network,

28:47transport, session, presentation, and

28:50application. And of course, this is all

28:52layertolayer communication. You would

28:55never have layer 2 on one side

28:57communicating with layer three on

28:58another side. That's just not the way it

29:00works. So, it's layertolayer

29:02communication.

29:05In this lesson, we're going to be going

29:07over the TCP IP model. So, here is the

29:10TCP IP model. Now the TCP IP model looks

29:13kind of stripped down by comparison to

29:15the OSI model and there are reasons for

29:18that and we'll talk a little bit more

29:20about that in a second. So in 1989 RFC

29:241122 was published. RFC 1122 is a

29:28request for comment that specifies an

29:31architectural model for communications

29:33between internet hosts. Now, it's

29:35important to note here that this is some

29:389 years give or take after the adoption

29:41of the OSI model by the ISO. So, we've

29:46got the OSI model in place, but TCPIP

29:49has become the standard protocol across

29:53what was slowly becoming what we now

29:56think of as the internet today. So we've

29:58got this TCP IP networking stack or

30:02networking suite of protocols and in

30:051989 they published this architectural

30:08model. When we talk about OSI we talk

30:11about layer 1, layer 2, layer 3 up to

30:14layer 7. When we're talking about the

30:15TCP IP model, the layers were only

30:18referred to by name. There was no

30:19numbering that was actually referenced.

30:21So the IETF manages the architecture and

30:24documentation and it's been updated

30:26several times since the original

30:28publication with RFC122.

30:32So we've got the network access layer

30:34and if you were kind of thinking about

30:36the OSI model in your head, we're going

30:38to flip back here to the TCP IP model

30:41and we've got the network access layer

30:43at the bottom. And what that really is

30:46is the data link layer and the physical

30:50layer of the OSI model. So it handles

30:52the physical connection. It handles

30:54error correction and control on the

30:56physical medium. It specifies how

30:58messages are translated onto the

31:00physical medium, whether it's electrical

31:02signals or optical and what that looks

31:05like and what the framing is going to

31:06look like. What we've really got here is

31:09the physical layer and the data link

31:11layer from the OSI models really wrapped

31:13up in this network access layer. And the

31:16TCP IP model is a little bit more

31:19compact in that regard. Rather than

31:21separating the two out because they're

31:22so closely tied together, they just

31:24created the network access layer. Now

31:27we've got the internet layer. This is

31:29the same as the network layer in the OSI

31:32model. IP and ICMP were intended for

31:34this layer. This is really where the

31:37robustness principle is really in play

31:39here. You'll hear the robustness

31:41principle referred to from time to time

31:43whether they call it the robustness

31:45principle or not. It says be liberal in

31:47what you accept and conservative in what

31:49you send. And that really came from a

31:52guy by the name of John Pastel who was

31:54really critical in the early days of

31:58getting the arponet and the NSFnet and

32:01the different networks that created the

32:04internet. He was really critical in

32:07helping do a lot of organizational work

32:10and managing the RFC's and doing a lot

32:13of other work around IP addresses and

32:16that sort of thing. So John Pastel

32:19always said be liberal in what you

32:20accept and conservative in what you

32:22send. And that really applies here at

32:24the internet layer. It keeps systems up

32:27and it keeps everybody working together

32:29and talking together. So the internet

32:32layer specifies processing rules and

32:34that helps ensure that datagramgrams end

32:36up where they're supposed to. Although

32:38different datagramgrams may actually

32:40require reassembly at this layer because

32:43they could end up being fragmented. Now

32:45we have a transport layer. same as the

32:47OSI model where we had the transport

32:49layer. TCP and UDP are transport layer

32:52protocols and they handle endtoend

32:54delivery. UDP doesn't actually care

32:56whether datagramgrams arrive or not. As

32:58a result, you'll hear UDP referred to as

33:00an unreliable protocol and TCP handles

33:04connectionoriented communication. By

33:06that I mean TCP guarantees delivery and

33:09it also makes sure that there's somebody

33:11on the other end to receive it. So there

33:14are reasons for having these two

33:16different protocols. Sometimes we just

33:17want to throw messages out onto the wire

33:20and we don't really care whether they

33:21get there or even what sequence they go

33:23in. If you think about doing a phone

33:26call over the internet using Skype as an

33:29example, when I am talking to you, I

33:32want the messages going from me to you

33:34to get there as quickly as possible. If

33:37some messages end up getting lost along

33:40the way, I don't really care so much

33:41because your ear is probably going to

33:43correct for it. And if it doesn't, then

33:46I don't really want it coming out of

33:48sequence because then it's going to

33:50sound like garbage to your ear. I really

33:52just want to send it. What gets there

33:54gets there and it gets played. If it

33:56doesn't get there, I'm not going to

33:57bother trying to resend it. TCP handles

33:59the bulk of communications across the

34:02internet because most of the time like

34:05web communication or file transfers or

34:07things like that. I really do care

34:09whether packets get there and what order

34:11they get there in and I want to make

34:13sure that they get reassembled

34:15correctly. So we've got a couple of

34:17different use cases and both UDP and TCP

34:20have their appropriate places in terms

34:23of network communications.

34:26Finally, we have the application layer.

34:28All application functionality is here.

34:30Session management, presentation, APIs,

34:32these are all at the application layer.

34:35Again, we go back to the model here and

34:38you'll see there are four layers. So the

34:40network access layer actually takes up

34:43the lower two layers of the OSI model.

34:46The application layer takes the top

34:48three layers of the OSI model. It's not

34:51like they took the functionality and

34:53just discarded it with the TCP IP model.

34:56What they said was, "We don't really

34:57feel that this needs to be broken out

34:59into its own individual layer." And as I

35:02mentioned with the OSI model, there's

35:04sometimes confusion about exactly where

35:06different protocols sit, particularly

35:09with the session layer. So in the TCP

35:12model, they just made it a lot more

35:13simple and it's really just four layers.

35:16So we've got the network access layer,

35:18the internet layer, the transport layer,

35:20and the application layer. So TCP IP is

35:24a four layer model. We've got network

35:26access, internet transport, and

35:28application. And that's the basics of

35:31the TCP IP model.

35:35In this lesson, we're going to be

35:36talking about capturing packets. So,

35:38capturing packets is a critical

35:41component to doing any sort of network

35:44troubleshooting or diagnosis. It's a

35:47really critical skill for any network

35:50engineer or frankly security engineer or

35:53pretty much anybody who does any sort of

35:56work on networks. As we go through these

36:00different lessons, we'll be doing a lot

36:01of packet captures and not only packet

36:04captures, but just looking at different

36:08packet captures. So, we're not only

36:09going to be capturing packets. We are

36:11going to be examining captures that have

36:14been done so we can dissect different

36:16protocols and take a look at how they

36:19work and the different requests that are

36:21going on. You can see here I've actually

36:24got a packet capture in process. I'm not

36:27actually storing this one. It's just all

36:29of the different requests that are going

36:31by and it's really just a summary here.

36:34So you can see the different source and

36:38destination addresses and the protocols

36:41that are being used as well as the

36:45different ports that are in use. And

36:47again, we're going to get into what all

36:49of those different words mean and how

36:52they work technically and we're going to

36:55describe all of that in different

36:56lessons. Right now, I just want to talk

36:58quickly about just capturing packets and

37:01the importance of capturing packets and

37:03the different types of packets that

37:05you're going to run across. You can see

37:07here I've got some IP packets. You can

37:10see some ARP packets. You can even see

37:12some IPv6 packets. If you're looking,

37:15you see IP6 in the second column as the

37:20things are scrolling by. Now, what I'm

37:22looking at here primarily is traffic

37:26that is destined specifically to my PC.

37:30So, you can see just scrolled off the

37:32screen. I'm actually going to cancel

37:36this request and I'm going to scroll

37:38back up and I'm going to look for these

37:42words that I really wanted to highlight

37:45here. So, at the top of this terminal

37:47window, you'll see uniccast. So anything

37:50that is directed specifically to me is a

37:54uniccast packet. The reason it's called

37:56uniccast is uni is a prefix meaning one.

38:01So we are sending a packet to one

38:04machine. Therefore we are doing a

38:07uniccast. So you can see a uniccast

38:11packet there. Now if I scroll down a

38:13little bit there were some other

38:16packets. There we go. At the top of the

38:19screen again, you'll see broadcast. Now,

38:22a broadcast packet is actually a packet

38:25that is destined for multiple systems or

38:29frankly every system. Any device on the

38:32network would get a broadcast packet

38:35because I am sending it across a broad

38:38spectrum of hosts. So, a broadcast would

38:42be sent to every device on a particular

38:46network. So that's a broadcast.

38:48There are protocols that use primarily

38:51uniccast packets and there are protocols

38:54that use primarily broadcast packets.

38:58And we're going to be going through

38:59those different protocols. And I did

39:01want to call out right up front the

39:04difference between broadcast and

39:05uniccast. And we'll revisit it as we go

39:08on through these different protocols and

39:11look at different packet captures. and

39:13we'll talk about what the different

39:14addresses look like that would be

39:17uniccast as opposed to broadcast. Now,

39:20what I've got up here in front of me is

39:23a packet capture tool called Wireshark.

39:26And what I was using before is a command

39:29line tool called TCP dump, which is

39:31available on most Unix like operating

39:34systems, and you can also get it for

39:36Windows as well, but it's a utility

39:39that's primarily for Unix like operating

39:42systems. I've got it running here on my

39:43Mac. There are also versions that are

39:46available for Linux and the various BSD

39:49flavors. So, TCP dump is a pretty common

39:54packet capture tool. And what I can do

39:56with TCP dump is I can actually store

39:59the results of a capture and it will get

40:01stored in a format that I can use inside

40:04of Wireshark. Wireshark, as you can see,

40:07is a graphical tool. we can look at the

40:12different protocols in a way that's more

40:15easy to understand. So I can just pop

40:18open a packet capture here

40:22and you can see the same sort of thing.

40:24We've got the packets that are scrolling

40:26by, but they're actually broken out into

40:28columns that are easier to understand.

40:30And you can see on the bottom here where

40:33it actually dissects the packet and

40:34we'll get into how Wireshark works in a

40:38different lesson. The way that this

40:40works, Wireshark or TCP dump, is it puts

40:44a network interface into what's called

40:46promiscuous mode. So promiscuous mode

40:49allows us to see all traffic that

40:53crosses this particular network

40:55interface. And the network interface is

40:58there to block out traffic that's not

41:02specifically destined to us. So, if we

41:05were on a different type of network that

41:08used a device that didn't filter those

41:12things. So, if we were using a hub as

41:14opposed to a switch and all traffic on

41:16the network were being sent to us, the

41:18only thing we would normally see or our

41:20operating system would normally see is

41:23packets that were destined to us that

41:25were uniccast packets or that were

41:27broadcast packets that everybody gets to

41:29see. Now, when we put a network device

41:32into promiscuous mode, everything comes

41:34up. Nothing is filtered any longer. So,

41:37what we're seeing here is all traffic on

41:40the network, whether it's destined for

41:43us or whether it's not destined for us.

41:46So, again, we'll get into more of the

41:49details around Wireshark in other

41:52lessons. And again, this is a tool that

41:54we're going to be using a lot as we go

41:56through the different lessons in this

41:59training video. So that's just an

42:03overview of doing packet capture. And

42:06again, I wanted to highlight the

42:07difference between uniccast and

42:09broadcast. And I also wanted to mention

42:12the promiscuous mode, which is the mode

42:15that we put the interface in in order to

42:17get all of the packets that are coming

42:20across the network interface. and they

42:22get pushed up into the network stack

42:25inside the operating system.

42:29In this lesson, we're going to be

42:30talking about using Wireshark.

42:32Wireshark, as you can see here, is the

42:35world's most popular network protocol

42:37analyzer. Now, it used to be that these

42:39protocol analyzers or packet capture

42:43utilities or network analyzers were

42:46really expensive devices that you had to

42:49buy and it required a lot of setup and

42:53you needed physical hardware. These

42:55days, it's just a piece of software. And

42:58Wireshark's been around for a while now

43:00under a couple of different names. And

43:03Wireshark is the most recent name, but

43:05they've been around for a while. It's a

43:07free piece of software. Runs on just

43:09about any platform that you probably

43:12have an interest in running it under.

43:15Runs under Mac OS as you see here. Runs

43:18under Windows, runs under Unix based

43:21operating systems like Linux. And just

43:25to get started with it, it's a pretty

43:27simple piece of software, but it also

43:29does a lot of really complex things. And

43:32the reason for introducing Wireshark

43:34here is we're going to be spending a lot

43:36of time in Wireshark as we go through

43:39this series of video lessons. Wireshark

43:43is going to give us the ability to look

43:46deeply into the protocols that we're

43:49going to be going over because I think

43:52that getting a protocol level

43:54understanding of what's going on really

43:57helps you understand networking and how

44:01systems interact with one another. It's

44:03also the best way to really see what

44:05happens because in reality the network

44:08can't lie. Applications make mistakes.

44:12applications can generate misleading

44:16error messages or log messages, but when

44:19you're looking at what's on the wire,

44:22the wire can't lie because at that

44:24point, we're just talking about an

44:25electrical signal, talking about bits

44:27and bites that are running across a

44:30physical wire. And so if you're looking

44:33for the best evidence as to what's

44:36actually going on with application

44:39interaction or going on on your network,

44:41you really want to be looking at the

44:43network level and looking at a network

44:47protocol analyzer like Wireshark. So the

44:50first thing that I want to do is I want

44:52to do a packet capture. Now there's a

44:55few different ways to kick off a packet

44:58capture with Wireshark. You can see on

45:01the left hand side here there is a

45:03capture box and there's an interface

45:05list. Now I could choose any of these

45:08interfaces to capture from and depending

45:12on what interface I'm using to connect

45:15to the network that would be the

45:17interface that I would choose. Now I can

45:20also go up here to the toolbar and you

45:24can see I could start a new live

45:26capture. And if I click that, that's

45:28just going to capture from the default

45:31network interface. And so I'm going to

45:34stop that one. I'm going to close it.

45:38I'm going to continue without saving. So

45:41let me show you another way here. I can

45:43just go up to the capture menu item, and

45:46you can see I've got interfaces,

45:48options, start, as well as capture

45:51filters. And if I select interfaces, I

45:54get basically the same thing as I do

45:56with the interface list. The difference

45:58is if I don't really know what interface

46:01that I want to capture from, then what I

46:04might want to do is bring up this

46:06dialogue box because as you can see,

46:08it's actually counting the packets on a

46:11per interface basis. And I can see here

46:13that EN1 is the interface that I'm

46:17actually getting a lot of traffic on.

46:20So, I'm going to select start there, and

46:23I can start capturing packets. You can

46:26see there's a lot of different menus,

46:29and we may get into some of these in a

46:32little bit more detail as we go through

46:35different protocols. Let me just show

46:37you a few different things that are

46:40useful. The first thing that you need to

46:42know about is filter. I've got all of

46:45these packets that are being captured.

46:48So far, I'm up to 78. And there could be

46:53hundreds or thousands of packets that I

46:56have captured, and I want a way to

46:59filter those packets. So, if I just

47:02typed IP, for example, I'm going to be

47:05looking at all of the IP packets. Well,

47:08that's not particularly useful because

47:10IP is a lower layer protocol and pretty

47:13much anything is going to be sitting on

47:16top of IP for the most part. Most of the

47:19things that we capture are going to be

47:21IP packets. So, that's not going to

47:23filter me very much. Now, I could do

47:26TCP, for example, and that's going to

47:29filter me down a little bit more. You

47:31can see that I've got a number of TCP

47:34packets. And in the protocol column,

47:38you'll see TCP, but you'll also see

47:41other protocols as well. And the reason

47:44that they're not all TCP is because

47:47other protocols ride on top of TCP. And

47:51we'll talk about the stack and how the

47:54different protocols layer on top of one

47:56another in another lesson. But you can

47:59see for example TLSV1 there. TLS is an

48:04encryption protocol that happens to ride

48:07over TCP. So I can do TCP. Now I could

48:11also do HTTP which would be web traffic.

48:15So I can see only web traffic. So that's

48:19really useful. Now those are protocols.

48:21What if I want to filter by something

48:25like IP address? So, IP address equals

48:29equals because that's the syntax that we

48:32use. And let's say I want to do

48:34192.168.1.43.

48:38One of the reasons I do that is because

48:40I can see 43 there. I happen to know

48:43it's going to come up. Now, I've got

48:45just packets that are either to or from

48:49that particular address.

48:52I can also do IP.source source or src.

48:57And I could do 192.168.1.43.

49:04And now I'm only going to get the

49:07packets where it's a source address

49:09rather than a destination address. Now

49:13you can see as I'm typing here, the box

49:15is actually changing colors. So this red

49:19background color in the filter box

49:21suggests that I don't have a filter

49:24expression that I can actually use. The

49:27reason for that is I don't have a

49:29complete IP address. And Wireshark knows

49:32that IP. SRC requires a complete IP

49:36address in order to work. So once I get

49:39a complete IP address, now it goes

49:42green. So the green indicates I have a

49:46complete filter that can actually parse.

49:49Of course, whether it's going to

49:50generate any results is a different

49:53problem. Now, whether I've actually

49:56captured any packets that would match

49:59that filter, well, we're not actually

50:01checking that in the filter box. So, I

50:04can do that. It's a parsible expression,

50:07but it doesn't necessarily mean it's

50:09going to yield any results. So, I can

50:12filter based on protocol. I can filter

50:16based on IP address. Let me just clear

50:20that out. I can filter on just about

50:24anything that you can see in the packet

50:27here. And there's a pretty dense

50:30filtering language understanding all of

50:32the different variables that you can

50:34plug in. But I'm just going to cover

50:37some of the basics here that we've

50:39already gone over so that you can see

50:41how you can start narrowing your filter

50:45and what gets displayed so it's easier

50:47to see what's going on. Now, one other

50:50thing that I can do, and I'm actually

50:51going to stop the capture here just to

50:53make it a little bit easier to see

50:55what's happening. So, we're not just

50:57having constant messages flooding

50:59through here. Now what I can do is I

51:03could actually select a packet here and

51:07if I right click on it I get a number of

51:09options. So I could actually apply this

51:13as a filter. So if I do a selected here

51:17now I've actually applied that as a

51:20filter. So what I'm getting is packets

51:23that look like that. So you can see the

51:26filter that actually got applied is

51:28ip.dst DST equals 192.168.1.1.

51:33So that's the filter that got applied

51:35there. Now I could go find another

51:38packet here. And there's another thing I

51:42want to demonstrate that is really going

51:44to be useful. Actually, let me filter

51:46down by TCP again. And I could actually

51:50do this here. Now what I could do is

51:54follow the TCP stream. So that's going

51:57to show me all of the messages related

52:01to that particular TCP stream. And in

52:03this case, what it's done is it's popped

52:06up all of the contents of the stream. So

52:10I can see in this case it's raw mode.

52:13And not really clear what this is,

52:16although it looks like it may be a

52:18calave request since I can see

52:20calendar.google.com

52:22as part of it.

52:25So, let me see if I can actually find an

52:28HTTP which would be a little bit easier

52:31to follow here. And I don't happen to

52:34have an HTTP request.

52:39Let me start a capture again.

52:45I just brought up Google and now I can

52:48go back to Wireshark.

52:50I'm going to stop the capture and I'm

52:52going to filter down to HTTP.

52:57Now I can do follow TCP stream here. And

53:00now you can see the HTTP content in

53:03clear text and readable. So this is what

53:06an HTTP request looks like here. And

53:10there's the get request. And if I scroll

53:12down, I can see the response there as

53:14well. So you can see where that would be

53:17really helpful if you are trying to find

53:21all of the messages in a particular

53:24dialogue between two systems. If it

53:27happens to be a TCP flow, for example,

53:31HTTP, then you could follow TCP stream

53:34and it will show you all of the messages

53:37and you can actually see the filter

53:38TCP.stream

53:40equals 10. it's actually flagged this

53:43particular stream as stream 10. And what

53:45we're looking at is all of the messages

53:48from that particular stream. So that's

53:52some basics around using Wireshark for

53:56capturing and analysis of packets and

53:59the different ways that you can do

54:01filters. As I said, we'll be using

54:04Wireshark quite extensively over the

54:07course of these lessons, and this is

54:10just to get you kind of familiar with

54:12the interface and how it operates.

54:18In this lesson, we're going to be

54:19talking about the Internet Engineering

54:21Task Force or IETF. Now, you may be

54:24wondering why we're talking about an

54:26organization like the IETF. The reason

54:29is the IETF is responsible for

54:32developing the majority of protocols

54:35that we run on the internet. The IETF is

54:39responsible for developing these

54:42protocols and standards in a way that's

54:44open and in a way that is going to

54:48hopefully get the most technical

54:51competence and the best protocols out of

54:54the process of doing this development.

54:58As a result of this process of what the

55:02IATF is responsible for, we end up with

55:05things like RFC's. RFC's are request for

55:09comments. And what a request for

55:11comments really is is a specification of

55:16how something is supposed to work. Let

55:19me just bring up a RFC here. And you can

55:24see that I am bringing up the RFC for

55:28the internet protocol. I've actually got

55:31a list of them here because I was

55:32looking for 791. RFC 791 is the

55:36specification for the internet protocol.

55:40And you can see it was written in

55:41September 1981.

55:44It was prepared for the defense advanced

55:47research projects agency or DARPA and it

55:51was prepared by the information sciences

55:54institute. You can see this one is over

55:5730 years old. But if you look through

56:00here, anything you need to know about a

56:03protocol that runs on the internet, or

56:06most of the protocols anyway that run on

56:08the internet, you can find in an RFC

56:11with the IETF.

56:13If you need to know exactly how an IP

56:16packet looks, then you can look up the

56:19IP RFC.

56:22And you can see that we've got the

56:25header format. This is exactly what an

56:29IP header should look like as defined by

56:32the specification. And this

56:34specification has now become a standard.

56:37But when this RFC was first written or

56:40when RFC's in general are first written,

56:43they go through working groups and

56:46people request comments and people

56:48receive comments or working groups

56:50request and receive comments and the

56:53comments go into making the protocols

56:57and the processes and procedures or

56:59whatever is documented in the RFC, they

57:02go into making those better. So, it's

57:05really a community effort. Now, there

57:07are a number of protocols and they don't

57:10all quite look the same anymore because

57:14we've really changed how we do things.

57:17You can see the IP RFC was requested by

57:22DARPA or the Defense Advanced Research

57:25Projects Agency and it was prepared by a

57:28particular entity in the case of a more

57:32recent RFC. So this one here is the

57:34session initiation protocol which is one

57:37of the core protocols for voice over IP

57:39traffic. You can see what we've got is

57:42the network working group and there's

57:45just a list of people who were

57:48responsible for working on this

57:50particular RFC. And there's the list in

57:54the upper right hand corner of the

57:56document and you can see the date there.

57:58Now, it wasn't actually created for

58:01anybody in particular and it wasn't

58:04prepared by anyone in particular. It

58:07actually came out of a working group and

58:09the IETF manages these working groups.

58:13That's one of their functions. And these

58:15working groups are responsible for not

58:18only creating but maintaining these

58:21RFC's and various standards. You can see

58:24in the upper leftand corner of the

58:27document, it obsoletes 2543.

58:31So I can actually go back here and I can

58:34look up 2543

58:39and there's RFC 2543

58:42and you can see it's actually the

58:45session initiation protocol. So what

58:48they did was they created another

58:51version of SIP and created a whole new

58:55RFC in order to manage that process of

58:59creating this new protocol or the new

59:02version of this protocol. And you can

59:05see the list here in the upper right

59:07hand corner again. And there's a couple

59:09of names that are actually the same as

59:11those who were responsible for creating

59:14SIP version two. Again, that's another

59:17thing that the IETF is responsible for.

59:20They're responsible for maintaining

59:22these standards tracks and also

59:24maintaining whether protocols obsolete

59:27other protocols or whether they've

59:30superseded them or deprecated them. They

59:32are responsible for maintaining the

59:36consistency of all of these protocols so

59:41that when you are looking for the most

59:43recent one, you're not going to get

59:45confused by, oh, I've got a version, but

59:49it doesn't say it's been obsoleted. So,

59:51the IETF is responsible for all of that

59:54and they manage that. So, again, we have

59:573261 saying that it obsoletes 2543.

1:00:01So we've got all of these protocols and

1:00:05they're managed and maintained by the

1:00:07IETF. And you can see over here on the

1:00:10left hand side you can see the working

1:00:11groups. We've got application working

1:00:14groups and you can see the different

1:00:16application working groups. We've got

1:00:18internet working groups and operations

1:00:21and management. We've got a routing

1:00:24working group, a security working group,

1:00:26and a transport working group. So all of

1:00:30these working groups meet on a regular

1:00:32basis. The IETF actually holds

1:00:34conferences on a regular basis and these

1:00:37working groups get together and they

1:00:40define these protocols and standards by

1:00:44working on RFC's and drafting these

1:00:47documents. Anytime you want to know the

1:00:51specifics about how a protocol works,

1:00:53the best place that you can go to is the

1:00:56RFC because we're not talking at that

1:00:59point about somebody's interpretation or

1:01:02how a particular vendor implemented a

1:01:05specification. We are talking about how

1:01:08it was defined by the people who

1:01:11actually created the protocol and

1:01:14created the standard. If you want to

1:01:16know how SIP was designed to work or why

1:01:19SIP was created, you come to the RFC and

1:01:23you can see exactly the details that are

1:01:27in it. Now, one of the things about

1:01:29RFC's is there's often a lot of wiggle

1:01:33room in them in terms of whether

1:01:37different aspects of a protocol may be

1:01:39implemented or should be implemented.

1:01:42So, there's language here. You can see

1:01:44in section three we've got a terminology

1:01:47section and it says in this document the

1:01:50keywords must, must not, required,

1:01:52shall, shall not, should, should not,

1:01:53recommended, not recommended, may and

1:01:55optional are to be interpreted as

1:01:58described in another document which is

1:02:00RFC 2119.

1:02:02The different words of course mean

1:02:05different things. Now something like

1:02:07must is an aspect of the protocol that

1:02:11really has to be there. Whereas

1:02:13something like should or should not is

1:02:16something that may be a little bit gray

1:02:18where one vendor may interpret that as

1:02:21well we really ought to do that and

1:02:23another as yeah it just says we should

1:02:26do that. It doesn't mean that we're

1:02:27going to do that. And that's where you

1:02:29get interoperability challenges. And

1:02:32that's one reason why there are

1:02:35different organizations that are

1:02:37responsible for managing

1:02:39interoperability

1:02:40groups to make sure that different

1:02:43vendors can actually interoperate with

1:02:45one another. And when implementations of

1:02:48protocols hit the marketplace that they

1:02:51actually will work more or less reliably

1:02:54with other vendors products. And it's

1:02:57not one of these situations where you

1:02:59have to have vendor A throughout your

1:03:02entire network in order to just work

1:03:05with, for example, the protocol SIP.

1:03:08There are different vendors that will

1:03:10interpret these specifications a little

1:03:13bit differently than others, and that

1:03:16can lead to some nuances. But if you

1:03:19want to know how a protocol was designed

1:03:22to work and what the people who were

1:03:25responsible for drafting and designing

1:03:27that protocol were thinking about when

1:03:31they put it together or how they

1:03:32documented it at any rate, then you

1:03:35really want to go to the RFC. And the

1:03:37place to look for RFC's is the IETF, of

1:03:42course, because they're responsible for

1:03:44doing all of the creation and

1:03:46maintaining. So that's the internet

1:03:47engineering task force.

1:03:51In this lesson, we're going to be

1:03:52talking about protocols. We're actually

1:03:55going to spend a lot of time over the

1:03:57course of these several lessons about

1:03:59TCP IP really talking about protocols.

1:04:03It would be useful to understand

1:04:05actually what a protocol is. When we're

1:04:08talking about protocols, not even

1:04:10thinking in terms of networking, there

1:04:13are actually protocols that you engage

1:04:15in. Well, probably a pretty regular

1:04:17basis, even a daily basis. Imagine we've

1:04:21got Bob and we've got Fred here and Bob

1:04:24runs into Fred on the street. What's the

1:04:27first thing that Bob's going to do?

1:04:29Well, the first thing that Bob's going

1:04:30to do, he's probably going to say

1:04:31something like hello. And Fred being the

1:04:35friendly sort is going to respond with

1:04:38hello as well. Now, Bob is probably not

1:04:42going to drop it there because that

1:04:44would be kind of awkward. just say

1:04:45hello. Hello. I suppose if they were

1:04:47just passing each other, that might do.

1:04:50But if they ran into each other and were

1:04:52stopped for any period of time, there

1:04:53would be something else along the lines

1:04:55of, "How are you?" And Fred might reply,

1:04:58"I'm fine." This actually is an example

1:05:02of a protocol. And in this case, the

1:05:05protocol that we're talking about is

1:05:07actually just this idea of greeting

1:05:10somebody that you know. Or if you're

1:05:13meeting somebody that you don't know,

1:05:15you may say, "My name is Rick." They

1:05:19might reply, "My name is George." Or

1:05:22whatever. That would also be an example

1:05:25of a protocol.

1:05:27All a protocol is is just a series of

1:05:30rules for communication. So there are

1:05:33guidelines and there are rules for how

1:05:35you would engage somebody else in just a

1:05:38simple act of communication. These are

1:05:41really sets of rules that we've honed

1:05:44over centuries and centuries of human

1:05:47interaction. So we don't really think of

1:05:50them as rules as much anymore. They're

1:05:52just kind of natural ways of behaving.

1:05:55Well, in fact, what they really are are

1:05:57protocols because they're a set of rules

1:05:59that we engage in with one another so

1:06:03that we're all really talking the same

1:06:05language on the same page and making

1:06:08sure that the other person is available

1:06:12for communication as well. So, when Bob

1:06:16and George here actually greet each

1:06:18other, in addition to this hello,

1:06:21there's probably some sort of eye

1:06:23contact. And that eye contact is

1:06:26important to ensure that the other

1:06:28person is actually listening to you and

1:06:32that you know that they're paying

1:06:34attention to what you're saying. There's

1:06:36not only the physical act of

1:06:38communicating and speaking or in sign if

1:06:42that's how you do it if you're using

1:06:43sign language. There are other

1:06:45mechanisms in play as well. So it's not

1:06:49only about what you say, it's often

1:06:51about how you say it. And because of

1:06:54that need for subtlety and inflection

1:06:58and eye contact, again, we've got these

1:07:01rules that we all sort of learn over

1:07:03time. And it's not like there's a book

1:07:05somewhere that says, "Here's a set of

1:07:07rules for how you communicate with

1:07:09somebody." We just kind of learn them

1:07:11over time. They're social norms and ways

1:07:15of behaving with one another so that we

1:07:17can have effective and useful

1:07:19communication. The same thing goes with

1:07:22computers. When they are talking, there

1:07:25needs to be a set of rules. And in this

1:07:27case, they're actually written down.

1:07:29There have to be a set of rules so that

1:07:31both computers can say things in a way

1:07:35that the other end of the conversation

1:07:38can actually understand what's being

1:07:40said and the context in which it's being

1:07:42said so that again, everyone stays on

1:07:45the same page. And that's really the

1:07:48gist of protocols and where we're going

1:07:50to be spending a lot of time

1:07:52understanding what these rules are and

1:07:55how they interact with other sets of

1:07:58rules and how you use those rules to do

1:08:01effective communication between computer

1:08:04systems over networks.

1:08:08In this lesson, we're going to be

1:08:10talking about networking utilities.

1:08:12There are a handful of networking

1:08:14utilities that we'll be using through

1:08:17the course of these lessons, but also

1:08:20that you'll find very useful as you

1:08:23continue making use of TCP IP

1:08:26networking. I'm going to be doing these

1:08:28under a Unix based operating system,

1:08:31which is Mac OS. But you'll find that

1:08:34either these utilities themselves that

1:08:36I'm going to be demonstrating or slight

1:08:38variations on them will actually work

1:08:42under both Linux and Windows. There are

1:08:46typically Windows analoges for the

1:08:48various utilities that we'll be using

1:08:50like ping and trace route and netstat

1:08:52and those sorts of things. In order to

1:08:54get to the place where you can access

1:08:57those utilities, you would need to bring

1:08:59up a command prompt. And you would do

1:09:01that by going to your start menu and

1:09:03then going to all programs, going to

1:09:06accessories, and you'll see a command

1:09:08prompt. if it's not somewhere in the

1:09:11menus ahead of that, it's typically

1:09:13under accessories. So that's where you

1:09:15would find the command prompt. Once you

1:09:17bring up the command prompt, you've

1:09:19actually got a command line where you

1:09:21can run ping, trace route, netstat, the

1:09:24various command line utilities that

1:09:25we'll be using here in this set of

1:09:28lessons. Now, the first one I want to

1:09:30show you is a utility called if config

1:09:34and that's going to show me the

1:09:36interface configuration for my network

1:09:39interfaces. Now, a variation on this

1:09:42particular utility also works under

1:09:44Windows. Instead of if config, it's

1:09:46actually IP config. You'll see more or

1:09:49less the same information. And it will

1:09:51be presented in slightly different ways

1:09:54but basically the two utilities are just

1:09:58ways of looking at the configuration for

1:10:01network interfaces. You can see here the

1:10:05list of network interfaces that I've got

1:10:07on the system and you can see cases

1:10:10where there is actually configuration

1:10:14for IP. Here's V-Nick 0 and it's got an

1:10:19internet address or an IP address and a

1:10:22net mask and a broadcast address and of

1:10:26course a MAC address as well. On top of

1:10:29that, we've also got EN1. In this case,

1:10:32it's the wireless interface on my

1:10:35Macintosh. That's got an IP address of

1:10:39192.168.1.22

1:10:42and of course a net mask here. the net

1:10:45mask or the subnet mask or just the

1:10:47network mask needs to be translated in

1:10:50this case from hexadesimal to decimal.

1:10:53This is just a short-handed way of using

1:10:56what we would typically see as in this

1:10:59case 255.255.255.0.

1:11:04So that's the interface configuration

1:11:07here. I'm going to take a look at

1:11:09another utility called netstat. In this

1:11:12case, I'm actually going to run it from

1:11:13a Linux system and I can show you

1:11:17information about all of the network

1:11:20activity that is going on on my system.

1:11:24So, you can see some connections that

1:11:28we've got going on. And here's actually

1:11:31where we're using domain sockets as

1:11:33opposed to internet connections. So

1:11:35these are basically files that reside on

1:11:39your system and network like

1:11:41communication goes on through these

1:11:44files. These are actually domain sockets

1:11:47and you can see it says without servers.

1:11:50Let's take a look at all of the ports

1:11:53where I've got listening applications.

1:11:56If I do netstat minus L, I can see all

1:12:00of the listeners. You can see that we

1:12:03are bound to everything. Asterisk means

1:12:06everything. So in this case, we're

1:12:08talking about all of the interfaces on

1:12:10the system. On the right hand side of

1:12:12the colon is the port that we are

1:12:15listening on. What this has done is it's

1:12:18actually looked up the common name for

1:12:21the service that typically runs on that

1:12:23port. So I could actually do a minus ln

1:12:28which is going to give me the port

1:12:31number without doing the translation. So

1:12:34I'm actually just going to see the port

1:12:36number if I do netstat minus ln. This is

1:12:39my SQL port. 139 has to do with Windows

1:12:43file sharing. 110 is the pop 3 server

1:12:48port. Port 80 is HTTP and so on. I can

1:12:52show you all of the listening ports on

1:12:56my system. I can also show the name of

1:13:01the program that's actually used for a

1:13:05particular connection. So I'm going to

1:13:08run netstat and we should be able to see

1:13:10the programs that are actually listening

1:13:12on these ports.

1:13:14Let's go back again. Here we've got

1:13:15MySQL. Not surprisingly, this is the

1:13:18MySQL server and we've got the Net Bios

1:13:22port. That would be 139. And you can see

1:13:25over here on the right, that's the Samba

1:13:27server. The POP 3 port is POP A3D.

1:13:32I can see the programs that are actually

1:13:35attached to the different communications

1:13:39that are going on on my system. So I can

1:13:42see everything that's happening from a

1:13:44networking perspective. You can look on

1:13:47the right hand side and you can see the

1:13:50program or the service that's actually

1:13:52making use of that networking

1:13:55communication.

1:13:57Something else that we are going to make

1:13:59use of is something called Netcat.

1:14:02Netcat runs under Linux. It will run on

1:14:05Mac OS. It will also run on Windows. And

1:14:09Netcat actually will open up connections

1:14:12to different systems. We'll make a fair

1:14:14amount of use of this in the coming

1:14:17lessons, but I want to show it to you

1:14:19quickly here. Netcat just opens up a

1:14:22connection and allows me to interface

1:14:25with a particular system on any given

1:14:28port. So, what I'm doing here is I'm

1:14:31running netcat to www.google.com

1:14:34google.com on port 80, which of course

1:14:36is the web port. And I'm just issuing an

1:14:39HTTP request here.

1:14:41And what I get, of course, is all of the

1:14:44HTML and JavaScript that that web server

1:14:48is providing. So if I were a browser,

1:14:51I'd be able to render this and you'd be

1:14:52able to see the page for Google in front

1:14:55of you. But netcat I can use for network

1:14:59troubleshooting if I want to be able to

1:15:02do some manual interaction with systems.

1:15:05Similarly, I can use the tnet client in

1:15:08the same way. If I connect to port 80,

1:15:12I'm really doing a TCP connection to a

1:15:15particular port. As I said, netcat will

1:15:18do a very similar thing. The difference

1:15:20is netcat also supports listening and it

1:15:23also supports UDP mode. So here I can

1:15:27just issue an HTTP request and I'm going

1:15:30to get the same response. Those are some

1:15:33networking utilities that again we're

1:15:35going to make use of in subsequent

1:15:37lessons but also that you'll find

1:15:40interesting or useful as you are doing

1:15:43networking. So we've got if config or IP

1:15:47config on Windows. We've got netstat and

1:15:50we've got netcat and tnet. Those are all

1:15:53pretty useful networking utilities.

1:15:58In this lesson, we're going to be

1:15:59talking about Ethernet. Ethernet is

1:16:02really a layer 2 protocol, although it

1:16:05specifies some layer 1 applications as

1:16:09well. Before I get into some more

1:16:11details about Ethernet, I want to talk a

1:16:13little bit about the history of where it

1:16:15came from. Xerox was actually developed

1:16:18in about 1973 1974 at the PaloAlto

1:16:22Research Center for Xerox. Now Xerox

1:16:26Park and it's called Park because of the

1:16:28PaloAlto Research Center is actually

1:16:31well known for a long history of

1:16:34innovation. Here's actually an article

1:16:37describing how Xerox created the very

1:16:41first computer mouse. And there's a

1:16:44picture here or an illustration of it.

1:16:46The first mouse was actually wood-based.

1:16:49So it was a basically a wooden box that

1:16:52had the electronic components in it.

1:16:55Xerox actually also created the very

1:16:57first graphical user interface. So

1:17:00that's where Ethernet came from.

1:17:02Ethernet came out of a long history of

1:17:05research and development activities at

1:17:07Xerox. Ethernet was created as a way to

1:17:12more easily do local area networks or

1:17:15link computers together. And that was

1:17:17all part of the project where the first

1:17:20graphical user interface was created.

1:17:22They really kind of wanted to create an

1:17:24office where everybody's kind of

1:17:26interacting on computers. And that was

1:17:28sort of Xerox's vision a long time ago

1:17:31back in the early '7s. So that's where

1:17:34Ethernet came from. It's a layer 2

1:17:36protocol. It's actually a family of

1:17:38protocols. When you think of Ethernet,

1:17:41often people think of these cables right

1:17:44here. So you can see this is a Cat 5

1:17:49cable and the Cat 5 component of it is

1:17:53the cabling part. And it's Cat 5 because

1:17:56it's category 5. And there are varying

1:18:00degrees of categories which specify

1:18:03really the gauge of the copper inside

1:18:06the cable itself. There's actually four

1:18:10pairs of thin copper wires or small

1:18:13copper wires which you can kind of see

1:18:16right here. You can see the different

1:18:18colors of the copper wires as they come

1:18:20out into the jack. Now the jack here is

1:18:23an RJ45 jack. And this is pretty common

1:18:26Ethernet cabling today. In reality, when

1:18:30Ethernet was first created, it was

1:18:33created using coaxial cable and it was

1:18:36shared media because coax didn't have

1:18:40any ability to do things like we do

1:18:42today where we do what we call home runs

1:18:45where every computer has its own cable

1:18:47and it goes back to a central networking

1:18:49component called either a hub or a

1:18:51switch depending on what kind of

1:18:53functionality it has. So, we've got all

1:18:55of these cables that are running to this

1:18:58network device, but early on it was

1:19:00really one long coaxial cable, and what

1:19:03you did was you clamped into the coax

1:19:06cable and you ran a connector out from

1:19:10that clamp-on connection. So, we have

1:19:12really shared networking or shared media

1:19:15where everybody's using the same wire to

1:19:18transmit across. And that's less so

1:19:20today, although we still have this

1:19:23concept of shared media. Part of the

1:19:26reason for that is depending on whether

1:19:28you've got a network device that's

1:19:30capable of doing the filtering to make

1:19:33sure that you only get the messages that

1:19:35are destined to you, then what you're

1:19:38really seeing is everything on the

1:19:40network. So you still get this concept

1:19:42of shared media. In the late 1970s,

1:19:46Deck, which is the digital equipment

1:19:48corporation, which was eventually bought

1:19:50by Compact and then Compact was bought

1:19:52by HP. Digital Intel and Xerox really

1:19:56took over Ethernet and started to

1:19:58promote it as a standard. As a result,

1:20:00for a while it was called the Dix

1:20:02Protocol. Now we call it Ethernet and

1:20:05it's really the most common of the layer

1:20:082, layer 1 networking that you're likely

1:20:12to see. As I said early on, it's a

1:20:15family of protocols. And most commonly,

1:20:18you'll see it running across these Cat 5

1:20:21cables or sometimes Cat 6 or Cat 5e

1:20:24cables, but you'll see it running across

1:20:26these cables that look like this with

1:20:28these connectors on them. Ethernet also

1:20:32can run over other media as well,

1:20:35including the air. So Wi-Fi when Wi-Fi

1:20:39was first created used many of the

1:20:42protocol concepts from Ethernet and

1:20:45Ethernet is really implemented in the

1:20:48wireless standards. So the 802.11

1:20:53really use Ethernet as the protocol

1:20:56foundation in terms of how things are

1:20:58framed and how they're put together. And

1:21:00we've got many different types of

1:21:02standards for Ethernet. There's the

1:21:04original 10bas 5 which you see mentioned

1:21:06here used coax cable and then we had 10

1:21:10bas t which uses twisted pair and then

1:21:14we have 100 bas t and then there was

1:21:181000 bas t which is gigabit ethernet.

1:21:21So, we had a lot of different types of

1:21:25Ethernet protocols depending on the

1:21:27speed that you're going at. And if you

1:21:30can't figure it out from the name, 10

1:21:33references the fact that it's 10

1:21:35megabits. 100 is 100 megabits and 1,00

1:21:39is 1,000 megabits, which is of course a

1:21:42gigabit. That's really the essence of

1:21:46the Ethernet protocol. And as I said, it

1:21:49really specifies the data link component

1:21:52as it mentions here. So we get the layer

1:21:542 aspect of it. But of course, there's

1:21:56also specifications for the physical

1:21:59side as well. These cables, for

1:22:01instance, are specified as part of the

1:22:04Ethernet suite of protocols.

1:22:08In this lesson, we're going to be

1:22:10talking about layer 2 addresses. Many

1:22:13layers actually require addresses in

1:22:16order to be able to differentiate one

1:22:20object from another. What we've got here

1:22:22is a number of computer systems or other

1:22:25types of systems like routers or other

1:22:30devices that would sit on the network

1:22:31and need to be able to be accessed. So,

1:22:35we've got all of these objects and they

1:22:38need to be accessed. So, we need an

1:22:40address for them because we need to know

1:22:42how to get to them. Just like when

1:22:44you're getting a letter, you don't just

1:22:46drop a letter out there and expect it's

1:22:48going to get to the right place. You've

1:22:50got to put an address on it if you want

1:22:51it to get to your friend who you're

1:22:53writing the letter to. You've got to put

1:22:55your friend's address on the outside of

1:22:57the envelope. Same sort of thing here.

1:23:00We've got an Ethernet header that you

1:23:02can actually think of as the envelope.

1:23:04And along with that envelope comes an

1:23:07address. You want to be able to make

1:23:10sure that if the letter doesn't get

1:23:13delivered, it comes back to you. So, you

1:23:15need to put your address as well as the

1:23:18address that the letter is going to.

1:23:20Similarly, we have a source and

1:23:21destination address in our layer 2

1:23:25header. What we've got here with

1:23:26Ethernet is actually a MAC address, and

1:23:30MAC stands for media access control. The

1:23:33MAC address, sometimes called the

1:23:35physical address, is actually bound to

1:23:38the network interface card, which is why

1:23:39it's called a physical address because

1:23:41it lives physically on the network

1:23:44interface card. We use this MAC address

1:23:47locally to deliver messages to one

1:23:50another. You may be wondering, well,

1:23:53we've also got IP addresses, so why not

1:23:56just use IP addresses everywhere that we

1:23:59go? The reason that we don't use IP

1:24:01addresses for all of our addressing

1:24:04needs is we need an address that's

1:24:08abstracted from the IP address so that

1:24:10we can use different networking

1:24:12protocols on top of Ethernet. So I've

1:24:15got Ethernet and that's where my MAC

1:24:17address lives is in the layer 2 header.

1:24:20I want to be able to use other

1:24:22networking protocols other than IP. So

1:24:26that's why we need a MAC address that's

1:24:29separate and distinct from the IP

1:24:31address. I need to have the ability to

1:24:36have other networking protocols like

1:24:38IPX, SPX or Apple Talk or DeckNet or

1:24:41some of the other protocols. We need

1:24:43that modularity. There has to be an

1:24:45address at layer 2 so that we can have

1:24:48different addresses at layer 3 and we're

1:24:51not required to just use the IP address.

1:24:55And it really protects the layer three

1:24:57protocol from having to implement all of

1:25:00the layer 2 pieces as well. So we do all

1:25:05of the stuff around the data link

1:25:07connection in the layer 2 which is where

1:25:11the media access control or MAC address

1:25:14lives. What we've got here you can see

1:25:17is a destination and a source address.

1:25:19And the addresses are the same in terms

1:25:22of their structure. You can see the

1:25:24destination in the left hand side says

1:25:28Netgear_CE

1:25:30col0383.

1:25:32Now what we've got in both of these is a

1:25:3548bit address and the first three bytes

1:25:40of the address are related to the

1:25:44vendor. It's actually called an OUI or

1:25:47an organizationally unique identifier.

1:25:50And what wireshark has done very nicely

1:25:53for us is it has looked up that OUI and

1:25:56it has determined that it is owned by

1:26:00the organization Netgear_CE.

1:26:03In the source, you can actually see the

1:26:06source is owned by Apple and it's got a

1:26:09designation of Apple_e2.

1:26:12We've got the Netgear and the Apple

1:26:15devices that are talking to one another.

1:26:18And the second three bytes actually are

1:26:22the nick address. So they are the unique

1:26:26address specific to that network

1:26:28interface card. So we've got three bytes

1:26:31that belong to the vendor. The E0469A

1:26:35that belongs to the vendor in the

1:26:36destination address and the C0383

1:26:41belongs to the network interface card.

1:26:43So that's the network interface cards

1:26:45address itself. and you put the two

1:26:47together and you get the MAC address.

1:26:50There are several different protocols

1:26:52actually that use MAC addresses.

1:26:55Ethernet is one. You can see here we're

1:26:57looking at an Ethernet packet. We can

1:27:00see the MAC address there. Bluetooth

1:27:03also uses MAC addresses. 802.11 WFI.

1:27:08Fiber interfaces like Fitty use MAC

1:27:11addresses and ATM also use MAC

1:27:14addresses. So, lots of different

1:27:16protocols use these same MAC addresses

1:27:19to identify the devices that are

1:27:23communicating back and forth. That's a

1:27:26little bit about MAC addresses and layer

1:27:292 addresses in general, but MAC

1:27:31addresses specifically. And MAC

1:27:33addresses are actually what we're going

1:27:35to see a lot of as we go through these

1:27:39different lessons and we look at

1:27:41different protocols. We're going to be

1:27:42seeing a lot of MAC addresses. We'll

1:27:44talk a little bit more about how MAC

1:27:46addresses are used and how the

1:27:48translation between a layer 2 MAC

1:27:52address and a layer 3 IP address for

1:27:55example happens and how you do lookups

1:27:58based on IP address versus MAC address.

1:28:02That's the layer 2 address and that's

1:28:05why we use layer 2 addresses as opposed

1:28:07to always using layer 3 addresses.

1:28:13In this lesson, we're going to be

1:28:14talking about PPP and some other layer 2

1:28:18protocols or encapsulation protocols

1:28:20similar to it. Now, PPP is the

1:28:22pointto-point protocol. It's actually

1:28:24sort of a successor to a protocol that

1:28:27was called slip, which is serial line

1:28:30IP. Now, these were protocols that were

1:28:33used primarily when we were using things

1:28:36like modems for communication, and we

1:28:39needed protocols that were capable of

1:28:42setting up connections between two

1:28:44devices quickly and easily, and also

1:28:48being able to encapsulate higher layer

1:28:51protocols. Right here, I've got just the

1:28:54Wikipedia article about the

1:28:56point-to-point protocol. Just want to

1:28:58show you the structure of a PPP frame.

1:29:01You can see here in this table that

1:29:04we've got a protocol and that's either

1:29:06one or two bytes and that's the setting

1:29:09of the protocol for the data field. And

1:29:11by protocol we're talking about what's

1:29:14actually in the payload. It's LCP which

1:29:17is the link control protocol or it's IP

1:29:20or IPX or Apple talk something like

1:29:22that. So then we've got the actual

1:29:24datagramgram or the information and

1:29:26there's some optional padding that goes

1:29:28as well. So we can see that there are

1:29:31some different phases for PPP. There's

1:29:34link dead link establishment

1:29:36authentication phase and we've also got

1:29:39some PPP configuration options. And this

1:29:42is where the protocol would actually do

1:29:44the setup of the connection. I'm going

1:29:48to bring open our good friend Wireark

1:29:51here. And I can show you a capture of

1:29:54some PPP frames. So you can see here

1:29:58we've got a configuration request. And

1:30:01we can pop this open here. And it says

1:30:04it's a link control protocol. So we've

1:30:07sent a PPP message out. And it's

1:30:10actually for a link control protocol. So

1:30:12that's the protocol that we're sending

1:30:14here. So we're actually sending a

1:30:17configuration request.

1:30:20You can see that the source and the

1:30:22destination have been altered here. So

1:30:25we've got a DTE and a DCE. And that's

1:30:29just two ends of the connection. In the

1:30:32first case, we've got DTE to DCE and

1:30:35then we've got DCE to DTE. And you can

1:30:38see they go through this negotiation

1:30:41process of doing the configuration

1:30:44request and they'll either acknowledge

1:30:46it or they'll not acknowledge it or

1:30:49knack it. PPP is capable of doing this

1:30:52connection setup. But what we really

1:30:54want is to be able to authenticate both

1:30:58ends so that we know that the right

1:31:00people or the right users are actually

1:31:03making use of this service. So I've got

1:31:06a different capture here and this is PPP

1:31:09with the extensible authentication

1:31:11protocol or E. Now you can also use the

1:31:14challenge handshake authentication

1:31:16protocol or CHAP to go along with PPP to

1:31:20provide the authentication but in this

1:31:23case I happen to have a packet capture

1:31:25here where they use E rather than chap.

1:31:28So we're doing the LCP setup here. Here

1:31:31you can see at the beginning we're doing

1:31:32a configuration request and there's a

1:31:35configuration request going the other

1:31:37direction. Now looks like we've set up

1:31:40the configuration. So we're requesting

1:31:43that we authenticate here. You can see

1:31:47it actually makes reference to RFC 3748

1:31:51here. They all do. There's the identity

1:31:54request and here's an identity response.

1:31:57And there is an identity response. we're

1:32:00sending the challenge. So with this,

1:32:04what happens is rather than sending a

1:32:06password across the wire, the

1:32:09authentication server will send a

1:32:12challenge and then there's some

1:32:14algorithm that you go through in order

1:32:17to create the response to the challenge

1:32:20and both ends know how to create that

1:32:23response based on what the challenge is.

1:32:26So typically what happens is the

1:32:28authentication server will send a value

1:32:31and it's probably some random value. So

1:32:34you can see here there's the value. Let

1:32:37me unhighlight that so it's a little

1:32:39more visible. What would typically

1:32:41happen is you would take that value and

1:32:44you would perform some sort of

1:32:45mathematical operation on it like

1:32:48perform a cryptographic hash or

1:32:50something like that with the password or

1:32:53with the username and password or with

1:32:55other pieces of data that are known to

1:32:58both ends of the conversation. So then

1:33:02what happens is we send the response

1:33:05back and you can see there's the

1:33:07response there. If the response matches

1:33:12what was computed on the end of the

1:33:15authentication server, now we've got a

1:33:17successful authentication. And you can

1:33:20see that's exactly what happens here.

1:33:23We've got a success to the

1:33:25authentication protocol. And now we can

1:33:28really set up the connection between the

1:33:31two ends. PPP is a protocol that ended

1:33:35up superseding this other protocol

1:33:37called slip and they are used for doing

1:33:42automatic configuration of connections

1:33:45across primarily things like serial

1:33:47lines although sometimes you'll see PPP

1:33:50being used in other situations like

1:33:53they've used PPP to help support DSL for

1:33:57example so you'll see PPPOE sometimes

1:34:00which is PPP over Ethernet It's not PPP

1:34:03over a serial line, which is more

1:34:05traditional. They're doing PPP over

1:34:08Ethernet in order to facilitate DSL

1:34:11working. You'll also sometimes see PPP

1:34:14over ATM. And we'll get into ATM in

1:34:18subsequent lessons. And what ATM

1:34:21actually is. PPP is really a way of

1:34:25automatically configuring a connection

1:34:28between two different endpoints. and

1:34:32doing all of the parameters around that

1:34:34configuration and doing authentication

1:34:37if authentication is actually required.

1:34:41In this lesson, we're going to be

1:34:43talking about WAN protocols or wide area

1:34:45network protocols. Now, there are

1:34:47several protocols that are used for wide

1:34:50area networks. And what I'm really

1:34:52talking about when I'm talking about

1:34:54wide area networks is the connections

1:34:57that are used when you're talking about,

1:35:00for example, your internet service

1:35:01provider. Any network provider uses

1:35:05these really large connections or really

1:35:08large pipes in order to transmit

1:35:10information. And there are protocols of

1:35:13course that are used to get that data

1:35:16from one point to another. You may think

1:35:19of the internet as this big sort of

1:35:21amorphous cloud. What it really is is a

1:35:24connection of pipes or tubes. These

1:35:26pipes or tubes of course use protocols

1:35:29in order to get data back and forth. And

1:35:32one of the protocols that is used an

1:35:34awful lot is synchronous optical

1:35:36networking or sonnet. Sonnet is an

1:35:40optical networking protocol of course

1:35:42because it's called synchronous optical

1:35:44networking. It's interesting because

1:35:47rather than the headers and then the

1:35:49payload with sonnet you end up with

1:35:52headers interled with the payload. So

1:35:55you can see here this is a sonnet frame

1:35:59or STM1 frame for synchronous transport

1:36:02module level one and there's an STM1

1:36:06frame and there's some other diagrams

1:36:09here. I'm not going to get into a lot of

1:36:11details about how sonnet works primarily

1:36:14because they don't actually have a

1:36:16packet capture. Not surprisingly, these

1:36:18kind of packet captures are difficult to

1:36:20get your hands on. I don't actually have

1:36:22a packet capture to show you what it

1:36:24really looks like, but I did want to

1:36:26touch on it because it is a really

1:36:28important protocol because it gets used

1:36:29a lot. Now, another one that gets used a

1:36:32lot is ATM. And I'm not talking about an

1:36:35automated teller machine. I'm talking

1:36:36about asynchronous transfer mode.

1:36:38Asynchronous transfer mode or ATM is

1:36:41interesting because it was actually

1:36:44developed in the late 1980s to handle

1:36:49ISDN.

1:36:50ISDN was going to be this great service

1:36:54that the phone company was going to

1:36:56offer. It was going to support

1:36:58highcapacity, great quality voice. So

1:37:02ATM was actually developed to meet the

1:37:04needs of ISDN. And ATM as I mentioned

1:37:08was interesting because rather than

1:37:11variable length packets you end up with

1:37:15fixed length cells. They don't use

1:37:18frames. Now other wide area networking

1:37:21protocols call their data units frames

1:37:24and ATM calls them cells. And one of the

1:37:28things about ATM that's kind of

1:37:30interesting is they're really smallsized

1:37:32cells. So you've got a five byt header

1:37:36and a 48 byt payload. So that gives you

1:37:40a 53 byt cell. And it doesn't matter

1:37:44what size data you've got, it's always

1:37:47going to be a 53 byt cell. So in the

1:37:50case where your data doesn't end up

1:37:53having enough to actually fill something

1:37:56that's a 53 byt cell, let's say you

1:37:59actually had something that was 486

1:38:03bytes, for example, I'd end up having 10

1:38:07cells and then I'd have a little bit of

1:38:10extra data. So I'd have six bytes that

1:38:13didn't fit into the 10 cells that I had

1:38:16already sent. So what ends up happening

1:38:18is they have to pad that cell out. So

1:38:21I've got 53 byt cells with ATM. Another

1:38:25protocol that's perhaps more common

1:38:29particularly with smaller networks is

1:38:32frame relay. And frame relay is actually

1:38:36kind of a cloud. You can see here in

1:38:39this diagram we've got the network

1:38:43provider. Typically, the phone company

1:38:45provides you this frame relay cloud and

1:38:48you connect your equipment to their

1:38:50frame relay switches and then they

1:38:53handle all of the communication about

1:38:56who you're communicating with and who's

1:38:58part of your frame relay network. And

1:39:00there could be lots of different

1:39:02businesses that are using the same

1:39:04equipment here in this frame relay

1:39:07cloud, but the phone company actually

1:39:10handles who gets to see what data. So

1:39:13theoretically, you don't have to worry

1:39:15about anybody else being able to see

1:39:17what it is you're doing and it's private

1:39:20in that sense because they're separating

1:39:22it out within the equipment. So frame

1:39:26relay is another type of wide area

1:39:29networking protocol and they use things

1:39:32like protocol data units and you can see

1:39:35what a protocol data unit here would

1:39:37consist of. So every frame relay

1:39:39protocol data unit would consist of a

1:39:42flag field, an address field, an

1:39:45information field, and a frame check

1:39:47sequence. So this is the bit that would

1:39:51get thrown on by the equipment before it

1:39:54got thrown out to the frame relay

1:39:56network. It would add all of these

1:39:58header bits on before it sent it out.

1:40:01Now frame relay also has the ability to

1:40:04do congestion control. As you see here,

1:40:07all of this stuff is actually handled

1:40:09inside of the network. This is not

1:40:12something again that you would typically

1:40:14ever see because it would be on the

1:40:16other side of the equipment that

1:40:19connects you to the internet or whatever

1:40:22provider you're connecting to for a

1:40:24network provider. So, we've got a number

1:40:27of different wide area network

1:40:29protocols. They are typically used for

1:40:31internet connections, although they're

1:40:33not exclusively used for internet

1:40:35connections. You could actually set up a

1:40:36wide area network between multiple

1:40:39sites. You would just go to your phone

1:40:42company or a network provider and they

1:40:45would drop a line at your place of

1:40:48business and then drop another line at

1:40:50another location. And you would use

1:40:52these protocols like sonnet or ATM or

1:40:55frame relay depending on what your needs

1:40:57were and the type of networking you were

1:41:01doing whether they were doing fiber or

1:41:04whether it was copperbased from the

1:41:06phone company. Sometimes the method of

1:41:09transmission affects the protocol that's

1:41:12being used. Obviously you're not going

1:41:13to run sonnet over copper for example.

1:41:16So that's just a little bit about wide

1:41:18area networking protocols.

1:41:22In this lesson, we're going to be

1:41:23talking about virtual LANs or VLANs.

1:41:26Sometimes they're called VLANs for

1:41:28short. What's a VLAN? Well, a local area

1:41:31network is a set of physical networking

1:41:34devices and cables. The reason we have

1:41:37virtual local area networks is because

1:41:40sometimes you want to set up different

1:41:42physical networks without actually

1:41:44deploying the physical hardware like

1:41:47switches that would allow you to do

1:41:49that. So you want to have some sort of

1:41:51physical isolation between different

1:41:55network segments, but you don't want to

1:41:57have to go purchase expensive switches

1:42:00to be able to do that. So you have one

1:42:03larger switch that you can connect a

1:42:05number of computers into and it allows

1:42:09you to set up different ports in the

1:42:11switch so that different computers can

1:42:14be on different virtual local area

1:42:16networks. So, how do we go about doing

1:42:19this virtual local area networking or

1:42:22VLAN? I've got a packet capture here.

1:42:25And you can see there's a number of

1:42:28packets or frames that have been

1:42:30captured. Right here, we've got the

1:42:33Ethernet header. This is the layer 2

1:42:35header in the packet. So, I've got my

1:42:38Ethernet header here. And here's what

1:42:40you would typically see. you would

1:42:41typically see the destination MAC

1:42:44address, the source MAC address, and

1:42:47then you would have the type, and in

1:42:49this case, I've got an IP packet.

1:42:52Additionally, we've got some other

1:42:55headers in this packet here. So, we've

1:42:57got a VLAN tag, and this VLAN tag right

1:43:01here says VLAN equals 118. Now, 118 is

1:43:05the number of the VLAN. So I can have a

1:43:08wide range of numbers which allow me to

1:43:13give some identification to the

1:43:16different virtual networks that I have.

1:43:19So I could say people in marketing are

1:43:22on VLAN 100, people in human resources

1:43:25are on VLAN 110, people in development

1:43:28are on VLAN 120, and so on. So I've got

1:43:33VLAN 118 here. This is what we call an

1:43:37802.1Q

1:43:39tag. So 802.1Q

1:43:42is the protocol specification for this

1:43:45VLAN tagging that allows the packets to

1:43:48be flagged as being part of a particular

1:43:51VLAN. So you can see here I've got this

1:43:54802.1Q tag and when a switch sees that

1:43:59tag it says oh you belong to this

1:44:01particular network and it knows which

1:44:04ports in the switch fabric are part of

1:44:08that particular virtual LAN and so

1:44:12broadcast messages would only go out to

1:44:14those particular ports. Uniccast

1:44:16messages of course are going to go to

1:44:19the specific port that the system that

1:44:22owns that address is connected to. This

1:44:25802.1Q tagging that we've got gives us

1:44:29the ability for PCs to join these local

1:44:33area networks or in some cases be on

1:44:36multiple networks at the same time

1:44:38depending on what the switch

1:44:40configuration is. But certainly

1:44:42switchto- switch communications have

1:44:45this 802.1Q tag here that gives us the

1:44:49ability to flag particular packets as

1:44:52being part of one VLAN or another VLAN.

1:44:56So again, 802.1Q

1:44:58and virtual LANs or VLANs give us the

1:45:01ability to set up multiple networks

1:45:05which would otherwise be physical

1:45:07networks, but it allows us to create

1:45:09logical networks from the same physical

1:45:12networking infrastructure. And all of

1:45:14the partitioning is done inside the

1:45:16network hardware itself. We don't have

1:45:19to worry about having multiple switches

1:45:22because the switch does all of that

1:45:24isolation and partitioning and make sure

1:45:27that the traffic for particular VLANs

1:45:30stays within the right ports that belong

1:45:34to those particular VLANs and doesn't go

1:45:36outside of them. So, we get that

1:45:38separation and it's all done inside the

1:45:41switches.

1:45:44In this lesson, we're going to be

1:45:45talking about purposes of the network

1:45:48layer. I've got a wire shark capture

1:45:50here, and you should be pretty familiar

1:45:52with looking at wire sharkark captures

1:45:53by this point, and I've flagged one of

1:45:56the packets here in the top. You can see

1:45:59I've got one selected. Now, in the

1:46:02bottom window, you can see all of the

1:46:04different headers or portions of that

1:46:07particular packet. So, I'm going to open

1:46:10up the network layer portion, and we're

1:46:12just going to talk quickly about the

1:46:14purposes of the network layer, and we'll

1:46:15look in more detail at the different

1:46:19portions of this header in a subsequent

1:46:22lesson, but right now, I just want to

1:46:24talk about the different purposes for

1:46:27the network layer. So, you can see here

1:46:30that we've got a source and a

1:46:33destination address. One of the things

1:46:36that the network layer does is it

1:46:38forwards packets from one network to

1:46:41another. So in this case, I've actually

1:46:44got two IP addresses that are on the

1:46:47same network. So we wouldn't actually

1:46:49have to cross a network boundary to get

1:46:53the messages to one another. So these

1:46:55messages are actually going to be

1:46:56transmitted strictly across layer 2.

1:46:59Now, if I had IP addresses that were on

1:47:03separate networks, for example,

1:47:0510.11810.1

1:47:07as my source and let's say my

1:47:09destination is 4.2.2.1,

1:47:12my destination address would be on a

1:47:15separate network. So, the network layer

1:47:17is responsible for forwarding those

1:47:20packets from one network to another

1:47:23network. And as a result, we have to

1:47:26know things like what the default

1:47:27gateway is or the gateway for particular

1:47:31routers that have particular subnets. So

1:47:34all of the routing is done at the

1:47:35network layer as well. Routing and

1:47:38forwarding packets done at the network

1:47:41layer. Of course, addressing is at the

1:47:43network layer. You see we've got IP

1:47:45addresses here. So that's done at the

1:47:47network layer. So I've got my source and

1:47:50my destination addresses here. These are

1:47:53logical addresses as compared to the

1:47:57physical addresses that we've got here

1:47:59in the Ethernet header, which would be

1:48:02the layer 2 header. So right here, I've

1:48:05got a source and a destination address,

1:48:07and that's my MAC address. So that's a

1:48:10physical address, meaning it's actually

1:48:12bound to the physical network device. So

1:48:15I've got physical addresses here. So why

1:48:18not just use the MAC addresses then to

1:48:21get messages from one device to another?

1:48:24Well, the reason for that, even though

1:48:26MAC addresses are globally unique,

1:48:29meaning no two network interface cards

1:48:31could ever have the same MAC address,

1:48:34MAC addresses are all going to look

1:48:36completely different depending on who

1:48:38the vendor is. And so we have no way to

1:48:42actually aggregate those addresses. So

1:48:45when we put a network together, I really

1:48:48want to have addresses that have

1:48:51something in common. So for example,

1:48:53right here, I've got 10.11810.1

1:48:57and then 10.11810.2.

1:49:00And you can see the first three segments

1:49:03of the address there are the same

1:49:05between the source and the destination.

1:49:07That means they're on the same network.

1:49:10And as a result, I can get messages to

1:49:13them pretty quickly because I can figure

1:49:16out through routing tables how to

1:49:18actually get messages to a device that's

1:49:21close to them. If I were to use MAC

1:49:23addresses, you can see these here are

1:49:26pretty different. So, I've got 0013

1:49:30and 001b.

1:49:32I don't really have a good way of

1:49:34getting messages to these two devices,

1:49:38even though they're on the same network.

1:49:40I don't have a good way of getting

1:49:42messages from the other side of the

1:49:45world, for example, to these two

1:49:47different devices because you'd have to

1:49:49have a table that included all of these

1:49:52MAC addresses here. That would pretty

1:49:55quickly get unwieldy. As a result, we

1:49:57have these logical addresses that are

1:50:00bound to the physical addresses. And

1:50:03these logical addresses here in the IP

1:50:06header provide us an ability to

1:50:08aggregate them so that we can more

1:50:11easily collect devices together into

1:50:14networks. And then we can have routing

1:50:17tables that can be aggregated and we can

1:50:21more efficiently get messages from one

1:50:24side of the globe to another side of the

1:50:26globe without having to worry about

1:50:29enormous tables to look up information

1:50:32in and figure out how to get messages

1:50:34from one side to the other. So we have

1:50:36logical addressing done here at the

1:50:39network layer as well. So we have the

1:50:42logical location which is the first part

1:50:45the 10.118.10

1:50:47in this case and then of course we have

1:50:48the host identification. So the.1 or the

1:50:52two would be the host identification in

1:50:55this part. So the network layer is

1:50:57responsible as I said for forwarding

1:50:59packets. We also have addressing. It

1:51:02does logical location and of course

1:51:04routing because that's where the address

1:51:06lives. routing is done at the network

1:51:10layer as well. So that's the purpose of

1:51:13the network layer.

1:51:17In this lesson, we're going to take a

1:51:19look at IP headers. IP headers are

1:51:21really important because they tell us a

1:51:24lot of information about what's going on

1:51:26with the datagramgram that's on the

1:51:28network, where it's going and how it's

1:51:31going to get there, and a lot of other

1:51:34information. So, let's just take a quick

1:51:36look through the IP headers and see what

1:51:39we can find. So, I've got a Wire Shark

1:51:42capture here. And this capture just has

1:51:45a number of, in this case, they're ICMP

1:51:48messages, which are of course IP

1:51:50packets. So, I've got the IP portion of

1:51:55the packet open here. And I could close

1:51:58it up. And you could see that I've got

1:52:01my layer 2 header. And then I've got my

1:52:03layer three header. And then here's the

1:52:06payload which is MP. So I'm going to

1:52:10open up the IP header portion. Just

1:52:14scroll down here so you can see the

1:52:15entire thing. One thing about Wireshark,

1:52:18I just want to point out here when you

1:52:20select different portions, it actually

1:52:22shows you in the lower part where in the

1:52:26raw message that particular section is

1:52:29located. You see when I've selected

1:52:32version, it actually has highlighted one

1:52:35bite out of the raw data down at the

1:52:39bottom where it's pulled that version

1:52:42from. You can see also that in addition

1:52:45to the version, I get the header length.

1:52:48Those two things are combined in that

1:52:50one bite. And in this case, you can see

1:52:52the header length is 20 bytes. That

1:52:55tells me that this entire header here,

1:52:58the entire IP header is 20 bytes. So

1:53:01I've got 20 bytes that has my IP header

1:53:04in it. So that's the header length.

1:53:07Moving down, the next portion is the

1:53:10differentiated services field or diff

1:53:12serve and that's sometimes used for type

1:53:16of service or toos. Typically what this

1:53:19is really used for is quality of

1:53:21service. So I can differentiate my types

1:53:25of traffic so that more important

1:53:28traffic gets a higher priority. And what

1:53:30this really is is all about

1:53:32prioritization

1:53:33so that you can make sure that the

1:53:35things that are really reliant on being

1:53:39there on time. So voice and video are

1:53:42good examples of this. and gaming

1:53:44traffic sometimes, although most network

1:53:47providers probably won't prioritize

1:53:49gaming traffic, but certainly voice and

1:53:51video will get prioritized because

1:53:53they're really sensitive in terms of the

1:53:56time it takes for a message to get from

1:53:59one endpoint to another endpoint. So we

1:54:02would use this differentiated services

1:54:04field or diffserve field to flag them as

1:54:08either voice or video so that our

1:54:10provider can prioritize that traffic and

1:54:13make sure that it gets to the other end

1:54:15faster. Now I've got the total length

1:54:18and that's the total length of the

1:54:21packet here that includes the headers as

1:54:25well as the data. You can see that's 100

1:54:27bytes. I've got my IP identification

1:54:31field here or IP ID and that identifies

1:54:35fragments of datagramgrams. So if I have

1:54:38to split a message up and I'm going to

1:54:42create fragments, I need to be able to

1:54:45put those fragments back together. The

1:54:47IP ID will actually help me do that. So

1:54:50I've got an identification header here

1:54:53as well. Now I've got a few flags and we

1:54:56were just talking about fragmentation.

1:54:58So different networks actually have

1:55:01maximum transmission units. So for

1:55:03example, Ethernet typically the maximum

1:55:06transmission unit meaning the largest

1:55:08size chunk of data that it can take

1:55:12across the physical medium is 1500

1:55:14bytes. That's pretty typical for

1:55:16Ethernet. You get 1500 bytes to send in

1:55:20any particular packet. So if you've got

1:55:24data that is more than 1500 bytes, then

1:55:27you're actually going to have to

1:55:29fragment the data up into multiple

1:55:31packets. So I've got a more fragments

1:55:34bit here to indicate that I've actually

1:55:36got more fragments or more portions of

1:55:39the data that are going to come. I've

1:55:42also got a don't fragment bit. What that

1:55:44says is don't actually chunk this up.

1:55:48Sometimes that will cause messages to be

1:55:51dropped because if you say you can't

1:55:53fragment it and we hit a portion of the

1:55:56network where the maximum transmission

1:55:58unit or the MTU is actually smaller than

1:56:02the amount of data that you've got and

1:56:04it needs to be fragmented, but you've

1:56:06got the don't fragment bit set, then the

1:56:08message is probably just going to get

1:56:10dropped. Then I've got my fragment

1:56:12offset tells me where in the stream of

1:56:16data this particular fragment is going

1:56:18to be. I've got a time to live header.

1:56:22Now in the protocol specification, it

1:56:24actually specifies that the time to live

1:56:27is in seconds, but in practice, this is

1:56:30really a hop count field. The number of

1:56:33network devices you go through are

1:56:35called hops. So every time I go past a

1:56:39network boundary which is handled by a

1:56:41router then I've gone a hop. As I said

1:56:44in practice we actually keep track of

1:56:47hop counts. So we keep track of the

1:56:48number of routers that we go through and

1:56:50that's our hop count. This time to live

1:56:53in this case 255.

1:56:56It would be unusual for you to go

1:56:58through 255 routers to get from one

1:57:02place to another. But let's say you had

1:57:05your TTL set to 10, for example. Once

1:57:08you hit a device past that 10, then the

1:57:13packet's just going to get discarded

1:57:15because you've exceeded your time to

1:57:17live. And actually, what would happen is

1:57:19we'd send a message back as an error

1:57:22back to the sending host saying packet

1:57:25expired in transit or message expired in

1:57:27transit. So for every router that this

1:57:30passes through, this time to live field

1:57:32here would get decremented. So we'd

1:57:35subtract one from it. And once we hit

1:57:37zero, now we've expired in transit and

1:57:39we've got to do something which would

1:57:41probably mean that we're going to

1:57:42generate an error. Now I get the

1:57:45protocol field here. And the protocol

1:57:48just says which IP protocol is going to

1:57:51be transmitted as the payload or the

1:57:55data that's part of this IP message or

1:57:58this IP packet. I've got ICMP here in

1:58:02this case and you can see it's actually

1:58:05protocol one and if I look down at the

1:58:08bottom here you can see it's 01 and that

1:58:11actually is where we get the one from.

1:58:13So there's a whole bite that's used for

1:58:15this protocol field here. Now I've also

1:58:19got the header check sum and it says

1:58:23929B.

1:58:25So that's two bytes that are used for

1:58:27the header check sum. And you can see

1:58:30here the two bytes that get used for

1:58:34that header check sum are right here. So

1:58:36929B

1:58:38and the header check sum is just there

1:58:41to make sure that the data hasn't been

1:58:44altered in some way. So we want to make

1:58:47sure that the data that was sent matches

1:58:50the data that was received. So both ends

1:58:52would perform a check sum. It's just a

1:58:54mathematical computation. And assuming

1:58:57the check sums match, we can make sure

1:58:59that the data that was sent is more than

1:59:02likely the data that was received. So

1:59:05that's what the check sum is there for.

1:59:06And this is really just the check sum on

1:59:08the header. It's not actually the

1:59:10checksum on the data. So we know the

1:59:12header hasn't been altered in some way

1:59:14through some sort of man-in-the-middle

1:59:16attack or something like that. Then I've

1:59:19got the source IP address. And you can

1:59:22see down here there are the four octets

1:59:24that are the source IP address. And I'm

1:59:28going to click on the destination. And

1:59:30I've got the four octets here that are

1:59:32the destination IP address. And by

1:59:35octet, I mean a collection of eight

1:59:37bits. Each section of an IP address is

1:59:41actually eight bits. And we'll talk

1:59:42about addressing in a different lesson.

1:59:45But just so you know, each of these

1:59:47between the dots is represented by 8

1:59:50bits, which means we can have values

1:59:53from 0 to 255.

1:59:56I've got one bite, two bytes, three

1:59:58bytes, and four bytes there. Those are

2:00:01my four octets. Same thing here. One

2:00:04bite, two bytes, three bytes, and four

2:00:07bytes. And then down at the bottom where

2:00:10it's highlighted in the raw message, you

2:00:12can see the four bytes there as well. So

2:00:15that's really the IP headers in a

2:00:18nutshell and what the different sections

2:00:20mean and the different pieces of data

2:00:24that you can find in the different

2:00:26headers and how they're all used. So

2:00:29that's the IP header in a nutshell.

2:00:33In this lesson, we're going to be

2:00:34talking about IP addresses. So an IP

2:00:38address is a logical address that

2:00:41belongs to the internet protocol or IP.

2:00:44Now IP is a layer three protocol and

2:00:47that's layer three in the OSI model as

2:00:50opposed to the TCP IP model. So I've got

2:00:53a layer three protocol here and I've got

2:00:56a logical address and you can see I've

2:00:58got a wire sharkark capture and here are

2:01:01a couple of IP addresses. So in this

2:01:03case I've got 10.11810.1

2:01:08and 10.11810.2

2:01:10two. And you can see they're denoted by

2:01:15four numbers that are separated by

2:01:17decimal points or dots.

2:01:20Let's just talk about what that means

2:01:22here. So each of these sections here is

2:01:24called an octet. Why is it called an

2:01:27octet? The reason it's called an octet

2:01:30is because it's actually represented by

2:01:34eight bytes. And let's take a look at

2:01:37what 10 would look like. Now, before I

2:01:39take a look at what 10 would look like,

2:01:41let me tell you what each digit here

2:01:43represents.

2:01:45This first digit here on the far left is

2:01:49actually going to be 2 to the 7th power.

2:01:52And that actually equals 128. The next

2:01:56one is 2 to the 6th power. That actually

2:01:59equals 64. Then I've got 2 to the 5th

2:02:04power is 32.

2:02:072 to the 4th power is 16.

2:02:112 to the 3 power is 8. 2 to the 2 power

2:02:16is 4. 2 to the first power is 2.

2:02:22And 2 to the 0 power equals 1.

2:02:28Let's take a look at what 10 would look

2:02:30like. I'm going to write it from left to

2:02:32right here, which is how you would

2:02:34normally write a number anyway. is just

2:02:36you have to keep track of which digit

2:02:39you're actually representing. So I'm

2:02:42actually looking for 2 to the3 which is

2:02:45the fifth digit from the left. So 1 2 3

2:02:504 and then I've got a one for my 2 to

2:02:53the 3. I've got a zero in my two to the

2:02:56second's place and then a one in my two

2:02:58to the first place and then a zero in my