-
Notifications
You must be signed in to change notification settings - Fork 1
/
mod1-03.html
464 lines (422 loc) · 25.9 KB
/
mod1-03.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Advanced Networking - Module 1 Chapter 3 - Network Protocols and Communications</title>
<meta name="description" content="Abilitante alle certificazioni Cisco CCENT e CCNA">
<meta name="author" content="Hacklab Cosenza">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<link rel="stylesheet" href="css/reveal.css">
<link rel="stylesheet" href="css/theme/hlcs.css" id="theme">
<!-- Code syntax highlighting -->
<link rel="stylesheet" href="lib/css/zenburn.css">
<!-- Printing and PDF exports -->
<script>
var link = document.createElement( 'link' );
var link = document.createElement( 'link' );
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = window.location.search.match( /print-pdf/gi ) ? 'css/print/pdf.css' : 'css/print/paper.css';
document.getElementsByTagName( 'head' )[0].appendChild( link );
</script>
<!--[if lt IE 9]>
<script src="lib/js/html5shiv.js"></script>
<![endif]-->
</head>
<body>
<div class="reveal">
<!-- Any section element inside of this container is displayed as a slide -->
<div class="slides">
<section>
<h1>Advanced Networking</h1>
<h2>Routing & Switching:</h2>
<h2>Introduction to Networks</h2>
<h3>Chapter 3: Network Protocols and Communications</h3>
<small><a href="http://hlcs.it">Hacklab Cosenza</a> / Centro di Ricerca su Tecnologia e Innovazione</small>
</section>
<section>
<h2>What is Communication?</h2>
<p>What are the elements of a communication?</p>
<ul>
<li>The <strong>message</strong>, of course.
<li>The <strong>source</strong> of the message, the <em>sender</em>
<li>The <strong>destination</strong> of the message, the <em>receiver</em>
<li>The <strong>channel</strong> in which communication occurs.
<li>The <strong>rules</strong>, or <em>protocols</em> to which both sender and receiver have to agree.
</ul>
<p>These elements belongs to every kind of communication.</p>
</section>
<section>
<h2>Rules of a communication</h2>
<p>By following established <strong>protocols</strong> that governs communications, it is possible to deliver and understand a message reliably.</p>
<p>There can be many protocols. Each one provides an agreement on the following requirements:</p>
<ul>
<li>Identifying sender and receiver
<li>Commong language and grammar structures
<li>Speed and timing
<li>Confirmation or acknowledgment of delivery
</ul>
</section>
<section>
<section>
<h2>What Protocols do</h2>
<h3>Message Encoding</h3>
<p><em>Encoding</em> is converting information between two different forms.</p>
<p><em>Decoding</em> is the reverse process.</p>
<p>Examples: words -> sounds; bits -> impulses.</p>
</section>
<section>
<h2>What Protocols do</h2>
<h3>Message Formatting and Encapsulation</h3>
<p>Now that we have an encoded message, we must send it with appropriate <strong>structure</strong>. <u>Letters</u>' recipient, greeting, content, closing, signature are perfect examples.</p>
<p>Most of the times is convenient to <em>enclose</em> the message for delivery, like we do with <u>envelopes</u> for letters.</p>
<p>Enclosing one message format in another is called <strong>Encapsulation</strong>. <strong>De-encapsulation</strong> is the reverse process.</p>
<p>Computers' envelopes are called <strong>frames</strong>.</p>
</section>
<section>
<h2>What Protocols do</h2>
<h3>Message Size</h3>
<p>Messages are usually <strong>divided into smaller parts</strong>, suited for how much the receiver can <strong>process at one time</strong>.</p>
<p>This division process is called <strong>segmenting</strong>.
<p>Each segment must abide to both a <strong>minimum and maximum</strong> size.</p>
</section>
<section>
<h2>What Protocols do</h2>
<h3>Message Timing</h3>
<ul>
<li><strong>Access Method</strong>: <em>when can I speak? what do I do if I speak when others are speaking too?</em></li>
<li><strong>Flow Control</strong>: <em>how fast/slow and for how long can I speak?</em></li>
<li><strong>Response Timeout</strong>: <em>how long do I wait for a response before reacting? what is the appropriate reaction when the other party is not responding?</em></li>
</ul>
</section>
<section>
<h2>What Protocols do</h2>
<h3>Message Delivery Options</h3>
<ul>
<li><strong>Unicast</strong>: one-to-one delivery.
<li><strong>Multicast</strong>: one-to-many delivery.
<li><strong>Broadcast</strong>: one-to-all delivery.
</ul>
<p>Sometimes the receiver is required to send confirmation (<strong><em>acknowledgment</em></strong> or ack) that it actually received the message.
</section>
</section>
<section>
<h2>Protocols in Stacks: Theory</h2>
<p><strong>Protocol Suite</strong>: several protocols that needs to interact toghether for a communication to occour.</p>
<p>This interactions is best thought (<em>model</em>) in terms of <strong>layers</strong> in a <strong>stack</strong>.</p>
<p>Each upper layer protocols <strong>depends on the functionality</strong> provided by lower level protocols.</p>
<p><u>Rule of thumb</u>: lower layer protocols are more concerned with <em>moving data</em>, upper layer ones with <em>message content</em>.</p>
</section>
<section>
<h2>Protocols in Stacks: Practice</h2>
<p>We can see the protocol stack model in action even in a <strong>simple communication</strong> between a web server and a browser.</p>
<ul>
<li><strong>Application Protocol</strong>: HTTP (Hypertext Transfer Protocol), requesting the right page to the web server.</li>
<li><strong>Transport Protocol</strong>: TCP (Transmission Control Protocol), it helps in splitting a single big page into multiple pieces that can be reassambled.</li>
<li><strong>Internet Protocol</strong>: IP, it identifies source and destination by address.</li>
<li><strong>Network Access Protocol</strong>: eg. Ethernet, placing the bits on to the wires.</li>
</ul>
</section>
<section>
<h2>Protocol Suites</h2>
<p>Protocol suites can be developed by <strong>a standards organization</strong> or by a <strong>vendor</strong>.</p>
<p>The TCP/IP Protocol Suite (IP, HTTP, DHCP and others) is a standard-based protocol suite. This means they are freely available to the public for <strong>implementation</strong>.</p>
<p>Following standards-based protocols allows for <strong>interoperability</strong>. Hw and Sw from different vendors are guaranteed to work together.</p>
<p>Some protocols are <strong>proprietary</strong>: only one vendor develops, controls and (often) knows how the protocol operates.</p>
</section>
<section>
<h2>TCP/IP Protocol Suite</h2>
<img src="http://i.imgur.com/bDGSrfQ.png">
<p>We will see all of these protocols throughout this course. :)</p>
</section>
<section>
<h2>TCP/IP Communication Process</h2>
<img src="http://i.imgur.com/D98yrCJ.gif">
<p>Let's see the <strong>simple communication</strong> between a web server sending the requested page to a browser (and the browser displaying it) from a <strong>TCP/IP perspective</strong>.</p>
<p><u>Data = Web Page</u></p>
</section>
<section>
<h2>Open Standards Organizations</h2>
<p>Standards are essentials for an open Internet, and they wouldn't happen without <strong>vendor-neutral, non-profit standard organizations</strong>.</p>
<p>By <strong>producing freely available protocol specifications</strong> they ensure that no single vendor can hold the Internet hostage of their own interests.</p>
<p>Very often the standards these organizations produce are guaranteed to be <strong><em>royalty-free</em></strong>, which means no payment is due for the patents used in them.</p>
</section>
<section>
<section>
<h2>The Internet Society</h2>
<img src="https://i.imgur.com/pNOqOkg.jpg" style="float: right;">
<p><strong>ISOC</strong> is an ensemble mainly focused on the development of the <strong>technical structure of the Internet</strong>.</p>
<p>It's governed by a board of 13 respected <strong>individuals</strong>, not tied to any specific company, agency, etc.</p>
<p>The <strong>IETF (Internet Engineering Task Force)</strong> maintain Internet technologies in the form of <strong>RFCs (<em>Requests for Comments</em>)</strong>. The <strong>IRTF (Internet Research Task Force)</strong> is more focused on <strong>forward-thinking research</strong>.</p>
</section>
<section>
<h2>ICANN and IANA</h2>
<p>The <strong>Internet Assigned Numbers Authority (IANA)</strong> is an organizations originally run by the US Gov. for managing</p>
<ul>
<li>IP address allocation,
<li>domain names
<li>protocol identifiers
<li>port numbers
</ul>
<p>and <strong>Internet namespaces in general at the higher level</strong>.</p>
<p>The <strong>Internet Corporation for Assigned Names and Numbers
(ICANN)</strong> is the non-profit that, over time, has carried over IANA duties under a contract with the US Gov.</p>
<p>Since 09/2016, USGov has relinquished control over ICANN, which is now managed by the global internet community.</p>
</section>
<section>
<h2>IEEE</h2>
<p>The <strong>Institute of Electrical and Electronics Engineers</strong> (pronounced <em>I-triple-E</em>) is dedicated to standards and innovation in <strong>electrical engineering and electronics</strong>.</p>
<p>Its standards <strong>affects whole industries</strong> besides just networking.</p>
<p>Standard are grouped in <strong>families</strong>, which are referred to by a number, followed by a dot and another number identifying a more specific area and its <strong>working group</strong>.</p>
<p><strong>IEEE 802</strong> family of standard deals with LANs and MANs. Particularly interesting to us are <strong>802.3 (Ethernet)</strong> and <strong>802.11 (Wireless LAN)</strong> standards.</p>
</section>
<section>
<h2>ISO</h2>
<p>The <strong>International Organization for Standardization</strong> is the largest developer of standards, covering almost every possible field, products and services.</p>
<p>ISO is best known in networking for developing the <strong>OSI, Open System Interconnection reference model</strong>.</p>
<p>Its purposes was to produce a <strong>layered framework for networking protocols</strong> but also applying in a full protocol suite for the Internet. But <strong>TCP/IP already won</strong>...</p>
<p><strong>ISO 9660</strong> should ring a bell if you ever burned a CD.</p>
</section>
<section>
<h2>EIA, TIA, ITU-T</h2>
<p>The <strong>EIA, Electonic Induestries Alliance</strong>, is best known for standardizing wiring and connectors and <strong>mounting racks</strong>.</p>
<p>The <strong>TIA, Telecommunications Industry Association</strong>, collaborates with the EIA and produces standards for radio, cellular and satellite equipment, and also VoIP devices.</p>
<p>The <strong>International Telecommunications Union-Telecommunication Standardization Sector (ITU-T)</strong> is responsible for country codes for international dialing and broadband communication standards.</p>
</section>
</section>
<section>
<section>
<h2>Layered Models</h2>
<img src="http://i.imgur.com/a0omhOa.gif" style="float: left; width: 50%; height: 50%;">
<p>A <strong>layered model</strong> for protocols helps to visualize what are their operation and the interactions between them.</p>
<p>A <strong>protocol model</strong> describes how an actual protocol suite operates. A <strong>reference model</strong> describes no particular suite, focusing on the highest possible level of <strong>abstraction</strong>.</p>
</section>
<section>
<h2>Benefits of Layered Models</h2>
<ul>
<li><strong>Reduced complexity</strong>: major concepts are distilled into smaller ones.</li>
<li><strong>Standard Interfaces</strong>: functions on one layer and interactions with other layers are clear.</li>
<li><strong>Easy to learn</strong>: Single, smaller aspects of protocols can be independently discussed.</li>
<li><strong>Easier interoperability</strong>: Hardware and software can be developed with the peace of mind that it will work with anything else.</li>
<li><strong>Modularity</strong>: implementations can be developed indipendently, by multiple parties, and easily replaced.</li>
</ul>
</section>
</section>
<section>
<h2>OSI Reference Model</h2>
<p>ISO's intention was to develop a <strong>framework for protocol suites</strong>, and also recommending a <strong>protocol suite for Internetworking</strong>. It was only half a success, TCP/IP taking the second half.</p>
<p>OSI 7 Layers Model, defining <strong>domains, functions and interactions between each layer and the ones directly below and above</strong>, has helped developed all types of protocols and networks.</p>
<p>Its <strong>7 Layers</strong> are: Physical, Data Link, Network, Transport, Session, Presentation, Application.</p>
</section>
<section>
<section>
<h2>OSI Reference Model</h2>
<h3>L1: Physical</h3>
<p>The Physical Layer deals with the hardware: it describes the mechanics of the actual, practical, <strong>activation, maintainance and deactivation of a physical connection</strong> for transmitting and receiving digital bits.</p>
</section>
<section>
<h2>OSI Reference Model</h2>
<h3>L2: Data Link</h3>
<p>Once you are can trasmit your bits from two points on a common media, they can't be random bits. They need to have a <strong>structure</strong>, they need to <strong>access the channel</strong> reliably. Data link protocols deals with producing the bits into frames for transmission over the physical media.</p>
</section>
<section>
<h2>OSI Reference Model</h2>
<h3>L3: Network</h3>
<p>The Network Layer describes protocols to <strong>identify</strong> the end devices that needs to communicate and making individual <strong>packets of data travelling</strong> from one to the other(s).</p>
</section>
<section>
<h2>OSI Reference Model</h2>
<h3>L4: Transport</h3>
<p>The transport layer protocols define <strong>how to segment the data</strong> belonging to each communication, transfer them and then reassembling them at the destination end device.</p>
</section>
<section>
<h2>OSI Reference Model</h2>
<h3>L5: Session</h3>
<p>The first four layers can successfully deliver data from one end device to another, but it's this layer that allows two applications to <strong>coordinate their dialogue and data exchange</strong>.</p>
<p>Session layer deals with <strong>authentication</strong>, <strong>authorization</strong> and also <strong>session restoration</strong>.</p>
</section>
<section>
<h2>OSI Reference Model</h2>
<h3>L6: Presentation</h3>
<p>Applications want to transfer their data, but that raises the problem of having an <strong>established and common way to represent those data</strong>. Session layer takes care of this.</p>
</section>
<section>
<h2>OSI Reference Model</h2>
<h3>L7: Application</h3>
<p>The Application is the <strong>interface between the software and the transmission of data over a network</strong>. It initiates the process of running through the stack of protocols on behalf of the user application.</p>
<p>Making two Application layers speak one another it's the ultimate goal: <strong>process-to-process</strong> communication.</p>
</section>
</section>
<section>
<section>
<h2>TCP/IP Protocol Model</h2>
<img src="http://i.imgur.com/DrBlKz8.gif">
<p>TCP/IP only defines 4 layers: <strong>Network Access (Link), Internet, Transport and Application</strong>.</p>
<p>It closely match OSI model in Network and Transport layers, but it aggregates many functions in Network Access and Application layers.</p>
</section>
<section>
<h2>TCP/IP vs. ISO/OSI</h2>
<ul>
<li><u>TCP/IP Network (or Link) Layer</u> roughly includes <u>ISO/OSI L1+L2</u>, but it doesn't go into the same level of detail.</li>
<ul>
<li>In the TCP/IP <strong><em>Updated Model</em></strong> the original network access layer has been splitted and the ISO/OSI Data Link and Physical layers have been adopted.</li>
</ul>
<li><u>TCP/IP Internet Layer</u> can be mapped to <u>ISO/OSI L3</u>.</li>
<li><u>TCP/IP Transport Layer is ISO/OSI L4</u>, but also includes some session management from L5.</li>
<li>The functions of <u>TCP/IP Application Layer</u> are those of <u>L5+L6+L7</u> in the ISO/OSI model.</li>
</ul>
</section>
</section>
<section>
<h2>Why Segmenting Data?</h2>
<p>One long, continuous stream of bits would mean:</p>
<ul>
<li>Busy channels for a long time
<li>Full retransmission in case of errors
</ul>
<p>Segmenting data into smaller pieces makes them <strong>more managable</strong> and avoids the two issues above.</p>
<p>By segmenting you then need <strong>multiplexing</strong> to interleave different communication's segments over a channel.</p>
</section>
<section>
<h2>Protocol Data Units (PDU)</h2>
<p>During the <em>encapsulation</em> process, application data gets <strong>additional information as it passes through layers</strong>.</p>
<p>After protocols add information to the data (in the form of <strong><em>headers</em></strong>), the data as a whole will assume <strong>a form closely related to the protocol</strong>, called PDU (<em>Protocol Data Unit</em>).</p>
<p>PDUs go by different names at different layers:</p>
<ul>
<li><strong>Data</strong> - General term for Application Layer (L7PDU).</li>
<li><strong>Segment</strong> - PDU of the Transport Layer (L4PDU).</li>
<li><strong>Packet</strong> - PDU of the Network Layer (L3PDU).</li>
<li><strong>Frame</strong> - PDU of the Data Link Layer (L2PDU).</li>
<li><strong>Bits</strong> - Physical Layer PDU.</li>
</ul>
</section>
<section>
<section>
<h2>Addresses</h2>
<p>Network and Data Link layers are those responsible for <strong>uniquely identifying the source and destination</strong> of the data exchange.</p>
<p>They <strong>both do that using addresses</strong>, but of different kind and for different purposes.</p>
<img src="http://i.imgur.com/xDdU0zT.gif">
</section>
<section>
<h2>Network Address: IP Addresses</h2>
<p>Network addresses are <strong>logical</strong> addresses (not tied to a specific device) required to deliver <u>a packet</u> from source to destination, either on the same or <strong>different networks</strong>.</p>
<p><strong>IP addresses</strong> are <u>structured</u> and delivery operates by moving (<em>routing</em>) packets <u>according to their structure</u>.</p>
<ul>
<li>The <u>network part</u> (192.168.1) is used by router to identify and <strong>reach the destination network</strong>.
<li>The <u>host part</u> (.1) is used by the <strong>last router</strong> to reach the destination host.
</ul>
<p>You need two of those IP addresses: source and destination.</p>
</section>
<section>
<h2>Data Link Address: MAC Addresses</h2>
<p>Data Link Layer (DLL or L2) addresses, also known as <strong>physical addresses</strong> (tied to the NIC), are used to <strong>reach another network interface in the same network</strong> (<em>link</em>).</p>
<p>DLL addresses, like <strong>MAC addresses</strong>, have <u>no structure</u>: 00:AA:BB:11:FF:01 and 00:AA:BB:11:FF:02 could be on different planets, for all we know.</p>
<p>L2 delivery operates on the <u>assumption</u> that end devices can <strong>communicate directly over the same link</strong>, just by sending frames with correct addressing onto the wire.</p>
<p>You need 2 MAC addresses: source and destination.</p>
</section>
</section>
<section>
<section>
<h2>Role of L2/L3 Addresses</h2>
<h3>In the same network</h3>
<div><img src="https://i.imgur.com/tTqWLbM.jpg"></div>
<ul>
<li><strong>L2 Src</strong>: 00:15:5F:3C:A2:68 (PC A NIC)</li>
<li><strong>L2 Dst</strong>: 00:44:C8:59:12:74 (PC B NIC)</li>
<li><strong>L3 Src</strong>: 192.168.1.3 (PC A IP)</li>
<li><strong>L3 Dst</strong>: 192.168.1.62 (PC B IP)</li>
</ul>
</section>
<section>
<h2>Role of L2/L3 Addresses</h2>
<h3>Over different networks (1)</h3>
<div><img src="https://i.imgur.com/tTqWLbM.jpg"></div>
<ul>
<li><strong>L2 Src</strong>: 00:15:5F:3C:A2:68 (PC A NIC)</li>
<li><strong>L2 Dst</strong>: 00:22:54:28:6F:FA (GW NIC, same net as PC A NIC)</li>
<li><strong>L3 Src</strong>: 192.168.1.3 (PC A IP)</li>
<li><strong>L3 Dst</strong>: 10.87.38.185 (PC C IP)</li>
</ul>
</section>
<section>
<h2>Role of L2/L3 Addresses</h2>
<h3>Over different networks (2)</h3>
<div><img src="https://i.imgur.com/tTqWLbM.jpg"></div>
<ul>
<li><strong>L2 Src</strong>: 00:85:CC:D3:E2:34 (GW NIC, same net as PC C)</li>
<li><strong>L2 Dst</strong>: 00:13:81:FC:F6:1A (PC C NIC)</li>
<li><strong>L3 Src</strong>: 192.168.1.3 (PC A IP, unchanged)</li>
<li><strong>L3 Dst</strong>: 10.87.38.185 (PC C IP, unchanged)</li>
</ul>
</section>
</section>
<section>
<h2>Default Gateway</h2>
<p>A <strong><em>gateway</em></strong> is a host (a router, almost always) in a network that <strong>knows how to reach other (specific) networks</strong>.</p>
<p>The <strong><em>default gateway</em></strong> is the router to which a host on a network will send <strong>every frame for which it has no specific gateway</strong>.</p>
<p>The default gateway is <em>presumed</em> to know what to do.</p>
<p>Default gateway either <strong>routes the packet</strong> to final destination or to another router, called <strong>next hop</strong>.</p>
<p><u>L2 addressing information is rewritten</u> at every hop.</p>
</section>
<section>
<h2>How do I get to know these addresses?</h2>
<p>A host needs to <strong>know both the logical and physical addresses of the destination host</strong> to be able to generate and send the frame.</p>
<p>For IP addresses, you probably know IP addresses on your own network and you enter them <strong>manually</strong>.</p>
<p>For remote networks, you can learn IP address by configuring your device to use <strong>DNS</strong> (<em>Domain Name System</em>).</p>
<p>Remembering MAC Addresses would be much more trickier, but fortunately <strong>ARP</strong> (<em>Address Resolution Protocol</em>) relieves you of that need.</p>
</section>
<section>
<section>
<h2>Why Don't We Go MAC-only?</h2>
<p>Think about it: we have <u>2 different sets of addresses both able to globally and uniquely identify hosts</u>. Why?</p>
<ul>
<li>For MAC addresses to work globally, every router <u>would need to know every MAC address ever released</u> and where it is. Sloooow.</li>
<li>It would not be possible to shorten that list by <u>"grouping" MAC addresses: there is no criteria/structure</u> to do it.</li>
<li>You <u>can't move a MAC address</u> from a host to another.</li>
<li>There are <u>L2 protocols other than Ethernet</u>, you know...</li>
<!--
<li>MAC addresses makes sense to use because you can't really skip <em>communicating in the same network</em>.</li>
-->
</ul>
</section>
<section>
<h2>Why Don't We Go IP-only?</h2>
<ul>
<li>Actually, <em>we could</em>. There are vocal proposal for networking based on L3-only addressing.</li>
<li>There are <u>not enough IPv4 addresses for every NIC</u>. <strong>IPv6 would solve this</strong>, but we've been stuck with IPv4 for 30+ years.</li>
<li>Also, <u>checking MAC addresses used to be much faster than checking IPs</u> (because of the lack of structure to analyze), but <strong>not anymore</strong>.</li>
</ul>
<p><strong>If we started from scratch today, we could probably just use IPs</strong>.</p>
<p>The reality is that the <strong>Ethernet+IP addressing has been working pretty well</strong> for ~40 years and almost everything has been based on it. So the urge to change it's minimal.</p>
</section>
</section>
<section>
<h1>End of Lesson</h1>
</section>
</div>
</div>
<script src="lib/js/head.min.js"></script>
<script src="js/reveal.js"></script>
<script>
// More info https://github.com/hakimel/reveal.js#configuration
Reveal.initialize({
controls: true,
progress: true,
history: true,
center: true,
transition: 'slide', // none/fade/slide/convex/concave/zoom
// More info https://github.com/hakimel/reveal.js#dependencies
dependencies: [
{ src: 'lib/js/classList.js', condition: function() { return !document.body.classList; } },
{ src: 'plugin/markdown/marked.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
{ src: 'plugin/markdown/markdown.js', condition: function() { return !!document.querySelector( '[data-markdown]' ); } },
{ src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } },
{ src: 'plugin/zoom-js/zoom.js', async: true },
{ src: 'plugin/notes/notes.js', async: true }
]
});
</script>
</body>
</html>