Core Protocol Stack Components and the TDI Interface

The core protocol stack components are those shown between the NDIS and TDI interfaces in Figure 1. They are implemented in the Windows Server 2003 Tcpip.sys driver. The TCP/IP stack is accessible through the TDI interface and the NDIS interface. The Winsock2 interface also provides some support for direct access to the protocol stack.
Address Resolution Protocol (ARP)
ARP performs IP address-to-MAC address resolution for outgoing packets. As each outgoing IP datagram is encapsulated in a frame, source and destination MAC addresses must be added. Determining the destination MAC address for each frame is the responsibility of ARP.
ARP compares the next-hop IP address on every outbound IP datagram to the ARP cache for the NIC over which the frame will be sent. If there is a matching entry, the MAC address is retrieved from the cache. If not, ARP broadcasts an ARP Request frame on the local subnet, requesting that the owner of the IP address in question reply with its MAC address. If the packet is going through a router, the next-hop address is that of a neighboring router and ARP resolves the MAC address for that next-hop router, rather than the final destination host. When an ARP reply is received, the ARP cache is updated with the new information, and it is used to address the packet at the link layer.
ARP Cache
You can use the ARP utility to view, add, or delete entries in the ARP cache. Examples are shown below. Entries added manually are static and are not automatically removed from the cache, whereas dynamic entries are removed from the cache (see the “ARP Cache Aging” section for more information).
The arp command can be used to view the ARP cache, as shown here:
C:\>arp -a
Interface: 157.60.137.88 --- 0x10003
Internet Address Physical Address Type
157.60.136.1 00-0a-42-b0-54-0a dynamic
157.60.137.0 00-b0-d0-e9-41-43 dynamic
Interface: 10.0.0.3 --- 0x10004
Internet Address Physical Address Type
10.0.0.1 08-00-2b-c4-25-b6 dynamic
The computer in this example is multihomed—has more than one NIC—so there is a separate ARP cache for each interface.
In the following example, the command arp –s is used to add a static entry to the ARP cache used by the second interface for the host whose IP address is 10.0.0.32 and whose NIC address is 00-60-8C-0E-6C-6A:
C:\>arp -s 10.0.0.32 00-60-8c-0e-6c-6a 10.0.0.3
C:\>arp -a
Interface: 157.60.137.88 --- 0x10003
Internet Address Physical Address Type
157.60.136.1 00-0a-42-b0-54-0a dynamic
157.60.137.0 00-b0-d0-e9-41-43 dynamic
Interface: 10.0.0.3 --- 0x10004
Internet Address Physical Address Type
10.0.0.1 08-00-2b-c4-25-b6 dynamic
10.0.0.32 00-60-8c-0e-6c-6a static
ARP Cache Aging
Windows Server 2003 adjusts the size of the ARP cache automatically to meet the needs of the system. If an entry is not used by any outgoing datagram for two minutes, the entry is removed from the ARP cache. Entries that are being referenced are removed from the ARP cache after ten minutes. Entries added manually are not removed from the cache automatically. The registry parameter ArpCacheLife, described in Appendix A, allows more administrative control over aging.
Use the command arp –d to delete entries from the cache, as shown below:
C:\>arp -d 10.0.0.32
C:\>arp -a
Interface: 157.60.137.88 --- 0x10003
Internet Address Physical Address Type
157.60.136.1 00-0a-42-b0-54-0a dynamic
157.60.137.0 00-b0-d0-e9-41-43 dynamic
Interface: 10.0.0.3 --- 0x10004
Internet Address Physical Address Type
10.0.0.1 08-00-2b-c4-25-b6 dynamic
ARP queues only one outbound IP datagram for a specified destination address while that IP address is being resolved to a MAC address. If a UDP-based application sends multiple IP datagrams to a single destination address without any pauses between them, some of the datagrams may be dropped if there is no ARP cache entry already present. An application can compensate for this by calling the Iphlpapi.dll routine SendArp() to establish an ARP cache entry, before sending the stream of packets. See INFO: IP Helper APIs Add Net Config and Stat Info to Win32 Apps or the MSDN for IP Helper API details.
Internet Protocol (IP)
IP is the mailroom of the TCP/IP stack, where packet sorting and delivery take place. At this layer, each incoming or outgoing packet is referred to as a datagram. Each IP datagram bears the source IP address of the sender and the destination IP address of the intended recipient. Unlike MAC addresses, the IP addresses in a datagram remain the same throughout a packet’s journey across an internetwork, unless you are using source routing. IP layer functions are described below.
Routing
Routing is a primary function of IP. Datagrams are handed to IP from UDP and TCP above, and from the NIC(s) below. Each datagram is labeled with a source and destination IP address. IP examines the destination address on each datagram, compares it to a locally maintained route table, and decides what action to take. There are three possibilities for each datagram:
-
It can be passed up to a protocol layer above IP on the local host.
-
It can be forwarded using one of the locally attached NICs.
-
It can be discarded.
The route table maintains four different types of routes:
-
Host route (a route to a single, specific destination IP address)
-
Subnet route (a route to a subnet)
-
Network route (a route to an entire network)
-
Default route (used when there is no other match)
To determine the single route to use to forward an IP datagram, IP uses the following process:
-
For each route in the route table, IP performs a bit-wise logical AND between the destination IP address and the netmask. IP compares the result with the network destination for a match. If they match, IP marks the route as one that matches the destination IP address.
-
From the list of matching routes, IP determines the route that has the most bits in the netmask. This is the route that matches the most bits to the destination IP address and is therefore the most specific route for the IP datagram. This is known as finding the longest or closest matching route.
-
If multiple closest matching routes are found, IP uses the route with the lowest metric. If multiple closest matching routes with the lowest metric are found, IP can choose to use any of those routes. For Windows Server 2003, IP uses the route corresponding to the adapter that is the highest in the binding order. You can view and modify the binding order from the Adapters and Bindings tab in the Advanced Settings dialog box for the Network Connections folder.
You can use the route print command to view the route table from the command prompt, as shown here:
C:\>route print
IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10002 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
0x10003 ...00 04 5a 56 10 06 ...... Linksys LNE100TX Fast Ethernet
Adapter(LNE100TX v4)
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 157.60.136.1 157.60.137.88 20
157.60.136.0 255.255.252.0 157.60.137.88 157.60.137.88 20
157.60.137.88 255.255.255.255 127.0.0.1 127.0.0.1 20
157.60.255.255 255.255.255.255 157.60.137.88 157.60.137.88 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 157.60.137.88 157.60.137.88 20
255.255.255.255 255.255.255.255 157.60.137.88 157.60.137.88 1
Default Gateway: 157.60.136.1
===========================================================================
Persistent Routes:
None
If the IPv6 protocol is installed, the display of the route print command also lists IPv6 routes.
The route table above is for a computer with the IP address of 157.60.137.88, the subnet mask of 255.255.252.0, and the default gateway of 157.60.136.1. It contains the following entries:
-
The first entry, to destination 0.0.0.0, is the default route.
-
The second entry is for the subnet 157.60.136.0, on which this computer resides.
-
The third entry, to destination 157.60.137.88, is a host route for the local host. It specifies the loopback address, which makes sense because a datagram bound for the local host should be looped back internally.
-
The fourth entry is for the all-subnets-directed broadcast address corresponding to the original Class B network ID 157.60.0.0.
-
The fifth entry is for the loopback network, 127.0.0.0.
-
The sixth entry is for IP multicasting, which is discussed later in this paper.
-
The final entry is for the limited broadcast (all ones) address.
The Default Gateway is the currently active default gateway. This is useful to know when multiple default gateways are configured.
On this host, if a packet is sent to 157.60.138.49, the closest matching route is the local subnet route (157.60.136.0 with the mask of 255.255.252.0). The packet is sent via the local interface that is assigned the IP address 157.60.137.88. If a packet is sent to 10.200.1.1, the closest matching route is the default route. In this case, the packet is forwarded to the default gateway at 157.60.136.1.
The route table is maintained automatically in most cases. When a host initializes, entries for the local network(s), loopback, multicast, and configured default gateway are added. More routes may appear in the table as the IP layer learns of them. For instance, the default gateway for a host may advise it of a better route to a specific address using ICMP redirect, which is explained later in this paper. Routes also may be added manually using the route command, or by a routing protocol. The -p (persistent) switch can be used with the route command to specify permanent routes. Persistent routes are stored in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\PersistentRoutes.
Windows Server 2003 TCP/IP introduces a new Automatic metric configuration option for interface-based and default gateway routing metrics. If selected for the interface, automatic metric configuration determines the metric for the routes associated with the interface configuration, such as subnet routes and host routes, based on the speed (bit rate) of the interface. The higher the speed, the lower the metric. For example, routes associated with 10 Mbps Ethernet interfaces have a metric of 30 and routes associated with 100 Mbps Ethernet interfaces have a metric of 20. If selected for the default gateway, automatic metric configuration determines the metric for the default route assigned to the interface, which is also based on the speed of the interface. Automatic metric configuration for both interface metrics and default routes are enabled by default and can be modified from the advanced configuration properties of the TCP/IP protocol for a connection in Network Connections. For more information, see An explanation of the Automatic Metric feature for Internet Protocol routes.
DHCP servers can also provide a base metric and a list of default gateways. If a DHCP server provides a base of 100, and a list of three default gateways, the gateways will be configured with metrics of 100, 101, and 102 respectively. A DHCP-provided base metric does not apply to statically configured default gateways.
By default, Windows-based systems do not behave as routers and do not forward IP datagrams between interfaces. However, the Routing and Remote Access service is included in Windows Server 2003 and can be enabled and configured to provide dynamic IP routing services using RIP and OSPF. Windows XP Professional includes support for silent RIP.
When running multiple logical subnets on the same physical network, the following command can be used to have IP treat all subnets as local (all destinations are on the local link):
route add 0.0.0.0 MASK 0.0.0.0
Thus, packets destined for non-local subnets are transmitted directly onto the local media instead of being sent to a router. In essence, the local interface card can be designated as the default gateway. This can be useful where several class C networks are used on one physical network with no router to the outside world, or in a proxy-ARP environment.
Duplicate IP Address Detection
Duplicate address detection is an important feature. When the stack is first initialized or when a new IP address is added, gratuitous ARP requests are broadcast for the IP addresses of the local host. The number of ARP requests to send is controlled by the ArpRetryCount registry parameter described in Appendix A, which defaults to 3. If another host replies to any of these ARP requests, the IP address is already in use. When this happens for an interface with a single manually-configured address, the Windows-based computer still boots; however, the interface containing the offending address is disabled, a system log entry is generated, and an error message is displayed. If the host that is defending the address is also a Windows-based computer, a system log entry is generated, and an error message is displayed on that computer. In order to update the ARP caches on other computers, the offending computer re-broadcasts another ARP request, spoofing the MAC address of the defending computer, to restore the proper values in the ARP caches of the other computers.
A computer using a duplicate IP address can be started when it is not attached to the network, in which case no conflict would be detected. However, if it is then plugged into the network, the first time that it sends an ARP request for another IP address, any computer running a version of Windows with the Windows NT codebase with a conflicting address detects the conflict. The computer detecting the conflict displays an error message and logs a detailed event in the system log. A sample event log entry is shown below:
The system detected an address conflict for IP address 10.199.40.123 with the system having network hardware address 00:DD:01:0F:7A:B5. Network operations on this system may be disrupted as a result.
DHCP-enabled clients inform the DHCP server with a DHCPDecline message when an IP address conflict is detected and, instead of disabling the TCP/IP protocol, they request a new address from the DHCP server and request that the server mark the conflicting address as bad.
Multihoming
When a computer is configured with more than one IP address, it is referred to as a multihomed system. Multihoming is supported in three different ways:
-
Multiple IP addresses per NIC
-
To add addresses for an interface, obtain properties of the Internet Protocol (TCP/IP) protocol in Network Connection, and then click Advanced. In the Advanced Settings dialog box, click Add on the IP Settings tab to add IP addresses.
-
NetBIOS over TCP/IP (NetBT) binds to only one IP address per interface card. When a NetBIOS name registration is sent out, only one IP address is registered per interface. This registration occurs over the IP address that is listed first on the IP Settings tab.
-
Multiple NICs per physical network. There are no restrictions, other than hardware limitations on the number of NICs.
-
Multiple networks and media types. There are no restrictions, other than hardware and media support. See the “The NDIS Interface and Below” section for supported media types.
When an IP datagram is sent from a multihomed host, it is passed to the interface with the best apparent route to the destination. Accordingly, the datagram may contain the source IP address of one interface in the multihomed host, yet be placed on the media by a different interface. The source MAC address on the frame is that of the interface that actually transmitted the frame to the media, and the source IP address is the one that the sending application sourced it from, not necessarily one of the IP addresses assigned to the sending interface.
When a computer is multihomed with NICs attached to disjoint networks (networks that are separate from and unaware of each other, such as a private network using private addressing and the Internet), routing problems may arise. It is often necessary to set up static routes to the private networks in this situation.
When configuring a computer to be multihomed on two disjoint networks, the best practice is to configure the default gateway on the interface connected to the largest and least-known network, in which the default route summarizes the most destinations. Then, either add static routes or use a routing protocol to provide connectivity to the hosts on the smaller or better-known network. Avoid configuring a different default gateway on each side; this can result in unpredictable behavior and loss of connectivity. For more information, see Default Gateway Behavior for Windows TCP/IP.
Note There can only be one active default gateway for a computer at any moment in time.
More details on name registration, resolution, and choice of NIC on outbound datagrams with multihomed computers are provided in the “Transmission Control Protocol (TCP),” “NetBIOS over TCP/IP,” and “Windows Sockets” sections of this paper.
Classless Inter-Domain Routing (CIDR)
CIDR, described in RFCs 1518 and 1519, removes the concept of address classes from the IP address assignment and management process. In place of predefined, well-known boundaries, CIDR allocates addresses defined by a network prefix, which makes more efficient use of available space. The network prefix defines the portion of the address that is fixed. For example, an assignment from an ISP to a corporate client might be expressed as 157.60.1.128/25. In this prefix, the first 25 bits are fixed and the last 7 bits can be used for address assignment. This would result in a 128-address block for local use, with the upper 25 bits being the network identifier part of the address. A legacy, class-full prefix would be expressed as w.0.0.0/8, w.x.0.0/16, or w.x.y.0/24. As these are reclaimed, they will be reallocated using classless CIDR techniques.
Given the installed base of classful systems, the initial implementation of CIDR was to summarize portions of the Class C address space. This process was called supernetting. Supernetting can be used to consolidate several network IDs into one prefix. For example, the network IDs 131.107.4.0, 131.107.5.0, 131.107.6.0, and 131.107.7.0 can be summarized with the network ID 131.107.4.0 with a subnet mask of 255.255.252.0 (131.107.4.0/22). For example:
NET 131.107.4.0 (1100 0111.1100 0111.0000 0100.0000 0000)
NET 131.107.5.0 (1100 0111.1100 0111.0000 0101.0000 0000)
NET 131.107.6.0 (1100 0111.1100 0111.0000 0110.0000 0000)
NET 131.107.7.0 (1100 0111.1100 0111.0000 0111.0000 0000)
MASK 255.255.252.0 (1111 1111.1111 1111.1111 1100.0000 0000)
All four of the network IDs share the same high-order 22 bits.
When routing decisions are made, only the bits covered by the subnet mask are used, thus making all these addresses appear to be part of the same network for routing purposes. Any routers in use must also support CIDR and may require special configuration.
Windows Server 2003 TCP/IP includes support for the all-0's and all-1's subnets as described in RFC 1878.
IP Multicasting
IP multicasting is used to provide efficient multicast services to clients that may not be located on the same network segment. Windows Sockets applications can join a multicast group to participate in a wide-area conference, for instance.
Windows Server 2003 TCP/IP is level 2-compliant with RFC 1112 (send and receive). IGMP is the protocol used to track multicast membership on a subnet, which is described later in this paper.
IP over ATM
Windows Server 2003 includes support for IP over ATM. RFC 1577 (and successors) define the basic operation of an IP over ATM network known as Classical IP over ATM (CLIP), which defines a Logical IP Subnet (LIS). A LIS is a set of IP hosts that can communicate directly with each other. Two hosts belonging to different LISs can communicate only through an IP router that is a member of both subnets. Windows Server 2003 also includes support for ATM LAN Emulation (LANE), which supports broadcasting.
ATM Address Resolution
Because an ATM network is non-broadcast, ARP broadcasts (as used by Ethernet or Token Ring) are not a suitable solution. Instead, a dedicated ARP server is used to provide IP-to-ATM address resolution.
One of the stations in a LIS is designated as an ARP server, and the ARP server software is loaded on it. Stations that use the services of the ARP server are referred to as ARP clients. All IP stations within a LIS are ARP clients. Each ARP client is configured with the ATM address of the ARP server. When an ARP client starts up, it makes an ATM connection to the ARP server, and sends a packet to the server that contains the client’s IP and ATM addresses. The ARP server builds a table of IP-address-to-ATM-address mappings. When a client has an IP packet to be sent to another client (whose IP address is known but whose ATM address is unknown), it first queries the ARP server for the ATM address of the desired client. When it receives a reply that contains the desired ATM address, the client establishes a direct ATM connection to the target client and sends IP packets for that client on this connection.
The clients close any ATM connection, including the connection to the server, if the connections are inactive. All clients refresh their IP and ATM address information with the server periodically (the default is 15 minutes). The server purges an entry that is not refreshed after 20 minutes (by default). The ATM ARP client and ARP server both support a number of adjustable registry parameters, which are listed in Appendix A.
Internet Control Message Protocol (ICMP)
ICMP is a maintenance protocol specified in RFC 792 and is normally considered part of the Internet layer. ICMP messages are encapsulated within IP datagrams, so that they can be routed throughout an internetwork. Windows Server 2003 TCP/IP uses ICMP to:
-
Report delivery problems encountered by routers or destination hosts.
-
Build and maintain route tables.
-
Perform router discovery.
-
Assist in Path Maximum Transmission Unit (PMTU) discovery.
-
Diagnose reachability problems (the ping, tracert, and pathping tools).
-
Adjust flow control to prevent link or router saturation.
Windows Server 2003 TCP/IP can perform router discovery as specified in RFC 1256. Router discovery provides an improved method of configuring and detecting default gateways. Instead of using manually- or DHCP-configured default gateways, hosts can dynamically discover routers on their subnet. If the primary router fails or the network administrators change router preferences, hosts can automatically switch to a backup router.
When a host that supports router discovery initializes, it joins the all-systems IP multicast group (224.0.0.1), and then listens for the router advertisements that routers send to that group. Hosts can also send router-solicitation messages to the all-routers IP multicast address (224.0.0.2) when an interface initializes to avoid any delay in being configured. Windows Server 2003 TCP/IP sends a maximum of three solicitations at intervals of approximately 600 milliseconds.
The use of router discovery is controlled by the PerformRouterDiscovery and SolicitationAddressBCast registry parameters, and it defaults to DHCP controlled in Windows Server 2003. Setting SolicitationAddressBCast to 1 causes router solicitations to be broadcast, instead of multicast, as described in RFC 1256.
Maintaining Route Tables
When a Windows-based computer is initialized, the route table normally contains only a few entries. One of those entries specifies a default gateway. Datagrams that have a destination IP address with no better match in the route table are sent to the default gateway. However, because routers share information about network topology, the default gateway may know a better route to a given address. When this is the case, then upon receiving a datagram that could take the better path, the router forwards the datagram normally. It then advises the sender of the better route, using an ICMP Redirect message. These messages typically specify redirection for a specific destination address. When a Windows-based computer receives an ICMP redirect, a validity check is performed to be sure that it came from the first-hop gateway in the current route, and that the gateway is on a directly connected network. If so, a host route with a 10-minute lifetime is added to the route table for that destination IP address. If the ICMP redirect did not come from the first-hop gateway in the current route, or if that gateway is not on a directly connected network, the ICMP redirect is ignored.
In Windows Server 2003 Service Pack 1, the new MaxICMPHostRoutes registry value defines the maximum number of host routes that can be added through the receipt of ICMP Redirect messages. For more information, see Appendix A.
Path Maximum Transmission Unit (PMTU) Discovery
TCP employs Path Maximum Transmission Unit (PMTU) discovery, as described in the “Transmission Control Protocol (TCP)” section of this paper. The mechanism relies on ICMP Destination Unreachable messages.
Use of ICMP to Diagnose Problems
The ping command-line utility is used to send ICMP echo requests to an IP address and wait for ICMP echo responses. Ping reports on the number of responses received and the time interval between sending the request and receiving the response. There are many different options that can be used with the ping utility.
Tracert is a route-tracing utility that can be very useful. Tracert works by sending ICMP echo requests to an IP address, while incrementing the Time to Live (TTL) field in the IP header, starting at 1, and analyzing the ICMP errors that are returned. Each succeeding echo request should get one hop further into the network before the TTL field reaches 0 and the router attempting to forward it returns an ICMP Time Exceeded-TTL Exceeded in Transit error message. Tracert prints out an ordered list of the routers in the path that returned these error messages, including the name and the IP address the nearside interface of each router. If the -d (do not do a DNS reverse query on each IP address) switch is used, only the IP address is reported. The example below illustrates using tracert to find the route from a computer dialed in over Point-to-Point Protocol (PPP) to an Internet service provider in Seattle to www.whitehouse.gov.
C:\>tracert www.whitehouse.gov
Tracing route to www.whitehouse.gov [128.102.252.1]
over a maximum of 30 hops:
1 300 ms 281 ms 280 ms roto.seanet.com [199.181.164.100]
2 300 ms 301 ms 310 ms sl-stk-1-S12-T1.sprintlink.net [144.228.192.65]
3 300 ms 311 ms 320 ms sl-stk-5-F0/0.sprintlink.net [144.228.40.5]
4 380 ms 311 ms 340 ms icm-fix-w-H2/0-T3.icp.net [144.228.10.22]
5 310 ms 301 ms 320 ms arc-nas-gw.arc.nasa.gov [192.203.230.3]
6 300 ms 321 ms 320 ms n254-ed-cisco7010.arc.nasa.gov [128.102.64.254]
7 360 ms 361 ms 371 ms www.whitehouse.gov [128.102.252.1]
Pathping is a command-line utility that combines the functionality of ping and tracert as well as introducing some new features. Along with the tracing functionality of tracert, pathping will ping each hop along the route multiple times and display delay and packet loss information per hop, which can help you determine if there is a high-loss link or router in the path.
|