The TCP/IP Protocol Suite

The TCP/IP protocol suite maps to a four-layer conceptual model known as the DARPA model, which was 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 OSI model. Figure 2-1 shows the architecture of the TCP/IP protocol suite.

Figure 2-1 The architecture of the TCP/IP protocol suite The TCP/IP protocol suite has two sets of protocols at the Internet layer: IPv4, also known as IP, is the Internet layer in common use today on private intranets and the Internet. IPv6 is the new Internet layer that will eventually replace the existing IPv4 Internet layer.

Network Interface Layer

The Network Interface layer (also called the Network Access layer) sends TCP/IP packets on the network medium and receives TCP/IP packets off the network medium. TCP/IP was designed to be independent of the network access method, frame format, and medium. Therefore, you can use TCP/IP to communicate across differing network types that use LAN technologies such as Ethernet and 802.11 wireless LANand WAN technologiessuch as Frame Relay and Asynchronous Transfer Mode (ATM). By being independent of any specific network technology, TCP/IP can be adapted to new technologies. The Network Interface layer of the DARPA model encompasses the Data Link and Physical layers of the OSI model. The Internet layer of the DARPA model does not take advantage of sequencing and acknowledgment services that might be present in the Data Link layer of the OSI model. The Internet layer assumes an unreliable Network Interface layer and that reliable communications through session establishment and the sequencing and acknowledgment of packets is the responsibility of either the Transport layer or the Application layer.

Internet Layer
The Internet layer responsibilities include addressing, packaging, and routing functions. The Internet layer is analogous to the Network layer of the OSI model. The core protocols for the IPv4 Internet layer consist of the following: The Address Resolution Protocol (ARP) resolves the Internet layer address to a Network Interface layer address such as a hardware address. The Internet Protocol (IP) is a routable protocol that addresses, routes, fragments, and reassembles packets. The Internet Control Message Protocol (ICMP) reports errors and other information to help you diagnose unsuccessful packet delivery. The Internet Group Management Protocol (IGMP) manages IP multicast groups. For more information about the core protocols for the IPv4 Internet layer, see "IPv4 Internet Layer" later in this chapter.

The core protocols for the IPv6 Internet layer consist of the following: IPv6 is a routable protocol that addresses and routes packets. The Internet Control Message Protocol for IPv6 (ICMPv6) reports errors and other information to help you diagnose unsuccessful packet delivery. The Neighbor Discovery (ND) protocol manages the interactions between neighboring IPv6 nodes. The Multicast Listener Discovery (MLD) protocol manages IPv6 multicast groups. For more information about the core protocols for the IPv6 Internet layer, see "IPv6 Internet Layer" later in this chapter.

Transport Layer
The Transport layer (also known as the Host-to-Host Transport layer) provides the Application layer with session and datagram communication services. The Transport layer encompasses the responsibilities of the OSI Transport layer. The core protocols of the Transport layer are TCP and UDP. TCP provides a one-to-one, connection-oriented, reliable communications service. TCP establishes connections, sequences and acknowledges packets sent, and recovers packets lost during transmission. In contrast to TCP, 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 the data that would fit into a single packet), when an application developer does not want the overhead associated with TCP connections, or when the applications or upper-layer protocols provide reliable delivery. TCP and UDP operate over both IPv4 and IPv6 Internet layers. Note The Internet Protocol (TCP/IP) component of Windows contains separate versions of the TCP and UDP protocols than the Microsoft TCP/IP Version 6 component does. The versions in the Microsoft TCP/IP Version 6 component are functionally equivalent to those provided with the Microsoft Windows NT 4.0 operating systems and contain all the most recent security updates. The existence of separate protocol components with their own versions of TCP and UDP is known as a dual stack architecture. The ideal architecture is known as a dual IP layer, in which the same versions of TCP and UDP operate over both IPv4 and IPv6 (as Figure 2-1 shows). Windows Vista has a dual IP layer architecture for the TCP/IP protocol components.

Application Layer
The Application layer allows applications to access the services of the other layers, and it defines the protocols that applications use to exchange data. The Application layer contains many protocols, and more are always being developed. The most widely known Application layer protocols help users exchange information: The Hypertext Transfer Protocol (HTTP) transfers files that make up pages on the World Wide Web. The File Transfer Protocol (FTP) transfers individual files, typically for an interactive user session. The Simple Mail Transfer Protocol (SMTP) transfers mail messages and attachments. Additionally, the following Application layer protocols help you use and manage TCP/IP networks: The Domain Name System (DNS) protocol resolves a host name, such as www.microsoft.com, to an IP address and copies name information between DNS servers. The Routing Information Protocol (RIP) is a protocol that routers use to exchange routing information on an IP network. The Simple Network Management Protocol (SNMP) collects and exchanges network management information between a network management console and network devices such as routers, bridges, and servers. Windows Sockets and NetBIOS are examples of Application layer interfaces for TCP/IP applications. For more information, see Application Programming Interfaces later in this chap ter.

Top of page

IPv4 Internet Layer

The IPv4 Internet layer consists of the following protocols: ARP IP (IPv4) ICMP IGMP The following sections describe each of these protocols in more detail.

ARP
When IP sends packets over a shared access, broadcast-based networking technology such as Ethernet or 802.11 wireless LAN, the protocol must resolve the media access control (MAC) addresses corresponding to the IPv4 addresses of the nodes to which the packets are being forwarded, also known as the next-hop IPv4 addresses. As RFC 826 defines, ARP uses MAC-level broadcasts to resolve next-hop IPv4 addresses to their corresponding MAC addresses. Based on the destination IPv4 address and the route determination process, IPv4 determines the nexthop IPv4 address and interface for forwarding the packet. IPv4 then hands the IPv4 packet, the nexthop IPv4 address, and the next-hop interface to ARP. If the IPv4 address of the packets next hop is the same as the IPv4 address of the packets destination, ARP performs a direct delivery to the destination. In a direct delivery, ARP must resolve the IPv4 address of the packets destination to its MAC address. If the IPv4 address of the packets next hop is not the same as the IPv4 address of the packets destination, ARP performs an indirect delivery to a router. In an indirect delivery, ARP must resolve the IPv4 address of the router to its MAC address To resolve the IPv4 address of a packets next hop to its MAC address, ARP uses the broadcasting facility on shared access networking technologies (such as Ethernet or 802.11) to send out a broadcast ARP Request frame. In response, the sender receives an ARP Reply frame, which contains the MAC address that corresponds to the IPv4 address of the packets next hop.

ARP Cache
To minimize the number of broadcast ARP Request frames, many TCP/IP protocol implementations incorporate an ARP cache, which is a table of recently resolved IPv4 addresses and their corresponding MAC addresses. ARP checks this 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 cache entries are permanent, and you add them manually using a TCP/IP tool, such as the Arp tool provided with Windows. Static ARP cache entries prevent nodes from sending ARP requests for commonly used local IPv4 addresses, such as those for routers and servers. The problem with static ARP cache entries is that you must manually update them when network adapter equipment changes. Dynamic ARP cache entries have time-out values associated with them so that they are removed from the cache after a specified period of time. For example, dynamic ARP cache entries for Windows are removed after no more than 10 minutes. To view the ARP cache on a Windowsbased computer, type arp -a at a command prompt. You can also use the Arp tool to add or delete static ARP cache entries.

ARP Process
When sending the initial packet as the sending host or forwarding the packet as a router, IPv4 sends the IPv4 packet, the next-hop IPv4 address, and the next-hop interface to ARP. Whether performing a direct or indirect delivery, ARP performs the following process: 1. Based on the next-hop IPv4 address and interface, ARP checks the appropriate ARP cache for an entry that matches the next-hop IPv4 address. If ARP finds an entry, ARP skips to step 6.

If ARP does not find an entry, ARP builds an ARP Request frame. This frame contains the MAC and IPv4 addresses of the interface from which the ARP request is being sent and the IPv4 packet's next-hop IPv4 address. ARP then broadcasts the ARP Request frame from the appropriate interface. 3. All nodes on the subnet receive the broadcasted frame and process the ARP request. If the next-hop address in the ARP request corresponds to the IPv4 address assigned to an interface on the subnet, the receiving node updates its ARP cache with the IPv4 and MAC addresses of the ARP requestor. All other nodes silently discard the ARP request. 4. The receiving node that is assigned the IPv4 packets next-hop address formulates an ARP reply that contains the requested MAC address and sends the reply directly to the ARP requestor. 5. When the ARP requestor receives the ARP reply, the requestor updates its ARP cache with the address mapping. With the exchange of the ARP request and the ARP reply, both the ARP requestor and ARP responder have each other's address mappings in their ARP caches. 6. The ARP requestor sends the IPv4 packet to the next-hop node by addressing it to the resolved MAC address. Figure 2-2 shows this process.

2.

Figure 2-2 The ARP address resolution process

Internet Protocol version 4 (IPv4)

IPv4 is a datagram protocol primarily responsible for addressing and routing packets between hosts. IPv4 is connectionless, which means that it does not establish a connection before exchanging data, and unreliable, which means that it does not guarantee packet delivery. IPv4 always makes a best effort attempt to deliver a packet. An IPv4 packet might be lost, delivered out of sequence, duplicated, or delayed. IPv4 does not attempt to recover from these types of errors. A higher-layer protocol, such as TCP or an application protocol, must acknowledge delivered packets and recover lost packets if needed. IPv4 is defined in RFC 791. An IPv4 packet consists of an IPv4 header and an IPv4 payload. An IPv4 payload, in turn, consists of an upper layer protocol data unit, such as a TCP segment or a UDP message. Figure 2-3 shows the basic structure of an IPv4 packet.

Figure 2-3 The basic structure of an IPv4 packet Table 2-1 lists and describes the key fields in the IPv4 header. IP Header Field Source IP Address Description The IPv4 address of the source of the IP packet.

Destination IP Address Identification Protocol Checksum Time-to-Live (TTL)

The IPv4 address of the intermediate or final destination of the IPv4 packet.

An identifier for all fragments of a specific IPv4 packet, if fragmentation occurs. An identifier of the upper-layer protocol to which the IPv4 payload must be passed. A simple mathematical computation used to check for bit-level errors in the IPv4 header.

The number of network segments on which the datagram is allowed to travel before a router s sets the TTL, and routers decrease the TTL by one when forwarding an IPv4 packet. This field p circulating on an IPv4 network.

Table 2-1 Key Fields in the IPv4 Header

Fragmentation and Reassembly

If a router receives an IPv4 packet that is too large for the network segment on which the packet is being forwarded, IPv4 on the router fragments the original packet into smaller packets that fit on the forwarding network segment. When the packets arrive at their final destination, IPv4 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 technologies, such as Ethernet or Token Ring. Fragmentation and reassembly work as follows: 1. Before an IPv4 packet is sent, the source places a unique value in the Identification field. 2. A router in the path between the sending host and the destination receives the IPv4 packet and notes that it is larger than the maximum transmission unit (MTU) of the network onto which the packet is to be forwarded. 3. IPv4 divides the original IPv4 payload into fragments that fit on the next network. Each fragment receives its own IPv4 header containing: o The original Identification field, which identifies all fragments that belong together. o The More Fragments flag, which indicates that other fragments follow. The More Fragments flag is not set on the last fragment, because no other fragments follow it. o The Fragment Offset field, which indicates the position of the fragment relative to the original IPv4 payload. When the remote host receives the fragments, it uses the Identification field to identify which fragments belong together and the Fragment Offset field to reassemble the fragments in their proper order to recreate the original IPv4 payload.

Internet Control Message Protocol (ICMP)

ICMP, defined in RFC 792, reports and helps troubleshoot errors for packets that are undeliverable. For example, if IPv4 cannot deliver a packet to the destination host, ICMP on the router or the destination host sends a Destination Unreachable message to the sending host. Table 2-2 lists and describes the most common ICMP messages. ICMP Message Echo Description

The Ping tool sends ICMP Echo messages to troubleshoot network problems by checking IP node. Nodes send Echo Reply messages to respond to ICMP Echo messages.

Echo Reply

Redirect Source Quench

Routers send Redirect messages to inform sending hosts of better routes to destination IPv Routers send Source Quench messages to inform sending hosts that their IPv4 packets are at the router. The sending hosts then send packets less frequently.

Destination Unreachable

Routers and destination hosts send Destination Unreachable messages to inform sending h delivered.

Table 2-2 Common ICMP Messages ICMP contains a series of defined Destination Unreachable messages. Table 2-3 lists and describes the most common messages. Destination Unreachable Message Host Unreachable Protocol Unreachable Description

Routers send Host Unreachable messages when they cannot find routes to destina

Destination IPv4 nodes send Protocol Unreachable messages when they cannot ma header with an IPv4 client protocol that is currently in use.

Port Unreachable

IPv4 nodes send Port Unreachable messages when they cannot match the Destinat with an application using that UDP port.

Fragmentation Needed and DF Set

IPv4 routers send Fragmentation Needed and DF Set messages when fragmentatio has set the Dont Fragment (DF) flag in the IPv4 header.

Table 2-3 Common ICMP Destination Unreachable Messages ICMP does not make IPv4 a reliable protocol. ICMP attempts to report errors and provide feedback on specific conditions. ICMP messages are carried as unacknowledged IPv4 packets and are themselves unreliable.

Internet Group Management Protocol (IGMP)

Routers and hosts use IGMP to manage membership in IPv4 multicast groups on a subnet. An IPv4 multicast group, also known as a host group, is a set of hosts that listen for IPv4 traffic destined for a specific IPv4 multicast address. IPv4 multicast traffic on a given subnet is sent to a single MAC address but received and processed by multiple IPv4 hosts. A host group member listens on a specific IPv4 multicast address and receives all packets sent to that IPv4 address. For a host to receive IPv4 multicasts, an application must inform IPv4 that it will receive multicasts at a specified IPv4 multicast address. IPv4 then informs the routers on locally attached subnets that it should receive multicasts sent to the specified IPv4 multicast address. IGMP is the protocol to register host group membership information. IGMP messages take the following forms: Host group members use the IGMP Host Membership Report message to declare their membership in a specific host group. Routers use the IGMP Host Membership Query message to poll subnets for information about members of host groups. Host group members use the IGMP Leave Group message when they leave a group of which they might be the last member on the subnet. For IPv4 multicasting to span routers across an IPv4 network, routers use multicast routing protocols to communicate host group information. Each router that supports multicast forwarding can then determine how to forward IPv4 multicast traffic.

Windows Server 2003 and Windows XP support IGMP, IGMP version 2, and IGMP version 3, which RFC 1112, RFC 2236, and RFC 3376 define respectively.

Top of page

IPv6 Internet Layer

IPv6 will eventually replace the IPv4 Internet layer protocols in the DARPA model. IPv6 replaces: IPv4 with IPv6 IPv6 is a routable protocol that addresses, routes, fragments, and reassembles packets. ICMP with ICMPv6 ICMPv6 provides diagnostic functions and reports errors when IPv6 packets cannot be delivered. IGMP with MLD MLD manages IPv6 multicast group membership. ARP with ND ND manages interaction between neighboring nodes, including automatically configuring addresses and resolving next-hop IPv6 addresses to MAC addresses. Software developers do not need to change the protocols at the Transport and Application layers to support operation over an IPv6 Internet layer, except when addresses are part of the payload or part of the data structures maintained by the protocol. For example, software developers must update both TCP and UDP to perform a new checksum, and they must update RIP to send and receive IPv6based routing information. The IPv6 Internet layer consists of the following protocols: IPv6 ICMPv6 ND MLD The following sections describe these protocols in more detail.

IPv6
Like IPv4, IPv6 is a connectionless, unreliable datagram protocol that is primarily responsible for addressing and routing packets between hosts. RFC 2460 defines IPv6 packet structure. An IPv6 packet consists of an IPv6 header and an IPv6 payload. The IPv6 payload consists of zero or more IPv6 extension headers and an upper layer protocol data unit, such as an ICMPv6 message, a TCP segment, or a UDP message. Figure 2-4 shows the basic structure of an IPv6 packet.

Figure 2-4 Basic structure of an IPv6 packet Table 2-4 lists and describes the key fields in the IPv6 header. IPv6 Header Field Source Address Destination Address Next Header Description A 128-bit IPv6 address to identify the original source of the IPv6 packet.

A 128-bit IPv6 address to identify the intermediate or final destination of the IPv6 packet.

An identifier for either the IPv6 extension header immediately following the IPv6 header or an up

TCP, or UDP. Hop Limit

The number of links on which the packet is allowed to travel before being discarded by a router. limit, and routers decrease the hop limit by one when forwarding an IPv6 packet. This field preve circulating on an IPv6 network.

Table 2-4 Key Fields in the IPv6 Header

IPv6 Extension Headers

IPv6 payloads can contain zero or more extension headers, which can vary in length. A Next Header field in the IPv6 header indicates the next extension header. Each extension header contains another Next Header field that indicates the next extension header. The last extension header indicates the upper layer protocol (such as TCP, UDP, or ICMPv6), if any, that the upper layer protocol data unit contains. The IPv6 header and extension headers replace the existing IPv4 header and its capability to include options. The new format for extension headers allows IPv6 to be augmented to support future needs and capabilities. Unlike options in the IPv4 header, IPv6 extension headers have no maximum size and can expand to accommodate all the extension data needed for IPv6 communication. RFC 2460 defines the following IPv6 extension headers that all IPv6 nodes must support: Hop-by-Hop Options header Destination Options header Routing header Fragment header Authentication header Encapsulating Security Payload header Typical IPv6 packets contain no extension headers. Sending hosts add one or more extension headers only if intermediate routers or the destination need to handle a packet in a particular way.

Fragmentation in IPv6
In IPv4, if a router receives a packet that is too large for the network segment to which the packet is being forwarded and fragmentation of the packet is allowed, IPv4 on the router fragments the original packet into smaller packets that fit on the forwarding network segment. In IPv6, only the sending host fragments a packet. If an IPv6 packet is too large, the IPv6 router sends an ICMPv6 Packet Too Big message to the sending host and discards the packet. A sending host can fragment packets and destination hosts can reassemble packets through the use of the Fragment extension header.

Internet Control Message Protocol for IPv6 (ICMPv6)

Like IPv4, IPv6 does not report errors. Instead, IPv6 uses an updated version of ICMP for IPv4. This new version is named ICMPv6, and it performs the common ICMP for IPv4 functions of reporting errors in delivery or forwarding and providing a simple echo service for troubleshooting. The ICMPv6 protocol also provides a message structure for ND and MLD messages. Table 2-5 lists and describes the ICMPv6 messages defined in RFC 2463. ICMPv6 Message Echo Request Echo Reply Destination Unreachable Description

Sending hosts send Echo Request messages to check IPv6 connectivity to a particular nod Nodes send Echo Reply messages to reply to ICMPv6 Echo Request messages.

Routers or destination hosts send Destination Unreachable messages to inform sending h cannot be delivered.

Packet Too Big Time Exceeded Parameter Problem

Routers send Packet Too Big messages to inform sending hosts that packets are too large

Routers send Time Exceeded messages to inform sending hosts that the hop limit of an IP

Routers send Parameter Problem messages to inform sending hosts when errors were enc header or an IPv6 extension header.

Table 2-5 Common ICMPv6 Messages ICMPv6 contains a series of defined Destination Unreachable messages. Table 2-6 lists and describes the most common messages. Destination Unreachable Message No Route Found Description Routers send this message when they cannot find routes to the destination routing tables.

Communication Prohibited by Administrative Policy Destination Address Unreachable Destination Port Unreachable

Routers send this message when a policy configured on the router prohibits destination. For example, this type of message is sent when a firewall discard

IPv6 routers send this message when they cannot resolve a destinations MA

Destination hosts send this message when an IPv6 packet containing a UDP does not correspond to a listening application.

Table 2-6 Common ICMPv6 Destination Unreachable Messages ICMPv6 does not make IPv6 a reliable protocol. ICMPv6 attempts to report errors and provide feedback on specific conditions. ICMPv6 messages are carried as unacknowledged IPv6 packets and are themselves unreliable.

Neighbor Discovery (ND)

ND is a set of ICMPv6 messages and processes that determine relationships between neighboring nodes. ND replaces ARP, ICMP Router Discovery, and ICMP Redirect used in IPv4 and provides additional functionality. Hosts use ND to: Discover neighboring routers. Discover and automatically configure addresses and other configuration parameters. Routers use ND to: Advertise their presence, host addresses, and other configuration parameters. Inform hosts of a better next-hop address to forward packets for a specific destination. Nodes (both hosts and routers) use ND to: Resolve the link-layer address (also known as a MAC address) of a neighboring node to which an IPv6 packet is being forwarded Dynamically advertise changes in MAC addresses. Determine whether a neighbor is still reachable. Table 2-7 lists and describes the ND processes described in RFC 2461. Neighbor Discovery Process Router discovery Description

The process by which a host discovers its neighboring routers. For more information, se

chapter. Prefix discovery

The process by which hosts discover the subnet prefixes for local subnet destinations. F subnet prefixes, see Chapter 3, "IP

Addressing."

Address autoconfiguration

The process for configuring IPv6 addresses for interfaces in either the presence or abse server such as one running Dynamic Host Configuration Protocol version 6 (DHCPv6). F Autoconfiguration" later in this chapter.

Address resolution

The process by which nodes resolve a neighbors IPv6 address to its MAC address. Add to ARP in IPv4. For more information, see "Address Resolution" in this chapter.

Next-hop determination

The process by which a node determines the next-hop IPv6 address to which a packet i destination address. The next-hop address is either the destination address or the addr

Neighbor unreachability detection Duplicate address detection Redirect function

The process by which a node determines that the IPv6 layer of a neighbor is not capabl

The process by which a node determines that an address considered for use is not alrea

The process of informing a host of a better first-hop IPv6 address to reach a destination

Table 2-7 IPv6 Neighbor Discovery Processes

Address Resolution
IPv6 address resolution consists of exchanging Neighbor Solicitation and Neighbor Advertisement messages to resolve the next-hop IPv6 address to its corresponding MAC address. The sending host sends a multicast Neighbor Solicitation message on the appropriate interface. The Neighbor Solicitation message includes the MAC address of the sending node. When the target node receives the Neighbor Solicitation message, it updates its neighbor cache (equivalent to the ARP cache) with an entry for the source address and MAC address included in the Neighbor Solicitation message. Next, the target node sends a unicast Neighbor Advertisement message with its MAC address to the sender of the Neighbor Solicitation message. After receiving the Neighbor Advertisement from the target, the sending host updates its neighbor cache with an entry for the target node based upon the included MAC address. At this point, the sending host and the target of the neighbor solicitation can send unicast IPv6 traffic.

Router Discovery
Router discovery is the process through which hosts attempt to discover the set of routers on the local subnet. In addition to configuring a default router, IPv6 router discovery also configures the following: The default setting for the Hop Limit field in the IPv6 header. A determination of whether the node should use an address configuration protocol, such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6), for addresses and other configuration parameters. The list of subnet prefixes defined for the link. Each subnet prefix contains both the IPv6 subnet prefix and its valid and preferred lifetimes. If indicated, the host uses the subnet prefix to create an IPv6 address configuration without using an address configuration protocol. A subnet prefix also defines the range of addresses for nodes on the local link. The IPv6 router discovery processes are the following:

IPv6 routers periodically send multicast Router Advertisement messages on the subnet advertising their existence as routers and other configuration parameters such as address prefixes and the default hop limit. IPv6 hosts on the local subnet receive the Router Advertisement messages and use their contents to configure addresses, a default router, and other configuration parameters. A host that is starting up sends a multicast Router Solicitation message. Upon receipt of a Router Solicitation message, all routers on the local subnet send a unicast Router Advertisement message to the host that sent the router solicitation. The host receives the Router Advertisement messages and uses their contents to configure addresses, a default router, and other configuration parameters.

Address Autoconfiguration
A highly useful aspect of IPv6 is its ability to automatically configure itself without the use of an address configuration protocol, such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6). By default, an IPv6 host can configure an address for use on the subnet for each interface. By using router discovery, a host can also determine the addresses of routers, additional addresses, and other configuration parameters. Router Advertisement messages indicate whether an address configuration protocol should be used. RFC 2462 defines IPv6 address autoconfiguration. For more information about IPv6 address autoconfiguration, see Chapter 6 Dynamic

Host

Configuration Protocol.

Multicast Listener Discovery (MLD)

MLD is the IPv6 equivalent of IGMP version 2 for IPv4. MLD is a set of ICMPv6 messages exchanged by routers and nodes, enabling routers to discover the set of IPv6 multicast addresses for which there are listening nodes for each attached interface. Like IGMPv2, MLD discovers only those multicast addresses that include at least one listener, not the list of individual multicast listeners for each multicast address. RFC 2710 defines MLD. Unlike IGMPv2, MLD uses ICMPv6 messages instead of defining its own message structure. The three types of MLD messages are: Multicast Listener Query Routers use Multicast Listener Query messages to query a subnet for multicast listeners. Multicast Listener Report Multicast listeners use Multicast Listener Report messages to either report interest in receiving multicast traffic for a specific multicast address or to respond to a Multicast Listener Query message. Multicast Listener Done Multicast listeners use Multicast Listener Done messages to report that they might be the last multicast group member on the subnet.

Top of page

Transmission Control Protocol (TCP)

TCP is a reliable, connection-oriented delivery service. 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. TCP peers, the two nodes using TCP to communicate, acknowledge when they receive data. A TCP segment is the protocol data unit (PDU) consisting of the TCP header and the TCP payload, also known as a segment. For each TCP segment sent containing data, the receiving host must return an acknowledgment (ACK). If an ACK is not received within a calculated time, the TCP segment is retransmitted. RFC 793 defines TCP. Table 2-8 lists and describes the key fields in the TCP header. Field Source Port Description TCP port of sending application.

Destination Port Sequence Number Acknowledgment Number Window Checksum

TCP port of destination application. Sequence number of the first byte of data in the TCP segment.

Sequence number of the next byte the sender expects to receive from its TCP pe

Current size of a memory buffer on the host sending this TCP segment to store i

A simple mathematical calculation that is used to check for bit-level errors in the

Table 2-8 Key fields in the TCP header

TCP Ports
To use TCP, an application must supply the IP address and TCP port number of the source and destination applications. A port provides a location for sending segments. A unique number identifies each port. TCP ports are distinct and separate from UDP ports even though some of them use the same number. Port numbers below 1024 are well-known ports that the Internet Assigned Numbers Authority (IANA) assigns. Table 2-9 lists a few well-known TCP ports. TCP Port Number 20 21 23 80 139 Table 2-9 Well-known TCP Ports For a complete list of assigned TCP ports, see http://www.iana.org/assignments/portDescription FTP (data channel) FTP (control channel) Telnet HTTP used for the World Wide Web NetBIOS session service

numbers.

TCP Three-Way Handshake

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 to exchange TCP window sizes. The following steps outline the process for the common situation when a client computer contacts a server computer: 1. The 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 server sends back a TCP segment containing its chosen initial sequence number, an acknowledgment of the clients sequence number, and a window size indicating the size of a buffer on the server to store incoming segments from the client. 3. The client sends a TCP segment to the server containing an acknowledgment of the servers 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.

Top of page

User Datagram Protocol (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 retransmit lost data. UDP messages consist of a UDP header and a UDP payload, also known as a message. RFC 768 defines UDP. Applications use UDP if they do not require an acknowledgment of receipt of data, and they 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. Table 2-10 lists and describes the key fields in the UDP header. Field Source Port Destination Port Checksum Description UDP port of sending application. UDP port of destination application.

A simple mathematical calculation that is used to check for bit-level errors in the UDP me

Table 2-10 Key Fields in the UDP Header

UDP Ports
To use UDP, an application must supply the IP address and UDP port number of the source and destination applications. A port provides a location for sending messages. A unique number identifies each port. UDP ports are distinct and separate from TCP ports even though some of them use the same number. Just like TCP ports, UDP port numbers below 1024 are well-known ports that IANA assigns. Table 2-11 lists a few well-known UDP ports. UDP Port Number 53 69 137 138 161 Table 2-11 Well-known UDP ports For a complete list of assigned UDP ports, see http://www.iana.org/assignments/portDescription Domain Name System (DNS) name queries Trivial File Transfer Protocol (TFTP) NetBIOS name service NetBIOS datagram service SNMP

numbers. Top of page

Packet Multiplexing and Demultiplexing

When a sending host sends an IPv4 or IPv6 packet, it includes information in the packet so that the data within the packet can be delivered to the correct application on the destination. The inclusion of identifiers so that data can be delivered to one of multiple entities in each layer of a layered architecture is known as multiplexing. Multiplexing information for IP packets consists of identifying the node on the network, the IP upper layer protocol, and for TCP and UDP, the port corresponding to the application to which the data is destined. The destination host uses these identifiers to

demultiplex, or deliver the data layer by layer, to the correct destination application. The IP packet also includes information for the destination host to send a response. IP contains multiplexing information to do the following: Identify the sending node (the Source IP Address field in the IPv4 header or the Source Address field in the IPv6 header). Identify the destination node (the Destination IP Address field in the IPv4 header or the Destination Address in the IPv6 header). Identify the upper layer protocol above the IPv4 or IPv6 Internet layer (the Protocol field in the IPv4 header or the Next Header field of the IPv6 header). For TCP segments and UDP messages, identify the application from which the message was sent (the Source Port in the TCP or UDP header). For TCP segments and UDP messages, identify the application to which the message is destined (the Destination Port in the TCP or UDP header). TCP and UDP ports can use any number between 0 and 65,535. Port numbers for client-side applications are typically dynamically assigned when there is a request for service, and IANA preassigns port numbers for well-known server-side applications. The complete list of pre-assigned port numbers is listed onhttp://www.iana.org/assignments/port-numbers. All of this information is used to provide multiplexing information so that: The packet can be forwarded to the correct destination. The destination can use the packet payload to deliver the data to the correct application. The receiving application can send a response. When a packet is sent, this information is used in the following ways: The routers that forward IPv4 or IPv6 packets use the Destination IP Address field in the IPv4 header or the Destination Address in the IPv6 header to deliver the packet to the correct node on the network. The destination node uses the Protocol field in the IPv4 header or the Next Header field of the IPv6 header to deliver the packet payload to the correct upper-layer protocol. For TCP segments and UDP messages, the destination node uses the Destination Port field in the TCP or UDP header to demultiplex the data within the TCP segment or UDP message to the correct application. Figure 2-5 shows an example of a DNS Name Query Request message in an IPv4 packet with a destination IP address of 131.107.89.223 being demultiplexed to the DNS service.

Figure 2-5 Example of IPv4 packet demultiplexing

Top of page

Application Programming Interfaces

Windows networking applications use two main application programming interfaces (APIs) to access TCP/IP services in Windows: Windows Sockets and NetBIOS. Figure 2-6 shows these APIs and the possible data flows when using them.

Figure 2-6 Architecture of the Windows Sockets and NetBIOS APIs Some architectural differences between the Windows Sockets and NetBIOS APIs are the following: NetBIOS over TCP/IP (NetBT) is defined for operation over IPv4. Windows Sockets operates over both IPv4 and IPv6. Windows Sockets applications can operate directly over the IPv4 or IPv6 Internet layers, without the use of TCP or UDP. NetBIOS operates over TCP and UDP only.

Windows Sockets
Windows Sockets is a commonly used, modern API for networking applications in Windows. The TCP/IP services and tools supplied with Windows are examples of Windows Sockets applications. Windows Sockets provides services that allow applications to use a specific IP address and port, initiate and accept a connection to a specific destination IP address and port, send and receive data, and close a connection. There are three types of sockets: A stream socket, which provides a two-way, reliable, sequenced, and unduplicated flow of data using TCP. A datagram socket, which provides bidirectional flow of data using UDP. A raw socket, which allows protocols to access IP directly, without using TCP or UDP. A socket functions as an endpoint for network communication. An application creates a stream or datagram socket by specifying three items: the IP address of the host, the type of service (TCP for connection-based service and UDP for connectionless), and the port the application is using. Two sockets, one for each end of the connection, form a bidirectional communications path. For raw sockets, the application must specify the entire IP payload.

NetBIOS
NetBIOS is an older API that provides name management, datagram, and session services to NetBIOS applications. An application program that uses the NetBIOS interface API for network communication can be run on any protocol implementation that supports the NetBIOS interface. Examples of Windows applications and services that use NetBIOS are file and printer sharing and the Computer Browser service. NetBIOS also defines a protocol that functions at the OSI Session layer. This layer is implemented by the underlying protocol implementation, such as NetBIOS over TCP/IP (NetBT), which RFCs 1001 and

1002 define. The NetBIOS name service uses UDP port 137. The NetBIOS datagram service uses UDP port 138. The NetBIOS session service uses TCP port 139. For more information about NetBIOS and NetBT, see Chapter 11, "NetBIOS

over TCP/IP."

Top of page

TCP/IP Naming Schemes in Windows

Although IP is designed to work with the 32-bit (IPv4) and 128-bit (IPv6) addresses of sending and destination hosts, computers users are much better at using and remembering names than IP addresses. If a name is used as an alias for an IP address, mechanisms must exist for assigning names to IP addresses, ensuring their uniqueness, and for resolving the name to its IP address. TCP/IP components of Windows use separate mechanisms for assigning and resolving host names (used by Windows Sockets applications) and NetBIOS names (used by NetBIOS applications).

Host Names
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. Windows Sockets applications, such as Internet Explorer and the Ping tool, can use one of two values to refer to the destination: the IP address or a host name. When the user specifies an IP address, name resolution is not needed. When the user specifies a host name, the host name must be resolved to an IP address before IP-based communication with the target resource can begin. Host names can take various forms. The two most common forms are a nickname and a fully qualified domain name (FQDN). A nickname is an alias to an IP address that individual people can assign and use. An FQDN is a structured name, such as www.microsoft.com, that follows the Internet conventions used in DNS. For information about how TCP/IP components in Windows resolve host names, see Chapter 7, Host

Name Resolution. For more information about DNS, see Chapter 8, Domain Name System Overview.

NetBIOS Names
A NetBIOS name is a 16-byte name that identifies a NetBIOS application on the network. A NetBIOS name is either a unique (exclusive) or group (nonexclusive) name. When a NetBIOS application communicates with a specific NetBIOS application on a specific computer, a unique name is used. When a NetBIOS process communicates with multiple NetBIOS applications on multiple computers, a group name is used. The NetBIOS name identifies applications at the Session layer of the OSI model. For example, the NetBIOS Session service operates over TCP port 139. Because all NetBT session requests are addressed to TCP destination port 139, a NetBIOS application must use the destination NetBIOS name when it establishes a NetBIOS session. An example of a process using a NetBIOS name is the file and print sharing server service on a Windowsbased computer. When your computer starts up, the server service registers a unique NetBIOS name based on your computers name. The exact name used by the server service is the 15 character computer name plus a 16th 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 also use the computer name to build their NetBIOS names, and the 16th character is typically used to identify each service. When you attempt to make a file-sharing connection to a computer running Windows Server 2003 or Windows XP by specifying the computers name, the Server service on the file server that 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. For a TCP connection to be created, the NetBIOS

name CORPSERVER <20> must be resolved to an IPv4 address. NetBIOS name resolution is the process of mapping a NetBIOS name to an IPv4 address. For more information about NetBT and NetBIOS name resolution methods, see Chapter 11, NetBIOS

over TCP/IP. Top of page

Chapter Summary
The key information in this chapter is the following: The TCP/IP protocol suite maps to the four layers of the DARPA model: Application, Transport, Internet, and Network Interface. The protocols of the IPv4 Internet layer consist of ARP, IP (IPv4), ICMP, and IGMP. The protocols of the IPv6 Internet layer consist of IPv6, ICMPv6, ND, and MLD. The protocols of the Transport layer include TCP and UDP. TCP is a reliable, connectionoriented delivery service. UDP provides a connectionless datagram service that offers unreliable, best-effort delivery of data transmitted in messages. IP packets are multiplexed and demultiplexed between applications based on fields in the IPv4, IPv6, TCP, and UDP headers. TCP/IP components in Windows support two main APIs for networking applications: Windows Sockets and NetBIOS. Windows Sockets is a modern API that allows applications to manage stream sockets, datagram sockets, and raw sockets. NetBIOS is an older API that allows applications to manage NetBIOS names, datagrams, and sessions. TCP/IP components in Windows support two naming schemes for networking applications: host names (used by Windows Sockets applications) and NetBIOS names (used by NetBIOS applications).

Top of page

Chapter Glossary
address autoconfiguration The IPv6 ND process of automatically configuring IPv6 addresses on an interface. address resolution The IPv4 (using ARP) or IPv6 (using ND) process that resolves the MAC address for a next-hop IP address. Address Resolution Protocol (ARP) A protocol that uses broadcast traffic on the local network to resolve an IPv4 address to its MAC address. ARP See Address Resolution Protocol. ARP cache A table for each interface of static or dynamically resolved IPv4 addresses and their corresponding MAC addresses. ICMP See Internet Control Message Protocol. ICMPv6 Internet Control Message Protocol for IPv6. IGMP See Internet Group Management Protocol. Internet Control Message Protocol (ICMP) A protocol in the IPv4 Internet layer that reports errors and provides troubleshooting facilities. Internet Control Message Protocol for IPv6 (ICMPv6) A protocol in the IPv6 Internet layer that reports errors, provides troubleshooting facilities, and hosts ND and MLD messages. Internet Group Management Protocol (IGMP) A protocol in the IPv4 Internet layer that manages multicast group membership on a subnet. Internet Protocol (IP) For IPv4, a routable protocol in the IPv4 Internet layer that addresses, routes, fragments, and reassembles IPv4 packets. Also used to denote both IPv4 and IPv6 sets of protocols. IP See Internet Protocol. IPv4 The Internet layer in widespread use on the Internet and on private intranets. Another term for IP. IPv6 The new Internet layer that will eventually replace the IPv4 Internet layer.

MLD See Multicast Listener Discovery. Multicast Listener Discovery (MLD) A set of three ICMPv6 messages that hosts and routers use to manage multicast group membership on a subnet. name resolution The process of resolving a name to an address. ND See Neighbor Discovery. neighbor cache A cache maintained by every IPv6 node that stores the IPv6 address of a neighbor and its corresponding MAC address. The neighbor cache is equivalent to the ARP cache in IPv4. Neighbor Discovery (ND) A set of ICMPv6 messages and processes that determine relationships between neighboring nodes. Neighbor Discovery replaces ARP, ICMP router discovery, and the ICMP Redirect message used in IPv4. Network Basic Input/Output System (NetBIOS) A standard API for user applications to manage NetBIOS names and access NetBIOS datagram and session services. NetBIOS See Network Basic Input/Output System. router discovery A Neighbor Discovery process in which a host discovers the local routers on an attached subnet. TCP See Transmission Control Protocol. Transmission Control Protocol (TCP) A reliable, connection-oriented Transport layer protocol that runs on top of IP. UDP See User Datagram Protocol User Datagram Protocol (UDP) An unreliable, connectionless Transport layer protocol that runs on top of IP. Windows Sockets A commonly used application programming interface (API) that Windows applications use to transfer data using TCP/IP.