How TCP-IP Works
How TCP-IP Works
In this section
Name Resolution
IPv4 Routing
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.
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 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.
Network Interface Layer
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.
Internet 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.
Transport Layer
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.
Application 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.
IP
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.
IP Header
Field Function
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 Designates the number of network segments on which the datagram is allowed to
(TTL) 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.
Fragmentation and reassembly
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.
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.
ARP
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.
ICMP
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.
Echo Request Troubleshooting message used to check IP connectivity to a desired host. The
ping utility sends ICMP Echo Request messages.
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 Sent by a router or the destination host to inform the sending host that the
Unreachable datagram cannot be delivered.
The following table describes the most common ICMP Destination Unreachable ICMP 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 Sent by an IP router when fragmentation must occur but is not allowed
and DF Set 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.
IGMP
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.
Host group membership is dynamic, hosts can join and leave the group at any time.
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
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.
Field Function
Sequence Number Sequence number of the first byte of data in the TCP segment.
Acknowledgment Sequence number of the byte the sender expects to receive next from the
Number 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.
TCP ports
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.
23 Telnet
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
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.
Field Function
UDP Checksum Verifies the bit-level integrity of the UDP header and the UDP data.
UDP ports
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.
161 SNMP
TCP/IP Application Interfaces
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.
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 Interface
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.
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.
NetBIOS datagrams
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.
NetBIOS sessions
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.
IPv4 Addressing
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.
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.
IPv4 Address Syntax
An IP address consists of 32 bits. Instead of expressing IPv4 addresses 32 bits at a time using binary notation
(Base2), 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.
IP Address
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.
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.
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.
Internet Address Classes
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
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
Class B
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.
Class D
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
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.
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.
Public addresses
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.
Private addresses
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:
Illegal addresses
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.
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.
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.
Unicast IPv4 Addressing Guidelines
When assigning network IDs to the subnets of an organization, use the following guidelines:
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.
Name Resolution
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.
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.
Domain Names
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.
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
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.
Copy Code
#
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.
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 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
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 0x20. 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.
B-node B-node uses broadcasted NetBIOS name queries for name registration and
(broadcast) 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 P-node uses a NetBIOS name server (NBNS), such as Windows Internet Name
(peer-peer) 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.
IPv4 Routing
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.
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.
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.
IP Routing Table Entry Types
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.
Route Determination Process
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.
Network
Destination Netmask Gateway Interface Metric Purpose
Loopback Network
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.
Local Host
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.
Network Broadcast
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.
Multicast
The multicast addresses route is used to send any multicast IP packets from the network adapter
corresponding to the node’s IP address.
Limited Broadcast
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.
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.
Manual
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.
Automatic
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.
ARP Cache
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.
ARP Process
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.
End-to-End Delivery
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.