One of the easiest analogies used to understand the OSI system model is that of sending a letter through the mail. A number of items must be completed for your letter to be delivered to the appropriate recipient.We walk a letter through the postal system and illustrate the parallel connections to the OSI system model.

The first thing that you need to do to send a letter is to write it.You sit down at your desk and write a letter to your friend that lives on the other side of the country. After you finish writing the letter, you get an envelope and address it to your friend.You then walk to your mailbox and place the letter inside.These actions correlate to the OSI system model layers nicely.Writing the letter corresponds roughly to the Application layer. If you used a word processor to write the letter, then print it out to place in the envelope, the act of printing the letter would be similar to what happens at the Application layer.The fact that you printed the letter means that you relinquished control of the letter to the network, the postal system in this case.Your actual words on the paper correspond to the Presentation layer in that you needed to ensure that the recipient, your friend, can read the letter.You presented your thoughts in a format your friend can read and comprehend. Addressing the letter can correspond to the Session, Transport, and Network layers. In networking terms, the steps of sealing the letter in the envelope and addressing it relate to the actions of UDP in a TCP/IP network. The data, your letter, was encapsulated in the envelope and passed down through the OSI model to the Network layer where it was addressed.Without the address, your letter cannot be delivered and the same principle applies to networking. Data cannot be delivered without an address. Placing the envelope in the mailbox is comparable to what happens at the Data-link and Physical layers of the OSI system model.The envelope was placed or encapsulated in the correct format for delivery on the network where it will be transmitted to the recipient. The mailbox maps to the Data-link layer and the postal carrier that picks up the envelope would be the Physical layer, responsible for ensuring that the envelope is delivered

Now that the envelope is in the network, the postal system, it may pass through many different offices. If you view these offices as nodes on a network, they would correspond to routers.The envelope reaches your local post office, or default gateway in a TCP/IP network, and is scanned by a computer to determine if the envelope requires routing for proper delivery. In this example, your friend lives across the country, so the envelope does need to be routed.The computers in the post office review the destination address and determine the best path for the envelope to take to reach its final destination.The next office, or hop, on the path the envelope takes may be a regional office or some other central location with routes to the next hop.Your envelope is transported by mail truck, plane, or other form of transportation.The actual path and transmission medium are unimportant to you as you relinquished control of your letter when you placed it in your mailbox.You are trusting that the postal service will ensure that your letter arrives.

Your envelope finally reaches the local post office for your friend.The envelope is delivered to your friend and is opened.Your friend opens the envelope, pulls out the letter, and reads it.These last steps correlate to the OSI system model working in reverse.The data, your letter, is de-encapsulated when the envelope is opened.The contents are then delivered to the recipient when your friend reads the letter, a mapping to the Presentation layer, and comprehends through the Application layer.

The seven layers to the OSI system model are as follows:

• Physical layer
• Data-link layer
• Network layer
• Transport layer
• Session layer
• Presentation layer
• Application layer

We start at the bottom with the Physical layer.The Physical layer of the OSI system model is responsible for defining the electrical and mechanical aspects of networking.Topics such as cabling and the methods for placing the 0’s and 1’s of binary data on the medium are covered in great detail here. Standards such as Category 5, RS-232, and coaxial cable fall within the realm of the Physical layer.

The next layer is the Data-link layer.The Data-link layer defines the protocols that control the Physical layer. Issues such as how the medium is accessed and shared, how devices or stations on the medium are addressed, and how data is framed before transmission on the medium are defined here. Common examples of Data-link layer protocols are Ethernet,Token Ring, FDDI, and PPP.

Within the Data-link layer are two sublayers: the Media Access Control (MAC) and Logical Link Control (LLC).These two sublayers each play an important role in the operation of a network.We start with the MAC first.The MAC sublayer is responsible for uniquely identifying devices on the network. As part of the standards of the OSI system model, when a network interface in a router, switch, PC, server, or other device that connects to a LAN is created, a globally unique 48-bit address is burned into the ROM of the interface.This address must be unique or the network will not operate properly. Each manufacturer of network interfaces has been assigned a range of addresses from the Institute of Electrical and Electronics Engineers (IEEE).The MAC sublayer is considered the lower of the two sublayers and is also responsible for determining the access method to the medium, such as token passing (Token Ring or FDDI) or contention (CSMA/CD). Figure 1.5 shows an example of MAC addresses “on the wire” after being passed from the MAC layer to the Physical layer and being converted to 0’s and 1’s.

The next sublayer is the LLC layer.The LLC sublayer is responsible for handling error control, flow control, framing, and MAC sublayer addressing.The most common LLC protocol is IEEE 802.2, which defines connectionless and connection-oriented variants. IEEE 802.2 defines Service Access Points (SAPs) through a field in the Ethernet,Token Ring, or FDDI frame.Two SAPs are associated with LLC: the Destination Service Access Point (DSAP) and the Source Service Access Point (SSAP).These SAPs in conjunction with the MAC address can uniquely identify the recipient of a frame.Typically LLC is used for protocols such as SNA that do not have a corresponding network layer.

The next layer defined by the OSI reference model is the Network layer.The Network layer is responsible for addressing a network above the Data-link layer. The Network layer is where protocols such as Transmission Control Protocol/Internet Protocol (TCP/IP), Internetwork Packet Exchange (IPX) and AppleTalk tie into the grand scheme of things. Routing functions are also performed at the Network layer.TCP/IP routing protocols such as Routing Information Protocol (RIP), Open Shortest Path First (OSPF), and the Border Gateway Protocol (BGP) operate at the Network layer.We focus more on TCP/IP in the upcoming “Review of TCP/IP Basics” section.

The three previous layers we covered, Physical, Data-link, and Network, are considered the lower level protocols in the OSI reference model.These are the protocols that will more than likely consume the majority of your time as a network engineer. However, that does not mean that the next four layers are not important to the operation of a network.They are equally important, because without the next four layers, your network doesn’t even need to be in existence.

The fourth layer of the OSI system model is the Transport layer.The Transport layer defines the protocols that control the Network layer, similar to the way the Data-link layer controls the Physical layer.The Transport layer specifies a higher level of flow control, error detection, and correction. Protocols such as TCP, User Datagram Protocol (UDP), Sequenced Packet Exchange (SPX), and Name Binding Protocol (NBP) operate at this layer.These protocols may be connection-oriented, such as TCP and SPX, or connectionless, such as UDP.

The fifth layer of the OSI system model is the Session layer.The Session layer is responsible for establishing, managing, and terminating communication sessionsbetween Presentation layer entities and the Transport layer, where needed. Lightweight Directory Access Protocol (LDAP) and Remote Procedure Call (RPC) are examples of Session layer protocols.

The sixth layer of the OSI system model is the Presentation layer.The Presentation layer is responsible for ensuring that data sent from the Application layer of one device is comprehensible by the Application layer of another device. IBM’s Network Basic Input Output System (NetBIOS) and Novell’s NetWare Core Protocol (NCP) are examples of Presentation layer protocols.The ISO also developed a Presentation layer protocol named Abstract Syntax Notation One(ASN.1), which describes data types independent of various computer structures and representation techniques.ASN.1 was at one time thought to be the Presentation layer protocol of choice, when the ISO’s protocol stack was going to sweep the networking industry. Now we know that some components of ISO, such as Intermediate System to Intermediate System (IS-IS) as a routing protocol, and the X.500 directory services protocol have been widely deployed, while the majority of the protocol stack has been neglected.

The seventh, and final, layer of the OSI system model is the Application layer. The Application layer is responsible for providing network services to applications such as e-mail, word processing, and file transfer, which are not implicitly defined in the OSI system model.The Application layer allows developers of software packages to not have to write networking routines into their program. Instead, developers can utilize programming functions to the Application layer and rely upon Layer 7 to provide the networking services they require. Some common examples of Application layer protocols include Simple Mail Transfer Protocol (SMTP), Hypertext Transfer Protocol (HTTP), and Telnet.

In Ethernet, the multiple access (MA) is the terminology for many stations connected to the same cable and having the opportunity to transmit. No device or station on the cable has any priority over any other device or station. All devices or stations on the cable do take turns communicating per the access algorithm to ensure that one device on the LAN does not monopolize the media.

The CS (carrier sense) refers to the process of listening before speaking in an Ethernet network.The carrier sense operation is performed by every device on the network by looking for energy on the media, the electrical carrier. If a carrier exists, the cable is in use, and the device must wait to transmit. Many Ethernet devices maintain a deferral or back-off counter defining the maximum number of attempts the device will make to transmit on the cable. If the deferral counter is exceeded, typically 15 attempts, the frame is discarded.

The CD (collision detect) in Ethernet refers to the capability of the devices on the wire to know when a collision occurs. Collisions in Ethernet happen when two devices transmit data at the same time on the cable. Collisions may be caused by the cable distance being exceeded, a defective device, or a poorly written driver that does not adhere to Ethernet specifications.When a collision is detected, the participants generate a collision enforcement signal.The enforcement signal lasts as long as the smallest Ethernet frame size, 64 bytes.This sizing ensures that all stations know about the collision and do not attempt to transmit during a collision event. After the collision enforcement signal has finished, the medium is again open to communications via the carrier sense protocol.

Deterministic access is the protocol used to control access to the physical medium in a token ring or FDDI network. Deterministic access means that a control system is in place to ensure that each device on the network has an equal opportunity to transmit.

Cabling

The physical infrastructure of a LAN is one of the most important components of a network. If the physical medium that data is traversing is faulty or installed incorrectly, network performance and operation will be impacted. It is analogous to the foundation of a building. Everything in the building is set upon the foundation, typically strong reinforced concrete or other equally durable and reliable building materials. If the foundation is not installed properly, everything built on this foundation is suspect. A LAN is the same, a faulty foundation can be disastrous to a network.You can install all of the high-end gear, switches, routers, servers, but if they don’t have the physical infrastructure to communicate effectively, your network will fail.

There are two primary forms of physical medium a network will utilize: copper and fiber. Between these two forms, there are sometimes many different standards of cable. For example, copper may be shielded, unshielded, twisted, untwisted, solid core, or braided core.We explore copper and fiber cable in more detail to provide a solid understanding of the importance of cabling in your network. You may be asking yourself “Why are we covering cabling in a book on wireless?”That is a very good question.Wireless, as its name implies, does not use physical cabling to provide communications to the wireless network. However, it does use copper cabling to connect to your existing LAN. If your existing LAN has out-of-spec or faulty cabling, your WLAN may not meet your expectations. (Or more importantly, your boss’s expectations!)

The most common form of LAN cabling installed today is copper. Copper has been the “preferred” installation since networks starting taking hold in the corporate world in 1980 when Xerox developed Ethernet. Copper is relatively cheap, easy to install, and can meet most distances that LANs were designed to cover.The original Ethernet specification used what is called thick coaxial cable. This cable lived up to its name for sure! Thick coax is much bigger than the traditional copper cable you might be familiar with. After thick coax came thin coax.Thin coax was a cheaper and easier to handle and install cable alternative. Both of these cable types are implemented in a bus topology.As we covered earlier, a bus topology is linear LAN architecture. Each device or station on a bus is connected to the same medium. One of the major downsides to thick and thin coax was that it created a single point of failure. If the bus were to experience a failure or cut, the network became nonfunctioning.

With the advances made in copper technology, twisted pair cable became a popular LAN medium.There are two main types of twisted pair cable: shielded and unshielded. Shielded, as its name implies, contains smaller copper cables, twisted among themselves with a shielded jacket around them. Shielded twisted pair allows copper cable to be installed in facilities where there is significant interference to the electrical signals passed along the cable.The shielding—as well as the twisting of the cables—plays a role in protecting the able from this interference.Twisted pair cables are less prone to interference than flat, or nontwisted cables.

Among the twisted pair cabling family are a number of different levels of cables.These are commonly referred to as categories, or CAT for short.The primary differences between the categories is the number of twists per foot in the cable. More twists per foot equals less susceptibility to outside interference. Some of the newer, higher categories of cabling also have internal dividers intertwined with the copper cabling to further reduce interference.These higher standards allow faster communications such as Fast Ethernet at 100 Mbps and Gigabit Ethernet at 1000 Mbs over copper cabling.

Bus Topology

A bus topology is a linear LAN architecture in which transmissions from network devices or stations propagate the entire length of the medium and are received by all nodes on the medium.A common example of a bus topology is Ethernet/IEEE 802.3 networks.

Star Topology

A star topology is a LAN architecture in which the devices or stations on a network are connected to a central communications device, such as a hub or switch. Logical bus and ring topologies are often physically implemented in star topologies.

Ring Topology

A ring topology is a LAN architecture in which the devices or stations on a network are connected to each other by unidirectional transmission links to form a single closed loop. Common examples of ring topologies are Token Ring/IEEE 802.5 and FDDI networks.

Mesh Topology

A mesh topology is a LAN architecture is which every device or station on a network is connected to every other device or station. Mesh topologies are expensive to deploy and cumbersome to manage because the number of connections in the network can grow exponentially.The formula used to calculate the number of connections in a fully meshed network is as follows:

(N x (N–1))/2

where N is the number of devices on the network. Divide the result by 2 to avoid double counting the device A-to-device-B connection and the device

B-to-device-A connection.To illustrate the large numbers that a fully meshed environment can reach, review the following examples:

• A small network with 50 users wants to implement a fully meshed topology.The number of connections required to do this would be (50 × (50–1))/2, which equals 1,225.That is a lot of connections for a small LAN!
• A medium network with 500 users wants to implement a fully meshed topology.The number of connections required to do this would be (500 × (500–1))/2 which equals 124,750 connections!

Now for the reality check on fully meshed networks. Fully meshed networks are typically implemented in a small handful of situations.The most common deployment model for fully meshed networks would be in the WAN arena. Frame Relay and ATM are technologies that are well suited for fully meshed networks with high availability requirements. Figure 1.4 depicts a typical mesh network.

There are three primary types of networks, the local area network (LAN), metropolitan area network (MAN), and the wide area network (WAN).The distinguishing feature of these networks is the spatial distance covered. LANs, as the name implies, are typically contained in a single structure or small geographic region. Groups of LANs interconnected may also be referred to as a campus in larger environments. MANs connect points or nodes in a geographic region larger than a LAN, but smaller than a WAN. Some of the same LAN technologies may be employed in a MAN, such as Gigabit Ethernet.WANs are geographically diverse networks and typically use technologies different from LANs or MANs. WANs typically are comprised of high-speed circuits leased from a telecommunications provider to facilitate connectivity.WANs rarely use the same technologies as LANs or MANs.Technologies such as Frame Relay, Integrated Services Digital Network (ISDN), X.25, Asynchronous Transfer Mode (ATM), Digital Subscriber Line (DSL) and others my be used.This is because of the larger distances WANs service.

Where can you fit WLANs into your existing infrastructure? Just about anywhere you like.WLANs allow network designers to no longer be constrained by the 100m distance limitation for Category 5 copper cabling. Because WLANs use radio frequency (RF) signals to communicate, users can stay connected to the network almost anywhere.

Many companies are merging WLANs into their traditional wired networks to provide connectivity to the network to large numbers of users. Conference rooms are a great place to start considering wireless in your network.The cost ofwiring a conference room and maintaining the hardware required to keep those wired jacks “hot” can be prohibitive. Conference rooms are used for “chalk talk” design sessions, application development sessions, and training. By using WLANs, the need for multiple data jacks in a conference room can be eliminated. A single antenna connected to a WLAN access point (AP) can support many users.

Warehouse applications are also prime candidates for WLAN. Real-time inventory control can be implemented using wireless. Imagine having your inventory control software connected to mobile devices on the warehouse floor tracking inventory as it fluctuates during the course of a day.WLANs can be a very important business driver, enabling a company to gain a competitive advantage.

Hospital bedside access is also a popular application for WLANs.The ability for a hospital staff member to check in a patient at bedside rather than waiting in line at an admissions desk is much more efficient. Bedside access can also enable a doctor to write a prescription or check medical records on a patient instantaneously.

College campuses and some companies are also extending the network infrastructure to public access areas both indoors and outside.This no longer restrains the user to just her desk, or even in the building, to be productive. For the growing mobile workforce, wireless provides the connectivity.

This original system was simply a loose agreement among network/host administrators on a set of mnemonic names that correlated to numeric IP addresses. This agreement formalized an existing practice. These administrators had already realized that their user communities either couldn’t or wouldn’t use numeric addresses to access specific hosts. Thus, virtually all of them had deployed a scripted function that allowed their users to use mnemonic names for host access. Their scripts checked those names against a small but ever-growing list of known host addresses and provided an automatic translation between names and numbers.

Because this function was highly localized, there wasn’t much consistency from network to network with respect to host naming conventions. After all, this was a localized translation function; the names used didn’t need to be the names used by those remote hosts’ administrators. They could be somewhat arbitrarily selected. For example, a name could be the local user’s nickname instead of the host’s official name. Needless to say, this had the potential to create great confusion. More importantly, given the highly decentralized nature of maintaining such local lists, the probability of disseminating information about moves, adds, deletes, or other changes quickly and evenly throughout the ARPANET community was slim to none. Thus, you could reasonably expect connectivity problems caused by this attempt at simplifying host access for users. Life is full of delicious irony!

hosts.txt

Fortunately, these sage administrators communicated with each other and often published documents requesting comments (ARPANET’s RFCs) from other administrators. Together, they realized that it was critical to standardize on a format for naming hosts as well as a set of names for known hosts. To ensure future scalability, they further agreed to have this list managed centrally to ensure that it remained as up-to-date and evenly distributed as possible. This mechanism became known as the hosts.txt file. The Stanford Research Institute maintained the hosts.txt file via its Network Information Center (NIC) and transmitted to known hosts using the file transfer protocol (FTP). RFCs 952 and 953 spelled out the details of this update mechanism and procedure in October 1985.

NOTE

A vestige of the original hosts.txt file and the mind-set that led to its creation remain in evidence even today. Most operating systems support the creation of a file that correlates IP addresses with mnemonics that are of local significance only. For example, UNIX systems contain an etc/hosts file to support this function.

The idea was simple enough: maintain a list of all known hosts, as well as certain other data that would be useful in deciphering the list. This list would be nothing more than a flat text file that was pushed to all administrators in the network on a regular basis. Updating local lists was up to each administrator. Failure to do so meant that their users did not have access to the most current information about known hosts.

Although it might sound foolish to try and track all known hosts in a single flat file, you must remember that this dates back to RFC 606, published in December 1973. The ARPANET was using IP, but the IPv4 address scheme had yet to be devised. The address space was still only 8 bits long. Mathematically, there couldn’t be any more than 255 hosts.

Problems with Flatness

The hosts.txt file approach worked well for a couple of years. However, several inherent problems threatened the usefulness of this mechanism as the Internet continued to grow:

• Collision of host names Locally defined host names create the possibility of a single character string being used to identify two or more different end systems. This is known as name collision, and it can result in an inconsistent translation of names to numeric addresses.

• A limited number of mnemonically useful names A finite number of useful and meaningful character strings can be used to name hosts. Imagine, for example, that only one host in the world could have the name klingon. Absent a hierarchical naming system, the first Trekkie who gave his or her computer that name would prevent anyone else in the world from using it.

• Timeliness and uniformity of implementing updates The “official list” couldn’t be updated in real time, so a batch-oriented approach was required. In other words, changes, deletes, and additions to the hosts.txt file would be batched and then sent out periodically. Depending on how frequently the updated list was sent out, a host could be online but still inaccessible. An additional time lag could be experienced if network or host administrators did not promptly process the newly received hosts.txt file.

• The lack of a name dispute resolution mechanism and authority Some mechanism is needed to reconcile cases in which two or more people select the same name for their box. In the days of the hosts.txt file, there was no way to resolve such disputes aside from embracing a first-come, first-served philosophy. But even that approach wasn’t perfect, because updates were done in a batched manner.

Generally speaking, these problems were rooted in the flatness of the address space. Flatness in this particular case means the absence of a hierarchical structure. That by itself limited the number of meaningful names that could be assigned to hosts. Each name could be used only once throughout the worldat least the parts of the world that interconnected via the Internet! Although the NIC was responsible for tracking hosts on the Internet, it had no authority to resolve disputes over names. Thus, a chronic problem became the collision of names. In a flat environment, host names had to be unique.

You could cope with this lack of hierarchy by assigning pseudo-random strings of letters to substitute for names. That could help ensure uniqueness for a very long time, but it utterly defeats the intent behind having a mnemonic name that users can understand and remember better than pseudo-random strings of numbers.

Aside from the limited number of names that could be both useful and usable, the notion of sending out a flat file periodically to update distributed tables meant that there would be a gap between when a host came online and when distributed users would know it existed.

The largest problem with the hosts.txt approach was its inability to scale upward. As more hosts on more networks came online, the challenge of keeping them up-to-date in the file grew immeasurably. Not only were there more hosts to keep track of, each of them also had to receive the hosts.txt file. After a while, just updating the file of known hosts became almost a full-time job.

NOTE

The person whose job it was to maintain the hosts file was informally known as the hostmaster. This function exists today even though the hosts.txt file has long since slipped into obsolescence. Today’s hostmasters assign IP addresses to endpoints and manage IP address space, among other duties.

By September 1981, with a mere 400+ hosts on the ARPANET, it had become painfully obvious that there had to be a better solution. A series of RFCs began emanating from the technical constituents of ARPANET calling for a hierarchical approach to Internet names. Although each examined the same problem from a different perspective, the prevailing theme remained the need for a hierarchical namespace. Over time, these disparate RFCs coalesced into a distributed, hierarchical system that became known as the Domain Name System (DNS).

NAT, by its very nature, conceals source and/or destination IP addresses. Many problems can emanate from that basic, inescapable fact. You can categorize these problems by their impact area:

• Technical incompatibilities

• Scalability and network performance issues

• Logistical difficulties

Each of these is examined briefly in the next sections.

Technical Incompatibilities

The most egregious problem is that NAT breaks any network-based application that requires end-to-end session integrity. This is a direct result of NAT’s interception of inbound and outbound IP packets and rewriting their headers to achieve the desired address translation.

Some of the specific technologies that are at least partially incompatible with NAT include SNMP, IPSec’s authentication and encryption technologies, and the emerging Mobile IP. Many network engineers believe that NAT is directly responsible for the inability of IPSec and Mobile IP to achieve any meaningful degree of market acceptance.

Scalability

Other problems with NAT have nothing to do with technical incompatibilities. For example, NAT imposes a potentially substantial overhead on any router that supports the translation function. This overhead can be substantial enough, depending on the configuration, to prevent graceful scalability. Hardware-based appliances have appeared on the market to prevent such adverse effects on your network, but not everyone who needs to implement NAT can afford to purchase another device. Consequently, the point about NAT’s impacts on router performance remains valid.

Another problem is that the probability of experiencing address problems increases greatly with NAT. The problem becomes worse, not better, with each additional translator you configure in your network. Think about it: The more translation devices you have in your network (ideally, you’d have one for each egress point), the more address tables you would have. Keeping them synchronized can be challenging, time-consuming, and onerous.

Logistical Challenges

There are logistical challenges, too, with a NAT network. For example, security is a double-edged sword. This chapter has treated NAT’s privacy-enhancing aspect as a positive attribute. However, that capability also has a dark side. Debugging a problem or chasing a hacker can run into a brick wall at a NAT simply because the true source IP address is hidden from destinations. Although such challenges aren’t showstoppers, they are just some of the little “gotchas” that await any network administrator who must implement and use NAT.

In all honesty, NAT has become an unavoidable part of the Internet technology base. Recent policy changes regarding the availability of directly registered address space (as discussed in earlier chapters) have made it all but necessary for many organizations that no longer qualify for their own address space. Regardless of how you feel about it, NAT is here to stay!

Originally described in RFC 1631 in May 1994, NAT was originally conceived as yet another of the stopgap measures to shore up the flagging IPv4 address space. If you take the time to read this document (www.ietf.org/rfc/rfc1631.txt), you will see that the IETF was absolutely counting on IPv6 to save the Internet from its impending address crisis. This document explicitly identifies the two biggest problems facing the Internet as a shortage of IP addresses and the scalability of routing across the Internet. In Chapter 5, “The Date of Doom,” we looked at how these two are really different perspectives on the same problem, so their appearance in RFC 1631 shouldn’t be a startling revelation.

What is startling is the explicit admission that at least some parties within the IETF were concerned that CIDR (then under development) might not buy enough time for IPv6 to be completed. That’s a staggering statement! CIDR was initially conceived as just another stopgap tool to buy time for the new IP protocol and addressing system to be developed. This fear became the motivator for the development of NAT.

Framing the Problem Statement

The authors of RFC 1631 apparently believed strongly enough in their proposal to say the following:

It is possible that CIDR will not be adequate to maintain the IP Internet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary.

With the benefit of hindsight, that remarkable statement is both amusing and illuminating. As late as the middle of 1994, there was still great debate as to whether a migration to a classless IP address system was even needed. This is significant because CIDR was stipulated in a series of RFCs published in September 1993, 8 months prior to the release of RFC 1631 NAT! If nothing else, this should give you some indication that there was little consensus on anything other than three basic facts:

• The IPv4 address space, in its class-based configuration, was about to break.

• The correct way to solve the problem was to make a completely new Internet Protocol (eventually named IPv6).

• Something needed to be done immediately to forestall the impending collapse of the classful system long enough to roll out the new version of IP.

Beyond these three basic facts, consensus broke down. Nobody really knew the correct approach to take, so the IETF attacked in all directions. The development of NAT capability was aimed at enhancing the usefulness of the RFC 1918 addresses. One of the single biggest “traps” inherent in the use of nonunique addresses was the inability to convert them to routable addresses. Should requirements change, and Internet connectivity become necessary, anyone using RFC 1918 addresses would face a painful address migration. In comparison, address translation seemed like a welcome alternative.

As significant as NAT has become, it is almost laughable to think that at its inception it was being bandied about as an alternative to CIDR. With hindsight, it is remarkably obvious that CIDR and NAT are different tools intended for different uses. Both technologies were also so successful at buying time for IPv4 that they are still in active use.

Technical Overview

Before we get too caught up in technical details, one salient point to understand is that NAT is a router-based function. It was designed to provide hosts on a private network with a means of communicating transparently with destinations outside that network, and vice versa. Traditionally, NAT has been used in conjunction with RFC 1918 addresses (specifically designed for use in addressing private numbers), but that is not a mandate. NAT can be used to translate unique addresses into other unique addresses, too. Either way, it enhances security by hiding addresses within a private network from the outside world. Thus, NAT can be highly appropriate for securing a network, regardless of what kind of IP addresses are in use.

The way this works is actually quite simple. A gateway router (one that sits at the border of two different networks) functions as an address translator between two neighboring networks. This translation means that a NAT network has different types of IP addresses, each serving a slightly different purpose. Before we venture too far ahead, you need to understand the subtle distinctions between these address types. If you assume that an enterprise is using NAT to establish communications with the Internet, this helps you establish a frame of reference for understanding the differences between the address types. The original specification for NAT had two address types:

• Inside local (IL) address This is the address of a host inside an enterprise’s network as it is known within that network. The IL may be globally unique (either obtained from the ISP or directly registered to the enterprise), or it may be selected from an RFC 1918 reserved range. Communications within a network may occur directly using IL addresses, without the need for translation.

• Inside global (IG) address This is the IP address of a host inside an enterprise’s network as it appears to the Internet. That last phrase is the critical distinction between an IG and an IL address. IG addresses must be globally unique, regardless of whether they were obtained from the ISP or directly registered to the enterprise. It is important to recognize that the IG address is advertised to external networks and is used for routing to the internal network. Thus, RFC 1918 private addresses cannot be used as IG addresses.

Together, these address types let a network communicate with other IP-based networks without having to reveal its internal addresses. That’s a key statement, because so many people think that the only reason NAT exists is for use with RFC 1918 addresses. The truth is, it can be used with any network address and may be implemented to enhance a network’s security regardless of whether it uses private or globally routable addresses.

The NAT router must keep a tableknown as an address translation table (no acronyms, please)that correlates these different address types. How this correlation works depends on whether we are talking about packets coming into, or going out of, that private network. We’ll look at both traffic types in the next section.

Over time, NAT has become much more sophisticated and feature-rich. Today’s NAT can translate external as well as internal addresses and can even translate TCP port addresses. Later in this chapter we’ll look at some of the technological advances that NAT has benefited from. For now, let’s continue with our examination of the basic NAT specification. This will give you a context within which you can better appreciate the enhancements made to NAT since RFC 1631.

Operational Mechanics

NAT is a router-based function that must reside at a network’s border. For the purposes of explaining how a NAT works, let’s start with a very basic implementation topology. Take a look at Figure 7-1. This figure shows a simple stub network that consists of just one local-area network. This LAN uses private addresses in the 172.16.9.0/24 block. NAT is performed at the gateway router between that network and the Internet. This connection is the only egress point for this network.

Figure 7-1. NAT Translates Nonunique and Unique Addresses at the Border of a Stub Network

For now, let’s make the simplifying assumption that the end user entered an IP address as opposed to a host and domain name string. This lets you focus on the mechanics of NAT without the added complexity of translating a name into an IP number. We’ll look at how that is done in Chapter 9, “IP Multicasting.” Given this simplifying assumption, when an endpoint on that LAN tries to access a host that resides outside its boundaries, the request can’t be resolved locally, and the gateway router accepts it. That router has only two interfaces configured: the LAN and a serial connection to the Internet. Because it is seldom useful to send a datagram or packet back through the interface it came in on, the router has only two choicesdrop the packet or send it out the other interface. Using the other interface requires that some work be done to the datagram, because that is the interface where NAT resides.

The first thing NAT does is check the header of that packet to determine its source IP address. The packet is coming from an endpoint located somewhere within the network, so the source IP address is an inside local address. NAT won’t permit such addresses to pass into an external network. NAT searches its address translation table for this address. If no entry is found that corresponds to that destination address, the packet is simply discarded. If a match is found within the address translation table, the corresponding inside global address is retrieved from the table and is used in lieu of the inside local address in the packet’s source address field.

Table 7-4 summarizes this gateway router’s address translation table. For the sake of example, let’s pretend that the globally routable address is in the 254.16.35.0 range. That address is not a valid address. In fact, it’s a part of the reserved Class E address space. But I am extremely reluctant to use “real” IP addresses in an example.

After a packet’s source address field is updated with the appropriate inside global address, the packet can be launched out the router’s interface and into the foreign network that lies beyond. Although that’s a brief-enough synopsis of how NAT treats outbound packets, it is also necessary to see how NAT supports address translation for incoming packets.

Very generally speaking, there are two basic reasons for packets to be inbound to a NAT network:

• Responses to a session generated from within the NAT network

• Sessions that originate from external hosts

Regardless of the variety, packets that are inbound to a NAT network pass through the same process. Such packets are sent to machines bearing inside local address types. As such, they must be intercepted by the NAT for translation of the destination address to an inside global address.

The process by which NAT translates IG addresses to IL addresses is exactly the reverse of the one we just looked at. An incoming packet is accepted by the NAT (which could be a process configured on a router interface, firewall, or other specialized network appliance), and its destination address is examined and hashed against the address translation table for a matching record. If the destination address (really an IG address) is known, the corresponding IL address is then substituted in the packet’s destination address, and the packet is launched into the private network. If the destination IG address isn’t known, the packet is discarded.

]]> http://www.ciscotrick.com/ip-addressing-fundamentals/nat/feed/ http://www.ciscotrick.com/ip-addressing-fundamentals/private-address-spaces/ http://www.ciscotrick.com/ip-addressing-fundamentals/private-address-spaces/#comments Fri, 15 Aug 2008 08:46:25 +0000 mekichan http://www.ciscotrick.com/?p=114 After the Internet became commercialized, its popularity soared. More importantly, so did the popularity of TCP/IP and its addressing architecture and space. Seemingly overnight, software engineers embraced the TCP/IP communications protocol suite and it became the de facto standard for networked communications between applications. As a direct result of this trend, many organizations began implementing TCP/IP to support their base of applications even though they might not have needed or wanted access to the Internet. Implementing TCP/IP absolutely requires that you also implement the Internet’s addressing scheme, regardless of whether you intend to actually use the Internet.

In March 1994, the IETF released RFC 1597. This document acknowledged that many organizations were using TCP/IP and IP addresses but remained isolated from the Internet. This was perfectly acceptable in the days before commercialization, because the installed base of TCP/IP networks was relatively low. But the commercialization of the Internet threatened to rapidly deplete the IP address space.

The theory behind RFC 1597 (and its update in RFC 1918) was that a block of addresses could be reserved for use in private networks. This afforded a legitimate mechanism for networks that needed IP for application support but did not want or need to access the Internet. Such a mechanism would serve a twofold purpose.

First, it would mitigate the demand for new IP addresses. This would help make the remaining address blocks last a little longer. The downside is that these addresses cannot be routed over the Internet.

Second, this approach would help keep down the swelling of the Internet’s routing tables. Reserved address blocks cannot be routed through the Internet and are limited to local use.

NOTE

The addresses reserved in RFC 1918 are sometimes called nonroutable addresses because they cannot be routed across the Internet. However, that does not mean that they can’t be routed! Quite the contrary: Many a private IP WAN has been built successfully using these so-called nonroutable addresses. The reserved addresses can be routedjust not across the Internet.

The Mathematics of Private Addressing

One very common misperception about RFCs 1597 and 1918 is that these documents reserved an entire Class A, an entire Class B, and an entire Class C network address space. People who think this either don’t really understand the IP address architecture or haven’t read the RFCs. Probably both. Table 7-1 lists the address blocks that were reserved in RFC 1597 (and reinforced in the updated RFC 1918, which is still Internet Best Current Practice #5) for use solely in private networks.

A quick glance at Table 7-1 should demonstrate that entire blocks of Class A, B, and C network address space are indeed not reserved! In fact, if you read those RFCs, you’ll see that only the address block taken from the Class A space matches the classical boundary for that address. Thus, the space reserved from the Class A address space by RFC 1918 is, in fact, an entire Class A address space. 8 of its address bits are used for network identification. That leaves 24 bits for host addresses. For this reason, the RFC refers to this reserved address block as the 24-bit address. This is in stark contrast to the popular convention of explicitly identifying the number of bits in a network address.

The others don’t follow the classical boundaries so neatly. The address block reserved by RFC 1918 within the Class B address range, for example, is actually a block of 16 numerically contiguous Class B spaces. If you plotted this out in a binary string, you would see that the Class B RFC 1597 space offers 20 bits for host addresses (rather than just 16, as is found in a Class B network). Thus, in the RFC, this address type is called the 20-bit address. As I mentioned before, this is very confusing and is contrary to the established conventions.

Table 7-2 shows you the binary and decimal limits of this reserved address space. The network mask is indicated in bold so that you can more easily see that this network block uses 12 bits.

The Class C network space is equal in size to a set of 255 numerically contiguous Class C network addresses. If you think about this, and visualize it in binary, you will realize that this reserved address space offers 16 bits of host addresses. Thus, the block reserved from the Class C address space is identical in size to a Class B network block. Table 7-3 shows the actual reserved range of addresses. Again, for your visual reference, the bits used to identify the network are indicated in bold. The other bits are used for host addressing.

Benefits and Drawbacks of Private Addressing

Having waded through the mathematics of reserved private address blocks, it’s probably appropriate to look at some of the operational impacts of private addressing. In other words, let’s look at the benefits and limitations of this tool.

Benefits

The greatest benefit of using private address space is that the global Internet address space is conserved for use where it is really needed. Although this is a noble goal, the benefits are distributed externally: The organization implementing private addressing is helping the Internet community at large, but not necessarily itself, in the processat least, not if this were the only benefit.

One other benefit, perhaps the most compelling of all, is that you don’t need permission to use these addresses. They were created explicitly to be unique per network but nonunique globally. As you saw earlier in this chapter, one of the more effective ways that IANA’s pool of available addresses was protected was by rationing them carefully. Gone are the days when address blocks were handed out to anyone who asked. With the introduction of RFC 1466, a stringent standard of justification was imposed on anyone asking for address space. Even service providers had to pass stringent criteria to justify being assigned more address space. So, here was the classic carrot and stick: Use the RFC 1597/1918 addresses hassle-free, or butt heads with the Keeper of Unassigned Addresses in an almost-always-futile attempt to procure your own addresses.

Another, more-subtle reason to use private addressing is that the network becomes inherently more secure. Because private address spaces are not valid routes across the Internet, a network that used them couldn’t be hacked via the Internet. Of course, such a network would have a difficult time communicating with the Internet if it had those addresses in the first place, but hopefully you get my point.

Drawbacks

The drawbacks of using the private address space reserved in RFC 1918 are relatively easy to enumerate. There’s exactly one. That first, last, and only drawback is that these addresses cannot be routed across the Internet. But they can be routed internally within a private network. You’re probably thinking that this isn’t a flaw; it’s a feature. And you’re right. But this becomes a problem if your requirements change after you implement RFC 1918 addresses. For example, if you suddenly find that your users require connectivity to, or accessibility from, the Internet, this limitation can become quite problematic. Quite literally, if you try to connect to the Internet using RFC 1918 addresses, you won’t be able to communicate at all. The ISP you are connecting to won’t recognize your address space (identified in each of your IP packets via the source address field) as routable, so no inbound packets will be able to reach you. That includes packets generated in response to your queries!

That’s not to say that using RFC 1918 addresses is risky. In fact, if you have no plans to connect to the Net, RFC 1918 is perfect for you.

When requirements change like that, you aren’t necessarily facing an address migration. This is where NAT can be extremely useful.