597 lines
No EOL
45 KiB
HTML
597 lines
No EOL
45 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
|
||
|
||
|
||
<html lang="en">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
||
<title>5.5. Internet Layer: IP — Computer Systems Fundamentals</title>
|
||
|
||
<link rel="stylesheet" href="_static/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous" />
|
||
<link rel="stylesheet" href="_static/css/pygments.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/normalize.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../JSAV/css/JSAV.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaMOD-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/jquery-1.11.4-smoothness-ui.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaStyle-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/csf.css" type="text/css" />
|
||
|
||
<style>
|
||
.underline { text-decoration: underline; }
|
||
</style>
|
||
|
||
<script type="text/javascript">
|
||
var DOCUMENTATION_OPTIONS = {
|
||
URL_ROOT: './',
|
||
VERSION: '0.4.1',
|
||
COLLAPSE_INDEX: false,
|
||
FILE_SUFFIX: '.html',
|
||
HAS_SOURCE: true
|
||
};
|
||
</script>
|
||
|
||
<script type="text/x-mathjax-config">
|
||
MathJax.Hub.Config({
|
||
tex2jax: {
|
||
inlineMath: [['$','$'], ['\\(','\\)']],
|
||
displayMath: [ ['$$','$$'], ["\\[","\\]"] ],
|
||
processEscapes: true
|
||
},
|
||
"HTML-CSS": {
|
||
scale: "80"
|
||
}
|
||
});
|
||
</script>
|
||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||
<link rel="index" title="Index" href="genindex.html" />
|
||
<link rel="search" title="Search" href="search.html" />
|
||
<link rel="index" title="Computer Systems Fundamentals" href="index.html" />
|
||
<link rel="next" title="6. Link Layer" href="LinkLayer.html" />
|
||
<link rel="prev" title="4. Network Security Fundamentals" href="NetSec.html" />
|
||
|
||
</head><body>
|
||
|
||
<nav class="navbar navbar-expand-md navbar-dark navbar-custom fixed-top">
|
||
|
||
<a class="navbar-brand py-0" href="index.html"><img src="_static/CSF-Logo-Square-Text.png" alt="OpenCSF Logo" height="40em" class="py-1 px-2 mb-0 align-center rounded-lg bg-white" /></a>
|
||
<!-- Show a navbar toggler on mobile -->
|
||
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#defaultNavbars" aria-controls="defaultNavbars" aria-expanded="false" aria-label="Toggle navigation">
|
||
<span class="navbar-toggler-icon"></span>
|
||
</button>
|
||
<div class="collapse navbar-collapse" id="defaultNavbars">
|
||
<ul class="navbar-nav mr-auto">
|
||
<li class="nav-item dropdown">
|
||
<a class="nav-link dropdown-toggle jmu-gold rounded" href="NetLayer.html#" id="navbarDropdownChapters" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">Contents</a>
|
||
<div class="dropdown-menu scrollable-menu" role="menu" aria-labelledby="navbarDropdownChapters">
|
||
<a class="dropdown-item" tabindex="-1" href="NetLayer.html#"><b>Chapter 1</b></a>
|
||
<a class="dropdown-item" href="IntroConcSysOverview.html"> 1.1. Introduction to Concurrent Systems</a>
|
||
<a class="dropdown-item" href="SysAndModels.html"> 1.2. Systems and Models</a>
|
||
<a class="dropdown-item" href="Themes.html"> 1.3. Themes and Guiding Principles</a>
|
||
<a class="dropdown-item" href="Architectures.html"> 1.4. System Architectures</a>
|
||
<a class="dropdown-item" href="StateModels.html"> 1.5. State Models in UML</a>
|
||
<a class="dropdown-item" href="SequenceModels.html"> 1.6. Sequence Models in UML</a>
|
||
<a class="dropdown-item" href="StateModelImplementation.html"> 1.7. Extended Example: State Model Implementation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 2</b></a>
|
||
<a class="dropdown-item" href="ProcessesOverview.html"> 2.1. Processes and OS Basics</a>
|
||
<a class="dropdown-item" href="Multiprogramming.html"> 2.2. Processes and Multiprogramming</a>
|
||
<a class="dropdown-item" href="KernelMechanics.html"> 2.3. Kernel Mechanics</a>
|
||
<a class="dropdown-item" href="Syscall.html"> 2.4. System Call Interface</a>
|
||
<a class="dropdown-item" href="ProcessCycle.html"> 2.5. Process Life Cycle</a>
|
||
<a class="dropdown-item" href="UnixFile.html"> 2.6. The UNIX File Abstraction</a>
|
||
<a class="dropdown-item" href="EventsSignals.html"> 2.7. Events and Signals</a>
|
||
<a class="dropdown-item" href="Extended2Processes.html"> 2.8. Extended Example: Listing Files with Processes</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 3</b></a>
|
||
<a class="dropdown-item" href="IPCOverview.html"> 3.1. Concurrency with IPC</a>
|
||
<a class="dropdown-item" href="IPCModels.html"> 3.2. IPC Models</a>
|
||
<a class="dropdown-item" href="Pipes.html"> 3.3. Pipes and FIFOs</a>
|
||
<a class="dropdown-item" href="MMap.html"> 3.4. Shared Memory With Memory-mapped Files</a>
|
||
<a class="dropdown-item" href="POSIXvSysV.html"> 3.5. POSIX vs. System V IPC</a>
|
||
<a class="dropdown-item" href="MQueues.html"> 3.6. Message Passing With Message Queues</a>
|
||
<a class="dropdown-item" href="ShMem.html"> 3.7. Shared Memory</a>
|
||
<a class="dropdown-item" href="IPCSems.html"> 3.8. Semaphores</a>
|
||
<a class="dropdown-item" href="Extended3Bash.html"> 3.9. Extended Example: Bash-lite: A Simple Command-line Shell</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 4</b></a>
|
||
<a class="dropdown-item" href="SocketsOverview.html"> 4.1. Networked Concurrency</a>
|
||
<a class="dropdown-item" href="FiveLayer.html"> 4.2. The TCP/IP Internet Model</a>
|
||
<a class="dropdown-item" href="NetApps.html"> 4.3. Network Applications and Protocols</a>
|
||
<a class="dropdown-item" href="Sockets.html"> 4.4. The Socket Interface</a>
|
||
<a class="dropdown-item" href="TCPSockets.html"> 4.5. TCP Socket Programming: HTTP</a>
|
||
<a class="dropdown-item" href="UDPSockets.html"> 4.6. UDP Socket Programming: DNS</a>
|
||
<a class="dropdown-item" href="AppBroadcast.html"> 4.7. Application-Layer Broadcasting: DHCP</a>
|
||
<a class="dropdown-item" href="Extended4CGI.html"> 4.8. Extended Example: CGI Web Server</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 5</b></a>
|
||
<a class="dropdown-item" href="InternetOverview.html"> 5.1. The Internet and Connectivity</a>
|
||
<a class="dropdown-item" href="AppLayer.html"> 5.2. Application Layer: Overlay Networks</a>
|
||
<a class="dropdown-item" href="TransLayer.html"> 5.3. Transport Layer</a>
|
||
<a class="dropdown-item" href="NetSec.html"> 5.4. Network Security Fundamentals</a>
|
||
<a class="dropdown-item" href="NetLayer.html"> 5.5. Network Layer: IP</a>
|
||
<a class="dropdown-item" href="LinkLayer.html"> 5.6. Link Layer</a>
|
||
<a class="dropdown-item" href="Wireless.html"> 5.7. Wireless Connectivity: Wi-Fi, Bluetooth, and Zigbee</a>
|
||
<a class="dropdown-item" href="Extended5DNS.html"> 5.8. Extended Example: DNS client</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 6</b></a>
|
||
<a class="dropdown-item" href="ThreadsOverview.html"> 6.1. Concurrency with Multithreading</a>
|
||
<a class="dropdown-item" href="ProcVThreads.html"> 6.2. Processes vs. Threads</a>
|
||
<a class="dropdown-item" href="RaceConditions.html"> 6.3. Race Conditions and Critical Sections</a>
|
||
<a class="dropdown-item" href="POSIXThreads.html"> 6.4. POSIX Thread Library</a>
|
||
<a class="dropdown-item" href="ThreadArgs.html"> 6.5. Thread Arguments and Return Values</a>
|
||
<a class="dropdown-item" href="ImplicitThreads.html"> 6.6. Implicit Threading and Language-based Threads</a>
|
||
<a class="dropdown-item" href="Extended6Input.html"> 6.7. Extended Example: Keyboard Input Listener</a>
|
||
<a class="dropdown-item" href="Extended6Primes.html"> 6.8. Extended Example: Concurrent Prime Number Search</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 7</b></a>
|
||
<a class="dropdown-item" href="SynchOverview.html"> 7.1. Synchronization Primitives</a>
|
||
<a class="dropdown-item" href="CritSect.html"> 7.2. Critical Sections and Peterson's Solution</a>
|
||
<a class="dropdown-item" href="Locks.html"> 7.3. Locks</a>
|
||
<a class="dropdown-item" href="Semaphores.html"> 7.4. Semaphores</a>
|
||
<a class="dropdown-item" href="Barriers.html"> 7.5. Barriers</a>
|
||
<a class="dropdown-item" href="Condvars.html"> 7.6. Condition Variables</a>
|
||
<a class="dropdown-item" href="Deadlock.html"> 7.7. Deadlock</a>
|
||
<a class="dropdown-item" href="Extended7Events.html"> 7.8. Extended Example: Event Log File</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 8</b></a>
|
||
<a class="dropdown-item" href="SynchProblemsOverview.html"> 8.1. Synchronization Patterns and Problems</a>
|
||
<a class="dropdown-item" href="SynchDesign.html"> 8.2. Basic Synchronization Design Patterns</a>
|
||
<a class="dropdown-item" href="ProdCons.html"> 8.3. Producer-Consumer Problem</a>
|
||
<a class="dropdown-item" href="ReadWrite.html"> 8.4. Readers-Writers Problem</a>
|
||
<a class="dropdown-item" href="DiningPhil.html"> 8.5. Dining Philosophers Problem and Deadlock</a>
|
||
<a class="dropdown-item" href="CigSmokers.html"> 8.6. Cigarette Smokers Problem and the Limits of Semaphores and Locks</a>
|
||
<a class="dropdown-item" href="Extended8ModExp.html"> 8.7. Extended Example: Parallel Modular Exponentiation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 9</b></a>
|
||
<a class="dropdown-item" href="ParallelDistributedOverview.html"> 9.1. Parallel and Distributed Systems</a>
|
||
<a class="dropdown-item" href="ParVConc.html"> 9.2. Parallelism vs. Concurrency</a>
|
||
<a class="dropdown-item" href="ParallelDesign.html"> 9.3. Parallel Design Patterns</a>
|
||
<a class="dropdown-item" href="Scaling.html"> 9.4. Limits of Parallelism and Scaling</a>
|
||
<a class="dropdown-item" href="DistTiming.html"> 9.5. Timing in Distributed Environments</a>
|
||
<a class="dropdown-item" href="DistDataStorage.html"> 9.6. Reliable Data Storage and Location</a>
|
||
<a class="dropdown-item" href="DistConsensus.html"> 9.7. Consensus in Distributed Systems</a>
|
||
<a class="dropdown-item" href="Extended9Blockchain.html"> 9.8. Extended Example: Blockchain Proof-of-Work</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Appendix A</b></a>
|
||
<a class="dropdown-item" href="CLangOverview.html"> A.1. C Language Reintroduction</a>
|
||
<a class="dropdown-item" href="Debugging.html"> A.2. Documentation and Debugging</a>
|
||
<a class="dropdown-item" href="BasicTypes.html"> A.3. Basic Types and Pointers</a>
|
||
<a class="dropdown-item" href="Arrays.html"> A.4. Arrays, Structs, Enums, and Type Definitions</a>
|
||
<a class="dropdown-item" href="Functions.html"> A.5. Functions and Scope</a>
|
||
<a class="dropdown-item" href="Pointers.html"> A.6. Pointers and Dynamic Allocation</a>
|
||
<a class="dropdown-item" href="Strings.html"> A.7. Strings</a>
|
||
<a class="dropdown-item" href="FunctionPointers.html"> A.8. Function Pointers</a>
|
||
<a class="dropdown-item" href="Files.html"> A.9. Files</a>
|
||
</div>
|
||
</li>
|
||
|
||
|
||
|
||
</ul>
|
||
</div>
|
||
|
||
<ul class="navbar-nav flex-row ml-md-auto d-none d-md-flex">
|
||
<li class="nav-item"><a class="nav-link jmu-gold" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/Books/csf/source/NetLayer.rst"
|
||
target="_blank" rel="nofollow">Show Source</a></li>
|
||
|
||
</ul>
|
||
</nav>
|
||
|
||
|
||
<div class="container center">
|
||
«  <a id="prevmod" href="NetSec.html">5.4. Network Security Fundamentals</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod" href="LinkLayer.html">5.6. Link Layer</a>  »
|
||
|
||
</div>
|
||
<br />
|
||
|
||
|
||
|
||
<script type="text/javascript" src="_static/js/jquery-2.1.4.min.js"></script>
|
||
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||
<script type="text/javascript" src="_static/js/jquery-1.11.4-ui.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/forge-0.7.0.min.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/jquery.transit.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/raphael.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/build/JSAV-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/config.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaUtils-min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaMOD-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-4.13.0.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-selection-multi.v1.min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/dataStructures.js"></script>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<script>ODSA.SETTINGS.DISP_MOD_COMP = true;ODSA.SETTINGS.MODULE_NAME = "NetLayer";ODSA.SETTINGS.MODULE_LONG_NAME = "Internet Layer: IP";ODSA.SETTINGS.MODULE_CHAPTER = "The Internet and Connectivity"; ODSA.SETTINGS.BUILD_DATE = "2021-06-11 17:38:24"; ODSA.SETTINGS.BUILD_CMAP = false;JSAV_OPTIONS['lang']='en';JSAV_EXERCISE_OPTIONS['code']='java';</script><div class="section" id="internet-layer-ip">
|
||
<h1>5.5. Internet Layer: IP<a class="headerlink" href="NetLayer.html#internet-layer-ip" title="Permalink to this headline">¶</a></h1>
|
||
<p>Transport-layer protocols, such as TCP and UDP, focus on the logical end-to-end communication
|
||
between processes. Consequently, these protocols still avoid the fact that network sockets are
|
||
exchanging data between different hosts. Instead, the transport layer still behaves very much like
|
||
local forms of IPC. Internet layer protocols begin to remove this layer of abstraction. That is, the
|
||
Internet layer extends the process-to-process structure of the transport layer with host-to-host
|
||
communication.</p>
|
||
<p>The Internet layer consists of two interacting components. The <a class="reference internal" href="Glossary.html#term-data-plane"><span class="xref std std-term">data plane</span></a> provides the
|
||
overall structure of the network, assigning addresses to hosts. The <a class="reference internal" href="Glossary.html#term-internet-protocol"><span class="xref std std-term">Internet Protocol</span></a> (IP)
|
||
is the primary protocol for the data plane; IP identifies the logical location of a host within the
|
||
Internet, both locally and across network boundaries. The <a class="reference internal" href="Glossary.html#term-control-plane"><span class="xref std std-term">control plane</span></a> protocols define the
|
||
routing paths that messages take through the network from a high level. These protocols include
|
||
<a class="reference internal" href="Glossary.html#term-open-shortest-path-first"><span class="xref std std-term">Open Shortest Path First</span></a> (OSPF), <a class="reference internal" href="Glossary.html#term-routing-information-protocol"><span class="xref std std-term">Routing Information Protocol</span></a> (RIP), and
|
||
<a class="reference internal" href="Glossary.html#term-border-gateway-protocol"><span class="xref std std-term">Border Gateway Protocol</span></a> (BGP). We will provide a brief overview of the key features of the
|
||
control plane protocols, but we will not be discussing the details of their operation.</p>
|
||
<div class="section" id="ip-addresses-and-subnets">
|
||
<h2>5.5.1. IP Addresses and Subnets<a class="headerlink" href="NetLayer.html#ip-addresses-and-subnets" title="Permalink to this headline">¶</a></h2>
|
||
<p>In the previous chapter, we introduced the notion of an IP address as an identifier that can be used
|
||
to locate a host within the network. IP version 4 (IPv4), defined in RFC 791, specifies addresses as
|
||
32-bit values. For readability purposes, IPv4 addresses are typically written in dotted-decimal
|
||
form; for example, the address <code class="docutils literal notranslate"><span class="pre">0x01020304</span></code> would be more commonly written as 1.2.3.4. The 32-bit
|
||
length creates a serious problem for IPv4, as this size means there are only 4,294,967,296 possible
|
||
IPv4 addresses. While the exact number of devices connected to the Internet is impossible to
|
||
determine, all estimates are significantly higher than this limit of 4 billion; a more accurate
|
||
estimate would be on the order of 50 billion.</p>
|
||
<p>As the number of connected devices grew, one technique to compensate for the limits of IPv4 was to
|
||
re-use addresses by dividing the Internet into multiple <a class="reference internal" href="Glossary.html#term-subnet"><span class="xref std std-term">subnets</span></a>, particularly private
|
||
subnets. Private subnets are defined by a range of IP addresses that cannot be reached from hosts
|
||
outside of that subnet. Subnets can be denoted using the <a class="reference internal" href="Glossary.html#term-classless-inter-domain-routing"><span class="xref std std-term">Classless Inter-Domain Routing</span></a>
|
||
(CIDR) notation, in which a dotted-decimal value is appended with /n, where n is the length of the
|
||
bit prefix for that subnet. For instance, 1.2.3.0/24 would denote the range of addresses from
|
||
1.2.3.0 up to 1.2.3.255, because the first 24 bits must match the <a class="reference internal" href="Glossary.html#term-subnet-mask"><span class="xref std std-term">subnet mask</span></a>, which is the
|
||
bitmask (255.255.255.0 in this case) that can be applied to any address in the subnet.</p>
|
||
<p>Readers who have set up a home wireless router may be familiar with the 192.168.0.0/16 subnet. This
|
||
CIDR notation means the all devices that connect to the wireless router are assigned IP addresses
|
||
that range from 192.168.0.0 to 192.168.255.255; the first 16 bits are designated to be identical for
|
||
all devices. The IPv4 specification declares that 192.168.0.0/16 is a range of addresses that can
|
||
only be used for a private subnet; similarly, 10.0.0.0/8 and 172.16.0.0/12 are also reserved.
|
||
Choosing between the three ranges depends on the number of devices that will be connected. The
|
||
192.168.0.0/16 subnet allows 16 bits to vary, so the subnet can host $2^{16}$ (65,536) possible
|
||
devices; this size is adequate for a home router. However, large organizations with thousands of
|
||
workers may require more than that. Using 172.16.0.0/12 allows for up to $2^{20}$ (1,048,576)
|
||
devices because 24 bits can vary; 10.0.0.0/8 supports up to $2^{24}$ (16,777,216) devices.</p>
|
||
<p>It may seem odd to allow the same IP address to be reused repeatedly. Specifically, if two devices
|
||
share the same IP address, it may seem that there is no way to tell them apart. <a href="NetLayer.html#netprivate">Figure 5.5.1</a> illustrates how this situation can be resolved. In this figure, Alice and Bob both
|
||
have home networks connected to the same ISP. In both of their homes, Alice and Bob have wireless
|
||
routers that assign addresses to devices that either connect wirelessly (such as a laptop) or via a
|
||
cable (such as a desktop). Note that both networks have a device with the IP address 192.168.1.2.
|
||
These IP addresses were assigned by the router using DHCP when the device joined the network. As
|
||
these subnet ranges are private, Alice’s devices and Bob’s devices have no knowledge of each other.
|
||
Alice’s phone (192.168.1.5) cannot communicate directly with Bob’s laptop at address 192.168.1.7. To
|
||
Alice’s devices, Bob’s devices simply do not exist.</p>
|
||
<div class="figure mb-2 align-right" id="id1" style="width: 45%">
|
||
<span id="netprivate"></span><a class="reference internal image-reference" href="_images/CSF-Images.5.9.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="Two private subnets with common IPv4 internal addresses" src="_images/CSF-Images.5.9.png" style="width: 95%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 5.5.1: Two private subnets with common IPv4 internal addresses</span></p>
|
||
</div>
|
||
<p>When any device needs to access a resource outside the subnet (such as the Internet in general), the
|
||
router acts as a <a class="reference internal" href="Glossary.html#term-gateway-router"><span class="xref std std-term">gateway</span></a>, using the IP address assigned by their ISP rather than the private
|
||
address. The router contains a <a class="reference internal" href="Glossary.html#term-network-address-translation"><span class="xref std std-term">network address translation</span></a> (NAT) service that performs
|
||
<a class="reference internal" href="Glossary.html#term-ip-masquerading"><span class="xref std std-term">IP masquerading</span></a>. In this approach, the router has two IP addresses: 192.168.1.0 is used for
|
||
communication with other devices in Alice’s home, while 75.3.28.14 is the IP address (assigned by
|
||
the ISP) the router uses with the outside world. If any of Alice’s devices try to contact a website
|
||
or to communicate with a P2P client on Bob’s network, Alice’s packets appear to be coming from
|
||
75.3.28.14—the IP external IP address of Alice’s router—rather than a 192.168.0.0/16 address. When
|
||
data is sent back to Alice’s device, her router consults the NAT data structures to forward the
|
||
packet to the correct device.</p>
|
||
<p>NAT and subnets provide one mechanism to deal with the limited number of possible IPv4 addresses,
|
||
but it only provides a temporary solution. As a more long-term approach, IETF created IPv6,
|
||
specified in RFC 2460, as the successor to IPv4. IPv6 increased the length of addresses from 32 bits
|
||
to 128 bits. This increased the range of possible addresses from just over 4 billion to over $3 *
|
||
10^{38}$, an address space size that will not be exhausted in the foreseeable future. Given that
|
||
private subnets can provide an element of security by keeping certain devices hidden from the
|
||
greater Internet, IPv6 continues to support this feature, referred to as <a class="reference internal" href="Glossary.html#term-unique-local-address"><span class="xref std std-term">unique local
|
||
addresses</span></a> (ULAs). The CIDR address fd00::/8 defines the range of ULAs.</p>
|
||
<p>Note, though, that this CIDR address does not allow local networks to host up to $2^{120}$ devices.
|
||
Instead, addresses in this range must adhere to the structure shown in <a class="reference external" href="NetLayer.html#tbl5-9">Table 5.9</a>. The
|
||
first eight bits denote the value <code class="docutils literal notranslate"><span class="pre">0xfd</span></code>, which constitutes the <code class="docutils literal notranslate"><span class="pre">Prefix</span></code> <code class="docutils literal notranslate"><span class="pre">1111110</span></code> and the
|
||
<code class="docutils literal notranslate"><span class="pre">L</span></code> bit <code class="docutils literal notranslate"><span class="pre">1</span></code>, thereby designating a ULA. (Setting <code class="docutils literal notranslate"><span class="pre">L</span></code> to <code class="docutils literal notranslate"><span class="pre">0</span></code> is reserved for future use.) The
|
||
<code class="docutils literal notranslate"><span class="pre">Global</span> <span class="pre">ID</span></code> is a 40-bit pseudo-random assigned value that is intended to identify private networks
|
||
uniquely. Within that private network, the next 16 bits can be used to denote separate private
|
||
subnets. This structure then leaves 64 bits for individual devices, allowing up to $2^{64}$ ($1.8 *
|
||
10^{19}$) devices.</p>
|
||
<center>
|
||
<table class="table table-bordered">
|
||
<thead class="jmu-dark-purple-bg text-light">
|
||
<tr>
|
||
<th class="py-0 center">7 bits</th>
|
||
<th class="py-0 center">1 bit</th>
|
||
<th class="py-0 center">40 bits</th>
|
||
<th class="py-0 center">16 bits</th>
|
||
<th class="py-0 center">64 bits</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="py-0 center"><code>Prefix</code></td>
|
||
<td class="py-0 center"><code>L</code></td>
|
||
<td class="py-0 center"><code>Global ID</code></td>
|
||
<td class="py-0 center"><code>Subnet ID</code></td>
|
||
<td class="py-0 center"><code>Interface ID</code></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<p>
|
||
Table 5.9: Structure of a ULA in IPv6
|
||
</p>
|
||
</center></div>
|
||
<div class="section" id="ip-packet-formats">
|
||
<h2>5.5.2. IP Packet Formats<a class="headerlink" href="NetLayer.html#ip-packet-formats" title="Permalink to this headline">¶</a></h2>
|
||
<p>As with TCP and UDP, IP attaches a header to a transport-layer segment (the payload) for delivery.
|
||
<a class="reference external" href="NetLayer.html#tbl5-10">Table 5.10</a> shows the structure of an IPv4 packet. The source and destination address
|
||
fields contain the 32-bit IPv4 address.</p>
|
||
<center>
|
||
<table class="table table-bordered">
|
||
<thead class="jmu-dark-purple-bg text-light">
|
||
<tr>
|
||
<th class="py-0 center" style="width: 12.5%">0-3</th>
|
||
<th class="py-0 center" style="width: 12.5%">4-7</th>
|
||
<th class="py-0 center" style="width: 12.5%">8-11</th>
|
||
<th class="py-0 center" style="width: 12.5%">12-15</th>
|
||
<th class="py-0 center" style="width: 12.5%">16-19</th>
|
||
<th class="py-0 center" style="width: 12.5%">20-23</th>
|
||
<th class="py-0 center" style="width: 12.5%">24-27</th>
|
||
<th class="py-0 center" style="width: 12.5%">28-31</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="py-0 center"><code>version</code></td>
|
||
<td class="py-0 center"><code>length</code></td>
|
||
<td class="py-0 center" colspan="2"><code>type of service</code></td>
|
||
<td class="py-0 center" colspan="4"><code>total length</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center" colspan="4"><code>identification</code></td>
|
||
<td class="py-0 center"><code>flags</code></td>
|
||
<td class="py-0 center" colspan="3"><code>fragment offset</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center" colspan="2"><code>TTL</code></td>
|
||
<td class="py-0 center" colspan="2"><code>protocol</code></td>
|
||
<td class="py-0 center" colspan="4"><code>header checksum</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center" colspan="8"><code>source address</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center" colspan="8"><code>destination address</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td class="p-0 center" colspan="8"><div class="xborder-highlight"><code>options</code></div></td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center" colspan="8"><code>payload<br />(transport-layer segment)</code></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<p>
|
||
Table 5.10: Structure of an IPv4 packet
|
||
</p>
|
||
</center><p>The IPv4 header contains several fields that are not currently used in practice or to support
|
||
advanced features that go beyond the scope of this text. However, there are some fields that are
|
||
important to highlight. The 4-bit version field distinguishes between IPv4 and IPv6. The
|
||
<code class="docutils literal notranslate"><span class="pre">protocol</span></code> field specifies which transport-layer protocol (TCP or UDP) will be used to interpret
|
||
the segment header. As with TCP and UDP, IPv4 performs a checksum calculation to determine that the
|
||
header has not been corrupted. Note, however, that IP does not check that the payload arrives
|
||
intact. Recall that the terms <a class="reference internal" href="Glossary.html#term-packet"><span class="xref std std-term">packet</span></a> and <a class="reference internal" href="Glossary.html#term-datagram"><span class="xref std std-term">datagram</span></a> are often treated synonymously; this lack of
|
||
integrity is related to that practice. Specifically, the term datagram generically refers to any
|
||
network data that is considered unreliable. Since IP provides no integrity check for the payload, it
|
||
is providing unreliable service and an IP packet satisfies the implication of the term datagram.</p>
|
||
<p>The <code class="docutils literal notranslate"><span class="pre">TTL</span></code> (time-to-live) field designates the maximum number of times that a packet can be
|
||
forwarded. Each time an IP packet is delivered to a router, either within a local network or within
|
||
the Internet as a whole, the <code class="docutils literal notranslate"><span class="pre">TTL</span></code> value is decremented. Once the counter reaches 0, the packet
|
||
will be destroyed by the router that currently holds it. <strong>This is one source of packet loss as
|
||
experienced by TCP</strong>. The <code class="docutils literal notranslate"><span class="pre">TTL</span></code> mechanism is vital for the overall success of the Internet, as it
|
||
prevents old packets from traversing the Internet forever, indefinitely consuming resources.</p>
|
||
<div class="topic border border-dark rounded-lg bg-light px-2 mb-3" id="netipexample">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-Example.png"><img alt="Decorative example icon" src="_images/CSF-Images-Example.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">Example 5.5.1 </p><hr class="mt-1" />
|
||
<p>To illustrate the structure of IPv4 address, recall the TCP message from <a href="TransLayer.html#transtcpexample">Example 5.3.2</a>. This message contained an HTTP GET request to a web server. The following
|
||
example shows an IPv4 header structure that could be used with this particular message.</p>
|
||
<center>
|
||
<table class="table table-bordered">
|
||
<tbody>
|
||
<tr>
|
||
<td class="py-0">Header</td>
|
||
<td class="py-0" width="40%"><code>4500<br />0060<br />0000 0000<br />08<br />06<br />6862<br />867e 8ddd<br />5dd8 d822</code></td>
|
||
<td class="py-0" width="50%"><code>IPv4, length = 20 bytes (5 words)<br />total length = 96 bytes<br />ID, flags, offset (not used here)<br />TTL<br />protocol (TCP)<br />checksum<br />source address 134.126.141.221<br />destination address 93.184.216.34</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0">Payload</td>
|
||
<td class="py-0" colspan="2">See <a href="TransLayer.html#transtcpexample">Example 5.3.2</a></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</center><p>The <code class="docutils literal notranslate"><span class="pre">length</span></code> field (5) indicates the size of the IPv4 header in four-byte words (20 bytes total);
|
||
this field indicates whether or not optional headers are in use. The <code class="docutils literal notranslate"><span class="pre">total</span> <span class="pre">length</span></code> field
|
||
indicates the full size of the packet (including the IPv4 header, the TCP header, and the HTTP
|
||
<code class="docutils literal notranslate"><span class="pre">GET</span></code> request) is 96 bytes in size. The <code class="docutils literal notranslate"><span class="pre">TTL</span></code> indicates that the packet can be routed an
|
||
additional 8 hops. The <code class="docutils literal notranslate"><span class="pre">protocol</span></code> field (6) tells the receiving host how to interpret the
|
||
payload; in this case, the payload contains TCP data. Lastly, the source and destination addresses
|
||
are shown in both hex format on the left and their dotted-decimal translations.</p>
|
||
</div>
|
||
<p>For completeness, <a class="reference external" href="NetLayer.html#tbl5-11">Table 5.11</a> shows the structure of an IPv6 packet. As expected, the
|
||
source and destination address fields have been increased from 32 to 128 bits. The <code class="docutils literal notranslate"><span class="pre">TTL</span></code> field has
|
||
been renamed as the <code class="docutils literal notranslate"><span class="pre">hop</span> <span class="pre">limit</span></code>, but the functionality of the field is the same. IPv4 contained a
|
||
field specifying the <code class="docutils literal notranslate"><span class="pre">total</span> <span class="pre">length</span></code> of the entire packet, whereas IPv6 specifies only the
|
||
<code class="docutils literal notranslate"><span class="pre">payload</span> <span class="pre">length</span></code>. This change arises because IPv6 headers are identical in length, containing no
|
||
optional fields. The other fields are used for features not discussed here.</p>
|
||
<center>
|
||
<table class="table table-bordered">
|
||
<thead class="jmu-dark-purple-bg text-light">
|
||
<tr>
|
||
<th class="py-0 center" style="width: 12.5%">0-3</th>
|
||
<th class="py-0 center" style="width: 12.5%">4-7</th>
|
||
<th class="py-0 center" style="width: 12.5%">8-11</th>
|
||
<th class="py-0 center" style="width: 12.5%">12-15</th>
|
||
<th class="py-0 center" style="width: 12.5%">16-19</th>
|
||
<th class="py-0 center" style="width: 12.5%">20-23</th>
|
||
<th class="py-0 center" style="width: 12.5%">24-27</th>
|
||
<th class="py-0 center" style="width: 12.5%">28-31</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="py-0 center"><code>version</code></td>
|
||
<td class="py-0 center" colspan="2"><code>traffic class</code></td>
|
||
<td class="py-0 center" colspan="6"><code>flow label</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center" colspan="4"><code>payload length</code></td>
|
||
<td class="py-0 center" colspan="2"><code>next header</code></td>
|
||
<td class="py-0 center" colspan="2"><code>hop limit</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center" colspan="8"><code>source address (128 bits)</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center" colspan="8"><code>destination address (128 bits)</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center" colspan="8"><code>payload<br />(transport-layer segment)</code></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<p>
|
||
Table 5.11: Structure of an IPv6 packet
|
||
</p>
|
||
</center></div>
|
||
<div class="section" id="network-routing-protocols">
|
||
<h2>5.5.3. Network Routing Protocols<a class="headerlink" href="NetLayer.html#network-routing-protocols" title="Permalink to this headline">¶</a></h2>
|
||
<p>While there are many routing protocols in contemporary use, three that are widespread are OSPF, RIP,
|
||
and BGP. These protocols illustrate two ways to distinguish routing protocols. One way to
|
||
distinguish them is based on the scope in which they operate. Recall that the Internet is not a
|
||
single network; rather, it is a network of interconnected networks. Each of these networks can be
|
||
considered an <a class="reference internal" href="Glossary.html#term-autonomous-system"><span class="xref std std-term">autonomous system</span></a> (AS). An AS is a network of hosts (or subnetworks) that are
|
||
centrally controlled by a single entity. For instance, a business, university, or home ISP may
|
||
operate and maintain an independent AS. OSPF and RIP perform intra-AS routing, indicating that these
|
||
protocols determine how packets are forwarded from one router to the next only within the context of
|
||
that AS. For instance, if you are connected to a university network and try to access the home page
|
||
of the university’s computer science department, your packets will only be forwarded within the AS
|
||
via either OSPF or RIP; your packets will not be delivered to the other side of the world before
|
||
coming back. On the other hand, BGP provides inter-AS routing; this technique is what allows you to
|
||
access servers on a different AS, owned and operated by a different organization.</p>
|
||
<p>BGP, defined in RFC 4271, is a router-to-router protocol that uses TCP, with servers listening on
|
||
port 179. Specifically, BGP is executed on <a class="reference internal" href="Glossary.html#term-gateway-router"><span class="xref std std-term">gateway routers</span></a> that serve as
|
||
the entry and exits to an AS. Using BGP, the routers exchange information regarding particular
|
||
attributes of that AS. One attribute, the <code class="docutils literal notranslate"><span class="pre">AS-PATH</span></code>, defines the sequence of ASs that would be
|
||
traversed to a target network. For instance, an <code class="docutils literal notranslate"><span class="pre">AS-PATH</span></code> to a news website might go from your
|
||
university to your university’s ISP to the news organization. The <code class="docutils literal notranslate"><span class="pre">NEXT-HOP</span></code> attribute serves as
|
||
an identifier for the <code class="docutils literal notranslate"><span class="pre">AS-PATH</span></code>. When a gateway router receives a packet from its network, it uses
|
||
these attributes to determine the shortest total <code class="docutils literal notranslate"><span class="pre">AS-PATH</span></code> length to the destination.</p>
|
||
<div class="figure mb-2 align-right" id="id2" style="width: 40%">
|
||
<span id="netdijkstra"></span><a class="reference internal image-reference" href="_images/CSF-Images.5.10.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="A network can be modeled as a weighted graph" src="_images/CSF-Images.5.10.png" style="width: 90%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 5.5.3: A network can be modeled as a weighted graph</span></p>
|
||
</div>
|
||
<p>The second key difference, as illustrated by OSPF and RIP, centers on how the shortest path is
|
||
determined. OSPF, defined in RFCs 2328 and 5340, implements <a class="reference internal" href="Glossary.html#term-dijkstra-s-algorithm"><span class="xref std std-term">Dijkstra’s algorithm</span></a> for finding
|
||
the shortest path between nodes in a graph. This algorithm is a form of <a class="reference internal" href="Glossary.html#term-link-state-routing"><span class="xref std std-term">link-state routing</span></a>,
|
||
in which all of the routers within the AS maintain information about the network as a whole. To
|
||
illustrate OSPF, consider <a href="NetLayer.html#netdijkstra">Figure 5.5.3</a>, which models a simple network as a
|
||
weighted, undirected graph. In this scenario, router A is trying to route a packet to router B. The
|
||
weights on the edges indicate a “cost” of using that network link, such as a time delay. The
|
||
shortest path, denoted with the arrows, has a total cost of 7 ms. Note that the edge marked with an
|
||
X would involve fewer hops between routers (only two intervening routers instead of three), but the
|
||
total cost would be 11 ms, making that path more expensive. In OSPF, routers broadcast messages to
|
||
ensure all routers have the same view of the network.</p>
|
||
<p>RIP, on the other hand, does not use Dijkstra’s algorithm. Instead, RIP employs <a class="reference internal" href="Glossary.html#term-dynamic-programming"><span class="xref std std-term">dynamic
|
||
programming</span></a> to update each router’s local view of the network as things change, as described in RFC
|
||
2453. For instance, consider the router in the middle of <a href="NetLayer.html#netdijkstra">Figure 5.5.3</a>. This
|
||
router has a link to B that currently costs 10 ms. Consider the effect of that link cost dropping to
|
||
1 ms. When this router becomes aware of the change, it updates its own internal information about
|
||
the minimal cost of the path to B. However, the router also forwards this updated information to its
|
||
neighbor A. A now discovers that it has a new shortest path to B: the cost of this path is 3 ms,
|
||
rather than the 7 ms for the path shown in <a href="NetLayer.html#netdijkstra">Figure 5.5.3</a>. A would then inform
|
||
its neighbors, but neither of A’s other neighbors benefit from this improved link. Consequently, the
|
||
traversal of the information stops. This approach is known as <a class="reference internal" href="Glossary.html#term-distance-vector-routing"><span class="xref std std-term">distance vector routing</span></a>.</p>
|
||
<p>When the distance vector routing terminates, the costs of the paths determined are identical to
|
||
those established by OSPF. To be clear, the actual paths returned by the two protocols may be
|
||
different, but the minimal cost will be identical. Using either OSPF or RIP, the total cost of the
|
||
path from A to B will be the same.</p>
|
||
<p>This raises the question of why one approach would be preferred over the other. The two protocols
|
||
have different features that offer advantages over each other. RIP imposes lower overhead on the
|
||
network, as messages are exchanged point-to-point, rather than being broadcast. RIP also requires
|
||
less space overhead, as the routers only need to maintain information about the cost of the path to
|
||
each node, rather than a universal view of the entire network. However, RIP imposes a maximum hop
|
||
limit, thus limiting the size of the network. OSPF also provides features related to multicasting
|
||
and security.</p>
|
||
<p>In summary, the Internet layer extends the process-to-process communication of the transport layer
|
||
with host-to-host communication. IPv4 and IPv6 specify the identifiers (IP addresses) that are used
|
||
to locate a host within the logical structure of the network. IP addresses thus define the data
|
||
plane of the Internet layer. The control plane consists of multiple routing protocols that determine
|
||
the path between hosts, as defined by the links between routers. The RIP and OSPF routing protocols
|
||
are used for intra-AS routing, determining the minimal cost path between hosts in a network that is
|
||
under centralized control. BGP provides inter-AS routing, thus providing a mechanism for data to be
|
||
routed between ASs that are independently owned and operated.</p>
|
||
<div
|
||
id="InterNetSumm"
|
||
class="embedContainer"
|
||
data-exer-name="InterNetSumm"
|
||
data-long-name="Internet layer questions"
|
||
data-short-name="InterNetSumm"
|
||
data-frame-src="../../../Exercises/Internet/InterNetSumm.html?selfLoggingEnabled=false&localMode=true&module=NetLayer&JXOP-debug=true&JOP-lang=en&JXOP-code=java"
|
||
data-frame-width="950"
|
||
data-frame-height="775"
|
||
data-external="false"
|
||
data-points="1.0"
|
||
data-required="True"
|
||
data-showhide="show"
|
||
data-threshold="5"
|
||
data-type="ka"
|
||
data-exer-id="">
|
||
|
||
<div class="center">
|
||
<div id="InterNetSumm_iframe"></div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<div class="mt-4 container center">
|
||
«  <a id="prevmod1" href="NetSec.html">5.4. Network Security Fundamentals</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod1" href="LinkLayer.html">5.6. Link Layer</a>  »
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
<br />
|
||
|
||
<div class="row jmu-dark-purple-bg">
|
||
<div class="col-md-12">
|
||
<center>
|
||
<a id="contact_us" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="mailto:webmaster@opencsf.org" role="button">Contact Us</a>
|
||
<a id="license" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/lib/license.html" target="_blank">License</a>
|
||
</center>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<script src="_static/js/popper.js-1.14.7-min.js" integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1" crossorigin="anonymous"></script>
|
||
<script src="_static/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>
|
||
</body>
|
||
</html> |