In this section

•	NAT Architecture
•	NAT Network Structure
•	Optional NAT Subsystems
•	NAT Processes and Interactions
•	Related Information

The network address translation (NAT) functionality provided by the Routing and Remote Access service enables computers on a private network to access computers on a public network, such as the Internet. In Windows Server 2003, the Routing and Remote Access NAT/Basic Firewall component is typically referred to as a routing protocol component. Strictly speaking, NAT is not a routing protocol; it does not send and receive traffic nor does it instigate changes to the routing table. However, the Routing and Remote Access service interfaces with the NAT/Basic Firewall component through the routing protocol interface, and, in this sense, NAT functions just like a routing protocol. Although NAT is not a true routing protocol, it is installed as if it were by using the Routing and Remote Access snap-in.

This document explains how Routing and Remote Access NAT works. It covers the components of Routing and Remote Access NAT architecture, a typical network behind a NAT-enabled router, optional NAT subsystems designed to simplify configuration for smaller networks, and NAT processes and interactions. The latter section explains how NAT works with TCP/IP, how address and port translation work, how dynamic and static mappings and IP reservations work, how NAT editors work, and includes a flowchart showing how inbound and outbound packets are processed.

For an introductory description of the problems Routing and Remote Access NAT is designed to solve and a quick sketch of typical NAT scenarios, see “What Is NAT?.” For information about tools used to install, configure, and manage Routing and Remote Access NAT, see “NAT Tools and Settings.”

Understanding the architecture of Routing and Remote Access NAT requires recognizing the relationship of the NAT routing protocol component to other routing components, to the NAT editors and proxies, to TCP/IP, and to the TCP/IP Address Resolution Protocol (ARP) module. The following figure illustrates Routing and Remote Access NAT architecture:

Routing and Remote Access NAT Architecture

The following table describes each component depicted in the figure.

Routing and Remote Access NAT Components

Component	Description
IP Router Manager	A component of the Routing and Remote Access service. The IP Router Manager uses input/output (I/O) controls to do the following: • Add interfaces to and remove interfaces from NAT. • Provide NAT with its configuration, which is stored as part of the IP global and per-interface information in the registry.
NAT	A routing protocol component that, when enabled on a server running the Routing and Remote Access service, translates IPv4 addresses and TCP or UDP port numbers of request packets originating from a client on a private network, forwards the translated packets to a destination computer on the Internet (or other public network), and then performs reverse translation for response packets sent by the destination computer back to the client. NAT can also translate packets for specifically allowed incoming traffic originating from a computer on the Internet to a client computer on the private network. For more information, see “NAT Network Structure” and “NAT Processes and Interactions” later in this document.
NAT Editors	Programs that perform translation for the data of certain network protocols that NAT on its own cannot translate. Routing and Remote Access NAT has the following built-in editors: • Internet Control Message Protocol (ICMP), which supports the transmission of error messages across a NAT. • Point-to-Point Tunneling Protocol (PPTP), which supports PPTP VPN traffic across a NAT. For more information, see “How NAT Editors Work” in “NAT Processes and Interactions” later in this document.
NAT Proxies	Programs that redirect packets to a module that builds a new packet modified so that the newly modified packet can cross a NAT. Routing and Remote Access NAT includes the File Transfer Protocol (FTP) proxy, which supports FTP traffic across a NAT, and the H.323 proxy, which supports NetMeeting calls across a NAT.
TCP/IP	The industry standard suite of protocols for transmitting data between computers over networks. Routing and Remote Access NAT is implemented as a routing protocol component that the TCP/IP protocol component in Windows calls when a data packet is sent or received. TCP/IP allows NAT to make modifications to a packet’s data (translating IP addresses and TCP or UDP port numbers) and to ensure that checksums within a modified packet are correct. For more information, see “How NAT Works with TCP/IP” and “How Address and Port Translation Work” in “NAT Processes and Interactions” later in this document.
ARP	The TCP/IP network layer protocol that uses broadcast traffic on the local network to resolve a logically assigned IPv4 address to its physical hardware or media access control (MAC) layer address. When mapping between public and private address pools when a pool of public addresses exists, NAT uses TCP/IP’s proxy ARP mechanism to respond to ARP queries for addresses in a public address pool. (Proxy ARP refers to the use of a particular machine, such as a NAT-enabled IP router, to respond to ARP requests for computers other than itself.)

In a typical scenario, a Routing and Remote Access NAT-enabled router provides access to the Internet for a small- or medium-sized organization that uses private IPv4 addresses. To support this type of network, in addition to a server running the Routing and Remote Access service with the NAT/Basic Firewall component enabled, the typical network configuration includes, at minimum, client computers running a Web browser, such as Internet Explorer, and a firewall, such as the Basic Firewall option available with Routing and Remote Access NAT. The NAT-enabled router lets the clients on the private network access a computer on the Internet, such as a Web server running Internet Information Services (IIS).

Unless the network contains multiple routed segments, neither a DHCP nor a DNS server is required because NAT functionality in Windows Server 2003 includes the DHCP allocator and the DNS proxy capabilities, which provide automatic addressing and name resolution, respectively. For more information about the DHCP allocator and the DNS proxy, see “DHCP Allocator” and “DNS Proxy” in “Optional NAT Subsystems” later in this document.

If a DHCP server or a DNS server does exist on the network, Routing and Remote Access NAT is also designed to work with those servers. In addition, Routing and Remote Access NAT is designed to work in networks with or without the Active Directory directory service.

The following figure shows an example of a single-subnet private network that uses a Routing and Remote Access NAT-enabled router to provide access to the Internet. Computers on the private network have a private IPv4 address, except for the router, which has both a private and a public address. The Web server, like any computer on the Internet, has a public IPv4 address.

Client on a Private Network Behind a Routing and Remote Access NAT Accessing a Resource over the Internet

The following table describes each component shown in the preceding figure.

Components of a Private Network Behind a NAT-enabled Router

Component	Description
Client PCs	Each client has a private IPv4 address configured on its network adapter. Clients need only a Web browser and access to a NAT-enabled router to be able to access the Web server across the Internet.
Routing and Remote Access NAT-enabled router	The NAT-enabled router has a private IP v4 address configured on its private interface, and a public IPv4 address configured on its Internet interface (in this example, a dial-up modem). The router has the optional Basic Firewall, DHCP allocator, and DNS proxy NAT components enabled. For more information, see “Optional NAT Subsystems.” For a larger network, an administrator might also configure a more sophisticated firewall in addition to using Basic Firewall to protect the Internet interface of the NAT-enabled router and might use a DHCP server (required if the network has more than one segment) and a DNS server.
Web server	A Web server on the Internet provides resources needed by the client computers on the private network. Like all computers on the Internet, it has a public IPv4 address.

For information about why NAT was developed to mediate between private and public networks, see “What Is NAT?” in this collection.

One major type of organization that deploys Routing and Remote Access NAT is the small office or home office (SOHO) customer. Routing and Remote Access NAT has three optional sub-components — Basic Firewall, DHCP allocator, and DNS proxy — that are designed specifically to provide vital services while simplifying configuration for smaller-sized networks.

In Windows Server 2003, the Routing and Remote Access NAT routing protocol component is now integrated with Basic Firewall in order to provide protection to the NAT-enabled router’s Internet interface. Basic Firewall is a simple stateful packet filter that prevents unsolicited traffic originating from a public network, such as the Internet, from reaching a private network through the public interface of the NAT-enabled router. Although enabling the Basic Firewall feature is optional, enabling it is a recommended practice even if your network has other firewall software installed. Enabling Basic Firewall helps secure the NAT-enabled router and strengthens overall network security by protecting the private network from unwanted Internet traffic.

Basic Firewall, which combines stateful packet filtering of network traffic with a set of static packet filters, monitors traffic that travels through the interface for which Basic Firewall is enabled. For an interface configured for private network traffic and to provide NAT, each packet’s source and destination addresses are recorded in a table and all incoming traffic from the public network is compared to the entries in that table. Traffic from a public network can reach the private network only if the table contains an entry that shows that the communication exchange is allowed.

Windows Server 2003 provides two methods to configure the Basic Firewall that is now integrated with Routing and Remote Access NAT:

•

If you use the Routing and Remote Access Server Setup Wizard to enable NAT, you can enable the Basic Firewall option during the same setup procedure.

•

Alternatively, if the Routing and Remote Access service is already installed with NAT enabled, you can use the Routing and Remote Access snap-in to enable Basic Firewall at any time. Note • In addition to the Basic Firewall included in the Windows Server 2003 Routing and Remote Access service to protect the public interface of a NAT router, Windows XP, Windows XP SP1, and Windows Server 2003 include Internet Connection Firewall (ICF) to protect the public interface of any server or workstation that provides Internet access to computers on a private network. ICF, which provides a firewall technology similar to Basic Firewall, can be configured by using Network Connections.

For more information about installing and configuring Routing and Remote Access NAT and its optional components, see “NAT Tools and Settings” in this collection.

If Routing and Remote Access NAT has Basic Firewall configured, an incoming TCP or UDP unicast packet is dropped unless it meets one of the following conditions:

•	The packet belongs to a previously established mapping, or meets the UDP loose source port criteria (see “How Dynamic Mapping, Static Mapping, and IP Reservations Work” in “NAT Processes and Interactions” later in this document).
•	The packet is a DHCP response packet, that is, UDP with source port 67 and destination port 68.
•	The packet matches a static port mapping (see “How Dynamic Mapping, Static Mapping, and IP Reservations Work” in “NAT Processes and Interactions” later in this document).
•	The packet matches a ticket (dynamic or editor-created). A ticket, in this context, is a statically defined port exemption that allows inbound packets that match this ticket.
•	The packet matches a redirect. A redirect changes the destination address and port of packets that match the redirect to the address or port specified in the redirect. In Routing and Remote Access NAT, a redirect is used either by the NAT FTP editor to enable FTP traffic across a NAT, or it is used by NAT deployed in combination with the Microsoft Internet Security and Acceleration (ISA) Server to provide high-security Internet access.

If Routing and Remote Access NAT has Basic Firewall configured, the firewall always accepts broadcast and multicast packets and passes them to the NAT component. However, on a computer running the Windows Server 2003, Windows XP SP1, or later operating system, NAT is set by default to drop all inbound broadcast and multicast packets. To change this default behavior, an administrator can add the following registry key and set it to 1 to allow inbound non-unicast traffic, that is, to allow broadcast and multicast packets across Basic Firewall:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IpNat\Parameters\AllowInboundNonUnicastTraffic

By default, AllowInboundNonUnicastTraffic is set to 0, which blocks inbound non-unicast traffic.

If Routing and Remote Access NAT has Basic Firewall configured, the firewall always accepts specially defined packets for the following IP protocols, which are already protected by IPSec, and passes them to the NAT component:

•	IP protocol 50 (or 0×32 in hexadecimal) for Internet Protocol security Encapsulating Security Payload (IPSec ESP), an IPSec protocol that provides confidentiality in addition to authentication, integrity, and replay.
•	IP protocol 51 (or 0×33 in hexadecimal) for IPSec Authentication Header (IPSec AH), a header that provides authentication integrity, and anti-replay.

The ICMP protocol, an extension to the Internet Protocol (IP), enables the generation of error messages, test packets, and informational messages related to IP. ICMP is described in RFC 792.

If Routing and Remote Access NAT has Basic Firewall configured, the following firewall behavior for ICMP traffic is defined:

•	Inbound echo, timestamp, mask, and router request packets are dropped.
•	Inbound echo, timestamp, mask, and router replies are dropped unless there exists a mapping automatically created by a corresponding outbound request.
•	Inbound time exceeded, parameter problem, destination unreachable, and source quench are always forwarded.
•	Outbound time exceeded, parameter problem, destination unreachable, and source quench are always dropped.
•	Redirects are always dropped.

An administrator can configure the ICMP behavior to allow message types that are dropped by default (for example, to allow an echo request).

In Windows Server 2003, the DHCP allocator feature of the Routing and Remote Access NAT routing protocol component provides a simplified form of automatic addressing. Windows Server 2003 (as well as Windows 2000 and Windows NT) supports automatic address acquisition by using the DHCP service. On starting up, a DHCP client obtains its addressing information from a DHCP server automatically, including its default gateway and DNS server. However, DHCP server configuration is complex and might be inappropriate for many SOHO networks. In response to this need, Windows, beginning with Windows 98, also supports Automatic Private IP Addressing (APIPA), in which client computers, when no DHCP server is available, automatically configure themselves with private addresses in the range 169.254.0.1 to 169.254.255.254 with a subnet mask of 255.255.0.0 (or 169.254.0.0/16 in Classless Inter-domain Routing [CDIR] notation). Computers using APIPA addresses can communicate only with other computers that are also using APIPA addresses within a single subnet but cannot connect to computers outside the subnet. This approach works, therefore, only for strictly local networks, but does not cover the case where a local network has a link to the Internet.

The DHCP allocator feature provided by Routing and Remote Access NAT provides a solution that is a combination of the two approaches just described. The DHCP allocator is disabled by default. If you enable it, the Routing and Remote Access NAT-enabled router will function as a simplified DHCP server, that is, it will automatically assign IPv4 addresses to local clients and advertise itself to its DHCP clients as both the default gateway and the DNS server to the Internet. Specifically, the DHCP allocator assigns the following to each client on the private network:

•	An IPv4 address and subnet mask.
•	The IPv4 address of a default gateway (the private address of the NAT-enabled router).
•	The IPv4 address of a DNS server (the private address of the NAT-enabled router; the router will forward a name resolution request that it receives from a client on its private network to the Internet–based DNS server for which the router is configured).

You must configure computers on the private network as DHCP clients in order to automatically receive the IP configuration.

Because the DHCP allocator provided by Routing and Remote Access NAT maintains no database, it does not require additional configuration beyond enabling the DHCP allocator feature. In Routing and Remote Access NAT, the DHCP allocator randomly allocates addresses from the range of configured addresses. For each address generated for a new client, the DHCP allocator uses the TCP/IP ARP module to ascertain whether that address is in use by another client. If a client replies to the ARP message indicating that it is using that address, a new address is generated. Each address assignment has a lease time of 10 minutes to avoid duplicate addresses that might be used by unavailable computers.

Note

•

Configuring the NAT DHCP allocator feature works well when all computers on the local network are connected to the same subnet. On the same subnet, computers share each other’s broadcasts and, therefore, can resolve each other’s names by using broadcast NetBIOS name queries. If the network has multiple subnets, you must use a DHCP server rather than the DHCP allocator capability of the NAT/Basic Firewall component.

The DHCP allocator allocates addresses only to clients on permanently connected interfaces (such as LAN media) that are configured as private. You can configure this feature at either of two points:

•	If you use the Routing and Remote Access Server Setup Wizard to enable NAT and you choose a network interface with a static IPv4 address as the private interface, you are given the option toenable the DHCP allocator feature for addressing services and the DNS Proxy feature for name resolution services. (For more information about “DNS Proxy,” see “DNS Proxy,” described next.)
•	Alternatively, if the Routing and Remote Access service is already installed with NAT enabled, you can use the Routing and Remote Access snap-in to enable the DHCP allocator at any time.

For more information about installing and configuring Routing and Remote Access NAT and its optional components, see “NAT Tools and Settings” in this collection.

In Windows Server 2003, the DNS proxy feature of the Routing and Remote Access NAT routing protocol component provides a simplified name resolution service. Windows Server 2003 (as well as Windows 2000 and Windows NT) supports the assignment of DNS server addresses to DHCP clients during DHCP address assignment. This scheme fails in the case of a SOHO where the DNS server resides either with an ISP or on a corporate network because the correct DNS server address cannot be known until after a connection is established. Moreover, the typical SOHO will not have a DHCP server configured.

To solve this problem, a Routing and Remote Access NAT-enabled router that has both the DHCP allocator (described earlier) and the DNS proxy features configured provides its own address as the DNS server address to DHCP clients on the local network. Then, when the connection to the Internet is established, the NAT-enabled router proxies DNS name resolution requests to the Internet DNS server address assigned to the Internet interface of the router. The DNS proxy makes the name resolution process transparent from the point of view of local computers. Like the DHCP allocator, the DNS proxy is disabled by default.

The following list explains how DNS proxy works:

1.	The private computer sends a DNS name query request to the DNS proxy (source: private computer IP address, destination: DNS proxy private IP address).
2.	DNS proxy saves the DNS name query request in memory and sends a new DNS name query request (source: DNS proxy public IP address, destination: Internet DNS server IP address).
3.	The Internet DNS server resolves the name and sends a DNS name query response (source: Internet DNS server IP address, destination: DNS proxy public IP address).
4.	DNS proxy matches the received DNS name query response with the saved DNS name query request and sends a new DNS name query response to the private computer (source: DNS proxy private IP address, destination: private computer IP address).

To the private computer, the DNS proxy is a DNS server. To the Internet DNS server, the DNS proxy is a DNS client.

Another possible scenario in a small private network in which no DHCP server exists is to enable the DNS proxy and disable the DHCP allocator. In this case, for each computer on the private network, a static IP address, subnet mask, and default gateway (the IP address of the NAT-enabled router) is configured by using the Network Connections folder to access the TCP/IP properties page for the network adapter on the private network. In addition, on the NAT-enabled router, the address of a DNS server on the Internet is configured as the DNS server for the router by using the TCP/IP properties page on the public interface of the NAT-enabled router. This configuration enables the NAT-enabled router to pass DNS name resolution requests to the Internet DNS server for which it is configured. For more information, see “Using Network Connections to Configure NAT Clients on the Private Network” in “NAT Tools and Settings.”

In a setting where the local network already has a DNS server configured, the DNS proxy can still be useful. In all likelihood, an existing DNS server is configured to forward Internet name resolution requests to a static Internet DNS server address. This static configuration will fail whenever the address of the Internet DNS server changes. With automatic name resolution provided by the DNS proxy feature, you can configure the existing DNS server to forward Internet DNS requests to the local address of the DNS proxy, and the DNS proxy will then handle the task of dynamically finding the Internet DNS server address when the Internet connection is established.

Using DNS proxy provides an adequate solution even if multiple routed segments exist. In that event, you must disable the DHCP allocator (if it is enabled), configure a full DHCP server, and then configure the DHCP server to give the NAT-enabled router’s local address on each subnet as the DNS server address for clients on that subnet. However, if multiple subnets are configured, the recommended option is to automatically install a full DNS server in default mode, which provides caching and name registration in addition to the name resolution.

This section covers the following topics:

•	How NAT works with TCP/IP
•	How address and port translation work
•	How dynamic and static mappings and IP reservations work
•	How NAT editors work
•	How mapping and translation work together

Routing and Remote Access NAT is implemented as a routing protocol component that TCP/IP calls when a packet is sent or received. For the benefit of modules such as firewalls, the TCP/IP driver supports a pointer that sets the callout that TCP/IP invokes for incoming and outgoing data packets. The parameters of the TCP/IP callout include the IP header and data and the context for the incoming or outgoing interface. The function to which TCP/IP calls out indicates whether the data packet should be forwarded, dropped, or processed as local host traffic. TCP/IP also allows the function to provide a replacement for the data packet, to accommodate any modifications that the NAT driver might make to the packet.

When mapping between public and private addresses when a pool of public addresses exists, NAT uses TCP/IP’s Proxy ARP mechanism to respond to ARP queries for public addresses in the pool.

In the translation process, the NAT routing protocol component makes routing decisions in order to determine the interface over which to forward any given packet. To avoid consulting TCP/IP for each packet, a cache is implemented in the NAT. To keep the cache consistent with the TCP/IP forwarding database, the NAT registers for notification of route changes with TCP/IP.

The Routing and Remote Access NAT-enabled router, located, logically, at the edge point between the private and public networks, mediates between its private network and the resources on the Internet that its users want to access. To do so, the router uses both address and port translation, as described in this section.

The NAT driver modifies the source address and port in the header of TCP or UDP packets sent from a client on the private network to the public network, while also modifying the destination address and port in packets returned from the public network to the private network. Specifically, for an application for which the IPv4 address and port information is located in the IP and TCP or UDP headers (the type of application for which NAT was originally designed), the NAT-enabled router can translate the following:

•	IPv4 address in the IP header
•	Port number (either a TCP port number in the TCP header, or a UDP port number in the UDP header)

For example, traffic between a private network and the Internet — Hypertext Transfer Protocol (HTTP) traffic used to access Web servers — requires the translation of the IPv4 address in the IP header and, possibly, the TCP port in the TCP header. Some applications, however, embed address or port information inside the data portion of the packet or do not use TCP or UDP ports to identify the data stream. Translation for these applications is more complicated, and for such translation to take place, an appropriate NAT editor must exist. For more information about NAT editors, see “How NAT Editors Work” later in this section.

When a computer user on the private network connects to a resource on the Internet (or other public network), the computer’s TCP/IP protocol creates an IP packet with values for the source address and port as well as for the destination address and port. This information is set in the IP header and in the TCP header (or UDP header), as shown in the center column of the following table. The source computer (or an intermediate router) forwards this packet to the NAT-enabled router. The router then translates the source address and port of the outgoing packet, as shown in the right column of the same table. Information modified by this translation is shown in the table in italic text:

Example of Translation of Address and Port of Outgoing Packet

Address and Port	Outgoing Packet Header When Client Initiates Request	Outgoing Packet Header after NAT Translates Source Address and Port
Source IPv4 Address	Private IPv4 address	ISP-allocated public IPv4 address1
Source Port	Source application TCP or UDP port	Remapped source application TCP or UDP port
Destination IPv4 Address	Internet resource IPv4 address	Internet resource IPv4 address
Destination Port	Internet resource TCP or UDP port	Internet resource TCP or UDP port

¹ This example is a case in which the public address on the Internet interface of the NAT-enabled router is allocated by an organization’s ISP

The NAT-enabled router then sends the remapped IP packet over the Internet. When the Internet resource sends back a response to the NAT, the incoming packet contains the information shown in the center column of the next table, “Example of Translation of Address and Port of Incoming Packet.” After the NAT maps and translates the destination address and port, it contains the information as shown in the right column of that table. The NAT-enabled router forwards the translated packet to the intranet client that made the initial request. Information modified by this translation is shown in the following table in italic text.

Example of Translation of Address and Port of Incoming Packet

Address and Port	Incoming Packet Header When Internet Resource Sends Response	Incoming Packet Header After NAT Translates Destination Address and Port
Source IPv4 Address	Internet resource IPv4 address	Internet resource IPv4 address
Source Port	Internet resource TCP or UDP port	Internet resource TCP or UDP port
Destination IPv4 Address	ISP-allocated public IPv4 address1	Private IPv4 address
Destination Port	Remapped source application TCP or UDP port	Source application TCP or UDP port

¹ This example is a case in which the public address on the Internet interface of the NAT-enabled router is one allocated by an organization’s ISP

For outgoing packets, the source IPv4 address and TCP or UDP port numbers are mapped to a public source IPv4 address and a possibly changed TCP or UDP port number. For incoming packets, the destination IPv4 address and TCP or UDP port numbers are mapped to the private IPv4 address and original TCP or UDP port number.

All computers on the private network behind the NAT-enabled IP router, including the router itself, have a unique private IPv4 address and a private port number. The router also has at least one globally unique (public) IPv4 address. Optionally, an administrator can configure the router with a pool of public addresses so that multiple clients can request public network resources at the same time. The router can handle traffic for multiple clients on its private network even when it does not have a sufficient number of addresses in its public address pool to accommodate all of the clients requesting access to the public network. It can accommodate additional clients by using Network Address Port Translation (NAPT) to modify port information in the TCP or UDP packets being transmitted. RFC 3022 describes NAPT.

NAPT extends address translation by using many-to-one mapping — multiple private addresses are mapped to a single public address on the Internet interface of the NAT-enabled router. This is helpful because the number of clients with private addresses is ordinarily far larger than the available number of public addresses on the NAT-enabled router, even if the router is configured with a relatively large number of addresses in a public address pool. When the public addresses in the pool have all been translated, NAT starts to perform port translation instead of address translation.

For TCP or UDP communications, the address and port translation functionality made available by NAPT permits a client on a private network to access multiple computers on the Internet, and it enables multiple private clients to access the same Internet computer at the same time. Because both TCP and UDP ports have 16 bits, NAPT allows up to 65,535 (2¹⁶-1) communications to take place at the same time. One is subtracted from the total number because port 0 for both TCP and UPD is reserved.

How NAPT works is best understood through an example. Consider the simple case of a private network with three computers — Client A, Client B, and Client C — that use the private network IPv4 range of 192.168.0.0 with a subnet mask of 255.255.255.0. The NAT-enabled router is configured with a public pool containing the following IPv4 addresses:

157.54.35.38

157.54.35.39

The user on Client A initiates a request to look at a Web page on the Internet, so Client A sends a TCP packet to the NAT-enabled router. The NAT driver translates the packet and adds an entry for it to the NAT Mapping Table. The following figure depicts the packet translation and the entry made into the mapping table for Client A:

Packet Translation and NAT Mapping Table Entry for Client A

Next, the user on Client B initiates another TCP session with a host on the public network. The following figure depicts the packet translation for Client B and the new entry for Client B, which is added to the mapping table that already contains the entry for Client B.

Packet Translation and NAT Mapping Table Entry for Client B

Finally, the user on Client C initiates traffic from the private to the public network and thus sends a packet to the NAT-enabled router. However, the public address pool configured on the NAT-enabled router contains only two addresses, which have already been used for Clients A and B. In this case, the NAT driver translates Client C’s private address:port pair to a unique public address:port pair by changing the public port number. That is, when the pool of public addresses, which is fewer in number than the number of clients on the private network, is exhausted, the NAT driver switches from address translation to port translation. The following figure depicts the packet translation for Client C and the new entry for Client C in the mapping table.

Packet Translation and NAT Mapping Table Entry for Client C

When the resource on the public network to which each client sent a request sends a response back to the client on the private network, the same process occurs in reverse: The NAT driver intercepts the response packet, looks up the packet’s destination address in the NAT Mapping Table, finds the corresponding address of a private network client, modifies the destination address and destination port in the response packets — this time translating the packet’s public destination address and port number back to the client’s private address and port number — recomputes the checksum (which it must do any time it replaces an address in a packet header), and then sends the response across the private network to the client.

In addition to the dynamic mapping just introduced in “How Address and Port Translation Work,” Routing and Remote Access NAT technology provides for two additional types of entries in the NAT Mapping Table: static mapping and IP reservations. Each of the three mapping types is designed for a different purpose.

Whenever a NAT-enabled router receives an outgoing TCP or UDP packet from a local client that is initiating communications with a computer on the public network, the NAT driver creates an entry in the NAT Mapping Table, called a 5-tuple entry, that contains the following five pieces of information:

{protocol (TCP or UDP), private address, private port, public address, public port}

An alternative notation representing this 5-tuple entry is the following:

{protocol (TCP or UPD), source address, source port, destination address, destination port}

The private address and port pair are automatically (dynamically) mapped to the public address and port pair. This is the type of mapping illustrated earlier in “How Address and Port Translation Work.” This entry in the NAT Mapping Table enables the NAT-enabled router to direct a response packet from a computer on the public network back to the client on the private network that sent initial the request.

Because the number of mappings that can be established is limited by the number of available 16-bit TCP and UDP ports, the NAT driver must eventually delete the dynamic mappings that it creates in order to free up port numbers for use in new mappings. A dynamic mapping entry remains in the mapping table for the length of time that the administrator specifies on the Translation tab for the properties of the NAT/Basic Firewall component in the Routing and Remote Access snap-in. Routing and Remote Access NAT, by default, uses the RFC 1631 recommended timeouts of 24 hours for idle TCP mappings and 1 minute for idle UDP mappings.

With dynamic mapping, in order for a TCP or UDP packet to pass through the NAT from the public network to the private network, a mapping must have been established previously by a packet sent from the private to the public network. However, if a client on the public network attempts to establish a TCP or UDP session with a computer on the private network (such as a Web server on the private network or a computer on the private network that provides a game application), no dynamic mapping will be found and the incoming packet will be discarded.

If an organization wants to allow such incoming traffic to a specific computer on the private network, Routing and Remote Access NAT allows an administrator to use the Services and Ports tab on the properties page of the public interface in the Routing and Remote Access snap-in to configure a static mapping for this traffic. Thus, the way that the NAT-enabled router forwards Internet traffic into its private network is either in response to traffic initiated by a user on the private network, which creates a dynamic mapping, or because an administrator has configured a static mapping to enable Internet users to access specific resources on the private network. (For an alternative to static mapping, see “IP Reservations” later in this section).

Static mappings have limited usefulness for connections between a private network and the Internet because of the large number of possible connections. Too many connections can make the NAT Mapping Table grow excessively and thus slow router performance.

A static mapping consists of a 5-tuple entry identical in content to a dynamic mapping entry:

{protocol (TCP or UDP), private address, private port, public address, public port}

Unlike a dynamic mapping, a static mapping explicitly matches a given TCP or UDP port number to both the private and the public address in the static entry in the mapping table. For example, to set up a Web server on a computer on a private network, an administrator could create a static mapping that maps [Public IPv4 Address, TCP Port 80] to [Private IPv4 Address, TCP Port 80]. Port 80 is, by convention, assigned to the World Wide Web (WWW) and used by Web servers for HTTP traffic. When a packet arrives for Public IPv4 Address and Port 80, the NAT-enabled router directs the packet to the Web server on the private network.

Any server running on a well-known port on the private network (such as HTTP or FTP servers) can have only one instance accessible to clients running on the public network.

Multiple interfaces can have translation enabled at the same time, as in the case of a home where a user connects both to the Internet and to a corporate network. Therefore, static mappings in Routing and Remote Access NAT can be configured on a per-interface basis.

A static mapping entry remains in the mapping table until an administrator deletes it.

To better support various types of peer-to-peer applications, the NAT mapping behavior for UDP differs from that of TCP in the following two ways:

When creating a new TCP mapping for an outbound packet, the NAT driver chooses a source port without regard for already existing mappings as long as such a choice does not result in a conflict. In contrast, when choosing a source port for a UDP mapping for an outbound packet, the NAT driver determines if a mapping exists that has the same private address and port. If such a mapping exists, the NAT driver will use the same public port for the new mapping. For example:

•	If a client on the private network makes a TCP connection to two different computers on the public network from the same source port, the NAT driver will choose different source ports for those mappings.
•	If a client on the private network sends UDP packets to two different computers on the public network from the same source port, the NAT driver will use the same source port for both mappings.

For TCP, an inbound packet must exactly match the 5-tuple for a mapping (that is, protocol, source address, source port, destination address, and destination port). For UDP, however, an inbound packet must match only the protocol, destination address, and destination port of a mapping — the source address and source port of the packet are effectively ignored. This “loose matching behavior” applies only if the private port is greater than 1024. Allowing this behavior for ports below 1024 would introduce a security risk because it might allow unfettered access to such sensitive TCP and UDP ports as 137 (NetBIOS Name service) and 445 (Microsoft Common Internet File System [CIFS]).

If you want to allow a computer on the Internet to initiate a connection to a computer on the private network behind the NAT-enabled router, an alternative to using static mapping is to configure an IP reservation to handle this traffic. If you establish a public IPv4 address reservation to one of the private IPv4 addresses on the private network, all incoming traffic addressed to the specified public address is sent to the private address reserved for it. Thus, instead of putting a computer directly on the public network, the traffic is transmitted through the NAT-enabled router. For both static mapping and IP reservations, this is an advantage because, typically, the router is configured with a firewall and other filters.

For example, you might want to use an IP reservation to allow traffic to a Web server on the private network. You can allow such incoming traffic by first using the Address Pool tab on the properties page of the public interface in the Routing and Remote Access snap-in to configure an IP address pool (you cannot configure an IP reservation until after you configure at least one IP address pool). You can then configure the IP reservation itself by using the Reservations button on the Address Pool tab.

IP reservations are particularly useful when the number of public IP addresses on the NAT-enabled router is large — reservations provide an easy way to map public to private addresses. In addition, IP reservations are useful for IP protocols that pick port numbers randomly, which means that the administrator does not need to know the port numbers in advance. IP reservations can also be used for IP protocols that do not use ports because this process is independent of the protocol (whether TCP, UDP, or ICMP). For an example showing how IP reservations work, see “Static Mapping and IP Reservation Examples” later in this document.

For outgoing traffic from a computer on the private network for which an IP reservation exists, the NAT-enabled router does not use the public IP address reserved for that private computer. Outgoing traffic from a computer on the private network to any destination on the Internet, including traffic to a Web server for which an IP reservation exists, is handled by the NAT-enabled router by using standard address and port translation.

When a network administrator uses the Routing and Remote Access snap-in to create an IP reservation, a 2-tuple entry is entered in the NAT Mapping Table:

{private address, public address}

An IP reservation remains in the mapping table until an administrator deletes it.

The behavior of dynamic and static mapping entries and IP reservations is determined by the amount of information each stores:

•	5-tuple dynamic and static mappings are more restrictive than IP reservations because incoming or outgoing traffic must match all five pieces of information in the NAT Mapping Table entry before the packet will be forwarded; or, in the case of UDP for ports greater than 1024, an inbound packet must match three pieces of information — the protocol, destination address, and destination port.
•	2-tuple IP reservations are less restrictive than either dynamic or static mappings because incoming or outgoing traffic that has a destination IPv4 address that matches the public IPv4 address in the NAT Mapping Table entry will be forwarded.

To continue the example presented earlier in “How Address and Port Translation Work,” which illustrates dynamic mapping, an administrator next decides to use Client B as a Web server and therefore uses the Routing and Remote Access snap-in to add a static mapping for Client B. This mapping means that all inbound TCP traffic directed to 157.54.35.38 and port 80 on the NAT-enabled router will match that address:port pair to Client B’s own address and port 80. Thus, the NAT Mapping Table shown in the earlier figure, “Packet Translation and NAT Mapping Table Entry for Client C,” changes to include a second entry for Client B (the new fourth row), as shown in the following table.

Static Mapping of Client B’s Private Address and Port to a Public Address and Port

Client	Private Address:Port	Protocol	Public Address:Port	Type
A	192.168.0.10:3576	TCP	157.54.35.38:5000	Dynamic address translation
B	192.168.0.11:2258	TCP	157.54.35.39:5000	Dynamic address translation
C	192.168.0.12:1944	TCP	157.54.35.39:5001	Dynamic port and address translation
B	192.168.0.11:80	TCP	157.54.35.38:80	Static address translation

If the administrator then uses the Routing and Remote Access snap-in to add an IP reservation to the NAT Mapping Table, reserving public IPv4 address 157.54.35.39 for Client A, any existing dynamic mappings to 157.54.35.39 are preempted by this change. That is, the earlier dynamic mappings to the public address 157.54.35.39 no longer exist. Only the IP reservation for 157.54.35.39 remains in the NAT Mapping Table, as shown in the following table.

IP Reservation of Client A’s Private Address to a Public Address

Client	Private Address:Port	Protocol	Public Address:Port	Type
A	192.168.0.10:3576	TCP	157.54.35.38:5000	Dynamic address translation
B	192.168.0.11:80	TCP	157.54.35.38:80	Static address translation
A	192.168.0.10:*	*	157.54.35.39.*	IP reservation address translation

With an IP reservation, as the asterisks in the last row of the preceding table indicate, it is irrelevant which protocol (TCP or UDP) is used or what the destination port number is on an inbound packet. All that matters is that the destination address is matched to the public IPv4 address in the reservation. Therefore, in the example in the preceding table, any traffic with a destination IPv4 address of 157.54.35.39 is forwarded to client A.

To summarize outbound and inbound packet translation:

•

When a TCP or UDP packet outbound to the Internet from a client on the private network arrives at the private interface of the NAT-enabled router, the NAT driver looks in the NAT Mapping Table for an existing dynamic mapping. If none is found, the NAT driver creates a new mapping, updates the checksum, and sends the packet out to the Internet over a dial-up, broadband, or other connection.

•

When a TCP or UDP packet inbound from the Internet arrives at the Internet interface of the NAT-enabled router, the NAT driver looks in the NAT Mapping Table for an existing dynamic or static mapping or for an IP reservation. If any of the three types of entries is found, the NAT driver translates the incoming packet and delivers it over the private interface of the NAT-enabled router to the client. Otherwise, the packet is discarded.

In Routing and Remote Access NAT, the NAT driver is designed to translate IPv4 address and TCP or UDP port information for traffic between a private and a public network. If the IPv4 address and port information is located only in the IP and TCP or UDP headers — as is the case, for example, for HTTP (World Wide Web) traffic — the NAT driver can translate the application protocol transparently. However, the NAT driver, on its own, cannot translate packets in the following two types of cases:

Certain applications embed address or port information inside the data portion of the packet rather than in the IP and TCP or UDP headers. One such application is the File Transfer Protocol (FTP) — for the FTP port command, FTP stores the IPv4 address in the FTP header. In addition, FTP stores the IPv4 address in dotted decimal format, which means that the translated IPv4 address in the FTP header can be a different size, and, therefore, the TCP sequence numbers must be modified to ensure that no data is lost. Other examples of applications that the NAT driver cannot translate transparently include streaming applications, such as RealAudio and CUSeeMe, which use a TCP connection to dynamically select a UDP port over which data is then transmitted.

Data that is tunneled from one geographic site to another through the Internet by using the Point-to-Point Tunneling Protocol (PPTP) does not use a TCP or UDP header. Instead, PPTP data uses a Generic Routing Encapsulation (GRE) header, and the Call ID, which is stored in the GRE header, identifies the data stream. If the NAT driver does not correctly translate the Call ID within the GRE header, connectivity problems can occur.

NAT editors are application level gateways (ALGs) that have been developed to translate packets in these two cases. A NAT editor examines the packets sent by such applications and modifies the data portion of the packet as appropriate. Because such modifications might change the size of packets, a NAT editor must also adjust sequence numbers for TCP connections after any translation has changed the number of bytes in the TCP data stream.

The Windows Server 2003 Routing and Remote Access service installs two built-in NAT editors along with the NAT routing protocol component — Internet Control Message Protocol (ICMP) to support error messages, and Point-to-Point Tunneling Protocol (PPTP) to support PPTP VPN traffic. Both editors are always on. The NAT driver consults the editors whenever the payload of the packet being translated matches one of the installed editors. The editor modifies the payload and returns the result to the NAT driver.

Note

•

In addition to the NAT editors, Routing and Remote Access NAT includes two NAT proxies, which redirect packets to a module that builds a new packet modified so that it can cross a NAT. The NAT proxies are the File Transfer Protocol (FTP) proxy, which supports FTP traffic across a NAT, and the H.323 proxy, which supports NetMeeting calls across a NAT. Unlike NAT editors, which are always on, NAT proxies are disabled by default. Both proxies can be turned on or off by using the appropriate Netsh command in the netsh routing ip nat context: you can enable the NAT proxies by using add ftp or add h323; you can disable the NAT proxies by using delete ftp or delete h323.

The two flowcharts in this section, “Processing for Outbound and Inbound NAT Traffic” and “Packet Translation Process,” outline the overall process that the Routing and Remote Access NAT-enabled router uses to manage outbound and inbound packets.

First, the router determines whether the packet is outbound or inbound. Depending on the outcome of that initial determination, the following occurs:

For traffic from the private network that is outbound to the Internet (or other public network), the NAT driver assesses whether or not an address/port mapping (whether a static or dynamic mapping, or an IP reservation) exists for the packet. If such a mapping exists, the NAT driver uses the existing mapping; if none exists, the NAT driver creates a new dynamic mapping. Whether a single IPv4 address or a pool of addresses is available determines how that mapping is made (see “How Address and Port Translation Work” earlier in this section). Next, the NAT driver checks for editors and invokes one if necessary (assuming that one exists). If no editor is needed, the NAT driver performs standard network address translation of the TCP or UDP header and the IP header (for an outbound packet, translating the source TCP or UDP port and the source IP address), and then refreshes the NAT Mapping Table. Finally, the NAT-enabled router uses its Internet interface to forward the outgoing packet to the resource computer on the Internet.

For a response or other specifically allowed incoming traffic from the Internet (or other public network) that is inbound to the private network, the NAT driver also assesses whether or not an address/port mapping (whether static or dynamic mapping, or an IP reservation) exists for the packet. If a mapping exists, the NAT driver uses the existing mapping; if no mapping exists, the incoming packet is discarded. Next, the NAT driver checks for editors and invokes one if necessary (assuming that one exists). If no editor is needed, the NAT driver performs standard network address translation of the TCP or UDP header and the IP header (for an inbound packet, translating the destination TCP or UDP port and the destination IP address), and then refreshes the NAT Mapping Table. Finally, the NAT-enabled router uses its private interface to forward the incoming packet to the appropriate computer on the private network.

Of the following two flowcharts, the second is a continuation of the first. In the first flowchart, “Processing for Outbound and Inbound NAT Traffic,” the two process boxes (one on the left and another on the right) labeled “Performs packet translation” both point to the second flowchart, “Packet Translation Process.”

Processing for Outbound and Inbound NAT Traffic

Packet Translation Process

For more information about NAT, see the following RFCs in the IETF RFC Database:

•	RFC 1631, “The IP Network Address Translator (NAT).”
•	RFC 3022, “Traditional IP Network Address Translator (Traditional NAT).”
•	RFC 1918, “Address Allocation for Private Internets.”
•	RFC 2663, “IP Network Address Translator (NAT) Terminology and Considerations.”

The following resource contains additional information that is relevant to this section:

•	“Network Address Translation (NAT)” in Internetworking with TCP/IP, Vol. 1: Principles, Protocols, and Architecture, Fourth Edition, by Douglas E. Comer, Prentice Hall, New Jersey, 2000.

Windows Server 2003 TCP/IP enables enterprise networking and connectivity. Adding TCP/IP to a Windows Server 2003 configuration offers the following advantages:

•	A standard, routable enterprise networking protocol that is the most complete and accepted protocol available. All modern network operating systems offer TCP/IP support, and most large networks rely on TCP/IP for much of their network traffic.
•	A technology for connecting dissimilar systems. Many standard connectivity utilities are available to access and transfer data between dissimilar systems, including File Transfer Protocol (FTP) and Telnet, a terminal emulation protocol. Several of these standard utilities are included with Windows Server 2003.
•	A robust, scalable, cross-platform client/server framework. Windows Server 2003 TCP/IP offers the Windows Sockets interface, which is ideal for developing client/server applications that can run on Windows Sockets–compliant TCP/IP protocol implementations from other vendors.
•	A method of gaining access to the Internet. The Internet consists of thousands of networks worldwide, connecting research facilities, universities, libraries, private companies, and individuals.

Note

•	The term Internet refers to the worldwide public Internet. An intranet refers to a private IP-based internetwork.

Windows Server 2003 TCP/IP supports the following standard features:

•	Ability to bind to multiple network adapters with different media types.
•	Logical and physical multihoming.
•	Internal IP routing capability.
•	Internet Group Management Protocol (IGMP) (IP multicasting).
•	Duplicate IP address detection.
•	Multiple configurable default gateways.
•	Dead gateway detection.
•	Automatic Path Maximum Transmission Unit (PMTU) discovery.
•	Internet Protocol security (IPSec).
•	Quality of Service (QoS).
•	Asynchronous Transfer Mode Tutorial (ATM) services.
•	Virtual Private Networks (VPNs) with the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol with IPSec (L2TP/IPSec).

The features and improvements of TCP/IP for Windows Server 2003 include the following:

•	Windows Server 2003 and Windows XP (Service Pack 1 or later) now include a production-quality IPv6 protocol stack. For more information about IPv6, see IPv6 Technical Reference.
•	Auto-negotiation of RFC 1323 options (window scaling and TCP timestamps).
•	Default support of network interface cards providing large send offload (LSO) and checksum offload.
•	Internet Group Management Protocol (IGMP) version 3.
•	Reliable multicast with Pragmatic General Multicast (PGM).
•	Alternate configuration of a static IP address configuration.
•	Automatic determination of the interface-related and default route metrics.

The standards for TCP/IP are published in a series of documents that are called Requests for Comments (RFCs). RFCs describe the internal workings of the Internet. Some RFCs describe network services or protocols and their implementations, whereas others summarize policies. TCP/IP standards are always published as RFCs, although not all RFCs specify standards.

TCP/IP standards are not developed by a committee, but rather by consensus. Anyone can submit a document for publication as an RFC. Documents are reviewed by a technical expert, a task force, or the RFC editor, and then assigned a status. The status specifies whether a document is being considered for becoming a standard.

There are five RFC status assignments, shown below.

RFC Status Assignments

Status	Description
Required	Must be implemented on all TCP/IP-based hosts and gateways.
Recommended	Encouraged that all TCP/IP-based hosts and gateways implement the RFC specifications. Recommended RFCs are usually implemented.
Elective	Implementation is optional. Application has been agreed to but is not a requirement.
Limited Use	Not intended for general use.
Not Recommended	Not recommended for implementation.

If a document is being considered for becoming a standard, it goes through stages of development, testing, and acceptance known as the Internet Standards Process. These stages are formally labeled maturity levels. The following table lists the three maturity levels for Internet Standards.

Maturity Levels for Internet Standards

Maturity Level	Description
Proposed Standard	This specification is generally stable, has resolved known design issues, is believed to be well understood, has received significant community review, and appears to hold enough community interest to be considered valuable.
Draft Standard	This must be well understood and known to be quite stable, both in its semantics and as a basis for developing an implementation.
Internet Standard	This specification is characterized by a high degree of technical maturity, and it is generally agreed that the specified protocol or service provides significant benefit to the Internet community.

When a document is published, it is assigned an RFC number. If changes are required, a new RFC is published with a new number. The original RFC is never updated. Therefore, it is important to verify that you have the most recent RFC on a particular topic.

RFCs can be obtained in several ways. To obtain any RFC, or a full and current indexed listing of all RFCs published to date, see the IETF RFC Database.

The TCP/IP protocol component that is installed in your network operating system is a series of interconnected protocols called the TCP/IP core protocols. All other applications and other protocols in the TCP/IP protocol suite rely on the basic services provided by the following protocols: IP, ARP, ICMP, IGMP, TCP, and UDP. For more information about these protocols, see How TCP/IP Works.

The Windows Server 2003 operating system provides the following TCP/IP-related services:

•	Dynamic Host Configuration Protocol (DHCP) client and server and DHCP Relay Agent (with the Routing and Remote Access service).
•	In the absence of a DHCP server, Automatic Private IP Addressing (APIPA) or an alternate static IP address configuration is used.
•	Windows Internet Name Service (WINS), a NetBIOS name client and server.
•	Domain Name System (DNS) client and server, including support for DNS dynamic updates.
•	Dial-up support using the Point-to-Point Protocol (client and server) and Serial Line Internet Protocol (client only).
•	PPTP and L2TP/IPSec, used for remote access and site-to-site VPN connections.
•	TCP/IP network printing (client only with the Lpr.exe and Lpq.exe tools).
•	SNMP agent.
•	NetBIOS interface.
•	Network Location Service.
•	Windows Sockets version 2 (Winsock2) interface.
•	Remote Procedure Call (RPC) support.
•	Network Dynamic Data Exchange (NetDDE).
•	Computer browsing (My Network Places) across IP routers.
•	Reliable multicast with the Pragmatic General Multicast (PGM) protocol.
•	Basic TCP/IP connectivity utilities, including: finger, ftp, rcp, rexec, rsh, telnet, and tftp.
•	Server and client software for simple network protocols, including: Character Generator, Daytime, Discard, Echo, and Quote of the Day.
•	Routing Information Protocol (RIP) listener (for Windows XP Professional) and RIP and Open Shortest Path First (OSPF) (with the Routing and Remote Access service).
•	Network Address Translator (NAT) capabilities using either the Internet Connection Service (ICS) or the NAT/Basic Firewall routing protocol component of the Routing and Remote Access Service.
•	Stateful firewalling capabilities using either the Internet Connection Firewall (ICF) or the NAT/Basic Firewall routing protocol component of the Routing and Remote Access service.
•	Multicast forwarding and IGMP router and proxy capabilities with the Routing and Remote Access Service.
•	TCP/IP management and diagnostic tools, including: arp, ipconfig, nbtstat, netsh, netstat, ping, pathping, route, nslookup, and tracert.

For more information about RFCs, see the IETF RFC Database.

In this section

•	TCP/IP Protocol Architecture
•	IPv4 Addressing
•	Name Resolution
•	IPv4 Routing
•	Physical Address Resolution
•	Related Information

TCP/IP for IP version 4 (IPv4) is a networking protocol suite that Microsoft Windows uses to communicate over the internet with other computers. It interacts with Windows naming services like DNS and security technologies, such as IPsec primarily, as these help facilitate the successful and secure transfer of IP packets between machines.

Ideally, TCP/IP is used whenever Windows-based computers communicate over networks.

This subject describes the components of the TCP/IP Protocol Suite, the protocol architecture, which functions TCP/IP performs, how addresses are structured and assigned, and how packets are structured and routed.

Microsoft Windows Server 2003 provides extensive support for the Transmission Control Protocol/Internet Protocol (TCP/IP) suite, as both a protocol and a set of services for connectivity and management of IP internetworks. Knowledge of the basic concepts of TCP/IP is an absolute requirement for the proper understanding of the configuration, deployment, and troubleshooting of IP-based Windows Server 2003 and Microsoft Windows 2000 intranets.

TCP/IP protocols map to a four-layer conceptual model known as the DARPA model, named after the U.S. government agency that initially developed TCP/IP. The four layers of the DARPA model are: Application, Transport, Internet, and Network Interface. Each layer in the DARPA model corresponds to one or more layers of the seven-layer Open Systems Interconnection (OSI) model.

The following figure shows the TCP/IP protocol architecture.

TCP/IP Protocol Architecture

Note

•	The architectural diagram above corresponds to the Internet Protocol TCP/IP and does not reflect IP version 6. To see a TCP/IP architectural diagrm that includes IPv6, see How IPv6 Works in this technical reference.

The Network Interface layer (also called the Network Access layer) handles placing TCP/IP packets on the network medium and receiving TCP/IP packets off the network medium. TCP/IP was designed to be independent of the network access method, frame format, and medium. In this way, TCP/IP can be used to connect differing network types. These include local area network (LAN) media such as Ethernet and Token Ring and WAN technologies such as X.25 and Frame Relay. Independence from any specific network media allows TCP/IP to be adapted to new media such as asynchronous transfer mode (ATM).

The Network Interface layer encompasses the Data Link and Physical layers of the OSI model. Note that the Internet layer does not take advantage of sequencing and acknowledgment services that might be present in the Network Interface layer. An unreliable Network Interface layer is assumed, and reliable communication through session establishment and the sequencing and acknowledgment of packets is the function of the Transport layer.

The Internet layer handles addressing, packaging, and routing functions. The core protocols of the Internet layer are IP, ARP, ICMP, and IGMP.

•	The Internet Protocol (IP) is a routable protocol that handles IP addressing, routing, and the fragmentation and reassembly of packets.
•	The Address Resolution Protocol (ARP) handles resolution of an Internet layer address to a Network Interface layer address, such as a hardware address.
•	The Internet Control Message Protocol (ICMP) handles providing diagnostic functions and reporting errors due to the unsuccessful delivery of IP packets.
•	The Internet Group Management Protocol (IGMP) handles management of IP multicast group membership.

The Internet layer is analogous to the Network layer of the OSI model.

The Transport layer (also known as the Host-to-Host Transport layer) handles providing the Application layer with session and datagram communication services. The core protocols of the Transport layer are Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP).

•	TCP provides a one-to-one, connection-oriented, reliable communications service. TCP handles the establishment of a TCP connection, the sequencing and acknowledgment of packets sent, and the recovery of packets lost during transmission.
•	UDP provides a one-to-one or one-to-many, connectionless, unreliable communications service. UDP is used when the amount of data to be transferred is small (such as data that fits into a single packet), when you do not want the overhead of establishing a TCP connection, or when the applications or upper layer protocols provide reliable delivery.

The TCP/IP Transport layer encompasses the responsibilities of the OSI Transport layer.

The Application layer lets applications access the services of the other layers and defines the protocols that applications use to exchange data. There are many Application layer protocols and new protocols are always being developed.

The most widely known Application layer protocols are those used for the exchange of user information:

•	The Hypertext Transfer Protocol (HTTP) is used to transfer files that make up the Web pages of the World Wide Web.
•	The File Transfer Protocol (FTP) is used for interactive file transfer.
•	The Simple Mail Transfer Protocol (SMTP) is used for the transfer of mail messages and attachments.
•	Telnet, a terminal emulation protocol, is used for logging on remotely to network hosts.

Additionally, the following Application layer protocols help facilitate the use and management of TCP/IP networks:

•	The Domain Name System (DNS) is used to resolve a host name to an IP address.
•	The Routing Information Protocol (RIP) is a routing protocol that routers use to exchange routing information on an IP internetwork.
•	The Simple Network Management Protocol (SNMP) is used between a network management console and network devices (routers, bridges, intelligent hubs) to collect and exchange network management information.

Examples of Application layer interfaces for TCP/IP applications are Windows Sockets and NetBIOS. Windows Sockets provides a standard application programming interface (API) under Windows Server 2003. NetBIOS is an industry-standard interface for accessing protocol services such as sessions, datagrams, and name resolution. More information on Windows Sockets and NetBIOS is provided later in this chapter.

The TCP/IP Application layer encompasses the responsibilities of the OSI Session, Presentation, and Application layers.

The TCP/IP protocol component that is installed in your network operating system is a series of interconnected protocols called the core protocols of TCP/IP. All other applications and other protocols in the TCP/IP protocol suite rely on the basic services provided by the following protocols: IP, ARP, ICMP, IGMP, TCP, and UDP.

IP is a connectionless, unreliable datagram protocol primarily responsible for addressing and routing packets between hosts. Connectionless means that a session is not established before exchanging data. Unreliable means that delivery is not guaranteed. IP always makes a “best effort” attempt to deliver a packet. An IP packet might be lost, delivered out of sequence, duplicated, or delayed. IP does not attempt to recover from these types of errors. The acknowledgment of packets delivered and the recovery of lost packets is the responsibility of a higher-layer protocol, such as TCP. IP is defined in RFC 791.

An IP packet consists of an IP header and an IP payload. The following table describes the key fields in the IP header.

Key Fields in the IP Header

IP Header Field	Function
Source Address	The IP address of the original source of the IP datagram.
Destination Address	The IP address of the final destination of the IP datagram.
Identification	Used to identify a specific IP datagram and to identify all fragments of a specific IP datagram if fragmentation occurs.
Protocol	Informs IP at the destination host whether to pass the packet up to TCP, UDP, ICMP, or other protocols.
Checksum	A simple mathematical computation used to verify the bit-level integrity of the IP header.
Time to Live (TTL)	Designates the number of network segments on which the datagram is allowed to travel before being discarded by a router. The TTL is set by the sending host and is used to prevent packets from endlessly circulating on an IP internetwork. When forwarding an IP packet, routers are required to decrease the TTL by at least one.

If a router receives an IP packet that is too large for the network to which the packet is being forwarded, IP fragments the original packet into smaller packets that fit on the downstream network. When the packets arrive at their final destination, IP on the destination host reassembles the fragments into the original payload. This process is referred to as fragmentation and reassembly. Fragmentation can occur in environments that have a mix of networking media, such as Ethernet and Token Ring.

The fragmentation and reassembly works as follows:

•	When an IP packet is sent by the source, it places a unique value in the Identification field.
•	The IP packet is received at the router. The IP router notes that the maximum transmission unit (MTU) of the network onto which the packet is to be forwarded is smaller than the size of the IP packet.
•	IP divides the original IP payload into fragments that fit on the next network. Each fragment is sent with its own IP header that contains: • The original Identification field identifying all fragments that belong together. • The More Fragments Flag indicating that other fragments follow. The More Fragments Flag is not set on the last fragment, because no other fragments follow it. • The Fragment Offset field indicating the position of the fragment relative to the original IP payload.

When the fragments are received by IP at the remote host, they are identified by the Identification field as belonging together. The Fragment Offset field is then used to reassemble the fragments into the original IP payload.

When IP packets are sent on shared access, broadcast-based networking media — such as Ethernet or Token Ring — the media access control (MAC) address corresponding to a forwarding IP address must be resolved. ARP uses MAC-level broadcasts to resolve a known forwarding or next-hop IP address to its MAC address. ARP is defined in RFC 826.

Internet Control Message Protocol (ICMP) provides troubleshooting facilities and error reporting for packets that are undeliverable. For example, if IP is unable to deliver a packet to the destination host, ICMP sends a Destination Unreachable message to the source host. The following table shows the most common ICMP messages.

Common ICMP Messages

ICMP Message	Function
Echo Request	Troubleshooting message used to check IP connectivity to a desired host. The ping utility sends ICMP Echo Request messages.
Echo Reply	Response to an ICMP Echo Request.
Redirect	Sent by a router to inform a sending host of a better route to a destination IP address.
Source Quench	Sent by a router to inform a sending host that its IP datagrams are being dropped due to congestion at the router. The sending host then lowers its transmission rate. Source Quench is an elective ICMP message and is not commonly implemented.
Destination Unreachable	Sent by a router or the destination host to inform the sending host that the datagram cannot be delivered.

The following table describes the most common ICMP Destination Unreachable ICMP messages.

Common ICMP Destination Unreachable Messages

Destination Unreachable Message	Description
Host Unreachable	Sent by an IP router when a route to the destination IP address cannot be found.
Protocol Unreachable	Sent by the destination IP node when the Protocol field in the IP header cannot be matched with an IP client protocol currently loaded.
Port Unreachable	Sent by the destination IP node when the Destination Port in the UDP header cannot be matched with a process using that port.
Fragmentation Needed and DF Set	Sent by an IP router when fragmentation must occur but is not allowed due to the source node setting the Don’t Fragment (DF) flag in the IP header.
Source Route Failed	Sent by an IP router when delivery of the IP packet using source route information (stored as source route option headers) fails.

ICMP does not make IP a reliable protocol. ICMP attempts to report errors and provide feedback on specific conditions. ICMP messages are carried as unacknowledged IP datagrams and are themselves unreliable. ICMP is defined in RFC 792.

Internet Group Management Protocol (IGMP) is a protocol that manages host membership in IP multicast groups on a network segment. An IP multicast group, also known as a host group, is a set of hosts that listen for IP traffic destined for a specific IP multicast address. IP multicast traffic is sent to a single MAC address but processed by multiple IP hosts. A specific host listens on a specific IP multicast address and receives all packets to that IP address.

The following are some of the additional aspects of IP multicasting:

•	Host group membership is dynamic, hosts can join and leave the group at any time.
•	A host group can be of any size.
•	Members of a host group can span IP routers across multiple networks. This situation requires IP multicast support on the IP routers and the ability for hosts to register their group membership with local routers. Host registration is accomplished using IGMP.
•	A host can send traffic to an IP multicast address without belonging to the corresponding host group.

For a host to receive IP multicasts, an application must inform IP that it will receive multicasts at a specified IP multicast address. If the network technology supports hardware-based multicasting, the network interface is told to pass up packets for a specific IP multicast address. In the case of Ethernet, the network adapter is programmed to respond to a multicast MAC address corresponding to the specified IP multicast address.

A host supports IP multicast at one of the following levels:

•	Level 0: No support to send or receive IP multicast traffic.
•	Level 1: Support exists to send but not receive IP multicast traffic.
•	Level 2: Support exists to both send and receive IP multicast traffic. Windows Server 2003, Windows 2000, Microsoft Windows NT version 3.5 and later, and TCP/IP support level 2 IP multicasting.

The protocol to register host group information is IGMP, which is required on all hosts that support level 2 IP multicasting. IGMP packets are sent using an IP header.

IGMP messages take three forms.

•	Host Membership Report. When a host joins a host group, it sends an IGMP Host Membership Report message to the all-hosts IP multicast address (224.0.0.1) or to the specified IP multicast address declaring its membership in a specific host group by referencing the IP multicast address. A host can also specify the specific sources from which multicast traffic is needed.
•	Host Membership Query. When a router polls a network to ensure that there are members of a specific host group, it sends an IGMP Host Membership Query message to the all-hosts IP multicast address. If no responses to the poll are received after several polls, the router assumes no membership in that group for that network and stops advertising that multicast group information to other routers.
•	Group Leave. When a host is no longer interested in receiving multicast traffic sent to a specific IP multicast address and it sent the last IGMP Host Membership Report message in response to an IGMP Host Membership Query, it sends an IGMP Group Leave message to the specific IP multicast address. Local routers verify that the host sending the IGMP Group Leave message is the last group member for that multicast address on that subnet. If no responses to the poll are received after several polls, the router assumes no membership in that group for that subnet and stops advertising that multicast group information to other routers.

For IP multicasting to span routers across an internetwork, multicast routing protocols are used by routers to communicate host group information so that each router supporting multicast forwarding is aware of which networks contain members of which host groups. IGMP is defined in RFCs 1112 and 2236.

TCP is a reliable, connection-oriented delivery service. The data is transmitted in segments. Connection-oriented means that a connection must be established before hosts can exchange data. Reliability is achieved by assigning a sequence number to each segment transmitted. An acknowledgment is used to verify that the data is received. For each segment sent, the receiving host must return an acknowledgment (ACK) within a specified period for bytes received. If an ACK is not received, the data is retransmitted. TCP is defined in RFC 793.

TCP uses byte-stream communications, wherein data within the TCP segment is treated as a sequence of bytes with no record or field boundaries. The following table describes the key fields in the TCP header.

Key Fields in the TCP Header

Field	Function
Source Port	TCP port of sending host.
Destination Port	TCP port of destination host.
Sequence Number	Sequence number of the first byte of data in the TCP segment.
Acknowledgment Number	Sequence number of the byte the sender expects to receive next from the other side of the connection.
Window	Current size of a TCP buffer on the host sending this TCP segment to store incoming segments.
TCP Checksum	Verifies the bit-level integrity of the TCP header and the TCP data.

A TCP port provides a specific location for delivery of TCP segments. Port numbers below 1024 are well-known ports and are assigned by the Internet Assigned Numbers Authority (IANA). The following table lists a few well-known TCP ports.

Well-Known TCP Ports

TCP Port Number	Description
20	FTP (Data Channel)
21	FTP (Control Channel)
23	Telnet
80	HTTP used for the World Wide Web
139	NetBIOS session service

A TCP connection is initialized through a three-way handshake. The purpose of the three-way handshake is to synchronize the sequence number and acknowledgment numbers of both sides of the connection and exchange TCP window sizes or the use of large window sizes or TCP timestamps. The following steps outline the process:

1.	The initiator of the TCP connection, typically a client, sends a TCP segment to the server with an initial Sequence Number for the connection and a window size indicating the size of a buffer on the client to store incoming segments from the server.
2.	The responder of the TCP connection, typically a server, sends back a TCP segment containing its chosen initial Sequence Number, an acknowledgment of the client’s Sequence Number, and a window size indicating the size of a buffer on the server to store incoming segments from the client.
3.	The initiator sends a TCP segment to the server containing an acknowledgment of the server’s Sequence Number.

TCP uses a similar handshake process to end a connection. This guarantees that both hosts have finished transmitting and that all data was received.

UDP provides a connectionless datagram service that offers unreliable, best-effort delivery of data transmitted in messages. This means that neither the arrival of datagrams nor the correct sequencing of delivered packets is guaranteed. UDP does not recover from lost data through retransmission. UDP is defined in RFC 768.

UDP is used by applications that do not require an acknowledgment of receipt of data and that typically transmit small amounts of data at one time. NetBIOS name service, NetBIOS datagram service, and SNMP are examples of services and applications that use UDP. The following table describes the key fields in the UDP header.

Key Fields in the UDP Header

Field	Function
Source Port	UDP port of sending host.
Destination Port	UDP port of destination host.
UDP Checksum	Verifies the bit-level integrity of the UDP header and the UDP data.

To use UDP, an application must supply the IP address and UDP port number of the destination application. A port provides a location for sending messages. A port functions as a multiplexed message queue, meaning that it can receive multiple messages at a time. Each port is identified by a unique number. It is important to note that UDP ports are distinct and separate from TCP ports even though some of them use the same number. The following table lists a few well-known UDP ports.

Well-Known UDP Ports

UDP Port Number	Description
53	Domain Name System (DNS) name queries
69	Trivial File Transfer Protocol (TFTP)
137	NetBIOS name service
138	NetBIOS datagram service
161	SNMP

For applications to access the services offered by the core TCP/IP protocols in a standard way, network operating systems like Windows Server 2003 make industry-standard application programming interfaces (APIs) available. APIs are sets of functions and commands that are programmatically called by application code to perform network functions. For example, a Web browser application connecting to a Web site needs access to TCP’s connection establishment service.

The following figure shows two common TCP/IP APIs, Windows Sockets and NetBIOS, and their relation to the core protocols.

APIs for TCP/IP

The Windows Sockets API is a standard API under Windows Server 2003 for applications that use TCP and UDP. Applications written to the Windows Sockets API run on many versions of TCP/IP. TCP/IP utilities and the SNMP service are examples of applications written to the Windows Sockets interface.

Windows Sockets provides services that allow applications to bind to a particular port and IP address on a host, initiate and accept a connection, send and receive data, and close a connection. There are two types of sockets:

•	A stream socket provides a two-way, reliable, sequenced, and unduplicated flow of data using TCP.
•	A datagram socket provides a one-way or two-way flow of data using UDP.

A socket is defined by a protocol and an address on the host. The format of the address is specific to each protocol. In TCP/IP, the address is the combination of the IP address and port. Two sockets, one for each end of the connection, form a bi-directional communications path.

To communicate, an application specifies the protocol, the IP address of the destination host, and the port of the destination application. After the application is connected, information can be sent and received.

NetBIOS allows applications to communicate over a network. NetBIOS defines two entities, a session-level interfaceand a session management and data transport protocol.

The NetBIOS interface is a standard API for user applications to submit network input/output (I/O) and control directives to underlying network protocol software. An application program that uses the NetBIOS interface API for network communication can be run on any protocol software that supports the NetBIOS interface.

NetBIOS also defines a protocolthat functions at thesession/transport level. This is implemented by the underlying protocol software (such as the NetBIOS Frames Protocol NBFP — a component of NetBEUI or NetBIOS over TCP/IP (NetBT)), which performs the network I/O required to accommodate the NetBIOS interface command set. NetBIOS over TCP/IP is defined in RFCs 1001 and 1002. NetBT is enabled by default, however Windows Server 2003 allows you to disable NetBT for an environment that contains no NetBIOS-based network clients or applications.

NetBIOS provides commands and support for NetBIOS Name Management, NetBIOS Datagrams, and NetBIOS Sessions.

NetBIOS name management services provide the following functions:

•

Name registration and release. When a TCP/IP host initializes, it registers its NetBIOS names by broadcasting or directing a NetBIOS name registration request to a NetBIOS Name Server such as a WINS server. If another host has registered the same NetBIOS name, either the host or a NetBIOS Name Server responds with a negative name registration response. The initiating host receives an initialization error as a result. When the workstation service on a host is stopped, the host discontinues broadcasting a negative name registration response when someone else tries to use the name and sends a name release to a NetBIOS Name Server. The NetBIOS name is said to be released and available for use by another host.

•

Name Resolution. When a NetBIOS application wants to communicate with another NetBIOS application, the IP address of the NetBIOS application must be resolved. NetBT performs this function by either broadcasting a NetBIOS name query on the local network or sending a NetBIOS name query to a NetBIOS Name Server.

The NetBIOS name service uses UDP port 137.

The NetBIOS datagram service provides delivery of datagrams that are connectionless, unsequenced, and unreliable. Datagrams can be directed to a specific NetBIOS name or broadcast to a group of names. Delivery is unreliable in that only the users who are logged on to the network receive the message. The datagram service can initiate and receive both broadcast and directed messages. The NetBIOS datagram service uses UDP port 138.

The NetBIOS session service provides delivery of NetBIOS messages that are connection-oriented, sequenced, and reliable. NetBIOS sessions use TCP connections and provide session establishment, keepalive, and termination. The NetBIOS session service allows concurrent data transfers in both directions using TCP port 139.

For IP version 4, each TCP/IP host is identified by a logical IP address. The IP address is a Network layer address and has no dependence on the Data-Link layer address (such as a MAC address of a network adapter). A unique IP address is required for each host and network component that communicates using TCP/IP and can be assigned manually or by using Dynamic Host Configuration Protocol (DHCP).

The IP address identifies a system’s location on the network in the same way a street address identifies a house on a city block. Just as a street address must identify a unique residence, an IP address must be globally unique to the internetwork and have a uniform format.

Each IP address includes a network ID and a host ID.

•	The network ID (also known as a network address) identifies the systems that are located on the same physical network bounded by IP routers. All systems on the same physical network must have the same network ID. The network ID must be unique to the internetwork.
•	The host ID (also known as a host address) identifies a workstation, server, router, or other TCP/IP host within a network. The host address must be unique to the network ID.

An IP address consists of 32 bits. Instead of expressing IPv4 addresses 32 bits at a time using binary notation (Base₂), it is standard practice to segment the 32 bits of an IPv4 address into four 8-bit fields called octets. Each octet is converted to a decimal number (base 10) from 0–255 and separated by a period (a dot). This format is called dotted decimal notation. The following table provides an example of an IP address in binary and dotted decimal formats.

An IP Address in Binary and Dotted Decimal Formats

Binary Format	Dotted Decimal Notation
11000000 10101000 00000011 00011000	192.168.3.24

For example, the IPv4 address of 11000000101010000000001100011000 is:

•	Segmented into 8-bit blocks: 11000000 10101000 00000011 00011000.
•	Each block is converted to decimal: 192 168 3 24
•	The adjacent octets are separated by a period: 192.168.3.24.

The notation w.x.y.z is used when referring to a generalized IP address, and is shown the following figure.

IP Address

The Internet standards define the following types of IPv4 addresses:

•	Unicast. Assigned to a single network interface located on a specific subnet on the network and used for one-to-one communications.
•	Multicast. Assigned to one or more network interfaces located on various subnets on the network and used for one-to-many communications.
•	Broadcast. Assigned to all network interfaces located on a subnet on the network and used for one-to-everyone-on-a-subnet communications.

The following sections describe these types of addresses in detail.

The IPv4 unicast address identifies an interface’s location on the network in the same way a street address identifies a house on a city block. Just as a street address must identify a unique residence, an IPv4 unicast address must be globally unique to the network and have a uniform format.

Each IPv4 unicast address includes a network ID and a host ID.

•

The network ID (also known as a network address) is the fixed portion of an IPv4 unicast address that identifies the set of interfaces that are located on the same physical or logical network segment as bounded by IPv4 routers. A network segment on TCP/IP networks is also known as a subnet. All systems on the same physical or logical subnet must use the same network ID and the network ID must be unique to the entire TCP/IP network.

•

The host ID (also known as a host address) is the variable portion of an IPv4 unicast address that is used to identify a network node’s interface on a subnet. The host ID must be unique to the network ID.

If the network ID is unique to the TCP/IP network and the host ID is unique to the network ID, then the entire IPv4 unicast address consisting of the network ID and host ID is unique to the entire TCP/IP network.

IPv4 multicast addresses are used for single-packet one-to-many delivery. On an IPv4 multicast-enabled intranet, an IPv4 packet addressed to an IPv4 multicast address is forwarded by routers to the subnets on which there are hosts listening to the traffic sent to the IPv4 multicast address. IPv4 multicast provides an efficient one-to-many delivery service for many types of communication.

IPv4 multicast addresses are defined by the class D Internet address class: 224.0.0.0/4. IPv4 multicast addresses range from 224.0.0.0 through 239.255.255.255. IPv4 multicast addresses for the 224.0.0.0/24 address prefix (224.0.0.0 through 224.0.0.255) are reserved for local subnet multicast traffic.

IPv4 uses a set of broadcast addresses to provide a one-to-everyone on the subnet delivery service. Packets sent to IPv4 broadcast addresses are processed by all the interfaces on the subnet. The following are the different types of IPv4 broadcast addresses:

•	Network broadcast. Formed by setting all the host bits to 1 for a classful address prefix. An example of a network broadcast address for the classful network ID 131.107.0.0/16 is 131.107.255.255. Network broadcasts are used to send packets to all interfaces of a classful network. IPv4 routers do not forward network broadcast packets.
•	Subnet broadcast. Formed by setting all the host bits to 1 for a classless address prefix. An example of a network broadcast address for the classless network ID 131.107.26.0/24 is 131.107.26.255. Subnet broadcasts are used to send packets to all hosts of a classless network. IPv4 routers do not forward subnet broadcast packets. For a classful address prefix, there is no subnet broadcast address, only a network broadcast address. For a classless address prefix, there is no network broadcast address, only a subnet broadcast address.
•	All-subnets-directed broadcast. Formed by setting all the original classful network ID host bits to 1 for a classless address prefix. A packet addressed to the all-subnets-directed broadcast was defined to reach all hosts on all of the subnets of a subnetted class-based network ID. An example of an all-subnets-directed broadcast address for the subnetted network ID 131.107.26.0/24 is 131.107.255.255. The all-subnets-directed broadcast is the network broadcast address of the original classful network ID. IPv4 routers can forward all-subnets directed broadcast packets, however the use of the all-subnets-directed broadcast address is deprecated in RFC 1812.
•	Limited broadcast. Formed by setting all 32 bits of the IPv4 address to 1 (255.255.255.255). The limited broadcast address is used for one-to-everyone delivery on the local subnet when the local network ID is unknown. IPv4 nodes typically only use the limited broadcast address during an automated configuration process such as Boot Protocol (BOOTP) or DHCP. For example, with DHCP, a DHCP client must use the limited broadcast address for all traffic sent until the DHCP server acknowledges the use of the offered IPv4 address configuration. IPv4 routers do not forward limited broadcast packets.

The Internet community originally defined address classes to accommodate different types of addresses and networks of varying sizes. The class of address defined which bits were used for the network ID and which bits were used for the host ID. It also defined the possible number of networks and the number of hosts per network. Of five address classes, class A, B, and C addresses were defined for IPv4 unicast addresses. Class D addresses were defined for IPv4 multicast addresses and class E addresses were defined for experimental uses.

Class A network IDs were assigned to networks with a very large number of hosts. The high-order bit in a class A address is always set to zero, which makes the address prefix for all class A networks and addresses 0.0.0.0/1 (or 0.0.0.0, 128.0.0.0). The next seven bits (completing the first octet) are used to enumerate class A network IDs. Therefore, address prefixes for class A network IDs have an 8-bit prefix length (/8 or 255.0.0.0). The remaining 24 bits (the last three octets) are used for the host ID. The address prefix 0.0.0.0/0 (or 0.0.0.0, 0.0.0.0) is a reserved network ID and 127.0.0.0/8 (or 127.0.0.0, 255.0.0.0) is reserved for loopback addresses. Out of a total of 128 possible class A networks, there are 126 networks and 16,777,214 hosts per network.

Note

•

All-Zeros and All-Ones Host IDs are Reserved

•

When enumerating host IDs for a given network ID, the two host IDs in which all the bits in the host ID are set to 0 (the all-zeros host ID) and all the bits in the host ID is set to 1 (the all-ones host ID) are reserved and cannot be assigned to network node interfaces. Hence, in the calculation above in which there are 24 bits for class A host IDs, the total number of possible host IDs is 16,777,216 (224). When you subtract the two reserved host IDs, the total number of usable host IDs is 16,777,214.

The following figure illustrates the structure of class A addresses.

Structure of class A addresses

Class B network IDs were assigned to medium to large-sized networks. The two high-order bits in a class B address are always set to 10, which makes the address prefix for all class B networks and addresses 128.0.0.0/2 (or 128.0.0.0, 192.0.0.0). The next 14 bits (completing the first two octets) are used to enumerate class B network IDs. Therefore, address prefixes for class B network IDs have a 16-bit prefix length (/16 or 255.255.0.0). The remaining 16 bits (last two octets) are used for the host ID. With 14 bits to express class B network IDs and 16 bits to express host IDs, this allows for 16,384 networks and 65,534 hosts per network.

The following figure illustrates the structure of class B addresses.

Structure of class B addresses

Class C addresses were assigned to small networks. The three high-order bits in a class C address are always set to 110, which makes the address prefix for all class C networks and addresses 192.0.0.0/3 (or 192.0.0.0, 224.0.0.0). The next 21 bits (completing the first three octets) are used to enumerate class C network IDs. Therefore, address prefixes for class C network IDs have a 24-bit prefix length (/24 or 255.255.255.0). The remaining 8 bits (the last octet) are used for the host ID. With 21 bits to express class C network IDs and 8 bits to express host IDs, this allows for 2,097,152 networks and 254 hosts per network.

The following figure illustrates the structure of class C addresses.

Structure of class C addresses

Class D addresses are reserved for IPv4 multicast addresses. The four high-order bits in a class D address are always set to 1110, which makes the address prefix for all class D addresses 224.0.0.0/4 (or 224.0.0.0, 240.0.0.0).

Class E addresses are reserved for experimental use. The high-order bits in a class E address are set to 1111, which makes the address prefix for all class E addresses 240.0.0.0/4 (or 240.0.0.0, 240.0.0.0)

The following table is a summary of the Internet address classes A, B, and C that can be used for IPv4 unicast addresses.

Internet Address Class Summary

Class	Value for w	Network ID Portion	Host ID Portion	Network IDs	Host IDs per Network
A	1-126	w	x.y.z	126	16,777,214
B	128-191	w.x	y.z	16,384	65,534
C	192-223	w.x.y	z	2,097,152	254

The Internet address classes are an obsolete unicast address allocation method that proved to be an inefficient way to assign network IDs and addresses to organizations connected to the Internet. For example, a large organization with a class A network ID can have up to 16,777,214 hosts. However, if the organization only uses 70,000 host IDs, then 16,707,214 potential IPv4 unicast addresses for the Internet are wasted.

On the modern-day Internet, IPv4 address prefixes are handed out to organization’s based on the organization’s actual need for Internet-accessible IPv4 unicast addresses using a method known as Classless Inter-Domain Routing (CIDR). For example, an organization determines that it needs 2,000 Internet-accessible IPv4 unicast addresses. The Internet Corporation for Assigned Names and Numbers (ICANN) or an Internet service provider (ISP) allocates an IPv4 address prefix in which 21 bits are fixed, leaving 11 bits for host IDs. From the 11 bits for host IDs, the organization can create 2,032 possible IPv4 unicast addresses.

CIDR-based address allocations typically start at 8 bits. The following table lists the required number of host IDs and the corresponding prefix length for CIDR-based address allocations.

Host IDs Needed and CIDR-based Prefix Lengths

Number of Host IDs	Prefix Length	Dotted Decimal
2–254	/24	255.255.255.0
255–510	/23	255.255.254.0
511–1,022	/22	255.255.252.0
1,021–2,046	/21	255.255.248.0
2,047–4,094	/20	255.255.240.0
4,095–8,190	/19	255.255.224.0
8,191–16,382	/18	255.255.192.0
16,383–32,766	/17	255.255.128.0
32,767–65,534	/16	255.255.0.0

If you want direct (routed) connectivity to the Internet, then you must use public addresses. If you want indirect (proxied or translated) connectivity to the Internet, you can use either public or private addresses. If your intranet is not connected to the Internet in any way, you can use any unicast IPv4 addresses that you want. However, you should use private addresses to avoid network renumbering when your intranet is eventually connected to the Internet.

Public addresses are assigned by ICANN and consist of either historically allocated class-based network IDs or, more recently, CIDR-based address prefixes that are guaranteed to be globally unique on the Internet. For CIDR-based address prefixes, the value of w (the first octet) is in the ranges of 1 through 126 and 128 through 223, with the exception of the private address prefixes described in “Private Addresses.”

When the public addresses are assigned, routes are added to the routers of the Internet so that traffic sent to an address that matches the assigned public address prefix can reach the assigned organization. For example, when an organization is assigned an address prefix in the form of a network ID and prefix length, that address prefix also exists as a route in the routers of the Internet. IPv4 packets destined to an address within the assigned address prefix are routed to the proper destination.

Each IPv4 interface requires an IPv4 address that is globally unique to the IPv4 network. In the case of the Internet, each IPv4 interface on a subnet connected to the Internet requires an IPv4 address that is globally unique to the Internet. As the Internet grew, organizations connecting to the Internet required a public address for each interface on their intranets. This requirement placed a huge demand on the pool of available public addresses.

When analyzing the addressing needs of organizations, the designers of the Internet noted that for many organizations, most of the hosts on an organization’s intranet did not require direct connectivity to the Internet. Those hosts that did require a specific set of Internet services, such as Web access and e-mail, typically access the Internet services through Application layer gateways such as proxy servers and e-mail servers. The result is that most organizations only required a small amount of public addresses for those nodes (such as proxies, servers, routers, firewalls, and translators) that were directly connected to the Internet.

For the hosts within the organization that do not require direct access to the Internet, IPv4 addresses that do not duplicate already-assigned public addresses are required. To solve this addressing problem, the Internet designers reserved a portion of the IPv4 address space and named this space the private address space. An IPv4 address in the private address space is never assigned as a public address. IPv4 addresses within the private address space are known as private addresses. Because the public and private address spaces do not overlap, private addresses never duplicate public addresses.

The private address space specified in RFC 1918 is defined by the following address prefixes:

•	10.0.0.0/8 (10.0.0.0, 255.0.0.0) Allows the following range of valid IPv4 unicast addresses: 10.0.0.1 to 10.255.255.254. The 10.0.0.0/8 address prefix has 24 host bits that can be used for any addressing scheme within the private organization.
•	172.16.0.0/12 (172.16.0.0, 255.240.0.0) Allows the following range of valid IPv4 unicast addresses: 172.16.0.1 to 172.31.255.254. The 172.16.0.0/12 address prefix has 20 host bits that can be used for any addressing scheme within the private organization.
•	192.168.0.0/16 (192.168.0.0, 255.255.0.0) Allows the following range of valid IPv4 unicast addresses: 192.168.0.1 to 192.168.255.254. The 192.168.0.0/16 address prefix has 16 host bits that can be used for any addressing scheme within the private organization.

Because the IPv4 addresses in the private address space will never be assigned by ICANN to an organization connected to the Internet, there will never be routes for the private address prefixes in Internet routers. You cannot connect to a private address over the Internet. Therefore, a host that has a private address must send its Internet traffic requests to an Application layer gateway (such as a proxy server) that has a valid public address or through a network address translator (NAT) that translates the private address into a valid public address.

Private organization intranets that do not need an Internet connection can choose any address scheme they want, even using public address prefixes that have been assigned by ICANN. If that organization later decides to connect to the Internet, its current address scheme might include addresses already assigned by ICANN to other organizations. These addresses conflict with existing public addresses assigned by ICANN and are known as illegal addresses. Connectivity from illegal addresses to Internet locations is not possible because the routers of the Internet send traffic destined to ICANN-allocated address prefixes to the assigned organizations, not to the organizations using illegal addresses.

For example, a private organization chooses to use the 206.73.118.0/24 address prefix for its intranet. The public address prefix 206.73.118.0/24 has been assigned by ICANN to the Microsoft Corporation and routes exist on the Internet routers to send all packets for IPv4 addresses on 206.73.118.0/24 to Microsoft routers. As long as the private organization does not connect to the Internet, there is no problem because the two address prefixes are on separate IPv4 networks; therefore they are unique to each separate network. If the private organization later connects directly to the Internet and continues to use the 206.73.118.0/24 address prefix, any Internet response traffic to locations matching the 206.73.118.0/24 address prefix is sent to Microsoft routers, not to the routers of the private organization.

An interface on a computer running Windows Server 2003 and Windows XP that is configured to obtain an IPv4 address configuration automatically that does not successfully contact a Dynamic Host Configuration Protocol (DHCP) server uses its alternate configuration, as specified on the Alternate Configuration tab.

If the Automatic Private IP Address option is selected on the Alternate Configuration tab and a DHCP server cannot be found, Windows TCP/IP uses Automatic Private IP Addressing (APIPA). Windows TCP/IP randomly selects an IPv4 address from the 169.254.0.0/16 address prefix and assigns the subnet mask of 255.255.0.0. This address prefix has been reserved by the ICANN and is not reachable on the Internet. APIPA allows single-subnet Small Office/Home Office (SOHO) networks to use TCP/IP without static configuration or the administration of a DHCP server. APIPA does not configure a default gateway. Therefore, only local subnet traffic is possible.

The following are special IPv4 addresses:

•	0.0.0.0 Known as the unspecified IPv4 address, it is used to indicate the absence of an address. The unspecified address is used only as a source address when the IPv4 node is not configured with an IPv4 address configuration and is attempting to obtain an address through a configuration protocol such as Dynamic Host Configuration Protocol (DHCP).
•	127.0.0.1 Known as the IPv4 loopback address, it is assigned to an internal loopback interface, enabling a node to send packets to itself.

When assigning network IDs to the subnets of an organization, use the following guidelines:

•

The network ID must be unique on the IPv4 network. If the network ID is for a subnet on which there are hosts that are directly accessible from the Internet, you must use a public IPv4 address prefix assigned by ICANN or an Internet service provider. If the network ID is for a subnet that is not directly accessible by the Internet, use either a legal public address prefix or a private address prefix that is unique on your private intranet.

•

The network ID cannot begin with the numbers 0 or 127. Both of these values for the first octet are reserved and cannot be used for IPv4 unicast addresses.

When assigning host IDs to the interfaces of nodes on an IPv4 subnet, use the following guidelines:

•	The host ID must be unique on the subnet.
•	You cannot use the all-zeros or all-ones host IDs.

When defining the range of valid IPv4 unicast addresses for a given address prefix, use the following standard practice:

•	For the first IPv4 unicast address in the range, set all the host bits in the address to 0, except for the low-order bit, which is set to 1.
•	For the last IPv4 unicast address in the range, set all the host bits in the address to 1, except for the low-order bit, which is set to 0.

For example, to express the range of addresses for the address prefix 192.168.16.0/20:

•	The first IPv4 unicast address in the range is 11000000 10101000 0001000000000001 (host bits are bold), or 192.168.16.1.
•	The last IPv4 unicast address in the range is 11000000 10101000 0001111111111110 (host bits are bold), or 192.168.31.254.

While IP is designed to work with the 32-bit IP addresses of the source and the destination hosts, computers users are much better at using and remembering names than IP addresses.

When a name is used as an alias for an IP address, a mechanism must exist for assigning that name to the appropriate IP node — to ensure its uniqueness and resolution to its IP address.

In this section, the mechanisms used for assigning and resolving host names (which are used by Windows Sockets applications), and NetBIOS names (which are used by NetBIOS applications) are discussed.

A host name is an alias assigned to an IP node to identify it as a TCP/IP host. The host name can be up to 255 characters long and can contain alphabetic and numeric characters and the “-” and “.” characters“.” Multiple host names can be assigned to the same host. For Windows Server 2003–based computers, the host name does not have to match the Windows Server 2003 computer name.

Windows Sockets applications, such as Microsoft Internet Explorer, can use one of two values to connect to the destination: the IP address or a host name. When the IP address is specified, name resolution is not needed. When a host name is specified, the host name must be resolved to an IP address before IP-based communication with the desired resource can begin.

Host names most commonly take the form of a domain name with a structure that follows Internet conventions. Name resolution, and domain names work the same whether they are used for IPv4 or IPv6 addresses.

To meet the need for a scaleable, customizable naming scheme for a wide variety of organizations, InterNIC has created and maintains a hierarchical namespace called the Domain Name System (DNS). The DNS naming scheme looks like the directory structure for files on a disk. Usually, you trace a file path from the root directory through subdirectories to its final location and its file name. However, a host name is traced from its final location back through its parent domains up to the root. The unique name of the host, representing its position in the hierarchy, is its Fully Qualified Domain Name (FQDN). The top-level domain namespace with second-level and subdomains is shown in the following figure.

Domain Name System

The domain namespace includes the following categories:

•	The root domain, which is indicated by “” (null), represents the root of the namespace.
•	Top-level domains, directly below the root, represent types of organizations. InterNIC is responsible for the maintenance of top-level domain names on the Internet. The following table has a partial list of the Internet’s top-level domain names.

Internet Top-Level Domain Names

Domain Name	Meaning
com	Commercial organization
edu	Educational institution
gov	Government institution
mil	Military group
net	Major network support center
org	Organization other than those above
int	International organization
<country/region code>	Each country/region (geographic scheme)

•	Second-level domains, below the top-level domains, represent specific organizations within the top-level domains. InterNIC is responsible for maintaining and ensuring uniqueness of second-level domain names on the Internet.
•	Subdomains are below the second-level domain. Individual organizations are responsible for the creation and maintenance of subdomains.

For example, for the FQDN websrv.wcoast.reskit.com:

•	The trailing period (.) denotes that this is an FQDN with the name relative to the root of the domain namespace. The trailing period is usually not required for FQDNs and if it is missing it is assumed to be present.
•	com is the top-level domain, indicating a commercial organization.
•	reskit is the second-level domain, indicating the Resource Kit Corporation.
•	wcoast is a subdomain of reskit.com indicating the West Coast division of the Resource Kit Corporation.
•	websrv is the name of the Web server in the West Coast division.

Domain names are not case-sensitive.

Organizations not connected to the Internet can implement whatever top and second-level domain names they want. However, typical implementations follow InterNIC specifications so that eventual participation in the Internet will not require a renaming process.

One common way to resolve a host name to an IP address is to use a locally stored database file that contains IP-address-to-host-name mappings. On most UNIX systems, this file is /etc/hosts. On Windows Server 2003 systems, it is the Hosts file in the %systemroot%\System32\Drivers\Etc directory.

The following is an example of the contents of the Hosts file:

#
Table of IP addresses and host names
#
127.0.0.1    localhost
131.107.34.1    router
172.30.45.121    server1.central.reskit.com s1

Within the Hosts file:

•	Multiple host names can be assigned to the same IP address. Note that the server at the IP address 172.30.45.121 can be referred to by its FQDN (server1.central.reskit.com) or a nickname (s1). This allows the user at this computer to refer to this server using the nickname s1 instead of typing the entire FQDN.
•	Entries can be case sensitive depending on the platform. Entries in the Hosts file for UNIX computers are case-sensitive. Entries in the Hosts file for Windows Server 2003, Windows XP, and Windows 2000–based computers are not case sensitive.

For computers running Windows Server 2003, Windows XP, and Windows 2000, the entries in the Hosts file are loaded into the DNS client resolver cache. When resolving host names, the DNS client resolver cache is always checked.

The advantage of using a Hosts file is that it is customizable for the user. Users can create whatever entries they want, including easy-to-remember nicknames for frequently accessed resources. However, the individual maintenance of the Hosts file does not scale well to storing large numbers of FQDN mappings.

To make host name resolution scalable and centrally manageable, IP address mappings for FQDNs are stored on DNS servers. To enable the querying of a DNS server by a host computer, a component called the DNS resolver is enabled and configured with the IP address of the DNS server. The DNS resolver is a built-in component of TCP/IP protocol stacks supplied with most network operating systems, including Windows Server 2003.

When a Windows Sockets application is given an FQDN as the destination location, the application calls a Windows Sockets function to resolve the name to an IP address. The request is passed to the DNS resolver component in the TCP/IP protocol. The DNS resolver packages the FQDN request as a DNS Name Query packet and sends it to the DNS server.

DNS is a distributed naming system. Instead of storing all the records for the entire namespace on each DNS server, each DNS server stores only the records for a specific portion of the namespace. The DNS server is authoritative for the portion of the namespace that corresponds to records stored on that DNS server. In the case of the Internet, hundreds of DNS servers store various portions of the Internet namespace. To facilitate the resolution of any valid domain name by any DNS server, DNS servers are also configured with pointer records to other DNS servers.

The following process outlines what happens when the DNS resolver component on a host sends a DNS query to a DNS server. This process is shown in the following figure and is simplified so that you can gain a basic understanding of the DNS resolution process.

1.	The DNS resolver component of the DNS client formats a DNS Name Query Request message containing the FQDN and sends it to the configured DNS server.
2.	The DNS server checks the FQDN in the DNS Name Query Request message against locally stored address records. If a record is found, the IP address corresponding to the requested FQDN is sent back to the client.
3.	If the FQDN is not found, the DNS server forwards the request to a DNS server that is authoritative for the FQDN.
4.	The authoritative DNS server returns the reply, which contains the resolved IP address, back to the original DNS server.
5.	The original DNS server sends the IP address mapping information to the client.

Resolving an FQDN by using DNS servers

To obtain the IP address of a server that is authoritative for the FQDN, DNS servers on the Internet go through an iterative process of querying multiple DNS servers until the authoritative server is found. For more information about DNS name-resolution processes, see the DNS Technical Reference.

TCP/IP implementations, including Windows Server 2003, allow the use of both a local database file and a DNS server to resolve host names. When a user specifies a host name in a Windows Sockets–based TCP/IP application:

•

TCP/IP checks the DNS client resolver cache (loaded with entries from the Hosts file and other previously resolved host names) for a matching name. If a matching name is not found in the local database file, the host name is packaged as a DNS Name Query Request message and sent to the configured DNS server.

Combining methods allows the user to have a local database file for resolving personalized nicknames and to use the globally distributed DNS database to resolve FQDNs.

NetBIOS name resolution is the process of successfully mapping a NetBIOS name to an IP address. A NetBIOS name is a 16-byte address used to identify a NetBIOS resource on the network. A NetBIOS name is either a unique (exclusive) or group (nonexclusive) name. When a NetBIOS process communicates with a specific process on a specific computer, a unique name is used. When a NetBIOS process communicates with multiple processes on multiple computers, a group name is used.

The NetBIOS name acts as a Session layer application identifier. For example, the NetBIOS session service operates over TCP port 139. All NetBT session requests are addressed to TCP destination port 139. When identifying a NetBIOS application with which to establish a NetBIOS session, the NetBIOS name is used.

An example of a process using a NetBIOS name is the File and Printer Sharing for Microsoft Networks component (the Server service) on a Windows Server 2003–based computer. When you start your computer, the Server service registers a unique NetBIOS name based on your computer’s name. The exact name used by the Server service is the 15-character computer name plus a sixteenth character of 0×20. If the computer name is not 15 characters long, it is padded with spaces up to 15 characters long. Other network services, such as the Workstation or Messenger service, also use the computer name to build their NetBIOS names. The sixteenth character is used to uniquely identify each service.

Note

•	The Messenger service refered to here is not Windows Messenger. Windows Messenger is a Microsoft application included in Windows Server 2003 that allows real-time messaging and collaboration.

The Server service on the file server you specify corresponds to a specific NetBIOS name. For example, when you attempt to connect to the computer called CORPSERVER, the NetBIOS name corresponding to the Server service is “CORPSERVER <20>” (note the padding using the space character). Before a file and print sharing connection can be established, a TCP connection must be created. In order for a TCP connection to be established, the NetBIOS name “CORPSERVER <20>” must be resolved to an IP address.

To view the NetBIOS names registered by NetBIOS processes running on a Windows Server 2003 computer, type nbtstat -n at the Windows Server 2003 command prompt.

The exact mechanism by which NetBIOS names are resolved to IP addresses depends on the node’s configured NetBIOS Node Type. RFC 1001 defines the NetBIOS Node Types listed in the following table.

NetBIOS Node Types

Node Type	Description
B-node (broadcast)	B-node uses broadcasted NetBIOS name queries for name registration and resolution. B-node has two major problems: (1) In a large internetwork, broadcasts can increase the network load, and (2) Routers typically do not forward broadcasts, so only NetBIOS names on the local network can be resolved.
P-node (peer-peer)	P-node uses a NetBIOS name server (NBNS), such as Windows Internet Name Service (WINS), to resolve NetBIOS names. P-node does not use broadcasts; instead, it queries the name server directly. The most significant problem with P-node is that all computers must be configured with the IP address of the NBNS, and if the NBNS is down, computers are not able to communicate even on the local network.
M-node (mixed)	M-node is a combination of B-node and P-node. By default, an M-node functions as a B-node. If it is unable to resolve a name by broadcast, it uses the NBNS of P-node.
H-node (hybrid)	H-node is a combination of P-node and B-node. By default, an H-node functions as a P-node. If it is unable to resolve a name through the NetBIOS name server, it uses a broadcast to resolve the name.

When NetBT is enabled, Windows Server 2003–based computers are B-node by default and become H-node when configured for a WINS server. Windows Server 2003 also uses a local database file called Lmhosts to resolve remote NetBIOS names.

After the host name or NetBIOS name is resolved to an IP address, the IP packet must be sent by the sending host to the resolved IP address. Routing is the process of forwarding a packet based on the destination IP address. Routing involves both the TCP/IP host and an IP router. A router is a device that forwards the packets from one network to another. Routers are also commonly referred to as gateways. Both the sending host and router need to make a determination about how the packet is forwarded.

To make these determinations, the IP layer consults a routing table stored in memory. Routing table entries are created by default when TCP/IP initializes and additional entries are added either manually by a system administrator or automatically through communication with routers.

IP packets use at least one of two types of delivery based on whether the final destination is located on a directly attached network. These two types of delivery are known as direct and indirect delivery.

•	Direct delivery occurs when the IP node (either the sending node or an IP router) forwards a packet to the final destination on a directly attached network. The IP node encapsulates the IP packet in a frame format for the Network Interface layer (such as Ethernet or Token Ring) addressed to the destination’s MAC address.
•	Indirect delivery occurs when the IP node (either the sending node or an IP router) forwards a packet to an intermediate node (an IP router) because the final destination is not on a directly attached network. The IP node encapsulates the IP packet in a frame format for the Network Interface layer (such as Ethernet or Token Ring) addressed to the IP router’s MAC address.

IP routing is a combination of direct and indirect deliveries.

In the following figure, when sending packets to node B, node A performs a direct delivery. When sending packets to node C, node A performs an indirect delivery to Router 1, and Router 1 performs an indirect delivery to Router 2, and then Router 2 performs a direct delivery to node C.

Direct and Indirect Deliveries

A routing table is present on all IP nodes. The routing table stores information about IP networks and how they can be reached (either directly or indirectly). Because all IP nodes perform some form of IP routing, routing tables are not exclusive to IP routers. Any node loading the TCP/IP protocol has a routing table. There are a series of default entries according to the configuration of the node and additional entries can be entered either manually through TCP/IP utilities or dynamically through interaction with routers.

When an IP packet is to be forwarded, the routing table is used to determine:

•	The next-hop IP address. For a direct delivery, the next-hop IP address is the destination IP address in the IP packet. For an indirect delivery, the next-hop IP address is the IP address of a router.
•	The next-hop interface. The next-hop interface identifies the physical or logical interface, such as a network adapter, that is used to forward the packet to either its destination or the next router.

Entries in the IP routing table contain the following information:

•	Network ID. The network ID or destination corresponding to the route. The network ID can identify a specific subnet, be a summarized route, or an IP address for a host route. In the Windows Server 2003 IP routing table, this is the Network Destination column.
•	Network mask. The mask that is used to match a destination IP address to the network ID. In the Windows Server 2003 IP routing table, this is the Netmask column.
•	Next hop. The IP address of the next hop. In the Windows Server 2003 IP routing table, this is the Gateway column.
•	Interface. An indication of which network interface is used to forward the IP packet.
•	Metric. A number used to indicate the cost of the route so the best route among possible multiple routes to the same destination can be selected. A common use of the metric is to indicate the number of hops (routers crossed) to the network ID.

Entries in the routing table can be used to store the following types of routes:

•	Directly attached network ID. Aroute for network IDs that are directly attached. For directly attached networks, the Next Hop field can be blank or contain the IP address of the interface on that network.
•	Remote network ID. A route for network IDs that are not directly attached but are available across other routers. For remote networks, the Next Hop field is the IP address of a local router.
•	Host route. A route to a specific IP address. Host routes allow routing to occur on a per-IP address basis. For host routes, the network ID is the IP address of the specified host and the network mask is 255.255.255.255.
•	Default route. The default route is designed to be used when a more specific network ID or host route is not found. The default route network ID is 0.0.0.0 with a network mask of 0.0.0.0.

To determine which routing table entry is used to find the next-hop address and interface, IP uses the following process:

•

For each entry in a routing table, IP performs a bit-wise logical AND operation between the destination IP address and the network mask. It compares the result with the network ID of the entry for a match.

•

A list of matching routes is compiled. The route that has the longest match (the route with the largest number of bits that match the destination IP address) is chosen. The longest matching route is the most direct route to the destination IP address. If multiple matching entries are found (for example, multiple routes to the same network ID), the router uses the lowest metric to select the best route. If multiple entries have the longest match and the lowest metric, the router designates one of them as the routing table entry. For Windows Server 2003 TCP/IP, the route chosen corresponds to the route associated with the interface that is first in the network binding order.

The end result of the route-determination process is a single route in the routing table that yields a next-hop IP address and interface. If the route-determination process fails to find a route, IP indicates a routing error. For the sending host, an IP routing error message is sent to the upper layer protocol, such as TCP or UDP. For a router, an ICMP Destination Unreachable–Host Unreachable message is sent to the sending host.

The following table shows the default routing table for a Windows Server 2003–based host (not a router). The host has a single network adapter and has the IP address 157.60.27.90, subnet mask 255.255.240.0, and a default gateway of 157.60.16.1.

Windows Server 2003 Routing Table

Network Destination	Netmask	Gateway	Interface	Metric	Purpose
0.0.0.0	0.0.0.0	157.60.16.1	157.60.27.90	1	Default Route
127.0.0.0	255.0.0.0	127.0.0.1	127.0.0.1	1	Loopback Network
157.60.16.0	255.255.240.0	157.60.27.90	157.60.27.90	1	Directly Attached Network
157.60.27.90	255.255.255.255	127.0.0.1	127.0.0.1	1	Local Host
157.60.255.255	255.255.255.255	157.60.27.90	157.60.27.90	1	Network Broadcast
224.0.0.0	240.0.0.0	157.60.27.90	157.60.27.90	1	Multicast
255.255.255.255	255.255.255.255	157.60.27.90	157.60.27.90	1	Limited Broadcast

The entry corresponding to the default gateway configuration is a network destination of 0.0.0.0 with a network mask (netmask) of 0.0.0.0. Any destination IP address that is logically ANDed with 0.0.0.0 results in 0.0.0.0. Therefore, for any IP address, the default route produces a match. If the default route is chosen because no better routes were found, the IP packet is forwarded to the IP address in the Gateway column (the default gateway of 157.60.16.1), by using the interface assigned the IP address in the Interface column.

The loopback network entry is designed to take any IP address of the form 127.x.y.z and forward it to the special loopback address of 127.0.0.1.

The local network entry corresponds to the directly attached network. IP packets destined for the directly attached network are not forwarded to a router but sent directly to the destination. Note that the Gateway and Interface columns match the IP address of the node. This indicates that the packet is sent from the network adapter corresponding to the node’s IP address.

The local host entry is a host route (network mask of 255.255.255.255) corresponding to the IP address of the host. All IP packets sent to the IP address of the host are forwarded to the loopback address.

The network broadcast entry is a host route (network mask of 255.255.255.255) corresponding to the all-subnets directed broadcast address (all subnets of class B network ID 157.60.0.0). Packets addressed to the all-subnets directed broadcast are sent from the network adapter corresponding to the node’s IP address.

The multicast addresses route is used to send any multicast IP packets from the network adapter corresponding to the node’s IP address.

The limited broadcast address is a host route (network mask of 255.255.255.255). Packets addressed to the limited broadcast are sent from the network adapter corresponding to the node’s IP address.

To view the IP routing table on a Windows Server 2003-based computer, type route print at a Windows Server 2003 command prompt.

When determining the next-hop IP address and interface from a route in the routing table:

•	If the gateway address is the same as the interface address, the next-hop IP address is set to the destination IP address of the IP packet.
•	If the gateway address is not the same as the interface address, the next-hop IP address is set to the gateway address.

For example, when traffic is sent to 157.60.16.48, the most specific matching route is the route for the directly attached network (157.60.16.0/20). The next-hop IP address is set to the destination IP address (157.60.16.48) and the interface is the network adapter that has been assigned the IP address 157.60.27.90.

When sending traffic to 192.168.0.79, the most specific matching route is the default route (0.0.0.0/0). The next-hop IP address is set to the gateway address (157.60.16.1) and the interface is the network adapter that has been assigned the IP address 157.60.27.90.

For IP routing to occur efficiently between routers in the IP internetwork, routers must be configured with remote network IDs or a default route. On large IP internetworks, one of the challenges faced by network administrators is how to maintain the routing tables on their IP routers so that IP traffic flow is traveling the best path and is fault tolerant.

There are two methods of maintaining routing table entries on IP routers.

Static IP routers have routing tables that do not change unless manually changed by a network administrator.

Static routing relies on the manual administration of the routing table. Remote network IDs are not discovered by static routers and must be manually configured. Static routers are not fault-tolerant. If a static router goes down, neighboring routers do not sense the fault and inform other routers.

Dynamic IP routers have routing tables that change automatically based on the exchange of routing information with other routers.

Dynamic routing employs the use of routing protocols, such as Routing Information Protocol (RIP) and Open Shortest Path First (OSPF), to dynamically update the routing table through the exchange of routing information between routers. Remote network IDs are discovered by dynamic routers and automatically entered into the routing table. Dynamic routers are fault-tolerant. If a dynamic router goes down, the fault is detected by neighboring routers, which send the changed routing information to the other routers in the internetwork.

Based on the destination IP address and the route determination process, IP determines the next-hop IP address and interface. IP then sends the IP packet, the next-hop IP address, and the interface to ARP.

If the next-hop IP address is the same as the destination IP address, then ARP performs a direct delivery. In a direct delivery, the MAC address corresponding to the destination IP address must be resolved.

If the next-hop IP address is not the same as the destination IP address, then ARP performs an indirect delivery. The next-hop IP address is the IP address of a router between the current IP node and the final destination. In an indirect delivery, the MAC address corresponding to the IP address of the router must be resolved.

To resolve a next-hop IP address to its MAC address, ARP uses broadcast traffic on shared access networking media (such as Ethernet or Token Ring) to send out a broadcasted ARP Request frame. An ARP Reply, containing the MAC address corresponding to the requested next-hop IP address, is sent back to the sender of the ARP Request.

To keep the number of broadcasted ARP Request frames to a minimum, many TCP/IP protocol stacks incorporate an ARP cache, which is a table of recently resolved IP addresses and their corresponding MAC addresses. TCP/IP checks the ARP cache before sending an ARP Request frame. Each interface has its own ARP cache.

Depending on the vendor implementation, the ARP cache can have the following qualities:

•

ARP cache entries can be dynamic (based on ARP Replies) or static. Static ARP entries are permanent and are manually added by using a TCP/IP utility such as the ARP tool provided with Windows Server 2003. Static ARP cache entries are used to prevent ARP Requests for commonly used local IP addresses, such as routers and servers. The problem with static ARP entries is that they have to be manually updated when network interface equipment changes.

•

Dynamic ARP cache entries have a time-out value associated with them to remove entries in the cache after a specified period of time. Dynamic ARP cache entries for Windows Server 2003 TCP/IP are given a maximum time of 10 minutes before being removed.

To view the ARP cache on a Windows Server 2003–based computer, type arp -a at a Windows Server 2003 command prompt.

IP sends ARP the IP packet, the next-hop IP address, and the next-hop interface. Whether performing a direct or indirect delivery, ARP carries out the following process, as shown in the following figure.

ARP process

1.	Based on the next-hop address and interface, ARP consults the appropriate ARP cache for an entry for the next-hop IP address. If an entry is found, ARP skips to step 6.
2.	If an entry is not found, ARP builds an ARP Request frame containing the MAC address of the interface sending the ARP Request, the IP address of the interface sending the ARP Request, and the next-hop IP address. ARP then broadcasts the ARP Request using the appropriate interface.
3.	All hosts receive the broadcasted frame and the ARP Request is processed. If the receiving host’s IP address matches the requested IP address (the next-hop IP address), its ARP cache is updated with the address mapping of the sender of the ARP Request.
4.	If the receiving host’s IP address does not match the requested IP address, the ARP Request is silently discarded.
5.	The receiving host formulates an ARP Reply containing the requested MAC address and sends it directly to the sender of the ARP Request.
6.	When the ARP Reply is received by the sender of the ARP Request, it updates its ARP cache with the address mapping.
7.	The ARP Request host and the ARP Reply host have each other’s address mappings in their ARP caches.
8.	ARP sends the IP packet to the next-hop node by addressing it to the resolved MAC address.

The IP routing processes for all nodes involved in the delivery of an IP packet include the sending host, the intermediate routers, and the destination host.

When a host sends a packet, the packet is transmitted from an upper layer protocol (TCP, UDP, or ICMP) to IP, and then IP on the sending host does the following:

1.	Sets the Time-to-Live (TTL) value to either a default or application-specified value.
2.	Checks its routing table for the best route to the destination IP address. If no route is found, IP sends a routing error message to the upper layer protocol (TCP, UDP, or ICMP).
3.	Determines the next-hop IP address and the interface, based on the most specific matching route.
4.	Sends the packet, the next-hop IP address, and the next-hop interface to Address Resolution Protocol (ARP), and then ARP resolves the next-hop IP address to its media access control (MAC) address and forwards the packet.

When a packet is received at a router, the packet is passed to IP, and IP on the router does the following:

1.	Verifies the IP header checksum. If the IP header checksum fails, the IP packet is discarded without notification to the user. This is known as a silent discard.
2.	Verifies whether the destination IP address in the IP packet corresponds to an IP address assigned to a router interface. If so, the router processes the IP packet as the destination host (see step 3 in the following “IP on the Destination Host” section).
3.	If the destination IP address is not the router, IP decrements the Time-to-Live (TTL). If the TTL is 0, the router discards the packet and sends an ICMP Time Expired–TTL Expired in Transit message to the sender.
4.	If the TTL is 1 or greater, IP updates the TTL field and calculates a new IP header checksum.
5.	IP checks its routing table for the best route to the destination IP address in the IP packet. If no route is found, the router discards the packet and sends an ICMP Destination Unreachable–Host Unreachable message to the sender.
6.	Based on the best route found, IP determines the next-hop IP address and interface.
7.	IP sends the packet, the next-hop IP address, and the interface to ARP, and then ARP forwards the packet to the appropriate MAC address.

This entire process is repeated at each router in the path between the source and destination host.

When a packet is received at the destination host, it is passed up to IP, and IP on the destination host does the following:

1.	Verifies the IP header checksum. If the IP header checksum fails, the IP packet is silently discarded.
2.	Verifies that the destination IP address in the IP packet corresponds to an IP address assigned to the host. If the destination IP address is not assigned to the host, the IP packet is silently discarded.
3.	Passes the IP packet without the IP header to the appropriate upper-level protocol, based on the IP protocol field. If the protocol does not exist, ICMP sends a Destination Unreachable–Protocol Unreachable message back to the sender.
4.	For TCP and UDP packets, IP checks the destination port and processes the TCP segment or UDP header. If no application exists for the UDP port number, ICMP sends a Destination Unreachable–Port Unreachable message back to the sender. If no application exists for the TCP port number, TCP sends a Connection Reset segment back to the sender.

•	For more information about RFCs, see the IETF RFC Database.