Cover

Copyright © 2003 by Microsoft Corporation


LOC

PUBLISHED BY
Microsoft Press
A Division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399

Copyright © 2003 by Microsoft Corporation

All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher.

Library of Congress Cataloging-in-Publication Data pending

Printed and bound in the United States of America.

1 2 3 4 5 6 7 8 9 QWE 8 7 6 5 4 3

Distributed in Canada by H.B. Fenn and Company Ltd.

A CIP catalogue record for this book is available from the British Library.

Microsoft Press books are available through booksellers and distributors worldwide. For further information about international editions, contact your local Microsoft Corporation office or contact Microsoft Press International directly at fax (425) 936-7329. Visit our Web site at www.microsoft.com/mspress. Send comments to mspinput@microsoft.com.

Active Directory, Microsoft, Microsoft Press, Outlook, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.

The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

Acquisitions Editors: Juliana Aldous Atkinson, Jeff Koch
Project Editor: Maureen Williams Zimmerman


Introduction

The Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite is the foundation of today's Internet and the foundation of many private computer networks. The TCP/IP protocol suite, which comprises more than just TCP and IP, enables computers within a network to communicate with each other.

TCP/IP was originally developed to enable ARPANET sites to communicate. ARPANET sites used different computers manufactured by different vendors, running different operating systems. The only common element between them was that they ran a common protocol.

As the ARPANET became the Internet, many companies began to use TCP/IP. With Microsoft Windows 2000, the Active Directory service requires TCP/IP.

This overview provides a brief introduction to the TCP/IP protocol suite, including the following:

  • A history of the TCP/IP protocol suite
  • A look at the Open Systems Interconnection (OSI) model and a comparison to the model that TCP/IP uses
  • An overview of the Microsoft Windows Server 2003 network architecture, illustrating how TCP/IP is implemented

This overview also serves as a foundation for this book.


Brief History of TCP/IP

In the mid to late 1960s, the U.S. Department of Defense's (DOD's) Advanced Research and Projects Administration (ARPA, or DARPA, as it later became known) began researching the creation of a network that would link up various ARPA contractors. They issued a contract to build the first Interface Message Processors (IMP) to Bolt, Baranek, and Newman (BBN), a consulting firm in Cambridge, Massachusetts. The IMP, which today probably would be called a router, was based on a Honeywell 516 minicomputer and was a system the size of a large refrigerator.

In the days of the first IMPs, there were no protocols to purchase—everything had to be designed from scratch. The concept of packet-switching-based networks wasn't new, but there were no significant implementations that ARPA or BBN could go out and buy.

The first IMP was delivered toward the end of the summer of 1969 at UCLA; the second IMP was delivered to Stanford Research Institute a month later. More IMPs were added over the coming months and years, and the ARPANET slowly became a reality.

During the 1970s, the number of sites connected to the ARPANET grew, initially, at a linear rate (one per month or so), but toward the end of the 1970s, the growth became exponential.

The initial protocols and addressing schemes that were used within the ARPANET were adequate to connect the first IMPs, and to prove that the concept of a heterogeneous packet-switching network was valid, but they didn't scale. Something better was needed, and in the late 1970s the development of what we now know as TCP/IP began to see the light of day. RFC 760, which described the Internet Protocol, was published on January 1, 1980. It was subsequently replaced by RFC 791, which was published in September 1981, along with an RFC describing TCP (RFC 793). RFC 768, describing User Datagram Protocol (UDP), had been issued the year before.

These RFCs define the core of the TCP/IP protocol suite and are still in use today. Although some of the details have changed, and some additional functionality has been added, such as flow control with TCP, these protocols have withstood the test of time and continue to serve their purpose. IP's addressing scheme, based on a 32-bit IP address, has proven inadequate for today's Internet, but no one in the 1970s could have foreseen what the Internet has become today.

Perhaps the biggest boost to the adoption of TCP/IP was the publication of the BSD 4.2 version of UNIX in 1983, which incorporated a TCP/IP suite. UNIX, which Bell Laboratories developed, had been viewed as a possible ARPA minihost, as noted in RFC 681. It was attractive for many reasons, not the least of which was that Bell licensed the operating system for a nominal fee, $150 for colleges and universities (although for "nonuniversity" institutions the license fee was $20,000). With the release of BSD 4.2, many universities could now afford additional minicomputers and the software to run on them. The result was an explosive growth in the use of the ARPANET and in the development of many of the tools and facilities we now take for granted, such as the Domain Name System (DNS).


The ISO OSI Model

The development of ARPANET was undertaken in an academic setting. At that time, it didn't capture much commercial interest. During the 1970s, the need for more open networking was a hot topic of conversation in the computer industry. Because networking was largely homogenous, computers from different manufacturers generally couldn't communicate.

In 1977, the International Organization for Standardization (ISO) began the development of a detailed reference model for OSI. The idea behind the OSI model was to enable the development of software that would allow an open system for the purpose of information exchange with another. The assumption was that an open system would use the applicable standards and therefore be able to interoperate.

The OSI model is a very loose standard in which the definitions and much of the terminology are vague. This was deliberate to ensure that the model didn't attempt to constrain an implementer to use existing techniques or terminology. Rather, it was intended to promote the development of protocols that could provide heterogeneous systems to interoperate. The OSI model also functions as a reference model, to enable other standards and protocols to be compared.

The OSI model starts from the premise that communication between two computers is sufficiently complex enough that it couldn't be considered as a single entity. Instead, the functions that make up the communications process should be broken up into a series of separate layers, with each successive layer built on top of a lower layer, and using the functions assigned to each layer. What the precise internal workings of the layers would be, however, was a detail left to developers—the key was to standardize the functions contained in each of the layers and the interfaces between them.

The ISO OSI model is made up of seven layers, as shown in Figure I-1.

Figure I-1. The seven layers of the ISO OSI model.

In this model, the application and the users are at the top, and physical communications media are at the bottom. The functions of the layers, in ascending order, are as follows:

  • Physical Puts a stream of bits on the physical media, the wire, and pulls them back off. This layer is typically implemented in hardware.
  • Data Link Defines the concept of a packet (a frame) and enables a computer to send a frame to another computer connected to the same wire. This layer is typically implemented in a mixture of hardware and system software.
  • Network Enables two end systems to send packets of data across an internetwork based on the lower levels. This layer, implemented in software, is inherently unreliable because a frame being sent out across a network might get lost, be badly routed, or become corrupted. The higher layers are responsible for reliability.
  • Transport Enables the reliable transmission of data across the network provided. It utilizes the end-to-end communication provided by the network layer and adds reliability.
  • Session Adds in the concept of sessions between two systems where the computers in the session will save information about the state of the session and later use that state information as the basis for future processing.
  • Presentation Meant for the translation of data between different formats as needed (for example, between ASCII and EBCIDC), thus separating the wire formats from the view of data seen by an application.
  • Application Where the applications and users reside. These applications use the other six layers to implement a business function based on the underlying network.

The designers of the OSI model had hoped that vendors would build protocols that mapped directly to this model. However, with seven layers, this model added a considerable overhead. Functions at each level needed to make procedure calls to lower levels, which involved a higher level layer packing up parameters and making a procedure call to the lower level, which would then need to validate those parameters. A few implementations were developed, but these implementations didn't achieve a significant commercial success.


The DARPA Model

The designers of the TCP/IP suite of protocols chose a simpler model with fewer layers to improve performance and ease of implementation. This model, known as the DARPA model, is simpler than the ISO model, having only four layers. The DARPA model is shown in Figure I-2, which also shows the correspondence between the two models.

Figure I-2. Comparing the DARPA model to the ISO model.

The four layers of the DARPA model are broadly compatible with the ISO model, although the mapping is not perfectly clean. The ISO Session layer, for example, doesn't perfectly map onto the DARPA model. In addition, some protocols break the model. Asynchronous Transfer Mode (ATM), for example, is a connection-oriented protocol effectively implemented in the hardware. Nevertheless, these models are still very useful because they enable the complex tasks involved with computer networking to be broken down into pieces that are more manageable.

In this book, we use both the OSI and DARPA models when discussing the TCP/IP protocol suite and associated services.


Windows Server 2003 Network Architecture Overview

One of the unique features of Microsoft Windows NT 3.1, when it was first released, was that it was supplied with a full suite of networking protocols. These came "in the box" and there was no need to buy and add extra software to enable a Windows NT system to interoperate with other Windows computers on a corporate network. These networking protocols have matured and been improved as Windows NT evolved to become Windows Server 2003, but the basic design has remained broadly the same.

A key characteristic of Windows Server 2003 networking is that it provides administrators with the ability to fully integrate third-party components. Additionally, the designers built the networking components to enable users to view and work with remote and local files in similar ways. Figure I-3 shows a high-level overview of the Windows Server 2003 (and Microsoft Windows XP) networking architecture.

Figure I-3. Windows Server 2003 network architecture.

As with all the other components of Windows Server 2003, the networking architecture is layered, which allows third-party vendors to add in different components. Microsoft provides the Transport Driver Interface (TDI) and Network Device Interface Specification (NDIS) layers, which third-party vendors can use to provide new network adapter drivers; new transport protocols; and new network providers, redirectors, and servers.

At the bottom of the network architecture diagram reside the network devices and device drivers. This includes both connectionless adapter types, such as Ethernet and Token Ring; wide area network (WAN) drivers for support of WAN protocols, such as Frame Relay and X.25; and connection-oriented adapters, such as ATM.

The NDIS interface serves as a dividing line between the transport protocols and the network hardware and drivers. This interface allows the transport protocols to use virtually any network device driver.

The transport protocols include the core of the TCP/IP protocol suite as well as NWLink (Microsoft's implementation of Internetwork Packet Exchange/Sequenced Packet Exchange [IPX/SPX]) and AppleTalk.

TDI, which sits above the transport protocols, provides an interface into the transport protocols for kernel mode components, such as the redirectors and servers.

At the top of this model, you will find the network infrastructure services such as Dynamic Host Configuration Protocol (DHCP), DNS, and Windows Internet Name Service (WINS), and network-aware applications such as Internet Information Services (IIS).


About This Book

This book is a straightforward, no-nonsense discussion of the concepts, principles, and processes of many protocols in the TCP/IP protocol suite and how they are supported by Windows XP and the Windows Server 2003 family of operating systems. It is primarily a discussion of protocols (what you might see on the wire during communication) and processes (how things work under the covers), rather than a discussion of planning, configuration, deployment, management, or application development. For a discussion of TCP/IP planning, configuration, deployment, and management, please see the Help and Support Center for the Windows Server 2003 family and the Windows Server 2003 Resource Kits. For a discussion of TCP/IP application development using Windows Sockets, see the Microsoft Developer Network at http://msdn.microsoft.com.

The bulk of the content of this book is about TCP/IP protocols, rather than the internal specifics of the implementation for Windows Server 2003. For example, this book does not contain in-depth internal details of the Microsoft implementation of TCP/IP in Windows XP or Windows Server 2003, such as internal structures, tables, buffers and their use, or coding logic. These details are only of interest to a relative handful of readers and are not published for security reasons and to protect Microsoft intellectual property. However, this book does contain details of how the Microsoft implementation of TCP/IP in Windows XP and Windows Server 2003 works for described TCP/IP processes and how to modify default behaviors with registry settings.

The purpose of this book is to both provide an educational vehicle to learn TCP/IP to a fair amount of technical depth and serve as a detailed technical reference. This book is not intended to be a TCP/IP or networking technology primer.

Who Should Read This Book

This book is intended for the following audiences:

  • Windows XP and Windows Server 2003 networking consultants and planners This includes anyone who will be planning for or deploying a network containing computers running Windows XP or Windows Server 2003.
  • Windows network administrators This includes anyone who is currently managing a Windows network and wants to gain additional technical knowledge about TCP/IP and its implementation for Windows XP and Windows Server 2003.
  • Microsoft Certified Systems Engineers (MCSEs) and Microsoft Certified Trainers (MCTs) This book can be a standard reference for MCSEs and MCTs for the TCP/IP protocol suite.
  • General technical staff Because this book is mostly about TCP/IP protocols and processes, independent of its implementation in Windows XP and Windows Server 2003, general technical staff can use this book as an in-depth reference on TCP/IP protocols.
  • Information technology (IT) students This book, using the training slides included on the companion CD-ROM, serves as an excellent textbook for a comprehensive TCP/IP course taught at an educational institution or inside your organization.

What Should You Know Before Reading This Book

This book assumes a foundation of networking knowledge that includes basic networking concepts and widely used networking technologies. For example, although we explain in detail how IP packets are encapsulated when sent over an Ethernet network segment, we do not explain the history of Ethernet or its technical details, such as signal encoding, cabling, topologies, or configuration options. This knowledge is assumed.

For basic networking concepts and technologies, consult a resource such as MCSE Training Kit: Networking Essentials Plus, Third Edition (Redmond, Wash.: Microsoft Press; ISBN 157231902X).

Organization of This Book

We have divided the book into four parts, corresponding to the four layers of the DARPA model:

  • The Network Interface Layer This part contains two chapters describing the local area network (LAN) and WAN technologies supported by Windows Server 2003 and, in particular, how they encapsulate IP datagrams. This section also includes a chapter describing Address Resolution Protocol (ARP), a simple protocol that resolves the hardware address (typically a media access control [MAC] address) for a specific next-hop IP address. This section also includes a chapter describing the Point-to-Point Protocol (PPP) suite of protocols, which provide encapsulation, link negotiation, and protocol configuration services for point-to-point links.
  • Internet Layer Protocols This part includes chapters describing IP (basic concepts and packet structure, addressing, and routing), Internet Control Message Protocol (ICMP), and Internet Group Management Protocol (IGMP). There is also a chapter on IP version 6 (IPv6), included specifically to provide an overview and to describe how it compares with IPv4, the current version of IP used on the Internet and described in detail in this book. For more information about IPv6 and its implementation in Windows XP and Windows Server 2003, see the book Understanding IPv6 by Joseph Davies (Redmond, Wash.: Microsoft Press, 2003; ISBN 0735612455).
  • Transport Layer Protocols This part contains chapters describing UDP, a simple Transport Layer protocol for sending unreliable messages, and Transmission Control Protocol (TCP), a complex Transport Layer protocol for sending reliable segments.
  • Application Layer Protocols and Services This part contains chapters describing key TCP/IP-related infrastructure services, including DHCP, DNS, and WINS. This part also includes chapters on file and printer sharing, Remote Authentication Dial-In User Service (RADIUS), IIS, Internet Protocol Security (IPSec), and virtual private networks (VPNs).

Network Monitor Traces

Throughout this book, we have illustrated the theory with packet captures. These show the actual behavior of a protocol or service as seen "on the wire." To improve the value of this book to you, we have included all of the traces referenced in this book on the companion CD-ROM.

The traces taken in the book were captured using Microsoft Network Monitor Version 2.0, which is a component of Systems Management Server version 2.0, and the Windows 2000 Server family. For readers who do not have access to Network Monitor, we also include a text version of each trace. The display of the trace in the book text and the text version of the capture file were done with Version 2.0 of Network Monitor.

Windows Server 2003 provides Network Monitor version 2.1. There are differences in the way that the frame structure is displayed between version 2.0 and 2.1.

About the Companion CD-ROM

The companion CD-ROM included with this book contains the following:

  • Electronic version of this book (eBook) A Hypertext Markup Language (HTML) Help version of the book allows you to view it online and perform text searches. HTML Help is the same format that is used for online Help in Windows 2000, Windows XP, and Windows Server 2003.
  • Microsoft Internet Explorer 6.0 Internet Explorer 6.0 version is included to ensure that you can view the electronic version of this book.
  • Network Monitor captures The Network Monitor capture files for all the captures mentioned in the book are included, as well as text (*.txt) versions if you do not have access to Network Monitor. Different versions of Network Monitor might display packet structure differently.
  • RFCs and Internet drafts The set of Internet Engineering Task Force (IETF) RFCs and Internet drafts as of the publication of this book are stored in separate folders (an \Rfc folder for the RFCs and an \Ietf Drafts folder for the Internet drafts).
  • Microsoft TCP/IP white papers The set of TCP/IP-related white papers posted on the Microsoft Web site (http://www.microsoft.com/) at the time of the publication of this book in both Microsoft Word and Adobe Acrobat format is stored in the \White_Papers folder. To obtain the Adobe Acrobat viewer, see http://www.adobe.com.
  • Microsoft Word and Microsoft PowerPoint viewers The Microsoft Word Viewer is contained in the \Viewers\WordViewer folder. To install the Microsoft Word viewer, run Wdview97.exe from the \Viewers\WordViewer folder. The Microsoft PowerPoint viewer is contained in the \Viewers \PP_Viewer folder. To install the Microsoft PowerPoint viewer, run Ppview.exe from the \Viewer\ PP_Viewer folder.

    If you already have Word, PowerPoint, or the Adobe viewer installer, you do not need to install these viewers.

  • Training slides The \TrainingSlides folder contains a set of Microsoft PowerPoint files that can be used to teach TCP/IP with this book. For more information, see "A Special Note to Teachers and Instructors."

Disclaimer: Third-Party Sites

For the user's convenience, this CD includes links to third-party sites. Please note that these products and links are not under the control of Microsoft Corporation and Microsoft is not responsible for their content, nor should their inclusion on the CD be construed as an endorsement of the product or the site. Please check third-party Web sites for the latest version of their software.

System Requirements

For detailed system requirements, see "System Requirements" at the back of this book.

A Special Note to Teachers and Instructors

If you are a teacher or instructor whose task it is to inculcate an understanding of the TCP/IP protocol suite in others, we strongly urge you to consider using this book and its slides as a basis for your own TCP/IP course. Obviously, it can be used for courses that supplement TCP/IP knowledge for Windows network administrators and systems engineers. However, because the content is mostly about the details of TCP/IP protocol suite packet structure and protocol processes, this book can also be used for an implementation-independent TCP/IP course.

The slides are included to provide a foundation for your own slide presentation, and contain either bulleted text or drawings that are synchronized with their chapter content. Because the slides were completed after the final book pages were done, there are some minor differences between the slides and the chapter content. These changes were made to enhance the ability to teach a TCP/IP course based on this book.

The template we have chosen for the included slides is intentionally simple so that there are minimal issues with text and drawing color translations when you switch to a different template. Please feel free to customize the slides as you see fit.

As fellow instructors, we wish you success in your efforts to teach this interesting and important technology to others.

What Is New in This Edition

Although not indicated by its title, this book is the second edition of Microsoft Windows 2000 TCP/IP Protocols and Services Technical Reference by Thomas Lee and Joseph Davies. The following are the changes from the first edition:

  • Chapter 1: Local Area Network (LAN) Technologies Now includes coverage of the IEEE 802.11 frame format
  • Chapter 4: Point-to-Point Protocol (PPP) A new chapter that describes the PPP protocol suite, the details of establishing a PPP connection, and PPP over Ethernet (PPPoE)
  • Chapter 5: Internet Protocol (IP) Basics Now includes a discussion of the definition of the IP Type of Service (TOS) field given in RFC 2874
  • Chapter 7: Internet Protocol (IP) Routing Now includes a section with examples of the route determination process for a Windows Server 2003 IP routing table
  • Chapter 9: Internet Group Management Protocol (IGMP) Now includes information about IGMP version 3 (IGMPv3)
  • Chapter 10: Internet Protocol Version 6 (IPv6) Rewritten to provide only a summary of the problems addressed by IPv6, IPv6 addressing, and the core protocols of IPv6
  • Chapter 17: Domain Name System (DNS) Now includes additional sections describing the delegation of domains, DNS extensions, and DNS security
  • Chapter 19: File and Printer Sharing Now includes additional information about the Common Internet File System (CIFS)
  • Chapter 20: RADIUS and Internet Authentication Service A new chapter that describes the Remote Authentication Dial-In User Service (RADIUS) protocol and Internet Authentication Service, a RADIUS server and proxy
  • Chapter 21: Internet Information Services (IIS) and the Internet Protocols Now includes additional information about HTTP and new information about the Network News Transfer Protocol (NNTP)
  • Chapter 22: Internet Protocol Security (IPSec) Rewritten to include the Internet Security Association Key Management Protocol (ISAKMP) messages and payloads, details about main mode and quick mode negotiation, and information about IPSec NAT Traversal (IPSec NAT-T)
  • Chapter 23: Virtual Private Networks (VPNs) Now includes detailed information about the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol (L2TP) including data encapsulation and connection establishment, maintenance, and termination

The chapters not mentioned were updated for new features, behaviors, and settings in Windows Server 2003.

Support

This book represents a best-effort snapshot of information at the time of its publication for the implementation of many protocols in the TCP/IP suite provided in the Windows Server 2003 family, as of the builds of Windows Server 2003 that were available inside Microsoft on November 15, 2002. Changes to IETF standards and Windows Server 2003 that were made after November 15, 2002 are not reflected in this book.

To obtain the latest information about IETF standards for TCP/IP, see the IETF Web site at http://www.ietf.org/.

Every effort has been made to ensure the accuracy of this book and the contents of the companion CD-ROM. Microsoft Press provides corrections for books at http://www.microsoft.com/mspress/support/. To connect directly to the Microsoft Press Knowledge Base and enter a query regarding a question or issue that you might have, visit http://www.microsoft.com/mspress/support/search.asp, type 0-7356-1291-9 in the search box, and then click Go.

If you have comments, questions, or ideas regarding this book or the companion CD-ROM, please send them to Microsoft Press using either postal mail or e-mail. The postal mail address is:

Microsoft Press
Attn: Microsoft Windows Server 2003 TCP/IP Protocols and Services Technical
Reference Editor
One Microsoft Way
Redmond, WA 98052-6399

The e-mail address is:

MSPInput@microsoft.com.

Please note that product support is not offered through these addresses. For Windows product support information, please visit the Microsoft Product Standard Support Web site at http://support.microsoft.com/default.aspx .


Local Area Network (LAN) Technologies

Part I
The Network Interface Layer
Chapter 1
Local Area Network (LAN) Technologies

To successfully troubleshoot Transmission Control Protocol/Internet Protocol (TCP/IP) problems on a local area network (LAN), it is important to understand how IP datagrams and Address Resolution Protocol (ARP) messages are encapsulated when sent by a computer running a member of the Microsoft Windows Server 2003 family or Windows XP on LAN technology links such as Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), and Institute of Electrical and Electronics Engineers (IEEE) 802.11. For example, IP datagrams sent over an Ethernet network segment can be encapsulated two different ways. If two hosts are not using the same encapsulation, communication cannot occur. It is also important to understand LAN technology encapsulations to correctly interpret the Ethernet, Token Ring, and FDDI portions of the frame when using Microsoft Network Monitor.


LAN Encapsulations

Because IP datagrams are an Open Systems Interconnection (OSI) Network Layer entity, IP datagrams must be encapsulated with a Data Link Layer header and trailer before being sent on the physical medium. The Data Link Layer header and trailer provide the following services:

  • Delimitation Frames at the Data Link Layer must be distinguished from each other. For each frame, the start and end of the frame are indicated and the frame's payload is distinguished from the Data Link Layer header and trailer.
  • Protocol identification Because many organizations use multiple protocol suites such as TCP/IP, Internetwork Packet Exchange (IPX), or AppleTalk, the protocols must be distinguished from each other.
  • Addressing For shared-access LAN technologies such as Ethernet, the source node and destination node must be identified.
  • Bit-level integrity check To detect bit-level errors in the entire frame received by the hardware, a bit-level integrity check in the form of a checksum is needed. The checksum is computed by the source node and included in the frame header or trailer. The destination recalculates the checksum and checks it against the included checksum. If the checksums match, the frame is considered free of bit-level errors. If the checksums do not match, the frame is silently discarded. This frame checksum is in addition to the checksums provided by upper layer protocols such as IP or TCP.

The particular way a network type (such as Ethernet or Token Ring) encapsulates data to be transmitted is called a frame format. The frame format corresponds to the information placed on the frame at the Logical Link Control (LLC) and Media Access Control (MAC) sublayers of the OSI Data Link Layer, and the frame format manifests itself as a header and trailer. If multiple frame formats exist for a given network type (such as Ethernet), the frame formats represent different header and trailer structures and are therefore incompatible with each other. In other words, all the nodes on the same network segment (bounded by routers) must use the same frame format to communicate.

This chapter is a discussion of Ethernet, Token Ring, FDDI, and IEEE 802.11 LAN technologies and their frame formats for IP datagrams and ARP messages. ARCnet is not discussed, as it is not a widely used networking technology.


Ethernet

Ethernet evolved from a 9.6 kilobit-per-second (Kbps) radio transmission system developed at the University of Hawaii called ALOHA. A key feature of ALOHA was that all transmitters shared the same channel and contended for access to the channel to transmit. This became the basis for the contention-based Ethernet that we know today.

In 1972, the Xerox Corporation created a 2.94-megabit-per-second (Mbps) network based on the principles of the ALOHA system. This new network, called Ethernet, featured carrier sense, in which the transmitter listens before attempting to transmit. In 1979, Digital, Intel, and Xerox (DIX) created an industry standard 10-Mbps Ethernet known as Ethernet II. In 1981, the IEEE Project 802 formed the 802.3 subcommittee to make 10-Mbps Ethernet an international standard. In 1995, the IEEE approved a 100-Mbps version of Ethernet called Fast Ethernet.

Ethernet existed before the IEEE 802.3 specification and, because there are multiple Ethernet standards, there are multiple ways of encapsulating data to be transmitted on an Ether-net network. This can be very confusing when two hosts on an Ethernet network segment cannot communicate, even though they are using the correct communication protocol (such as TCP/IP) and Application Layer protocol (such as File Transfer Protocol [FTP]).

IP datagrams and ARP messages sent on an Ethernet network segment use either Ethernet II encapsulation (described in RFC 894) or IEEE 802.3 Sub-Network Access Protocol (SNAP) encapsulation (described in RFC 1042). These RFCs are included in the \Rfc folder on the companion CD-ROM.

Ethernet II

The Ethernet II frame format was defined by the Ethernet specification created by Digital, Intel, and Xerox before the IEEE 802.3 specification. The Ethernet II frame format is also known as the DIX frame format. Figure 1-1 shows Ethernet II encapsulation for an IP datagram.

Figure 1-1. The Ethernet II frame format showing the Ethernet II header and trailer.

Ethernet II Header and Trailer

The fields in the Ethernet II header and trailer are defined as follows:

  • Preamble The Preamble field is 8 bytes long and consists of 7 bytes of alternating 1s and 0s (each byte is the bit sequence 10101010) to synchronize a receiving station and a 1-byte 10101011 sequence that indicates the start of a frame. The Preamble provides receiver synchronization and frame delimitation services.
    The Preamble field is not visible with Network Monitor.
  • Destination Address The Destination Address field is 6 bytes long and indicates the destination's address. The destination can be a unicast, a multicast, or the Ethernet broadcast address. The unicast address is also known as an individual, physical, hardware, or MAC address. For the Ethernet broadcast address, all 48 bits are set to 1 to create the address 0xFF-FF-FF-FF-FF-FF.
  • Source Address The Source Address field is 6 bytes long and indicates the sending node's unicast address.
  • EtherType The EtherType field is 2 bytes long and indicates the upper layer protocol contained within the Ethernet frame. After the network adapter passes the frame to the host's network operating system, the EtherType field's value is used to pass the Ethernet payload to the appropriate upper layer protocol. If no upper layer protocols have registered interest in receiving the payload at the frame's EtherType field value, it is silently discarded.

    The EtherType field acts as the protocol identifier for the Ethernet II frame format. For an IP datagram, the field is set to 0x0800. For an ARP message, the EtherType field is set to 0x0806. The current list of defined EtherType field values can be found at http://www.iana.org/assignments/ethernet-numbers .

  • Payload The Payload field for an Ethernet II frame consists of a protocol data unit (PDU) of an upper layer protocol. Ethernet II can send a maximum-sized payload of 1500 bytes. Because of Ethernet's collision detection facility, Ethernet II frames must send a minimum payload size of 46 bytes. If an upper layer PDU is less than 46 bytes long, it must be padded so that it is at least 46 bytes long. The Ethernet minimum frame size is discussed in greater detail in the section entitled "Ethernet Minimum Frame Size," later in this chapter.
  • Frame Check Sequence The Frame Check Sequence (FCS) field is 4 bytes long and provides bit-level integrity verification on the bits in the Ethernet II frame. The FCS is also called a cyclical redundancy check (CRC). The source node calculates the FCS and places the result in this field. When the destination receives the FCS, it runs the same CRC algorithm and compares its own value with the one placed in the FCS field by the source node. If the two values match, the frame is considered valid and the destination node processes it. If the two values do not match, the frame is silently discarded.

    The FCS calculation consists of dividing a 33-bit prime number into the number consisting of the bits in the frame (not including the Preamble and FCS fields). The result of the division is a quotient and a remainder. The 4-byte FCS field is set to the remainder, which is always a 32-bit value. The FCS can detect 100 percent of all single-bit errors. Although it is mathematically possible to selectively change multiple bits in the frame without invalidating the value of the FCS field, it is highly improbable that the type of random noise and damage that occurs on networks will result in a frame with bits that are changed, but retains a valid FCS.

    The FCS calculation provides only a bit-level integrity service, not a data integrity or authentication service. A valid FCS does not imply that only the node with the unicast address stored in the Source Address field could have sent it and that it was not modified in transit. The FCS calculation is well known and an intermediate node could easily intercept the frame, alter its contents, perform the FCS calculation, and place the new value in the FCS field before forwarding the frame. The receiver of the frame could not detect that the frame contents were altered using just the FCS field. For data integrity and authentication services, use Internet Protocol Security (IPSec). For more information on IPSec, see Chapter 22, "Internet Protocol Security (IPSec)."

    The FCS field provides only bit-level error detection, not error recovery. When the receiver-calculated FCS value does not match the value of the FCS stored in the frame, the only conclusion that can be reached is that, somewhere in the frame, a bit or bits were changed. The FCS calculation does not produce any information on where the error occurred or how to correct it, but other types of CRC calculations do provide this information. An example of such a CRC calculation is the 1-byte Header Checksum field in the Asynchronous Transfer Mode (ATM) cell header, which provides error detection and limited error recovery services for the bits in the ATM header.

The FCS field is not visible with Network Monitor.

The following Network Monitor trace (Capture 01-01, included in the \Captures folder on the companion cd-rom) shows the Ethernet II frame format for an IP datagram:

+	Frame: Base frame properties

    ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

        + ETHERNET: Destination address : 001054CAE140

        + ETHERNET: Source address : 00600852F9D8

        ETHERNET: Frame Length : 74 (0x004A)

        ETHERNET: Ethernet Type : 0x0800 (IP:  DOD Internet Protocol)

        ETHERNET: Ethernet Data: Number of data bytes remaining = 60 (0x003C)

+	IP: ID = 0xAE09; Proto = ICMP; Len: 60

+	ICMP: Echo: From 192.168.160.186 To 192.168.160.01
The ETHERNET: Frame Length and ETHERNET: Ethernet Data fields are Network Monitor informational fields, and do not correspond to fields that are physically present in the Ethernet header.

The Ethernet Interframe Gap

Unlike Token Ring and FDDI, Ethernet frame formats do not have a way to explicitly indicate the end of the frame. Rather, Ethernet frames use an implied postamble by leaving a gap between each Ethernet frame. This gap, known as the Ethernet interframe gap, is used to space Ethernet frames. The Ethernet interframe gap is a specific measure of the time required to send 96 bits of data (9.6 Ethernet network segment).

The Ethernet interframe gap is used as a postamble; after receiving bits of a frame, if the wire falls silent for 96 bit times, the last bit in the received frame occurred 96 bit times ago.

Ethernet Minimum Frame Size

All Ethernet frames must carry a minimum payload of 46 bytes. The Ethernet minimum frame size is a result of the Ethernet collision detection scheme applied to a maximum-extent Ethernet network. To detect a collision, Ethernet nodes must be transmitting long enough for the signal indicating the collision to be propagated back to the sending node. The maximum-extent Ethernet network consists of Ethernet segments configured using 10Base5 cabling and the IEEE 802.3 Baseband 5-4-3 rule.

The IEEE 802.3 Baseband 5-4-3 rule states that there can be a maximum of five physical segments between any two nodes, with four repeaters between the nodes. However, only three of these physical segments can have connected nodes (populated physical segments). The other two physical segments can be used only to link physical segments to extend the network length. Repeaters count as a node on the physical segment. When using 10Base5 cabling, each physical segment can be up to 500 meters long. Therefore, an Ethernet network's maximum linear length is 2500 meters.

Figure 1-2 shows Ethernet Node A and Ethernet Node B at the farthest ends of a 5-4-3 network using 10Base5 cabling.

Figure 1-2. The maximum-extent Ethernet network and the slot time.

When Node A begins transmitting, the signal must propagate the network length. In the worst-case collision scenario, Node B begins to transmit just before the signal for Node A's frame reaches it. The collision signal of Node A and Node B's frame must travel back to Node A for Node A to detect that a collision has occurred.

The time it takes for a signal to propagate from one end of the network to the other is known as the propagation delay. In this worst-case collision scenario, the time that it takes for Node A to detect that its frame has been collided with is twice the propagation delay. Node A's frame must travel all the way to Node B, and then the collision signal must travel all the way from Node B back to Node A. This time is known as the slot time. An Ethernet node must be transmitting a frame for the slot time for a collision with that frame to be detected. This is the reason for the minimum Ethernet frame size.

The propagation delay for this maximum-extent Ethernet network is 28.8 Therefore, the slot time is 57.6 Ethernet node must transmit 576 bits. Therefore, the entire Ethernet frame, including the Preamble field, must be a minimum size of 576 bits, or 72 bytes long. Subtracting the Preamble (8 bytes), Source Address (6 bytes), Destination Address (6 bytes), EtherType (2 bytes), and FCS (4 bytes) fields, the minimum Ethernet payload size is 46 bytes.

Upper layer PDUs smaller than 46 bytes are padded to 46 bytes, ensuring the minimum Ethernet frame size. This padding is not part of the IP datagram or the ARP message, and is not included in any length indicator fields within the IP datagram or ARP message. For example, this padding is not included in the IP header's Total Length field, which indicates only the size of the IP datagram, and is used to discard the padding bytes.

IEEE 802.3

The IEEE 802.3 frame format is the result of the IEEE 802.2 and 802.3 specifications, and consists of an IEEE 802.3 header and trailer and an IEEE 802.2 LLC header. Figure 1-3 shows the IEEE 802.3 frame format.

Figure 1-3. The IEEE 802.3 frame format showing the IEEE 802.3 header and trailer and the IEEE 802.2 header.

IEEE 802.3 Header and Trailer

The fields in the IEEE 802.3 header and trailer are defined as follows:

  • Preamble The Preamble field is 7 bytes long and consists of alternating 1s and 0s that synchronize a receiving station. Each byte is the bit sequence 10101010.
  • Start Delimiter The Start Delimiter field is the 1-byte bit sequence 10101011, which indicates the start of a frame. The combination of the IEEE 802.3 Preamble and Start Delimiter fields is the exact same bit sequence as the Ethernet II Preamble field.
    The Preamble and Start Delimiter fields are not visible with Network Monitor.
  • Destination Address The Destination Address field is the same as the Ethernet II Destination Address field except that IEEE 802.3 allows both 6-byte and 2-byte addresses. IEEE 802.3 2-byte addresses are not commonly used.
  • Source Address The Source Address field is the same as the Ethernet II Source Address field except that IEEE 802.3 allows both 6-byte and 2-byte addresses.
  • Length The Length field is 2 bytes long and indicates the number of bytes from the LLC header's first byte to the payload's last byte. The Length field does not include the IEEE 802.3 header or the FCS field. This field's minimum value is 46 (0x002E), and its maximum value is 1500 (0x05DC).
  • Frame Check Sequence The FCS field is 4 bytes long and is identical to the Ethernet II FCS field.

IEEE 802.2 LLC Header

The fields in the IEEE 802.2 LLC header and trailer are defined as follows:

  • DSAP The Destination Service Access Point (DSAP) field is 1 byte long and indicates the destination upper layer protocol for the frame.
  • SSAP The Source Service Access Point (SSAP) field is 1 byte long and indicates the source upper layer protocol for the frame.

    The DSAP and SSAP fields act as protocol identifiers for the IEEE 802.3 frame format. The defined value for the DSAP and SSAP fields for IP is 0x06. However, it is not used in the industry. Instead, the SNAP header is used to encapsulate IP datagrams with an IEEE 802.3 header. The SNAP header is discussed in greater detail in the section entitled "IEEE 802.3 SNAP," later in this chapter. The current list of defined DSAP and SSAP values can be found at http://www.iana.org/assignments/ieee-802-numbers.

  • Control The Control field can be 1 or 2 bytes long depending on whether the LLC-encapsulated data is an LLC datagram, known as a Type 1 LLC operation, or part of an LLC session, known as a Type 2 LLC operation.

    A Type 1 LLC operation (a 1-byte Control field) is a connectionless, unreliable LLC datagram. With an LLC datagram, LLC is not providing reliable delivery service on behalf of the upper layer protocol. A Type 1 LLC datagram is known as an Unnumbered Information (UI) frame and is indicated by setting the Control field to the value 0x03.

    A Type 2 LLC operation (a 2-byte Control field) is a connection-oriented, reliable LLC session. Type 2 LLC frames are used when LLC is providing reliable delivery service for the upper layer protocol.

    For IP datagrams and ARP messages, reliable LLC services are never used. Therefore, IP datagrams and ARP messages are always sent as a Type 1 LLC datagram with the Control field set to 0x03 to indicate a UI frame.

Differentiating an Ethernet II Frame from an IEEE 802.3 Frame

It is common for a network operating system to support multiple frame formats simultaneously. TCP/IP for the Windows Server 2003 family and Windows XP supports both Ethernet II and IEEE 802.3 frame formats for IP datagrams and ARP messages. There are many similarities between the Ethernet II and IEEE 802.3 frame formats, such as the following:

  • The Ethernet II Preamble field is identical to the IEEE 802.3 Preamble and Start Delimiter fields.
  • With the exception of the 2-byte address allowed by IEEE 802.3, the Source Address and Destination Address fields are identical.
  • The FCS is identical.

The ability to differentiate between the Ethernet II and the IEEE 802.3 frame formats lies in the first 2 bytes past the Source Address field. For the Ethernet II frame format, these 2 bytes are the EtherType field. For the IEEE 802.3 frame format, these 2 bytes are the Length field. The following algorithm is used to determine whether these 2 bytes are an EtherType field or a Length field:

  • If the value of these 2 bytes is greater than 1500 (0x05DC), it is an EtherType field and an Ethernet II frame format.
  • If the value of these 2 bytes is less than or equal to 1500 (0x05DC), it is a Length field and an IEEE 802.3 frame.

This comparison can be made because there are no defined EtherType values less than 0x05DC. The lowest EtherType value is 0x0600, used to indicate the Xerox Network Systems (XNS) protocol.

IEEE 802.3 SNAP

Although there is a defined value of 0x06 for the Service Access Point (SAP) for IP, it is not used in the industry. RFC 1042 states that IP datagrams and ARP frames sent over IEEE 802.3, 802.4, and 802.5 networks must use the SNAP encapsulation.

The IEEE 802.3 SNAP was created as an extension to the IEEE 802.3 specification to allow protocols that were designed to operate with an Ethernet II header to be used in an IEEE 802.3-compliant environment. Figure 1-4 shows the IEEE 802.3 SNAP frame format.

Figure 1-4. The IEEE 802.3 SNAP frame format showing the SNAP header and an IP datagram.

To denote a SNAP frame, the DSAP and SSAP fields are set to the SNAP-defined value of 0xAA within the LLC header. Because all SNAP-encapsulated payloads are not using reliable LLC services, every SNAP frame is an LLC datagram. Therefore, the Control field is set to 0x03 to indicate a UI frame.

The SNAP header consists of the following two fields:

  • The Organization Code field is 3 bytes long and is used to indicate the organization that maintains the meaning of the 2 bytes that follow. For IP data-grams and ARP messages, the Organization Code field is set to 0x00-00-00.
  • For the Organization Code field set to 0x00-00-00, the next 2 bytes of the SNAP header are the 2-byte EtherType field. The same values for IP (0x0800) and ARP (0x0806) are used.

Because of the increased overhead of the LLC header (3 bytes total) and the SNAP header (5 bytes), the payload for an IEEE 802.3 SNAP frame has a maximum size of 1492 bytes and a minimum size of 38 bytes. Padding is added when needed to ensure that the payload is at least 38 bytes long.

The following Network Monitor trace (Capture 01-02, included in the \Captures folder on the companion CD-ROM) shows the IEEE 802.3 SNAP frame format for an ARP Request frame:

+	Frame: Base frame properties

    ETHERNET: 802.3 Length = 50

        +	ETHERNET: Destination address : FFFFFFFFFFFF

        +	ETHERNET: Source address : 00AA004BB147

            ETHERNET: Frame Length : 50 (0x0032)

            ETHERNET: Data Length : 0x0024 (36)

            ETHERNET: Ethernet Data: Number of data bytes remaining = 36 (0x0024)

    LLC: UI DSAP=0xAA SSAP=0xAA C

            LLC: DSAP = 0xAA : INDIVIDUAL : Sub-Network Access Protocol (SNAP)

            LLC: SSAP = 0xAA: COMMAND : Sub-Network Access Protocol (SNAP)

            LLC: Frame Category: Unnumbered Frame

            LLC: Command = UI

            LLC: LLC Data: Number of data bytes remaining = 33 (0x0021)

    SNAP: ETYPE = 0x0806

            SNAP: Snap Organization code = 00 00 00

            SNAP: Snap etype : 0x0806

            SNAP: Snap Data: Number of data bytes remaining = 28 (0x001C)

+ ARP_RARP: ARP: Request, Target IP: 192.168.50.2
The ETHERNET: Data Length, ETHERNET: Ethernet Data, LLC: Frame Category, LLC: LLC Data, and SNAP: Snap Data fields are Network Monitor informational fields and do not correspond to fields that are physically present in the Ethernet header.

By default, TCP/IP for the Windows Server 2003 family and Windows XP uses Ether-net II encapsulation when sending and receiving frames on an Ethernet network. TCP/IP for the Windows Server family 2003 and Windows XP receives both types of frame formats but, by default, only responds with Ethernet II encapsulated frames. To send IEEE 802.3 SNAP encapsulated IP and ARP messages, use the following registry setting:

ArpUseEtherSNAP

Location:	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\

Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-1

Default value: 0

Present by default: No

ArpUseEtherSNAP either enables (when set to 1) or disables (when set to 0) the use of the IEEE 802.3 SNAP frame format when sending IP and ARP frames. ArpUseEtherSNAP is disabled by default, meaning that IP and ARP frames are sent with Ethernet II encapsulation. Regardless of the ArpUseEtherSNAP setting, both types of frame formats are received.

With ArpUseEtherSNAP disabled, TCP/IP for the Windows Server 2003 family and Windows XP recognizes a SNAP-encapsulated ARP Request message and responds with an Ethernet II-encapsulated ARP Reply frame. The assumption is that the node sending the ARP Request message will recognize the Ethernet II encapsulation on the ARP Reply and use Ethernet II encapsulation for subsequent communications. If the node sending the ARP Request does not switch, IP communication between the node sending the ARP Request and the node sending the ARP Reply is impossible.

With ArpUseEtherSNAP enabled, TCP/IP for the Windows Server 2003 family and Windows XP switches to Ethernet II encapsulation if one of the following two scenarios occurs: a SNAP-encapsulated ARP Request frame is responded to with an Ethernet II-encapsulated ARP Reply frame, or an Ethernet II-encapsulated ARP Request is received.

Special Bits on Ethernet MAC Addresses

Within the Source Address and Destination Address fields of the Ethernet II and IEEE 802.3 frame formats, special bits are defined, as Figure 1-5 shows.

The Individual/Group Bit

The Individual/Group (I/G) bit is used to indicate whether the address is a unicast (individual) or multicast (group) address. For a unicast address, the I/G bit is set to 0. For a multicast address, the I/G bit is set to 1. The broadcast address is a special case of multicast and its I/G bit is set to 1. The I/G bit is also known as the multicast bit.

The Universal/Locally Administered Bit

The Universal/Locally (U/L) Administered bit is used to indicate whether the IEEE allocated the address. For a universal address allocated by the IEEE, the U/L bit is set to 0. Universal addresses are guaranteed to be universally unique because network adapter manufacturers obtain universally unique vendor identifiers from the IEEE and assign unique 3-byte serial numbers to each network adapter. The 6-byte physical address of a network adapter, as programmed into the adapter during the manufacturing process, is a universally administered address.

For a locally administered address, the U/L bit is set to 1. Some network adapters allow you to override the network adapter's physical address and specify a new physical address. In this case, the new address must have the U/L bit set to 1 to indicate that it is locally administered.

The U/L bit is significant only for unicast addresses (the I/G bit is set to 0). When the I/G bit is set to 1, this bit does not imply a locally or universally administered address. The U/L bit is relevant for both the Source Address and Destination Address.

Figure 1-5. The special bits defined for Ethernet source and destination MAC addresses.

Routing Information Indicator Bit

The Routing Information Indicator bit indicates whether MAC-level routing information is present. This bit is meaningful only for Token Ring addresses. Token Ring has a MAC-level routing mechanism known as Token Ring source routing. Even though this bit is meaningless for Ethernet addresses, it is still reserved and set to 0 to prevent problems when employing a translating bridge or Layer 2 switch between an Ethernet segment and a Token Ring ring.

For example, suppose the Routing Information Indicator bit is not reserved at the value of 0 for Ethernet addresses, and this bit is set to 1 through a universal or locally administered address. When the address is translated to a Token Ring address, the Routing Information Indicator bit is set to 1 when there is no source routing information present, which can cause the Token Ring node to drop the frame.

The following Network Monitor trace (Capture 01-03, included in the \Captures folder on the companion CD-ROM) shows the special bits for Ethernet MAC addresses:

+	Frame: Base frame properties

    ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

            ETHERNET: Destination address : 01005E400009

                ETHERNET: .......1 = Group address

                ETHERNET: ......0. = Universally administered address

            ETHERNET: Source address : 00E034C0A060

                ETHERNET: .......0 = No routing information present

                ETHERNET: ......0. = Universally administered address

            ETHERNET: Frame Length : 591 (0x024F)

            ETHERNET: Ethernet Type : 0x0800 (IP:  DOD Internet Protocol)

            ETHERNET: Ethernet Data: Number of data bytes remaining = 577 (0x0241)

+	IP: ID = 0xDBD2; Proto = UDP; Len: 577

+	UDP: IP Multicast: Src Port: Unknown, (3985); Dst Port: Unknown (20441);
                    Length = 557 (0x22D)


Token Ring

Token Ring is a ring access network technology originally proposed by Olaf Soderblum in 1969. IBM purchased the rights to the original design and created and released its Token Ring product in 1984. Key elements of the original IBM design were the use of proprietary connectors, twisted-pair cable out to the network node, and structured wiring systems using centralized active hubs.

In 1985, the IEEE Project 802 created the 802.5 subcommittee and Token Ring became an international standard. IBM created Token Ring to replace Ethernet as the most popular LAN technology. Although Token Ring is in many ways a superior technology to Ethernet, a combination of cost issues and marketing has made it less popular than Ethernet.

The original specification was for a 4 Mbps transmission rate, but that was followed by an additional specification at 16 Mbps. On the same ring, all nodes must operate at the same speed. Common implementations use 4-Mbps rings connected together, using 16-Mbps rings as a high-speed backbone.

IP and ARP encapsulation over Token Ring networks are described in RFC 1042, which can be found in the \Rfc folder on the companion CD-ROM.

IEEE 802.5

The IEEE 802.5 frame format is the result of the IEEE 802.2 and 802.5 specifications, and consists of an IEEE 802.5 header and trailer and an IEEE 802.2 LLC header. The IEEE 802.5 frame format is shown in Figure 1-6.

Figure 1-6. The IEEE 802.5 frame format showing the IEEE 802.5 header and trailer and the IEEE 802.2 header.

IEEE 802.5 Header and Trailer

The fields in the IEEE 802.5 header and trailer are defined as follows:

  • Start Delimiter The Start Delimiter field is 1 byte long and identifies the start of the frame. The Start Delimiter field contains nondata symbols known as J and K symbols that are deliberate violations of the Token Ring signal encoding scheme. The J symbol is an encoding violation of a 1 and the K symbol is an encoding violation of a 0. The Start Delimiter field provides a very explicit preamble. Unlike Ethernet, Token Ring frames do not have an interframe gap to separate frames on the wire. The Start Delimiter field also provides synchronization for the receiver.
    The Start Delimiter field is not visible with Network Monitor.
  • Access Control The Access Control field is 1 byte long and contains bits for the following:
    • Setting the current priority of the token (3 bits). An interesting facility of Token Ring is its ability to prioritize access to the token and, therefore, the right to transmit data based on seven priority levels.
    • Setting the token reservation level (3 bits). The token reservation bits set the priority of the token once the station that is currently transmitting releases it.
    • Indicating whether the frame has passed the ring monitor station (1 bit). As the frame passes the ring monitor station, the Monitor bit is set to 1. If the ring monitor station sees a frame with the Monitor bit set to 1, the frame has already been sent on the ring. The ring monitor station removes the frame from the ring and then purges the ring.
    • Indicating whether the frame that follows is a token or a frame (1 bit). If set to 0, what follows is a token. If set to 1, what follows is a frame.
  • Frame Control The Frame Control field is 1 byte long and contains bits for the following:
    • Indicating whether the frame that follows is a Token Ring MAC management frame or an LLC frame (2 bits).
    • Indicating the type of Token Ring MAC management frame such as Purge, Claim Token, and Beacon (4 bits).

    Two bits within the Frame Control field are reserved.

  • Destination Address The Destination Address field is 6 bytes long and indicates the address of the destination. For Token Ring, the Destination Address field can be the following:
    • A universal or locally administered unicast address.
    • The universal broadcast address (0xFF-FF-FF-FF-FF-FF).
    • The Token Ring broadcast address (0xC0-00-FF-FF-FF-FF). A frame using the Token Ring broadcast address is designed to remain on a single ring and is not forwarded by Token Ring source-route bridges.
    • A multicast address.
    • A Token Ring functional address. A functional address is a type of multicast address that is specific to Token Ring and is typically used by Token Ring MAC management frames.
  • Source Address The Source Address field is 6 bytes long and indicates the sending node's unicast address.
  • Payload The Payload field for a Token Ring frame consists of a PDU of an upper layer protocol. Unlike Ethernet, there is no minimum frame size and the maximum transmission unit (MTU) for Token Ring is not a defined number, but dependent on factors such as the bit rate and the token holding time. Token ring MTUs are further complicated by the presence of Token Ring source-routing bridges. More information on Token Ring MTUs for IP datagrams can be found in the section entitled "IEEE 802.5 SNAP," later in this chapter.
  • Frame Check Sequence The FCS field is a 4-byte CRC that uses the same algorithm as Ethernet to provide a bit-level integrity check of all fields in the Token Ring frame, from the Frame Control field to the Payload field. The FCS does not provide bit-level integrity for the Access Control or Frame Status fields. This allows bits in these fields, such as the Monitor bit, to be set without forcing a recalculation of the FCS.

    The FCS is checked as it passes each node on the ring. If the FCS fails at any node, the Error bit in the End Delimiter field is set to 1 and the receiving node does not copy the frame.

  • End Delimiter The End Delimiter is a 1-byte field that identifies the end of the frame. Like the Start Delimiter, the End Delimiter contains J and K nondata symbols to provide an explicit postamble. The End Delimiter field also contains the following:
    • An Intermediate Frame indicator (1 bit), used to indicate whether this frame is the last frame in the sequence (when set to 0) or more frames are to follow (when set to 1).
    • An Error Detected indicator (1 bit), used to indicate whether this frame has failed the FCS calculation.

    Because there is no Length field in the IEEE 802.5 frame, the End Delimiter is used to locate the end of the payload and the position of the FCS and Frame Status fields.

  • Frame Status The Frame Status field is a 1-byte field that contains the following:
    • Two copies of the Address Recognized indicator. The destination node sets the Address Recognized indicators to indicate that the address in the Destination Address field was recognized.
    • Two copies of the Frame Copied indicator. The destination node sets the Frame Copied indicators to indicate that the frame was successfully copied into a buffer on the network adapter.

    Two copies of each indicator are needed because the FCS field does not protect the Frame Status field.

    The Address Recognized and Frame Copied indicators are not used as acknowledgments for reliable data delivery. The sending Token Ring network adapter uses these indicators to retransmit the frame, if necessary.

The FCS, End Delimiter, and Frame Status fields are not visible with Network Monitor.

IEEE 802.2 LLC Header

The fields in the IEEE 802.2 LLC header are defined and used in the same way as the IEEE 802.2 LLC header for the IEEE 802.3 frame format, as discussed in the section entitled "IEEE 802.3," earlier in this chapter.

IEEE 802.5 SNAP

As described earlier in this chapter, the value of 0x06 is defined as the SAP for IP. However, it is not defined for use in RFC 1042 and not used in the industry. Therefore, similar to the case of IEEE 802.3 frames, to send an IP datagram over an IEEE 802.5 network, the IP datagram must be encapsulated using SNAP, as Figure 1-7 shows.

Figure 1-7. The IEEE 802.5 SNAP frame format showing the SNAP header and an IP datagram.

The following Network Monitor trace (Capture 01-04, included in the \Captures folder on the companion CD-ROM) shows the IEEE 802.5 SNAP frame format for an IP datagram:

+	Frame: Base frame properties

    TOKENRING: Length =  66, Priority Normal (No token) LLC Frame

            TOKENRING: Access control = 16 (0x10) Original, Frame, Priority: Normal

                            (No token)

                TOKENRING: .....000	Reservation bits: Reservation = Normal, No
                                    token needed.

                TOKENRING: ....0...	Monitor bit = Original (non-repeated)

                TOKENRING: ...1....	Token bit = Frame

                TOKENRING: 000.....	Priority bits: Priority = Normal, No token

                                    needed.

            TOKENRING: Frame control = 64 (0x40), LLC Frame

                TOKENRING: ....0000	Control bits = Normal Buffered

                TOKENRING: 01......	Frame type = LLC Frame

        +	TOKENRING: Destination address : 400030370AF4

        +	TOKENRING: Source address      : 10007038213A

            TOKENRING: Frame length : 66 (0x0042)

            TOKENRING: Tokenring data: Number of data bytes remaining = 52 (0x0034)

    LLC: UI DSAP=0xAA SSAP=0xAA C

            LLC: DSAP = 0xAA : INDIVIDUAL : Sub-Network Access Protocol (SNAP)

            LLC: SSAP = 0xAA: COMMAND : Sub-Network Access Protocol (SNAP)

            LLC: Frame Category: Unnumbered Frame

            LLC: Command = UI

            LLC: LLC Data: Number of data bytes remaining = 49 (0x0031)

    SNAP: ETYPE = 0x0800

            SNAP: Snap Organization code = 00 00 00

            SNAP: Snap etype : 0x0800

            SNAP: Snap Data: Number of data bytes remaining = 44 (0x002C)

+	IP: ID = 0xCA3D; Proto = TCP; Len: 44

+	TCP: ....S.,	len: 0, seq:364446-364446, ack: 0, win: 16384, src:50982

                            dst: 21
The TOKENRING: Frame length, TOKENRING: Tokenring data, LLC: Frame Category, LLC: LLC Data, and SNAP: Snap Data fields are Network Monitor informational fields and do not correspond to fields that are physically present in the Token Ring header.

For a 10-millisecond (ms) token-holding time, the maximum sizes for IP datagrams are 4464 bytes for 4-Mbps Token Ring network adapters and 17,914 bytes for 16-Mbps Token Ring network adapters. If Token Ring source-routing bridges are present, the maximum size of IP datagrams can be 508, 1020, 2044, 4092, and 8188 bytes.

For more information on Token Ring MTUs, see RFC 1042 in the \Rfc folder on the companion CD-ROM.

Special Bits on Token Ring MAC Addresses

Within the Source Address and Destination Address fields of the IEEE 802.5 frame format, special bits are defined, as shown in Figure 1-8.

Figure 1-8. The special bits defined on Token Ring source and destination MAC addresses.

The Individual/Group Bit

Identical to Ethernet, the I/G bit for Token Ring addresses is used to indicate whether the address is a unicast (individual) or multicast (group) address. For unicast addresses, the I/G bit is set to 0. For multicast addresses, the I/G bit is set to 1.

The Universal/Locally Administered Bit

Identical to Ethernet, the U/L Administered bit for Token Ring addresses is used to indicate whether the IEEE has allocated the address. For universal addresses allocated by the IEEE, the U/L bit is set to 0. For locally administered addresses, the U/L bit is set to 1. The U/L bit is relevant for both the Source Address and Destination Address fields.

Functional Address Bit

The Functional Address bit indicates whether the address is a functional address (when set to 0) or a nonfunctional address (when set to 1). Token Ring defines the following two types of multicast addresses:

  • Functional addresses Multicast addresses that are specific to Token Ring. There are specific functional addresses for identifying the ring monitor, the ring-parameter server, and a source-routing bridge.
  • Nonfunctional addresses General multicast addresses that are not Token Ring-specific.

The Functional Address bit is significant only if the I/G bit is set to 1.

Routing Information Indicator Bit

The Routing Information Indicator bit indicates whether MAC-level routing information is present. In the case of Token Ring, the Routing Information Indicator bit indicates the presence of a source-routing header between the IEEE 802.5 header and the IEEE 802.2 LLC header. Token Ring source routing is not OSI Network Layer routing, but rather a MAC sublayer routing scheme that allows a sending node to discover and specify a route through a defined series of rings and bridges within a Token Ring network segment.

The following Network Monitor trace (Capture 01-04, included in the \Captures folder on the companion CD-ROM) shows the special bits for Token Ring addresses:

+	Frame: Base frame properties

    TOKENRING: Length =  66, Priority Normal (No token) LLC Frame

        +	TOKENRING:	Access control = 16 (0x10) Original, Frame, Priority: Normal

                    (No token)

        + TOKENRING:	Frame control = 64 (0x40), LLC Frame

            TOKENRING:	Destination address : 400030370AF4

                TOKENRING:	Destination Address I/G Bit 	= Individual address

                TOKENRING:	Destination Address U/L bit	= Locally administered

                        address

                TOKENRING:	Destination Address Functional bit = Functional address

            TOKENRING:	Source address      : 10007038213A

                TOKENRING:	Source Address Routing bit = No routing information

                        present

                TOKENRING: Source Address U/L bit     = Universally administered

                        address

            TOKENRING:	Frame length : 66 (0x0042)

            TOKENRING:	Tokenring data: Number of data bytes remaining = 52 (0x0034)

+	LLC: UI DSAP=0xAA SSAP=0xAA C

+	SNAP: ETYPE = 0x0800 + IP: ID = 0x21E0; Proto = TCP; Len: 44

+	TCP: ....S., len:    0, seq:1891988225-1891988225, ack:         0,

                    win: 8192, src:50982  dst: 3180


FDDI

FDDI is a network technology developed by the American National Standards Institute (ANSI). FDDI is an optical fiber-based token passing ring with a bit rate of 100 Mbps. It was designed to span long distances and, in most implementations, it acts as a campus-wide high-speed backbone. FDDI offers advanced features beyond Token Ring, such as the ability to self-heal a break in the ring and the use of guaranteed bandwidth.

Although not developed by the IEEE as part of the 802 standards, the FDDI specification is quite similar to the IEEE 802.3 and 802.5 specifications; it defines the MAC sublayer of the OSI Data Link Layer and the Physical Layer, and it uses the IEEE 802.2 LLC sublayer. Copper Data Distributed Interface (CDDI) is a version of FDDI that operates over twisted-pair copper wire.

RFC 1188 describes IP encapsulation over FDDI networks. You can find RFC 1188 in the \Rfc folder on the companion CD-ROM.

FDDI Frame Format

The FDDI frame format is the result of the IEEE 802.2 and ANSI FDDI specifications, and consists of an FDDI header and trailer and an IEEE 802.2 LLC header. Figure 1-9 shows the FDDI frame format.

Figure 1-9. The FDDI frame format showing the FDDI header and trailer and IEEE 802.2 header.

FDDI Header and Trailer

The fields in the FDDI header and trailer are defined as follows:

  • Preamble The Preamble field is 2 bytes long and provides receiver synchronization.
  • Start Delimiter The Start Delimiter field is 1 byte long and identifies the start of the frame. Like Token Ring, the Start Delimiter field contains nondata symbols known as J and K symbols that are deliberate violations of the FDDI signal encoding scheme. The J symbol is an encoding violation of a 1 and the K symbol is an encoding violation of a 0.
    The Preamble and Start Delimiter fields are not visible with Network Monitor.
  • Frame Control The Frame Control field is 1 byte long and contains bits for the following:
    • Setting the class of the frame (1 bit). FDDI frames can be sent as synchronous or asynchronous frames. Synchronous frames are used for guaranteed bandwidth and response time. Asynchronous frames are used for dynamic bandwidth sharing. The Class bit is set to 1 for synchronous frames and 0 for asynchronous frames.
    • Setting the length of the Destination Address and the Source Address fields (1 bit). Like IEEE 802.3, FDDI supports 2-byte and 6-byte addresses. The Address bit is set to 1 for 6-byte addresses and 0 for 2-byte addresses.
    • Indicating that what follows is a token (either nonrestricted or restricted), a station management frame, a MAC frame, an LLC frame, or an LLC frame with a specific priority (6 bits).
  • Destination Address The Destination Address field is either 2 bytes or 6 bytes long and indicates the address of the destination (2-byte addresses are seldom used). For 6-byte addresses, FDDI Destination Address fields are defined the same as Ethernet Destination Address fields to provide easy interoperability between bridged or Layer 2 switched Ethernet and FDDI segments. The destination address is a unicast, multicast, or broadcast address.
  • Source Address The Source Address field is either 2 bytes or 6 bytes long and indicates the unicast address of the sending node (2-byte addresses are seldom used).
  • Frame Check Sequence The FCS field is a 4-byte CRC that uses the same algorithm as Ethernet to provide a bit-level integrity check of all fields in the FDDI frame, from the Frame Control field to the Payload field. The FCS is checked as it passes each node on the ring. If the FCS fails at any node, the Error bit in the Frame Status field is set to 1 and the receiving node does not copy the frame.
  • End Delimiter The End Delimiter field is 1 byte long and identifies the end of the frame. Like the Start Delimiter field, the End Delimiter field contains J and K nondata symbols to provide an explicit postamble. Because there is no Length field in the FDDI frame, the End Delimiter field is also used to locate the end of the payload, and the position of the FCS and Frame Status fields.
  • Frame Status The Frame Status field is typically 2 bytes long and contains bits for the following:
    • The Address Recognized indicator The destination node sets the Address Recognized indicator to show that the address in the Destination Address field was recognized.
    • The Frame Copied indicator The destination node sets the Frame Copied indicator to show that the frame was successfully copied into a buffer on the network adapter.
    • The Error indicator Any FDDI station sets the Error indicator to 1 when the FCS field is invalid.

    Similar to Token Ring, the Address Recognized and Frame Copied indicators are not used as acknowledgments for reliable data delivery. Rather, the sending FDDI network adapter uses these indicators to retransmit the frame if necessary.

The FCS, End Delimiter, and Frame Status fields are not visible with Network Monitor.

IEEE 802.2 LLC Header

The fields in the IEEE 802.2 LLC header are defined and used in the same way as the IEEE 802.2 LLC header for the IEEE 802.3 and IEEE 802.5 frame format discussed earlier in this chapter.

Payload

The payload for an FDDI frame consists of a PDU of an upper layer protocol. The entire FDDI frame from the Preamble field to the Frame Status field can be a maximum size of 4500 bytes. Once you subtract the FDDI and IEEE 802.2 LLC headers, the maximum payload size is 4474 bytes with a 3-byte LLC header, and 4473 bytes with a 4-byte LLC header.

FDDI SNAP

As described earlier in this chapter, the value of 0x06 is defined as the SAP for IP. However, it is not defined for use in RFC 1188 and not used in the industry. Therefore, similar to the case of IEEE 802.3 frames and IEEE 802.5 frames, to send an IP datagram over an FDDI network, the IP datagram must be encapsulated using the SNAP header, as shown in Figure 1-10.

Figure 1-10. The FDDI SNAP frame format showing the SNAP header and an IP datagram.

The following Network Monitor trace (Capture 01-05, included in the \Captures folder on the companion CD-ROM) shows the FDDI SNAP frame format for an IP datagram:

+	Frame: Base frame properties

    FDDI: Length = 81, type = 0x57 (LLC).

            FDDI:	Frame control bits = 87 (0x57)

                FDDI: ..01.... = LLC frame

                FDDI: 0....... = Asynchronous frame

                FDDI: .1...... = 48-bit addresses

        +	FDDI:	Destination address : 00608C14AF25

        +	FDDI:	Source address : 00608C13182A

            FDDI:	Frame Length : 81 (0x0051)

            FDDI:	Fddi Data: Number of data bytes remaining = 68 (0x0044)

    LLC: UI DSAP=0xAA SSAP=0xAA C

            LLC: DSAP = 0xAA : INDIVIDUAL : Sub-Network Access Protocol (SNAP)

            LLC: SSAP = 0xAA: COMMAND : Sub-Network Access Protocol (SNAP)

            LLC: Frame Category: Unnumbered Frame

            LLC: Command = UI

            LLC: LLC Data: Number of data bytes remaining = 65 (0x0041)

    SNAP: ETYPE = 0x0800

            SNAP:	Snap Organization code = 00 00 00

            SNAP:	Snap etype : 0x0800

            SNAP:	Snap Data: Number of data bytes remaining = 60 (0x003C)

+	IP: ID = 0xA665; Proto = ICMP; Len: 60

+	ICMP: Echo: From 192.168.44.01 To 192.168.44.254
The FDDI: Frame Length, FDDI: Fddi Data, LLC: Frame Category, LLC: LLC Data, and SNAP: Snap Data fields are Network Monitor informational fields and do not correspond to fields that are physically present in the FDDI header.

The maximum-sized IP datagram that can be sent on an FDDI network is 4352 bytes. This number of bytes is the result of taking the maximum FDDI frame size of 4500 bytes and subtracting the FDDI header and trailer (22 bytes), the LLC header (3 bytes), and the SNAP header (5 bytes), and reserving 117 bytes for future purposes.

IP datagrams and ARP messages sent over FDDI networks also have the following constraints:

  • Only 6-byte FDDI source and destination addresses can be used.
  • All IP and ARP frames are transmitted as asynchronous class LLC frames using unrestricted tokens.

RFC 1188 does not define how frame priorities are used or how the FDDI node deals with the values of the Address Recognized and Frame Copied indicators.

FDDI nodes send ARP Requests using the Ethernet ARP Hardware Type value of 0x00-01, but can receive ARP Requests using the ARP Hardware Types of 0x00-01 and 0x00-06 (IEEE networks). The use of the Ethernet ARP Hardware Type value is designed to allow FDDI hosts and Ethernet hosts in a bridged or Layer 2 switched environment to send and receive ARP messages.

Special Bits on FDDI MAC Addresses

Because FDDI MAC addresses are defined in the same way as Ethernet MAC addresses, the special bits on FDDI MAC addresses are the same as those defined for Ethernet MAC addresses.

The Network Monitor trace shown in Capture 01-05 (included in the \Captures folder on the companion CD-ROM) shows the special bits in the FDDI header.


IEEE 802.11

IEEE 802.11 is a set of standards for wireless LAN technologies. The original 802.11 standard defines wireless networking using either 1 Mbps or 2 Mbps bit rates in the Industrial, Scientific, and Medical (ISM) 2.54 gigahertz (GHz) frequency band. IEEE 802.11b defines a maximum bit rate of 11 Mbps in the 2.54 GHz ISM band. IEEE 802.11a defines a maximum bit rate of 54 Mbps in the 5.8 GHz band. IEEE 802.11b is by far the most widely deployed of the IEEE 802.11 standards.

At the MAC sublayer, IEEE 802.11 (all versions) uses a combination of congestion avoidance and Request to Send (RTS), Clear to Send (CTS), and Acknowledgment (ACK) frames to ensure that only one wireless node is transmitting at a time and that the sent frame is successfully received.

IEEE 802.11 wireless nodes can communicate in the following ways:

  • Directly with each other using an operating mode known as ad hoc mode.
  • With a wireless access point (AP) using an operating mode known as infrastructure mode. In infrastructure mode, the wireless AP acts as a transparent bridge connecting wireless nodes to a wired network.

To identify a wireless network in either operating mode, IEEE 802.11 uses a Service Set Identifier (SSID).

Because wireless networking uses broadcast radio waves, a wireless node within range of a transmitting wireless node can capture IEEE 802.11 frames and interpret the data. To provide a level of security that is equivalent to a wired network, IEEE 802.11 uses Wired Equivalent Privacy (WEP) to provide data confidentiality (encryption) for IEEE 802.11 payloads.

IEEE 802.11 Frame Format

The IEEE 802.11 frame format consists of an IEEE 802.11 header and trailer and an IEEE 802.2 LLC header. Figure 1-11 shows the IEEE 802.11 frame format.

Figure 1-11. The IEEE 802.11 frame format showing the IEEE 802.11 header and trailer and the IEEE 802.2 header.

IEEE 802.11 Header and Trailer

The fields in the IEEE 802.11 header and trailer for a data frame sent by wireless nodes or by a wireless AP to a wireless node are defined as follows:

  • Frame Control A 2-byte field that contains control information that defines the type of frame and how to process the frame. For more information, see the section entitled "Frame Control Field," later in this chapter.
  • Duration/ID Field A 2-byte field that is used to indicate the duration of time in microseconds needed to transmit the frame and the acknowledgment.
  • Address 1 A 6-byte field that contains either the destination MAC address of a wireless node (when sent by a wireless node to another wireless node in ad hoc mode or sent by the wireless AP to the wireless node) or the SSID (when sent by a wireless node to a wireless AP).
  • Address 2 A 6-byte field that contains either the MAC address of the sending node (when sent to another wireless node in ad hoc mode or sent to the wireless AP) or the SSID (when sent by the wireless AP to a wireless node).
  • Address 3 A 6-byte field that contains the SSID for frames sent to another wireless node in ad hoc mode, the source address for frames sent from the wireless AP to a wireless node, or the destination address for frames sent from a wireless node to the wireless AP.
  • Sequence Control A 2-byte field that contains a 4-bit Fragment Number field and a 12-bit Sequence Number field that, when used together, allow the receiver to discard duplicate frames. When a frame is fragmented, the Fragment Number field is used to indicate the number of the fragment. Otherwise, the Fragment Number field is set to 0. The Sequence Number field indicates the number of the frame starting at 0, incrementing to 4095, and then starting again at 0. All fragments of a frame have the same sequence number.
  • Address 4 A 6-byte field that contains the MAC address of the originating wireless node. This field is typically present only in frames in which both the To DS and From DS flags in the Frame Control field are set to 1, indicating inter-wireless AP communication.
  • Frame Check Sequence A 4-byte CRC that uses the same algorithm as Ethernet to provide a bit-level integrity check of all fields in the IEEE 802.11 frame, from the Frame Control field to the Payload field.

IEEE 802.2 LLC Header

The fields in the IEEE 802.2 LLC header are defined and used in the same way as the IEEE 802.2 LLC header for the IEEE 802.3, IEEE 802.5, and FDDI frame formats discussed earlier in this chapter.

Payload

The payload for an IEEE 802.11 frame can be a maximum size of 2312 bytes. IEEE 802.11 payloads can be MAC management frames (such as beacon frames sent by wireless APs), control fames (such as RTS, CTS, and ACK frames), or data frames containing the PDU of an upper layer protocol (such as an IP datagram). If the payload of a data frame is encrypted with WEP, the upper layer PDU is preceded by a plaintext 4-byte Initialization Vector (IV) field and followed with an encrypted 4-byte Integrity Check Value (ICV) field, lowering the maximum upper layer PDU size to 2304 bytes. The IV and ICV fields are not shown in Figure 1-11.

Frame Control Field

Figure 1-12 shows the Frame Control field.

Figure 1-12. The Frame Control field in the IEEE 802.11 header.

The Frame Control field contains the following subfields:

  • Protocol Version A 2-bit field that indicates the version of the 802.11 protocol used to construct the frame. This field is set to 0 for the current version of IEEE 802.11. If the Protocol Version field is set to a value that is not supported by the receiving wireless node, the frame is silently discarded.
  • Type A 2-bit field that indicates the type of IEEE 802.11 frame. There are three defined values: 00 for management frames, 01 for control frames, and 10 for data frames. The value of 11 is currently reserved.
  • Subtype A 4-bit field that indicates the specific type of management, control, or data frame.
  • To DS A 1-bit flag that indicates (when set to 1) that the frame is destined for the distribution system (DS), the wired network that connects wireless APs and provides access to wired network nodes. Only wireless nodes that are operating in infrastructure mode set this flag.
  • From DS A 1-bit flag that indicates (when set to 1) that the frame is originating from the wired network. This flag is only set by the wireless AP when forwarding a frame to a wireless node operating in infrastructure mode.
  • More Fragments A 1-bit flag that indicates (when set to 1) that there are more fragments of the frame for which this frame is also a fragment. If the frame is not fragmented or is the last fragment of a fragmented frame, the More Fragments flag is set to 0.
  • Retry A 1-bit flag that indicates (when set to 1) that this frame is a retransmission of a previously transmitted frame.
  • Power Management A 1-bit flag that indicates (when set to 1) that the transmitting wireless node is operating in a power-saving mode.
  • More Data A 1-bit flag that indicates (when set to 1) that the wireless AP has at least one frame buffered to send to the wireless node.
  • WEP A 1-bit flag that indicates (when set to 1) that the payload is encrypted with WEP.
  • Order A 1-bit flag that indicates (when set to 1) that the frames must be processed in order.

IEEE 802.11 SNAP

An IP datagram sent over an IEEE 802.11 network must be encapsulated with a SNAP header. Figure 1-13 shows SNAP encapsulation for IP datagrams sent over an IEEE 802.11 link (rather than between wireless APs).

Figure 1-13. The IEEE 802.11 SNAP frame format showing the SNAP header and an IP datagram.
Because IEEE 802.11 network adapters are represented inside the Windows Server 2003 family and Windows XP as Ethernet adapters, IEEE 802.11 frames captured with Network Monitor are displayed with an Ethernet II header.


Summary

LAN technology encapsulations provide delimitation, addressing, protocol identification, and bit-level integrity services. IP datagrams and ARP messages sent over Ethernet links are encapsulated using either the Ethernet II or IEEE 802.3 SNAP frame formats. IP datagrams and ARP messages sent over Token Ring links are encapsulated using the IEEE 802.5 SNAP frame format. IP datagrams and ARP messages sent over FDDI links are encapsulated using the FDDI SNAP frame format. IP datagrams and ARP messages sent over IEEE 802.11 links are encapsulated using the IEEE 802.11 SNAP frame format.


Wide Area Network (WAN) Technologies

Chapter 2
Wide Area Network (WAN) Technologies

To successfully troubleshoot TCP/IP problems on a wide area network (WAN), it is important to understand how IP datagrams and Address Resolution Protocol (ARP) messages are encapsulated by a computer running a member of the Microsoft Windows Server 2003 family or Windows XP that uses a WAN technology such as T-carrier, Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), X.25, frame relay, or Asynchronous Transfer Mode (ATM). It is also important to understand WAN technology encapsulations to interpret the WAN encapsulation portions of a frame when using Microsoft Network Monitor or other types of WAN frame capture programs or facilities.


WAN Encapsulations

As discussed in Chapter 1, "Local Area Network (LAN) Technologies," IP datagrams are an Open Systems Interconnection (OSI) Network Layer entity that requires a Data Link Layer encapsulation before being sent on a physical medium. For WAN technologies, the Data Link Layer encapsulation provides the following services:

  • Delimitation Frames at the Data Link Layer must be distinguished from each other, and the frame's payload must be distinguished from the Data Link Layer header and trailer.
  • Protocol identification On a multiprotocol WAN link, protocols such as TCP/IP, Internetwork Packet Exchange (IPX), or AppleTalk must be distinguished from each other.
  • Addressing For WAN technologies that support multiple possible destinations using the same physical link, the destination must be identified.
  • Bit-level integrity check A checksum provides a bit-level integrity check between either the peer nodes on the link or forwarding nodes on a packet-switching network.

This chapter discusses WAN technologies and their encapsulations for IP datagrams and ARP messages. WAN encapsulations are divided into two categories based on the types of IP networks of the WAN link:

  • Point-to-point links support an IP network segment with a maximum of two nodes. These links include analog phone lines, ISDN lines, Digital Subscriber Line (DSL) lines, and T-carrier links such as T-1, T-3, Fractional T-1, E-1, and E-3. Point-to-point links do not require Data Link Layer addressing.
  • Non-broadcast multiple access (NBMA) links support an IP network segment with more than two nodes; however, there is no facility to broadcast a single IP datagram to multiple locations. NBMA links include packet-switching WAN technologies such as X.25, frame relay, and ATM. NBMA links require Data Link Layer addressing.


Point-to-Point Encapsulation

The two most prominent industry standard encapsulations for sending IP datagrams over a point-to-point link are Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP).

SLIP

As RFC 1055 describes, SLIP is a very simple packet-framing protocol that offers only frame delimitation services. SLIP does not provide protocol identification or bit-level integrity verification services. SLIP was designed to be easy to implement for links that did not require these types of services.

SLIP is described in RFC 1055, which can be found in the \Rfc folder on the companion CD-ROM.

To delimit IP datagrams, SLIP uses a special character called the END character (0xC0), which is placed at the beginning and end of each IP datagram. Successive IP datagrams have two END characters between them: one to mark the end of one datagram and one to mark the beginning of another.

The END character presents a problem because if it occurs within the IP datagram and is sent unmodified, the receiving node interprets the END character as the marker for the end of the IP datagram. If this happens, the originally sent IP datagram is truncated and is eventually discarded because of failed checksums in the IP header and upper layer protocol headers. Figure 2-1 shows a SLIP-encapsulated IP datagram.

Figure 2-1. SLIP encapsulation, showing the simple frame delimitation services for an IP datagram.

To prevent the occurrence of the END character within the IP datagram, SLIP uses a technique called character stuffing. The END character is escaped, or replaced, with a sequence beginning with another special character called the ESC (0xDB) character. The SLIP ESC character has no relation to the American Standard Code for Information Interchange (ASCII) ESC character.

If the END character occurs within the original IP datagram, it is replaced with the sequence 0xDB-DC. To prevent the misinterpretation of the ESC character by the receiving node, if the ESC (0xDB) character occurs within the original IP datagram, it is replaced with the sequence 0xDB-DD. Therefore:

  • END characters can occur only at the beginning and end of the SLIP frame.
  • On the sending node, SLIP replaces the END character within the IP datagram with the sequence 0xDB-DC. On the receiving node, SLIP translates the 0xDB-DC sequence back to 0xC0.
  • On the sending node, SLIP replaces the ESC character within the IP datagram with the sequence 0xDB-DD. On the receiving node, the 0xDB-DD sequence is translated back to 0xDB. If the IP datagram contains the sequence 0xDB-DC, the escaping of the ESC character turns this sequence into 0xDB-DD-DC to prevent the receiver from misinterpreting the 0xDB-DC sequence as 0xC0.

Figure 2-2 shows SLIP character stuffing.

Figure 2-2. SLIP character stuffing, showing the escaping of the END and ESC characters within an IP datagram.

As RFC 1055 describes, the maximum size of an IP datagram over a SLIP connection is 1006 bytes—the size imposed by Berkeley UNIX drivers that existed when the RFC was written. Most systems adhere to the industry standard maximum size of 1006 bytes. However, some systems, such as those running the Windows Server 2003 family or Windows XP, allow a maximum packet size of 1500 bytes over a SLIP connection to prevent fragmentation of IP datagrams when SLIP links are used in conjunction with Ethernet network segments.

Although SLIP does not provide for the negotiation of compression methods during the connection setup, SLIP does support a compression scheme known as Compressed SLIP (C-SLIP).

RFC 1144 describes C-SLIP and how it is used to compress IP and TCP headers to a 3- to 5-byte header on the SLIP link. This RFC can be found in the \Rfc folder on the companion CD-ROM.

Dial-up network connections for the Windows Server 2003 family and Windows XP use SLIP and C-SLIP to create SLIP-based remote access connections to a network access server. The incoming connections feature of the Network Connections folder and the Windows Server 2003 family Routing and Remote Access service does not support SLIP or C-SLIP.

PPP

PPP is a standardized point-to-point network encapsulation method that addresses the shortcomings of SLIP and provides Data Link Layer functionality comparable to LAN encapsulations. PPP provides frame delimitation, protocol identification, and bit-level integrity services.

PPP is described in RFC 1661, which can be found in the \Rfc folder on the companion CD-ROM.

RFC 1661 describes PPP as a suite of protocols that provide the following:

  • A Data Link Layer encapsulation method that supports multiple protocols simultaneously on the same link.
  • A protocol for negotiating the Data Link Layer characteristics of the point-to-point connection named the Link Control Protocol (LCP).
  • A series of protocols for negotiating the Network Layer properties of Network Layer protocols over the point-to-point connection named Network Control Protocols (NCPs). For example, RFCs 1332 and 1877 describe the NCP for IP called Internet Protocol Control Protocol (IPCP). IPCP is used to negotiate an IP address, the addresses of name servers, and the use of the Van Jacobsen TCP compression protocol.

This chapter discusses only the Data Link Layer encapsulation. Chapter 4, "Point-to-Point Protocol (PPP)," describes LCP and the NCPs needed for IP connectivity.

PPP encapsulation and framing is based on the International Organization for Standardization (ISO) High-Level Data Link Control (HDLC) protocol. HDLC was derived from the Synchronous Data Link Control (SDLC) protocol developed by IBM for the Systems Network Architecture (SNA) protocol suite. HDLC encapsulation for PPP frames is shown in Figure 2-3.

HDLC encapsulation for PPP frames is described in RFC 1662, which can be found in the \Rfc folder on the companion CD-ROM.
Figure 2-3. PPP encapsulation using HDLC framing for an IP datagram.

The fields in the PPP header and trailer are defined as follows:

  • Flag A 1-byte field set to 0x7E (bit sequence 01111110) that indicates the start and end of a PPP frame. Unlike SLIP, a single Flag character is used between back-to-back PPP frames.
  • Address A 1-byte field that is a by-product of HDLC. In HDLC environments, the Address field is used as a destination address on a multipoint network. PPP links are point-to-point and the destination node is always the other node on the point-to-point link. Therefore, the Address field for PPP encapsulation is set to 0xFF—the broadcast address.
  • Control A 1-byte field that is also an HDLC by-product. In HDLC environments, the Control field is used to implement sequencing and acknowledgments to provide Data Link Layer reliability services. For session-based traffic, the Control field is more than 1 byte long. For datagram traffic, the Control field is 1 byte long and set to 0x03 to indicate an unnumbered information (UI) frame. Because PPP does not provide reliable Data Link Layer services, PPP frames are always UI frames. Therefore, PPP frames always use a 1-byte Control field set to 0x03.
  • Protocol A 2-byte field used to identify the upper layer protocol of the PPP payload. For example, 0x00-21 indicates an IP datagram, 0x00-29 indicates an AppleTalk datagram, and 0x00-2B indicates an IPX datagram.

    For the current list of PPP protocol numbers, see http://www.iana.org/assignments/ppp-numbers.

  • Frame Check Sequence (FCS) A 2-byte field used to provide bit-level integrity services for the PPP frame. The sender calculates the FCS, which is then placed in the FCS field. The receiver performs the same FCS calculation and compares its result with the result stored in this field. If the two FCS values match, the PPP frame is considered valid and is processed further. If the two FCS values do not match, the PPP frame is silently discarded.

The HDLC encapsulation for PPP frames is also used for Asymmetric Digital Subscriber Line (ADSL) broadband Internet connections.

Figure 2-4 shows a typical PPP framing for an IP datagram when using Address and Control field suppression and Protocol field compression.

Figure 2-4. Typical PPP encapsulation for an IP datagram.

This abbreviated form of PPP framing is a result of the following:

  • Because the Address field is irrelevant for point-to-point links, in most cases the PPP peers agree during LCP negotiation to not include the Address field. This is done through the Address and Control Field Compression LCP option.
  • Because the Control is always set to 0x03 and provides no other service, in most cases the PPP peers agree during LCP negotiation to not include the Control field. This, too, is done through the Address and Control Field Compression LCP option.
  • Because the high-order byte of the PPP Protocol field for Network Layer protocols such as IP, AppleTalk, and IPX is always set to 0x00, in most cases the PPP peers agree during LCP negotiation to use a 1-byte Control field. This is done through the Protocol Compression LCP option.
For the Windows Server 2003 family, PPP frames captured with the Network Monitor do not display the HDLC structure, as shown in Figures 2-3 and 2-4. PPP control frames contain simulated source and destination media access control (MAC) addresses and only the PPP Protocol field. PPP data frames contain a simulated Ethernet II header.

PPP on Asynchronous Links

As in SLIP, PPP on asynchronous links such as analog phone lines uses character stuffing to prevent the occurrence of the FLAG character within the PPP payload. The FLAG character is escaped, or replaced, with a sequence beginning with another special character called the ESC (0x7D) character. The PPP ESC character has no relation to the ASCII or SLIP ESC character.

If the FLAG character occurs within the original IP datagram, it is replaced with the sequence 0x7D-5E. To prevent the misinterpretation of the ESC character by the receiving node, if the ESC (0x7D) character occurs within the original IP datagram, it is replaced with the sequence 0x7D-5D. Therefore:

  • FLAG characters can occur only at the beginning and end of the PPP frame.
  • On the sending node, PPP replaces the FLAG character within the IP datagram with the sequence 0x7D-5E. On the receiving node, the 0x7D-5E sequence is translated back to 0x7E.
  • On the sending node, PPP replaces the ESC character within the PPP frame with the sequence 0x7D-5D. On the receiving node, the 0x7D-5D sequence is translated back to 0x7D. If the IP datagram contains the sequence 0x7D-5E, the escaping of the ESC character turns this sequence into 0x7D-5D-5E to prevent the receiver from misinterpreting the 0x7D-5E sequence as 0x7E.

Additionally, character stuffing is used to stuff characters with values less than 0x20 (32 in decimal notation) to prevent these characters from being misinterpreted as control characters when software flow control is used over asynchronous links. The escape sequence for these characters is 0x7D-x, where x is the original character with the fifth bit set to 1. The fifth bit is defined as the third bit from the high-order bit using the bit position designation of 7-6-5-4-3-2-1-0. Therefore, the character 0x11 (bit sequence 0-0-0-1-0-0-0-1) would be escaped to the sequence 0x7D-31 (bit sequence 0-0-1-1-0-0-0-1).

The use of character stuffing for characters less than 0x20 is negotiated using the Asynchronous Control Character Map (ACCM) LCP option. This LCP option uses a 32-bit bitmap to indicate exactly which character values need to be escaped.

For more information on the ACCM LCP option, see RFCs 1661 and 1662. These can be found in the \Rfc folder on the companion CD-ROM.

PPP on Synchronous Links

Character stuffing is an inefficient method of escaping the FLAG character. If the PPP payload consists of a stream of 0x7E characters, character stuffing roughly doubles the size of the PPP frame as it is sent on the medium. For asynchronous, byte-boundary media such as analog phone lines, character stuffing is the only alternative.

On synchronous links such as T-carrier, ISDN, and Synchronous Optical Network (SONET), a technique called bit stuffing is used to mark the location of the FLAG character. Recall that the FLAG character is 0x7E, or the bit sequence 01111110. With bit stuffing, the only time six 1 bits in a row are allowed is for the FLAG character as it is used to mark the start and end of a PPP frame. Throughout the rest of the PPP frame, if there are five 1 bits in a row, a 0 bit is inserted into the bit stream by the synchronous link hardware. Therefore, the bit sequence 111110 is stuffed to produce 1111100 and the bit sequence 111111 is stuffed to become 1111101. Therefore, six 1 bits in a row cannot occur except for the FLAG character when it is used to mark the start and end of a PPP frame. If the FLAG character does occur within the PPP frame, it is bit stuffed to produce the bit sequence 011111010. Bit stuffing is much more efficient than character stuffing. If stuffed, a single byte becomes 9 bits, not 16 bits, as is the case with character stuffing. With synchronous links and bit stuffing, data sent no longer falls along bit boundaries. A single byte sent can be encoded as either 8 or 9 bits, depending on the presence of a 11111 bit sequence within the byte.

PPP Maximum Receive Unit

The maximum-sized PPP frame, the maximum transmission unit (MTU) for a PPP link, is known as the Maximum Receive Unit (MRU). The default value for the PPP MRU is 1500 bytes. The MRU for a PPP connection can be negotiated to a lower or higher value using the Maximum Receive Unit LCP option. If an MRU is negotiated to a value lower than 1500 bytes, a 1500-byte MRU must still be supported in case the link has to be resynchronized.

PPP Multilink Protocol

The PPP Multilink Protocol (MP) is an extension to PPP that allows you to bundle or aggregate the bandwidth of multiple physical connections. It is supported by the Windows Server 2003 family and Windows XP Network Connections and the Windows Server 2003 family Routing and Remote Access service. MP takes multiple physical connections and makes them appear as a single logical link. For example, with MP, two analog phone lines operating at 28.8 Kbps appear as a single connection operating at 57.6 Kbps. Another example is the aggregation of multiple channels of an ISDN Basic Rate Interface (BRI) or Primary Rate Interface (PRI) line. In the case of a BRI line, MP makes the two 64-Kbps BRI B-channels appear as a single connection operating at 128 Kbps.

MP is described in RFC 1991, which can be found in the \Rfc folder on the companion CD-ROM.

MP is an extra layer of encapsulation that operates within a PPP payload. To identify an MP packet, the PPP Protocol field is set to 0x00-3D. The payload of an MP packet is a PPP frame or the fragment of a PPP frame. If the size of the PPP payload that would be sent on a single-link PPP connection, plus the additional MP header, is greater than the MRU for the specific physical link over which the MP packet is sent, MP fragments the PPP payload.

MP fragmentation divides the PPP payload along boundaries that will fit within the link's MRU. The fragments are sent in sequence using an incrementing sequence number, and flags are used to indicate the first and last fragments of an original PPP payload. A lost MP fragment causes the entire original PPP payload to be silently discarded.

MP encapsulation has two different forms: the long sequence number format (shown in Figure 2-5) and the short sequence number format. The long sequence number format adds 4 bytes of overhead to the PPP payload.

Figure 2-5. The Multilink Protocol header, using the long sequence number format.

The fields in the MP long sequence number format header are defined as follows:

  • Beginning Fragment Bit Set to 1 on the first fragment of a PPP payload and to 0 on all other PPP payload fragments.
  • Ending Fragment Bit Set to 1 on the last fragment of a PPP payload and to 0 on all other PPP payload fragments. If a PPP payload is not fragmented, both the Beginning Fragment Bit and Ending Fragment Bit are set to 1.
  • Reserved Set to 0.
  • Sequence Number Set to an incrementally increasing number for each MP payload sent. For the long sequence number format, the Sequence Number field is 3 bytes long. The Sequence Number field is used to number successive PPP payloads that would normally be sent over a single-link PPP connection, and is used by MP to preserve the packet sequence as sent by the PPP peer. Additionally, the Sequence Number field is used to number individual fragments of a PPP payload so that the receiving node can detect a fragment loss.

Figure 2-6 shows the short sequence number format, which adds 2 bytes of overhead to the PPP payload.

Figure 2-6. The Multilink Protocol header, using the short sequence number format.

The short sequence format has only 2 reserved bits, and its Sequence Number field is only 12 bits long. The long sequence number format is used by default unless the Short Sequence Number Header Format LCP option is used during the LCP negotiation.


X.25

In the 1970s, a standard set of protocols known as X.25 was created to provide users with a standard way to send packetized data across a packet-switched public data network (PSPDN). Until X.25, PSPDNs and their interfaces were proprietary and completely incompatible. Changing PSPDN vendors meant purchasing new Public Data Network (PDN) interfacing equipment. X.25 is an international standard, as specified by the International Telecommunications Union-Telecommunication sector (ITU-T).

X.25 was developed during a time when the telecommunication infrastructure was largely based on noisy copper cabling. A typical use for PSPDNs at that time was the communication of a dumb terminal with a mainframe computer. Errors in transmission because of noisy cabling could not be recovered by dumb terminal equipment. Therefore, X.25 was designed to provide a reliable data transfer service—an unusual feature for a Data Link Layer protocol. All data sent to the PSPDN using X.25 was reliably received and forwarded to the desired endpoint. The reliable service of X.25 typically is not needed for the communication of more intelligent endpoints using protocol suites such as TCP/IP. However, X.25 is still used as a WAN technology over which to send TCP/IP data because of its international availability.

As Figure 2-7 shows, X.25 defines the interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE). A DTE can be a terminal that does not implement the complete X.25 functionality; as such, it is known as a nonpacket mode DTE. A nonpacket mode DTE is connected to a DCE through a translation device called a packet assembler/disassembler (PAD). X.25 does not attempt to define the nature of the DCE-to-DCE communication within the PSPDN. These details are left to the X.25 vendor.

Figure 2-7. The X.25 WAN service, showing DTE, DCE, PAD, and the X.25 interface to the PSPDN.

End-to-end communication between DTEs is accomplished through a bidirectional and full-duplex logical connection called a virtual circuit. Virtual circuits permit communication between DTEs without the use of dedicated circuits. Data is sent as it is produced, using the bandwidth of the PDN infrastructure more efficiently. X.25 can support permanent virtual circuits (PVCs) or switched virtual circuits (SVCs). A PVC is a path through a packet-switching network that is statically programmed into the switches. An SVC is a path through a packet-switching network that is negotiated using a signaling protocol each time a connection is initiated.

Once a virtual circuit is established, a DTE sends a packet to the other end of a virtual circuit using an X.25 virtual-circuit identifier called the Logical Channel Number (LCN). The DCE uses the LCN to forward the packet within the PDN to the appropriate destination DCE.

X.25 encompasses the Physical, Data Link, and Network Layers of the OSI model.

  • Physical Layer X.25 can use a variety of interface standards such as X.21bis (roughly equivalent to EIA/TIA232C [formerly RS-232-C]) or V.35.
  • Data Link Layer X.25 at the Data Link Layer uses a framing called Link Access Procedure-Balanced (LAPB), another variant of the HDLC protocol.
  • Network Layer X.25 at the Network Layer uses a framing called Packet Layer Protocol (PLP). For X.25 SVCs, X.25 call setup packets contain a connection establishment address known as an X.121 address, also referred to as an International Data Number (IDN). X.121 addresses have a variable length (up to 14 decimal digits). Once the SVC is created, the LCN is used for data transfer. User data transfer is performed reliably between endpoints using flow control, sequencing, and acknowledgments.

Although X.25 is defined at the Physical, Data Link, and Network Layers of the OSI model, relative to sending IP datagrams, X.25 is a Data Link and Physical Layer technology.

Typical packet sizes for X.25 PSPDNs are 128, 256, or 512 bytes. User information, such as IP datagrams that are beyond the packet size of the X.25 PSPDN, are segmented by X.25 and reliably reassembled.

X.25 Encapsulation

X.25 encapsulation can take two different forms:

  • If IP datagrams are the only type of data being sent across the virtual circuit, IP traffic is identified by setting the 1-byte Network Layer Protocol Identifier (NLPID) to 0xCC in the first octet in the Call User Data (CUD) field of the X.25 Call Request packet. IP datagrams are encapsulated with the X.25 PLP and LAPB headers.
  • If IP datagrams are one of many types of data being sent across the virtual circuit (a multiprotocol link), the NLPID in the CUD field of the X.25 Call Request packet is set to 0x00 to indicate null encapsulation. IP datagrams are encapsulated with the NLPID header set to 0xCC and the X.25 PLP and LAPB headers.
X.25 encapsulation of IP datagrams is described in RFC 1356, which can be found in the \Rfc folder on the companion CD-ROM.

Figure 2-8 shows the X.25 encapsulation for IP datagrams on a multiprotocol link.

Figure 2-8. X.25 encapsulation of IP datagrams for a multiprotocol link.

NLPID

For multiprotocol virtual circuits, the 1-byte NLPID field is present and set to 0xCC to indicate an IP datagram. For a single protocol virtual circuit, the NLPID field is not present. If the IP datagram is fragmented, the NLPID is fragmented along with the IP datagram.

PLP Header

The fields in the X.25 PLP header are defined as follows:

  • General Format Indicator (GFI) A 4-bit field that identifies the PLP payload as a user data or an X.25 message, the packet numbering scheme (modulo 8 or modulo 128), and whether delivery confirmation with the endpoint is required.
  • Logical Channel Number (LCN) A 12-bit field that identifies the virtual circuit over which the X.25 packet is to travel. The LCN is only locally significant between the DTE and DCE. When an X.25 connection is negotiated, an X.25 LCN is assigned so that the originating node can multiplex data to the proper destination. Up to 4095 virtual circuits can be identified (LCN = 0 is used for X.25 signaling). The first 4 bits of the LCN were originally defined for use as a Logical Group Number (LGN). The LGN was intended for use as a method of bundling multiple logical X.25 channels together for X.25 virtual circuit routing, but it was never used. However, the concept of having a two-level hierarchy for virtual circuit identification is used for ATM.
  • Packet Type Identifier For X.25 protocol messages, the 1-byte Packet Type Identifier field identifies the type of X.25 message. When user data is being sent, the Packet Type Identifier field is used to provide sequencing, acknowledgments, and X.25 fragmentation.

RFC 1356 sets the IP MTU for X.25 networks at 1600 bytes. However, most X.25 networks support only X.25 packet sizes of 128, 256, or 512 bytes. To accommodate the sending of a 1600-byte IP datagram over an X.25 network, X.25 fragments the IP datagram along boundaries that will fit on the X.25 network. A bit within the PTI field called the M-bit is used for fragment delimitation. Similar to the More Fragments flag in the IP header, the M-bit in the X.25 PLP header is set to 1 if more fragments follow, and set to 0 for the last fragment. Unlike IP fragmentation, X.25 fragmentation recovers from lost fragments.

LAPB Header and Trailer

The following fields are present in the LAPB header and trailer:

  • Flag As in PPP frames, the 1-byte Flag field is set to 0x7E to mark the beginning and end of the X.25 frame. Bit stuffing is used on synchronous links, and character stuffing is used on asynchronous links to prevent the occurrence of the flag character within the X.25 frame.
  • Address A 1-byte field used to specify X.25 commands and responses.
  • Control A 1-byte field that provides further qualifications of command and response frames, and also indicates the frame format and function. For X.25 protocol messages, the Control field provides sending and receiving sequence numbers.
  • Frame Check Sequence (FCS) A 2-byte cyclical redundancy check (CRC) used to check for errors in the LAPB frame.


Frame Relay

When packet-switching networks were first introduced, they were based on existing analog copper lines that experienced a high number of errors. X.25 was designed to compensate for these errors and provide connection-oriented reliable data transfer. In these days of high-grade digital fiber-optic lines, there is no need for the overhead associated with X.25. Frame relay is a packet-switched technology similar to X.25, but without the added framing and processing overhead to provide guaranteed data transfer. Unlike X.25, frame relay does not provide link-to-link reliability. If a frame in the frame relay network is corrupted in any way, it is silently discarded. Upper layer communication protocols such as TCP must detect and recover discarded frames.

A key advantage frame relay has over private-line facilities, such as T-Carrier, is that frame relay customers can be charged based on the amount of data transferred, instead of the distance between the endpoints. It is common, however, for the frame relay vendor to charge a fixed monthly cost. In either case frame relay is distance-insensitive. A local connection, such as a T-1 line, to the frame relay vendor's network is required. Frame relay allows widely separated sites to exchange data without incurring long-haul telecommunications costs.

Frame relay is a packet-switching technology defined in terms of a standardized interface between user devices (typically routers) and the switching equipment in the vendor's network (frame relay switches).

Frame relay is similar to X.25 in the following ways:

  • A packet-switching technology designed to send variable-sized packets.
  • Designed for the transfer of LAN traffic (computer communication protocols such as TCP/IP).
  • Provides a mechanism for multiplexing multiple logical connections (virtual circuits) over a single physical link.

However, frame relay differs from X.25 in the following ways:

  • Frame relay is an unreliable data transfer service. Frame relay switches silently discard frames lost as a result of congestion or corruption.
  • Frame relay provides no flow control. However, frame relay does provide for basic congestion notification that can be used to notify upper layer protocols to implement their own flow control.

Typical frame relay service providers currently only offer PVCs. The frame relay service provider establishes the PVC when the service is ordered. A new standard for an SVC version of frame relay uses the ISDN signaling protocol as the mechanism for establishing the virtual circuit. This new standard is not widely used in production networks.

Frame relay speeds range from 56 Kbps to 1.544 Mbps. The required throughput for a given link determines the committed information rate (CIR). The CIR is the throughput guaranteed by the frame relay service provider. Most frame relay service providers allow a customer to transmit bursts above the CIR for short periods of time. Depending on congestion, the bursted traffic can be delivered by the frame relay network. However, traffic that exceeds the CIR is delivered on a best-effort basis only. This flexibility allows for network traffic spikes without dropping frames.

Frame Relay Encapsulation

Frame relay encapsulation of IP datagrams is based on HDLC, as RFC 2427 describes. Unlike X.25, frame relay encapsulation assumes that multiple protocols are sent over each Frame Relay virtual circuit. IP datagrams are encapsulated with the NLPID header set to 0xCC and a Frame Relay header and trailer. Figure 2-9 shows the frame relay encapsulation for IP datagrams.

HDLC, as the basis for frame relay encapsulation of IP datagrams, is described in RFC 2427, which can be found in the \Rfc folder on the companion CD-ROM.
Figure 2-9. Frame relay encapsulation for IP datagrams, showing the Frame Relay header and trailer.

The fields in the Frame Relay header and trailer are defined as follows:

  • Flag As in PPP and X.25 frames, the Flag field is 1 byte long and is set to 0x7E to mark the beginning and end of the Frame Relay frame. Bit stuffing is used on synchronous links to prevent the occurrence of the Flag character within the Frame Relay frame.
  • Address The Address field is multiple bytes long (typically 2 bytes), and contains the Frame Relay virtual circuit identifier called the Data Link Connection Identifier (DLCI) and congestion indicators. The Address field's structure is discussed in the section entitled "Frame Relay Address Field," later in this chapter.
  • Control A 1-byte field set to 0x03 to indicate a UI frame.
  • NLPID A 1-byte field set to 0xCC to indicate an IP datagram.
  • Frame Check Sequence A 2-byte CRC used for bit-level integrity verification in the Frame Relay frame. If a Frame Relay frame fails integrity verification, it is silently discarded.

Frame Relay Address Field

The Frame Relay Address field can be 1, 2, 3, or 4 bytes long. Typical frame relay implementations use a 2-byte Address field, as shown in Figure 2-10.

Figure 2-10. A 2-byte Frame Relay Address field.

The fields within the 2-byte Address field are defined as follows:

  • DLCI The first 6 bits of the first byte and the first 4 bits of the second byte comprise the 10-bit DLCI. The DLCI is used to identify the Frame Relay virtual circuit over which the Frame Relay frame is traveling. Like the X.25 LCN, the DLCI is only locally significant. Each Frame Relay switch changes the DLCI value as it forwards the Frame Relay frame. The devices at each end of a virtual circuit use a different DLCI value to identify the same virtual circuit. Table 2-1 lists the defined values for the DLCI.
    Table 2-1. Defined Values for the Frame Relay DLCI
    DLCI Value Use

    0

    In-channel signaling

    1-15

    Reserved

    16-991

    Assigned to user connections

    992-1022

    Reserved

    1023

    In-channel signaling

  • Extended Address (EA) The last bit in each byte of the Address field is the EA bit. If this bit is set to 1, the current byte is the last byte in the Address field. For the 2-byte Address field, the value of the EA bit in the first byte of the Address field is 0, and the value of the EA bit in the second byte of the Address field is 1.
  • Command/Response (C/R) The seventh bit in the first byte of the Address field is the C/R bit. It currently is not used for frame relay operations, and is set to 0.
  • Forward Explicit Congestion Notification (FECN) The fifth bit in the second byte of the Address field is the FECN bit. It is used to inform the destination Frame Relay node that congestion exists in the path from the source to the destination. The FECN bit is set to 0 by the source Frame Relay node, and set to 1 by a Frame Relay switch if it is experiencing congestion in the forward path. If the destination Frame Relay node receives a Frame Relay frame with the FECN bit set, the node can indicate the congestion condition to upper layer protocols that can implement receiver-side flow control. The interpretation of the FECN bit for IP traffic is not defined.
  • Backward Explicit Congestion Notification (BECN) The sixth bit in the second byte of the Address field is the BECN bit. The BECN bit is used to inform the destination Frame Relay node that congestion exists in the path from the destination to the source (in the opposite direction in which the frame was traveling). The BECN bit is set to 0 by the source Frame Relay node, and set to 1 by a Frame Relay switch if it is experiencing congestion in the reverse path. If the destination Frame Relay node receives a Frame Relay frame with the BECN bit set, the node can indicate the congestion condition to upper layer protocols that can implement sender-side flow control. The interpretation of the BECN bit for IP traffic is not defined.
  • Discard Eligibility (DE) The seventh bit in the second byte of the Address field is the DE bit. Frame Relay switches use the DE bit to decide which frames to discard during a period of congestion. Frame Relay switches consider the frames with the DE bit set to be a lower priority and discards them first. The initial Frame Relay switch sets the DE bit to 1 on a frame when a customer has exceeded the CIR for the virtual circuit.

The maximum-sized frame that can be sent across a frame relay network varies according to the frame relay provider. RFC 2427 requires all frame relay networks to support a minimum frame size of 262 bytes, and a maximum frame size of 1600 bytes, although maximum frame sizes of up to 4500 bytes are common. Using a maximum frame size of 1600 bytes and a 2-byte address field, the IP MTU for frame relay is 1592.


ATM

ATM, or cell relay, is the latest innovation in broadband networking and is destined to eventually replace most existing WAN technologies. As with frame relay, ATM provides a connection-oriented, unreliable delivery service. ATM allows for the establishment of a connection between sites, but reliable communication is the responsibility of an upper layer protocol such as TCP.

ATM improves on the performance of frame relay. Instead of using variable-length frames, ATM takes a LAN traffic protocol data unit (PDU) such as an IP datagram and segments it into 48-byte segments. A 5-byte ATM header is added to each segment. The 53-byte ATM frames consisting of the segments of the IP datagram are sent over the ATM network, which the destination then reassembles. The fixed-length 53-byte ATM frame, known as an ATM cell, allows the performance of the ATM-switching network to be optimized.

ATM is available today as a PVC or an SVC through an ATM-switched network. ATM has been demonstrated at data rates up to 9.6 gigabits per second (Gbps) using SONET, an international specification for fiber-optic communication. ATM is a scalable solution for data, voice, audio, fax, and video, and can accommodate all of these information types simultaneously. ATM combines the benefits of circuit switching (fixed-transit delay and guaranteed bandwidth) with the benefits of packet switching (efficiency for bursty traffic).

The ATM Cell

The ATM cell consists of a 5-byte ATM header and a 48-byte payload. The following are two types of ATM headers:

  • User network interface (UNI) header The ATM header that exists within a private network or between a customer site and a public ATM service provider.
  • Network-to-network interface (NNI) header The ATM header that exists within a public ATM service provider's network.

Figure 2-11 shows the ATM cell header format at either a public or private UNI.

Figure 2-11. The ATM header format that exists at the ATM UNI.

The fields in the ATM header are defined as follows:

  • Generic Flow Control (GFC) A 4-bit field that was originally added to support the connection of ATM networks to shared access networks such as a Distributed Queue Dual Bus (DQDB) ring. The GFC field was designed to give the UNI 4 bits in which to negotiate multiplexing and flow control among cells of a single ATM virtual circuit. However, the use and exact values of the GFC field have not been standardized, so the value is always set to 0x0.
  • Virtual Path Identifier (VPI) The identifier of the virtual path for this particular cell. VPIs for a particular ATM virtual circuit are discovered during the virtual-circuit setup process for SVCs, and they are manually configured for PVCs. At the UNI, the VPI is 8 bits, allowing up to 256 different virtual paths. VPI 0 exists by default on all ATM equipment and is used for administrative purposes, such as signaling to create and delete dynamic ATM connections.
  • Virtual Channel Identifier (VCI) The identifier of the virtual channel within the specified virtual path. Like VPIs, VCIs are dynamically allocated for SVC connections and manually configured for PVC connections. The VCI is 16 bits, allowing up to 65,536 different virtual channels for each virtual path. For each VPI, the ITU reserves VCIs 0 through 15, and the ATM Forum reserves VCIs 16 through 32. The reserved VCIs are used for signaling, operation and maintenance, and resource management.

    The combination of VPI and VCI identifies the virtual circuit for a given ATM cell and comprises the ATM routing information that is used by ATM switches to forward the cell to its destination. The VPI/VCI combination acts as a local virtual circuit identifier in the same way as an LCN in X.25 and the DLCI in frame relay.

  • Payload Type Indicator (PTI) A 3-bit field consisting of the following fields:
    • ATM Cell Type The first bit of the PTI field is used as an indicator of the type of ATM cell. Set to 0 to indicate user data, and set to 1 to indicate operations, administration, and management (OA&M) data.
    • Explicit Forward Congestion Indication (EFCI) The second bit of the PTI field is used as an indicator of whether the cell experienced congestion in its journey from the source to the destination. The source sets the EFCI bit to 0. If an interim switch is experiencing congestion during the forwarding of the cell, the switch sets the bit to 1. Once set to 1, all other switches in the path leave this bit set at 1. Destination ATM endpoints can use the EFCI bit to implement receiver-side flow control mechanisms until cells with an EFCI bit set to 0 are received. The EFCI bit is similar in function to the FECN bit used in frame relay.
    • AAL5 Segmentation Flag Used in user ATM cells to indicate the last cell in a block for ATM Adaptation Layer 5 (AAL5). For nonuser ATM cells, the third bit is used for OA&M functions. AAL5 is described in detail in the section entitled "AAL5," later in this chapter.
  • Cell Loss Priority (CLP) A 1-bit field that is used as a cell priority indicator. If set to 0, the cell is high priority and interim switches must make every effort to forward the cell successfully. If the CLP bit is set to 1, the interim switches can elect to discard the cell in congestion situations. The CLP bit is similar to the DE bit in frame relay. Setting the CLP bit to 1 can be done by the ATM endpoint on creation, as a way to indicate a lower priority cell, or at the ATM switch, if the cell is beyond the negotiated parameters of the vir- tual circuit (similar to bursting above the CIR in frame relay).
  • Header Error Check (HEC) A 1-byte field that allows an ATM switch or ATM endpoint to correct a single-bit error, or to detect multibit errors in the first 4 bytes of the ATM header. Multibit errored cells are silently discarded. Note that the HEC checks only the ATM header and not the ATM payload. Checking the payload for errors is the responsibility of upper layer protocols.

Figure 2-12 shows the ATM cell header format at the public NNI.

Figure 2-12. The ATM header format that exists at the ATM NNI.

The only differences between the UNI and NNI headers are as follows:

  • No GFC field ATM switches in an ATM service provider do not need a way to negotiate the multiplexing for various types of shared-access user connections.
  • VPI is now 12 bits long This allows up to 4096 virtual paths per transmission path. With an extended VPI, ATM service providers have more flexibility to perform virtual path switching and to create a backbone architecture to support trunk lines in the voice telephone system.

ATM Architecture

The ATM architectural model (known as the B-ISDN/ATM Model) has three main layers, as shown in Figure 2-13.

Figure 2-13. The ATM architectural model, showing the three main layers and their sublayers.

Physical Layer

The Physical Layer provides for the transmission and reception of ATM cells across a physical medium between two ATM devices. The Physical Layer is subdivided into a Physical Medium Dependent (PMD) sublayer and Transmission Convergence (TC) sublayer.

The PMD sublayer is responsible for the transmission and reception of individual bits on a physical medium. These responsibilities encompass bit-timing, signal-encoding, interfacing with the physical medium, and the physical medium itself. ATM does not rely on any specific bit rate, encoding scheme, or medium. Various specifications for ATM exist for coaxial cable, shielded and unshielded twisted-pair wire, and optical fiber at speeds ranging from 64 Kbps through 9.6 Gbps.

The TC sublayer acts as a converter between the bit stream at the PMD sublayer and ATM cells. When transmitting, the TC sublayer maps ATM cells onto the format of the PMD sublayer (such as DS-3 or SONET frames). Because a continuous stream of bytes is required, idle cells occupy portions in the ATM cell stream that are not used. The receiver silently discards idle cells so they are never passed to the ATM layer for processing. The TC sublayer also is responsible for generation and verification of the HEC field for each cell, and for determining ATM cell delineation (where the ATM cells begin and end).

ATM Layer

The ATM Layer provides cell multiplexing, demultiplexing, and VPI/VCI routing functions. In addition, the ATM Layer is responsible for supervising the cell flow to ensure that all connections remain within their negotiated cell throughput limits. The ATM Layer can take corrective action so that those connections operating outside their negotiated parameters do not affect those connections that are obeying their negotiated connection parameters. Additionally, the ATM Layer ensures that the cell sequence from any source is maintained.

The ATM Layer multiplexes and demultiplexes, routes ATM cells, and ensures their sequence from end to end. However, if a switch drops a cell because of congestion or corruption, it is not the ATM Layer's responsibility to correct the dropped cell through retransmission or to notify other layers of the dropped cell. Layers above the ATM Layer must sense the lost cell and decide whether to correct for its loss.

ATM Adaptation Layer

The ATM Adaptation Layer (AAL) is responsible for the creation and reception of 48-byte payloads using the ATM Layer on behalf of different types of applications. The AAL is subdivided between the Convergence sublayer (CS) and the Segmentation and Reassembly (SAR) sublayer. ATM adaptation is necessary to interface the cell-based technology at the ATM Layer, to the bit-stream technology of digital devices (such as telephones and video cameras), and the packet-stream technology of modern data networks (such as frame relay or LAN protocols, including TCP/IP).

Convergence Sublayer

The CS is the last place that an application block of data (also known as a PDU) has its original form before being handed to the SAR sublayer for division into 48-byte ATM payloads. The CS is responsible for an encapsulation that allows the application data block to be distinguished and handed to the destination application. The CS is further subdivided into two sublayers: the Common Part CS (CPCS), which must be implemented, and the Service Specific CS (SSCS), which might be implemented depending on the actual service. If the SSCS is not implemented, it does not add headers to the data being sent.

SAR Sublayer

On the sending side, the SAR sublayer takes the block of data from the CS (hereafter known as the CPCS PDU) and divides it into 48-byte segments. Each segment is then handed to the ATM Layer for final ATM encapsulation. On the receiving side, the SAR sublayer receives each ATM cell and reassembles the CPCS PDU. The completed CPCS PDU is then handed up to the CS for processing.

To provide a standard mechanism for the CPCS and SAR sublayers, the ITU-T has created a series of ATM Adaptation Layers as follows:

  • AAL1 Designed for isochronous (time-dependent), constant bit rate, connection-oriented applications, and used to provide circuit emulation.
  • AAL2 Designed for isochronous, variable bit rate, connection-oriented applications, and used for compressed voice or video.
  • AAL3/4 Designed for non-isochronous, variable bit rate, connection-oriented or connectionless applications, and used for X.25 or LAN traffic.
  • AAL5 Designed for non-isochronous, variable bit rate, connection-oriented or connectionless applications. It is typically used for LAN traffic such as IP datagrams because its overhead is lower than that of AAL3/4.

AAL5

AAL5 provides a way for non-isochronous, variable bit rate, connectionless applications to send and receive data. The data communications industry developed AAL5 as a straightforward framing at the CPCS that tends to behave like existing LAN technologies such as Ethernet. AAL5 is the AAL of choice when sending connection-oriented (frame relay) or connectionless (IP or IPX) LAN protocol traffic over an ATM network.

AAL5 Framing

Figure 2-14 shows the framing that occurs at AAL5.

Figure 2-14. AAL5 framing, showing the payload and the AAL5 trailer.

The fields in the AAL5 frame are defined as follows:

  • Payload The block of data that an application sends. The size can vary from 1 byte to 65,535 bytes.
  • Pad Of variable length (0-47 bytes). The Pad field is present to make the entire CPCS PDU an integral number of 48-byte units.
  • User To User Indication A 1-byte field that is used to transfer information between AAL users. The exact use of this byte is not defined and is left to the implementation.
  • Common Part Indicator A 1-byte field that is currently used only for alignment processes so that the nonpadded portion of the AAL5 trailer is on a 64-bit boundary.
  • Length of Payload A 2-byte field used to indicate the length in bytes of the Payload field so that the receiver can discard the Pad field.
  • CRC A 4-byte CRC that provides bit-level integrity services on the entire CPCS PDU. The AAL5 CRC uses the same checksum algorithm as IEEE 802 network technologies such as Ethernet (IEEE 802.3) and Token Ring (IEEE 802.5).

The SAR sublayer for AAL5 segments the CPCS PDU along 48-byte boundaries and passes the segments to the ATM Layer for encapsulation with an ATM header. On the receiving side, the SAR sublayer reassembles the incoming 48-byte ATM payloads and passes the result to the CPCS. The SAR uses the AAL5 Segmentation Flag field, the third bit in the PTI field, to indicate when the last 48-byte unit in a CPCS PDU is sent. On the receiving side, when the ATM cell is received with the AAL5 Segmentation Flag field set, the ATM Layer indicates this to AAL5 so that analysis of the full CPCS PDU can begin.

Sending an IP Datagram Over an ATM Network

The method of sending IP datagrams over an ATM network using AAL5 is known as classical IP over ATM, and is described in RFCs 1577 and 1626. To ensure compatibility with IP datagrams sent over a Switched Multimegabit Data Service (SMDS) network, another cell-based WAN technology, IP datagrams have a maximum size of 9180 bytes. Figure 2-15 shows IP datagram encapsulation using AAL5.

RFCs 1577 and 1626 describe classical IP over ATM. These can be found in the \Rfc folder on the companion CD-ROM.
Figure 2-15. IP datagram encapsulation using AAL5.

At the SAR sublayer, the CPCS PDU is segmented into 48-byte units that become the ATM payloads for a stream of ATM cells. When the last cell in the CPCS PDU is sent, the AAL5 Segmentation Flag field is set to 1. When the last cell is received, the receiver uses the CRC to check the validity of the bits in the CPCS PDU. If the CRC is valid, the Length field is used to discard the Pad field. The AAL trailer is stripped, and the end result is the originally transmitted IP datagram that is then passed to the IP layer for processing.

For a given ATM virtual circuit, IP datagrams must be sent one at a time. The cells of multiple IP datagrams cannot be mixed on the same virtual circuit. The ATM header contains no information to signify which cells belong to which CPCS PDU. ATM segmentation differs from IP fragmentation in this regard. With IP fragmentation, the Identification field serves to group all the fragments of the original IP datagram together. An IP router can send the fragments of different IP packets alternately without a reconstruction issue on the receiving side. With ATM segmentation, there is no fragment ID field or equivalent that can be used to differentiate CPCS PDUs.

Example of Sending an IP Datagram

Figure 2-16 shows an example of sending a 128-byte IP datagram across an ATM network using AAL5.

Figure 2-16. Example of sending an IP datagram over ATM using AAL5 encapsulation.

The AAL5 trailer with an 8-byte Pad field is added to the IP datagram. The 8 bytes of the Pad field make the entire AAL5 CPCS PDU 144 bytes, an integral multiple of 48. The resulting AAL5 CPCS PDU is then segmented into three 48-byte segments. Each 48-byte segment becomes the payload of an ATM cell sent in sequence to the destination ATM endpoint on the virtual circuit. When the last segment is sent, the AAL5 Segmentation Flag field is set to 1.

For the Windows Server 2003 family, ATM traffic captured with Network Monitor does not display the individual ATM cells or the ATM header. The ATM header displayed with Network Monitor contains a simulated source and destination MAC address and the VPI and VCI fields for the virtual circuit.

Multiprotocol Encapsulation with AAL5

When multiple protocols are sent over the same ATM virtual circuit, a protocol identifier is needed to differentiate the various Network Layer protocols.

Multiprotocol encapsulation over ATM is described in RFC 1483, which can be found in the \Rfc folder on the companion CD-ROM.

To add a protocol identifier to the CPCS PDU, the Sub-Network Access Protocol (SNAP) method used by IEEE 802.x networks is used. Figure 2-17 shows multiprotocol encapsulation over AAL5.

Figure 2-17. Multiprotocol encapsulation for AAL5, using the LLC and SNAP headers.

As described in Chapter 1, "Local Area Network (LAN) Technologies," the SNAP header consists of a Logical Link Control (LLC) header and a SNAP header. Within the LLC header, the Destination Service Access Point is set to 0xAA, the Source Service Access Point is set to 0xAA, and the Control field is set to 0x03. Within the SNAP header, the Organization Unique Identifier is set to 00-00-00 and the EtherType field is set to 0x08-00 for IP.

When the ATM virtual circuit is created, both ATM endpoints negotiate the use of either single-protocol or multiprotocol AAL5 encapsulation.


Summary

Typical WAN technology encapsulations used by the Windows Server 2003 family and Windows XP provide delimitation, addressing, protocol identification, and bit-level integrity services. IP datagrams and ARP messages sent over point-to-point WAN links can be encapsulated using SLIP, PPP, or MP. IP datagrams and ARP messages sent over NBMA links such as X.25, frame relay, or ATM use the appropriate single or multiprotocol encapsulation.


Address Resolution Protocol (ARP)

Chapter 3
Address Resolution Protocol (ARP)

To successfully troubleshoot problems forwarding IP datagrams on a local area network (LAN) link, it is important to understand how Address Resolution Protocol (ARP) is used to resolve a node's IP address to its corresponding Network Interface Layer address. TCP/IP for the Microsoft Windows Server 2003 family and Windows XP supports ARP for address resolution and duplicate IP address detection. The Network Bridge for the Windows Server 2003 family and Windows XP and the Routing and Remote Access service for the Windows Server 2003 family uses a variation of ARP called proxy ARP to forward IP datagrams between nodes on separate segments of a subdivided subnet.


Overview of ARP

ARP is the protocol used by shared access, broadcast-based networking technologies such as Ethernet and Token Ring. This protocol is used to resolve the next-hop IP address of a node to its corresponding media access control (MAC) address. The MAC address also is known as the physical, hardware, or network adapter address. The resolved MAC address becomes the destination MAC address in the Ethernet or Token Ring header to which an IP datagram is addressed when it is sent on the medium. ARP resolves an Internet Layer address (an IP address) to a Network Interface Layer address (a MAC address).

ARP is described in RFC 826, which can be found in the \Rfc folder on the companion CD-ROM.

The next-hop IP address is not necessarily the same as the destination IP address of the IP datagram. As is discussed in detail in Chapter 7, "Internet Protocol (IP) Routing," the result of the route determination process for every outgoing IP datagram is a next-hop interface and a next-hop IP address. For direct deliveries to destinations on the same subnet, the next-hop IP address is the datagram's destination IP address. For indirect deliveries to remote destinations, the next-hop IP address is the IP address of a router on the same subnet as the forwarding host.

IP was designed to be independent of any specific Network Interface Layer technology. Therefore, there is no way to determine the destination Network Interface Layer address from the next-hop IP address. For example, Ethernet and Token Ring MAC addresses are 6 bytes long, and IP addresses are 4 bytes long. During the manufacturing process, the MAC address is assigned to the adapter. A network administrator assigns the IP address (either directly through manual configuration or indirectly through the administration of a Dynamic Host Configuration Protocol [DHCP] server). Because there is no correlation between the assignments of these two addresses for a given IP node, it is impossible to derive oneaddress from the other. ARP is a broadcast-based, request-reply protocol that provides a dynamic address resolution facility to map next-hop IP addresses to their corresponding MAC addresses.

ARP consists of the following two messages:

  • ARP Request The forwarding node uses the ARP Request message to request the MAC address for a specific next-hop IP address. The ARP Request is a MAC-level broadcast frame intended to reach all the nodes on the physical network segment to which the interface sending the ARP Request is attached. The node sending the ARP Request is known as the ARP requester.
  • ARP Reply The ARP Reply message is used to reply to the ARP requester. The node whose IP address matches the requested IP address in the ARP Request message sends the ARP Reply. The ARP Reply is a unicast MAC frame sent to the destination MAC address of the ARP requester. The node sending the ARP Reply is known as the ARP responder.

Because the ARP Request message is a MAC-level broadcast, all next-hop IP addresses to be resolved must be directly reachable (on the same subnet) from the interface used to send the ARP Request. For proper routing table entries, this is always the case. If a routing table entry contains an invalid next-hop IP address and the address is not directly reachable for the interface, ARP fails to resolve the next-hop IP address.

All nodes within the same broadcast domain receive the ARP Request. A broadcast domain is a portion of a network over which a broadcast frame is propagated. Hubs, bridges, and, more recently, Layer 2 switches propagate the ARP Request. However, IP routers or Layer 3 switches do not propagate ARP frames.

The ARP Cache

As is common in many TCP/IP implementations, TCP/IP for the Windows Server 2003 family and Windows XP maintains a RAM-based table of IP and MAC address mappings known as the ARP cache. When an ARP exchange is complete (both the ARP Request and the ARP Reply are sent and received), both the ARP requester and the ARP responder have each other's IP address-to-MAC address mappings in their ARP caches. Subsequent packets forwarded to the previously resolved IP addresses use the ARP cache entry's MAC address. The ARP cache is always checked before an ARP Request is sent. There is a separate ARP cache for each IP interface.

After the MAC address for a next-hop IP address is determined using an ARP Request-ARP Reply exchange, the resolved MAC address is used as the destination MAC address for subsequent packets. If the node whose IP address has already been resolved fails, the ARP requester node continues to use its ARP cache entry and send packets on the medium to the resolved MAC address. Because the resolved MAC address corresponds to a network adapter that is no longer present on the network, all of the network segment's nodes ignore the frame. Because the next-hop IP address was mapped to a MAC address with the ARP cache entry, and the frame was sent on the medium, IP and ARP on the sending node consider the IP datagram to be successfully delivered.

This condition is known as a network black hole; packets sent on the network are dropped and the sender or forwarder is unaware of the condition. The user at the ARP requester computer does not notice this condition until TCP connections or other types of session-oriented traffic begin to time out. This particular type of network black hole persists as long as the entry for the mapping remains in the ARP cache. After the entry is removed, an ARP Request-ARP Reply exchange is attempted again. Because the failed node does not respond to the ARP Request, the lack of an ARP Reply can be used to indicate an unsuccessful delivery of IP packets using the next-hop IP address.

By default, ARP cache entries for the Windows Server 2003 family and Windows XP persist for only 2 minutes. If the ARP cache entry is used within 2 minutes, it is given additional time in 2-minute increments, up to a maximum lifetime of 10 minutes. After a maximum of 10 minutes, the ARP cache entry is removed and must be resolved through another ARP Request-ARP Reply exchange. The time-out of ARP cache entries is configurable with the ArpCacheLife and ArpCacheMinReferencedLife registry settings.

ArpCacheLife

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-0xFFFFFFFF

Default value: 120

Present by default: No

ArpCacheLife sets the number of seconds that an unused ARP cache entry is kept. If the ArpCacheLife entry is not present, the default value of ArpCacheLife is 120 seconds (2 minutes).

ArpCacheMinReferencedLife

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-0xFFFFFFFF

Default value: 600

Present by default: No

ArpCacheMinReferencedLife sets the number of seconds that a used ARP cache entry persists in the ARP cache. The default value of ArpCacheMinReferencedLife is 600 seconds (10 minutes). The ArpCacheMinReferencedLife and ArpCacheLife registry settings are used in the following ways:

  • If ArpCacheLife is greater than or equal to ArpCacheMinReferencedLife, both used and unused ARP cache entries persist for ArpCacheLife seconds.
  • If ArpCacheLife is less than ArpCacheMinReferencedLife, unused ARP cache entries expire in ArpCacheLife seconds, and used entries expire in ArpCacheMinReferencedLife seconds.

In addition, TCP/IP for the Windows Server 2003 family and Windows XP allows the use of static ARP cache entries, which can be added through the use of the Arp utility using the -s command-line option. Static ARP cache entries do not time out of the ARP cache. However, they are stored in RAM and must be added each time TCP/IP is initialized.

While a next-hop IP address is being resolved, ARP for the Windows Server 2003 family and Windows XP stores only one IP datagram for that next-hop IP address. If multiple datagrams are sent to the same next-hop IP address without pause, it is possible that some datagrams might be dropped before the ARP exchange completes. This is not a problem for TCP connection data, but User Datagram Protocol (UDP) messages might experience packet loss because of this behavior. In this case, use the SendArp( ) function to create the ARP cache entry prior to sending packets.

Updating the MAC Address

The default behavior of TCP/IP for the Windows Server 2003 family and Windows XP is to update the ARP cache entry with additional time, in 2-minute increments, while it is in use. Another way of updating the ARP cache entry is through the receipt of an ARP Request sent by the node with the ARP cache entry's IP address. When an ARP Request that was sent by an IP node corresponding to an existing entry in the ARP cache isreceived, the ARP cache entry is updated with the received ARP Request's MAC address.

When a network black hole is caused by a failed interface, and when the interface is replaced, the first ARP Request frame sent on that interface contains the interface's new MAC address. After receipt of that ARP Request, all of the network segment's nodes that have an ARP cache entry for that node's IP address update the ARP cache entry with the new MAC address. The network black hole is removed by the resetting of ARP cache entries when the ARP Request is sent.

ARP Registry Settings

By default, the Windows Server 2003 family and Windows XP use the Ethernet II encapsulation described in Chapter 1, "Local Area Network (LAN) Technologies," when sending both IP and ARP frames. The TCP/IP protocol for the Windows Server 2003 family and Windows XP receives both Ethernet II and IEEE 802.3 Sub-Network Access Protocol (SNAP)-encapsulated frames, but, by default, they respond only with Ethernet II-encapsulated frames. To send IEEE 802.3 SNAP-encapsulated IP and ARP frames, use the ArpUseEtherSNAP registry setting.

ArpUseEtherSNAP

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-1

Default value: 0

Present by default: No

ArpUseEtherSNAP either enables (when set to 1) or disables (when set to 0) the use of the IEEE 802.3 SNAP frame format when sending IP and ARP frames. ArpUseEtherSNAP is disabled by default, meaning that IP and ARP frames are sent with Ethernet II encapsulation. Regardless of the ArpUseEtherSNAP setting, both types of frame formats are received.

For Token Ring, the ArpTRSingleRoute and ArpAlwaysSourceRoute provide control over broadcast ARP Requests in a Token Ring source-routed environment.

ArpTRSingleRoute

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-1

Default value: 0

Present by default: No

ArpTRSingleRoute either disables (when set to 0) or enables (when set to 1) the sending of ARP Requests as single-route broadcasts. When disabled, the default ARP Requests are sent as all-routes broadcasts.

A Token Ring source-routed environment is a series of rings connected by source-routing bridges. The rings can be connected so that there are multiple paths to any given node. Although this creates fault tolerance for the source-routing bridges, it also causes a problem for all-routes broadcast frames. An all-routes broadcast frame travels all possible paths. If there are five different paths between a node sending an all-routes broadcast frame and a ring, five copies of that all-routes broadcast frame appear on that ring.

To prevent this problem, nodes are configured to send single-route broadcast frames, and source-routing bridges are configured to either propagate single-route or all-routes broadcast frames. With proper design, a network administrator can define a single path over which single-route broadcast traffic travels even though multiple paths for all-routes broadcast traffic exist. Using single-route broadcasts, a Token Ring environment can maintain its fault tolerance and avoid the duplication of broadcast traffic.

ArpAlwaysSourceRoute

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-1 or not present

Default value: Not present

Present by default: No

ArpAlwaysSourceRoute either disables (when set to 0) or enables (when set to 1) the use of source routing on broadcast ARP Requests. When the ArpAlwaysSourceRoute setting is not present in the registry, the default setting causes the ARP to send the ARP Request without source routing first. If no reply is received, ARP sends the ARP Request with source routing.

To enable communication with a Network Load Balancing (NLB) cluster that is operating in multicast mode, use the EnableBcastArpReply setting.

EnableBcastArpReply

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-1

Default value: 1

Present by default: No

EnableBcastArpReply either enables (when set to 1) or disables (when set to 0) the use of a multicast MAC address in the Sender Hardware Address (SHA) field in an ARP Reply message. NLB clusters that are operating in multicast mode use a multicast MAC address for their hardware address. This multicast address is the value of the SHA field in an ARP Reply sent by a cluster member when responding to an ARP Request for the IP address of the cluster. If a host on the same subnet as the NLB cluster does not support the use of a multicast MAC address in the SHA field of an ARP Reply, communication with the cluster is not possible. EnableBcastArpReply is enabled by default.


ARP Frame Structure

ARP frames use the EtherType of 0x0806. ARP is not a client protocol of IP, and ARP frames do not contain an IP header. Thus, ARP is useful only for resolving MAC addresses for IP addresses that are on the same physical network segment, the boundaries of which are defined by IP routers. IP routers never forward an ARP Request or ARP Reply frame.

As RFC 826 describes, an ARP frame's structure suggests that ARP could be used for MAC address resolution for protocols other than IP. However, in practice, IP is the only protocol that uses the ARP frame format. Figure 3-1 shows the structure of the ARP frame.

Figure 3-1. The structure of an ARP frame for LAN technologies.
ARP as a potential MAC address resolution for non-IP protocols is discussed in RFC 826, which can be found in the \Rfc folder on the companion CD-ROM.

The fields in the ARP header are defined as follows:

  • Hardware Type A 2-byte field that indicates the type of hardware being used at the Data Link Layer. Table 3-1 lists some commonly used ARP Hardware Type values. After receipt of an ARP frame, an IP node verifies that the Hardware Type value of the ARP frame matches the Hardware Type value of the interface on which the ARP frame was received. If it does not match, the frame is silently discarded. For a complete list of ARP Hardware Type values, see http://www.iana.org/assignments/arp-parameters.
    Table 3-1. ARP Hardware Type Values
    Hardware Type Value Data Link Layer Technology

    1 (0x00-01)

    Ethernet (10 Mbps)

    6 (0x00-06)

    IEEE 802 Networks (Token Ring)

    15 (0x00-0F)

    Frame relay

    16 (0x00-10)

    Asynchronous Transfer Mode (ATM)

  • Protocol Type A 2-byte field that indicates the protocol for which ARP is providing address resolution. This field uses the same values as the Ethernet II EtherType field. For IP address resolution, the Protocol Type field is set to the EtherType for IP, 0x0800. After receipt of an ARP frame, an IP node verifies that the ARP Protocol Type is set to 0x0800. If it is not set to 0x0800, the frame is silently discarded.
  • Hardware Address Length A 1-byte field that indicates the length in bytes of the hardware address in the Sender Hardware Address and Target Hardware Address fields. For Ethernet and Token Ring, the Hardware Address Length field is set to 6. For frame relay, the Hardware Address Length typically is set to 2 (for the commonly used 2-byte Frame Relay Address field).
  • Protocol Address Length A 1-byte field that indicates the length in bytes of the protocol address in the Sender Protocol Address and Target Protocol Address fields. For the IP protocol, the length of IP addresses is 4 bytes.
  • Operation (Opcode) A 2-byte field that indicates the type of ARP frame. Table 3-2 lists the commonly used ARP Operation values. For a complete list of ARP Operation values, see http://www.iana.org/assignments/arp-parameters .
    Table 3-2. ARP Operation Values
    Operation Value Type of ARP Frame

    1

    ARP Request

    2

    ARP Reply

    8

    Inverse ARP Request

    9

    Inverse ARP Reply

  • Sender Hardware Address (SHA) A field that is the length of the value of the Hardware Address Length field and contains the hardware or Data Link Layer address of the ARP frame's sender. For Ethernet and Token Ring, the SHA field contains the MAC address of the node sending the ARP frame.
  • Sender Protocol Address (SPA) A field that is the length of the value of the Protocol Address Length field and contains the protocol address of the ARP frame's sender. For IP, the SPA field contains the IP address of the node sending the ARP frame.
  • Target Hardware Address (THA) A field that is the length of the value of the Hardware Address Length field and contains the hardware or Data Link Layer address of the ARP frame's target (destination). For Ethernet and Token Ring, the THA field is set to 0x00-00-00-00-00-00 for ARP Request frames, and it is set to the MAC address of the ARP requester for ARP Reply frames.
  • Target Protocol Address (TPA) A field that is the length of the value of the Protocol Address Length field and contains the protocol address of the ARP frame's target (destination). For IP, the TPA field is set to the IP address being resolved in the ARP Request frame, and it is set to the IP address of the ARP requester in the ARP Reply frame.

ARP Request and ARP Reply Example

The ARP Request and ARP Reply exchange contains all the information for the ARP requester to determine the IP address and MAC address of the ARP responder, and for the ARP responder to determine the IP address and MAC address of the ARP requester. Figure 3-2 shows an ARP Request and ARP Reply exchange.

Figure 3-2. The resolution of Node 2's MAC address by Node 1, using an exchange of ARP Request and ARP Reply frames.

Node 1, with the IP address of 10.0.0.99 and the MAC address of 0x00-60-08-52-F9-D8, needs to forward an IP datagram to Node 2 at the IP address of 10.0.0.1. Based on information in Node 1's routing table, the next-hop IP address to reach Node 2 is 10.0.0.1, using the Ethernet interface. Node 1 constructs an ARP Request frame and sends it as a MAC-level broadcast using the Ethernet interface.

The following Network Monitor trace (Frame 1 of Capture 03-01 in the \Captures folder on the companion CD-ROM) is for the ARP Request frame sent by Node 1:

+	Frame: Base frame properties

    ETHERNET: ETYPE = 0x0806 : Protocol = ARP:  Address Resolution Protocol

        +	ETHERNET:	Destination address : FFFFFFFFFFFF

        +	ETHERNET:	Source address : 00600852F9D8

            ETHERNET:	Frame Length : 42 (0x002A)

            ETHERNET:	Ethernet Type : 0x0806 (ARP:  Address Resolution Protocol)

            ETHERNET:	Ethernet Data: Number of data bytes remaining = 28 (0x001C)

    ARP_RARP: ARP: Request, Target IP: 10.0.0.1

            ARP_RARP:	Hardware Type = Ethernet (10Mb)

            ARP_RARP:	Protocol Type = 2048 (0x800)

             ARP_RARP:	Hardware Address Length = 6 (0x6)

            ARP_RARP:	Protocol Address Length = 4 (0x4)

            ARP_RARP:	Opcode = Request

            ARP_RARP:	Sender's Hardware Address = 00600852F9D8

            ARP_RARP:	Sender's Protocol Address = 10.0.0.99

            ARP_RARP:	Target's Hardware Address = 000000000000

            ARP_RARP:	Target's Protocol Address = 10.0.0.1

The known quantity—the IP address of 10.0.0.1—is set to the Target Protocol Address field. The unknown quantity—the hardware address of 10.0.0.1—is the Target Hardware Address field in the ARP Request frame, which is set to 000000000000. Included in the ARP Request are the IP and MAC addresses of Node 1 so that Node 2 can add an entry for Node 1 to its own ARP cache.

After receipt of the ARP Request frame at Node 2, the node checks the values of the ARP Hardware Type and Protocol Type fields. Node 2 then examines its own ARP cache for an entry matching the SPA. If an entry exists, Node 2 updates the MAC address of the ARP cache entry with the value stored in the SHA. For our example purposes, no entry for 10.0.0.99 exists.

Node 2 then examines the value of the TPA. Because the TPA is the same as Node 2's IP address, Node 2 adds an ARP cache entry consisting of [SPA, SHA] to its ARP cache. It then checks the ARP Operation field. Because the received ARP frame is an ARP Request, Node 2 constructs an ARP Reply to send back to Node 1.

The following Network Monitor trace (Frame 2 of Capture 03-01 in the \Captures folder on the companion CD-ROM) is for the ARP Reply frame sent by Node 2:

+	Frame: Base frame properties

    ETHERNET: ETYPE = 0x0806 : Protocol = ARP:  Address Resolution Protocol

        +	ETHERNET:	Destination address : 00600852F9D8

        +	ETHERNET:	Source address : 001054CAE140

            ETHERNET:	Frame Length : 60 (0x003C)

            ETHERNET:	Ethernet Type : 0x0806 (ARP:  Address Resolution Protocol)

            ETHERNET:	Ethernet Data: Number of data bytes remaining = 46 (0x002E)

    ARP_RARP: ARP: Reply, Target IP: 10.0.0.99 Target Hdwr Addr: 00600852F9D8

            ARP_RARP:	Hardware Type = Ethernet (10Mb)

            ARP_RARP:	Protocol Type = 2048 (0x800)

            ARP_RARP:	Hardware Address Length = 6 (0x6)

            ARP_RARP:	Protocol Address Length = 4 (0x4)

            ARP_RARP:	Opcode = Reply

            ARP_RARP:	Sender's Hardware Address = 001054CAE140

            ARP_RARP:	Sender's Protocol Address = 10.0.0.1

            ARP_RARP:	Target's Hardware Address = 00600852F9D8

            ARP_RARP:	Target's Protocol Address = 10.0.0.99

            ARP_RARP:	Frame Padding

In the ARP Reply, all quantities are known and the frame is addressed at the MAC level using Node 1's unicast MAC address. The quantity that Node 1 needs—Node 2's MAC address—is the SHA field's value.

After receipt of the ARP Reply frame, Node 1 checks the values of the ARP Hardware Type and Protocol Type fields. Node 1 then examines its own ARP cache for an entry matching the SPA. No entry exists; otherwise, an ARP Request would not have been sent. Node 1 then examines the TPA's value. Because the TPA is the same as Node 1's IP address, Node 1 adds an ARP cache entry consisting of [SPA, SHA] to its ARP cache. Node 1 then checks the ARP Operation field. Because the received ARP frame is an ARP Reply, the ARP frame is discarded.

Frame Padding and Ethernet

Notice that the ARP frames of the Network Monitor trace contain a Frame Padding field. This is not an ARP field, but the consequence of sending an ARP frame on an Ethernet network. As discussed in Chapter 1, Ethernet payloads using the Ethernet II encapsulation must be a minimum length of 46 bytes to adhere to the minimum Ethernet frame size. The ARP frame is only 28 bytes long. Therefore, to send the ARP frame on an Ethernet network, it must be padded with 18 padding bytes.

When using Network Monitor, you might notice that sometimes the Frame Padding field does not appear on either the ARP Request or the ARP Reply frames. Does this mean that the ARP frame was sent as a runt—an Ethernet frame with a length below the minimum frame size? No. The answer to the mystery lies in the implementation of Network Monitor within the Windows Server 2003 family. Network Monitor receives frames by acting as a Network Driver Interface Specification (NDIS) protocol. When any frame is sent or received, Network Monitor receives a copy. However, when frames are sent, Network Monitor receives a copy of the frame before the frame padding is added. When the frame is received, Network Monitor receives a full copy of the frame. Therefore, you do not see a Frame Padding field on an ARP frame if it was captured on the node sending the ARP frame. The example Network Monitor trace displayed in this chapter was taken on Node 1. Therefore, the frame padding is only seen on the ARP Reply frame.


Gratuitous ARP and Duplicate IP Address Detection

ARP also is used to provide duplicate IP address detection through the transmission of ARP Requests known as gratuitous ARPs. A gratuitous ARP is an ARP Request for a node's own IP address. In the gratuitous ARP, the SPA and the TPA are set to the same IP address.

If a node sends an ARP Request for its own IP address and no ARP Reply frames are received, the node determines that other nodes are not using its assigned IP address. If a node sends an ARP Request for its own IP address and an ARP Reply frame is received, the node determines that another node is using its assigned IP address.

The ArpRetryCount registry setting controls the number of gratuitous ARPs that are sent.

ArpRetryCount

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-3

Default value: 3

Present by default: No

ArpRetryCount sets the number of times that a gratuitous ARP is sent when initializing IP for a specific IP address. If no ARP Reply is received after sending ArpRetryCount gratuitous ARPs, IP assumes the IP address is unique on the network segment.

The gratuitous ARP attempts to detect the use of a duplicate IP address by a node on the same network segment. Because routers do not propagate ARP frames, a gratuitous ARP does not detect an IP address conflict between two nodes that are located on different network segments.

IP Address Conflict Detection

In an IP address conflict, the node that is already successfully configured with the IP address is known as the defending node. The node that is sending the gratuitous ARP is known as the offending node. Based on the ARP Reply, the offending node can determine the defending node's MAC address.

On the Offending Node

If the offending node is a computer running a member of the Windows Server 2003 family or Windows XP that is manually configured with a conflicting IP address, the receipt of the ARP Reply to the gratuitous ARP prevents TCP/IP from initializing using the conflicting address. An error message is displayed and an event is logged in the system event log.

If the offending node is a computer running a member of the Windows Server 2003 family or Windows XP using DHCP, gratuitous ARPs are sent for the IP address received in the DHCPOFFER message. If an ARP Reply is received in response to the gratuitous ARPs, the DHCP client sends a DHCPDECLINE message to the DHCP server. If the DHCP server is running a member of the Windows Server 2003 family, the IP address sent in the DHCPOFFER is flagged as a bad IP address and is not allocated to any other DHCP clients. The DHCP client starts the DHCP lease allocation process by sending a new DHCPDISCOVER message. For more information on DHCP, see Chapter 16, "Dynamic Host Configuration Protocol (DHCP) Server Service."

On the Defending Node

The defending node detects an address conflict whenever the SPA of the incoming ARP Request is the same as an IP address configured on the defending node. For gratuitous ARPs from an offending node, both the SPA and TPA are set to the conflicting address. However, gratuitous ARPs are not the only ARP Requests that can have the SPA set to a conflicting address.

For example, if a node using a conflicting address is started without being connected to its network segment, no replies to the gratuitous ARPs are received and the node initializes TCP/IP using the conflicting address. If the node is then placed on the same network segment as the defending node, no additional gratuitous ARPs are sent. However, each time either node using the conflicting address sends an ARP Request, the SPA is set to the conflicting address. In this case, an error message is displayed and an event is logged in the system event log. Both nodes continue to use the conflicting IP address, but each displays an error message and logs an event every time the other node sends an ARP Request.

The Gratuitous ARP and Address Conflict Exchange

The gratuitous ARP and address conflict detection for the Windows Server 2003 family is an exchange of three frames. The first two frames are the ARP Request-ARP Reply exchange for the conflicting address:

  1. The offending node attempting to detect another node on the same network segment using the same IP address sends the gratuitous ARP Request.
  2. The defending node sends the ARP Reply to the offending node.

When the gratuitous ARP is sent, the SPA is set to a conflicting IP address and the SHA is set to the offending node's MAC address. Nodes on the network segment that have an ARP cache entry for [conflicting IP address, defending node's MAC address] have their ARP cache entries updated to [conflicting IP address, offending node's MAC address]. The gratuitous ARP sent by the offending node updates all the ARP cache entries for the nodes communicating with the defending node; this causes future IP datagrams to be sent to the offending node's MAC address. A worst-case scenario is when the defending node is the default gateway for the network segment. Sending the gratuitous ARP Request causes all nodes on that network segment with an entry in their ARP cache for the default gateway IP address to forward all traffic off the subnet to the offending node's MAC address.

When the ARP Reply is sent, it is sent to the defending node's MAC address. The unicast ARP Reply does not correct the improper ARP cache entries. Therefore, to reset the ARP cache entries that were improperly updated by the offending node's sending of the gratuitous ARP Request, the defending node sends another broadcast ARP Request. The defending node's ARP Request is a gratuitous ARP, as if the defending node were doing its own conflict detection. The defending node's ARP Request contains the SHA set to the defending node's MAC address. Network segment nodes that have had their ARP cache entries improperly set to [conflicting IP address, offending node's MAC address] are reset to the proper mapping of [conflicting IP address, defending node's MAC address].

The Network Monitor trace in Capture 03-02 (in the \Captures folder on the companion CD-ROM) shows the gratuitous ARP and address conflict exchange. Frame 1 is the offending node's gratuitous ARP. Frame 2 is the defending node's ARP Reply. Frame 3 is the defending node's gratuitous ARP. At the end of Frame 3, all network segment nodes that have the IP address 169.254.0.1 in their ARP caches have been reset to the proper MAC address of 0x00-60-97-02-6D-3D.


Inverse ARP (InARP)

For non-broadcast multiple access (NBMA)-based WAN technologies such as X.25, frame relay, and ATM, the Network Interface Layer address is not a MAC address but a virtual circuit identifier. For example, for frame relay, the virtual circuit identifier is the Frame Relay Data Link Connection Identifier (DLCI). To address frames for a given destination, the Frame Relay header's DLCI is set to the value that corresponds to the virtual circuit over which the frame is traveling. With NMBA technologies, the virtual circuit identifier is known but the IP address of the interface on the other end of the virtual circuit is not.

InARP is used to resolve the IP address on the other end of a virtual circuit based on a known Frame Relay DLCI. As RFC 2390 describes, InARP was designed specifically for frame relay virtual circuits. Frame relay link management protocols such as Local Management Interface (LMI) determine which virtual circuits are in use over the physical connection to the frame relay service provider. Once the DLCIs are determined, InARP is used to query each virtual circuit to determine the IP address of the interface on the other end. The response to the InARP is used to build a table of entries consisting of [DLCI, next-hop IP address].

InARP is described in RFC 2390, which can be found in the \Rfc folder on the companion CD-ROM.

Because the DLCI values are only locally significant, the SHA and THA are irrelevant. In both the InARP Request and InARP Reply, the SHA field is typically set to 0 and the TPA field is set to the local DLCI value. The relevant information is the value of the SPA field in the InARP Request and the InARP Reply. The InARP responder uses the InARP Request's SPA to add an entry to its table consisting of [local DLCI, SPA of InARP Request]. The InARP requester uses the InARP Reply's SPA to add an entry to its table consisting of [local DLCI, SPA of InARP Reply].

The InARP Request and Reply have the same structure as the ARP Request and Reply, except 2-byte hardware addresses are used. The ARP Operation field is set to 0x0008 for an InARP Request and 0x0009 for an InARP Reply.


Proxy ARP

Proxy ARP is the answering of ARP Requests on behalf of another node. As RFC 925 describes, Proxy ARP is used in situations in which a subnet is divided without the use of a router. A proxy ARP device is placed between nodes on the same subnet. The proxy ARP device is aware of which nodes are available on which segment. The proxy ARP device also answers ARP Requests and facilitates the forwarding of unicast IP packets for communication between nodes on separate segments. The existence of the proxy ARP device is transparent to the nodes on the subnet. A proxy ARP device is often physically a router device; however, it is not acting as an IP router, forwarding IP datagrams between two IP subnets. Figure 3-3 shows an example of a proxy ARP configuration.

Use of proxy ARP in divided subnet situations is described in RFC 925, which can be found in the \Rfc folder on the companion CD-ROM.
Figure 3-3. A single subnet configuration, using a proxy ARP device.

When Node 1 wants to send an IP datagram to Node 2 on the other side of the proxy ARP device, because Node 1 and Node 2 are on the same logical IP subnet, Node 1 sends an ARP Request with Node 2's IP address as the TPA. The proxy ARP device receives the ARP Request and, even though the TPA is not its own address, the proxy ARP device sends an ARP Reply to Node 1 with the proxy ARP device's MAC address as the SHA. Node 1 then sends the IP datagram to the proxy ARP device's MAC address. As far as Node 1 is concerned, it has resolved Node 2's MAC address and delivered the IP datagram to Node 2. The proxy ARP device next delivers the IP datagram to Node 2, using ARP if necessary to resolve Node 2's MAC address.

For the Windows Server 2003 family and Windows XP, the Network Bridge feature of the Network Connections folder acts as a proxy ARP device when performing Layer 3 bridging between segments for which the Network Bridge cannot perform Layer 2 transparent bridging.

For the Windows Server 2003 family, the Routing and Remote Access service also uses proxy ARP to facilitate communications between remote access clients and nodes on the network segment to which the remote access server is attached. When IP-based remote access clients connect, the remote access server assigns them an IP address. The IP address assigned can either be from the address range of a subnet to which the remote access server is attached, an on-subnet address, or from the address range of a separate subnet, an off-subnet address. Proxy ARP is used when the remote access server assigns an on-subnet address. An on-subnet address range is used when either the Routing and Remote Access service is configured to use DHCP to obtain addresses, or a range of addresses from a directly attached subnet is manually configured. Figure 3-4 shows an example of a remote access server manually configured with an on-subnet address range.

Figure 3-4. A remote access server running a member of the Windows Server 2003 family and configured with an on-subnet address range using Proxy ARP.

The subnet to which the remote access server is attached is 10.1.1.0/24, implying a range of usable addresses from 10.1.1.1 through 10.1.1.254. In this case, the network administrator is using the high end of the range (10.1.1.200 through 10.1.1.254) for assignment to remote access clients.

When an IP-based remote access client successfully connects and is assigned an IP address, the Routing and Remote Access service tracks the assigned address in a connection table. When a host on the network to which the remote access server is attached sends an ARP Request for the remote access client's assigned on-subnet IP address, the remote access server answers with an ARP Reply and receives the IP datagram. The Routing and Remote Access service then forwards the IP datagram addressed to the remote access client over the appropriate remote access connection.

If the remote access server is manually configured with a range of addresses that represents a different subnet (an off-subnet address range), the remote access server acts as an IP router forwarding IP datagrams between separate subnets and proxy ARP is not used.


Summary

ARP is used as a translation layer between Internet Layer addresses and Network Interface Layer addresses. ARP on LAN links is used to resolve the next-hop IP address of a node to its corresponding MAC address and to detect IP address conflicts. InARP on NBMA links is used to map a DLCI value to the IP address of the node on the other end of the virtual circuit. Proxy ARP is used to subdivide an IP subnet and provide transparent communication without using an IP router.


Point-to-Point Protocol (PPP)

Chapter 4
Point-to-Point Protocol (PPP)

As first introduced in Chapter 2, "Wide Area Network (WAN) Technologies," PPP is a standard for using point-to-point network links that provides the following:

  • A Data Link Layer encapsulation method that supports multiple protocols simultaneously on the same link.
  • A protocol for negotiating the Data Link Layer characteristics of the point- to-point connection named the Link Control Protocol (LCP).
  • A series of protocols for negotiating the Network Layer properties of Network Layer protocols over the point-to-point connection named Network Control Protocols (NCPs). For example, RFCs 1332 and 1877 describe the Internet Protocol Control Protocol (IPCP), the NCP for IP. IPCP is used to negotiate an IP address, the addresses of name servers, and the use of the Van Jacobsen TCP compression protocol.

Chapter 2 discusses only the Data Link Layer encapsulation. This chapter describes LCP and the set of NCPs needed for PPP and IP connectivity.

PPP is described in RFC 1661, which can be found in the \Rfc folder on the companion CD-ROM.

PPP Connection Process

There are four phases to a PPP connection, all of which must be completed before data can be sent on the connection. The four phases are the following:

  1. PPP configuration using LCP
  2. Authentication using a PPP authentication protocol (optional)
  3. Callback
  4. Protocol configuration using NCPs

Phase 1: PPP Configuration Using LCP

In the first phase of the PPP connection process, PPP connection parameters are configured using LCP. With LCP, the PPP peers negotiate a common set of parameters that are used for all subsequent phases of the PPP connection and for sending data. Some of the communication parameters that are negotiated are the following:

  • The maximum receive unit (MRU), the largest PPP frame that can be sent on the connection
  • Whether the Address and Control fields in the PPP header are used (for links that use the High-Level Data Link Control [HDLC] encapsulation that is described in RFC 1662)
  • Whether the Protocol field in the PPP header can be compressed from 2 bytes to 1 byte
  • The PPP authentication protocol to be used during the authentication phase
  • Whether Multilink PPP (MP) is used

For more information, see the section entitled "Link Control Protocol," later in this chapter.

Phase 2: Authentication

After LCP negotiation, the authentication process using the PPP authentication protocol negotiated during phase 1 is performed. This process is specific to the PPP authentication protocol used. For more information, see the section entitled "PPP Authentication Protocols," later in this chapter.

Phase 3: Callback

If the authentication process succeeds and callback behavior is configured, the answering PPP peer terminates the connection and initiates a connection to the original calling PPP peer, a feature of PPP implementations known as callback. The PPP implementation in the Microsoft Windows Server 2003 family and Windows XP uses the Callback Control Protocol (CBCP) to complete the callback phase. For more information, see the section entitled "Callback and the Callback Control Protocol," later in this chapter.

Phase 4: Protocol Configuration Using NCPs

After PPP is configured, the original initiating PPP peer is authenticated, and callback is done (optional and only if configured), individual data protocols and ancillary PPP services such as encryption and compression are configured using NCPs. For more information, see the section entitled "Network Control Protocols," later in this chapter.

PPP Connection Termination

After a PPP connection is established, it can be terminated at any time by either the connection-initiating or connection-receiving PPP peer. PPP connections can be terminated by user action, connection policy action (such as terminating the connection after a specific amount of idle time), or link failure. When the PPP connection terminates, PPP informs the data protocols that were operating over it that the point-to-point interface is no longer available.


Link Control Protocol

LCP, described in RFC 1661, is a simple protocol to configure a common set of PPP connection parameters (for phase 1 of the PPP connection). It is also used by NCPs to configure specific data protocol configuration parameters (for phase 2 of the PPP connection). LCP uses the PPP Protocol ID 0xC0-21. Figure 4-1 shows an LCP frame.

Figure 4-1. The structure of an LCP frame.

The fields in the LCP frame are defined as follows:

  • Code A 1-byte field that identifies the type of LCP message
  • Identifier A 1-byte field that identifies a specific pair of LCP messages: the request and the response
  • Length A 2-byte length field that indicates the size of the LCP message in bytes
  • Data A variable-sized field that contains the LCP frame type-specific data

Table 4-1 lists the LCP frame types described in RFC 1661.

Table 4-1. LCP Frame Types
Code | Frame Type | Description
1 | Configure-Request | Sent to open or reset a PPP connection.
2 | Configure-Ack | Sent to indicate when the last Configure-Request frame contains options with acceptable values. The LCP negotiation is complete when each PPP peer both sends and receives Configure-Ack frames.
3 | Configure-Nak | Sent to indicate that the LCP options in the Configure-Request are recognized, but some option values are not acceptable.
4 | Configure-Reject | Sent to indicate that the LCP options in the Configure-Request frame are either not recognized or not acceptable.
5 | Terminate-Request | Sent to close the PPP connection.
6 | Terminate-Ack | Sent to respond to the Terminate-Request message.
7 | Code-Reject | Sent when the LCP Code field of a received LCP frame is unknown.
8 | Protocol-Reject | Sent when the PPP Protocol field of a received PPP frame is unknown.
9 | Echo-Request | Sent to test the PPP connection.
10 | Echo-Reply | Sent in response to an Echo-Request frame.
11 | Discard-Request | Sent to test outbound data on the link.
The LCP Echo-Request and Echo-Reply messages are not related to the Internet Control Message Protocol (ICMP) Echo and Echo Reply messages.

LCP Options

The data portion of an LCP message consists of one or more LCP options for the Configure-Request, Configure-Ack, Configure-Nak, and Configure-Reject LCP frames. An LCP option is formatted in type-length-value (TLV) format. A 1-byte Type field indicates the option type, a 1-byte Length field indicates the length in bytes of the entire option, and the Option Data field contains the data of the option. Figure 4-2 shows an LCP message that contains LCP options.

Figure 4-2. The structure of an LCP frame containing LCP options.

Table 4-2 lists common LCP options used by PPP peers that run Microsoft operating systems.

Table 4-2. LCP Options
Option Name | Type | Length | Description
Maximum Receive Unit (MRU) | 1 | 4 | Used to indicate the maximum size of the PPP frame that can be supported on the connection. The maximum size is 65,535. The default MRU is 1500.
Asynchronous Control Character Map (ACCM) | 2 | 6 | Contains a 4-byte bit map indicating which ASCII control characters from 0x0 to 0x20 use character escapes for asynchronous links. Character escapes are used to distinguish data from control characters sent on the connection. By default, character escapes are used for all 32 control characters.
Authentication Protocol | 3 | 5 or 6 | Used to indicate the PPP authentication protocol for the authentication phase to verify the identity. For Microsoft PPP peers, the values are 0xC2-27 for Extensible Authentication Protocol (EAP), 0xC2-23-80 for Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), 0xC2-23-81 for MS-CHAP version 2, 0xC2-23-05 for Message Digest version 5 Challenge Handshake Authentication Protocol (MD5-CHAP), 0xC0-27 for Shiva Password Authentication Protocol (SPAP), and 0xC0-23 for Password Authentication Protocol (PAP).
Magic Number | 5 | 6 | Contains a random number to distinguish a PPP peer and detect looped back lines.
Protocol Compression | 7 | 2 | A flag option that indicates that the sender wants to use a 1-byte Protocol field for PPP data frames. PPP control frames using LCP or NCPs still use a 2-byte Protocol field.
Address and Control Field Compression | 8 | 2 | A flag option that indicates that the sender wants to remove the Address and Control fields from the HDLC-based PPP header.
Callback | 13 | 3 | Used to determine the callback behavior for the connection. For PPP clients and servers running a modern 32-bit or 64-bit Windows operating system, CBCP is used to determine callback behavior.

Additional LCP options are defined in RFC 1661.

LCP Negotiation Process

LCP is used to negotiate the parameters of PPP when sending data in a single direction on the PPP connection. Different PPP parameters could be negotiated in the two different directions of data travel on a PPP connection. Therefore, each PPP peer must perform a separate LCP negotiation. An LCP negotiation is used by a PPP peer to establish how the other PPP peer should send data to it. Each LCP negotiation is a series of LCP frames to negotiate the use of a common set of parameters for data sent by the PPP peer on the other side of the PPP connection from the LCP negotiation initiator. For two PPP peers, Peer A and Peer B, Peer A initiates an LCP negotiation for the data to be sent by Peer B and Peer B initiates a separate LCP negotiation for the data to be sent by Peer A.

An individual LCP negotiation consists of an initial set of LCP options using the LCP Configure-Request message. The specific set of LCP options is negotiated using Configure-Nak and Configure-Reject messages and finally confirmed with a Configure-Ack message. Both negotiations occur simultaneously, making it more difficult to read the captures of PPP connection establishments.

When a PPP peer sends a Configure-Request message, the response is one of the following:

  • Configure-Nak message Sent because one or more options in the Configure-Request message have unacceptable values
  • Configure-Reject message Sent because one or more of the options are either unknown or non-negotiable
  • Configure-Ack message Sent because all of the options have acceptable values

When the Configure-Reject message is received, the unknown or non-negotiable options are removed from the list of LCP options being configured by the initiating PPP peer and a new Configure-Request message is sent. When the Configure-Nak message is received, the included options are set to their indicated values and a new Configure-Request message is sent. When the Configure-Ack message is received, the LCP negotiation is complete. For each new Configure-Request message, the Identifier field in the LCP header is changed to a new value to match a sent Configure-Request message with its response.

For example, the following is a sample LCP negotiation using fictional options:

  1. Peer 1 sends a Configure-Request message requesting that options A and B (both flag options) be used, that option C be set to 5000, and that option D be set to 1.
  2. Because Peer 2 does not understand option B, it sends a Configure-Reject message containing option B.
  3. Peer 1 sends a new Configure-Request message requesting that option A be used, that option C be set to 5000, and that option D be set to 1.
  4. Because Peer 2 prefers that option C be set to 1500 and option D be set to 3, it sends a Configure-Nak message containing option C set to 1500 and option D set to 3.
  5. Peer 1 sends a new Configure-Request message requesting that option A be used, that option C be set to 1500, and that option D be set to 3.
  6. Because all the options in the Configure-Request message contain known options with preferred values, Peer 2 sends a Configure-Ack message.

The following frames (Frame 1 through Frame 8) from the Network Monitor trace in Capture 04-01 (in the \Captures folder on the companion CD-ROM) summarize an LCP negotiation between a remote access client computer running Microsoft Windows XP and a remote access server computer running a member of the Windows Server 2003 family. The summary frames have been indented for readability.

Frame	Time		Src MAC Addr	Dst MAC Addr	Protocol 	Description

1	7.060152		RECV		RECV		LCP	Config Req Packet,
                            Ident = 0x00, Length = 50

2	7.060152		SEND		SEND		LCP	Config Req Packet,
                            Ident = 0x00, Length = 58

3	7.060152		SEND		SEND		LCP	Config Ack Packet,
                            Ident = 0x00, Length = 50

4	7.130253		RECV		RECV		LCP	Config Reject Packet,
                            Ident = 0x00, Length = 8

5	7.130253		SEND		SEND		LCP	Config Req Packet,
                            Ident = 0x01, Length = 54

6	7.220383		RECV		RECV		LCP	Config No Ack Packet,
                            Ident = 0x01, Length = 9

7	7.220383		SEND		SEND		LCP	Config Req Packet,
                            Ident = 0x02, Length = 55

8	7.320527		RECV		RECV		LCP	Config Ack Packet,
                            Ident = 0x02, Length = 55

Due to the architecture of PPP in Windows XP and the Windows Server 2003 family, PPP frames captured by Network Monitor are displayed as an Ethernet frame with the PPP Protocol ID field taking the place of the EtherType field. The source and destination media access control (MAC) addresses are set to either SEND or RECV, depending whether the frame was sent to (set to SEND) or received from (set to RECV) the computer on which the Network Monitor capture was taken. In this instance, the Network Monitor capture was taken on the remote access server. Therefore, the RECV frames were sent by the remote access client and the SEND frames were sent by the remote access server.

For this trace, Frames 1 and 3 correspond to the LCP negotiation initiated by the remote access client for the frames sent by the remote access server. Frame 2 and frames 4 through 8 correspond to the LCP negotiation initiated by the remote access server for the frames sent by the remote access client.


PPP Authentication Protocols

After LCP negotiation is complete, the authentication protocol agreed on during LCP negotiation using LCP option 3 is used to establish the identity and credentials of the PPP peer that is requesting the PPP connection, typically a remote access client (for remote access dial-up or virtual private network [VPN] connections) or a calling router (for router-to-router dial-up or VPN connections). The authentication process is phase 2 of the PPP connection establishment.

The Windows Server 2003 family and Windows XP support the following PPP authentication protocols:

  • Password Authentication Protocol (PAP)
  • Shiva Password Authentication Protocol (SPAP)
  • Challenge Handshake Authentication Protocol (CHAP)
  • Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
  • MS-CHAP version 2 (MS-CHAP v2)
  • Extensible Authentication Protocol (EAP)
SPAP is a proprietary authentication protocol and is not described in this chapter.

PAP

PAP is a very simple, plaintext authentication protocol described in RFC 1334. The entire PAP negotiation consists of the following messages:

  1. The connection-initiating PPP peer (the calling peer) sends a PAP Authenticate-Request message to the authenticating PPP peer (the answering peer), which contains the calling peer's user name and password in plaintext.
  2. The answering peer validates the user name and password. If the user name and password are correct, the answering peer sends a PAP Authenticate-Ack message. If not, the answering peer sends a PAP Authenticate-Nak message.

Obviously, PAP is not a secure authentication protocol. A malicious user that can capture the PAP frames sent between the calling peer and answering peer can view the contents of the PAP Authenticate-Request message to determine the user name and password of a valid user account. The use of PAP is highly discouraged and is only included in Windows XP and the Windows Server 2003 family for troubleshooting and compatibility with PPP peers that do not support more secure authentication protocols.

PPP peers negotiate the use of PAP during phase 1 by specifying LCP option 3 (authentication protocol) and the authentication protocol 0xC0-23. After phase 1 negotiation is complete, PAP messages use the PPP protocol ID 0xC0-23.

Figure 4-3 shows the PAP Authenticate-Request message.

Figure 4-3. The structure of the PAP Authenticate-Request message.

The following are the fields in the PAP Authenticate-Request message:

  • Code A 1-byte field that identifies the type of PAP message. For Authenticate-Request messages, the value of the Code field is set to 1.
  • Identifier A 1-byte field that is used to identify a pair of PAP messages: the request and the response. The calling peer sets the value of the Identifier field.
  • Length A 2-byte field that indicates the size of the PAP message in bytes.
  • Peer ID Length A 1-byte field that indicates the size of the Peer ID field in bytes.
  • Peer ID A variable-sized field that contains the user name of the calling peer.
  • Password Length A 1-byte field that indicates the size of the Password field in bytes.
  • Password A variable-sized field that contains the password of the calling peer.

Figure 4-4 shows the PAP Authenticate-Ack and Authenticate-Nak messages.

Figure 4-4. The structure of the PAP Authenticate-Ack and Authenticate-Nak messages.

The following are the fields in the Authenticate-Ack and Authenticate-Nak messages:

  • Code For an Authenticate-Ack message, the value of the Code field is set to 2. For an Authenticate-Nak message, the value of the Code field is set to 3.
  • Identifier A 1-byte field that is set to the value of the Identifier field in the corresponding Authenticate-Request message.
  • Length A 2-byte field that indicates the size of the PAP message in bytes.
  • Message Length A 1-byte field that indicates the size of the Message field in bytes.
  • Message A variable-sized field that contains a message for the calling peer. The Message field is not used by Microsoft operating systems. Some PPP implementations display the message text to the user who is connecting.

Capture 04-02 in the \Captures folder on the companion CD-ROM contains an example of a PAP authentication.

CHAP

CHAP is a more secure authentication protocol, described in RFC 1994, that uses a challenge-response exchange of messages to validate that the calling peer has knowledge of the user's password. The password itself is never sent. Although more secure than PAP, CHAP does not provide mutual authentication. The calling peer authenticates to the answering peer but the answering peer does not authenticate to the calling peer. Without mutual authentication, a calling peer is unable to determine whether it is calling a valid answering peer.

When the use of CHAP is negotiated during phase 1, an algorithm that is used to provide proof of knowledge of the user password is also specified. For the Message Digest-5 (MD5) algorithm, the LCP option data for the authentication protocol contains the CHAP authentication protocol (0xC2-23) and the MD-5 algorithm (0x05). CHAP messages use the PPP Protocol ID 0xC2-23.

CHAP authentication using MD5 consists of the following three messages:

  1. The answering peer sends a CHAP Challenge message that contains a CHAP session ID (the value of the Identifier field), a challenge string, and the name of the answering peer.
  2. The calling peer sends a CHAP Response message that contains the user name of the calling peer and an MD5 hash of the CHAP session ID, the challenge string, and the user's password.
  3. The answering peer calculates its own MD5 hash of the CHAP session ID, the challenge string, and user password and compares the result with the MD5 hash in the CHAP Response message. If the two hashes are identical, the answering peer sends a CHAP Success message. If not, the answering peer sends a CHAP Failure message and the connection is terminated.

Figure 4-5 shows the CHAP Challenge and CHAP Response messages.

Figure 4-5. The structure of the CHAP Challenge and CHAP Response messages.

The following are the fields in the CHAP Challenge and CHAP Response messages:

  • Code A 1-byte field that identifies the type of CHAP message. For a CHAP Challenge message, the value of the Code field is set to 1. For a CHAP Response message, the value of the Code field is set to 2.
  • Identifier A 1-byte field that is used to identify a pair or sequence of CHAP messages (the CHAP session ID). The calling peer sets the value of the Identifier field.
  • Length A 2-byte field that indicates the size of the CHAP message in bytes.
  • Value Size A 1-byte field that indicates the size of the Value field.
  • Value A variable-sized field that contains either the challenge string for the CHAP Challenge message or the MD5 hash for the CHAP Response message.
  • Name A variable-sized field that contains the name of either the answering peer for the CHAP Challenge message or the calling peer for the CHAP Response message.

Figure 4-6 shows the structure of the CHAP Success and CHAP Failure messages.

Figure 4-6. The CHAP Success and CHAP Failure message structure.

The following are the fields in the CHAP Success and CHAP Failure messages:

  • Code For a CHAP Success message, the value of the Code field is set to 3. For a CHAP Failure message, the value of the Code field is set to 4.
  • Identifier A 1-byte field that is used to indicate the CHAP session ID.
  • Length A 2-byte field that indicates the size of the CHAP message in bytes.
  • Message A variable-sized field that contains a message for the calling peer. The Message field is optional and is not used by Microsoft operating systems.

Capture 04-03 in the \Captures folder on the companion CD-ROM contains an example of an MD5-CHAP authentication.

MS-CHAP

To calculate the MD5 hash for CHAP, the user's password must be available in plaintext form. By default, Microsoft operating systems do not store a plaintext version of user passwords. Instead, they store a Message Digest-4 (MD4) hash of the password. MS-CHAP is a CHAP-based authentication protocol, described in RFC 2433, that is designed to work with the MD4 hash of account passwords to validate calling peer credentials. Like MD5-CHAP, MS-CHAP does not require the passwords to be sent and does not provide mutual authentication.

When MS-CHAP is negotiated during phase 1, the LCP option data for the authentication protocol contains the CHAP authentication protocol (0xC2-23) and the MS-CHAP algorithm (0x80). MS-CHAP messages use the PPP Protocol ID 0xC2-23.

MS-CHAP authentication consists of the following three messages:

  1. The answering peer sends a CHAP Challenge message that contains a challenge string and the name of the answering peer.
  2. The calling peer sends an MS-CHAP Response message that contains the user name of the calling peer and an encrypted response based on the challenge string and the MD4 hash of the user's password.
  3. The answering peer calculates its own encrypted result based on the challenge string and the MD4 hash of the user's password and compares it to the version in the MS-CHAP Response message. If the two results are identical, the answering peer sends a CHAP Success message. If not, the answering peer sends a CHAP Failure message.

Figure 4-7 shows the MS-CHAP Response message.

Figure 4-7. The structure of the MS-CHAP Response message.

The following are the fields in the MS-CHAP Response message:

  • Code For an MS-CHAP Response message, the value of the Code field is set to 2.
  • Identifier A 1-byte field that is set to the value of the Identifier field in the original CHAP Request message.
  • Length A 2-byte field that indicates the size of the MS-CHAP Response message in bytes.
  • Value Size A 1-byte field that indicates the size of the CHAP Value field. For the MS-CHAP Response message, the CHAP Value field consists of the LAN Manager Response, the Windows NT Response, and the Flags fields and is a fixed size of 49 bytes.
  • LAN Manager Response A 24-byte field that contains the LAN Manager-encoded response. The use of this field is deprecated and should be set to 0.
  • Windows NT Response A 24-byte field that contains the Windows NT-encoded response.
  • Flags A 1-byte field that indicates, when set to 1, that the Windows NT Response field has a value and should be preferred over the value in the LAN Manager Response field. Because the use of the LAN Manager Response field is deprecated, this field is always set to 1.
  • Name A variable-sized field that contains the name of the calling peer.

Capture 04-04 in the \Captures folder on the companion CD-ROM contains an example of an MS-CHAP authentication.

MS-CHAP also allows the answering peer to indicate specific error conditions in the Message field of the CHAP Failure message. One of the errors is ERROR_PASSWD_EXPIRED. When the calling peer receives this error indication, it can submit an MS-CHAP Change Password message to submit a new password for the account corresponding to the account of the user name. There are two versions of the Change Password message: Version 1 is used by older Microsoft operating systems and its use is deprecated due to its weak security. Version 2 is used by newer Microsoft operating systems, such as Windows XP and the Windows Server 2003 family. For more information about these messages, see RFC 2433.

MS-CHAP v2

MS-CHAP v2 is a CHAP-based authentication protocol described in RFC 2759 that, unlike both CHAP and MS-CHAP, provides mutual authentication. With MS-CHAP v2, the answering peer receives confirmation that the calling peer has knowledge of the user account's password and the calling peer receives confirmation that the answering peer has knowledge of the user account's password. To provide for this mutual authentication, both peers issue a challenge and must receive a valid response or the connection is terminated.

When MS-CHAP v2 is negotiated during phase 1, the LCP option data for the authentication protocol contains the CHAP authentication protocol (0xC2-23) and the MS-CHAP v2 algorithm (0x81). MS-CHAP v2 messages use the PPP Protocol ID 0xC2-23.

MS-CHAP v2 authentication consists of the following four steps:

  1. The answering peer sends a CHAP Challenge message that contains a challenge string and the name of the answering peer.
  2. The calling peer sends an MS-CHAP v2 Response message that contains the user name of the calling peer, a challenge string for the answering peer, and an encrypted response based on the answering peer's challenge string and the MD4 hash of the user's password.
  3. The answering peer calculates its own encrypted result based on its challenge string and the MD4 hash of the user's password and compares it to the version in the MS-CHAP v2 Response message. If the two results are identical, the answering peer sends a CHAP Success message with a Message field that contains an encrypted response based on the calling peer's challenge string, the answer- ing peer's challenge string, the calling peer's response, the calling peer's user name, and the calling peer's password. If the two results are not identical, the answering peer sends a CHAP Failure message.
  4. The calling peer calculates its own encrypted result to validate the answering peer's encrypted response. If the results match, the calling peer continues with the next phase of the PPP connection. If not, the calling peer terminates the connection.

Figure 4-8 shows the structure of the MS-CHAP v2 Response message.

Figure 4-8. The MS-CHAP v2 Response message structure.

The following are the fields in the MS-CHAP v2 Response message:

  • Code For an MS-CHAP v2 Response message, the value of the Code field is set to 2.
  • Identifier A 1-byte field that is set to the value of the Identifier field in the original CHAP Challenge message.
  • Length A 2-byte field that indicates the size of the MS-CHAP v2 Response message in bytes.
  • Value Size A 1-byte field that indicates the size of the CHAP Value field. For the MS-CHAP v2 Response message, the CHAP Value field consists of the Peer Challenge, Reserved, Windows NT Response, and Flags fields and is a fixed size of 49 bytes.
  • Peer Challenge A 16-byte field that contains the challenge string for the answering peer as set by the calling peer.
  • Reserved An 8-byte field that should be set to 0.
  • Windows NT Response A 24-byte field that contains the Windows NT- encoded response.
  • Flags A 1-byte field that is reserved for future use and should be set to 0.
  • Name A variable-sized field that contains the name of the calling peer.

Capture 04-05 in the \Captures folder on the companion CD-ROM contains an example of an MS-CHAP v2 authentication.

Like MS-CHAP, MS-CHAP v2 also allows the answering peer to indicate specific error conditions in the Message field of the CHAP Failure message. One of the errors is ERROR_PASSWD_EXPIRED. When the calling peer receives this error indication, it can submit an MS-CHAP v2 Change Password message to submit a new password for the account corresponding to the user name. For more information about the MS-CHAP v2 Change Password message, see RFC 2759.

EAP

EAP was designed as an extension to PPP to allow for more extensibility and flexibility in the implementation of authentication methods for PPP connections. For PAP, CHAP, MS-CHAP, and MS-CHAP v2, the authentication process is a fixed exchange of messages. With EAP, the authentication process can consist of an open-ended conversation, in which messages are sent by either PPP peer on an as-needed basis. In addition, unlike the PPP authentication protocols discussed so far in this chapter, EAP does not select a specific authentication method during phase 1 of the connection. Rather, the selection of a specific EAP authentication method, known as an EAP type, is done during phase 3 of the connection. EAP is described in RFC 2284.

When EAP is negotiated during phase 1, the LCP option data for the authentication protocol indicates EAP (0xC2-27). EAP messages use the PPP Protocol ID 0xC2-27.

The Windows Server 2003 family includes the EAP-MD5 CHAP, EAP-Transport Level Security (TLS), and Protected EAP (PEAP) EAP types. Because EAP is architecturally designed to support multiple EAP types, additional types can be added by creating an EAP type dynamic-link library (DLL) file using the EAP Software Development Kit (SDK), which is part of the Windows Server Platform SDK, and installing the DLL file on the calling peer and the authenticating server. The authenticating server is the computer that actually performs the validation of the calling peer's credentials and is typically either the answering peer or a central authentication server, such as a Remote Authentication Dial-In User Service (RADIUS) server.

EAP defines four types of messages:

  1. An EAP-Request message is sent by the authentication server to request information from the calling peer. There can be multiple EAP-Request messages for an EAP authentication session.
  2. An EAP-Response message is sent by the calling peer to indicate information requested by the authentication server in an EAP-Request message.
  3. An EAP-Success message is sent by the authentication server when the calling peer has successfully responded to all of the EAP-Request messages for the EAP session.
  4. An EAP-Failure message is sent by the authentication server when the calling peer has not successfully responded to all of the EAP-Request messages for the EAP session.

Figure 4-9 shows the structure of EAP-Request and EAP-Response messages.

Figure 4-9. EAP-Request and EAP-Response message structure.

The following are the fields in an EAP-Request or EAP-Response message:

  • Code A 1-byte field that identifies the type of EAP message. For an EAP- Request message, the value of the Code field is set to 1. For an EAP-Response message, the value of the Code field is set to 2.
  • Identifier A 1-byte field that is used to match an EAP-Request message with an EAP-Response message.
  • Length A 2-byte field that indicates the size of the EAP message in bytes.
  • Type A 1-byte field that indicates the EAP type. For EAP-MD5 CHAP, the value of the Type field is 4.
  • Type-Specific Data A variable-sized field that contains data for the specific EAP message. For example, in the EAP-Response/Identity message, the type-specific data is a string that identifies the calling PPP peer.

Table 4-3 lists EAP types.

Table 4-3. EAP Types
Type Value | Type | Description
1 | Identity | Used by the authenticating server to request the identity of the calling client (in the EAP-Request/Identity message) and used by the calling client to indicate its identity to the authenticating server (in the EAP-Response/Identity message).
2 | Notification | Used by the authentication server to indicate a displayable message to the calling peer.
3 | Nak | Used by a calling peer in a response message to indicate that the calling peer does not support the authentication type proposed by the authenticating server. The Nak message also includes a proposed authentication type that is supported by the calling peer.
4 | MD5 Challenge | Used for the messages of the MD5-CHAP authentication method.
13 | EAP-TLS | Used for the messages of the TLS authentication method.

Figure 4-10 shows the structure of EAP-Success and EAP-Failure messages.

Figure 4-10. EAP-Success and EAP-Failure message structure.

The following are the fields in an EAP-Success and EAP-Failure message:

  • Code For an EAP-Success message, the value of the Code field is set to 3. For an EAP-Failure message, the value of the Code field is set to 4.
  • Identifier Set to the value of the last EAP-Response message.
  • Length For the EAP-Success and EAP-Failure messages, the Length field is set to 4.

EAP-MD5 CHAP

The EAP-MD5 CHAP type is the MD5-based CHAP authentication protocol performed using EAP messages, rather than its own messages. EAP-MD5 CHAP authentication consists of the following process:

  1. The authenticating server sends an EAP-Request/Identity message to the call-ing peer.
  2. The calling peer sends an EAP-Response/Identity message to the authenticat-ing server.
  3. The authenticating server sends an EAP-Request/MD5-Challenge message to the calling peer containing a challenge string and the name of the authenticating server.
  4. The calling peer sends an EAP-Response/MD5-Challenge message to the authenticating server containing the user's name and an MD5 hash of the CHAP session ID, the challenge string, and the user's password.
  5. The authenticating server calculates its own MD5 hash of the CHAP session ID, the challenge string, and the user's password and compares the result with the MD5 hash in the EAP-Response/MD5-Challenge message. If the two hashes are identical, the authenticating server sends an EAP-Success message. If not, the authenticating server sends an EAP-Failure message and the connection is terminated.

Figure 4-11 shows the structure of the EAP-Request/MD5-Challenge and EAP-Response/MD5-Challenge messages.

Figure 4-11. EAP-Request/MD5-Challenge and EAP-Response/MD5-Challenge message structure.

The following are the fields in the EAP-Request/MD5-Challenge and EAP-Response/MD5-Challenge messages:

  • Code A 1-byte field that identifies the type of EAP message. For an EAP- Request/MD5-Challenge message, the value of the Code field is set to 1. For an EAP-Response/MD5-Challenge message, the value of the Code field is set to 2.
  • Identifier A 1-byte field that is used to match an EAP-Request/MD5-Challenge message with an EAP-Response/MD5-Challenge message. This is the CHAP session ID for EAP-MD5 CHAP authentication.
  • Length A 2-byte field that indicates the size of the CHAP message in bytes.
  • Type A 1-byte field that indicates the EAP type. For EAP-MD5 Challenge, the value of the Type field is 4.
  • Value Size A 1-byte field that indicates the size of the Value field. Because the Value for MD5-Challenge is a 16-byte challenge string and the response is an MD5 hash (also 16 bytes long), the value of the Value Size field is set to 16 for both types of messages.
  • Value For an EAP-Request/MD5-Challenge message, the Value field contains the challenge string of the authenticating server. For an EAP-Response/MD5-Challenge, the value contains an MD5 hash of the challenge string and the calling peer's user password.
  • Name A variable-sized field that contains the name of either the authenticating server for the EAP-Request/MD5-Challenge message or the calling peer for the EAP-Response/MD5-Challenge message.

Capture 04-06 in the \Captures folder on the companion CD-ROM contains an example of an EAP-MD5 CHAP authentication.

EAP-TLS

EAP-TLS is the use of TLS to provide authentication for the establishment of a PPP connection. TLS is described in RFC 2246 and EAP-TLS is described in RFC 2716. EAP-TLS provides mutual authentication (the calling PPP peer authenticates to the authenticating server and the authenticating server answers to the calling PPP peer), protected negotiation of the set of cryptographic services used for the connection, and mutual determination of encryption and signing key material. EAP-TLS uses certificates rather than passwords for authentication, resulting in a highly secure authentication method.

The details of EAP-TLS negotiation are beyond the scope of this book. For more details, see RFCs 2716 and 2246.


Callback and the Callback Control Protocol

After the authentication phase of the PPP connection process, CBCP negotiates the use of callback. If callback is negotiated, the answering PPP peer terminates the PPP connection, and then calls the original calling PPP peer at a specified phone number. CBCP messages use the PPP Protocol ID 0xC0-29 and have the same structure as LCP messages. However, only the first seven LCP message types are used, corresponding to LCP Codes 1 through 3. For the Callback-Request (Code set to 1), Callback-Response (Code set to 2), and Callback-Ack (Code set to 3) messages, the data portion of the CBCP message contains one or more CBCP options.

Table 4-4 lists the CBCP options used by Microsoft PPP peers.

Table 4-4. CBCP Options
Option Name | Type | Length | Description
No Callback | 1 | 2 | Used to specify that callback is not used
Callback to a User-Specified Number | 2 | Variable | Used to specify that the calling PPP peer determines the callback number
Callback to an Administrator-Defined Number | 3 | Variable | Used to specify that the answering PPP peer determines the callback number
Callback to Any of a List of Numbers | 4 | Variable | Used to specify that the answering PPP peer calls the calling PPP peer back at one of a list of phone numbers


Network Control Protocols

After the callback phase of the PPP connection process, individual NCPs are used to negotiate the configuration of networking protocols, such as TCP/IP, and the additional PPP facilities of compression and encryption.

IPCP

IPCP is used to automatically configure TCP/IP configuration for a calling PPP peer. IPCP as used by Microsoft PPP peers is described in RFCs 1332 and 1877. RFC 1332 defines the original set of IPCP options and RFC 1877 defines an additional set of options to automatically configure the IP address of name servers such as Domain Name System (DNS) and Windows Internet Name Service (WINS) servers.

IPCP messages use the PPP Protocol ID 0x80-21 and have the same structure as LCP messages. However, only the first seven LCP message types are used, corresponding to LCP Codes 1 through 7. For the Configure-Request (Code set to 1), Configure-Ack (Code set to 2), Configure-Nak (Code set to 3), and Configure-Reject (Code set to 4) IPCP messages, the data portion of the IPCP message contains one or more IPCP options.

Table 4-5 lists the IPCP options defined in RFCs 1332 and 1877 that are used by Microsoft PPP peers.

Table 4-5. IPCP Options
Option Name | Type | Length | Description
IP Compression Protocol | 2 | 4 | Negotiates the use of Van Jacobsen compression
IP Address | 3 | 6 | Used to assign an IP address to the point-to-point interface of the calling PPP peer
Primary DNS Server Address | 129 | 6 | Used to assign a primary DNS server to the point-to-point interface of the calling PPP peer
Primary NBNS Server Address | 130 | 6 | Used to assign a primary NetBIOS Name Server (NBNS) server, a WINS server, to the point-to-point interface of the calling PPP peer
Secondary DNS Server Address | 131 | 6 | Used to assign a secondary DNS server to the point-to-point interface of the calling PPP peer
Secondary NBNS Server Address | 132 | 6 | Used to assign a secondary NBNS server, a WINS server, to the point-to-point interface of the calling PPP peer

A typical TCP/IP configuration for a local area network (LAN) interface includes an IP address, a subnet mask, and a default gateway. A PPP interface configured with IPCP does not include a subnet mask or a default gateway. For computers running Windows XP or a member of the Windows Server 2003 family, the subnet mask of 255.255.255.255 is automatically configured. In addition, a new default route is added to the routing table. This new default route has the gateway and interface addresses set to the IP address of the PPP interface and a routing metric of 1. The routing metric of the existing default route is increased for the duration of the PPP connection. This behavior can be modified in the General tab of the Properties dialog box of the TCP/IP protocol for a dial-up or VPN connection by clearing the Use Default Gateway On Remote Network check box.

Although DNS server IP addresses are assigned, a DNS domain name is not. To automatically configure a DNS domain name, PPP calling peers running Windows XP or a member of the Windows Server 2003 family send a DHCPINFORM message on the PPP link after the PPP connection is established. If the answering peer supports the relaying of Dynamic Host Configuration Protocol (DHCP) messages, the DHCPINFORM message is relayed to a DHCP server and the response is relayed back to the PPP calling peer. Based on the DNS domain name DHCP option (Option 15) in the response, the PPP peer automatically configures a DNS domain name on the point-to-point interface.

Compression Control Protocol

Compression Control Protocol (CCP), described in RFC 1962, allows PPP peers to negotiate the use of a data compression algorithm. CCP messages use the PPP Protocol 0x80-FD and have the same structure as LCP messages. However, only the first seven LCP message types are used, corresponding to LCP Codes 1 through 7. For the Configure- Request (Code set to 1), Configure-Ack (Code set to 2), Configure-Nak (Code set to 3), and Configure-Reject (Code set to 4) CCP messages, the data portion of the CCP message contains one or more CCP options. Table 4-6 lists these CCP options.

Table 4-6. CCP Options
Option Name | Type | Length | Description
Organization Unique Identifier | 0 | 6 or larger | Used to identify a proprietary compression protocol
Microsoft Point-to-Point Compression (MPPC) | 18 | 6 | Used to indicate the use of MPPC, Microsoft Point-to-Point Encryption (MPPE), and MPPE encryption options

MPPE and MPPC

CCP option 18 for MPPC is used to negotiate the use of both MPPC and MPPE, as described in RFC 3078. The data for CCP option is a 4-byte (32-bit) Supported Bits field that contains bits to indicate the use of CCP and the use of MPPE and MPPE encryption options. Within the 32-bit Supported Bits field, the following bits are defined:

  • The low-order bit enables (when set to 1) or disables (when set to 0) the use of MPPC.
  • The fifth low-order bit (starting from 1) enables (when set to 1) or disables (when set to 0) the use of 40-bit encryption keys for MPPE that are derived from the LAN Manager encoding of the user's password. This bit is obsolete and its use should be rejected.
  • The sixth low-order bit (starting from 1) enables (when set to 1) or disables (when set to 0) the use of 40-bit encryption keys for MPPE that are derived from the Windows NT encoding of the user's password.
  • The seventh low-order bit (starting from 1) enables (when set to 1) or disables (when set to 0) the use of 128-bit encryption keys for MPPE that are derived from the Windows NT encoding of the user's password.
  • The eighth low-order bit (starting from 1) enables (when set to 1) or disables (when set to 0) the use of 56-bit encryption keys that are derived from the Windows NT encoding of the user's password.
  • The 25th low-order bit (starting from 1) enables (when set to 1) or disables (when set to 0) the use of stateless encryption mode, in which the MPPE encryption key is changed with every message sent or received.

When negotiating MPPC and MPPE, the PPP peers determine a common setting for MPPC (enabled or disabled), a common highest MPPE encryption strength (the use of 40-bit, 56-bit, or 128-bit encryption keys), and whether to use stateless MPPE.

MPPE is only possible if the authentication protocol used during the authentication phase is MS-CHAP, MS-CHAP v2, or EAP-TLS. Only these authentication methods provide mutually determined keying material that is used as the initial MPPE encryption key.

Both MPPC and MPPE use the same PPP Protocol ID, 0x00-FD. However, each PPP peer knows whether MPPC, MPPE, or both are being used for frames sent on the PPP connection. Therefore, for the following cases:

  • If MPPC is used and MPPE is not, the PPP Protocol ID is 0x00-FD and the PPP payload is decompressed using the MPPC decompression algorithm.
  • If MPPE is used and MPPC is not, the PPP Protocol ID is 0x00-FD and the PPP payload is decrypted using the MPPE decryption algorithm.
  • If both MPPC and MPPE are used, the PPP payload is always compressed before it is encrypted. Therefore, the PPP Protocol ID 0x00-FD identifies an MPPE-encrypted payload. The payload is first decrypted using MPPE. The resulting MPPE payload consists of a PPP header with the PPP Protocol ID set to 0x00-FD and a payload compressed with MPPC. MPPC decompresses the payload. The resulting MPPC payload consists of a PPP header with the PPP Protocol ID set to 0x00-21 (assuming an IP datagram).

If the PPP payload is compressed with MPPC or encrypted with MPPE, the PPP payload is not parsed by Network Monitor. When using Network Monitor to troubleshoot PPP payloads after the PPP connection is created, disable compression and encryption.

Encryption Control Protocol

Encryption Control Protocol (ECP), described in RFC 1968, allows PPP peers to negotiate the use of a data encryption algorithm. ECP messages use the PPP Protocol IDs 0x80-53 or 0x80-55 and have the same structure as LCP messages. However, because Microsoft PPP peers only support the use of MPPE for encryption of PPP payloads, ECP is not supported or used. For more information, see RFC 1968.

Network Monitor Example

The following Network Monitor summary (Capture 04-07 in the \Captures folder on the companion CD-ROM) is an example of a successful PPP connection using the MS-CHAP v2 authentication protocol:

1	7.060152	RECV	RECV	LCP			Config Req
            Packet, Ident = 0x00, Length = 50

2	7.060152	SEND	SEND	LCP			Config Req
            Packet, Ident = 0x00, Length = 58

3	7.060152	SEND	SEND	LCP			Config Ack
            Packet, Ident = 0x00, Length = 50

4	7.130253	RECV	RECV	LCP			Config Reject
            Packet, Ident = 0x00, Length = 8

5	7.130253	SEND	SEND	LCP			Config Req
            Packet, Ident = 0x01, Length = 54

6	7.220383	RECV	RECV	LCP			Config No Ack
            Packet, Ident = 0x01, Length = 9

7	7.220383	SEND	SEND	LCP			Config Req
            Packet, Ident = 0x02, Length = 55

8	7.320527	RECV	RECV	LCP			Config Ack
            Packet, Ident = 0x02, Length = 55

9	7.320527	SEND	SEND	PPPCHAP			Challenge, ID =
            0x 0: Challenge

10	7.330541	RECV	RECV	LCP			Ident Packet,
            Ident = 0x01, Length = 18

11	7.350570	RECV	RECV	LCP			Ident Packet,
            Ident = 0x02, Length = 24

12	7.390628	RECV	RECV	PPPCHAP			Challenge, ID =
            0x 0: Response, test

13	7.390628	SEND	SEND	PPPCHAP			Challenge, ID =
            0x 0: Success

14	7.390628	SEND	SEND	CBCP			Callback Request,
            Ident = 0x01

15	7.430685	RECV	RECV	CBCP			Callback
            Response, Ident = 0x01

16	7.430685	SEND	SEND	CBCP			Callback
            Acknowledgement, Ident = 0x01

17	7.440700	SEND	SEND	CCP			Configuration
            Request, Ident = 0x04

18	7.440700	SEND	SEND	IPCP			Configuration
            Request, Ident = 0x05

19	7.450714	RECV	RECV	CCP			Configuration
            Request, Ident = 0x03

20	7.450714	SEND	SEND	CCP			Configuration
            Acknowledgement, Ident = 0x03

21	7.470743	RECV	RECV	IPCP			Configuration
            Request, Ident = 0x04

22	7.470743	SEND	SEND	IPCP			Configuration
            Reject, Ident = 0x04

23	7.480757	RECV	RECV	CCP			Configuration
            Acknowledgement, Ident = 0x04

24	7.490772	RECV	RECV	IPCP			Configuration
            Acknowledgement, Ident = 0x05

25	7.510800	RECV	RECV	IPCP			Configuration
            Request, Ident = 0x05

26	7.510800	SEND	SEND	IPCP			Configuration No
            Acknowledgement, Ident = 0x05

27	7.540844	RECV	RECV	IPCP			Configuration
            Request, Ident = 0x06

28	7.540844	SEND	SEND	IPCP			Configuration
            Acknowledgement, Ident = 0x06

In this example, the following frames show the four phases of the PPP connection:

  • Frames 1 through 8 and frames 10 and 11 are for phase 1, the LCP negotiation.
  • Frames 9, 12, and 13 are for phase 2, authentication.
  • Frames 14 through 16 are for phase 3, callback.
  • Frames 16, 19, 20, and 23 are for CCP negotiation (in phase 4). Frames 18, 21, 22, and 24 through 28 are for IPCP negotiation (in phase 4).


PPP over Ethernet

PPP over Ethernet (PPPoE) is a method of encapsulating PPP frames so that they can be sent over an Ethernet network. PPPoE was created so that Internet service providers (ISPs) that deploy a broadband Internet access technology in a bridged Ethernet topology, such as cable modems or Digital Subscriber Line (DSL), can use the per-user authentication and connection identification facilities of PPP to identify individual customer connections for accounting and billing purposes. PPPoE is described in RFC 2516.

PPPoE connections have the following two phases:

  1. A discovery phase in which a client computer uses PPPoE frames to discover the presence of an access concentrator (AC), a device that terminates the cable modem or DSL connection and provides access to the Internet, and to determine a PPPoE session ID
  2. A PPP session phase, in which a PPP connection is established and used for data transfer in the same way as a dial-up or VPN-based PPP connection

Figure 4-12 shows a PPPoE frame.

Figure 4-12. The structure of a PPPoE frame.

The following are the fields in the PPPoE frame:

  • Version A 4-bit field that is set to the value of 1.
  • Type A 4-bit field that is set to the value of 1.
  • Code A 1-byte field that is used to identify the type of PPPoE message. There are defined values for the PPPoE frames exchanged during the discovery phase. For PPP frames, the Code field is set to 0.
  • Session_ID A 2-byte field that identifies the PPPoE session ID. This field is set to 0 until a session ID is negotiated with the AC during the discovery phase of the PPPoE connection.
  • Length A 2-byte field that is used to indicate the size in bytes of the PPPoE payload.
  • PPPoE Payload A variable-sized payload that can contain either one or more PPPoE tags for PPPoE frames sent during the discovery phase or PPP frames for the PPP session phase. PPPoE tags are information elements in TLV format. Typical PPPoE tags used during the discovery phase are Service-Name (the name of the ISP or service offered by the AC) and AC-Name (the name of the AC). For a complete list of PPPoE tags and their structure, see RFC 2516.

The EtherType value in the Ethernet II header for PPPoE frames is set to 0x88-63 for PPPoE discovery frames and 0x88-64 for PPP session frames. For more information about the Ethernet II header, see Chapter 1, "Local Area Network (LAN) Technologies."

PPPoE Discovery Stage

The PPPoE discovery process consists of the following four PPPoE frames:

  1. The PPPoE Active Discovery Initiation (PADI) frame is sent by the PPPoE client to the Ethernet broadcast address (0xFF-FF-FF-FF-FF-FF). Within the Ethernet payload, the Code field is set to 9, the Session ID is set to 0, and there is a single Service-Name PPPoE tag, as well as other tags as needed. If the network connection in the Network Connections folder corresponding to the broadband Internet adapter has been configured with a service name, that service name is sent. Otherwise, the PADI frame is sent with a null service name.
  2. The PPPoE Active Discovery Offer (PADO) frame is sent by the AC to the unicast MAC address of the PPPoE client. Within the Ethernet payload, the Code field is set to 7, the Session ID is set to 0, there are the AC-Name and Service-Name tags, and other tags as needed. If the network connection in the Network Connections folder corresponding to the broadband Internet adapter has not been configured with a service name, it is automatically set to the value of the Service-Name tag in the PADO frame.
  3. The PPPoE Active Discovery Request (PADR) frame is sent by the PPPoE client to the unicast MAC address of the AC. Within the Ethernet payload, the Code field is set to 25, the Session ID is set to 0, and there is a Service-Name tag and other tags as needed.
  4. The PPPoE Active Discovery Session-confirmation (PADS) frame is sent by the AC to the unicast MAC address of the PPPoE client. Within the Ethernet payload, the Code field is set to 101, the Session ID field is set to the session ID for the PPP session of the PPPoE client, and there is a Service-Name tag, as well as other tags as needed.

To terminate the PPPoE session, either the PPPoE client or the AC can send a PPPoE Active Discovery Terminate (PADT) frame, which contains the Code field set to 167 and the session ID set to the session being terminated.

PPPoE Session Stage

After the PPPoE discovery process is complete, a PPP connection is negotiated and network protocol data such as IP datagrams are sent over the PPPoE connection. Figure 4-13 shows a PPPoE frame that contains a PPP frame.

Figure 4-13. The structure of a PPPoE frame that contains a PPP frame.

Because of the additional PPPoE overhead, the maximum size of PPP frames that can be sent over a PPPoE connection is 1494 bytes.


Summary

PPP is used for encapsulation, link negotiation, and network protocol negotiation for network protocol packets that are sent over a point-to-point link. The PPP connection process has four phases: link negotiation, authentication, callback negotiation, and network protocol negotiation. During link negotiation, each PPP peer determines how it will send PPP frames. During authentication, PPP authentication protocols such as CHAP, MS-CHAP, and EAP are used to verify the credentials of the calling or answering PPP peer. During callback negotiation, the calling and answering PPP peers determine whether the answering PPP peer will call the calling peer back and at which phone number. During network protocol negotiation, NCPs such as IPCP, CCP, and ECP are used to determine the use and configuration of TCP/IP, compression, and encryption.

PPPoE is a method of encapsulating PPP frames so that they can be sent over an Ethernet link. A PPPoE connection consists of two phases: a PPPoE discovery phase and a PPPoE session phase. After a PPPoE connection is negotiated during the discovery phase, PPP is used to negotiate a connection and send network protocol frames during the PPPoE session phase.


Internet Protocol (IP) Basics

Part II
Internet Layer Protocols
Chapter 5
Internet Protocol (IP) Basics

To fully grasp TCP/IP, one needs to have a thorough understanding of one of its most important protocols: IP. IP is the internetworking building block of all the other protocols at the Internet Layer and above.


Introduction to IP

IP embodies the Internet Layer of the Department of Defense (DoD) Advanced Research Projects Agency (DARPA) model and provides the internetworking functionality that makes possible large-scale internetworks such as the Internet. IP has lasted since it was formalized in 1981, and will continue to be used on the Internet for years to come. Only relatively recently have IP's shortcomings been addressed in a new version known as IP version 6 (IPv6). For more information on IPv6, see Chapter 10, "Internet Protocol Version 6 (IPv6)." IP's amazing longevity is a tribute to its original design.

RFC 791, "Internet Protocol," describes IP. This RFC can be found in the \Rfc folder on the companion CD-ROM.
This chapter uses the term IP to refer to version 4 of IP, which is in widespread use today. IP version 6 is denoted as IPv6.

IP Services

IP offers the following services to upper layer protocols:

  • Internetworking protocol IP is an internetworking protocol, also known as a routable protocol. The IP header contains information necessary for routing the packet, including source and destination IP addresses. An IP address is composed of two components: a network address and a node address. Internetwork delivery, or routing, is possible because of the existence of a destination network address. IP allows the creation of an IP internetwork, which consists of two or more networks interconnected by IP router(s).

    The IP header also contains a link count, which is used to limit the number of links on which the packet can travel before being discarded.

  • Multiple client protocols IP is an internetwork carrier for upper layer protocols. IP can carry several different upper layer protocols, but each IP packet can contain data from only one upper layer protocol at a time. Because each packet can carry one of several protocols, there must be a way to indicate the upper layer protocol of the packet payload so that it can be forwarded to the appropriate upper layer protocol at the destination. Both the client and the server always use the same protocol for a given exchange of data. Therefore, the packet does not need to indicate separate source and destination protocols.

    Examples of upper layer protocols include other Internet Layer protocols such as Internet Control Message Protocol (ICMP) and Internet Group Management Protocol (IGMP) and Transport Layer protocols such as TCP and User Datagram Protocol (UDP).

  • Datagram delivery IP is a datagram protocol that provides a connectionless, unreliable delivery service for upper layer protocols. Connectionless means that no handshaking occurs between IP nodes prior to sending data, and no logical connection is created or maintained at the Internet Layer. Unreliable means that IP sends a packet without sequencing and without an acknowledgment that the destination was reached. IP makes a best effort to deliver packets to the next hop or the final destination. End-to-end reliability is the responsibility of upper layer protocols such as TCP.
  • Independence from Network Interface Layer At the Internet Layer, IP is designed to be independent of the network technology present at the Network Interface Layer. IP is independent of Open Systems Interconnection (OSI) Physical Layer attributes such as cabling, signaling, and bit rate. It also is independent of OSI Data Link Layer attributes such as media access control (MAC) scheme, addressing, and maximum frame size. IP uses a 32-bit address that is independent of the addressing scheme used at the Network Interface Layer.
  • Fragmentation and reassembly To support the maximum frame sizes of different Network Interface Layer technologies, IP allows for the fragmentation of a payload when forwarding onto a link that has a lower maximum transmission unit (MTU) than the IP datagram size. Routers or sending hosts fragment an IP payload, and fragmentation can occur multiple times. The destination host then reassembles the fragments into the originally sent IP payload. More information on fragmentation and reassembly are provided later in this chapter in the section entitled "Fragmentation."
  • Extensible through IP options When features are required that are not available using the standard IP header, IP options can be used. IP options are appended to the standard IP header and provide custom functionality, such as the ability to specify a path that an IP datagram follows through the IP internetwork.
  • Datagram packet-switching technology IP is an example of a datagram packet-switching technology: Each packet is a datagram, an unacknowledged and nonsequenced message that is forwarded by the switches of the switching network using a globally significant address. In the case of IP, each switch in the switching network is an IP router, and the globally significant address is the destination IP address. This address is examined at each router, which makes an independent routing decision and forwards the packet. Because each router decides independently where to forward a packet, a packet's path from Node 1 to Node 2 is not necessarily a packet's path from Node 2 to Node 1. Additionally, because each packet is separately switched, each can take a different path between the source and destination; because of various transit delays, each packet can arrive in a different order from which it was sent.
The term switch is used here for a generalized forwarding device and is not meant to imply a Layer 2 switch. A Layer 2 switch is typically used in Ethernet environments to segment traffic.

IP MTU

Each Network Interface Layer technology imposes a maximum-sized frame that can be sent. This frame consists of the framing header and trailer and a payload. The maximum size of a frame for a given Network Interface Layer technology is called the MTU. For an IP packet, the Network Interface Layer payload is an IP datagram. Therefore, the maximum-sized payload becomes the maximum-sized IP datagram. This is known as the IP MTU.

Table 5-1 lists the IP MTUs for the various Network Interface Layer technologies that are described in Chapter 1, "Local Area Network (LAN) Technologies," and Chapter 2, "Wide Area Network (WAN) Technologies."

Table 5-1. IP MTUs for Common Network Interface Layer Technologies
Network Interface Layer Technology | IP MTU
Ethernet (Ethernet II encapsulation) | 1500
Ethernet (IEEE 802.3 Sub-Network Access Protocol [SNAP] encapsulation) | 1492
Token Ring (4 and 16 Mbps) | Varies based on token holding time
Fiber Distributed Data Interface (FDDI) | 4352
X.25 | 1600
Frame relay | 1592 (with a 2-byte Address field in the Frame Relay header)
Asynchronous Transfer Mode (ATM; Classical IP over ATM) | 9180

In an environment with mixed Network Interface Layer protocols, fragmentation can occur when crossing a router from a link with a higher IP MTU to a link with a lower IP MTU. IP fragmentation is discussed in more detail later in this chapter in the section entitled "Fragmentation."

In the Microsoft Windows Server 2003 family, it is possible to override the MTU as reported to the Network Driver Interface Specification (NDIS) interface by the network adapter driver using the following registry setting:

MTU

Key:		HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\InterfaceGUID

Data type: REG_DWORD

Valid range: 88 - <the MTU reported by the network adapter>

Default: 0xFFFFFFFF (the MTU reported by the network adapter)

Present by default: No

When TCP/IP initializes, it queries its bound NDIS network adapter driver and receives the MTU. The MTU registry setting is used to set an MTU that is lower than the default MTU, as reported by the NDIS driver, and greater than the minimum value of 88. Values in the MTU registry setting that are greater than the default MTU are ignored; if the MTU registry setting is set to a value less than 88, 88 is used.

It is useful to change the default MTU size for testing or for solving MTU issues in translational bridge environments.


The IP Datagram

An IP datagram consists of an IP header and an IP payload, as shown in Figure 5-1 and described here:

Figure 5-1. The IP datagram.
  • IP header The IP header is of variable size, between 20 and 60 bytes, in 4-byte increments. It provides routing support, payload identification, IP header and datagram size indication, fragmentation support, and options.
  • IP payload The IP payload is of variable size, ranging from 8 bytes (a 68-byte IP datagram with a 60-byte IP header) to 65,515 bytes (a 65,535-byte IP datagram with a 20-byte header).

As sent on a link, the IP datagram is wrapped with a Network Interface Layer header and trailer to create a Network Interface Layer frame.


The IP Header

Figure 5-2 shows the IP header's structure. The following sections discuss the fields of the IP header.

Figure 5-2. The structure of the IP header.

Version

The Version field is 4 bits long and is used to indicate the IP header version. A 4-bit field can have values from 0 through 15. The standard IP version used today on corporate networks and the Internet is version 4. The next version of IP is IPv6. All other values for the Version field are either undefined or not in use. For the latest list of the defined values of the IP Version field, see http://www.iana.org/assignments/version-numbers.

Header Length

The Header Length field is 4 bits long and is used to indicate the IP header size. The maximum number that can be represented with 4 bits is 15. Therefore, the Header Length field cannot possibly be a byte counter. Rather, the Header Length field indicates the number of 32-bit words (4-byte blocks) in the IP header. The typical IP header does not contain any options and is 20 bytes long. The smallest possible header length is 5 (0x5). With the maximum amount of IP options, the largest IP header can be 60 bytes long, indicated with a header length of 15 (0xF).

Using a 4-byte block counter to indicate the IP header size means that the IP header size must always be a multiple of 4. If IP options extend the IP header, they must do so in 4-byte increments. If an IP option is not 4 bytes long, option padding bytes must be used so that the IP header is always on a 4-byte boundary.

Type Of Service

The Type Of Service (TOS) field is 8 bits long and is used to indicate the quality of service with which this datagram is to be delivered by the internetwork routers. The TOS field has two definitions: the RFC 791 definition and the RFC 2474 definition.

RFC 791 Definition of the TOS Field

As defined in RFC 791, the TOS field contains subfields and flags to indicate desired precedence, delay, throughput, reliability, and cost characteristics.

Within the 8 bits of the TOS field, there are five fields that indicate a different quality of the datagram delivery, as shown in Figure 5-3. The TOS field is set by the sending host and is not modified by routers. All IP datagram fragments contain the same TOS setting as the original IP datagram.

Figure 5-3. The structure of the RFC 791 IP Type Of Service field.

Normally, a sending host sends an IP datagram with the TOS field set to the value of 0x00: routine precedence, normal delay, normal throughput, normal reliability, and normal cost. Routers normally ignore the values in the TOS field and forward all datagrams as if the fields are not set. This is known as TOS0 routing. However, modern routing protocols such as Open Shortest Path First (OSPF) and Integrated Intermediate System-Intermediate System (IS-IS) now support the calculation of routes for each value of the TOS field.

The routers and the routing protocol determine how the various values in the TOS field are interpreted. In a properly configured network, packets with specific TOS values are forwarded over different paths. This can improve routing and delivery efficiency in a multipath IP internetwork. For example, an IP internetwork could have one path for general traffic, one for low-delay traffic, and another path for high-reliability traffic. When sending hosts set various combinations of TOS values, routers can choose among those paths.

The TOS field is used for quality of service (QoS) in IP internetworks.

Precedence

The Precedence field is 3 bits long and is used to indicate the importance of the datagram. Table 5-2 lists the defined values of the Precedence field.

Table 5-2. Values of the IP Precedence Field
Precedence Value | Precedence
000 | Routine
001 | Priority
010 | Immediate
011 | Flash
100 | Flash Override
101 | CRITIC/ECP
110 | Internetwork Control
111 | Network Control

The Precedence field is set to 000 (Routine) by default.

Delay

The Delay field is a flag indicating either Normal Delay (when set to 0) or Low Delay (when set to 1). If Delay is set to 1, the IP router forwards the IP datagram along the path that has the lowest delay characteristics. An application can request the low delay path when sending either time-sensitive data, such as digitized voice or video, or interactive traffic, such as Telnet sessions. Based on the Delay flag, the router might choose the lower delay terrestrial wide area network (WAN) link over the higher delay satellite link, even if the satellite link has a higher bandwidth.

Throughput

The Throughput field is a flag indicating either Normal Throughput (when set to 0) or High Throughput (when set to 1). If the Throughput field is set to 1, the IP router forwards the IP datagram along the path that has the highest throughput characteristics. An application can request the high throughput path when sending bulk data. Based on the Throughput flag, the router can choose the higher throughput satellite link over the lower throughput terrestrial WAN link, even if the terrestrial link has a lower delay.

Reliability

The Reliability field is a flag indicating either Normal Reliability (when set to 0) or High Reliability (when set to 1). During periods of congestion at an IP router, the Reliability field is used to decide which IP datagrams to discard first. If the Reliability field is set to 1, the IP router discards these datagrams last. An application can request the high reliability path when sending time-sensitive data, so that it cannot be discarded. For example, with some methods of sending digital video, the digitized video is sent as two types of packets: The primary type is used to reconstruct the basic video image, and a secondary type is used to provide a higher resolution image. In this case, the primary packets are sent with the Reliability field set to 1 and the secondary packets are sent with the Reliability field set to 0. If congestion occurs at the router, the router discards the secondary packets first.

Cost

The Cost field is a flag indicating either Normal Cost (when set to 0) or Low Cost (when set to 1), where cost indicates monetary cost. If the Cost field is set to 1, the IP router forwards the IP datagram along the path that has the lowest cost characteristics. An application can request the low cost path when sending noncritical data. Based on the Cost flag, the router can choose a lower cost terrestrial link over a higher cost satellite link, even if the terrestrial link has a lower bandwidth.

Reserved

The Reserved field is the last bit and must be set to 0. Routers ignore this field when forwarding IP datagrams.

Setting the TOS with Ping

The Windows Server 2003 family Ping utility with the -v option can be used to set the TOS value in ICMP Echo messages. The syntax is as follows:

PING -v TOS_Value destination

The TOS value is expressed in decimal format. For example, to ping 10.0.0.1 with a TOS field that is normal precedence, minimum delay, and minimum monetary cost, use the following command:

ping -v 18 10.0.0.1

The Ping -v option has an effect only if the DisableUserTOSSetting registry setting is set to 0.

RFC 2474 Definition of the TOS Field

To accommodate QoS delivery of IP packets over an IP internetwork, RFC 2474 redefines the 8 bits in the TOS field in terms of a 6-bit Differentiated Services Code Point (DSCP) field and 2 unused bits. The DSCP value identifies the per-hop behavior that the receiving routers use to determine the special delivery handling for the packet. DSCP values are defined by network policy.

The RFC 2474-defined TOS field is shown in Figure 5-4.

Figure 5-4. The structure of the RFC 2474 IP TOS field.

Differentiated services are an alternative to IP QoS mechanisms that use the Resource ReSerVation Protocol (RSVP). RSVP requires a signaling process initiated by communicating nodes and that flow state be maintained at each intermediate router. With differentiated services, network policy determines the DSCP values and their corresponding delivery and queuing parameters. The network policy is propagated to both the routers and the communicating hosts. When a host needs a nondefault QoS delivery for a packet, it selects the appropriate DSCP value and places it in the TOS field in the IP header. The intermediate routers note the DSCP value and provide the corresponding nondefault QoS delivery service.

TCP/IP for the Windows Server 2003 family uses the RFC 2474 definition of the TOS field by default. Its value is set with the QoS components of the Windows Server 2003 family. You can permit applications to directly modify the TOS field with the following registry setting:

DisableUserTOSSetting

Key:		HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value type: REG_DWORD

Valid range: 0 - 1

Default: 1

Present by default: No

The DisableUserTOSSetting controls whether the TOS field can (when set to 0) or cannot (when set to 1) be specified by applications using Windows Sockets registry setting. By default, the TOS field cannot be specified by applications and is used exclusively for IP differentiated services QoS. If QoS is not being used and you want to specify the TOS field value using applications, set DisableUserTOSSetting to 0.

Total Length

The Total Length field is 2 bytes long and is used to indicate the size of the IP datagram (IP header and IP payload) in bytes. With 16 bits, the maximum total length that can be indicated is 65,535 bytes. For maximum-sized IP datagrams, the total length is the same as the IP MTU for that Network Interface Layer technology.

Between the header length and the total length, the IP payload length can be determined from the following formula:

IP payload length (bytes) = total length (bytes) - 4 X header length (32-bit words)

Identification

The Identification field is 2 bytes long and is used to identify a specific IP packet sent between a source and destination node. The sending host sets the field's value, and the field is incremented for successive IP datagrams. The Identification field is used to identify the fragments of an original IP datagram.

Flags

The Flags field is 3 bits long and contains two flags for fragmentation. One flag is used to indicate whether the IP payload is eligible for fragmentation, and the other indicates whether or not there are more fragments to follow for this fragmented IP datagram.

More information on these flags and their uses can be found in the section entitled "Fragmentation," later in this chapter.

Fragment Offset

The Fragment Offset field is 13 bits long and is used to indicate the offset of where this fragment begins relative to the original unfragmented IP payload.

More information on the Fragment Offset field can be found in the section entitled "Fragmentation," later in this chapter.

Time To Live

The Time To Live (TTL) field is 1 byte long and is used to indicate how many links on which this IP datagram can travel before an IP router discards it. The TTL field was originally intended for use as a time counter, to indicate the number of seconds that the IP datagram could exist on the Internet. An IP router was intended to keep track of the time that it received the IP datagram and the time that it forwarded the IP datagram. The TTL was then decreased by the number of seconds that the packet resided at the router.

However, the latest modern standard (RFC 1812) specifies that IP routers decrement the TTL by 1 when forwarding an IP datagram. Therefore, the TTL is an inverse link count. The sending host sets the initial TTL, which acts as a maximum link count. The maximum value limits the number of links on which the datagram can travel and prevents a datagram from indefinitely looping.

Some additional aspects of the TTL field include the following:

  • Routers decrement the TTL in received packets to be routed before consulting the routing table. If the TTL is less than 1, the packet is discarded and an ICMP Time Expired-TTL Expired In Transit message is sent back to the sending host.
  • Destination hosts do not check the TTL field.
  • Sending hosts must send IP datagrams with a TTL greater than 0. The exact value of the TTL for sent IP datagrams is either an operating system default or is specified by the application. The maximum value of the TTL is 255.
  • A recommended value of the TTL is twice the diameter of your internetwork. The diameter is the number of links between the farthest two nodes on the IP internetwork.
  • The TTL is independent of routing protocol metrics such as the Routing Information Protocol (RIP) hop count and the OSPF cost.
The TTL can be mistakenly referred to as a hop count when in fact it is a link count. The difference is subtle but important. The hop count is the number of routers to cross to reach a given destination. Link count is the number of Network Interface Layer links to cross to reach a given destination. The difference between hop count and link count is 1. For example, if Host A and Host B are separated by five routers, the hop count is 5, but the link count is 6. An IP datagram sent from Host A to Host B with a TTL of 5 is discarded by the fifth router. An IP datagram sent from Host A to Host B with a TTL of 6 will arrive at Host B.

You can change the default value of the TTL field for sent packets with the following registry setting:

DefaultTTL

Key:		HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value type: REG_DWORD

Valid range: 0 - 255

Default: 128

Present by default: No

The default value of DefaultTTL is set to 128 so that IP packets sent by a Windows Server 2003 family-based computer can reach locations on the Internet that might need to traverse many links. Changing the value of DefaultTTL is necessary only when the diameter of your network changes. Windows Sockets applications can override this default value.

Setting the TTL with Ping

The Windows Server 2003 family Ping utility with the -i option can be used to set the TTL value in ICMP Echo messages. The syntax is:

PING -i TTL_Value destination

The TTL value is expressed in decimal format. For example, to ping 10.0.0.1 with a TTL field that is set to 7, use the following command:

ping -i 7 10.0.0.1

The default TTL for ICMP Echo messages sent by Ping is 128.

Protocol

The Protocol field is 1 byte long and is used to indicate the upper layer protocol contained within the IP payload. The Protocol field is an explicit indication of the client protocol. Some common values of the IP Protocol field are 1 for ICMP, 6 for TCP, and 17 (0x11) for UDP. The Protocol field acts as a multiplex identifier so that the payload can be passed to the proper upper layer protocol on receipt at the destination node.

Windows Sockets applications can refer to protocols by name. Protocol names are resolved to protocol numbers through the Protocol file stored in the %SystemRoot%\ System32\Drivers\Etc directory.

Table 5-3 lists some of the values of the IP Protocol field for protocols that the Windows Server 2003 family supports.

Table 5-3. Values of the IP Protocol Field
Value | Protocol
1 | ICMP
2 | IGMP
4 | IP in IP encapsulation
6 | TCP
17 | UDP
41 | IPv6
47 | Generic Routing Encapsulation (GRE)
50 | IP Security Encapsulating Security Payload (ESP)
51 | IP Security Authentication Header (AH)
89 | OSPF

For a complete list of IP Protocol field values, see http://www.iana.org/assignments/protocol-numbers.

Header Checksum

The Header Checksum field is 2 bytes long and performs a bit-level integrity check on the IP header only. The IP payload is not included, and IP payloads must include their own checksums to check for bit-level integrity. The sending host performs an initial checksum in the sent IP datagram. Each router in the path between the source and destination verifies the Header Checksum field before processing the packet. If the verification fails, the router silently discards the IP datagram.

Because each router in the path between the source and destination decrements the TTL, the header checksum changes at each router.

To compute the header checksum, each 16-bit quantity in the IP header is ones complemented; bits within the 16-bit quantity that are set to 0 are changed to 1, bits within the 16-bit quantity that are set to 1 are changed to 0. The ones complemented 16-bit quantities are added together and the sum is ones complemented. The result is placed in the Header Checksum field.

For the purposes of computing the header checksum over all the fields in the IP header, the value of the Header Checksum field is set to 0.

Source Address

The Source Address field is 4 bytes long and contains the IP address of the source host, unless a Network Address Translator (NAT) is translating the IP datagram. A NAT is used to translate between public and private addresses when connecting to the Internet.

For more information on NAT, see RFC 1631 in the \Rfc folder on the companion CD-ROM.

Destination Address

The Destination Address field is 4 bytes long and contains the IP address of the destination host, unless the IP datagram is being translated by a NAT or being loose or strict source routed. More information on IP source routing can be found in the section entitled "IP Options," later in this chapter.

Options and Padding

Options and padding can be added to the IP header, but must be done in 4-byte increments so that the size of the IP header can be indicated using the Header Length field.

The following Network Monitor trace (Capture 05-01 in the \Captures folder on the companion CD-ROM) shows the structure of the IP header:

+	Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

    IP:	ID = 0x34CD; Proto = ICMP; Len: 60

        IP: Version = 4 (0x4)

        IP: Header Length = 20 (0x14)

        IP: Precedence = Routine

        IP: Type of Service = Normal Service

        IP: Total Length = 60 (0x3C)

        IP: Identification = 13517 (0x34cd)

        IP: Flags Summary = 0 (0x0)

            IP: .......0 = Last fragment in datagram

            IP: ......0. = May fragment datagram if necessary

        IP: Fragment Offset = 0 (0x0) bytes

        IP: Time to Live = 128 (0x80)

        IP: Protocol = ICMP - Internet Control Message

        IP: Checksum = 0xB869

        IP: Source Address = 157.59.8.1

        IP: Destination Address = 157.59.8.1

        IP: Data: Number of data bytes remaining = 40 (0x0028)

+	ICMP: Echo: From 157.59.11.19 To 157.54.08.01


Fragmentation

When a source host or a router must transmit an IP datagram on a link and the MTU of the link is less than the IP datagram's size, the IP datagram must be fragmented. When IP fragmentation occurs, the IP payload is segmented and each segment is sent with its own IP header.

The IP header contains information required to reassemble the original IP payload at the destination host. Because IP is a datagram packet-switching technology and the fragments can arrive in a different order from which they were sent, the fragments must be grouped (using the Identification field), sequenced (using the Fragment Offset field), and delimited (using the More Fragments flag).

Virtual circuit packet-switching technologies such as X.25 and ATM require only fragment/segment delimitation. For example, with ATM Adaptation Layer 5, an IP datagram is segmented into 48-byte segments that become the payloads for ATM cells. ATM sends the stream of cells that comprise the IP datagram and uses the third bit of the Payload Type field in the ATM header to indicate the end of the stream of cells for an IP datagram.

Fragmentation Fields

Figure 5-5 shows the fragmentation fields in the IP header, which are covered in the following sections.

Figure 5-5. The fields in the IP header used for fragmentation.

Identification

The IP Identification field is used to group all the fragments of an original IP datagram together. The sending host sets the value of the Identification field, and this value is not changed during the fragmentation process. The Identification field is set even when fragmentation of the IP payload is not allowed by setting the Don't Fragment (DF) flag.

Don't Fragment Flag

The DF flag is set to 0 to allow fragmentation and set to 1 to prohibit fragmentation, so fragmentation occurs only if the DF flag is set to 0. If fragmentation is needed to forward the IP datagram and the DF flag is set to 1, the router sends an ICMP Destination Unreachable-Fragmentation Needed And DF Set message back to the source host and discards the IP datagram.

Fragmentation and reassembly is an expensive process at the routers and the destination host. The DF flag and the ICMP Destination Unreachable-Fragmentation Needed And DF Set message are the mechanisms by which a sending host discovers the MTU of the path between the source and the destination, or Path MTU Discovery. For more information, see Chapter 8, "Internet Control Message Protocol (ICMP)."

More Fragments Flag

The More Fragments (MF) flag is set to 0 if there are no more fragments that follow this fragment (this is the last fragment), and set to 1 if there are more fragments that follow this fragment (this is not the last fragment).

Fragment Offset

The Fragment Offset field is set to indicate the position of the fragment relative to the original IP payload. The Fragment Offset is an offset used for sequencing during reassembly, putting the incoming fragments in proper order to reconstruct the original payload. The Fragment Offset field is 13 bits long. With a maximum IP payload size of 65,515 bytes (the maximum IP MTU of 65,535 minus a minimum-sized IP header of 20 bytes), the Fragment Offset field cannot possibly indicate a byte offset. At 13 bits, the maximum value is 8191. The fragment offset must be 16 bits long to be a byte offset.

Because 16 bits are required to indicate a maximum-sized IP payload and only 13 bits are available in the Fragment Offset field, each value of the fragment offset must represent 3 bits. Therefore, the Fragment Offset field is defined in terms of 8-byte blocks, called fragment blocks.

During fragmentation, the payload is fragmented along 8-byte boundaries and the maximum number of 8-byte fragment blocks is placed in each fragment. The Fragment Offset field is set to indicate the starting fragment block for the fragment relative to the original IP payload.

For each fragment being fragmented by a router, the original IP header is copied and the following fields are changed:

  • Header Length Might or might not change depending on whether IP options are present and whether the options are copied to all fragments or just the first fragment. IP options are discussed in the section entitled "IP Options," later in this chapter.
  • TTL Decremented by 1.
  • Total Length Changed to reflect the new IP header and IP payload size.
  • MF Set to 1 for first or middle fragments. Set to 0 for the last fragment.
  • Fragment Offset Set to indicate the position of the fragment in fragment blocks relative to the original unfragmented payload.
  • Header Checksum Recalculated based on the changed fields in the IP header.

The Identification field does not change for each fragment.

Fragmentation Example

As an example of the fragmentation process, a node on a Token Ring network sends a fragmentable IP datagram with the IP Identification field set to 9999 to a node on an Ethernet network, as shown in Figure 5-6.

Figure 5-6. An example of a network where IP fragmentation can occur.

Assuming a 9-ms token holding time, a 4-Mbps ring, and no Token Ring source routing header, the IP MTU for the Token Ring network is 4482 bytes. The Ethernet IP MTU is 1500 bytes using Ethernet II encapsulation. Table 5-4 shows the fields relevant to fragmentation in the IP header and their values for the original IP datagram.

Table 5-4. Original IP Datagram
IP Header Field | Value
Total Length | 4482
Identification | 9999
DF | 0
MF | 0
Fragment Offset | 0

The IP router connecting the two networks receives the IP datagram, checks its routing table, and notes that the interface on which to forward the datagram has a lower IP MTU than the datagram's size. The router then checks the DF flag. If set to 1, the router discards the IP datagram and sends an ICMP Destination Unreachable-Fragmentation Needed And DF Set message back to the source host. If set to 0, the IP router fragments the 4462-byte IP payload (assuming no IP options are present) into four fragments, each of which can be sent on the 1500-byte Ethernet network.

IP payloads on an Ethernet network can be 1480 bytes long, assuming no IP options are present. Each 1480-byte payload is 185 fragment blocks (185 X 8 = 1480). Therefore, the four fragments are three fragments each with payloads of 1480 bytes and the last fragment with a payload of 22 bytes (4462 = 1480 + 1480 + 1480 + 22). Figure 5-7 shows the fragmentation process.

Figure 5-7. The IP fragmentation process when fragmenting from a 4482-byte IP MTU link to a 1500-byte IP MTU link.

Table 5-5 shows the fields relevant to fragmentation in the IP header of the four fragments.

Table 5-5. Fragments of the Original IP Datagram
IP Header Field | Value
Fragment 1
Total Length | 1500
Identification | 9999
DF | 0
MF | 1
Fragment Offset | 0
Fragment 2
Total Length | 1500
Identification | 9999
DF | 0
MF | 1
Fragment Offset | 185
Fragment 3
Total Length | 1500
Identification | 9999
DF | 0
MF | 1
Fragment Offset | 370
Fragment 4
Total Length | 42
Identification | 9999
DF | 0
MF | 0
Fragment Offset | 555

Reassembly Example

The fragments are forwarded by the intermediate IP router(s) to the destination host. Because IP is a datagram-based packet-switching technology, the fragments can take different paths to the destination and arrive in a different order from which the fragmenting router forwarded them. IP uses the Identification and Source IP Address fields to group the arriving fragments together.

After receiving a fragment (not necessarily the first fragment of the original IP payload), IP allocates reassembly resources comprised of the following:

  • A data buffer to contain the IP payload (65,515 bytes)
  • A header buffer to contain the IP header (60 bytes)
  • A fragment block bit table (1024 bytes or 8192 bits)
  • A total length data variable
  • A timer

IP knows that a fragment arrived because either the MF flag or the Fragment Offset field has a nonzero value. An unfragmented IP datagram has the MF flag set to 0 and the Fragment Offset field set to 0. When the first fragment arrives (the Fragment Offset field is 0), its IP header is placed in the header buffer. When the last fragment arrives (the MF flag is 0), the total data length is computed.

For each arriving fragment, the IP payload is placed in the data buffer according to the values of the Fragment Offset and Total Length fields; the bits corresponding to the arriving fragment blocks are set in the fragment block bit table. When the final fragment arrives (which might not be the last fragment), all the bits in the fragment block bit table are set and reassembly of the original IP datagram is complete. IP delivers the IP payload to the appropriate upper layer protocol based on the Protocol field's value.

The reassembly timer is used to abandon the reassembly process within a certain amount of time. If all the fragments do not arrive before the reassembly timer expires, the IP datagram is discarded and the destination host can send an ICMP Time Exceeded-Fragmentation Time Expired message to the source host. RFC 791 recommends a default reassembly timer of 15 seconds; as fragments arrive, the reassembly timer is set to the maximum of the current value and the value of the arriving fragment's TTL field.

Figure 5-8 shows the reassembly process for our example fragmentation.

Figure 5-8. The IP reassembly process for the four fragments of the original IP datagram.

Fragmenting a Fragment

It is possible for fragments to become further fragmented. In this case, each fragmented payload is fragmented to fit the MTU of the link onto which it is being forwarded. The process of fragmenting a fragmented payload is slightly different from fragmenting an original IP payload in how the MF flag is set.

When fragmenting a fragmented payload, the MF flag is always set to 1, except when the fragment of the fragmented payload is the last fragment of the original payload.

  • If an IP router fragments a previously fragmented first or middle fragment, all of the fragments have the MF flag set to 1.
  • If an IP router fragments a previously fragmented last fragment, all of the fragments except the last fragment have the MF flag set to 1.

Therefore, regardless of how many times the IP datagram is fragmented, only one fragment has the MF flag set to 0, indicating the last fragment of the original IP payload.

Network Monitor Capture 05-02 (in the \Captures folder on the companion CD-ROM) provides another example of source-based IP fragmentation. The capture is the fragmentation of a 1500-byte IP datagram so that it fits on a subnet with a 576-byte IP MTU.

Avoiding Fragmentation

As seen from the preceding discussion, although fragmentation allows IP nodes to connect regardless of differing MTUs in intermediate network segments and without user intervention, IP fragmentation and reassembly is a relatively expensive process—both at the routers (or sending hosts) and at the destination host. On the modern Internet, fragmentation is highly discouraged; Internet routers are busy enough with the forwarding of IP traffic.

Fragmentation can be avoided by taking the following measures:

  • Set the DF flag to 1 on all IP datagrams sent.
  • Discover the IP MTU that is supported by all of the links in the path between the source and the destination (the path MTU).

For more information on the Path MTU Discovery process, see Chapter 8, "Internet Control Message Protocol (ICMP)."

Setting the DF Flag with Ping

The Windows Server 2003 family Ping utility with the -f option can be used to set the DF flag to 1 in ICMP Echo messages. The syntax is

ping -f destination

For example, to ping 10.0.0.1 and set the DF to 1, use the following command:

ping -f 10.0.0.1

By default, ICMP Echo messages sent by Ping have the DF flag set to 0 (fragmentation allowed).

Setting the IP Payload Size with Ping

The Windows Server 2003 family Ping utility with the -l option can be used to send IP packets with an arbitrary size by specifying the size of the Optional Data field in an ICMP Echo message. The syntax is:

ping -l Optional_Data_field_size destination

The Optional Data field size value is expressed in decimal format.

For example, to ping 10.0.0.1 with an Optional Data field size of 5000, use the following command:

ping -l 5000 10.0.0.1

The default Optional Data field size for Ping is 32 bytes.

The Optional Data field size is not the same as the IP payload size because ICMP Echo messages include an 8-byte ICMP header. Therefore, to calculate the IP payload's size, add 8 to the size of the ICMP payload. To calculate the IP datagram's size, add 20 to the size of the IP payload. To ping with an Echo message at the maximum size allowed by the Network Interface technology, subtract 28 from the IP MTU. For example, to ping with a maximum-sized Echo message on an Ethernet network (with an IP MTU of 1500), use the following Ping command:

ping -l 1472 10.0.0.1

Using Ping to Create Source-Fragmented Packets

The Windows Server 2003 family Ping utility with the -l option can be used to produce source-fragmented packets. Pinging with an ICMP payload size that is greater than (IP MTU - 28) bytes produces source-fragmented packets. For example, pinging from an Ethernet node with an ICMP payload size of 1472 or less does not produce fragmented packets. Pinging from an Ethernet node with an ICMP payload size greater than 1472 does produce fragmented packets.

Fragmentation and Translational Bridging Environments

Translational bridging is the interconnection of two different Network Interface Layer technologies on the same network by a Layer 2 device such as a bridge or switch. A common use for translational bridges is to connect an Ethernet segment to a Token Ring segment. In modern networks, switches use translational bridging to connect 10-Mbps or 100-Mbps Ethernet nodes to servers on high-speed ports. Common high-speed port technologies include FDDI, Gigabit Ethernet (GbE), and ATM.

The most serious obstacle to translational bridging is the difference in MTU between various Network Interface Layer technologies. Because there is no router involved, we cannot rely on either fragmentation or Path MTU Discovery processes to account for the differing MTUs. A translational bridge does not have the capability to fragment. Frames larger than the MTU of the link onto which they are to be forwarded are silently discarded by the bridge.

As discussed in Chapter 12, "Transmission Control Protocol (TCP) Basics," when a TCP connection is established, both nodes communicate MTU information in the form of the TCP Maximum Segment Size (MSS) option. After receiving each other's TCP MSS, both nodes agree to send TCP segments at the lowest MSS of the two nodes. However, despite this negotiation, proper communication between all nodes in a translational bridging environment might require the modification of the IP MTU of specific nodes.

For example, Figure 5-9 shows two Ethernet switches connected on an Ethernet backbone. On each Ethernet switch is an FDDI port connected to an FDDI ring containing application servers. When the servers on the same FDDI ring communicate with each other, they can send packets with the FDDI MTU of 4352 bytes. When an Ethernet node on one of the switches uses TCP to connect to an application server on either FDDI ring, the TCP MSS option lowers the MTU of TCP-based IP datagrams to 1500.

Figure 5-9. An MTU problem in a translational bridging environment caused by two FDDI hosts connected to two Ethernet switches.

However, consider the communication between application servers on different FDDI rings. In creating the TCP connection, each server negotiates an FDDI-based TCP MSS. Therefore, Ethernet switches silently discard TCP-based IP datagrams sent between servers on different rings that have an IP total length greater than 1500.

The solution to this problem is to manually configure the application servers' IP MTU for the smallest IP MTU of all the links within the translational bridged network.

Using our example, the IP MTU of the application servers on the FDDI rings are set to 1500, so translational bridges can forward IP datagrams between FDDI rings. Changing the application servers' MTU means that when sending packets to application servers on the same ring, the packets are sent at the lower MTU of 1500, a lower efficiency than the default FDDI MTU of 4352. However, it is better to have lower efficiency between servers on the same ring than zero efficiency between servers on different rings.

For nodes running a member of the Windows Server 2003 family, use the MTU registry setting to override the default MTU setting reported by NDIS.


IP Options

IP options are additional fields appended to the standard 20-byte IP header. Although IP options are not required on each IP header, the ability to process IP option fields is required. IP options are used infrequently for network testing purposes.

The IP options portion size of the IP header varies in length based on the IP options that are being used. The individual IP options also vary in length from a single octet to multiple four-octet quantities. Recall that the maximum-sized IP header that can be indicated with the Header Length field is 60 bytes. With a standard IP header size of 20 bytes, 40 bytes are left for IP options.

The first byte of each IP option has the format shown in Figure 5-10.

Figure 5-10. The structure of the IP option octet.

Copy

The Copy field is 1 bit long and is used when a router or a sending host must fragment the IP datagram. When the Copy field is set to 0, the IP option should be copied only into the first fragment. When the Copy field is set to 1, the IP option should be copied into all fragments.

Option Class

The Option Class field is 2 bits long and is used to indicate the general class of the option. Table 5-6 lists the defined option classes.

Table 5-6. Option Classes
Option Class | Description
0 | Network control
1 | Reserved for future use
2 | Debugging and measurement
3 | Reserved for future use

Option Number

The Option Number field is 5 bits long and is used to indicate a specific option within the option class. Each option class can have up to 32 different option numbers.

Table 5-7 lists the defined option classes and numbers for nonmilitary computing.

Table 5-7. Option Classes and Numbers
Option Class | Option Number | Description
0 | 0 | End Of Option List A one-octet option used to indicate the end of an option list
0 | 1 | No Operation A one-octet option used to align octets in a list of options
0 | 3 | Loose Source Routing A variable-length option used to route a datagram through a specified path where alternate routes can be taken
0 | 7 | Record Route A variable-length option used to trace a route through an IP internetwork
0 | 9 | Strict Source Routing A variable-length option used to route a datagram through a specified path where alternate routes cannot be taken
0 | 20 | IP Router Alert A fixed-length option used to inform the router that additional processing of the datagram is required
2 | 4 | Internet Timestamp A variable-length option used to record a series of timestamps at each hop

End Of Option List

The End Of Option List option is always a single octet in length and is used at the end of the IP options when they do not fall on a 4-byte boundary. This option is used only at the end of all the IP options, not at the end of each option.

No Operation

The No Operation option is always a single octet in length and is used between IP options when an IP option does not fall on a 4-byte boundary.

Record Route

The Record Route option is a variable-length option that is used to record the IP addresses of the far side interfaces of IP routers as it traverses the IP internetwork. The far side interface is the interface on the router on which the IP datagram is forwarded, presumed to be farthest from the sending host.

As the IP datagram is forwarded from router to router, each router adds its IP address to the list; each router also modifies the Next Slot Pointer field. The route from the source host to the destination host is recorded. To get the complete route, there must be enough room in the Record Route option header. Unlike Token Ring source routing, the number of IP address slots is specified by the sending host and is fixed in the IP header.

The Record Route option contains the following fields:

  • Option Code Set to 7 (Copy Bit=0, Option Class=0, Option Number=7).
  • Option Length Set by the sending host to the number of octets in the Record Route option.
  • Next Slot Pointer Set to the octet offset (starting at 1) within the Record Route option of the next available IP address. The minimum value of the Next Slot Pointer field is 4.
  • First IP Address, Second IP Address Set to the IP address of the far side interface by routers. With a maximum of 40 bytes in the IP options portion of the IP header, there is enough room for a maximum of nine IP addresses.

Record Route Processing

An IP router receiving an IP datagram with the Record Route option compares the Option Length and Next Slot Pointer fields. If the Next Slot Pointer field is less than the Option Length field, there are open IP address fields. The router records the IP address of the interface that is forwarding the datagram in the next available IP address field; the router also updates the Next Slot Pointer field by adding 4. If the value of the Next Slot Pointer field is greater than the Option Length field, routers have used all of the available IP address fields. The router then forwards the IP datagram without modifying the Record Route option.

Both hosts must agree that the information in the Record Route option will be processed in IP datagrams sent between them. If one host does not agree, the information in the Record Route option is ignored on receipt and return IP datagrams are not sent with the Record Route option.

Because the Record Route option size is not a multiple of 4 bytes, either an End Of Options option (if there are no more options) or a No Operation option (if there are more options) must be added to ensure that the IP header is an integral multiple of 4 bytes.

Setting the Record Route Option with Ping

The Windows Server 2003 family Ping utility with the -r option can be used to add the Record Route option and set the number of IP address slots in the Record Route option within an ICMP Echo message. The syntax is:

ping -r IP_address_slots destination

The IP address slots value is expressed in decimal format.

For example, to ping 10.0.0.1 with seven IP address slots, use the following command:

ping -r 7 10.0.0.1

When both hosts are computers running a member of the Windows Server 2003 family, the Record Route option records the IP addresses of the far side interfaces of forwarding routers in the ICMP Echo message. When the Echo message is received, the IP addresses recorded are maintained and the Echo Reply message is sent with the same Record Route option. The Echo Reply message contains the recorded route for the Echo message and the recorded route for the Echo Reply message.

Therefore, with the Ping -r option, it is possible to record the far side router interfaces for the Echo message (the path from Host A to Host B) and the far side router interfaces for the Echo Reply message (the path from Host B to Host A). However, because there is only room for nine IP address slots, this is possible only if there are no more than four routers between hosts.

Network Monitor Capture 05-03 (in the \Captures folder on the companion CD-ROM) provides an example of Ping utility traffic and the use of the Record Route option.

The Tracert utility does not use the Record Route option.

Strict and Loose Source Routing

The IP routing process at IP routers is performed through a comparison of the destination IP address with entries in a local routing table. Each router makes a forwarding decision. However, it is sometimes necessary to specify a path that an IP datagram is to take regardless of the router's routing table entries. The path is specified before the source host sends the datagram; this is known as source routing.

For example, in a multipath IP internetwork (where there is more than one path between IP networks), routers choose the best path based on a lowest cost metric. Once a router determines all of the best paths, the higher cost paths are not used unless the topology of the internetwork changes. To check that higher cost paths contain valid links, you must do source routing.

Source routing in IP is done by specifying the IP address(es) of the near side interfaces of the desired routers between the source and its destination. At each leg of the journey, the destination IP address in the IP header is set to the IP address of the next near side router interface. IP supports both loose and strict source routing. In loose source routing, the next router's IP address does not have to be a neighboring router; it can be multiple hops away. In strict source routing, the next router's IP address must be a neighboring router (a single hop away).

IP source routing also records the path taken in the same way as the Record Route option. For each leg of the journey, the IP address of the interface on the router that forwarded the IP datagram is recorded.

To use IP source routing, it must be enabled on all the routers in the path between the source and destination hosts. It is a common practice to disable source routing on routers, especially those connected to the Internet.

Strict Source Route Option

The Strict Source Route option contains the following fields:

  • Option Code Set to 137 (Copy Bit=1, Option Class=0, Option Number=9).
  • Option Length Set by the sending host to the number of octets in the Strict Source Route option.
  • Next Slot Pointer Set to the octet offset (starting at 1) within the Strict Source Route option for the next router. The Next Slot Pointer field's minimum value is 4. This field is used also in the same manner as the Record Route option to determine the location of the next IP address slot for recording the route.
  • First IP Address, Second IP Address Set by the sending host for the series of IP addresses for successive router destinations in the strict source route; set also by IP routers to the IP address of the forwarding interface. With a maximum of 40 bytes in the IP options portion of the IP header, there is enough room for a maximum of nine IP addresses.

When a sending host sends an IP datagram with the Strict Source Route option, the sending host does the following:

  1. Sets the Next Slot Pointer field's value to 4.
  2. Places the first IP address in the strict source route in the IP header's Destination IP Address field.

When an IP router receives an IP datagram with the Strict Source Route option, it compares the Option Length and Next Slot Pointer fields. If the Next Slot Pointer field is less than the Option Length field, the router does the following:

  1. Adds 4 to the Next Slot Pointer field's value.
  2. Replaces the IP header's destination IP address with the IP address that is recorded in the next slot (based on the Next Slot Pointer field's new value).
  3. Records the IP address of the forwarding interface in the previous slot.

If the next destination IP address is not reachable using a directly attached network (the IP address of a neighboring router or host), the IP datagram is discarded and an ICMP Destination Unreachable-Source Route Failed message is sent back to the source host.

If the Next Slot Pointer field's value is greater than the Option Length field's value, the IP datagram has reached its final destination.

Because the size of the Strict Source Route option is not a multiple of 4 bytes, either an End Of Options option (if there are no more options) or a No Operation option (if there are more options after the Strict Source Route option) must be added to ensure that the IP header is an integral multiple of 4 bytes. In the Windows Server 2003 family, TCP/IP places the Strict Source Route option as the last option in the list and uses an End Of Options option to specify the end of the list of options.

Setting the Strict Source Route Option with Ping

The Windows Server 2003 family Ping utility with the -k option can be used to add the Strict Source Route option. The Ping utility also can be used to set the IP addresses of successive routers and the final destination in ICMP Echo messages. The syntax is:

ping -k IP_address_of_first_hop IP_address_of_second_hop ...
destination_IP_address

For example, to ping 10.0.0.1 through neighboring router interfaces 192.168.1.1 and 192.168.2.1, use the following command:

ping -k 192.168.1.1 192.168.2.1 10.0.0.1

Network Monitor Capture 05-04 (in the \Captures folder on the companion CD-ROM) provides an example of Ping utility traffic and the use of the Strict Source Route option.

Loose Source Route Option

The Loose Source Route option contains the following fields:

  • Option Code Set to 131 (Copy Bit=1, Option Class=0, Option Number=3).
  • Option Length Set by the sending host to the number of octets in the Loose Source Route option.
  • Next Slot Pointer Set to the octet offset (starting at 1) within the Loose Source Route option for the next router. The Next Slot Pointer field's minimum value is 4. The Next Slot Pointer field also is used in the same manner as the Record Route option to determine the location of the next IP address slot for recording the route.
  • First IP Address, Second IP Address Set by the sending host for the series of IP addresses for successive router destinations in the loose source route, and set by IP routers to the forwarding interface's IP address. With a maximum of 40 bytes in the IP options portion of the IP header, there is enough room for a maximum of nine IP addresses.

When a sending host sends an IP datagram with the Loose Source Route option, the sending host does the following:

  1. Sets the Next Slot Pointer field's value to 4.
  2. Places the first IP address in the loose source route in the IP header's Destination IP Address field.

When an IP router receives an IP datagram with the Loose Source Route option, it compares the Option Length and Next Slot Pointer fields. If the Next Slot Pointer field's value is less than the Option Length field's value, the router does the following:

  1. Adds 4 to the Next Slot Pointer field's value.
  2. Replaces the IP header's destination IP address with the IP address that is recorded in the next slot (based on the Next Slot Pointer field's new value).
  3. Records the IP address of the forwarding interface in the previous slot.

If the Next Slot Pointer field's value is greater than the Option Length field's value, the IP datagram has reached its final destination.

Because the size of the Loose Source Route option is not a multiple of 4 bytes, either an End Of Options option (if there are no more options) or a No Operation option (if there are more options) must be added to ensure that the IP header is an integral multiple of 4 bytes.

Setting the Loose Source Route Option with Ping

The Windows Server 2003 family Ping utility with the -j option can be used to add the Loose Source Route option. Additionally, it is used to set the IP addresses of successive routers and the final destination in ICMP Echo messages. The syntax is:

    ping -j IP_address_of_first_hop IP_address_of_second_hop ...
    destination_IP_address

For example, to ping 10.0.0.1 through neighboring router interfaces 192.168.1.1 and 192.168.2.1, use the following command:

    ping -j 192.168.1.1 192.168.2.1 10.0.0.1

Network Monitor Capture 05-05 (in the \Captures folder on the companion CD-ROM) provides an example of Ping utility traffic and the use of the Loose Source Route option.

The ability of an IP router running a member of the Windows Server 2003 family to forward source-routed IP packets is controlled by the following registry setting:

DisableIPSourceRouting

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value type: REG_DWORD

Valid range: 0 - 2

Default: 1

Present by default: No

Use the DisableIPSourceRouting registry setting to forward source-routed packets (when set to 0), to not forward source-routed packets (when set to 1), or to drop all incoming source-routed packets (when set to 2). By default, DisableIPSourceRouting is configured not to forward source-routed packets.

IP Router Alert

The IP Router Alert option is used to indicate to IP routers that additional processing of the IP datagram is required even when the IP datagram is not addressed to the router. The IP Router Alert option is used for RSVP and IGMP version 2. For example, when a router receives an IP datagram with the IP Router Alert option, it looks at the IP Protocol field to see if the IP payload requires additional processing before making a forwarding decision. RFC 2113 describes the IP Router Alert option.

The IP Router Alert option contains the following fields:

  • Option Code Set to 148 (Copy Bit=1, Option Class=0, Option Number=20).
  • Option Length Set to the fixed length of 4.
  • Value A 2-byte field set to 0. All other values are reserved. The value of 0 indicates that the router must examine the packet.

Internet Timestamp

The Internet Timestamp option is used to record the time that an IP datagram arrived at each IP router in the path between the source and destination host. The Internet Timestamp option is similar to the Record Route option in that the sending node creates blank entries in the IP header that routers fill out as the packet travels through the IP internetwork. Each entry consists of the router's IP address and a 32-bit integer timestamp that indicates the number of milliseconds since midnight, Universal Time. If Universal Time is not being used, the high-order bit of the timestamp field is set to 1.

To use Internet timestamps, Internet timestamping must be enabled on all the routers in the path between the source and destination hosts. It is common for routers to either not support Internet timestamping or have it disabled.

The Internet Timestamp option contains the following fields:

  • Option Code Set to 68 (Copy Bit=0, Option Class=2, Option Number=4).
  • Option Length Set by the sending host to the number of octets in the Internet Timestamp option.
  • Next Slot Pointer Set to the octet offset (starting at 1) within the Internet Timestamp option of the next slot for the recording of the IP address and timestamp. The Next Slot Pointer field's minimum value is 5.
  • Overflow Set by routers to indicate the number of routers that were unable to record their IP address and timestamp.
  • Flags Set by the sending host to indicate the format of the IP Address/Timestamp slots. When Flags is set to 0, the IP address is omitted. This allows up to nine timestamps to be recorded. When Flags is set to 1, the IP address is recorded, allowing up to four IP address/timestamp pairs to be recorded. The Internet Timestamp option format shown assumes Flags is set to 1. When Flags is set to 3, the sending node specifies the IP addresses of successive routers: A timestamp is recorded only if the IP address in the slot matches the router's IP address.
  • First IP Address/First Timestamp Set by routers to record the IP address and timestamp of the routers encountered (when Flags is set to 1) or specified (when Flags is set to 3).

When a sending host sends an IP datagram with the Internet Timestamp option, the sending host does the following:

  1. Sets the Next Slot Pointer field's value to 5.
  2. For a specified route (when Flags is set to 3), places the series of IP addresses in the Internet Timestamp option.

When an IP router receives an IP datagram with the Internet Timestamp option, it compares the Option Length and Next Slot Pointer fields. If the Next Slot Pointer field's value is less than the Option Length field's value, it does the following:

  • If Flags is set to 3, the router replaces the IP header's destination IP address with the IP address that is recorded in the next slot (based on the Next Slot Pointer field).
  • If Flags is set to 1 or 3, the router records the IP address of the interface on which the IP datagram was received in the same slot.
  • If Flags is set to 0, the router records the timestamp and adds 4 to the Next Slot Pointer field. If Flags is set to 1, the router records the timestamp after the IP address and adds 8 to the Next Slot Pointer field. If Flags is set to 3, the router replaces the IP address and adds 4 to the Next Slot Pointer field.

If the Next Slot Pointer field's value is greater than the Option Length field's value, the router increments the Overflow field. If the Overflow field is 15 before incrementing, an ICMP Parameter Problem is sent back to the source host.

Setting the Internet Timestamp Option with Ping

The Windows Server 2003 family Ping utility and the -s option can be used to send ICMP Echo messages with the Internet timestamp. The syntax is the following:

ping -s slots destination

For example, to ping the IP address of 10.9.1.1 using Internet timestamps with three slots, use the following command:

ping -s 3 10.9.1.1

Network Monitor Capture 05-06 (in the \Captures folder on the companion CD-ROM) provides an example of Ping utility traffic and the use of the Internet Timestamp option.


Summary

IP provides the internetworking building block for all other Internet Layer and higher protocols in the TCP/IP suite. IP provides a best effort, unreliable, connectionless datagram delivery service between networks of an IP internetwork. The IP header provides addressing, type of delivery, maximum link count, fragmentation, and checksum services. IP fragmentation provides a way for IP datagrams to travel over links with a lower IP MTU than the original IP datagram. The basic services of the IP header are extended through IP options, the most common of which provide source routing, path recording, router alert, and timestamping functions.


Internet Protocol (IP) Addressing

Chapter 6
Internet Protocol (IP) Addressing

To successfully administer and troubleshoot IP internetworks, it is important to understand all aspects of IP addressing. One of the most important aspects of TCP/IP network administration is the assignment of unique and proper IP addresses to all the nodes of an IP internetwork. Although the concept of IP address assignment is simple, the actual mechanics of efficient IP address allocation using subnetting techniques are somewhat complicated. Additionally, it is important to understand the role of IP broadcast and multicast traffic and how these addresses map to Network Interface Layer addresses such as Ethernet and Token Ring media access control (MAC) addresses.


Types of IP Addresses

An IP address is a 32-bit logical address that can be one of the following types:

  • Unicast A unicast IP address is assigned to a single network interface attached to an IP internetwork. Unicast IP addresses are used in one-to-one communications.
  • Broadcast A broadcast IP address is designed to be processed by every IP node on the same network segment. Broadcast IP addresses are used in one-to-everyone communications.
  • Multicast An IP multicast address is an address on which one or multiple nodes can be listening on the same or different network segments. IP multicast addresses are used in one-to-many communications.


Expressing IP Addresses

The IP address is a 32-bit value that computers are adept at manipulating. Humans, however, do not think in binary mode, 32 bits at a time. Because most humans are trained in the use of decimal (base 10 numbering system) rather than binary (base 2 numbering system), it is common to express IP addresses in a decimal form.

The 32-bit IP address is divided from the high-order bit to the low-order bit into four 8-bit quantities called octets. IP addresses are normally written as four separate decimal octets delimited by a period (a dot). This is known as dotted decimal notation.

For example, the IP address 00001010000000011111000101000011 is subdivided into four octets:

00001010 00000001 11110001 01000011

Each octet is converted to a base 10 number and separated from the others by periods:

10.1.241.67

A generalized IP address is indicated with w.x.y.z, as Figure 6-1 shows.

Figure 6-1. The generalized IP address consisting of 32 bits expressed in dotted decimal notation.

Converting from Binary to Decimal

To convert a binary number to its decimal equivalent, add the numbers represented by the bit positions that are set to 1. Figure 6-2 shows an 8-bit number and the decimal value of each position.

Figure 6-2. An 8-bit number showing bit positions and their decimal equivalents.

For example, the 8-bit binary number 01000011 is 67 (64 + 2 + 1). The maximum number that can be expressed with an 8-bit number (11111111) is 255 (128 + 64 + 32 + 16 + 8 + 4 + 2 + 1).

Converting from Decimal to Binary

To convert from decimal to binary, analyze the decimal number to see if it contains the quantities represented by the bit positions from the high-order bit to the low-order bit. Starting from the high-order bit quantity (128), if each quantity is present, the bit in that bit position is set to 1. For example, the decimal number 211 contains 128, 64, 16, 2, and 1. Therefore, 211 is 11010011 in binary notation.

IP Addresses in the IP Header

IP addresses are used in the IP header's Source Address and Destination Address fields.

  • The IP header's Source Address field is always either a unicast address or the special address 0.0.0.0. The unspecified IP address, 0.0.0.0, is used only when the IP node is not configured with an IP address and the node is attempting to obtain an address through a configuration protocol such as Dynamic Host Configuration Protocol (DHCP).
  • The IP header's Destination Address field is a unicast address, multicast address, or broadcast address.


Unicast IP Addresses

Each network interface on which TCP/IP is active must be identified by a unique, logical, unicast IP address. The unicast IP address is a logical address because it is an Internet Layer address that has no direct relation to the address being used at the Network Interface Layer. For example, the unicast IP address assigned to a host on an Ethernet network has no relation to the 48-bit MAC address used by the Ethernet network adapter.

The unicast IP address is an internetwork address for IP nodes that contains a network ID and a host ID.

  • The network ID, or network address, identifies the nodes that are located on the same logical network. In most cases, a logical network is the same as a physical network segment with boundaries that are defined by IP routers. In some cases, multiple logical networks exist on the same physical network using a practice called multinetting. All nodes on the same logical network share the same network ID. If all nodes on the same logical network are not configured with the same network ID, routing or delivery problems occur. The network ID must be unique to the internetwork.
  • The host ID, or host address, identifies a node within a network. A node is a router or host (a nonrouter interface such as a workstation, server, or other TCP/IP-based system). The host ID must be unique within each network segment.
The term network ID applies to class-based network IDs, subnetted network IDs, and classless network IDs.

Figure 6-3 is an example of a unicast IP address and its network ID and host ID portions.

Figure 6-3. The structure of an example IP address showing the network ID and host ID.

A History Lesson: IP Address Classes

This section is called "A History Lesson" because modern networks are not based on the Internet address classes. Because of the Internet's recent rapid expansion, the Internet authorities saw clearly that the original class-based structure did not scale well to the size of a global internetwork. For example, if the Internet authorities were still handing out class-based addresses, there would be hundreds of thousands of routes in the routing tables of Internet backbone routers. To prevent this scaling problem, addressing on the modern Internet is classless. However, the understanding of Internet address classes is an important element in understanding IP addressing.

RFC 791 defined the unicast IP address in terms of address classes to create well-defined networks of various sizes. The design goal was to create the following:

  • A small number of large networks (networks with a large amount of nodes)
  • A moderate number of moderate-sized networks
  • A large number of small networks

The result was the creation of address classes, subdivisions of the 32-bit IP address space defined by setting high-order bits and dividing the remaining bits into network ID and host ID.

Class A

Class A addresses are designed for networks with a large number of hosts. The high-order bit is set to 0. The first 8 bits (the first octet) are defined as the network ID; the last 24 bits (the last three octets) are defined as the host ID. Figure 6-4 illustrates the class A address.

Figure 6-4. The class A address showing the network ID and the host ID.

Class B

Class B addresses are designed for moderate-sized networks with a moderate number of hosts. The two high-order bits are set to 10. The first 16 bits (the first two octets) are defined as the network ID; the last 16 bits (the last two octets) are defined as the host ID. Figure 6-5 illustrates the class B address.

Figure 6-5. The class B address showing the network ID and the host ID.

Class C

Class C addresses are designed for small networks with a small number of hosts. The three high-order bits are set to 110. The first 24 bits (the first three octets) are defined as the network ID; the last 8 bits (the last three octets) are defined as the host ID. Figure 6-6 illustrates the class C address.

Figure 6-6. The class C address showing the network ID and the host ID.

Additional Address Classes

Class D and E addresses are defined, in addition to unicast address classes A, B, and C.

Class D

Class D addresses are for IP multicast addresses. The four high-order bits are set to binary 1110. The next 28 bits are used for individual IP multicast addresses. For more information on IP multicast addresses, see the section entitled "IP Multicast Addresses," later in this chapter. The Microsoft Windows Server 2003 family supports class D addresses for IP multicast traffic.

Class E

Class E addresses are experimental addresses reserved for future use. The five high-order bits in a class E address are set to 11110. The Windows Server 2003 family does not support the use of class E addresses.

Rules for Enumerating Network IDs

When enumerating IP network IDs, the following rules apply:

  • The network ID cannot begin with 127 as the first octet. All 127.x.y.z addresses are reserved as loopback addresses.
  • All the bits in the network ID cannot be set to 1. Network IDs set to all 1s are reserved for broadcast addresses.
  • All the bits in the network ID cannot be set to 0. Network IDs set to all 0s are reserved for indicating a host on the local network.
  • The network ID must be unique to the IP internetwork.

Table 6-1 lists the ranges of network IDs based on the IP address classes. Network IDs are expressed by setting all host bits to 0 and expressing the result in dotted decimal notation.

Table 6-1. Address Class Ranges of Network IDs
Address Class | First Network ID | Last Network ID | Number of Networks
Class A | 1.0.0.0 | 126.0.0.0 | 126
Class B | 128.0.0.0 | 191.255.0.0 | 16,384
Class C | 192.0.0.0 | 223.255.255.0 | 2,097,152
IP network IDs, even though expressed in dotted decimal notation, are not IP addresses assigned to network interfaces. The IP network ID is the network address that is common for all network interfaces attached to the same logical network.

Rules for Enumerating Host IDs

When enumerating IP host IDs, the following rules apply:

  • All bits in the host ID cannot be set to 1. Host IDs set to all 1s are reserved for broadcast addresses.
  • All the bits in the host ID cannot be set to 0. Host IDs set to all 0s are reserved for the expression of IP network IDs.
  • The host ID must be unique to the network.

Table 6-2 lists the ranges of host IDs based on the IP address classes.

Table 6-2. Address Class Ranges of Host IDs
Address Class | First Host ID | Last Host ID | Number of Hosts
Class A | w.0.0.1 | w.255.255.254 | 16,777,214
Class B | w.x.0.1 | w.x.255.254 | 65,534
Class C | w.x.y.1 | w.x.y.254 | 254

Subnets and the Subnet Mask

Subnetting is designed to make more efficient use of a fixed address space, namely, an IP network ID. The network bits are fixed and the host bits are variable. Originally, the host bits were designed to indicate host IDs within an IP network ID. With subnetting, host ID bits can be used to express a combination of a subnetwork ID and a subnetwork host ID, thereby better utilizing the host bits.

Consider a class B network that has 65,534 possible hosts. A network segment of 65,534 hosts is technically possible but impractical because of the accumulation of broadcast traffic. All nodes on the same physical network segment belong to the same broadcast domain and share the same broadcast traffic. Because making all 65,534 hosts share the same broadcast traffic is not a practical configuration, most of the host IDs are not usable.

To create smaller broadcast domains and make better use of the host bits, RFC 950 defines a method of subdividing a network ID into subnetworks—subsets of the original class-based network—by using bits in the host ID portion of the original IP network ID. Each subnetwork, or subnet, is assigned a new subnetted network ID. Hosts on subnets are assigned host IDs from the remaining host bits in the subnetted network ID.

Although RFC 950 discusses subnetting in terms of class-based network IDs, subnetting is a general technique that can be used on classless network IDs or used recursively on subnetted network IDs. This is described in the section entitled "Variable-Length Subnetting," later in this chapter.

The proper subnetting of a network ID is transparent to the rest of the IP internetwork. For example, consider the class B network ID of 131.107.0.0 (shown in Figure 6-7), which is connected to the Internet. The class-based network ID was obtained from the InterNIC and is a fixed address space. Because this class B network ID represents an impractical broadcast domain, it is subnetted. However, in subnetting 131.107.0.0, we should not require any reconfiguration of the Internet routers.

Figure 6-7. The class B network 131.107.0.0 before subnetting.

From an analysis of broadcast traffic, it is determined that there should be no more than 250 nodes on each broadcast domain. Therefore, network ID 131.107.0.0 is subnetted to look like a class C address by using the first 8 high-order host bits (the third octet represented by y) for the subnetted network ID. Note that before the subnetting, only the first two octets are considered the network ID. After the subnetting, the first three octets are considered the network ID. The new network IDs are 131.107.1.0, 131.107.2.0, and 131.107.3.0, as Figure 6-8 shows.

Figure 6-8. The class B network 131.107.0.0 after subnetting.

The IP router connected to the Internet has an interface on each of the subnets and is aware of the new subnetting scheme. The IP router forwards IP datagrams from the Internet to the host on the appropriate subnet. The Internet routers are completely unaware of the subnetting of 131.107.0.0. They still consider all IP addresses in the range of 131.107.0.0 through 131.107.255.255 to be reachable through the IP router's Internet interface.

The Subnet Mask

With subnetting, a host or router can no longer assume the network ID and host ID designations of the IP address classes. The node needs additional configuration to distinguish the network ID and host ID portions of an IP address, whether the network ID is class-based, classless, or a subnetted network ID.

RFC 950 defines the use of a bit mask to identify which bits in the IP address belong to the network ID and which belong to the host ID. This bit mask, called a subnet mask or address mask, is defined by the following:

  • If the bit position corresponds to a bit in the network ID, it is set to 1.
  • If the bit position corresponds to a bit in the host ID, it is set to 0.

Since the publication of RFC 950, TCP/IP nodes require a subnet mask to be configured for each IP address, even when class-based addressing is used. A default subnet mask corresponds to a class-based network ID. A custom subnet mask corresponds to either a classless network ID or a subnetted network ID. The subnet mask is the definitive piece of configuration information that allows the node to determine its own network ID.

Subnet Masks in Dotted Decimal Representation

Frequently, the subnet mask is expressed in dotted decimal notation. Although expressed in the same form as an IP address, the subnet mask is not an IP address. As an example of subnet masks in dotted decimal notation, default subnet masks are based on the IP address classes. Table 6-3 lists the default subnet masks for class A, B, and C network IDs in dotted decimal notation.

Table 6-3. Dotted Decimal Notation for Default Subnet Masks
Address Class | Bits for Subnet Mask | Subnet Mask
Class A | 11111111 00000000 00000000 00000000 | 255.0.0.0
Class B | 11111111 11111111 00000000 00000000 | 255.255.0.0
Class C | 11111111 11111111 11111111 00000000 | 255.255.255.0

A custom subnet mask is used whenever you perform nonclassful addressing. In our earlier example, the classful network ID 131.107.0.0 is subnetted by using the third octet for subnets. The subnetted network ID 131.107.1.0 no longer uses the default subnet mask 255.255.0.0. To express the third octet as part of the network ID, the custom subnet mask 255.255.255.0 is used.

The subnetted network ID and its corresponding subnet mask are expressed in dotted decimal notation as 131.107.1.0, 255.255.255.0.

Network Prefix Length Representation of Subnet Masks

Although it is technically possible to subnet IP network IDs by choosing host bits in a noncontiguous fashion, it is impractical and mathematically challenging to enumerate the subnetted network IDs and the host IDs per subnet. For this reason, you must subnet by choosing host bits in a contiguous fashion from the high-order host bit.

Because the network ID bits are always contiguous starting from the highest order bit, an easier and more compact way of expressing the subnet mask is to indicate the number of network ID bits using network prefix notation, or Classless Inter-Domain Routing (CIDR) notation. Network prefix notation views the IP address in terms of the prefix (the network ID) and the suffix (the host ID). Network prefix notation is:

/# of bits in the network ID

Network prefix notation is commonly used with TCP/IP implementations other than the Windows Server 2003 family, and it is an important notation to understand looking forward to IP version 6 (IPv6).

Table 6-4 lists the equivalent subnet mask in network prefix notation for the IP address classes.

Table 6-4. Network Prefix Notation for Default Subnet Masks
Address Class | Bits for Subnet Mask | Network Prefix
Class A | 11111111 00000000 00000000 00000000 | /8
Class B | 11111111 11111111 00000000 00000000 | /16
Class C | 11111111 11111111 11111111 00000000 | /24

In our earlier example, the classful network ID 131.107.0.0, with the subnet mask of 255.255.0.0, is expressed in network prefix notation as 131.107.0.0/16. If 131.107.0.0 were subnetted by using the third octet to express subnets, a total of 24 contiguous bits would be used for the subnetted network ID. The subnetted network ID 131.107.1.0 and its corresponding subnet mask are expressed in network prefix notation as 131.107.1.0/24.

Expressing Network IDs

The fixed network ID bits and the subnet mask define the network ID. Therefore, network IDs must always be expressed by the combination of the network ID and a subnet mask. Expressing a network ID without its subnet mask is ambiguous. For example, for the network ID 10.16.0.0, which bits are used for the network ID? The first 16? The first 24? The first 12?

The following are examples of properly expressed network IDs:

  • 192.168.45.0, 255.255.255.0
  • 10.99.0.0/16

All hosts on the same logical network must be using the same network ID bits and the same subnet mask. For example, 131.107.0.0/16 is not the same as 131.107.0.0/24. For the network ID 131.107.0.0/16, the usable IP addresses range from 131.107.0.1 through 131.107.255.254. For the network ID 131.107.0.0/24, the usable IP addresses range from 131.107.0.1 through 131.107.0.254. Clearly, 131.107.0.0/16 and 131.107.0.0/24 do not represent the same group of hosts.

Determining the Network ID

In earlier examples, classful network IDs and subnetted network IDs all fell along octet boundaries where it was easy to determine the network ID and host ID portion of the IP address. However, real-world subnetting is not always done along octet boundaries. For example, some network administrators might determine that, for their situation, they need only three host bits for subnetting.

Because subnetting can occur along nonoctet boundaries, there must be a method of determining the network ID from an IP address with an arbitrary subnet mask. IP uses a method called a bit-wise logical AND to extract the network ID.

Recall how the subnet mask is defined: 1 is used to indicate a network ID bit and 0 is used to indicate a host ID bit. In a logical AND comparison, the result is 1 when the value of the two bits being compared is 1. Otherwise, the result is 0. This comparison is done for all 32 bits of the IP address and subnet mask. The result of the bit-wise logical AND of the IP address and the subnet mask is the network ID.

For example, what is the network ID of the IP node 131.107.164.26 with a subnet mask of 255.255.240.0? To obtain the result in binary notation, convert both the IP address and subnet mask to binary. Then perform the logical AND comparison for each bit.

IP address | 10000011 01101011 10100100 00011010
Subnet mask | 11111111 11111111 11110000 00000000
Network ID | 10000011 01101011 10100000 00000000

The result of the bit-wise logical AND of the 32 bits of the IP address and the subnet mask is the network ID 131.107.160.0 with the subnet mask of 255.255.240.0.

Notice the following:

  • The bits in the network ID portion of the IP address are copied directly to the result. A value of 1 in the network ID portion of the IP address becomes a 1 in the result. A value of 0 in the network ID portion of the IP address becomes a 0 in the result.
  • All bits in the host ID portion of the IP address are set to 0. Because the subnet mask uses a 0 for host ID bit positions, the logical AND comparison always yields a 0.

Therefore, because the bits in the network ID are copied and the bits in the host ID are set to 0, the result must be the network ID.

How to Subnet

The act of subnetting a network ID is a relatively complex procedure; although there are numerous subnet calculators available, the ability to subnet is a vital skill for any TCP/IP network administrator.

Subnetting is done in two basic steps:

  1. Based on your design requirements, decide how many host bits you need for the proper balance between number of subnets and number of hosts per subnet.
  2. Based on the number of host bits chosen, enumerate the subnetted network IDs, including the ranges of usable IP addresses for each subnetted network ID. The actual mechanics of defining the subnetted network IDs can be done in binary or decimal notation.

There are two methods for the second step of subnetting, the enumeration of the subnetted network IDs:

  • The binary method, in which the individual bits of the subnetted network IDs are manipulated and converted to dotted decimal notation, can be used to subnet. However, this method does not scale well to large numbers of subnets. It is described here primarily to illustrate the subnetting process in its most fundamental form.
  • The decimal method, in which subnetted network IDs are derived from calculations on decimal numbers, scales well to large numbers of subnets and lends itself well to spreadsheets and programming code.

Step 1: Determining the Number of Host Bits

To determine the number of host bits required for subnetting, perform an analysis of your internetwork. You should determine the following:

  • The number of subnets needed both now and in the future Be sure to plan for expansion. Subnetting an existing network requires reassigning IP addresses to IP interfaces. Although DHCP can ease this burden, routers and other fixed-address types of hosts might need to be manually reconfigured. Subnetting is not something you want to do often.
  • The maximum number of hosts needed on each subnet This number depends on how many hosts you want sharing the same broadcast traffic. In most cases, when choosing between more subnets and more hosts per subnet, the practical choice is to choose more subnets.

There is an inverse relationship between the number of subnets and the number of hosts per subnet that can be supported by a given subnetting scheme. As Figure 6-9 illustrates, when you choose more host bits, the number of subnets goes up, but the number of hosts per subnet goes down by approximately a factor of 2.

Figure 6-9. The relationship between the number of subnets and hosts per subnet when subnetting the class B network ID 131.107.0.0.

If we choose one host bit when subnetting the class B network ID 131.107.0.0, two subnets can be expressed, with 32,766 hosts per subnet. If we choose eight host bits, 256 subnets can be expressed with 254 hosts per subnet.

Determine how many subnets you need now, and plan for growth by estimating how many you will need in the next five years. Each physical network segment is a subnet. Point-to-point wide area network (WAN) connections such as leased lines might need subnetted network IDs, unless your routers support unnumbered connections. Non-broadcast multiple access (NBMA) WAN technologies such as frame relay need subnetted network IDs. Use additional host bits if the remaining host bits can express more hosts per subnet than you will need.

Subnetting always starts with a fixed address space in the form of a network ID. The network ID to be subnetted can be a classful network ID, a classless network ID (as allocated using CIDR), or a previously subnetted classful or classless network ID. The fixed address space contains a sequence of bits that are fixed (the network ID bits) and a sequence of bits that are variable (the host ID bits).

Based on your analysis of the desired number of subnets and number of hosts per subnet, a specific number of high-order host bits are converted from host bits into subnet bits. The combination of the original network ID bits and the converted host bits becomes the new subnetted network ID.

As you determine how many host bits you need, you determine the new subnet mask for your subnetted network IDs.

Tables 6-5, 6-6, and 6-7 list the subnetting of classful network IDs according to the requirement of a specific number of subnets. These tables can be useful when determining a subnetting scheme for a class-based network ID based on a required number of subnets and a desired number of hosts per subnet.

Table 6-5. Subnetting of a Class A Network ID
Required Number of Subnets | Number of Host Bits | Subnet Mask | Number of Hosts per Subnet
1-2 | 1 | 255.128.0.0 or /9 | 8,388,606
3-4 | 2 | 255.192.0.0 or /10 | 4,194,302
5-8 | 3 | 255.224.0.0 or /11 | 2,097,150
9-16 | 4 | 255.240.0.0 or /12 | 1,048,574
17-32 | 5 | 255.248.0.0 or /13 | 524,286
33-64 | 6 | 255.252.0.0 or /14 | 262,142
65-128 | 7 | 255.254.0.0 or /15 | 131,070
129-256 | 8 | 255.255.0.0 or /16 | 65,534
257-512 | 9 | 255.255.128.0 or /17 | 32,766
513-1024 | 10 | 255.255.192.0 or /18 | 16,382
1025-2048 | 11 | 255.255.224.0 or /19 | 8190
2049-4096 | 12 | 255.255.240.0 or /20 | 4094
4097-8192 | 13 | 255.255.248.0 or /21 | 2046
8193-16,384 | 14 | 255.255.252.0 or /22 | 1022
16,385-32,768 | 15 | 255.255.254.0 or /23 | 510
32,769-65,536 | 16 | 255.255.255.0 or /24 | 254
65,537-131,072 | 17 | 255.255.255.128 or /25 | 126
131,073-262,144 | 18 | 255.255.255.192 or /26 | 62
262,145-524,288 | 19 | 255.255.255.224 or /27 | 30
524,289-1,048,576 | 20 | 255.255.255.240 or /28 | 14
1,048,577-2,097,152 | 21 | 255.255.255.248 or /29 | 6
2,097,153-4,194,304 | 22 | 255.255.255.252 or /30 | 2
Table 6-6. Subnetting of a Class B Network ID
Required Number of Subnets | Number of Host Bits | Subnet Mask | Number of Hosts per Subnet
1-2 | 1 | 255.255.128.0 or /17 | 32,766
3-4 | 2 | 255.255.192.0 or /18 | 16,382
5-8 | 3 | 255.255.224.0 or /19 | 8190
9-16 | 4 | 255.255.240.0 or /20 | 4094
17-32 | 5 | 255.255.248.0 or /21 | 2046
33-64 | 6 | 255.255.252.0 or /22 | 1022
65-128 | 7 | 255.255.254.0 or /23 | 510
129-256 | 8 | 255.255.255.0 or /24 | 254
257-512 | 9 | 255.255.255.128 or /25 | 126
513-1024 | 10 | 255.255.255.192 or /26 | 62
1025-2048 | 11 | 255.255.255.224 or /27 | 30
2049-4096 | 12 | 255.255.255.240 or /28 | 14
4097-8192 | 13 | 255.255.255.248 or /29 | 6
8193-16,384 | 14 | 255.255.255.252 or /30 | 2
Table 6-7. Subnetting of a Class C Network ID
Required Number of Subnets | Number of Host Bits | Subnet Mask | Number of Hosts per Subnet
1-2 | 1 | 255.255.255.128 or /25 | 126
3-4 | 2 | 255.255.255.192 or /26 | 62
5-8 | 3 | 255.255.255.224 or /27 | 30
9-16 | 4 | 255.255.255.240 or /28 | 14
17-32 | 5 | 255.255.255.248 or /29 | 6
33-64 | 6 | 255.255.255.252 or /30 | 2

Step 2: Defining the Subnetted Network IDs (Binary Method)

The technique presented here describes how to subnet an arbitrary network ID into subnets that yield both subnetted network IDs and their corresponding range of valid IP addresses using binary analysis. There are other techniques that might seem easier, but they are typically limited in scope. This technique works for any subnetting situation.

Step 2a: Enumerating the Subnetted Network IDs (Binary)

Create a three-column table with 2n rows where n is the number of host bits chosen for the subnetting. The first column is used for the subnet number, the second column is for the binary representation of the subnetted network ID, and the third column is for the dotted decimal representation of the subnetted network ID.

For the binary representation for each entry in the table, the original network ID bits are fixed at their original values. The host bits chosen for subnetting, hereafter known as the subnet bits, are allowed to vary over all of their possible values, and the remaining host bits are set to 0.

The table's first entry is the subnet, defined by setting all the subnet bits to 0 (also called the all-zeros subnet). The result is converted to dotted decimal notation. This subnetted network ID does not appear to be different from the original network ID; but remember that a network ID is a combination of the dotted decimal notation and a subnet mask. With the new subnet mask, the subnetted network ID is clearly different from the original network ID.

In the following entries, treat the subnet bits as though they were distinct binary numbers. Increment the value within the subnet bits and convert the result of the entire 32-bit subnetted network ID to dotted decimal notation.

As an example of this technique, subnet the class B network ID 131.107.0.0 by using three bits of the classful host ID. The new subnet mask for the subnetted network IDs is 255.255.224.0, or /19. Based on using three host bits, create a table with eight entries
(8 = 23). The first entry is the all-zeros subnet. The additional entries are increments of the binary number represented by the subnet bits (underlined). Table 6-8 lists the subnetted network IDs.

Table 6-8. A 3-Bit Subnetting of 131.107.0.0 (Binary)
Subnet | Binary Representation | Subnetted Network ID
1 | 10000011.01101011.00000000.00000000 | 131.107.0.0/19
2 | 10000011.01101011.00100000.00000000 | 131.107.32.0/19
3 | 10000011.01101011.01000000.00000000 | 131.107.64.0/19
4 | 10000011.01101011.01100000.00000000 | 131.107.96.0/19
5 | 10000011.01101011.10000000.00000000 | 131.107.128.0/19
6 | 10000011.01101011.10100000.00000000 | 131.107.160.0/19
7 | 10000011.01101011.11000000.00000000 | 131.107.192.0/19
8 | 10000011.01101011.11100000.00000000 | 131.107.224.0/19

Step 2b: Enumerating IP Address Ranges for Each Subnetted Network ID (Binary)

For each subnetted network ID, the range of valid IP addresses must be determined as follows:

  1. Create a three-column table with 2n entries where n is the number of host bits chosen for the subnetting. The first column is used for the subnet number, the second column is for the binary representation of the first and last IP address in the range, and the third column is for the dotted decimal representation of the first and last IP address in the range. Alternately, you can extend the table created for enumerating the subnetted network IDs by adding two columns.
  2. Express the first and last IP address in the range in binary notation. The first IP address is defined by setting the remaining host bits to 0, except for the last host bit. The last IP address is defined by setting the remaining host bits to 1, except for the last host bit.
  3. Convert the binary representation of the first and last IP address to dotted decimal notation.
  4. Repeat steps 2 and 3 until the table is complete.

To continue our example, Table 6-9 lists the enumeration of the range of valid IP addresses for the 3-bit subnetting of 131.107.0.0. The host bits are underlined.

Table 6-9. Enumeration of IP Addresses for the 3-Bit Subnetting of 131.107.0.0 (Binary)
Subnet | Binary Representation | Range of IP Addresses
1 | 10000011.01101011.00000000.00000001 - 10000011.01101011.00011111.11111110 | 131.107.0.1 - 131.107.31.254
2 | 10000011.01101011.00100000.00000001 - 10000011.01101011.00111111.11111110 | 131.107.32.1 - 131.107.63.254
3 | 10000011.01101011.01000000.00000001 - 10000011.01101011.01011111.11111110 | 131.107.64.1 - 131.107.95.254
4 | 10000011.01101011.01100000.00000001 - 10000011.01101011.01111111.11111110 | 131.107.96.1 - 131.107.127.254
5 | 10000011.01101011.10000000.00000001 - 10000011.01101011.10011111.11111110 | 131.107.128.1 - 131.107.159.254
6 | 10000011.01101011.10100000.00000001 - 10000011.01101011.10111111.11111110 | 131.107.160.1 - 131.107.191.254
7 | 10000011.01101011.11000000.00000001 - 10000011.01101011.11011111.11111110 | 131.107.192.1 - 131.107.223.254
8 | 10000011.01101011.11100000.00000001 - 10000011.01101011.11111111.11111110 | 131.107.224.1 - 131.107.255.254

Step 2: Defining the Subnetted Network IDs (Decimal Method)

The previous technique describes a subnetting technique using binary. Although this method works for any valid subnetting scheme, it does not scale well. For example, if you were performing a 10-bit subnetting, you would have 1024 entries in the table. Whereas programmers are adept at binary manipulation and can create programs to automate this process, nonprogrammers find it easier to work with decimal numbers. Therefore, the following technique treats the 32-bit network ID and IP address as a single decimal number to enumerate the subnetted network ID and its corresponding range of IP addresses. Either technique—binary or decimal—yields the same result.

Step 2a: Enumerating the Subnetted Network IDs (Decimal)

  1. Create a three-column table with 2n entries where n is the number of host bits chosen for the subnetting. The first column is used for the subnet number the second column is for the decimal representation of the subnetted network ID, and the third column is for the dotted decimal representation of the subnetted network ID.
  2. Convert the original network ID from dotted decimal notation (w.x.y.z) to N, its decimal representation:

    N = w x y z

  3. Compute I, the increment value, based on h, the number of host bits remaining:

    I = 2h

  4. For the first table entry, the all-zeros subnet, the decimal representation of the subnetted network ID is N, and the subnetted network ID is w.x.y.z, with its new subnet mask.
  5. For the decimal representation of the next table entry, add the increment I to the previous entry.
  6. Convert the decimal representation of the subnetted network ID to dotted decimal notation (W.X.Y.Z) using the following formulas (where s is the decimal representation of the subnetted network ID):

    W = int (s/16777216)

    X = int ((s mod 16777216)/65536)

    Y = int ((s mod 65536)/256)

    Z = s mod 256

    In the formulas, int ( ) denotes integer division and yields the integer multiple, and mod ( ) denotes the modulus operator and yields the remainder after division.

  7. Repeat steps 5 and 6 until the table is complete.

To compare the two techniques and verify that they will both yield the same result, let us perform a decimal 3-bit subnetting of 131.107.0.0.

Based on n = 3, we create a table with eight entries. The entry for Subnet 1 is the all-zeros subnet. N, the decimal representation of 131.107.0.0, is 2204827648 (131 X 16777216 + 107 X 65536). Because there are 13 remaining host bits, the increment value I is 213, or 8192. Entries for Subnets 2 through 8 are incremented by 8192.

Table 6-10 lists the subnetted network IDs of 131.107.0.0.

Table 6-10. A 3-Bit Subnetting of 131.107.0.0 (Decimal)
Subnet | Decimal Representation | Subnetted Network ID
1 | 2204827648 | 131.107.0.0/19
2 | 2204835840 | 131.107.32.0/19
3 | 2204844032 | 131.107.64.0/19
4 | 2204852224 | 131.107.96.0/19
5 | 2204860416 | 131.107.128.0/19
6 | 2204868608 | 131.107.160.0/19
7 | 2204876800 | 131.107.192.0/19
8 | 2204884992 | 131.107.224.0/19

Step 2b: Enumerating IP Address Ranges for Each Subnetted Network ID (Decimal)

For each subnetted network ID, the range of valid IP addresses must be determined as follows:

  1. Create a three-column table with 2n entries where n is the number of host bits chosen for the subnetting. The first column is used for the subnet number, the second column is for the decimal representation of the first and last IP address in the range, and the third column is for the dotted decimal representation of the first and last IP address in the range. Alternately, you can extend the table created for enumerating the subnetted network IDs by adding two columns.
  2. Compute the increment value J based on h, the number of host bits remaining:

    J = 2h - 2

  3. The decimal representation of the first IP address is N + 1, where N is the decimal representation of the subnetted network ID. The decimal representation of the last IP address is N + J.
  4. Convert the decimal representation of the first and last IP address to dotted decimal notation (W.X.Y.Z) using the following formulas (where s is the decimal representation of the first or last IP address):

    W = int (s/16777216)

    X = int ((s mod 16777216)/65536)

    Y = int ((s mod 65536)/256)

    Z = s mod 256

    In the formulas, int ( ) denotes integer division and yields the integer multiple, and mod ( ) denotes the modulus operator and yields the remainder after division.

  5. Repeat steps 3 and 4 until the table is complete.

To continue with our example, we enumerate the range of valid IP addresses for the 3-bit subnetting of 131.107.0.0. Compute the increment value J = 213 - 2 = 8190. Table 6-11 lists the ranges of IP addresses for the eight subnetted network IDs.

Table 6-11. Enumeration of IP Addresses for the 3-Bit Subnetting of 131.107.0.0 (Decimal)
Subnet | Decimal Representation | Range of IP Addresses
1 | 2204827649 - 2204835838 | 131.107.0.1 - 131.107.31.254
2 | 2204835841 - 2204844030 | 131.107.32.1 - 131.107.63.254
3 | 2204844033 - 2204852222 | 131.107.64.1 - 131.107.95.254
4 | 2204852225 - 2204860414 | 131.107.96.1 - 131.107.127.254
5 | 2204860417 - 2204868606 | 131.107.128.1 - 131.107.159.254
6 | 2204868609 - 2204876798 | 131.107.160.1 - 131.107.131.107
7 | 2204876801 - 2204884990 | 131.107.192.1 - 131.107.223.254
8 | 2204884993 - 2204893182 | 131.107.224.1 - 131.107.255.254

All-Zeros and All-Ones Subnets

In the previous discussion's examples, we used the subnet where all the host bits were set to 0 (the all-zeros subnet) and the subnet where all the host bits were set to 1 (the all-ones subnet). The use of these subnets is somewhat controversial.

Originally, RFC 950 forbade the use of these subnets as valid subnets because:

  • The all-zeros subnet caused problems for early routing protocols that did not use a subnet mask to distinguish a network ID. Therefore, 131.107.0.0/16 was the same network to the router as 131.107.0.0/19.
  • The subnet broadcast address for the all-ones subnet uses the same address as a special broadcast address, called the all-subnets-directed broadcast address. An IP datagram for the all-subnets-directed broadcast was designed to be forwarded by routers to all classful network ID subnets. For more information on the all-subnets-directed broadcast address, see the section entitled "IP Broadcast Addresses," later in this chapter.

The restriction on the use of the all-zeros and all-ones subnets is part of the legacy of classful networks. The result of this restriction is that substantial portions of a fixed address space are unusable and wasted. For example, when performing a 3-bit subnetting of 131.107.0.0 and excluding the all-zeros and all-ones subnets, only six subnets are available. The range of IP addresses 131.107.0.1 through 131.107.31.254 for the all-zeros subnet and 131.107.224.1 through 131.107.255.254 for the all-ones subnet are unusable.

RFC 1812 now allows the use of all-zeros and all-ones subnets for classless environments for the following reasons:

  • Classless environments use routing protocols that advertise the subnet mask with the network ID. Therefore, 131.107.0.0/16 is distinguishable from 131.107.0.0/19.
  • The all-subnets-directed broadcast has no meaning in a classless environment.

Even though RFC 1812 now allows the use of these special subnets, there is no guarantee that all of your routers and hosts support them. It is a common default configuration for routers not to support one or the other special subnet and they must be instructed to do so. Verify that your routers and hosts support the all-zeros and all-ones subnets before using them. Hosts and routers running a member of the Windows Server 2003 family support the use of the all-zeros and all-ones subnets without additional configuration.

Variable-Length Subnetting

The preceding discussion illustrates how a fixed network ID can be subdivided into equally sized subnets. The 3-bit subnetting of the classful network ID 131.107.0.0/16 produced eight equally sized subnets, each containing 8190 possible IP addresses. However, in the real world, network segments are not of equal sizes. Some network segments require more IP addresses than others. For example, a network segment containing hosts requires more IP addresses than a backbone network segment containing just a few routers. Point-to-point WAN connections require only two IP addresses.

If equally sized subnetting were done, it would have to be done based on the network segment that required the largest amount of hosts. All other network segments would have the same amount of IP addresses, some of which are unassigned or unusable.

To maximize the use of the fixed address space, subnetting is applied recursively to produce subnets of different sizes all derived from the same original network ID. This is known as variable-length subnetting. Differently sized subnets use different subnet masks, or variable-length subnet masks (VLSM).

Because all of the subnets are derived from the same network ID, if the subnets are contiguous, the routes for all the subnets can be summarized by advertising the original network ID. Contiguous subnets are subnets of the same network ID that are connected to each other.

When performing variable-length subnetting, care must be taken so that each subnet is unique, and with its subnet mask, can be distinguished from all other subnets of the original network ID. Variable-length subnetting requires a careful analysis of your network segments to determine how many of each sized network you require. Then, starting from your network ID, subnetting is performed as many times as needed to express as many subnets as desired with the proper sizes.

With variable-length subnetting, the subnetting technique is applied recursively: You subnet a previously subnetted network ID. When subnetting a previously subnetted network ID, the subnetted network ID bits are fixed and an appropriate number of remaining host bits is chosen for subnetting.

Example of Variable-Length Subnetting

To expand on our earlier example, let us continue subnetting the classful network ID of 131.107.0.0/16. After the 3-bit subnetting has been performed, the remaining addresses must be divided such that:

  • Half of the addresses are reserved for future use
  • Three subnets are allocated with up to 8190 IP addresses
  • 31 subnets are allocated with up to 254 IP addresses
  • 64 subnets are allocated with only 2 IP addresses

Recall that the 3-bit subnetting of 131.107.0.0/16 produced the eight subnets listed in Table 6-12.

Table 6-12. The Eight Subnets for the 3-Bit Subnetting of 131.107.0.0/16
Subnet | Subnetted Network ID
1 | 131.107.0.0/19
2 | 131.107.32.0/19
3 | 131.107.64.0/19
4 | 131.107.96.0/19
5 | 131.107.128.0/19
6 | 131.107.160.0/19
7 | 131.107.192.0/19
8 | 131.107.224.0/19

Reserve Half of the IP Addresses for Future Use

To reserve half of the addresses for future use, set aside the first four subnets (131.107.0.0/19, 131.107.32.0/19, 131.107.64.0/19, 131.107.96.0/19).

Obtain Three Subnets with up to 8190 IP Addresses

To obtain three subnets with up to 8190 IP addresses per subnet, choose the next three subnets (131.107.128.0/19, 131.107.160.0/19, 131.107.192.0/19). Each subnet has 13 host bits, for a total of 8190 IP addresses per subnet.

Obtain 31 Subnets with up to 254 IP Addresses

To obtain 31 subnets, each with up to 254 IP addresses, perform a 5-bit subnetting of 131.107.224.0/19. The result is 32 subnets (131.107.224.0/24, 131.107.225.0/24, 131.107.226.0/24 . . . 131.107.253.0/24, 131.107.254.0/24, 131.107.255.0/24). To fulfill the requirement, choose the first 31 subnets (131.107.224.0/24 to 131.107.254.0/24).

Obtain 64 Subnets with only 2 IP Addresses

To obtain 64 subnets with only 2 usable IP addresses, perform a 6-bit subnetting of 131.107.255.0/24. The result is 64 subnets (131.107.255.4/30, 131.107.255.8/30, 131.107.255.12/30 . . . 131.107.255.244/30, 131.107.255.248/30, 131.107.255.252/30).

Figure 6-10 shows the variable-length subnetting of 131.107.0.0/16.

Figure 6-10. The variable-length subnetting of 131.107.0.0/16 into subnets of different sizes.

Variable-Length Subnetting and Routing

Variable-length subnetting requires routing protocols to advertise the subnet mask with the network ID. Routing Information Protocol (RIP) version 2, Open Shortest Path First (OSPF), and Border Gateway Protocol version 4 (BGP-v4) support variable-length subnetting environments, but RIP version 1 does not.

Supernetting and CIDR

As the Internet grew suddenly from a collection of educational institutions and government agencies to a business-oriented, pervasive, global internetwork, great stress was placed on the IP address space. Assigning classful network IDs to organizations meant a quick, wasteful depletion of the Internet address space.

For example, numerous organizations worldwide require more than 254 IP addresses. Therefore, a single class C network ID is insufficient. A single class B network ID, however, provides sufficient IP addresses and enough host bits to implement subnetting within the organization's internal network. Although this is good for the organization, it is bad for the Internet IP address space. Consider the smaller organization that needs only 4000 IP addresses. Assigning a class B network with 65,534 possible IP addresses means that 61,534 IP addresses are unassigned and wasted.

Now, instead of an entire class B network ID, the InterNIC assigns a range of class C network IDs. For example, InterNIC assigns 16 class C network IDs to an organization needing 4000 IP addresses. Each class C network ID allows for 254 IP addresses. Therefore, 16 class C network IDs allow for 4064 IP addresses.

This technique minimizes the wasting of Internet IP addresses, but it introduces a new problem. If a single class B network ID is assigned, that single class B network ID becomes a single route in the routing tables of the Internet backbone routers. If 16 class C network IDs are assigned, 16 class C network IDs become 16 routes in the routing tables of the Internet backbone routers.

Extending this example to its ultimate limits, there are more than 2 million class C network IDs. After assigning them all, it is possible to have more than 2 million routes in the routing tables of the Internet backbone routers. Even with today's technology, it is difficult to build an IP router that can have a routing table with millions of entries, and forward IP datagrams at megabit or gigabit per second speeds.

To prevent this scaling problem from overwhelming Internet routers, a route aggregation technique called CIDR is used to express a range of class C network IDs as a single route. This is the method of address allocation that the modern Internet uses. CIDR solves the scaling problem by minimizing the total number of routes that must be stored in the routing tables of Internet routers.

CIDR uses a supernetted subnet mask to express the range of class C network IDs. A supernetted subnet mask is less specific or contains fewer network ID bits than a classful subnet mask. In contrast, a subnetted subnet mask is more specific, or contains more network ID bits, than a classful subnet mask.

Views on CIDR Allocation

The CIDR method of address allocation can be viewed in two different ways:

  1. A range of class C network IDs
  2. An address space in which multiple classful networks are combined into a single classless network

The latter perspective is more appropriate for today's Internet and for looking forward to IPv6.

A Range of Class C Network IDs

Viewed as a range of class C network IDs, our requirement is based on the number of class C network segments needed in our organization. The following requirements are for a range of class C network IDs to be expressible as a single route using a network ID and a subnet mask:

  • The class C network IDs must be sequential.
  • The number of allocated class C network IDs must be expressed as a power of 2.

For example, Table 6-13 lists the range (or block) of eight class C network IDs, starting with network ID 223.1.184.0.

Table 6-13. A Block of Eight Class C Network IDs Starting with 223.1.184.0
Starting Network ID | 223.1.184.0 | 11011111 00000001 10111/u>000 00000000
Ending Network ID | 223.1.191.0 | 11011111 00000001 10111/u>111 00000000

Notice that the first 21 bits (underlined) of the range of class C network IDs are the same. The last 3 bits of the third octet vary over all possible values from 000 through 111. This range of class C network IDs can be aggregated with the network ID and subnet mask listed in Table 6-14.

Table 6-14. The Aggregated Block of Class C Network IDs
Network ID | 223.1.184.0
Subnet Mask (binary) | 11111111 11111111 11111000 00000000
Subnet Mask | 255.255.248.0
Network Prefix Length | /21

A block of class-based network IDs, as allocated in this example, is known as a CIDR block.

Table 6-15 lists the number of class C network IDs and the supernetted subnet mask for a required number of hosts.

Table 6-15. Supernetting and Class C Addresses
Required Hosts | Number of Class C Network IDs | Supernetted Subnet Mask
2-254 | 1 | 255.255.255.0 or /24
255-508 | 2 | 255.255.254.0 or /23
509-1016 | 4 | 255.255.252.0 or /22
1017-2032 | 8 | 255.255.248.0 or /21
2033-4064 | 16 | 255.255.240.0 or /20
4065-8128 | 32 | 255.255.224.0 or /19
8129-16,256 | 64 | 255.255.192.0 or /18
16,257-32,512 | 128 | 255.255.128.0 or /17
32,513-65,024 | 256 | 255.255.0.0 or /16

An Address Space

From the perspective of an address space, CIDR blocks are no longer viewed as a range of class C network IDs. Even though the CIDR block is obtained from the class-defined range of class C network IDs, it does not necessarily represent a range of class C network IDs. Viewing the CIDR block as a range of class C network IDs implies that we will assign each class C network ID within the block to each of our networks.

In reality, we typically want to assign network IDs of various sizes to the networks of our intranet in a variable-length subnetting scheme. Now our requirement is based on the number of IP addresses required, rather than the number of class C networks in our organization.

For example, to assign 4000 IP addresses to an organization, determine the number of bits required to express 4000 IP addresses. Using powers of 2, 12 bits are needed to express 4094 IP addresses. Therefore, 12 bits are used for the host ID portion, and 20 bits for the network ID portion. The subnet mask indicates 20 bits of network ID. For example, starting from an unassigned portion of the IP address space, the InterNIC allocates the 223.1.176.0 network with the subnet mask of 255.255.240.0 (or 223.1.176.0/20) address space to the organization.

The allocated address space allows the assignment of the range of IP addresses from 223.1.176.1 through 223.1.191.254. However, it is unlikely that the organization will use all 4094 IP addresses on the same network segment. Rather, the organization can use variable-length subnetting and the 12 host bits to create a series of subnets containing the suitable number of appropriately sized subnets.

With CIDR, IP network IDs lose their classful heritage and become address spaces where certain bits are fixed (the network ID bits), and certain bits are variable (the host ID bits). Using variable-length subnetting techniques, the organization's needs should determine how to best utilize the host bits.

CIDR and Routing

CIDR, like variable-length subnetting, requires routing protocols to advertise the subnet mask with the network ID. RIP version 2, OSPF, and BGP-v4 support CIDR environments, but RIP version 1 does not.

Public and Private Addresses

When deploying an IP addressing scheme in your organization, the main consideration is whether your intranet is connected to the Internet:

  • If your organization is not connected to the Internet, it is technically possible to choose any IP network IDs—classful or classless—without concern for using overlapping addresses being used on the Internet. However, it is highly recommended that you choose a private address range.
  • If your organization is connected to the Internet, it can be connected in one of two ways. If your organization uses a direct-routed connection using a router or firewall, you must use InterNIC-compliant addresses as allocated by the InterNIC or an Internet service provider (ISP). If your organization uses an indirect connection using a proxy server or a Network Address Translator (NAT), you must use addresses that do not overlap with addresses that do, or might, exist on the Internet.

Organizations connected to the Internet must choose between the use of public or private addresses.

Public Addresses

The InterNIC assigns public addresses that are within the public address space consisting of all of the possible unicast addresses on the Internet worldwide. Historically, the InterNIC assigned classful network IDs to organizations connecting to the Internet without regard to geographical location. Today, the InterNIC assigns CIDR blocks to ISPs based on geographical location; the ISPs then subdivide their assigned CIDR blocks to customers. Subdivision of the remaining class C address space based on geographical location was done to provide hierarchical routing and to minimize the number of routes in Internet backbone routers. Public addresses are guaranteed to be globally unique.

When an organization or an ISP is assigned a block of addresses in the public address space, a route exists in the Internet routers' routing tables so that the assigned public addresses are reachable through the ISP. Historically, a classful network ID was added to all of the Internet routers. Today, a route consisting of the range of assigned addresses is added to the routing tables of regional and ISP Internet routers.

One or more (network ID, mask) pairs summarize the range of public IP addresses assigned to an organization. These pairs become the routes in the ISP and Internet routers so that the IP addresses of the organization can be reached.

Illegal or Overlapping Addresses

Organizations that are not connected to the Internet either directly or indirectly are free to choose any addressing scheme without regard to whether the addresses have been assigned to another ISP or organization. However, if that organization later decides to connect to the Internet, a new addressing scheme might be required.

The addresses assigned when the organization was not connected to the Internet might include public addresses that have been assigned to other organizations or ISPs by the InterNIC. If that is the case, these addresses are duplicates that conflict with assigned addresses. This is known as illegal, or overlapping, addressing. Internet traffic from hosts using illegal addresses is forwarded to the routers of the organization that was originally assigned those addresses. Therefore, organizations using illegal addressing are unreachable on the Internet.

For example, an organization that is not connected to the Internet decides to use the address space 207.46.130.0/24 for its intranet. As long as the organization does not connect to the Internet, the use of 207.46.130.0/24 is not an issue. If the organization then connects to the Internet using a direct routed connection, the use of 207.46.130.0/24 is illegal and no responses from hosts on the 207.46.130.0/24 network segment are received.

In this configuration, when a host sends traffic to an Internet location, it sends the traffic with the source IP address within the address space of 207.46.130.0/24. When the Internet host sends a response, it sends the response to the destination IP address within the address space of 207.46.130.0/24. InterNIC assigned Microsoft Corporation the address space 207.46.130.0/24, and a route exists in Internet routers to forward traffic with the destination IP address in this range to Microsoft Corporation's routers. Therefore, the responses to traffic sent by the hosts on the illegal address space 207.46.130.0/24 are forwarded to Microsoft Corporation's routers, and not to the routers of the organization using the illegal addresses.

It is common practice among ISPs to discard IP packets sent from a customer site when the source IP address field is not set to a valid public address assigned to the customer. This is known as ingress filtering, which attempts to prevent the sending of traffic from hosts using illegal addresses and address spoofing (the sending of IP traffic from a source IP address that is not assigned to a host).

Private Addresses

As the Internet experienced exponential growth, the demand for public IP addresses increased commensurately. Because each node on an organization's intranet required a globally unique public IP address, organizations requested enough IP addresses from the InterNIC to assign unique IP addresses to all of the nodes within their organizations.

However, when an analysis of IP addressing within organizations was done, the Internet authorities noticed that most organizations actually needed very few public addresses. The only hosts that required public IP addresses were those that communicated directly with systems on the Internet, such as Web servers, File Transfer Protocol (FTP) servers, e-mail servers, proxy servers, and firewalls. Most of the hosts within an organization's intranet obtained access to Internet resources through Application Layer gateways such as proxy servers and e-mail servers.

For hosts within the organization's intranet that do not require direct access to the Internet, a legal IP address space must be used. For this purpose, Internet authorities created the private address space, a subset of the Internet IP address space that can be used without conflict within an organization, for hosts that do not require a direct connection to the Internet.

The private and public address spaces are separate and do not overlap. The InterNIC never assigns private addresses—IP addresses within the private address space—to an organization or ISP. This also means that private IP addresses are not reachable on the Internet.

Because private addresses are not reachable on the Internet, hosts on an intranet with private addressing cannot be directly connected to the Internet. Rather, they must be indirectly connected to the Internet using a NAT or an Application Layer gateway such as a proxy server.

A NAT is a router that translates between private addresses and public addresses for Internet traffic. The proxy server receives a request from a host on the intranet for Internet resources. The proxy server then sends the request to the Internet resource and the response traffic is forwarded back to the requesting host. When the proxy server sends the request to the Internet resource, it uses public addressing. Both proxy servers and NATs have private addresses on their intranet interface and public addresses on their Internet interface.

For more information on network address translation, see RFC 3022, which can be found in the \Rfc folder on the companion CD-ROM.

The following three address blocks define the private address space:

  • 10.0.0.0/8 The 10.0.0.0/8 private network is an address space with 24 host bits that can be used for any subnetting scheme within the private organization.
  • 172.16.0.0/12 The 172.16.0.0/12 private network is an address space with 20 host bits that can be used for any subnetting scheme within the private organization. From a classful perspective, the 172.16.0.0/12 private network ID is the range of 16 class B network IDs from 172.16.0.0/16 through 172.31.0.0/16.
  • 192.168.0.0/16 The 192.168.0.0/16 private network is an address space with 16 host bits that can be used for any subnetting scheme within the private organization. From a classful perspective, the 192.168.0.0/16 private network ID is the range of 256 class C network IDs from 192.168.0.0/24 through 192.168.255.0/24.
For more information on the public address space, see RFC 1918, which can be found in the \Rfc folder on the companion CD-ROM.

Automatic Private IP Addressing

When you configure a computer running a member of the Windows Server 2003 family to obtain its IP address automatically and a DHCP server does not respond to the DHCPREQUEST and DHCPDISCOVER messages, TCP/IP for the Windows Server 2003 family configures itself using the Automatic Private IP Addressing (APIPA) feature (provided TCP/IP is not configured to use an alternate static address configuration). Using APIPA, TCP/IP for the Windows Server 2003 family randomly picks an IP address in the address space of 169.254.0.0/16. This address space has been reserved by the Internet Assigned Numbers Authority (IANA) and is not reachable on the Internet.

After choosing an IP address, TCP/IP for the Windows Server 2003 family sends a gratuitous Address Resolution Protocol (ARP) to check for IP address uniqueness. After receiving no response to the gratuitous ARP, TCP/IP for the Windows Server 2003 family is configured for the randomly chosen IP address and the subnet mask of 255.255.0.0. If a response to the gratuitous ARP is received, TCP/IP for the Windows Server 2003 family randomly chooses a new address in the 169.254.0.0/16 address space. After APIPA configuration, TCP/IP for the Windows Server 2003 family continues to send DHCPDISCOVER messages every five minutes. If a DHCP server responds, TCP/IP for the Windows Server 2003 family abandons the APIPA configuration and the DHCP-allocated address takes effect. For more information on gratuitous ARP, see Chapter 3, "Address Resolution Protocol (ARP)."

APIPA was designed to simplify the configuration of a single subnet small office/home office (SOHO) network that is not connected to the Internet or any other IP internetwork. With APIPA, all the computers on a single-subnet SOHO network configure themselves and are able to communicate without manually configuring TCP/IP or setting up a DHCP server.

APIPA does not provide automatic configuration of a default gateway, the IP address of a Domain Name System (DNS) server, a DNS domain name, the IP address of a Windows Internet Name Service (WINS) server, or NetBIOS node type. A single-subnet SOHO network does not need a default gateway, and broadcast NetBIOS name queries resolve names for communication between computers.

TCP/IP for the Windows Server 2003 family APIPA behavior is controlled by the following registry settings:

IPAutoconfigurationEnabled

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\InterfaceGUID

Value type: REG_DWORD

Valid range: 0 - 1

Default: 1

Present by default: No

IPAutoconfigurationEnabled either enables (when set to 1) or disables (when set to 0) APIPA-based IP address configuration either globally or per interface. The default is enabled both globally and per interface, and the setting for an interface overrides the global setting.

IPAutoconfigurationSubnet

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\InterfaceGUID

Value type: REG_SZ (String)

Valid range: A valid IP network ID expressed in dotted decimal notation.

Default: 169.254.0.0

Present by default: No

IPAutoconfigurationSubnet specifies the IP network ID for the network prefix of APIPA-configured addresses. The default value is 169.254.0.0. IPAutoconfigurationSubnet can be specified globally or per interface, and the setting for an interface overrides the global setting.

IPAutoconfigurationMask

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\InterfaceGUID

Value type: REG_SZ (String)

Valid range: A valid subnet mask expressed in dotted decimal notation.

Default: 255.255.0.0

Present by default: No

IPAutoconfigurationMask specifies the subnet mask for the network prefix of APIPA-configured addresses. The default value is 255.255.0.0. IPAutoconfigurationMask can be specified globally or per interface and the setting for an interface overrides the global setting.

The network ID specified for the IPAutoconfigurationSubnet cannot be more specific than the subnet mask specified for the IPAutoconfigurationMask. In other words, the network ID cannot contain bits set to 1 when the corresponding bit in the mask is set to 0. An example of an incorrect network ID and subnet mask combination is the network ID 169.254.47.0 with the subnet mask of 255.255.0.0. The correct subnet mask for this network ID is 255.255.255.0.


IP Broadcast Addresses

IP broadcast addresses are used for single-packet one-to-everyone delivery. A sending host addresses the IP packet using a broadcast address and every node on the sending node's network segment receives and processes the packet. IP broadcast addresses can be used only as the destination IP address.

There are four different types of IP broadcast addresses. For each type, the broadcast IP packet is addressed at the Network Interface Layer using the network technology's broadcast address. For example, for Ethernet and Token Ring networks, all IP broadcasts are sent using the Ethernet and Token Ring broadcast address 0xFF-FF-FF-FF-FF-FF.

Network Broadcast

The IP network broadcast address is the address formed by setting all the host bits to 1 for a classful address. 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 hosts of a classful network, which listen for and process packets addressed to the network broadcast address. IP routers do not forward network broadcast packets.

Subnet Broadcast

The IP subnet broadcast address is the address formed by setting all the host bits to 1 for a nonclassful address. An example of a network broadcast address for the nonclassful network ID 131.107.26.0/24 is 131.107.26.255. Subnet broadcasts are used to send packets to all hosts of a subnetted, supernetted, or otherwise nonclassful network. All hosts of a nonclassful network listen for and process packets addressed to the subnet broadcast address. IP routers do not forward subnet broadcast packets.

For a classful network, there is no subnet broadcast address, only a network broadcast address. For a nonclassful network, there is no network broadcast address, only a subnet broadcast address.

All-Subnets-Directed Broadcast

The IP all-subnets-directed broadcast address is the address formed by setting all the original classful network ID host bits to 1 for a nonclassful network. A packet addressed to the all-subnets-directed broadcast is intended 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.

All hosts of a nonclassful network listen for and process packets addressed to the all-subnets-directed broadcast address. RFC 922 required IP routers to forward all-subnets-directed broadcast packets to all subnets of the original classful network ID implied in the address. However, this forwarding was not widely implemented.

With the advent of classless network IDs, the all-subnets-directed broadcast address is no longer relevant. According to RFC 1812, the use of the all-subnets-directed broadcast has been deprecated.

Notice how the all-subnets-directed address is the same as the subnet broadcast for the all-ones subnet. For example, the 8-bit subnetting of the class B network ID 157.54.0.0 produces the subnets {157.54.0.0/24, 157.54.1.0/24 . . . 157.54.254.0/24, 157.54.255.0/24}. For the last subnet, 157.54.255.0/24, the subnet broadcast is 157.54.255.255, which is the same as the all-subnets-directed broadcast address of 157.54.255.255. This address conflict is not an issue for routers that do not forward all-subnets-directed broadcast traffic.

Limited Broadcast

The limited broadcast address is the address formed by setting all 32 bits of the IP address to 1 (255.255.255.255). The limited broadcast address is used when an IP node must perform a one-to-everyone delivery on the local network but the network ID is unknown.

The limited broadcast address is typically used only by nodes 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 IP address lease.

All hosts, classful or nonclassful, listen for and process packets addressed to the limited broadcast address. Although it appears that the limited broadcast address is addressed to all nodes on all networks, it appears only on the local network and is never forwarded by routers. The limited broadcast packet is limited to the local network segment.

The following registry setting controls the address of the limited broadcast address:

UseZeroBroadcast

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters \InterfaceGUID

Value type: REG_DWORD

Valid range: 0 - 1

Default: 0

Present by default: Yes

UseZeroBroadcast determines whether the limited broadcast is 0.0.0.0 (when set to 1) or 255.255.255.255 (when set to 0). By default, UseZeroBroadcast is set to 0. Some implementations of TCP/IP, such as those derived from UNIX, use 0.0.0.0 as their limited broadcast address. On the same subnet, all nodes should be using the same limited broadcast address.


IP Multicast Addresses

IP multicast addresses are used for single-packet one-to-many delivery. A sending host addresses the IP packet using an IP multicast address; every node on the sending node's internetwork that is listening for the multicast traffic receives and processes the packet. Unlike broadcast packets, routers forward IP multicast packets and only the hosts listening for the IP multicast traffic are disturbed. IP multicast addresses can be used only as the destination IP address.

As RFC 1112 describes, the set of hosts listening for the traffic of a specific IP multicast address is called a host group. Host group members can be located anywhere on the IP internetwork. They also can join and leave the host group at any time. For routers to forward IP multicast traffic to host group members, the routers must be aware of where the members of a multicast group are located. For more information on how hosts and routers facilitate the forwarding of IP multicast traffic, see Chapter 9, "Internet Group Management Protocol (IGMP)."

Multicast IP addresses are in the class D range. Multicast IP addresses range from 224.0.0.0 through 239.255.255.255 (224.0.0.0/4). Multicast IP addresses in the range 224.0.0.0 through 224.0.0.255 (224.0.0.0/24) are reserved for local subnet traffic. Table 6-16 lists some of the reserved IP addresses in this range used by the Windows Server 2003 family. For a complete list, see http://www.iana.org/assignments/multicast-addresses .

Table 6-16. Reserved Local Subnet IP Multicast Addresses
Multicast IP Address | Purpose
224.0.0.1 | The all-hosts multicast address, designed to reach all hosts on a subnet
224.0.0.2 | The all-routers multicast address, designed to reach all routers on a subnet
224.0.0.5 | The AllSPFRouters address, designed to reach all OSPF routers on a subnet
224.0.0.6 | The AllDRRouters address, designed to reach all OSPF designated routers on a subnet
224.0.0.9 | The RIP version 2 multicast address, designed to reach all RIP version 2 routers on a subnet

Mapping IP Multicast Addresses to MAC Addresses

To fulfill the promise of IP multicast traffic—where a single IP datagram is processed only by the host group members—IP multicast traffic must be mapped to a corresponding MAC-level multicast address. The corresponding MAC-level multicast becomes an interesting address to the network interface card (NIC), and all traffic addressed to that interesting address with a valid frame check sequence is passed up through a hardware interrupt to the operating system.

Ethernet and Fiber Distributed Data Interface

To denote a MAC-level multicast address, Ethernet and Fiber Distributed Data Interface (FDDI) network adapters set the Individual/Group (I/G) bit, the low-order bit of the first byte of the destination MAC address, to 1. For IP multicast addressing, the range of multicast MAC addresses is 0x01-00-5E-00-00-00 to 0x01-00-5E-7F-FF-FF. The high-order 25 bits are set to 0000001 00000000 01011110 0. The low-order 23 bits are available for use by IP multicast addresses.

To map an IP multicast address to an Ethernet or FDDI MAC-level multicast address, the low-order 23 bits of the IP multicast address are copied to the low-order 23 bits in the Ethernet multicast address as Figure 6-11 shows.

Figure 6-11. The mapping of IP multicast addresses to Ethernet and FDDI MAC addresses.

In the high-order 9 bits of the IP multicast address, the first 4 bits are set to 1110; the next 5 bits are variable. These 5 bits do not map to the corresponding Ethernet and FDDI multicast address. Therefore, up to 32 different IP multicast addresses can map to the same Ethernet and FDDI MAC-level multicast address. IP multicast packets received that do not correspond to a multicast address registered by an application or another protocol are silently discarded.

A node registers interest in a specific multicast group by informing the NIC to listen for another interesting destination address for incoming frames. In the Windows Server 2003 family, this is done through the NDISRequest( ) function. For example, by default TCP/IP for the Windows Server 2003 family listens for all multicast traffic sent to the all-hosts multicast address 224.0.0.1. Therefore, TCP/IP informs the NIC through NDIS to pass up frames with the destination MAC address of 0x01-00-5E-00-00-01.

Token Ring

As RFC 1469 describes, Token Ring can support the same type of multicast IP-address-to-MAC mapping as Ethernet and FDDI. However, because of the hardware limitations of most Token Ring network adapters, typically all IP multicast addresses are mapped to the single Token Ring functional address of 0xC0-00-00-04-00-00.

TCP/IP for the Windows Server 2003 family multicast behavior for Token Ring is controlled by the following registry setting:

TrFunctionalMcastAddress

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value type: REG_DWORD

Valid range: 0 - 1

Default: 1

Present by default: No

TrFunctionalMcastAddress either enables (when set to 1) or disables (when set to 0) the use of the Token Ring functional address of 0xC0-00-00-04-00-00 for all IP multicast traffic sent on Token Ring adapters. If disabled, IP multicast traffic is sent using the MAC-level broadcast address 0xFF-FF-FF-FF-FF-FF. This setting is enabled by default.


Summary

IP addresses can be unicast, broadcast, or multicast. For unicast addresses, subnetting techniques allow a network ID to be allocated, in an efficient manner, to the subnets of an IP internetwork. Internet authorities have defined public addresses that are reachable on the Internet and private addresses that are designed for use on private intranets not directly connected to the Internet. IP broadcast addresses are used to send IP datagrams to all the nodes on a physical or logical subnet. IP multicast addresses are used to send IP datagrams to all members of a multicast host group.


Internet Protocol (IP) Routing

Chapter 7
Internet Protocol (IP) Routing

To troubleshoot TCP/IP connectivity problems, it is important to understand how packets are forwarded from a source to a destination node on an Internet Protocol (IP) internetwork. For data to be exchanged between any two nodes, each must be reachable from the other. For universal reachability, a forwarding path between any two nodes must exist in both directions. The forwarding paths are determined by the contents of local IP routing tables and the nature of the IP routing infrastructure.


Introduction to IP Routing

IP routing is the process of forwarding unicast IP traffic to its destination in an IP internetwork with an arbitrary topology. Specifically, IP routing is the process of forwarding packets from the sending host through a series of intermediate routers. To facilitate the forwarding process, the sending host and each router make a forwarding decision based on the contents of their local IP routing table. For hosts and routers running a member of the Microsoft Windows Server 2003 family, the IP routing table entries are created based on the TCP/IP configuration, static routing table entries, Internet Control Message Protocol (ICMP) Redirect, or routing protocols.

For discussion in this chapter, a node is a network device running the TCP/IP protocol, a host is a TCP/IP node that does not have routing capability, and a router (or gateway) is a TCP/IP node that does have routing capability. Both hosts and routers are considered nodes.

Direct and Indirect Deliveries

When forwarding an IP datagram, the sending host performs either a direct or indirect delivery to the destination. If the destination is directly reachable—on a directly attached network segment—the forwarding node performs a direct delivery by resolving the destination node's media access control (MAC) address and sending the frame to the destination. If the destination is not directly reachable—not on a directly attached network segment—the host uses its IP routing table to determine an intermediate router's next-hop IP address. The forwarding node performs an indirect delivery by resolving the intermediate router's MAC address and sending the frame to the intermediate router.

The IP routing process is a series of direct and indirect deliveries, as shown in Figure 7-1. For Host A and Host B, on the same network segment, Host A performs a direct delivery when sending packets to Host B. For Host A and Host C, on different network segments separated by a single IP router, Host A performs an indirect delivery to the router. The router then performs a direct delivery to Host C.

Figure 7-1. IP forwarding showing direct and indirect delivery.

For more details on the behavior of the Address Resolution Protocol (ARP) during direct and indirect deliveries, see Chapter 3, "Address Resolution Protocol (ARP)."


Types of Links

The IP forwarding process and IP routing table entries vary depending on the type of link over which the packet is being forwarded. The following are the three types of links:

  • Broadcast
  • Point-to-point
  • Nonbroadcast multiple access

Broadcast

The broadcast link type is characterized by its ability to have more than two nodes on the same network segment, and each frame sent is received at the Network Interface Layer by all of the network segment's nodes. Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI) are examples of broadcast links. In each case, one of the possible multiple nodes on the network segment must be distinguished using a Network Interface Layer address. For Ethernet, Token Ring, and FDDI, the Network Interface Layer address is the destination MAC address. ARP is used to resolve the destination MAC address for a given next-hop IP address.

The broadcast link type supports the ability to multicast to a group of hosts on the network segment or to broadcast to all hosts on the segment. Routing protocols such as Routing Information Protocol (RIP) or Open Shortest Path First (OSPF) use the ability to multicast to propagate routing information. RIP routers can use either subnet broadcasts or the 224.0.0.9 multicast address. OSPF routers use the multicast addresses of 224.0.0.5 and 224.0.0.6. Figure 7-2 shows Ethernet, an example of a broadcast link.

Figure 7-2. A broadcast link such as Ethernet where a single packet is received by multiple nodes.

To forward an IP datagram on a broadcast network, knowledge of the next-hop IP address is required.

Point-to-Point

The point-to-point link type is characterized by its ability to support only two IP nodes. Examples of point-to-point links are typical leased-line and circuit-switched wide area network (WAN) links such as analog phone lines, T-Carrier (including T1/E1 and T3/E3), and Integrated Services Digital Network (ISDN). For point-to-point links, there is only one possible node that receives the forwarded IP datagram. Therefore, ARP is not used to resolve a Network Interface Layer address and the next-hop IP address is irrelevant.

Routing protocols such as RIP and OSPF work over point-to-point links without modification. For broadcast RIP announcements, the two routers' IP addresses on the point-to-point link network segment must be from the same IP network ID. If the IP addresses of the two routers' interfaces on the point-to-point link are from different network IDs, the receiving router does not process broadcast RIP requests or announcements. If this is the case, use RIP version 2 and multicast announcements.

For OSPF, the router interfaces are configured for the OSPF point-to-point network type. In this configuration, OSPF routers always use the multicast address of 224.0.0.5. Figure 7-3 shows a leased-line connection between two routers using T1, an example of a point-to-point link.

Figure 7-3. A point-to-point link such as a T1 leased line contains a maximum of two nodes.

Non-Broadcast Multiple Access

The non-broadcast multiple access (NBMA) link type is characterized by its ability to support more than two IP nodes; however, this link type cannot multicast or broadcast. Examples of NBMA links are packet-switched WAN technologies such as X.25, frame relay, and Asynchronous Transfer Mode (ATM). In each of these technologies, a single WAN adapter can support multiple virtual circuits. However, with the exception of recent developments in frame relay, NBMA links have no capability to send a single packet that is copied to all the configured virtual circuits.

For X.25, frame relay, and ATM adapters operating in NBMA mode, the next-hop IP address is relevant. However, because there is no multicast or broadcast facility, ARP is not used. Inverse ARP can be used to discover the IP addresses of the routers on the other end of the virtual circuit. The next-hop IP address from the route in the routing table is mapped to the appropriate virtual circuit identifier using a table maintained by the adapter.

For RIP and OSPF operation over an NBMA network, instead of broadcasting or multicasting, RIP or OSPF neighbors are configured. Each neighbor is a unicast location to which RIP or OSPF traffic is sent. Figure 7-4 shows a frame relay spoke and hub configuration, an example of an NBMA link.

Figure 7-4. An NBMA link such as frame relay, where a single interface supports multiple virtual circuits without a broadcast facility.

For X.25, frame relay, and ATM adapters operating in multi- or subinterface mode, each virtual circuit is represented as a separate logical adapter. Each logical adapter is the equivalent of a point-to-point adapter. RIP and OSPF are configured the same way as a point-to-point link.


The IP Routing Table

The IP routing table is a database of routes present in memory on all IP nodes. Each entry, or route, in the routing table contains forwarding information for a range of destination IP addresses. The level of detail for destination IP addresses—the number of routes in the routing table—depends on whether the IP node is a host or a router. Typically, IP hosts have few entries and IP routers have many.

It is common on IP internetworks to configure IP hosts with a default gateway. This configuration creates a default route that effectively summarizes all destinations. For IP routers, it is common for the routing table to contain an entry for every reachable network on the IP internetwork, although route summarization and default routing are also commonly used.

In each case, the IP routing table's purpose is to yield two values for the destination IP address of each packet being forwarded:

  • The next-hop interface The next-hop interface is the representation of a physical or logical device over which the IP datagram is forwarded.
  • The next-hop IP address The next-hop IP address is the IP address of the node to which the IP datagram is forwarded. For direct deliveries, the next-hop IP address is the destination IP address of the IP datagram being forwarded. For indirect deliveries, the next-hop IP address is the IP address of a directly reachable intermediate router to which the IP datagram is being forwarded.

Structure

A route in the IP routing table contains enough information to identify the destination, identify the next-hop interface and IP address, and distinguish the best route to use when multiple routes to the destination are found.

Typical IP routing tables contain the following fields for each route:

  • Destination Used in conjunction with the Network Mask field, this field is a representation of the range of IP addresses that is reachable with this route. The Destination field can be an IP network ID (classful, subnet, supernet) or an IP address.
  • Network Mask The network mask is the bit mask that is used to determine the significant bits in the Destination field. A 1 bit in the Network Mask field identifies a bit that must match the Destination field for this route. A 0 bit in the Network Mask field indicates a bit that does not have to match the Destination field. The Network Mask field must consist of a series of contiguous 1 bits followed by a series of contiguous 0 bits. The Destination and the Network Mask fields define a range of IP addresses. An IP datagram with a destination IP address within the range matches the route.

    To determine whether the destination IP address of an IP datagram being forwarded matches a route, the destination IP address is bit-wise logically ANDed with the Network Mask. The result is compared with the value of the Destination field for the route. If they match, the route matches the destination IP address for the packet and the corresponding next-hop IP address is used.

    Due to the ANDing process used between the Network Mask field and the Destination field, the Destination field cannot be more specific than the Network Mask field. In binary terms, the Destination field cannot have bits set to 1 in bit positions where the Network Mask field has bits set to 0. Because the logical ANDing of a 1 and a 0 is always a 0, the ANDing of the Network Mask field with any IP address never results in a match to the Destination field. This is a useless route because it never matches any destination. Computers running a member of the Windows Server 2003 family do not allow such a route to be added to the IP routing table. To test whether a destination and network mask combination is invalid, perform a bit-wise logical AND of the destination and the network mask. If the result is not the destination, the combination is invalid.

  • Next-Hop IP Address Indicates the IP address to which the IP datagram is to be forwarded if it matches this route. The Next-Hop IP Address field's value is relevant for broadcast or NBMA links and irrelevant for point-to-point links. For routes of directly attached network segments, the Next-Hop IP Address field can be set to the IP address of that network segment's interface. This is the behavior of the IP routing table for the Windows Server 2003 family.
  • Interface This is the designation of the logical or physical interface used when forwarding IP datagrams using this route. The Interface field's value can be a logical name or the IP address assigned to the interface. The IP routing table for the Windows Server 2003 family uses the IP address assigned to the interface.
  • Metric This field indicates the route's cost and is used by the route determination process to choose among multiple routes with the same destination and network mask. When there are multiple routes that match the same des-tination and network mask, the route with the lowest metric is used. The Metric field is commonly used to reflect the hop count—the number of routers to the destination—although routing protocols such as OSPF use customizable link costs that take into account the bandwidth, delay, and physical link costs when calculating the metric.

Types of Routes

A route in the IP routing table is one of the following types (in order of most to least specific):

  • Host route A route to a specific IP address; therefore, the network mask is 255.255.255.255 (/32). Host routes allow you to customize IP routing on a per IP address basis. Host routes are commonly used to specify a more optimal route to specific hosts on a remote subnet.
  • Network ID route A route for classful, classless, subnet, and supernetted destinations. The network mask for a network ID route is somewhere between 128.0.0.0 (/1) and 255.255.255.254 (/31).

    Each network ID route can be either a directly attached network ID route or a remote network ID route. A directly attached network ID route is a route for a network segment on which the router has an interface. Routes for directly attached network IDs might not have a value for the next-hop IP address. A remote network ID is a network ID that is available across another router. For remote network ID routes, the next-hop IP address is an intermediate router's IP address. The next-hop IP address must be directly reachable using the interface in the Interface field.

  • Default route A route to all destinations, used when no other host route or network ID route matching the destination is found. The default route has a destination of 0.0.0.0 and a network mask of 0.0.0.0 (/0) and is sometimes expressed as 0/0. Notice that the default route is a matching route for any destination IP address (any IP address AND 0.0.0.0 is 0.0.0.0). A default route is used to summarize all possible destinations. The default gateway configured on an IP host creates a default route in the IP routing table. For routers, a default route is used to summarize all destinations, and is typically used for static routing and summarizing all the destinations of a large IP internetwork such as the Internet.

Route Determination Process

For any IP datagram being forwarded, a single route in the routing table must be chosen to determine the next-hop interface and IP address for the forwarding process. To determine the single best route for forwarding, IP uses the following process:

  1. For each route in the IP routing table, determine which routes match the destination IP address in the IP datagram by performing a bit-wise logical AND between the destination IP address and the network mask, and comparing the result to the value of the Destination field. If they match, mark the route as a matching route.
  2. From the routes that matched the destination, determine which have the largest number of 1 bits in the Network Mask field. The route(s) with the largest number of 1 bits are the route(s) that most closely matched the destination IP address. This is known as the longest match or closest match paradigm. The longest match is the most specific route to the destination node. Note that for the default route, there are no 1 bits in the Network Mask field; however, it is a matching route.
  3. From the list of longest matching routes, determine which has the lowest metric.
  4. From the list of longest matching routes with the lowest metric, the router is free to choose from the remaining routes.

The end result of the route determination process is the choice of a single route that is the most specific route to the destination with the lowest metric. The single route chosen yields the next-hop IP address and the interface over which to forward the IP datagram.

If no matching route is found, IP indicates a routing error. For a sending host, an internal IP routing error informs the upper layer protocol. For a router, the IP datagram is discarded and an ICMP Destination Unreachable-Host Unreachable message is sent back to the sending host.

The closest matching route process favors routes matching the destination in the following order:

  1. Host route For a host route, all 32 bits match the destination IP address.
  2. Subnet route For a route representing a subnetted network ID, all the class-based network bits and all the subnet bits match the destination IP address.
  3. Class-based network route For a route representing a class-based network ID, all class-based network bits match the destination IP address.
  4. Supernet or summarized route For a route representing a supernetted (Classless Interdomain Routing [CIDR]) or summarized route, all the bits in the summarized network ID match the destination IP address.
  5. Default route For the default route, none of the bits matches the destination IP address.


IP Routing Table for the Windows Server 2003 Family

The IP routing table for the Windows Server 2003 family (for a single interface host with the IP address 131.107.140.89, subnet mask 255.255.240.0, and default gateway 131.107.128.1), as displayed with the route print command, is shown here:

F:\>route print

===========================================================================

Interface List

0x1 ........................... MS TCP Loopback interface

0x10003 ...00 04 5a 56 0f 5b ...... Linksys LNE100TX Fast Ethernet Adapter(LNE100TX v4) #2

===========================================================================

===========================================================================

Active Routes:

Network Destination	Netmask			Gateway		Interface	Metric

0.0.0.0			0.0.0.0			131.107.128.1	131.107.140.89	20
127.0.0.0			255.0.0.0			127.0.0.1		127.0.0.1		1
131.107.128.0		255.255.240.0		131.107.140.89	131.107.140.89	20
131.107.140.89		255.255.255.255		127.0.0.1		127.0.0.1		20
131.107.255.255		255.255.255.255		131.107.140.89	131.107.140.89	20
224.0.0.0			240.0.0.0			131.107.140.89	131.107.140.89	20
255.255.255.255		255.255.255.255		131.107.140.89	131.107.140.89	1

Default Gateway:	131.107.128.1

===========================================================================

Persistent Routes:

    None

This example of an IP routing table for the Windows Server 2003 family consists of the following routes:

  • Default route (0.0.0.0 with 0.0.0.0 or 0/0)

    The closest matching route when there are no other matches. If the default route is chosen, the packet is forwarded to the default gateway's IP address (131.107.128.1) using the interface assigned to the IP address 131.107.140.89.

  • Loopback network route (127.0.0.0 with 255.0.0.0 or 127.0.0.0/8)

    Matches any IP address in the range 127.0.0.0 through 127.255.255.255. All IP addresses beginning with 127 are reserved for loopback. All IP datagrams addressed in this range are forwarded to the reserved loopback address 127.0.0.1 using the loopback interface.

  • Directly attached network route (131.107.128.0 with 255.255.240.0 or 131.107.128.0/20)

    A route to the locally attached subnet. When this route is chosen, the IP datagram is forwarded to the destination IP address using the interface assigned the IP address 131.107.140.89.

  • Local host route (131.107.140.89 with 255.255.255.255 or 131.107.140.89/32)

    A host route for the assigned IP address. All traffic addressed to the local host IP address is forwarded to the reserved loopback address 127.0.0.1 using the loopback interface.

  • All-subnets-directed broadcast route (131.107.255.255 with 255.255.255.255 or 131.107.255.255/32)

    A host route for the all-subnets-directed broadcast address for the class B network ID 131.107.0.0/16. Packets addressed to the all-subnets-directed broadcast address are sent as MAC-level broadcasts, using the interface assigned the IP address of 131.107.140.89. An all-subnets-directed broadcast route is present only if the locally attached network segment is subnetted. For more information on the all-subnets-directed broadcast, see Chapter 6, "Internet Protocol (IP) Addressing."

  • Multicast addresses route (224.0.0.0 with 240.0.0.0 or 224.0.0.0/4)

    Used to match all class D addresses reserved for IP multicast traffic. IP multicast packets are sent as MAC-level multicasts, using the interface assigned the IP address of 131.107.140.89.

  • Limited broadcast route (255.255.255.255 with 255.255.255.255 or 255.255.255.255/32)

    A host route for the limited broadcast address. Datagrams addressed to the limited broadcast address are sent as MAC-level broadcasts using the interface assigned the IP address 131.107.140.89.

These are the routes in the IP routing table created based on the common configuration of an IP address, a subnet mask, and a default gateway. Additional routes can be added through static routes, the receipt of ICMP Redirect messages, or a routing protocol.

The IP routing table for the Windows Server 2003 family differs from the IP routing table for Microsoft Windows 2000 in the following ways:

  • The routing metric for interface and default gateway-based routes is by default set by the TCP/IP protocol based on the speed of the interface. In this example, the routing metric of 20 indicates a 100-Mbps Ethernet interface. Automatic determination of interface-based routing metrics can be disabled through the advanced properties of the TCP/IP protocol.
  • The netmask for the multicast route is 240.0.0.0, rather than 224.0.0.0. This new netmask is a better match for the class D range of addresses defined for multicast addresses.

Multihomed Nodes

For multihomed nodes—nodes with more than one IP address—additional entries for the local host route, the directly attached network ID route, the multicast route, and the limited broadcast address are present for each IP address added. An example is shown here:

F:\>route print

===========================================================================

Interface List

0x1 ........................... MS TCP Loopback interface

0x10003 ...00 04 5a 56 0f 5b ...... Linksys LNE100TX Fast Ethernet Adapter (LN0TX v4) #2

0x10004 ...00 04 5a 56 0f 62 ...... Linksys LNE100TX Fast Ethernet Adapter (LN0TX v4)

===========================================================================

===========================================================================

Active Routes:

Network Destination	Netmask		Gateway		Interface	Metric

0.0.0.0			0.0.0.0		131.107.128.1	131.107.140.89	20
10.117.94.0		255.255.255.0	10.117.94.30	10.117.94.30	30
10.117.94.30		255.255.255.255	127.0.0.1		127.0.0.1		30
10.255.255.255		255.255.255.255	10.117.94.30	10.117.94.30	30
127.0.0.0			255.0.0.0		127.0.0.1		127.0.0.1		1
131.107.128.0		255.255.240.0	131.107.140.89	131.107.140.89	20
131.107.140.89		255.255.255.255	127.0.0.1		127.0.0.1		20
131.107.255.255		255.255.255.255	131.107.140.89	131.107.140.89	20
224.0.0.0			240.0.0.0		10.117.94.30	10.117.94.30	30
224.0.0.0			240.0.0.0		131.107.140.89	131.107.140.89	20
255.255.255.255		255.255.255.255	10.117.94.30	10.117.94.30	1
255.255.255.255		255.255.255.255	131.107.140.89	131.107.140.89	1

Default Gateway:		131.107.128.1

===========================================================================

Persistent Routes:

    None

In this example, the Linksys LNE100TX Fast Ethernet Adapter #2 is configured with the IP address 131.107.140.89, the subnet mask 255.255.240.0, and the default gateway of 131.107.128.1. The Linksys LNE100TX Fast Ethernet Adapter is configured with the IP address 10.117.94.30 and the subnet mask 255.255.255.0. The Linksys LNE100TX Fast Ethernet Adapter is plugged into a 10-Mbps Ethernet hub, and the routes corresponding to this interface have an automatically determined routing metric of 30. The Linksys LNE100TX Fast Ethernet Adapter #2 is plugged into a 100-Mbps Ethernet hub, and the routes corresponding to this interface have an automatically determined routing metric of 20.

Maintaining the IP Routing Table

You maintain the IP routing table for the Windows Server 2003 family with the Route command-line utility. With Route, you can view the routing table and add, change, and delete routes. The IP routing table is stored in random access memory (RAM) and is not preserved when the computer is restarted. It rebuilds a default routing table based on the TCP/IP configuration when TCP/IP is initialized.

To make additional static routes persistent so that they are always added when TCP/IP is initialized, add the routes using the route add command with the -p option. Routes added with the -p option are stored in the registry under the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\

Parameters\PersistentRoutes

For a computer running a member of the Windows Server 2003 family and the Routing and Remote Access service, the IP routing table also can be maintained from the Routing and Remote Access administrative tool. Use shortcut menu options available from the IP Routing\Static Routes object to view the IP routing table and add static routes. Figure 7-5 shows the IP routing table as it appears in the Routing and Remote Access administrative tool.

Figure 7-5. The IP routing table as viewed from the Routing and Remote Access administrative tool.

The IP Routing Process for the Windows Server 2003 Family

The IP routing process for the Windows Server 2003 family is as follows:

  1. Perform the route determination process previously described to choose a single route that is the closest match to the destination and has the lowest metric.
  2. From the chosen route, examine the gateway and interface IP addresses.
  3. If the gateway IP address is the same as the interface IP address, set the next-hop IP address to the destination IP address in the IP datagram being forwarded.
  4. If the gateway IP address is not the same as the interface IP address, set the next-hop IP address to the gateway IP address.

The result of the IP routing process for the Windows Server 2003 family is the IP address of the interface over which the packet is to be forwarded (the Interface field's IP address) and the next-hop IP address (either the IP datagram's destination IP address or the Gateway field's value). This result is then passed to the ARP module to determine the following:

  • For unicast IP traffic sent over broadcast links, the unicast MAC address of the node using the next-hop IP address
  • For multicast IP traffic sent over broadcast links, the multicast MAC address corresponding to the multicast IP address
  • For broadcast IP traffic sent over broadcast links, the MAC-level broadcast address

For more details on how ARP resolves the unicast MAC address of the node to which the datagram is being forwarded, see Chapter 3, "Address Resolution Protocol (ARP)."

Examples of Route Determination for the Windows Server 2003 Family

A host running a member of the Windows Server 2003 family has the following IP routing table:

F:\>route print

===========================================================================

Interface List

0x1 ........................... MS TCP Loopback interface

0x10003 ...00 04 5a 56 0f 5b ...... Linksys LNE100TX Fast Ethernet Adapter(LNE100TX v4) #2

===========================================================================

===========================================================================

Active Routes:

Network Destination	Netmask		Gateway		Interface	Metric

0.0.0.0			0.0.0.0		172.16.1.1	172.16.1.99	20
127.0.0.0			255.0.0.0		127.0.0.1		127.0.0.1		1
172.16.1.0		255.255.255.0	172.16.1.99	172.16.1.99	20
172.16.1.99		255.255.255.255	127.0.0.1		127.0.0.1		20
172.16.255.255		255.255.255.255	172.16.1.99	172.16.1.99	20
224.0.0.0			240.0.0.0		172.16.1.99	172.16.1.99	20
255.255.255.255		255.255.255.255	172.16.1.99	172.16.1.99	1

Default Gateway:		172.16.1.1

===========================================================================

Persistent Routes:

    None

The following are examples of how this routing table is used to determine the next-hop IP address and interface for several different destinations:

  • Unicast destination 172.16.1.47

    When sending traffic to the unicast destination IP address 172.16.1.47 (local subnet traffic), the matching routes are the default route (0.0.0.0 with 0.0.0.0) and the local subnet route (172.16.1.0 with 255.255.255.0). Because the local subnet route is a closer match to the destination IP address (the first 24 bits in the Network Destination matched rather than 0 bits for the default route), the directly attached network ID route is chosen. Because the Gateway and Interface fields are set to the same value, the next-hop IP address for the datagram is set to 172.16.1.47. The IP datagram, the next-hop IP address (172.16.1.47), and the interface (172.16.1.99) are passed to ARP to perform a direct delivery.

  • Unicast destination 192.168.0.79

    When sending traffic to the unicast destination IP address 192.168.0.79 (remote traffic), the only matching route is the default route (0.0.0.0 with 0.0.0.0). Because the Gateway and Interface fields are different, the next-hop IP address for the datagram is set to 172.16.1.1. The IP datagram, the next-hop IP address (172.16.1.1), and the interface (172.16.1.99) are passed to ARP to perform an indirect delivery.

  • Multicast destination 224.0.0.1

    When sending traffic to the multicast destination IP address 224.0.0.1, the matching routes are the default route (0.0.0.0 with 0.0.0.0) and the multicast route (224.0.0.0 with 240.0.0.0). Because the multicast route is a closer match to the destination IP address (the first 4 bits in the Network Destination matched rather than 0 bits for the default route), the multicast route is chosen. Because the Gateway and Interface fields are set to the same value, the next-hop IP address for the datagram is set to 224.0.0.1. The IP datagram, the next-hop IP address (224.0.0.1), and the interface (172.16.1.99) are passed to the ARP module. However, for multicast traffic, the corresponding Network Interface Layer address for 224.0.0.1 is determined (for Ethernet and FDDI, the MAC address is 01-00-5E-00-00-01) and the packet is sent without performing address resolution.

  • Subnet broadcast destination 172.16.1.255

    When sending traffic to the subnet broadcast destination IP address 172.16.1.255, the matching routes are the default route (0.0.0.0 with 0.0.0.0) and the local subnet route (172.16.1.0 with 255.255.255.0). Because the local subnet route is a closer match to the destination IP address (24 bits in the Network Destination matched rather than 0 bits for the default route), the directly attached network ID route is chosen. Because the Gateway and Interface fields are set to the same value, the next-hop IP address for the datagram is set to 172.16.1.255. The IP datagram, the next-hop IP address (172.16.1.255), and the interface (172.16.1.99) are passed to the ARP module. However, for broadcast traffic, the corresponding Network Interface Layer address for broadcast traffic is determined (for Ethernet, Token Ring, and FDDI, the MAC address is FF-FF-FF-FF-FF-FF) and the packet is sent without performing address resolution.

  • Unicast destination 172.16.1.99

    When sending traffic to the unicast destination IP address 172.16.1.99, the matching routes are the default route (0.0.0.0 with 0.0.0.0), the local subnet route (172.16.1.0 with 255.255.255.0), and the local host route (172.16.1.99 with 255.255.255.255). Because the local host route is the closest possible match to the destination IP address (all 32 bits in the Network Destination matched rather than 24 bits for the local subnet route and 0 bits for the default route), the local host route is chosen. The next-hop address is 127.0.0.1 and the next-hop interface is the loopback adapter. The packet is forwarded to the internal loopback adapter without performing address resolution.


IP Routing from Sending Host to Destination

To fully understand IP routing, we must examine the series of forwarding processes that occur at the sending host, the intermediate routers, and the destination host. The following processes assume an IP header without Loose Route, Strict Route, or Record Route IP options.

Sending Host Forwarding Process

When the sending host (a computer running a member of the Windows Server 2003 family) forwards an IP datagram, IP performs the following steps:

  1. The Time to Live (TTL) is set to either the default value or the value specified by an upper layer protocol.
  2. The destination IP address is passed to the IP routing process for the Windows Server 2003 family, which determines the next-hop interface and IP address. If no route is chosen, IP indicates a routing error to the upper layer protocol.
  3. IP passes the IP datagram, the next-hop IP address, and the next-hop interface to ARP.
  4. ARP resolves the next-hop IP address to a unicast MAC address for the indicated interface. For a direct delivery, ARP resolves the destination's MAC address. For an indirect delivery, ARP resolves the intermediate router's MAC address. Once ARP determines the MAC address for the next-hop IP address, it calls NDISSend() to send the frame using the appropriate network adapter.
This sending process assumes that there are no Internet Protocol Security (IPSec) rules that either modify the packet or prevent its sending and that there are no Routing and Remote Access service IP filters that prevent its sending.

IP Router Forwarding Process

When a computer running a member of the Windows Server 2003 family acting as an IP router receives an IP datagram, IP performs the following steps:

  1. IP verifies the IP header checksum. It runs the checksum calculation and compares the result with the value stored in the IP datagram's Header Checksum field. If the result does not match the value of the Header Checksum field, IP silently discards the IP datagram.
  2. IP checks the IP Version field. If the IP version does not equal 4, IP silently discards the IP datagram.
  3. If the IP packet contains either a loose or strict source routing header and the DisableIPSourceRouting registry setting is set to 1 (the default), the packet is silently discarded.
  4. If the IP packet is a fragment, the Routing and Remote Access service is running, and fragmentation checking is enabled on the interface on which the packet was received, the packet is silently discarded. Fragmentation checking is enabled in the General tab from the properties of an interface in the IP Routing\General node in the Routing and Remote Access administrative tool.
  5. IP checks the destination IP address in the IP datagram.
  6. If the destination address in the datagram is an IP multicast address and multicast forwarding is enabled, IP forwards the datagram appropriately. For more information on this process, see Chapter 9, "Internet Group Management Protocol (IGMP)."
  7. If the destination address corresponds to local host traffic (it is an IP address of a router interface or a broadcast address of a locally attached network), IP processes the datagram as the destination host.
  8. If the destination IP address in the datagram is a unicast address that is not a local host IP address, IP decrements the TTL value in the IP header.
  9. If the TTL is 0 (or less), IP submits the IP header and the first 8 bytes of the IP payload to ICMP with an error indication. IP then discards the IP datagram. ICMP includes the IP header and the first 8 bytes of the IP payload as the payload of an ICMP Time Expired-TTL Expired message that is sent back to the sending host.
  10. If the TTL is 1 or greater after decrementing, IP updates the TTL field with its new value, recalculates the IP header checksum, and updates the Header Checksum field's value.
  11. IP passes the value of the destination IP address in the IP datagram to the IP route determination process. If no route is found, IP submits the IP header and the IP payload's first 8 bytes to ICMP with an error indication. IP then discards the IP datagram. ICMP includes the IP header and the first 8 bytes of the IP payload as the payload of an ICMP Destination Unreachable-Host Unreachable message that is sent back to the sending host.
  12. If a route is found, IP passes the modified IP datagram, the next-hop interface, and the next-hop IP address to ARP.
  13. ARP resolves the next-hop IP address to a unicast MAC address for the indicated interface. For a direct delivery, ARP resolves the destination's MAC address. For an indirect delivery, ARP resolves the intermediate router's MAC address. Once the MAC address for the next-hop IP address is determined, ARP calls NDISSend( ) to send the frame using the appropriate network adapter.

This forwarding process is repeated at each intermediate router in the path between the sending host and the destination host.

This forwarding process assumes that there are no IPSec rules that either modify the packet or prevent its forwarding and that there are no Routing and Remote Access service IP filters that prevent its forwarding.

Destination Host Receiving Process

When the final intermediate router performs a direct delivery to the destination host, IP on the destination host performs the following steps:

  1. IP verifies the IP header checksum. It runs the checksum calculation and compares the result with the value stored in the IP datagram's Header Checksum field. If the result does not match the Header Checksum field's value, IP silently discards the datagram.
  2. IP checks the IP Version field. If the IP version does not equal 4, IP silently discards the datagram.
  3. IP checks the destination IP address in the datagram.
  4. If the destination address in the datagram is a unicast address that is not a local host IP address, IP silently discards the datagram.
  5. If the destination IP address corresponds to local host traffic (it is an IP address of a host interface or a broadcast address of a locally attached network) or an IP multicast address, IP checks the Protocol field.
  6. If the Protocol field's value corresponds to an upper layer protocol that is being used on the host, IP passes the IP payload to the appropriate upper layer protocol.
  7. If the Protocol field's value does not correspond to an upper layer protocol that is being used on the host, IP forwards the IP header and the first 8 bytes of the IP payload to ICMP with an error indication. IP then discards the IP datagram. ICMP includes the IP header and the first 8 bytes of the IP payload as the payload of an ICMP Destination Unreachable-Protocol Unreachable message that is sent back to the sending host.
  8. If the IP payload is a TCP segment, IP hands the TCP segment to TCP. After TCP verifies the TCP checksum, it checks the destination port in the TCP header. If the value of the Destination Port field corresponds to an application running on the host, the TCP segment is processed further. If the value of the Destination Port field does not correspond to an application running on the host, a TCP Connection Reset segment is sent back to the sending host. For more information on TCP connections, see Chapter 13, "Transmission Control Protocol (TCP) Connections."
  9. If the IP payload is a User Datagram Protocol (UDP) message, IP hands the UDP message to UDP. After UDP verifies the UDP checksum, it checks the Destination Port field in the UDP header. If the value of the Destination Port field corresponds to an application running on the host, the UDP message is processed further. If the value of the Destination Port field does not correspond to an application running on the host, UDP submits the IP header and the first 8 bytes of the IP payload to ICMP with an error indication. UDP then discards the UDP message. ICMP includes the IP header and the first 8 bytes of the IP payload as the payload of an ICMP Destination Unreachable-Port Unreachable message that is sent back to the sending host.
This receiving process assumes that there are no IPSec rules, TCP/IP protocol filters, or Routing and Remote Access service IP filters that prevent its reception.


IP Routing Infrastructure Overview

For the successful delivery of IP datagrams to an arbitrary location in an IP internetwork, you must employ an IP routing infrastructure. Hosts and routers must have the supporting routes in their routing table to forward unicast traffic to any reachable location. Typically for hosts, all destinations are either directly reachable or reachable through a default route pointing to their default gateway. Routers, however, have either explicit routes for each network segment in the IP internetwork, summarized or aggregated routes, or a default route. The combination of the host's routing table entries and the routers comprise the IP routing infrastructure.

The type of IP routing infrastructure that you deploy can have the following characteristics:

  • Single-path vs. multipath
  • Class-based vs. classless
  • Flat vs. hierarchical
  • Static vs. dynamic
  • Single vs. multiple autonomous systems

Single-Path vs. Multipath

For a single-path routing infrastructure, IP traffic can only travel a single path between any source and any destination. Single-path infrastructures are simple but they are intolerant of network faults. A downed link or a downed router creates physically separate portions of the internetwork that are unreachable for the duration of the fault.

For a multipath routing infrastructure, IP traffic can travel different paths between any source and destination. Typically, a multipath environment forwards IP traffic along a single path until the network topology changes. When coupled with dynamic routing, multipath routing infrastructures can be fault-tolerant. Multipath infrastructures are more complex to plan and implement and there is a possibility that, either because of misconfiguration or a period when the internetwork topology is changing, a routing loop can form. A routing loop is a path through the routing infrastructure that loops back on itself, which occurs when routers forward traffic in a loop that does not include the network segment of the destination. Traffic caught in a routing loop is forwarded between the routers of the loop until the TTL in the IP header becomes 0. Figure 7-6 shows a routing loop created by misconfiguration of the default route (0/0) among three routers (Router B, Router D, and Router C).

Figure 7-6. A default routing loop among Router B, Router D, and Router C.

One way to detect routing loops in your internetwork is to use the Ping command-line utility with the -i option set to 255. The -i option sets the TTL in the ICMP Echo message. If the Ping utility displays "TTL Expired In Transit," there is a good chance you have a routing loop. To ensure that you do have a routing loop, use the Tracert command-line utility to trace the route to the destination. In the Tracert display, look for a set of router IP addresses or names that repeats.

Class-Based vs. Classless

Your routing infrastructure can be either class-based or classless. Although originally a class-based routing infrastructure, address allocation and routing on the modern Internet is classless.

Class-Based Routing

Class-based routing is the determination of the network ID based on the IP address classes. Class-based routing protocols such as RIP version 1 do not advertise a subnet mask when advertising routes. You can subnet with class-based routing protocols; however, there are limitations to the types of addresses and configurations that are permitted.

For example, when subnetting a class-based network ID, all of the subnets of the class-based network ID must be contiguous. Class-based routing protocols do not advertise the subnets of a class-based network ID on network segments that are not a subnet of the class-based network ID. Rather, on network segments that are not a subnet of the class-based network ID, they advertise the summarized class-based network ID. Class-based IP routers summarize the subnets of a class-based network ID by advertising the class-based network ID. Because of this behavior, all subnets must be contiguous. Two different subnets of the same class-based network ID in different parts of the IP internetwork (discontiguous subnets) both separately advertise the summarized class-based network ID. With two routes to the same class-based network ID, routers use the one with the lowest metric. Regardless of which route is chosen, because of proximity to the advertising router, incorrect routing occurs. The locations on both subnets are not reachable by all hosts on the IP internetwork. Because routes learned from neighboring routers are received without a network mask, the class-based router must assume the subnet mask based on the following:

  • If the route fits the class (there are no 1 bits in the host ID portion of the class-based network ID), the class-based default subnet mask is assumed. For example, if the route 195.241.4.0 is received, the network mask of 255.255.255.0 is assumed. This assumption assigns the incorrect mask for CIDR blocks and other uses of aggregated routes. For example, for the CIDR block 195.241.8.0/21, the route assumed by the class-based router is 195.241.8.0/24.
  • If the route does not fit the class (there are more host bits than the class-based network ID), but fits the subnet mask of the interface on which it was received, the subnet mask of the interface on which it was received is assumed. This assumption can assign the incorrect mask for subnetting situations in which the advertised route just happens to fit the subnet mask of the interface on which it was received but is not the correct network mask for the route.
  • If the route does not fit the class or the subnet mask of the interface on which it was received, it is assumed to be a host route with a network mask of 255.255.255.255. This assumption can assign the incorrect mask for many subnetting situations in which the network segment's mask is more specific than the class or the mask of the interface on which it was received. For example, when you subnet 128.1.0.0/16 using variable-length subnetting and the network ID of a network segment is 128.1.64.0/18, the route for the subnetted network ID 128.1.176.0/20 is incorrectly assumed to be 128.1.176.0/32. All locations on the 128.1.176.0/20 network segment are unreachable from the router receiving the advertisement.

Classless Routing

With classless routing, routers never assume that the network mask is based on address classes. Classless routing protocols such as RIP version 2 and OSPF advertise the network mask with the network ID. Because no mask assumptions are made, classless routing allows discontiguous subnets of a network ID, variable-length subnetting, CIDR blocks, and route aggregation. In today's classless world, IP internetworks should be using classless routing with an appropriate routing protocol. Class-based routing should be used only in networks that require compatibility with legacy routing protocols such as RIP version 1.

Flat vs. Hierarchical

For a flat routing infrastructure, each separate network segment is represented as a single route in the IP routers' routing table (assuming no use of default routing). The entire internetwork is a collection of IP network segments with no structure. Although a flat routing infrastructure can work well for small- to medium-sized internetworks, flat routing, when scaled to large networks, produces a large number of routes in routing tables. Consider the example of the Internet. The Internet Network Information Center (InterNIC) at one time allocated class-based network IDs to organizations on request, creating a flat routing infrastructure on the Internet. As the number of allocated network IDs grew, so did the number of routes in the routing tables of Internet backbone routers. Today, Internet backbone routers have more than 80,000 routes in their routing tables.

For a hierarchical routing infrastructure, ranges of network IDs are collapsed to a single network ID and, therefore, a single route through the use of route aggregation techniques. Also, in a hierarchical routing infrastructure, IP network segments that share a common network ID prefix are grouped together and have a network/subnetwork/sub-subnetwork structure. With a hierarchical routing infrastructure, routers at the border of a region of network segments sharing the same set of network ID prefixes advertise a single route that summarizes or aggregates all of the network IDs of the region. In this way, routing information propagated outside the region is highly simplified. Very few routes exist on the backbone of a properly configured hierarchical internetwork.

There are many advantages to hierarchical routing infrastructures, but they require proper planning and an addressing scheme that allows groups of network IDs to be grouped together. Figure 7-7 shows an example of a hierarchical routing infrastructure based on the private network ID 10.0.0.0/8. The arrows and routes represent the summarized route that is advertised outside the region by the router(s) at the region's border.

Figure 7-7. A hierarchical addressing and routing scheme showing routing regions and route summarization at region borders.

For a variety of reasons involving the impracticality of renumbering the IP internetwork, some IP internetworks have a combination of flat and hierarchical routing infrastructures. Before the development of CIDR, the Internet had a flat routing infrastructure. Post-CIDR, IP addresses are allocated using a hierarchical global addressing scheme. However, because of the difficulty of reallocating public network IDs to existing organizations, today's Internet remains a mixed flat and hierarchical routing infrastructure.

Static vs. Dynamic

The ongoing maintenance of routing tables can be done either manually through static routing or automatically using dynamic routing.

Static Routing

Static routing relies on manually configured routes. It supports classless routing because each route must be added with a network mask, making the destination unambiguous. Static routing can work well for small internetworks but it does not scale well because of the manual administration involved. Static routing can also work well in branch office scenarios where, rather than using a routing protocol across the WAN link to the branch office, static routes are added to the branch office and hub office routers to make the locations on each other's network segments reachable.

Ideally, an IP router has explicit knowledge of each network ID in the internetwork, either through an explicit or aggregated route. Default routing is used when connecting a smaller set of network segments to a much larger set of network segments and the creation of explicit or aggregated routes is impractical or impossible. Static routes are often used to connect to the Internet. It is impractical to add the Internet's 80,000 routes to the routing table of the static router; therefore, add a single default route pointing to the downstream Internet service provider (ISP) router.

Static routing is not fault tolerant. A static router cannot sense that a neighboring router is no longer available (if the link to the neighboring router remains operational) or that a remote network segment is no longer reachable and make adjustments to its routing table.

The Windows Server 2003 Family as a Static IP Router

A computer running a member of the Windows Server 2003 family can act as a static IP router by installing multiple network adapters, creating a multihomed computer. A separate IP address and subnet mask is configured for each network adapter, defining routes for the directly attached networks. It is natural to want to configure a default gateway, but this creates a default route, and a default route on a static router is based on a design decision of your static routing environment.

If you use default routing, it is also natural for you to configure a default gateway for each network adapter. However, you must configure a default gateway for a single network adapter corresponding to the network adapter attached to the network segment of the router you want to use for your default route. If you configure a default gateway for more than one network adapter, a default route with an interfaced-based metric is added for each default gateway. This can lead to multiple default routes in the routing table with the same metric. In this situation, TCP/IP for the Windows Server 2003 family picks a default route based on the first network adapter binding. This can lead to undesired behavior if TCP/IP for the Windows Server 2003 family chooses a less than optimal default route.

Once the network adapters are configured, enable IP routing for computers running a member of the Windows Server 2003 family by configuring and enabling the Routing and Remote Access service. For computers running Microsoft Windows XP, set the following registry value to 1:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\

Parameters\IpEnableRouter

After you enable IP routing, add the appropriate specific or aggregated routes of your internetwork using either the Routing and Remote Access administrative tool or the ROUTE ADD command at a command prompt.

Dynamic Routing

Dynamic routers rely on routing protocols—protocols used by routers to communicate routing information—to maintain IP routing tables. Routes for remote network IDs are learned through routing protocol traffic and added or removed from IP routing tables. When all of the IP internetwork routers have received all the information needed to create routes that reflect the internetwork's current topology, the internetwork has converged.

Dynamic routing in a multipath routing infrastructure can provide fault tolerance. When a route becomes unreachable, it is removed from the routing table and its unreachability is conveyed to neighboring routers. When a link or router goes down, routes are adjusted for a new path to the network segments affected by the network fault. Routing protocols can be either class-based or classless depending on how the route is advertised.

The two most common IP routing protocols for private IP internetworks are RIP and OSPF, both of which are supported by the Windows Server 2003 family.

RIP

RIP is a distance vector routing protocol. Distance vector routing protocols propagate routing information in the form of a network ID and its "distance" or hop count. RIP has a maximum distance of 15 hops. Locations 16 or more hops away are considered unreachable. The original version of RIP, known as RIP version 1, described in RFC 1058, is a class-based routing protocol. The network ID is announced without its network mask. Therefore, the restrictions of class-based routing apply. A newer version of RIP, RIP version 2, described in RFC 1723, is a classless routing protocol. The RIP version 2 announcement includes a network ID and a subnet mask.

RFCs 1058 and 1723 describe RIP versions 1 and 2. These RFCs can be found in the \Rfc folder on the companion CD-ROM.

RIP is a simple routing protocol with a periodic route-advertising mechanism designed for use in small- to medium-sized IP internetworks. RIP does not scale well to large or very large IP internetworks.

RIP Operation

When a RIP router is initialized, it announces the appropriate routes in its routing table on all interfaces. The RIP router also sends a RIP General Request message on all interfaces. All neighboring routers—those on the same network segments as the router sending the request—send the contents of their routing tables in response; those responses build the initial routing table. Learned routes are given a three-minute lifetime (by default) before being removed by RIP from the IP routing table.

After initialization, the RIP router periodically announces (every 30 seconds, by default) the appropriate routes in its routing table for each interface. The exact set of routes being announced depends on whether the RIP router is implementing split horizon (where routes are not announced over the interfaces on which they were learned) or split horizon with poison reverse (where routes learned on interfaces are announced as unreachable).

Fault tolerance for RIP internetworks is based on the time-out of RIP-learned routes. If a change occurs in the internetwork topology, RIP routers can send a triggered update—a routing update, sent immediately—rather than waiting for a scheduled announcement.

OSPF

OSPF is a link state routing protocol. Link state routing protocols propagate routing information in the form of link state advertisements (LSAs) that contain the connected networks and their cost. The cost of each router interface is a unitless number that the network administrator assigns, and it can include delay, bandwidth, and monetary cost factors. The accumulated cost among network segments in an OSPF internetwork must be less than 65,535. OSPF is a classless routing protocol; OSPF LSAs contain the network ID and subnet mask for routes. OSPF is described in RFC 2328.

OSPF Operation

Each router has an LSA that describes its current state. The LSA of each OSPF router is efficiently propagated throughout the OSPF internetwork through logical relationships between neighboring routers called adjacencies. When the propagation of all current router LSAs is complete, the OSPF internetwork has converged.

Based on the collection of OSPF LSAs—known as the link state database—OSPF calculates the lowest cost path to each route, and those paths become OSPF routes in the IP routing table. To keep the size of the link state database down, OSPF allows the creation of areas. An OSPF area is a grouping of contiguous networks. In all OSPF networks, there is at least one area called the backbone area. OSPF areas allow the summarization or aggregation of routing information at the boundaries of an OSPF area. A router at the boundary of an OSPF area is known as an area border router (ABR).

Figure 7-8 shows an example of a multiple-area OSPF internetwork. Area 1 consists of a series of variable-length subnetted network segments from the address space 10.47.0.0/16. By default, the ABR for Area 1 propagates routing information in the form of LSAs for each separate network segment within Area 1. Using route summarization, the ABR is configured to propagate only the single route 10.47.0.0/16. All of the destinations within Area 1 are reachable outside of that area using this route. Areas and route summarization allow OSPF internetworks to scale to large organizational IP internetworks.

Figure 7-8. A multiple-area OSPF internetwork showing the route summarization of Area 1.

The Windows Server 2003 Family as a Dynamic Router

A computer running a member of the Windows Server 2003 family can act as a dynamic router supporting RIP and OSPF by installing multiple network adapters and enabling and configuring the Routing and Remote Access service. A separate IP address and subnet mask is configured for each network adapter, defining the directly attached network ID routes. In the case of dynamic routing, default routes are less typically used so a default gateway need not be configured for any network adapter.

After the Routing and Remote Access service is enabled, static IP routing is enabled. Using the Routing and Remote Access administrative tool, add the RIP for IP or OSPF routing protocols and then enable them on your installed network adapters by adding your network adapters to the appropriate routing protocol. The detailed configuration of RIP and OSPF options is beyond the scope of this book. For more information, see the Windows Server 2003 family online Help and the Microsoft Windows Server 2003 Resource Kit Internetworking Guide.

A computer running Microsoft Windows XP Professional can use the RIP protocol to listen to RIP traffic using the RIP Listener, a service installed as a separate networking component. A computer using the RIP Listener service is known as a silent RIP host. The RIP Listener service listens for all RIP version 1 broadcast traffic on the local network segment and maintains routes in the IP routing table.

Single vs. Multiple Autonomous Systems

Very large IP internetworks such as the Internet are divided into regions called autonomous systems (ASs). An AS is a contiguous region of the internetwork under the same administrative control. Administrative control is typically defined by an organization such as an institution or corporation. Within an AS, one or more Interior Gateway Protocols (IGPs) are used. Examples of IGPs include RIP and OSPF. Between autonomous systems, Exterior Gateway Protocols (EGPs) are used. An example of an EGP is the Border Gateway Protocol version 4 (BGP-4). EGPs used between autonomous systems are independent of the IGPs used within the AS.

For most organizations, a single AS is often sufficient. The Internet, however, is a multiple-AS environment composed of a somewhat hierarchical organization of ASs using BGP-4 as the EGP. As seen with OSPF, each AS can be subdivided into areas or domains (if you are using multiple IGPs) to define a hierarchical structure within the AS. If you are an ISP, you might need to implement BGP-4 to communicate routing information to other Internet ASs. The Windows Server 2003 family does not provide support for BGP-4.


Routing Utilities

The Windows Server 2003 family provides the following command-line utilities for maintaining and testing routing functionality:

  • Route Used to view the IP routing table, add temporary and persistent routes, change existing routes, and remove routes from the IP routing table.
  • Ping Used to verify reachability by sending ICMP Echo messages to intended destinations. It also supports the use of IP strict and loose source route options.
  • Tracert Sends ICMP Echo messages with incrementally higher values of the TTL field to discover the path between a node and a destination. In list form, Tracert displays the series of near-side router interfaces encountered by the ICMP Echo message as it traverses the internetwork toward the destination.
  • Pathping Used to discover the path between a host and a destination, and also to identify high-loss links or routers.

For more information about how Ping, Tracert, and Pathping work, see Chapter 8, "Internet Control Message Protocol (ICMP)."


Summary

IP routing is a combination of direct and indirect delivery processes that forward an IP datagram from the source node to the destination node. At each hop, a local IP routing table is consulted to determine how the datagram is delivered to the next hop or the final destination. The route determination process results in a next-hop interface and IP address. The routing infrastructure of an IP internetwork provides reachability between any source and destination node and can be class-based or classless, flat or hierarchical, and static or dynamic, and can consist of a single AS or multiple ASs. The Windows Server 2003 family supports static routing and dynamic routing using RIP version 1, RIP version 2, and OSPF.


Internet Control Message Protocol (ICMP)

Chapter 8
Internet Control Message Protocol (ICMP)

IP provides end-to-end datagram delivery capabilities for IP datagrams. However, IP does not provide any facilities for reporting routing or delivery errors encountered by an IP datagram in its journey from the source to the destination. The Internet Control Message Protocol (ICMP) reports error and control conditions on behalf of IP.

When a protocol encounters an error that cannot be recovered in the processing of a packet, it can do one of the following:

  • Discard the offending packet without sending an error notification to the sending host. This is known as a silent discard. For example, an Ethernet network adapter checks each Ethernet frame for bit-level errors by performing a checksum and comparing its own result with the Frame Check Sequence value stored in the frame. If the two checksums do not match, the adapter considers the frame invalid and silently discards it.
  • Discard the offending packet and send an error notification to the sending host. This is known as an informed discard. ICMP provides an informed discard service for specific types of IP routing and delivery errors.

ICMP is an extensible protocol that also provides functions to check IP connectivity and aid in the automatic configuration of hosts.

ICMP does not make IP reliable. There are no facilities within IP or ICMP to provide sequencing or retransmission of IP datagrams that encounter errors. ICMP messages are unreliably sent as IP datagrams, and although ICMP reports an error, there are no requirements for how the sending host treats the error. It is up to the TCP/IP implementation to interpret the error and adjust its behavior accordingly.

ICMP messages are sent only for the first fragment of an IP datagram. ICMP messages are not sent for problems encountered by ICMP error messages or for problems encountered by broadcast or multicast datagrams.

ICMP is documented in RFCs 792, 950, 1812, 1122, 1191, and 1256. These RFCs can be found in the \Rfc folder on the companion CD-ROM.


ICMP Message Structure

ICMP messages are sent as IP datagrams. Therefore, an ICMP message consisting of an ICMP header and ICMP message data is encapsulated with an IP header using IP Protocol number 1. The resulting IP datagram is then encapsulated with the appropriate Network Interface Layer header and trailer. Figure 8-1 shows the resulting frame.

Figure 8-1. ICMP message encapsulation showing the IP header and Network Interface Layer header and trailer.

In the IP header of ICMP messages, the Source IP Address field is set to the router or host interface that sent the ICMP message. The Destination IP Address field is set to the sending host of the offending packet (in the case of ICMP error messages), a specific host, an IP broadcast, or IP multicast address. Every ICMP message has the same structure, as Figure 8-2 shows.

Figure 8-2. The structure of an ICMP message showing the fields common to all types of ICMP messages.

The common fields in the ICMP message are defined as follows:

  • Type A 1-byte field that indicates the type of ICMP message (Echo vs. Echo Reply, and so on). Table 8-1 lists the most commonly used ICMP types.
  • Code A 1-byte field that indicates a specific ICMP message within an ICMP message type. If there is only one ICMP message within an ICMP type, the Code field is set to 0. The combination of ICMP Type and Code determines a specific ICMP message.
  • Checksum A 2-byte field for a 16-bit checksum covering the ICMP message. ICMP uses the same checksum algorithm as IP for the IP header checksum.
  • Type-Specific Data Optional data for each ICMP type.


ICMP Messages

Table 8-1 lists the most commonly used ICMP types.

Table 8-1. Common ICMP Types
ICMP Type | Description
0 | Echo Reply
3 | Destination Unreachable
4 | Source Quench
5 | Redirect
8 | Echo (also known as an Echo Request)
9 | Router Advertisement
10 | Router Solicitation
11 | Time Exceeded
12 | Parameter Problem
For a complete list of ICMP types, see http://www.iana.org/assignments/icmp-parameters.

The following sections discuss the ICMP messages supported by TCP/IP for the Microsoft Windows Server 2003 family.

ICMP Echo and Echo Reply

One of the most heavily used ICMP facilities is the ability to send a simple message to an IP node and have the message echoed back to the sender. This facility is useful for network troubleshooting and debugging. The simple message sent is an ICMP Echo, and the message echoed back to the sender is an ICMP Echo Reply. For the Windows Server 2003 family, the Ping, Tracert, and Pathping utilities use Echo and Echo Reply messages to provide information about reachability and the path taken to reach a destination node. Figure 8-3 shows the ICMP Echo message structure.

Figure 8-3. The structure of the ICMP Echo message.

The fields in the ICMP Echo message are defined as follows:

  • Type Set to 8.
  • Code Set to 0.
  • Identifier A 2-byte field that stores a number generated by the sender that is used to match the ICMP Echo with its corresponding Echo Reply.
  • Sequence Number A 2-byte field that stores an additional number that is used to match the ICMP Echo with its corresponding Echo Reply. The combination of the values of the Identifier and Sequence Number fields identifies a specific Echo message.
  • Optional Data Optionally, data can be added at the end of the ICMP packet.

For information on how the Windows Server 2003 family determines Identifier, Sequence Number, and Optional Data fields, see the sections "Ping Utility" and "Tracert Utility," later in this chapter.

Frame 1 of the Network Monitor Capture 08-01 (in the \Captures folder on the companion CD-ROM) shows the structure of an ICMP Echo message.

Figure 8-4 shows the ICMP Echo Reply message structure.

Figure 8-4. The structure of the ICMP Echo Reply message.

The fields in the ICMP Echo Reply message are defined as follows:

  • Type Set to 0.
  • Code Set to 0.
  • Identifier Set to the value of the Identifier field of the Echo message being echoed.
  • Sequence Number Set to the value of the Sequence Number field of the Echo message being echoed.
  • Optional Data Set to the value of the Optional Data field of the Echo message being echoed.

Echoed in the Echo Reply message are the Identifier, Sequence Number, and Optional Data fields. The host that sent the original Echo message verifies these fields on receipt. If the fields are not correctly echoed, the Echo Reply message is ignored.

Frame 2 of the Network Monitor Capture 08-01 (in the \Captures folder on the companion CD-ROM) shows the structure of an ICMP Echo Reply message sent in response to an Echo message.

Sending ICMP Echo messages and receiving ICMP Echo Reply messages checks for the following:

  • The host sending the Echo message can forward the Echo message to either the destination (direct delivery) or to a neighboring router (indirect delivery).
  • The routing infrastructure between the host sending the Echo message and the destination can forward the Echo message to the destination.
  • The host sending the Echo Reply message can forward the Echo Reply message to either the destination (the sender of the Echo message) or to a neighboring router.
  • The routing infrastructure between the host sending the Echo Reply message and the destination can forward the Echo Reply message to the destination.

ICMP Destination Unreachable

IP attempts a best-effort delivery of datagrams to their destination. Routing or delivery errors can occur along the path or at the destination. When a routing or delivery error occurs, a router or the destination discards the offending datagram and attempts to report the error by sending an ICMP Destination Unreachable message to the source IP address of the offending packet. Figure 8-5 shows the ICMP Destination Unreachable message structure.

Figure 8-5. The structure of the ICMP Destination Unreachable message.

The fields in the ICMP Destination Unreachable message are defined as follows:

  • Type Set to 3.
  • Code Set to a value from 0 to 13. Table 8-2 lists and discusses the different ICMP Destination Unreachable Code values.
  • IP Header + First 8 Bytes Of Offending Datagram To provide meaningful information to the sender of the offending datagram, the ICMP Destination Unreachable message contains the IP header and the first 8 bytes of the discarded datagram. The IP header contains the IP Identification field. For Transmission Control Protocol (TCP) segments, the first 8 bytes of the IP payload contain the source and destination port numbers and the sequence number. For User Datagram Protocol (UDP) messages, the first 8 bytes contain the entire UDP header including the source and destination port numbers.
Table 8-2. Code Values for ICMP Destination Unreachable Messages
Code Value | Meaning
0 - Network Unreachable | Sent by an IP router when a route for the destination IP address cannot be found in the routing table. The source IP address of this message identifies the router that could not find a route. This message is largely obsolete in today's classless Internet due to the inability of the router to determine the network ID of the destination.
1 - Host Unreachable | Sent by an IP router when a route to the destination was not found in the routing table. In today's classless Internet, this is the more appropriate message to send when a router cannot determine the next hop for an IP datagram. This message's source IP address identifies the router that could not deliver the datagram to the destination host.
2 - Protocol Unreachable | Sent by the destination host when the Protocol field in the datagram's IP header does not match a client protocol of IP that is being used by the destination. For example, if a host is sent an Open Shortest Path First (OSPF) packet (IP protocol 89), it sends a Protocol Unreachable message back to the sender.
3 - Port Unreachable | Sent by the destination host when the destination port in the UDP or TCP header does not match an application running on the destination. In practice, however, when TCP ports cannot be found, TCP sends a Connection Reset segment. Therefore, Port Unreachable messages are sent only for UDP messages.
4 - Fragmentation Needed And DF Set | Sent by an IP router when fragmentation is needed to forward the IP datagram but the Don't Fragment (DF) flag is set in the IP header. The Fragmentation Needed And DF Set message is an important part of the Path Maximum Transmission Unit (PMTU) Discovery process discussed in the "PMTU Discovery" section of this chapter. This message's source IP address identifies the router that could not fragment the IP datagram.
5 - Source Route Failed | Sent by an IP router when it cannot forward an IP datagram using information stored in the Source Route option in the IP header. For example, this ICMP Destination Unreachable message is sent if the sending host is using a strict source route and the next router is not directly reachable. The Source Route Failed message contains source route options of the same type as the offending datagram and includes the path back to the sending host. This message's source IP address identifies the router that could not forward the source-routed IP datagram. For more information on IP source routing, see Chapter 5, "Internet Protocol (IP) Basics."
6 - Destination Network Unknown | Sent by an IP router when the destination network for the destination IP address is indicated in the routing table as an unknown network. In practice, the Destination Network Unknown message is obsolete; IP routers send a Host Unreachable message instead.
7 - Destination Host Unknown | Sent by an IP router when the destination host does not exist as detected through Network Interface Layer mechanisms. In practice, the Destination Host Unknown message is sent only when the router cannot deliver to a host that is connected to the router by a point-to-point link. This message's source IP address identifies the router that could not deliver the IP datagram.
8 - Source Host Isolated | An obsolete message sent by an IP router when it can detect that the source host is isolated from the rest of the network.
9 - Communication with Destination Network Administratively Prohibited | Sent by an IP router when a route to the destination IP address was found but the router cannot forward the IP datagram because of a prohibitive network policy. This message's source IP address identifies the router that could not forward the IP datagram.
10 - Communication with Destination Host Administratively Prohibited | Sent by an IP router when it cannot deliver to the destination host because of a prohibitive network policy. This message's source IP address identifies the router that could not deliver the IP datagram.
11 - Network Unreachable for Type of Service | Sent by an IP router when a route to the destination IP address for the Type Of Service (TOS) indicated in the IP header of the IP datagram was not found. Only routers that use the TOS field when forwarding IP datagrams send this message. This message's source IP address identifies the router that could not forward the IP datagram.
12 - Host Unreachable for Type of Service | Sent by an IP router when it cannot deliver to the destination host for the TOS indicated in the IP header of the IP datagram. Only routers that use the TOS field when forwarding IP datagrams send this message. This message's source IP address identifies the router that could not forward the IP datagram.
13 - Communication Administratively Prohibited Because of Firewalls | Sent by an IP router when it cannot forward or deliver the IP datagram because of administratively configured packet filters on the router. This message's source IP address identifies the router that could not forward or deliver the IP datagram.

Network Monitor Example

To illustrate a Destination Unreachable message, examine the following Network Monitor trace (Capture 08-02 in the \Captures folder on the companion CD-ROM). Frame 1 is an Echo message sent to a private address while on the Internet. Because private addresses are not reachable on the Internet, Frame 2 is the ICMP Destination Unreachable-Host Unreachable message sent by an Internet router.

Frame 1: The ICMP Echo Message

+ FRAME: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

IP: ID = 0x8A03; Proto = ICMP; Len: 60

      IP: Version = 4 (0x4)

      IP: Header Length = 20 (0x14)

      IP: Precedence = Routine

      IP: Type of Service = Normal Service

      IP: Total Length = 60 (0x3C)

      IP: Identification = 35331 (0x8A03)

    + IP: Flags Summary = 0 (0x0)

      IP: Fragment Offset = 0 (0x0) bytes

      IP: Time to Live = 32 (0x20)

      IP: Protocol = ICMP - Internet Control Message

      IP: Checksum = 0x26AA

      IP: Source Address = 134.39.89.236

      IP: Destination Address = 10.0.0.1

      IP: Data: Number of data bytes remaining = 40 (0x0028)

  ICMP: Echo: From 134.39.89.236 To 10.00.00.01

      ICMP: Packet Type = Echo

      ICMP: Echo Code = 0(0x0)

      ICMP: Checksum = 0x1B5C

      ICMP: Identifier = 256 (0x100)

      ICMP: Sequence Number = 12544 (0x3100)

      ICMP: Data: Number of data bytes remaining = 32 (0x0020)

Frame 2: The ICMP Destination Unreachable-Host Unreachable Message

+ FRAME: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

  IP: ID = 0x7AA9; Proto = ICMP; Len: 56

      IP: Version = 4 (0x4)

      IP: Header Length = 20 (0x14)

      IP: Precedence = Routine

      IP: Type of Service = Normal Service

      IP: Total Length = 56 (0x38)

      IP: Identification = 31401 (0x7AA9)

    + IP: Flags Summary = 0 (0x0)

      IP: Fragment Offset = 0 (0x0) bytes

      IP: Time to Live = 252 (0xFC)

      IP: Protocol = ICMP - Internet Control Message

      IP: Checksum = 0xBA4A

      IP: Source Address = 168.156.1.33

      IP: Destination Address = 134.39.89.236

      IP: Data: Number of data bytes remaining = 36 (0x0024)

  ICMP: Destination Unreachable: 10.0.0.1   (See frame 1)

      ICMP: Packet Type = Destination Unreachable

      ICMP: Unreachable Code = Host Unreachable

      ICMP: Checksum = 0xA7A2

      ICMP: Unused Bytes = 0 (0x0)

      ICMP: Data: Number of data bytes remaining = 28 (0x001C)

          ICMP: Description of original IP frame

          ICMP: (IP) Version = 4 (0x4)

          ICMP: (IP) Header Length = 20 (0x14)

        + ICMP: (IP) Service Type = 0 (0x0)

          ICMP: (IP) Total Length = 60 (0x3C)

          ICMP: (IP) Identification = 35331 (0x8A03)

        + ICMP: (IP) Flags Summary = 0 (0x0)

          ICMP: (IP) Fragment Offset = 0 (0x0) bytes

          ICMP: (IP) Time to Live = 28 (0x1C)

          ICMP: (IP) Protocol = ICMP - Internet Control Message

          ICMP: (IP) Checksum = 0x2AAA

          ICMP: (IP) Source Address = 134.39.89.236

          ICMP: (IP) Destination Address = 10.0.0.1

          ICMP: (IP) Data: Number of data bytes remaining = 8 (0x0008)

          ICMP: Description of original ICMP frame

              ICMP: Checksum = 0x1B5C

              ICMP: Identifier = 256 (0x100)

              ICMP: Sequence Number = 12544 (0x3100)

Notice that the ICMP Destination Unreachable-Host Unreachable message contains the discarded version of the IP header and the first 8 bytes (the ICMP header) of Frame 1.

PMTU Discovery

As discussed in Chapter 5, "Internet Protocol Basics," IP fragmentation is an expensive process for both routers and the destination host and should be avoided. An early solution to avoiding fragmentation was the use of a 576-byte IP maximum transmission unit (MTU) to send data to a location on another network. RFC 791 recommends that Network Interface Layer technologies support an IP MTU size of 576 bytes. However, this solution is inefficient; two Ethernet nodes separated by routers send each other 576-byte IP datagrams rather than 1500-byte IP datagrams.

The current solution to avoiding fragmentation is known as PMTU Discovery, and is described in RFC 1191. With PMTU Discovery, hosts send all IP datagrams with the DF flag set to 1. If a router cannot forward an IP datagram onto a link because the datagram's size exceeds the link's MTU, it sends an ICMP Destination Unreachable-Fragmentation Needed And DF Set message (ICMP Type 3, Code 4) back to the sender. Although this has been the behavior since the inception of IP and ICMP, PMTU Discovery support on the router modifies the ICMP message to include the IP MTU of the link onto which the forwarding of the IP datagram failed.

Figure 8-6 shows the modified ICMP Destination Unreachable message. The previous 32-bit Unused field is now a 16-bit Unused field and a 16-bit Next Hop MTU field. The router sets the Next Hop MTU field to the next-hop network segment's IP MTU. After receiving this message, the sending host adjusts the size of the IP datagram to the Next Hop MTU size and retransmits the IP datagram. Sending hosts and all the IP routers in your internetwork must support PMTU.

Figure 8-6. A PMTU-compliant ICMP Destination Unreachable-Fragmentation Needed And DF Set message showing the Next Hop MTU field.

To discover the initial PMTU, a sending host that supports PMTU sets the initial PMTU to the IP MTU of the directly attached network. The host then sends an IP datagram with the DF flag set to 1 at the PMTU size.

After receipt of an ICMP Destination Unreachable-Fragmentation Needed And DF Set message with the Next Hop MTU indicated, the sending host sets the PMTU to the value of the Next Hop MTU and resends the adjusted IP datagram.

The PMTU is determined when no more ICMP Destination Unreachable-Fragmentation Needed And DF Set messages are received.

In the Network Monitor Capture 08-03 (in the \Captures folder on the companion CD-ROM), Frame 1 shows an ICMP Echo message with the DF set to 1 and a 1000-byte Optional Data field. This packet is being forwarded across a router interface that supports only a 576-byte IP MTU. Frame 2 is an ICMP Destination Unreachable-Fragmentation Needed And DF Set message indicating the Next Hop MTU of 576.

Adjusting the PMTU

In a single-path internetwork, the PMTU remains the same once discovered. In a multipath internetwork, the PMTU can change based on the paths that the IP datagrams travel because of changing conditions in the routing infrastructure. The PMTU can change to be either higher or lower than the currently known PMTU.

  • For a lower PMTU, the sending host is immediately informed through a Destination Unreachable-Fragmentation Needed And DF Set message.
  • For a higher PMTU, because there is no mechanism on the routers to inform the sending host that larger datagrams can now be sent, it is up to the host to rediscover the new larger PMTU. If the host's PMTU is smaller than the IP MTU of the locally attached network, the sending host attempts to send larger IP datagrams five minutes after receiving the last ICMP Destination Unreachable-Fragmentation Needed And DF Set message, and at one-minute intervals thereafter.

Routers That Do Not Support PMTU

PMTU Discovery relies on PMTU support on the sending host and all of the internetwork's routers. TCP/IP for the Windows Server 2003 family supports PMTU Discovery for both hosts and routers. However, what happens when an intermediate router does not support PMTU Discovery?

The lack of support for PMTU Discovery on IP routers can occur on the following two levels:

  • The router sends back ICMP Destination Unreachable-Fragmentation Needed And DF Set messages without the Next Hop MTU field.
  • The router does not send back ICMP Destination Unreachable-Fragmentation Needed And DF Set messages.

In the first case, the router is not RFC 1191-compliant and according to the sending host, the Destination Unreachable-Fragmentation Needed And DF Set message contains a 0 Next Hop MTU. The sending host assumes that PMTU Discovery is not possible and uses either the minimum PMTU of 576 bytes or a series of plateau values for the PMTU until Destination Unreachable-Fragmentation Needed And DF Set messages are no longer received. Table 8-3 lists the plateau values, which correspond to the IP MTUs of common Network Interface Layer technologies. Hosts running a member of the Windows Server 2003 family do not use these plateau values. TCP/IP PMTU behavior for the Windows Server 2003 family is described later in this chapter.

Table 8-3. Plateau Values for PMTU
Plateau Value | Representing
65,535 | Maximum IP MTU
32,000 | Just in case
17,914 | 16-Mbps IBM Token Ring
8166 | IEEE 802.4
4352 | IEEE 802.5 (4 Mbps) and Fiber Distributed Data Interface (FDDI)
2002 | Wideband Network and IEEE 802.5 (4 Mbps)
1492 | Ethernet/IEEE 802.3 (Sub-Network Access Protocol [SNAP])
1006 | Serial Line Internet Protocol (SLIP)
508 | X.25 and Attached Resource Computer Network (ARCnet)
296 | Point-to-Point (low delay)
68 | Minimum IP MTU

When a router does not send back Destination Unreachable-Fragmentation Needed And DF Set messages, it is called a PMTU Black Hole Router. PMTU Black Hole Routers perform silent discards for datagrams that cannot be fragmented. Because IP is unreliable, it is the responsibility of an upper layer protocol to recover from the discarded packet. For example, TCP segments are retransmitted when their retransmission timer expires.

To successfully detect a PMTU Black Hole Router, discarded packets with the DF flag set to 1 are retransmitted with the DF flag set to 0. If an acknowledgment is received, the TCP maximum segment size (MSS) is lowered to the next lowest plateau value and the DF flag for subsequent IP datagrams is set to 1. This process repeats until the PMTU is found.

TCP/IP PMTU behavior for the Windows Server 2003 family is controlled by the following registry settings:

EnablePMTUBHDetect

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-1

Default: 0

Present by default: No

EnablePMTUBHDetect enables (when set to 1) or disables (when set to 0) the detection of PMTU Black Hole Routers. By default, detection of PMTU Black Hole Routers is disabled. TCP sends segments with the DF flag set to 1. If no acknowledgments are received after the maximum number of TCP retransmissions, the TCP connection is terminated. If enabled, the PMTU is set at 576 bytes after no acknowledgment is received for a large segment after several retransmissions.

EnablePMTUDiscovery

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-1

Default: 1

Present by default: No

EnablePMTUDiscovery enables (when set to 1) or disables (when set to 0) PMTU Discovery for TCP connection data. By default, PMTU Discovery is enabled. TCP attempts to discover the PMTU by initially transmitting segments at the largest segment size and then adjusting the segment size when Destination Unreachable-Fragmentation Needed And DF Set messages are received.

If disabled, PMTU Discovery is not performed and an IP MTU of 576 bytes is assumed for traffic not destined to a host on a locally attached network.

ICMP Source Quench

When a router becomes congested because of a sudden increase in traffic, a slow link, or inadequate processor and memory resources, the router begins to discard incoming IP datagrams. When a router discards an IP datagram because of congestion, it might send an ICMP Source Quench message back to the sending host. The Source IP Address field of the ICMP Source Quench message identifies the congested router. The destination host can also send ICMP Source Quench messages when IP datagrams are arriving too quickly to be buffered.

RFC 792 does not document the specific implementation details of when a router or destination host sends ICMP Source Quench messages. A router can begin sending Source Quench messages when its memory buffer for storing incoming packets is approaching its maximum capacity, rather than waiting for the buffer to fill. A router does not have to send a Source Quench message for every packet discarded. In fact, RFC 1812 states that routers should not send ICMP Source Quench messages because creating more traffic on a congested internetwork only aggravates the congestion.

The ICMP Source Quench message is an Internet Layer notification. However, the Internet Layer has no mechanism for flow control. IP is unaware of when to increase or decrease its transmission rate. Similarly, UDP has no mechanism for flow control.

TCP is an upper layer protocol that has flow control mechanisms to lower the transmission rate. Therefore, after receipt of the ICMP Source Quench message for a discarded TCP segment, a notification is made to TCP. TCP treats the receipt of the ICMP Source Quench message for a specific TCP segment as a lost TCP segment that needs to be retransmitted. TCP then adjusts its transmission rate for the connection according to the slow start and congestion avoidance algorithms. The sending host gradually increases its transmission rate, giving time for the routers to clear their buffers. For more information, see Chapter 14, "Transmission Control Protocol (TCP) Data Flow." Figure 8-7 shows the ICMP Source Quench message structure.

Figure 8-7. The structure of the ICMP Source Quench message.

The fields in the ICMP Source Quench message are defined as follows:

  • Type Set to 4.
  • Code Set to 0.
  • IP Header + First 8 Bytes Of Discarded Datagram The ICMP Source Quench message contains the IP header and the first 8 bytes of the discarded datagram.

In the Windows Server 2003 family, TCP/IP properly implements TCP flow control if an ICMP Source Quench message is received and contains the IP header and TCP header (only the first 8 bytes) for an active TCP connection. In the Windows Server 2003 family, TCP/IP does not send ICMP Source Quench messages as a router when the router buffers fill and packets are discarded.

ICMP Redirect

It is common for hosts to have minimal routing tables. A typical host has a route to the locally attached network and a default route corresponding to the host's configured default gateway. The routers keep all other knowledge of the internetwork's topology—the entire list of network IDs and the best next-hop IP addresses to reach them. For network segments containing a single router and hosts configured with the IP address of the single router as their default gateway, all routing from hosts to remote networks occurs through the optimal path—the single router.

However, if there are multiple routers on a network segment with hosts configured with a default gateway of a single router, the possibility exists for nonoptimal routing. Consider the IP internetwork in Figure 8-8.

Figure 8-8. An ICMP Redirect scenario where a host with a configured default gateway must forward an IP datagram using another router.

Host A, 10.0.0.99/24, is configured with the default gateway of 10.0.0.1. Host A sends an IP datagram to Host B at 192.168.1.99. Router 1 is attached to network 10.0.0.0/24 and the rest of the IP internetwork. Router 2 is attached to network 10.0.0.0/24 and 192.168.1.0/24. According to the default route in Host A's IP routing table, to reach 192.168.1.99, forward the IP datagram to 10.0.0.1. This is not the optimal path, however. For the optimal path, the datagram must be forwarded to 10.0.0.2.

To inform Host A of the more optimal route for traffic to Host B at 192.168.1.99, Router 1 uses an ICMP Redirect message. Host A uses the contents of the ICMP Redirect message to create a host route in its routing table so that subsequent IP datagrams to Host B take the more optimal route through Router 2 at 10.0.0.2.

The following is the ICMP Redirect process in detail:

  1. Host A forwards the IP datagram destined for Host B to its default gateway, Router 1, at the IP address of 10.0.0.1.
  2. Router 1 receives the IP datagram. Because the IP datagram is not destined for an IP address assigned to Router 1, Router 1 checks the contents of its routing table for a route to Host B. A route is found for 192.168.1.0/24 at the next-hop IP address of 10.0.0.2.
  3. Before forwarding the IP datagram to Router 2 at 10.0.0.2, Router 1 notices that the sending host's IP address, the IP address of the interface on which the IP datagram was received, and the next-hop IP address are all on the same network, 10.0.0.0/24.
  4. Router 1 forwards the IP datagram to Router 2.
  5. Router 1 sends an ICMP Redirect message to Host A. The Redirect message contains the next-hop IP address for Router 2, 10.0.0.2, and the IP header of the discarded IP datagram.
  6. Based on the contents of the Redirect message, Host A creates a host route for the IP address of Host B, 192.168.1.99, at the next-hop IP address of 10.0.0.2.
  7. Subsequent packets from Host A to Host B are forwarded to Router 2 at the IP address of 10.0.0.2.

ICMP Redirect messages are never sent for IP datagrams using source route options. The presence of source route options means that a specific path must be followed without regard to whether it is optimal. Source route options are sometimes used to test connectivity along nonoptimal paths.

Figure 8-9 shows the ICMP Redirect message structure.

Figure 8-9. The structure of the ICMP Redirect message.

The fields in the ICMP Redirect message are defined as follows:

  • Type Set to 5.
  • Code Set to 0-3 (see Table 8-4).
  • Router IP Address A 4-byte field set to the next-hop IP address for the more optimal route to the destination of the offending IP datagram. This IP address becomes the address in the Gateway column of the host route created in the IP routing table for the Windows Server 2003 family.
  • IP Header + First 8 Bytes Of Forwarded Datagram To identify the forwarded IP datagram, the IP header and the first 8 bytes of the IP payload are encapsulated and sent back to the sending host. Included in the encapsulated IP header is the destination IP address that becomes the value in the Destination Network column for the host route created in the IP routing table for the Windows Server 2003 family. The Network Mask for the host route is set to 255.255.255.255.
Table 8-4. Values of the Code Field in an ICMP Redirect
Code Value | Meaning
0 | Redirected datagrams for the network (obsolete)
1 | Redirected datagrams for the host
2 | Redirected datagrams for the TOS and the network
3 | Redirected datagrams for the TOS and the host
ICMP Redirect messages are sent only when the sending host forwards an IP datagram using a nonoptimal route. ICMP Redirect messages are never sent when routers forward IP datagrams using nonoptimal routes.

Network Monitor Capture 08-04 (in the \Captures folder on the companion CD-ROM) shows an ICMP Echo message and the ICMP Redirect message for the example previously discussed.

In the Windows Server 2003 family, TCP/IP behavior for ICMP Redirect messages is controlled by the following registry setting:

EnableICMPRedirect

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-1

Default: 0

Present by default: Yes

EnableICMPRedirect enables (when set to 1) and disables (when set to 0) the adding of host routes to the IP routing table when an ICMP Redirect message is received. EnableICMPRedirect is disabled by default. If enabled, when a host running TCP/IP for the Windows Server 2003 family receives an ICMP Redirect message, it first checks the source IP address to ensure that it was sent from the router indicated by the Gateway column for the route to the destination in the IP routing table. TCP/IP for the Windows Server 2003 family also ensures that the source IP address of the ICMP Redirect is directly reachable. If the ICMP Redirect did not come from the directly reachable indicated router, the ICMP Redirect is ignored. Host routes created through ICMP Redirect messages persist in the routing table for 10 minutes. After 10 minutes, the ICMP Redirect process occurs again.

ICMP Router Discovery

ICMP Router Discovery is a set of ICMP messages documented in RFC 1256 that are used by both routers to advertise their presence and by hosts to discover their network segment's routers, and choose which router will be the host's default gateway. ICMP Router Discovery provides a fault-tolerance mechanism for downed routers. Hosts eventually realize that their current default gateway has become unavailable and switch their default gateway to the next most preferred router.

ICMP Router Discovery uses the following two different ICMP messages:

  • ICMP Router Advertisement The ICMP Router Advertisement message is sent pseudo-periodically (at a random interval between a minimum and maximum value) by a router to advertise its continued existence, a preference level, and a time after which it can be considered unavailable.
  • ICMP Router Solicitation Hosts send an ICMP Router Solicitation message whenever they need to discover the most preferred router to use as their default gateway. ICMP Router Discovery-capable hosts that have not been configured with a default gateway send an ICMP Router Solicitation message on startup. Additionally, hosts send an ICMP Router Solicitation message when the availability time of their current default gateway (discovered through ICMP Router Discovery) expires.

ICMP Router Discovery is not a routing protocol; it provides information only on a preferred default gateway for hosts on a network segment. ICMP Router Discovery does not provide any information on network IDs or optimal paths.

ICMP Router Advertisement

Routers send the ICMP Router Advertisement message to either the all-hosts multicast IP address (224.0.0.1), the subnet (or network) broadcast address, or the limited broadcast address. ICMP Router Advertisements are sent pseudo-periodically and in response to an ICMP Router Solicitation. The default interval for ICMP Router Advertisements is between 7 and 10 minutes. The Routing and Remote Access service implementation of ICMP Router Discovery sends ICMP Router Advertisements to the all-hosts multicast IP address. Figure 8-10 shows the ICMP Router Advertisement message structure.

Figure 8-10. The structure of the ICMP Router Advertisement message.

The fields in the ICMP Router Advertisement message are defined as follows:

  • Type Set to 9.
  • Code Set to 0.
  • Number Of Addresses A 1-byte field that indicates how many IP addresses are being advertised. Normally, only a single IP address is advertised. For a router with multiple interfaces on the same network segment, multiple IP addresses are advertised.
  • Address Entry Size A 1-byte field that indicates how many 32-bit words (4-byte quantities) are contained in a Router Advertisement entry. A Router Advertisement entry consists of an IP address (32 bits) and a preference level (32 bits). Therefore, the Address Entry Size field is always set to 2.
  • Lifetime A 2-byte field that indicates the time in seconds after the last received Router Advertisement that the router can be considered down. This is equivalent to the Dead Interval for the OSPF routing protocol. The Lifetime field has a default value of 3600 (30 minutes).
  • Router Address A 4-byte field that indicates the IP address of the network segment's router interface on which the advertisement was sent.
  • Preference Level A 4-byte field that indicates the level of preference for using the Router Address as the IP address of your default gateway. The router advertising the highest preference level is the most preferred router. If there are two or more routers with the same preference level, the router with the numerically smallest router address becomes the default gateway.

Router Advertisement behavior for the Routing and Remote Access service is configured per interface through the properties of an interface in the IP Routing\General node in the Routing and Remote Access administrative tool.

ICMP Router Solicitation

Hosts send the ICMP Router Solicitation message to the all-routers multicast IP address (224.0.0.2), the subnet (or network) broadcast address, or the limited broadcast address.

TCP/IP for the Windows Server 2003 family listens for ICMP Router Advertisements that are sent to the all-hosts multicast address of 224.0.0.1 and sends up to three ICMP Router Solicitation messages spaced 600 milliseconds apart to the all-routers multicast IP address. Figure 8-11 shows the ICMP Router Solicitation message structure.

Figure 8-11. The structure of the ICMP Router Solicitation message.

The fields in the ICMP Router Solicitation message are defined as follows:

  • Type Set to 10.
  • Code Set to 0.
  • Reserved A 4-byte field that is set to all 0s.

In the Windows Server 2003 family, TCP/IP host Router Discovery behavior is controlled by the following registry settings:

PerformRouterDiscovery

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters\Interfaces\InterfaceGUID

Data type: REG_DWORD

Valid range: 0-2

Default: 2

Present by default: No

PerformRouterDiscovery enables (when set to 1) and disables (when set to 0) ICMP Router Discovery per interface. Alternately, when PerformRouterDiscovery is set to 2 (the default), it is disabled but can be enabled if the computer is a Dynamic Host Configuration Protocol (DHCP) client and the Perform router discovery option (option code 31) is sent by the DHCP server.

SolicitationAddressBCast

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters\Interfaces\InterfaceGUID

Data type: REG_DWORD

Valid range: 0-1

Default: 0 (disabled)

Present by default: No

SolicitationAddressBCast enables (when set to 1) or disables (when set to 0) the use of the subnet (or network) broadcast address as the destination IP address of ICMP Router Solicitation messages. When disabled (the default), TCP/IP for the Windows Server 2003 family uses the all-routers IP multicast address (224.0.0.2).

ICMP Time Exceeded

The ICMP Time Exceeded message is sent in the following instances:

  • When a router decrements the IP header's TTL field to 0 (the ICMP Time Exceeded-TTL Exceeded in Transit message)
  • When the reassembly timer for a fragmented IP datagram expires (the ICMP Time Exceeded-Fragment Reassembly Time Exceeded message)

When the TTL goes to 0 for an IP datagram, it can mean one of two things:

  • The IP datagram was sent with an inadequate TTL that does not reflect the current number of links between the source and destination nodes. In this case, the TTL should be increased.
  • A routing loop exists in the internetwork. As discussed in Chapter 7, "Internet Protocol (IP) Routing," a routing loop occurs when IP routers have incorrect routing information and forward an IP datagram in a loop that never reaches the destination. To test for a routing loop, send an IP datagram with a TTL of 255, the maximum value. If an ICMP Time Exceeded-TTL Exceeded in Transit message is still received, a routing loop exists in your internetwork.

Destination hosts receiving a fragmented IP datagram use a reassembly timer as a maximum time to wait before discarding the incomplete IP datagram. If all of an IP datagram's fragments arrive within the time allotted in the reassembly timer, the IP datagram is successfully reassembled. If the reassembly timer expires before all of an IP datagram's fragments have been received, the destination host discards the incomplete payload and can send an ICMP Time Exceeded-Fragment Reassembly Time Exceeded message back to the source. Figure 8-12 shows the ICMP Time Exceeded message structure.

Figure 8-12. The structure of the ICMP Time Exceeded message.

The fields in the ICMP Time Exceeded message are defined as follows:

  • Type Set to 11.
  • Code Set to 0 or 1. Set to 0 by a router to indicate a TTL expiration (the ICMP Time Exceeded-TTL Exceeded in Transit message). Set to 1 by a destination host to indicate a reassembly expiration (the ICMP Time Exceeded-Fragment Reassembly Time Exceeded message).
  • IP Header + First 8 Bytes Of Discarded Datagram To identify the discarded IP datagram, the ICMP Time Exceeded message contains the IP header and the first 8 bytes of the IP payload.

Network Monitor Capture 08-05 (in the \Captures folder on the companion CD-ROM) shows an ICMP Echo message from an Internet host sent to an Internet Web site with an insufficient TTL.

ICMP Parameter Problem

A router or a destination host sends an ICMP Parameter Problem message when an error occurs in the processing of the IP header that causes the IP datagram to be discarded, and there are no other ICMP messages that can be used to indicate the error. ICMP Parameter Problem messages can be sent because of errors in TCP/IP implementations causing incorrect formatting of IP header fields. Typically, ICMP Parameter Problem messages are sent because of incorrect arguments in IP option fields. Figure 8-13 shows the ICMP Parameter Problem message structure.

Figure 8-13. The structure of the ICMP Parameter Problem message.

The fields in the ICMP Parameter Problem message are defined as follows:

  • Type Set to 12.
  • Code Set to 0-2. See Table 8-5.
  • Pointer A 1-byte field set to the byte offset (starting at 0) in the encapsulated IP header where the error was detected for Parameter Problem messages with the Code field set to 0.
  • IP Header + First 8 Bytes Of Discarded Datagram To identify the discarded IP datagram, the ICMP Parameter Problem message contains the IP header and the first 8 bytes of the IP payload.
Table 8-5. ICMP Parameter Problem Code Values
Code Value | Meaning
0 | Pointer indicates error
1 | Missing a required option
2 | Bad length
ICMP Parameter Problem messages are never sent for IP datagrams with an invalid checksum. IP datagrams that fail the checksum are silently discarded.

ICMP Address Mask Request and Address Mask Reply

The ICMP Address Mask Request and Address Mask Reply messages were introduced in RFC 950 as a method for an IP node to discover its subnet mask. When subnetting, a class-based subnet mask based on the first three bits of the IP address can no longer be assumed.

An IP node can send an ICMP Address Mask Request as directed traffic to a known router or as a broadcast using either the all-subnets-directed broadcast or the limited broadcast IP address. If an IP node does not know its IP address, it can send the ICMP Address Mask Request with a source IP address of 0.0.0.0. The subsequent ICMP Address Mask Reply must then be sent as a broadcast.

The ICMP Address Mask Reply is sent by a router and contains the 32-bit subnet mask for the network segment on which the Address Mask Request was received. If no Address Mask Reply is received, the IP node assumes a class-based subnet mask.

The ICMP Address Mask Request and Address Mask Reply messages have the structure shown in Figure 8-14.

Figure 8-14. The structure of the ICMP Address Mask Request and Reply messages.

The fields in the ICMP Address Mask Request and Address Mask Reply messages are defined as follows:

  • Type Set to 17 for the Address Mask Request and 18 for the Address Mask Reply.
  • Code Set to 0.
  • Identifier Optionally used to match an Address Mask Reply with its original Address Mask Request.
  • Sequence Number Also optionally used to match an Address Mask Reply with its original Address Mask Request.
  • Address Mask The 32-bit subnet mask corresponding to the IP host's network or subnet. The Address Mask field is set to 0.0.0.0 in the Address Mask Request and the 32-bit subnet mask of the network segment in the Address Mask Reply.

In TCP/IP for the Windows Server 2003 family, ICMP Address Mask Reply message behavior is controlled by the following registry setting:

EnableAddrMaskReply

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-1

Default: 0

Present by default: No

EnableAddrMaskReply enables (when set to 1) and disables (when set to 0) the sending of an Address Mask Reply message after the receipt of an Address Mask Request message. By default, the sending of Address Mask Reply messages is disabled.


Ping Utility

The Ping command-line utility for the Windows Server 2003 family is the primary network tool for troubleshooting IP connectivity. The Ping utility tests reachability, name resolution, source routing, network latency, and other issues for both IP version 4 (IPv4) and IP version 6 (IPv6). For IPv4, Ping sends an ICMP Echo message to a specified destination and records the round-trip time, the number of bytes sent, and the corresponding Echo Reply's TTL. When Ping finishes sending ICMP Echo messages, it displays statistics on the average number of replies and round-trip time. For IPv6, Ping works the same way and performs the same functions only using Internet Control Message Protocol version 6 (ICMPv6) Echo Request messages.

When you ping a destination IPv4 address, the default behavior is to send four fragmentable, non-source-routed ICMP Echo messages with an Optional Data field of 32 bytes and wait four seconds for the corresponding ICMP Echo Reply. When you ping a name, normal name resolution mechanisms resolve the name to an IPv4 or IPv6 address before the ICMP Echo or ICMPv6 Echo Request messages are sent. If TCP/IP for the Windows Server 2003 family is unable to resolve the name to an address, the Ping utility displays an error message. If a corresponding Echo Reply is not received within four seconds, Ping displays the error message "Request Timed Out."

In the ICMP header of Ping-generated ICMP Echo messages in the Windows Server 2003 family:

  • The Identifier field is set to 768 (0x300).
  • The Sequence Number field for the first Echo message is chosen as a multiple of 256 (0x100) and the Sequence Number for subsequent Echo messages is incremented by 256 (0x100).
  • The Optional Data field is 32 bytes (by default), consisting of the string "abcdefghijklmnopqrstuvwabcdefghi."

Ping Options

Table 8-6 lists the use and default values of Ping utility options.

Table 8-6. Ping Utility Options
Option | Use | Default
-t | Sends Echo messages until interrupted. | Not used
-a | Performs a Domain Name System (DNS) reverse query to resolve the DNS host name of the specified address. | Not used
-n count | The number of Echo messages to send. | 4
-l size | The size of the Optional Data field up to a maximum of 65,500. | 32
-f | Sets the DF flag to 1. This switch is only valid for IPv4 traffic. | Not used
-i TTL | Sets the value of the TTL field in the IPv4 header or the Hop Limit field in the IPv6 header. | 128
-v TOS | Sets the value of the TOS field in the IPv4 header. The TOS value is in decimal notation. This switch is only valid for IPv4 traffic. | 0
-r count | Sends the ICMP Echo messages using the IP Record Route option and sets the value of the number of slots. Count has a maximum value of 9. This switch is only valid for IPv4 traffic. | Not used
-s count | Sends the ICMP Echo messages using the IP Internet Timestamp option and sets the value of the number of slots. Count has a maximum value of 4. In the Windows Server 2003 family, Ping uses the Internet Timestamp flag set to 1 (records both the IP addresses of each hop and the timestamp). This switch is only valid for IPv4 traffic. | Not used
-j host-list | Sends the ICMP Echo messages using the Loose Source Route option and sets the next-hop addresses to the IP addresses in the host list. The host list is made up of IP addresses separated by spaces corresponding to the loose source route. There can be up to nine IP addresses in the host list. This switch is valid only for IPv4 traffic. | Not used
-k host-list | Sends the ICMP Echo messages using the Strict Source Route option and sets the next-hop addresses to the IP addresses in the host list. The host list is made of IP addresses separated by spaces corresponding to the strict source route. There can be up to nine IP addresses in the host list. This switch is only valid for IPv4 traffic. | Not used
-w timeout | Waits the specified amount of time, in milliseconds, for the corresponding Echo Reply before displaying a Request Timed Out message. | 4000
-R | Forces Ping to trace the round-trip path by sending the ICMPv6 Echo Request message to the destination and including an IPv6 Routing extension header with the next destination of the sending node. This switch is only valid for IPv6 traffic. | Not used
-S sourceaddr | Forces Ping to use a specified source address. This switch is only valid for IPv6 traffic. | Not used
-4 | Forces Ping to use an IPv4 address when the DNS name query for a host name returns both IPv4 and IPv6 addresses. | Not used
-6 | Forces Ping to use an IPv6 address when the DNS name query for a host name returns both IPv4 and IPv6 addresses. | Not used

Network Monitor Example

The following Network Monitor trace (Capture 08-01 in the \Captures folder on the companion CD-ROM) illustrates a summary of a typical use of the Ping utility to ping a destination IPv4 address. Four Echo messages are sent and four Echo Reply messages are received. The summarized frames have been indented for readability.

Frame	Time	Src MAC Addr	Dst MAC Addr	Protocol	Description

1	0.271	0060083E4607	00502AB9A440	ICMP	Echo, From
                        157.59.11.19 To 157.59.08.01

2	0.271	00502AB9A440	0060083E4607	ICMP	Echo Reply, To
                        157.59.11.19 From 157.59.08.01

3	1.271	0060083E4607	00502AB9A440	ICMP	Echo, From
                        157.59.11.19 To 157.59.08.01

4	1.271	00502AB9A440	0060083E4607	ICMP	Echo Reply, To
                        157.59.11.19 From 157.59.08.01

5	2.273	0060083E4607	00502AB9A440	ICMP	Echo, From
                        157.59.11.19 To 157.59.08.01

6	2.273	00502AB9A440	0060083E4607	ICMP	Echo Reply, To
                        157.59.11.19 From 157.59.08.01

7	3.275	0060083E4607	00502AB9A440	ICMP	Echo, From
                        157.59.11.19 To 157.59.08.01

8	3.275	00502AB9A440	0060083E4607	ICMP	Echo Reply, To
                        157.59.11.19 From 157.59.08.01


Tracert Utility

The Tracert utility uses ICMP Echo or ICMPv6 Echo Request messages to determine the path—the series of routers—that unicast IPv4 and IPv6 traffic takes from a source host to a destination host. Tracert tests reachability, name resolution, network latency, routing loops, and other issues.

When you tracert a destination IP address, the default behavior is to trace the route and report the round-trip time, the near-side router IP address, and the DNS name corresponding to the near-side router IP address. When you tracert a name, normal name resolution techniques resolve the name to an IP address before the ICMP Echo messages are sent. If TCP/IP for the Windows Server 2003 family is unable to resolve the name to an IP address, the Tracert utility displays an error message.

Tracert for IPv4 destinations works in the following manner:

  1. An ICMP Echo message is sent to the destination with the TTL in the IP header set to 1. If the destination is on a directly attached network, the destination responds with a corresponding Echo Reply message and Tracert is done.
  2. If the destination is not in a directly attached network, the ICMP Echo message is forwarded to an IP router.
  3. The IP router determines that the IP datagram is transit traffic (not destined for the router) and decrements the TTL. Because the TTL is now 0, the IP router discards the IP datagram and sends back an ICMP Time Exceeded-TTL Exceeded in Transit message to the sending host with the source IP address set to the IP address of the interface on which the ICMP Echo message was received. The interface on which the ICMP Echo message was received is the near-side interface, the interface that is the smallest number of hops from the sending host.
  4. After receipt of the ICMP Time Exceeded-TTL Exceeded in Transit message, the Tracert utility records the round-trip time and the source IP address.
  5. Tracert sends two more ICMP Echo messages and records their round-trip time.
  6. An ICMP Echo message is sent to the destination with the IP header's TTL set to 2. The Echo is forwarded to a neighboring IP router.
  7. The neighboring IP router determines that the IP datagram is transit traffic, decrements the TTL to 1, and forwards it to the next hop or the final destination.
  8. If the destination is on a directly attached network, the destination responds with a corresponding Echo Reply and Tracert is done.
  9. If the destination is not on a directly attached network, the IP router determines that the IP datagram is transit traffic and decrements the TTL. Because the TTL is now 0, the IP router discards the IP datagram and sends back an ICMP Time Exceeded-TTL Exceeded in Transit message to the sending host with the source IP address set to the IP address of the interface on which the ICMP Echo was received. The interface on which the ICMP Echo was received is the near-side interface, the interface that is the smallest number of hops from the sending host.
  10. After receipt of the ICMP Time Exceeded-TTL Exceeded in Transit message, the Tracert utility records the round-trip time and the source IP address.
  11. Tracert sends two more ICMP Echo messages and records their round-trip time.

This process continues until the destination is reached and replies with ICMP Echo Reply messages.

The Tracert utility records the series of near-side router interfaces in the path from the sending host to a destination. By default, Tracert also performs a DNS reverse query on each near-side router interface and displays the host name corresponding to the IP address. You can prevent this behavior and speed up the completion of Tracert by using the -d option.

If a router silently discards packets with an expired TTL, Tracert shows a series of * characters for that hop. If ICMP packet filtering is occurring on a near-side router interface, that router and all subsequent routers show the * character until 30 hops are attempted (the default).

Network Monitor Example

The following frames from a Network Monitor trace (Capture 08-06 in the \Captures folder on the companion CD-ROM) summarize a typical use of the Tracert utility to trace the route to a destination IP address. In this case, Tracert is used to trace the path across two routers, and the -d option is used to simplify the process and the display. The summarized frames have been indented for readability.

Frame	Time	Src MAC Addr	Dst MAC Addr	Protocol	Description

1	1.241	0060083E4607	00502AB9A440	ICMP	Echo, From
                157.59.11.19 To 157.59.224.33

2	1.241	00502AB9A440	0060083E4607	ICMP	Time Exceeded
                while trying to deliver to
                157.59.224.33 See frame 1

3	1.242	0060083E4607	00502AB9A440	ICMP	Echo, From
                157.59.11.19 To 157.59.224.33

4	1.242	00502AB9A440	0060083E4607	ICMP	Time Exceeded
                while trying to deliver to
                157.59.224.33  See frame 3

5	1.260	0060083E4607	00502AB9A440	ICMP	Echo, From
                157.59.11.19 To 157.59.224.33

6	1.260	00502AB9A440	0060083E4607	ICMP	Time Exceeded
                while trying to deliver to
                157.59.224.33  See frame 5

7	2.263	0060083E4607	00502AB9A440	ICMP	Echo, From
                157.59.11.19 To 157.59.224.33

8	2.263	00502AB9A440	0060083E4607	ICMP	Time Exceeded
                while trying to deliver to
                157.59.224.33  See frame 7

9	2.264	0060083E4607	00502AB9A440	ICMP	Echo, From
                157.59.11.19 To 157.59.224.33

10	2.265	00502AB9A440	0060083E4607	ICMP	Time Exceeded
                while trying to deliver to
                157.59.224.33  See frame 9

11	2.265	0060083E4607	00502AB9A440	ICMP	Echo, From
                157.59.11.19 To 157.59.224.33

12	2.266	00502AB9A440	0060083E4607	ICMP	Time Exceeded
                while trying to deliver to
                157.59.224.33  See frame 11

13	3.264	0060083E4607	00502AB9A440	ICMP	Echo, From
                157.59.11.19 To 157.59.224.33

14	3.265	00502AB9A440	0060083E4607	ICMP	Echo Reply, To
                157.59.11.19 From 157.59.224.33

15	3.266	0060083E4607	00502AB9A440	ICMP	Echo, From
                157.59.11.19 To 157.59.224.33

16	3.267	00502AB9A440	0060083E4607	ICMP	Echo Reply, To
                157.59.11.19 From 157.59.224.33

17	3.268	0060083E4607	00502AB9A440	ICMP	Echo, From
                157.59.11.19 To 157.59.224.33

18	3.268	00502AB9A440	0060083E4607	ICMP	Echo Reply, To
                157.59.11.19 From 157.59.224.33

Frames 1 through 6 are the first hop. In Frames 1, 3, and 5, the IP header's TTL is set to 1. The local router decrements the TTL to 0 and sends back ICMP Time Exceeded-TTL Exceeded in Transit messages (Frames 2, 4, and 6).

Frames 7 through 12 are the second hop. In Frames 7, 9, and 11, the IP header's TTL is set to 2. The second router in the path decrements the TTL to 0 and sends back the ICMP Time Exceeded-TTL Exceeded in Transit messages (Frames 8, 10, and 12).

Frames 13 through 18 reach the destination. In Frames 13, 15, and 17, the IP header's TTL is set to 3, which is an adequate TTL to reach a destination two routers away. The destination sends back the appropriate Echo Reply messages (Frames 14, 16, and 18).

The round-trip times reflected in the Tracert display are not necessarily the same round-trip times for normal traffic. Most routers process ICMP errors and messages at a lower priority. Therefore, the round-trip times reflected in the Tracert display might be larger than the round-trip times for normal traffic. Additionally, it is possible for network conditions and the path to change during the route-tracing process, giving misleading results.

Tracert Options

Table 8-7 lists the use and default values of Tracert utility options.

Table 8-7. Tracert Utility Options
Option | Use | Default
-d | Instructs Tracert to not perform a DNS reverse query on every router IP address. If the host name of each router is unimportant, using the -d option speeds up the Tracert display of the path. | Performs DNS reverse queries on each router IP address
-h max_hops | Instructs Tracert to increment the TTL up to max_hops. | 30
-j host-list | Sends the ICMP Echo messages using the loose source route specified in the host-list. The host list is up to nine IP addresses separated by spaces corresponding to the loose source route to the destination. This switch is valid only for IPv4 traffic. | Not used
-w timeout | Waits the specified amount of time in milliseconds for the response before displaying a *. | 4000
-R | Forces Tracert to trace the round-trip path by sending the ICMPv6 Echo Request message to the destination and including an IPv6 Routing extension header with the next destination of the sending node. This switch is valid only for IPv6 traffic. | Not used
-S sourceaddr | Forces Tracert to use a specified source address. This switch is valid only for IPv6 traffic. | Not used
-4 | Forces Tracert to use an IPv4 address when the DNS name query for a host name returns both IPv4 and IPv6 addresses. | Not used
-6 | Forces Tracert to use an IPv6 address when the DNS name query for a host name returns both IPv4 and IPv6 addresses. | Not used


Pathping Utility

The Pathping command-line utility for the Windows Server 2003 family is used to test router and link latency and packet losses for both IPv4 and IPv6. For IPv4, Pathping works by sending successive ICMP Echo messages to each point in the path and recording the following: the average round-trip time, the packet loss when sending ICMP Echo messages to each router, and the packet loss when sending ICMP Echo messages across the links between each router.

The following is an example of the display of the Pathping utility:

C:\>pathping 10.10.2.99

Tracing route to 10.10.2.99 over a maximum of 30 hops

  0  10.0.1.100
  1  10.0.1.1
  2  192.168.1.2
  3  172.16.1.2
  4  10.10.2.99

Computing statistics for 100 seconds...

            Source to Here   This Node/Link

Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           10.0.1.100
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  10.0.1.1
                                0/ 100 =  0%   |
  2    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.1.2
                                0/ 100 =  0%   |
  3    0ms     0/ 100 =  0%     0/ 100 =  0%  172.16.1.2
                                0/ 100 =  0%   |
  4    1ms     0/ 100 =  0%     0/ 100 =  0%  10.10.2.99

Trace complete.

In this example, Pathping is sending ICMP Echo messages from a sending host (10.0.1.100) to a destination host (10.10.2.99) across three routers (10.0.1.1, 192.168.1.2, and 172.16.1.2). Pathping first resolves the path using the same method as Tracert. Next, Pathping sends ICMP Echo messages to each near-side router interface and to the destination (in the path order), and repeats this process 99 times. In this example, the Tracert utility sends an ICMP Echo message to 10.0.1.1, then to 192.168.1.2, then to 172.16.1.2, then to the destination, 10.10.2.99. This process is repeated 99 times so that 100 ICMP Echo messages are sent to each near-side router interface in the path and the destination. From the responses (and lack of responses), Pathping accumulates statistics for the following:

  • Packet losses for packets sent on the link between the source host (10.0.1.100) and the first router (10.0.1.1)
  • Packet losses and average round-trip times for packets sent to the first router in the path (with the near-side interface of 10.0.1.1)
  • Packet losses for packets sent on the link between the first router (10.0.1.1) and the second router in the path (with the near-side interface of 192.168.1.2)
  • Packet losses and average round-trip times for packets sent to the second router in the path (192.168.1.2)
  • Packet losses for packets sent on the link between the second router (192.168.1.2) and the third router in the path (with the near-side interface of 172.16.1.2)
  • Packet losses and average round-trip times for packets sent to the third router in the path (172.16.1.2)
  • Packet losses for packets sent on the link between the third router (172.16.1.2) and the destination (10.10.2.99)
  • Packet losses and average round-trip times for packets sent to the destination (10.10.2.99)

The Source To Here column displays the average round-trip time and packet loss for packets destined to a specific IP address. These packets must be processed as the destination and an ICMP Echo Reply message must be constructed and sent. The This Node/Link column displays the packet loss for packets that are either traveling across a link (as indicated by | in the Address column), across a router (as indicated by an intermediate router IP address in the Address column), or to the destination (as indicated by the destination IP address in the Address column). Packets sent across a router are typically forwarded using an optimized forwarding process that is much faster than responding as the destination of an ICMP Echo Reply message.

Network Monitor Capture 08-07 (in the \Captures folder on the companion CD-ROM) contains the traffic of the Pathping utility for this example.

Pathping Options

Table 8-8 lists the use and default values of Pathping utility options.

Table 8-8. Pathping Utility Options
Option | Use | Default
-n | Instructs Pathping to not perform a DNS reverse query on every router IP address. If the host name of each router is unimportant, the -n option accelerates the Pathping display of the path. | Performs DNS reverse queries on each router IP address
-h max_hops | Instructs Pathping to increment the TTL up to max_hops. | 30
-g host-list | Sends the ICMP Echo messages using the loose source route specified in the host-list. The host list is up to nine IP addresses separated by spaces corresponding to the loose source route to the destination. | Not used
-p period | Waits the specified amount of time in milliseconds between successive Echo messages. | 250
-q num_queries | Sends the num_queries number of queries for each hop. | 100
-w timeout | Waits the specified amount of time in milliseconds for the response. | 3000
-4 | Forces Pathping to use an IPv4 address when the DNS name query for a host name returns both IPv4 and IPv6 addresses. | Not used
-6 | Forces Pathping to use an IPv6 address when the DNS name query for a host name returns both IPv4 and IPv6 addresses. | Not used


Summary

ICMP is a set of messages that provides services that are not part of IP. ICMP includes the following services: diagnostic (Echo and Echo Reply messages), delivery error reporting (Destination Unreachable, Time Exceeded, Source Quench, and Redirect messages), router discovery (Router Advertisement and Router Solicitation messages), IP header problems (Parameter Problem message), and address mask discovery (Address Mask Request and Address Mask Reply messages). The ICMP Destination Unreachable-Fragmentation Needed And DF Set message is used for PTMU Discovery. The Ping, Tracert, and Pathping utilities provided with the Windows Server 2003 family use ICMP messages to provide diagnostic functionality.


Internet Group Management Protocol (IGMP)

Chapter 9
Internet Group Management Protocol (IGMP)

Historically, data transfer services used one-to-one delivery, using unicast addressing and routing across an IP internetwork. The utility of one-to-many delivery across an IP internetwork has recently become an interesting and cost-effective way to deliver audio, video, and other types of content to multiple destinations. One-to-many delivery service requires hosts to inform local routers of their interest in receiving the traffic so that routers can forward the traffic to the network segments of the listening hosts.


Introduction to IP Multicast and IGMP

IP multicast provides an efficient one-to-many delivery service. To achieve one-to-many delivery using IP unicast traffic, each datagram needs to be sent multiple times. To achieve one-to-many delivery using IP broadcast traffic, a single datagram is sent, but all nodes process it, even those that are not interested. Broadcast delivery service is unsuitable for internetworks, as routers are designed to prevent the spread of broadcast traffic. With IP multicast, a single datagram is sent and forwarded across routers only to the network segments containing nodes that are interested in receiving it.

Historically, IP multicast traffic has been little utilized. However, recent developments in audio and video teleconferencing, distance learning, and data transfer to a large number of hosts have made IP multicast traffic more important.

RFCs 1112 and 2236 describe IP multicast and the Internet Group Management Protocol (IGMP). These RFCs can be found in the \Rfc folder on the companion CD-ROM.

IP Multicasting Overview

The following are the essential details of IP multicast operation:

  • All multicast traffic is sent to a class D address in the range 224.0.0.0 through 239.255.255.255 (224.0.0.0/4). All traffic in the range 224.0.0.0 through 224.0.0.255 (224.0.0.0/24) is for the local subnet and is not forwarded by routers. Multicast-enabled routers forward multicast traffic in the range 224.0.1.0 through 239.255.255.255 with an appropriate Time to Live (TTL).
  • A specific multicast address is called a group address.
  • The set of hosts that listen for multicast traffic at a specific group address is called a multicast group or host group. Multicast group members can receive traffic to their unicast address and the group address. Multicast groups can be permanent or transient. A permanent group is assigned a well-known group address. An example of a permanent group is the all-hosts multicast group, listening for traffic on the well-known multicast address of 224.0.0.1. The membership of a permanent group is transient; only the group address is permanent.
  • There are no limits on a multicast group's size.
  • A host can send multicast traffic to the group address without belonging to the multicast group.
  • There are no limits to how many multicast groups to which a host can belong.
  • There are no limits on when members of a multicast group can join and leave a multicast group.
  • There are no limits on the location of multicast group members.

IP multicast must be supported by the hosts and the routers of an IP internetwork.

Host Support

To support IP multicast, hosts must be able to send and receive IP multicast traffic. RFC 1112 defines three levels of IP multicast support for hosts as follows:

  • Level 0 No support for sending or receiving IP multicast traffic
  • Level 1 Support for sending IP multicast traffic
  • Level 2 Support for sending and receiving IP multicast traffic

The IP multicast support level is controlled through the following registry setting:

IGMPLevel

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value Type: REG_DWORD

Valid Range: 0-2

Default: 2

Present by Default: No

By default, TCP/IP for the Windows Server 2003 family supports Level 2 IP multicasting.

Sending IP Multicast Traffic

A host sending an IP multicast packet must first determine the IP multicast address. The IP multicast address is determined by either the application or protocol (a well-known or reserved IP multicast address), or obtained from a server allocating unique IP multicast addresses. Multicast Address Dynamic Client Allocation Protocol (MADCAP) is an extension to the Dynamic Host Configuration Protocol (DHCP) standard that is used to obtain a unique IP multicast address. Multicast scopes configured on the DHCP server define ranges of IP multicast addresses. Similar to allocating unicast IP addresses, unique IP multicast addresses are allocated to a single DHCP client. If multiple hosts use the same IP multicast address for different applications, the wrong traffic could be forwarded to host group members. For more information on multicast support by the DHCP service in the Windows Server 2003 family, see Chapter 16, "Dynamic Host Configuration Protocol (DHCP) Server Service."

After determining the destination IP multicast address, the sending host must construct the IP datagram with its own IP address as the source IP address, the intended IP multicast address as the destination IP address, and an appropriate TTL value. For local subnet IP multicast traffic destined for addresses in the range 224.0.0.0 through 224.0.0.255 (224.0.0.0/24), the TTL is set to 1. Routers do not forward IP multicast traffic in this range even if the TTL is greater than 1. For nonlocal subnet traffic, the TTL should be set to a value that is high enough to reach all host group members. Table 9-1 lists the recommended values of the TTL for IP multicast traffic and their scope.

Table 9-1. Recommended Values of the TTL for IP Multicast Traffic
TTL Value | Description
0 | Restricted to the same host
1 | Restricted to the same subnet
15 | Restricted to the same site
63 | Restricted to the same region
127 | Worldwide
191 | Worldwide; limited bandwidth
255 | Unrestricted

Once the sending host constructs the IP multicast datagram, the IP packet is passed through the IP forwarding process. The multicast entry in the IP routing table (the route(s) with the destination of 224.0.0.0 and the network mask of 240.0.0.0) informs IP that the datagram must be forwarded to the destination IP address, using the local network interface. The IP datagram, the forwarding IP address, and the interface are submitted to the Address Resolution Protocol (ARP).

The ARP module checks the forwarding IP address. Because the forwarding IP address is in the range 224.0.0.0 through 239.255.255.255 (224.0.0.0/4), ARP bypasses the process of checking the ARP cache and sending a broadcast ARP Request frame. For Ethernet and Fiber Distributed Data Interface (FDDI) hosts, the destination IP address is mapped to the destination media access control (MAC) address using the process described in Chapter 6, "Internet Protocol (IP) Addressing." For Token Ring hosts, all IP multicast traffic is addressed to the Token Ring functional address of 0xC0-00-00-04-00-00 unless otherwise specified with the TrFunctionalMcastAddress registry setting.

Receiving IP Multicast Traffic

To receive IP multicast traffic, a host informs the IP layer to process traffic for a specific group address. To facilitate the request, the IP module does the following:

  • Informs the Network Interface Layer technology to add the MAC-level multicast address that corresponds to the group address to the list of interesting destination MAC addresses. In the Windows Server 2003 family, the IP module within the TCP/IP protocol uses the NDISRequest( ) function.
  • If the group address is not in the range 224.0.0.1 through 224.0.0.255 (224.0.0.0/24), an IGMP Host Membership Report message is sent to inform local routers to forward the host group traffic to the network segment of the listening host.

If there are multiple applications on the host using the same group address, IP tracks application group membership and passes a copy of the received IP multicast datagram to each listening application. For a multihomed host, IP tracks group membership for each network segment.

Router Support

To support IP multicast forwarding and routing, a router must be able to do the following:

  • Listen for IGMP Host Membership Report messages sent from hosts on local network segments.
  • Track and maintain group membership for hosts on local network segments. Routers maintain host group membership through the receipt of IGMP Host Membership Report messages and the sending of IGMP Host Membership Query messages.
  • In a multicast-enabled intranet with more than two routers, a router must be able to communicate host group membership information to neighboring routers. This is done using a multicast routing protocol such as Distance Vector Multicast Routing Protocol (DVMRP), Multicast Extensions to Open Shortest Path First (MOSPF), or Protocol Independent Multicast (PIM).
  • Listen for all IP multicast traffic on all attached network segments. To do this, the router must put the network interface into either promiscuous listening mode or multicast promiscuous listening mode. In promiscuous mode, all incoming frames are considered interesting and passed to upper layers for processing. Promiscuous mode is a processor and interrupt-intensive listening mode typically used only for protocol analysis or network sniffing.

    Multicast promiscuous mode is a special listening mode in which all packets with the Individual/Group (I/G) bit set in the destination MAC address are considered interesting. The I/G bit is also known as the multicast bit. For Ethernet frames, the multicast bit is the last bit of the first byte in the destination MAC address. In multicast promiscuous mode, all frames with the multicast bit set and a valid Frame Check Sequence (FCS) field are passed up to the operating system for processing. See Chapter 1, "Local Area Network (LAN) Technologies," for more information on the multicast bit. In multicast promiscuous mode, an IP multicast router receives a copy of every IP multicast packet for processing or forwarding. Not all network adapters support multicast promiscuous mode. A network adapter that supports promiscuous mode might not support multicast promiscuous mode.

  • Forward IP multicast traffic with a valid TTL on appropriate network segments where there are host group members or where there are downstream routers that have host group members. The IP multicast forwarding capability is provided by the TCP/IP protocol. Similar to unicast forwarding, when IP multicast forwarding is enabled, the TTL of the packet being forwarded is decremented, and is then forwarded over the appropriate interfaces based on the entries in a local multicast forwarding table. IP silently discards multicast traffic with a TTL of 0.

    IP multicast traffic is forwarded to network segments that have either a listening host or a router that has informed the router forwarding the IP multicast traffic that there are host group members downstream. The entries in the IP multicast forwarding table do not indicate which hosts are listening or how many group members there are on a network segment—only that at least one host member is present on the network segment (or a downstream network segment).

The Multicast-Enabled IP Internetwork

Figure 9-1 shows a multicast-enabled intranet. To support the forwarding of IP multicast traffic from any host to any group member, hosts and routers must support the following criteria:

  • Any host receiving IP multicast traffic joins the multicast group by sending IGMP Host Membership Report messages on the local network segment.
  • Any host sending IP multicast traffic forms the IP multicast frame and sends it on the local network segment.
    Figure 9-1. A multicast-enabled intranet showing multicast-enabled hosts and routers.
  • IP multicast routers forward the IP multicast traffic from the originating network segment to all segments where there are group members. IGMP Host Membership Report messages inform the routers about group members on locally attached network segments. For downstream host members, IP multicast routers communicate downstream host member information using multicast routing protocols. In both cases, IGMP and multicast routing protocols update the router's local TCP/IP multicast forwarding tables.

The Internet's Multicast-Enabled Backbone

The portion of the Internet that is IP-multicast-enabled is known as the multicast backbone (MBONE). The MBONE was originally created to multicast the audio for Internet Engineering Task Force (IETF) meetings for members who could not attend. Today, the MBONE is used for the audio and video of IETF meetings, launches of the National Aeronautic and Space Administration (NASA) space shuttle, and teleconferences of all kinds. The MBONE is also the testbed for the development of IP multicast technology such as applications, tools, and routing protocols.

The MBONE is a logical IP multicast topology overlaid on the Internet's physical unicast topology. Not all Internet portions and Internet service providers (ISPs) support the forwarding of IP multicast traffic. To connect two portions of the Internet that support IP multicast traffic, IP multicast traffic is tunneled or wrapped with another IP header addressed from one router to another router. The typical tunneling is called IP-in-IP tunneling, described in RFC 1853. The MBONE is a series of multicast-enabled islands connected together with IP-in-IP tunnels.

IP-in-IP tunneling is described in RFC 1853, which can be found in the \Rfc folder on the companion CD-ROM.


IGMP Message Structure

IGMP is the protocol used to maintain local subnet host group membership, and it is required for hosts that support Level 2 IP multicasting. IGMP messages are sent as IP datagrams with the IP Protocol field set to 2. Therefore, an IGMP message is encapsulated with an IP header. The resulting IP datagram is then encapsulated with the appropriate Network Interface Layer header and trailer. Figure 9-2 shows the resulting frame.

Figure 9-2. IGMP message encapsulation showing the IP header and Network Interface Layer header and trailer.

In the IP header of IGMP messages, the Source IP Address field is set to the router or host interface that sent the IGMP message; the Destination IP Address field depends on the type of IGMP message.

IGMP Version 1 (IGMPv1)

IGMPv1 defines two types of IGMP messages: the Host Membership Report and the Host Membership Query.

IGMPv1 is described in Appendix I of RFC 1112, which can be found in the \Rfc folder on the companion CD-ROM.

Host Membership Report

A host sends a Host Membership Report message to inform local routers that the host wants to receive IP multicast traffic at a specified group address. A host also sends a Host Membership Report in response to a Host Membership Query message sent by a router. Host Membership Report messages are sent, with a TTL of 1, to the destination IP address of the multicast group.

Host Membership Query

A router sends a Host Membership Query message to poll a network segment and verify that there are hosts still listening for IP multicast traffic. Host Membership Query messages are sent, with a TTL of 1, to the destination IP address of the all-hosts IP multicast address (224.0.0.1). An IGMPv1 Host Membership Query is a general query, attempting to identify all multicast groups being listened to by hosts on a network segment.

Hosts that receive the Host Membership Query message send a Host Membership Report message for all the host groups for which they are members. To prevent an avalanche of response traffic, host group members choose a random report delay time for each host group and wait to hear from other host group members on the network segment. If another host group member sends a Host Membership Report message, the waiting host does not send a reply.

This behavior is consistent with the information kept by multicast routers. A multicast router does not track which hosts on a network segment are members of a host group, only that there is at least one host group member.

If no hosts respond with a Host Membership Report to a group address that the multicast router is tracking for the network segment, the multicast router can remove that entry from the multicast forwarding table and inform other multicast routers through multicast routing protocols. Multicast traffic to the removed group address is no longer forwarded to the network segment.

IGMPv1 Message Structure

Figure 9-3 shows the structure of the IGMPv1 message.

Figure 9-3. The structure of the IGMPv1 message.

The fields in the IGMPv1 header are defined as follows:

  • Version A 4-bit field set to 1 to indicate IGMPv1.
  • Type A 4-bit field that indicates the type of IGMP message. Set to 1 for a Host Membership Query. Set to 2 for a Host Membership Report.
  • Unused A 1-byte field zeroed by the sender and ignored by the receiver.
  • Checksum A 2-byte field that stores the checksum on the 8-byte IGMP message.
  • Group Address A 4-byte field that for a Host Membership Report stores the multicast group address being joined by the listening host. In a Host Membership Query, the Group Address field is 0.0.0.0.

Table 9-2 summarizes the addresses used in IGMPv1 Host Membership Report and Host Membership Query messages.

Table 9-2. Addresses Used in IGMPv1 Messages
 | Host Membership Report | Host Membership Query
Source IP Address (IP header) | Host IP Address | Router IP Address
Destination IP Address (IP header) | Group IP Address | 224.0.0.1
Group Address | Group IP Address | 0.0.0.0

Network Monitor Examples

The following Network Monitor trace (Capture 09-01 in the \Captures folder on the companion CD-ROM) is an IGMPv1 Host Membership Report message for a host joining the host group 224.0.1.41:

+ FRAME: Base frame properties

  ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

            ETHERNET: Destination address : 01005E000129

                ETHERNET: .......1 = Group address

                ETHERNET: ......0. = Universally administered address

        +	ETHERNET: Source address : 00C04FD7BAEC

            ETHERNET: Frame Length : 60 (0x003C)

            ETHERNET: Ethernet Type : 0x0800 (IP:  DOD Internet Protocol)

            ETHERNET: Ethernet Data: Number of data bytes remaining = 46 (0x002E)

    IP:	ID = 0xB201; Proto = IGMP; Len: 28

            IP: Version = 4 (0x4)

            IP: Header Length = 20 (0x14)

            IP: Precedence = Routine

            IP: Type of Service = Normal Service

            IP: Total Length = 28 (0x1C)

            IP: Identification = 45569 (0xB201)

        +	IP: Flags Summary = 0 (0x0)

            IP: Fragment Offset = 0 (0x0) bytes

            IP: Time to Live = 1 (0x1)

            IP: Protocol = IGMP - Internet Group Management

            IP: Checksum = 0x118E

            IP: Source Address = 10.0.11.40

            IP: Destination Address = 224.0.1.41

            IP: Data: Number of data bytes remaining = 8 (0x0008)

            IP: Padding: Number of data bytes remaining = 18 (0x0012)

    IGMP: Version 1 Membership Report

            IGMP: Type = Version 1 Membership Report

            IGMP: Unused = 0 (0x0)

            IGMP: Checksum = 0x0CD6

            IGMP: Group Address = 224.0.1.41

Note that the group address of 224.0.1.41 is being mapped to the Ethernet destination address of 01-00-5E-00-01-29 (41 in hexadecimal is 0x29). Also note that IGMP messages must be padded with 18 padding bytes on Ethernet networks to adhere to the Ethernet minimum payload size of 46 bytes (padding bytes not shown).

The following Network Monitor trace (Capture 09-02 in the \Captures folder on the companion CD-ROM) is an IGMPv1 Host Membership Query message:

+	FRAME: Base frame properties

    ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

        ETHERNET: Destination address : 01005E000001

            ETHERNET: .......1 = Group address

            ETHERNET: ......0. = Universally administered address

    +	ETHERNET: Source address : 00E034C0A060

        ETHERNET: Frame Length : 60 (0x003C)

        ETHERNET: Ethernet Type : 0x0800 (IP:  DOD Internet Protocol)

        ETHERNET: Ethernet Data: Number of data bytes remaining = 46 (0x002E)

    IP:	ID = 0x0; Proto = IGMP; Len: 28

            IP: Version = 4 (0x4)

            IP: Header Length = 20 (0x14)

            IP: Precedence = Internetwork Control

            IP: Type of Service = Normal Service

            IP: Total Length = 28 (0x1C)

            IP: Identification = 0 (0x0)

        +	IP: Flags Summary = 0 (0x0)

            IP: Fragment Offset = 0 (0x0) bytes

            IP: Time to Live = 1 (0x1)

            IP: Protocol = IGMP - Internet Group Management

            IP: Checksum = 0xC71E

            IP: Source Address = 10.0.8.1

            IP: Destination Address = 224.0.0.1

            IP: Data: Number of data bytes remaining = 8 (0x0008)

            IP: Padding: Number of data bytes remaining = 18 (0x0012)

  IGMP: Membership Query

            IGMP: Type = Membership Query

            IGMP: Max Resp Time = 100 (0x64)

            IGMP: Checksum = 0xEE9B

            IGMP: Group Address = 0.0.0.0

Notice that for both traces, the IP header's TTL field is set to 1.

IGMP Version 2 (IGMPv2)

IGMPv2 provides additional capabilities to help multicast routers converge a multicast group to the set of hosts listening for traffic. IGMPv2 is backward compatible with IGMPv1.

The additional capabilities of IGMPv2 are as follows:

  • The Leave Group message
  • The Group-Specific Query message
  • The election of a multicast querier
  • The IGMPv2 Host Membership Report message
IGMPv2 is described in RFC 2236, which can be found in the \Rfc folder on the companion CD-ROM.

The Leave Group Message

With IGMPv1, if a host leaves a specific multicast group and it is the last member of the multicast group for that subnet, the local router is not explicitly informed. The router maintains the entry in its multicast forwarding table and continues to forward multicast traffic to the host's subnet. Only after the router sends a Host Membership Query message and receives no response for the multicast group does the router recognize that there are no more hosts on that network segment for that group address. The router then updates its multicast forwarding table, discontinues forwarding IP multicast traffic to the network segment, and informs neighboring routers of the new state. This can lead to long leave latency times. During the leave latency time, multicast traffic is forwarded to network segments that do not contain group members.

During the periodic polling process, when an IGMPv2 host responds to a membership query, it assumes that it is potentially the last member in the group for that subnet because no other hosts responded before it. If that host leaves the group, it sends an IGMP Leave Group message to the all-routers IP multicast address. To ensure that the host leaving is truly the last host in the group for the subnet, the multicast router sends a series of group-specific membership queries. If the multicast router receives a response from another host for that group, the router maintains the group membership state for that group on that subnet. If the multicast router does not receive any responses, it can prevent the forwarding of traffic to that group to the subnet. If there are host members on downstream subnets available across subnet routers, multicast traffic for the group is still forwarded to the subnet.

The Group-Specific Query Message

In the case of IGMPv2, two different types of Host Membership Query messages are defined: the General Query and the Group-Specific Query. The General Query is the same as the IGMPv1 Host Membership Query. The Group-Specific Query is designed to check for host membership in a specific group. In the Group-Specific Query, the IP header's destination IP address and the IGMP header's group address are set to the group address being queried.

The Multicast Querier

IGMPv2 supports the election of a multicast querier, a single router per network segment that sends Host Membership Query messages. With IGMPv1, the designation of a single multicast router to perform queries is a function of the multicast routing protocol. Because all IGMP traffic is sent to multicast addresses, every multicast router on a network segment receives all IGMP messages. Therefore, only a single router is needed to send queries.

The IGMPv2 multicast querier election is simple: A router assumes that it is the multicast querier until it receives a Host Membership Query (either General or Group-Specific) from another router with a numerically lower IP address. If it is the only router on a subnet and it does not receive a query from another router in an interval called the Other Querier Present Interval (by default set for 255 seconds), the router becomes the querier for that network.

IGMPv2 Message Structure

Figure 9-4 shows the structure of the IGMPv2 message.

Figure 9-4. The structure of the IGMPv2 message.

The IGMPv2 header contains the following fields:

  • Type IGMPv2 combines the IGMPv1 4-bit Version field and IGMPv1 4-bit Type field into a single 8-bit Type field. Table 9-3 lists the Type field values.
    Table 9-3. Values of the IGMPv2 Type Field
    Type Message

    17 (0x11)

    Host Membership Query The previous Version 0x1 and Type 0x1 are combined to form 0x11, or 17.

    18 (0x12)

    IGMPv1 Host Membership Report The previous Version 0x1 and Type 0x2 are combined to form 0x12, or 18.

    22 (0x16)

    IGMPv2 Host Membership Report The IGMPv2 Host Membership Report has the same function as the IGMPv1 Host Membership Report and is intended to be received by only IGMPv2-capable multicast routers.

    23 (0x17)

    Leave Group Message

  • Maximum Response Time The IGMPv1 Unused field is used in IGMPv2 Membership Query messages (either General or Group-Specific) to store a maximum time in tenths of a second within which a host must respond to the query. The maximum response time becomes the maximum value of the report delay timer for subnet host members.
  • Checksum A 2-byte field that stores a checksum on the 8-byte IGMP message.
  • Group Address Set to 0.0.0.0 for the general Host Membership Query and set to the specific group address for all other IGMPv2 message types.

Table 9-4 summarizes the addresses used in IGMPv2 Group-Specific Host Membership Query and Group Leave messages.

Table 9-4. Addresses Used in IGMPv2 Messages
 | Group-Specific Query | Group Leave
Source IP Address (IP header) | Router IP Address | Host IP Address
Destination IP Address (IP header) | Group IP Address | 224.0.0.2
Group Address | Group IP Address | Group IP Address

Network Monitor Example

The following Network Monitor trace (Capture 09-03 in the \Captures folder on the companion CD-ROM) shows an IGMPv2 Host Membership Report message for a host registering the group address 239.255.255.252:

+	Frame: Base frame properties

    ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

            ETHERNET: Destination address : 01005E7FFFFC

                ETHERNET: .......1 = Group address

                ETHERNET: ......0. = Universally administered address

        +	ETHERNET: Source address : 0060083E4607

            ETHERNET: Frame Length : 46 (0x002E)

            ETHERNET: Ethernet Type : 0x0800 (IP:  DOD Internet Protocol)

            ETHERNET: Ethernet Data: Number of data bytes remaining = 32 (0x0020)

    IP:	ID = 0x1A26; Proto = IGMP; Len: 32

            IP: Version = 4 (0x4)

            IP: Header Length = 24 (0x18)

            IP: Precedence = Routine

            IP: Type of Service = Normal Service

            IP: Total Length = 32 (0x20)

            IP: Identification = 6694 (0x1A26)

            IP: Flags Summary = 0 (0x0)

                IP: .......0 = Last fragment in datagram

                IP: ......0. = May fragment datagram if necessary

            IP: Fragment Offset = 0 (0x0) bytes

            IP: Time to Live = 1 (0x1)

            IP: Protocol = IGMP - Internet Group Management

            IP: Checksum = 0x07ED

            IP: Source Address = 10.1.8.200

            IP: Destination Address = 239.255.255.252

            IP: Option Fields

                IP: Unrecognized Option

                    IP: Option Type = 0x94

                    IP: Option Length = 4 (0x4)

                    IP: Option data: Number of data bytes remaining = 2 (0x0002)

            IP: Data: Number of data bytes remaining = 8 (0x0008)

                 IP: Padding: Number of data bytes remaining = 14 (0x000E)

    IGMP: Version 2 Membership Report

            IGMP: Type = Version 2 Membership Report

            IGMP: Unused = 0 (0x0)

            IGMP: Checksum = 0xFA02

            IGMP: Group Address = 239.255.255.252

Notice the existence of the IP Router Alert option (Option Type 0x94) that is used to inform the router that further processing of the IP header is required. For more information on the IP Router Alert option, see Chapter 5, "Internet Protocol (IP) Basics."

IGMP Version 3 (IGMPv3)

IGMPv3 supports multicast source-specific reports and queries. With IGMPv1 and IGMPv2, multicast group members report membership and routers query for membership without regard to the source of the multicast traffic. IGMPv3 allows you to have multiple sources for multicast traffic, which can be beneficial when you are multicasting a video session across an enterprise organization. Rather than having a single source of the multicast packets that comprise the video broadcast, you can have multiple sources distributed regionally. Then, multicast hosts can join the group and specify a multicast source that is topologically closest to them (a regional source).

IGMPv3 is described in RFC 3376, which is available in the \RFC folder of the companion CD-ROM.

When an IGMPv3 host sends a Host Membership Report message, it can specify the multicast group and either the list of multicast sources from which the host can receive the multicast packets (the include list) or a list of the multicast sources from which the host must not receive multicast packets (the exclude list). Multicast routers and multicast routing protocols use the list of sources to include or exclude in the IGMPv3 Host Membership Report message to promote the forwarding of multicast packets from included sources and prevent the forwarding and delivery of multicast packets from excluded sources.

In IGMPv3, the Host Membership Query message is modified to allow an IGMPv3 router to send source- and-group-specific queries. An IGMPv3 host uses a new Host Membership Report message to send source-specific reports.

IGMPv3 Host Membership Query

The IGMPv3 Host Membership Query message is for a group- and source-specific query, sent by an IGMPv3 router to determine if there are any group members in the indicated group address for traffic from one of the sources in the source list. The IGMPv3 Host Membership Query message uses the same IGMP Type number (0x11) and has the same format as the IGMPv2 Host Membership Query message. However, there are additional fields after the Group Address field that allow the router to specify querying parameters and list the sources of the multicast group being queried. These additional fields are only included for an IGMPv3 group- and source-specific query.

Beyond the Group Address field, the IGMPv3 Host Membership Query message contains the following fields:

  • Reserved A 4-bit field set to 0 by the sender that is ignored by the receiver.
  • Suppress Router-Side Processing A 1-bit field that, when set to 1, indicates that receiving routers are to suppress normal processing when receiving a query message.
  • Querier's Robustness Variable A 3-bit field that indicates the robustness variable of the sending router. The robustness variable is a measure of how many IGMP packets can be lost without recovery. IGMP can recover from Querier's Robustness Variable - 1 lost IGMP packets.
  • Querier's Query Interval A 1-byte field that indicates the number of seconds between query messages of the sending router.
  • Number Of Sources A 2-byte field that indicates the number of source addresses included in the message.
  • Source Address A 4-byte field that indicates the unicast IP address of a multicast source.

Figure 9-5 shows the structure of the IGMPv3 Host Membership Query message.

Figure 9-5. The structure of the IGMPv3 Host Membership Query message.

IGMPv3 Host Membership Report

The IGMPv3 Host Membership Report message contains one or more group records and is sent to the multicast address 224.0.0.22, a reserved multicast address for all IGMPv3-capable multicast routers. Each group record contains the group address and the list of sources to either include or exclude.

The IGMPv3 Host Membership Report message contains the following fields:

  • Type A 1-byte field set to 0x22 to indicate an IGMPv3 Host Membership Report message.
  • Reserved A 1-byte field set to 0 by the sender and ignored by the receiver.
  • Checksum A 2-byte field that stores a checksum on the IGMPv3 message.
  • Reserved A 2-byte field set to 0 by the sender and ignored by the receiver.
  • Number Of Records A 2-byte field that indicates the number of group records contained in the message.
  • Group Record A variable-sized field that contains a multicast address on which the sending host is listening and either an include list or exclude list of sources.

Figure 9-6 shows the structure of the IGMPv3 Host Membership Report message.

Figure 9-6. The structure of the IGMPv3 Host Membership Report message.

The IGMPv3 Host Membership Report message group record contains the following fields:

  • Record Type A 1-byte field that indicates the type of group record and whether the list of sources is an inclusion or exclusion list.
  • Auxiliary Data Length A 1-byte field that indicates the number of bytes of auxiliary data included in the group record.
  • Number Of Sources A 2-byte field that indicates the number of multicast sources contained in the group record.
  • Multicast Address A 4-byte field that indicates the IP address of the group that the host is joining.
  • Source Address A 4-byte field that indicates the unicast IP address of a multicast source.
  • Auxiliary Data A variable-sized field that contains additional data for this group record.

Figure 9-7 shows the structure of an IGMPv3 Host Membership Report message group record.

Figure 9-7. The structure of the IGMPv3 Host Membership Report message group record.


The Windows Server 2003 Family and IGMP

The Windows Server 2003 family supports IP multicast sending, receiving, and forwarding through the TCP/IP protocol and the Routing and Remote Access service.

TCP/IP Protocol

TCP/IP for the Windows Server 2003 family supports IP multicast traffic in the following ways:

  • To support host reception of IP multicast traffic, TCP/IP for the Windows Server 2003 family is an IGMPv3-capable host.
  • To support host transmission and reception of IP multicast traffic, TCP/IP for the Windows Server 2003 family supports the mapping of IP multicast addresses to MAC addresses for Ethernet and FDDI network adapters as described in RFC 1112. For Token Ring network adapters, all IP multicast traffic by default is mapped to the Token Ring functional address of 0x-C0-00-00-04-00-00.
  • To support the forwarding of IP multicast traffic, TCP/IP for the Windows Server 2003 family supports multicast forwarding based on the entries in the TCP/IP multicast forwarding table and the setting of the EnableMulticastForwarding registry setting. You can view the contents of the TCP/IP multicast forwarding table from the Routing and Remote Access administrative tool or from the display of the netsh routing ip show mfe command.

In the Windows Server 2003 family, TCP/IP behavior for IP multicast forwarding is controlled by the following registry setting:

EnableMulticastForwarding

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data Type: REG_DWORD

Valid Range: 0-1

Default: 0

Present by Default: No

EnableMulticastForwarding enables (when set to 1) or disables (when set to 0) the forwarding of IP multicast traffic. By default, multicast forwarding is disabled.

Routing and Remote Access Service

In the Windows Server 2003 family, the Routing and Remote Access service functions as a limited multicast forwarder using IGMPv1, IGMPv2, or IGMPv3 to track local group membership. Because IGMP is not a true multicast routing protocol, routers running a member of the Windows Server 2003 family can support only limited multicast configurations. For more information on recommended configurations, see the Internetworking Guide in the Microsoft Windows Server 2003 Resource Kit.

In the Routing and Remote Access service, IGMP is implemented as a routing protocol component added and configured through the Routing and Remote Access administrative tool. After running the Routing and Remote Access Server Setup Wizard, the IGMP routing protocol component is automatically added. Add individual routing interfaces to the IGMP routing protocol and configure them for either IGMP router mode or IGMP proxy mode.

Interfaces in IGMP Router Mode

An interface in IGMP router mode acts as an IGMP-capable IP multicast forwarder and performs the following actions:

  • Places the network adapter in multicast promiscuous mode If the network interface is a broadcast network type such as Ethernet or FDDI, the network adapter is placed in multicast promiscuous mode. If the network adapter does not support multicast promiscuous mode, an event is logged in the system event log.
  • Manages local subnet multicast group membership The routing interface uses IGMP to listen for IGMP Host Membership Report and Leave Group messages, to elect an IGMP querier, and to send General and Group-Specific Host Membership Query messages.
  • Updates the TCP/IP multicast forwarding table Based on ongoing group membership for the interface, IGMP in conjunction with other components of the Routing and Remote Access service maintains the TCP/IP multicast forwarding table.

Interfaces in IGMP Proxy Mode

An interface in IGMP proxy mode acts as an IGMP-capable IP multicast proxy host for hosts on IGMP router mode interfaces and performs the following functions:

  • Forwards IGMP Host Membership Reports IGMP Host Membership Report messages received on IGMP router mode interfaces are forwarded on the IGMP proxy mode interface. The forwarded Host Membership Report messages have a TTL of 1. The received Host Membership Reports are not forwarded using the entries in the TCP/IP multicast forwarding table.
  • Adds multicast MAC addresses to the network adapter table For each group address registered by proxy, the corresponding multicast MAC address is added to the table of interesting MAC addresses on the network adapter (for local area network [LAN] technologies such as Ethernet and FDDI). The network adapter is not placed in promiscuous mode unless the network card cannot support listening to all required multicast MAC addresses. Nonlocal IP multicast traffic received on the IGMP proxy mode interface is passed to the TCP/IP protocol for multicast forwarding.
  • Updates the TCP/IP multicast forwarding table To facilitate the forwarding of multicast traffic from a multicast source on an IGMP router mode interface to a group member downstream from the IGMP proxy mode interface, the IGMP routing protocol adds entries to the TCP/IP multicast forwarding table so that all nonlocal IP multicast traffic received on IGMP router mode interfaces is forwarded over the IGMP proxy mode interface. The IGMP proxy mode interface forwards all nonlocal multicast traffic received from IGMP router mode interfaces regardless of whether or not there are group members present downstream from the IGMP proxy mode interface.

IGMP proxy mode is designed to connect a router running a member of the Windows Server 2003 family to a fully capable IP multicast internetwork, as Figure 9-8 shows. A good example of this is the connection of a single router intranet to the MBONE. IGMP proxy mode is enabled on a single interface connected to the multicast-enabled internetwork.

Figure 9-8. The use of IGMP router mode and proxy mode to connect a single router intranet to an IP multicast-enabled internetwork.

The combination of IGMP router mode interfaces and the IGMP proxy mode interface allows the sending and receiving of IP multicast traffic for hosts on a peripheral network segment using a router running a member of the Windows Server 2003 family.

Multicast Group Members on IGMP Router Mode Interfaces

Host members on IGMP router mode interfaces receive host group traffic through the following process:

  1. A host sends an IGMP Host Membership Report message on the local subnet.
  2. The router updates its multicast forwarding table with the appropriate entry.
  3. The IGMP routing protocol uses the NDISRequest( ) function to add the multicast MAC address corresponding to the IP multicast address to the table of interesting MAC addresses on the network adapter on which IGMP proxy mode is enabled.
  4. The router forwards the IGMP Host Membership Report message on the IGMP proxy mode interface.
  5. The neighboring IP multicast-enabled router receives the IGMP Host Membership Report message, makes the appropriate changes to its multicast forwarding table, and informs downstream IP multicast-enabled routers using multicast routing protocols that a host member exists on the IGMP proxy mode interface network segment.

Routers of the IP multicast-enabled internetwork forward IP multicast traffic sent to the host group to the neighboring IP multicast-enabled router, which forwards the traffic on the IGMP proxy mode interface network segment. The IGMP proxy mode interface receives the multicast traffic and submits it to the TCP/IP multicast forwarding process. Based on the entries in the multicast forwarding table, the IP multicast traffic is forwarded on the IGMP router mode interface connected to the network segment containing the host member.

Multicast Sources on IGMP Router Mode Interfaces

The multicast traffic of multicast sources on IGMP router mode interfaces is forwarded through the following process:

  1. A multicast source host sends nonlocal IP multicast traffic to a specific group address.
  2. The IGMP router mode interface receives the multicast traffic.
  3. For the first multicast packet, the IGMP routing protocol adds an entry to the TCP/IP multicast forwarding table, indicating that there are host members present on the IGMP proxy mode interface.
  4. The multicast traffic is passed to the multicast forwarding process. Based on the entries in the multicast forwarding table, the multicast traffic is forwarded on the IGMP proxy mode interface.
  5. The neighboring IP multicast-enabled router receives the IP multicast traffic and passes it to the multicast forwarding process. Based on the entries in the multicast forwarding table of the IP multicast-enabled router, the multicast packet is either forwarded to host members (local or downstream) or silently discarded.


Summary

IGMP provides a mechanism for hosts to register their interest in receiving IP multicast traffic sent to a specific group address (the Host Membership Report message), for hosts to indicate that they are no longer interested in receiving IP multicast traffic sent to a specific group address (the Leave Group message), and for routers to query the membership of all host groups (the General Host Membership Query) or a single host group (the Group-Specific Host Membership Query). TCP/IP for the Windows Server 2003 family supports IGMPv1, IGMPv2, and IGMPv3, as well as IP multicast forwarding. In the Windows Server 2003 family, the Routing and Remote Access service uses IGMP to maintain the IP multicast forwarding table and provide multicast forwarding in limited configurations.


Internet Protocol Version 6 (IPv6)

Chapter 10
Internet Protocol Version 6 (IPv6)

After decades of faithful service, the current version of IP, also known as IP version 4 (IPv4), is showing signs of age. The growth of the Internet and the inclusion of a variety of unanticipated technologies are putting a strain on the original design. Before we begin to discuss IPv4's pitfalls, we must take a moment to reflect on the design of IPv4. This protocol was designed in the late 1970s (roughly the Bronze Age of computing) and has risen above all other networking protocols to become the de facto world standard for data communications. There are not many computer technologies that were designed in 1978 that are still in use today, much less as the cornerstone of a global communications infrastructure.

As this book is primarily about IPv4, the coverage of IPv6 in this chapter is deliberately written to provide an overview of the technology and how it compares with IPv4. Throughout the rest of this book, when IP is used, it denotes IPv4. For more information about IPv6 and its implementation in Microsoft Windows XP and the Windows Server 2003 family, see the book Understanding IPv6 (Redmond, Wash: Microsoft Press, 2003) by Joseph Davies.


The Disadvantages of IPv4

In today's Internet, IPv4 has the following disadvantages:

  • Limited address space The most visible and urgent problem with using IPv4 in the modern Internet is the rapid depletion of public addresses. Due to the initial address class allocation practices of the early Internet, public IPv4 addresses are becoming scarce. Organizations in the United States hold most public IPv4 address space worldwide.

    This limited address space has forced the wide deployment of Network Address Translators (NATs), which can share one public IPv4 address among several privately addressed computers. NATs have the side effect of blocking secure traffic, specifically Internet Protocol security (IPSec)-protected traffic, and disabling some types of peer-to-peer applications. Although many workarounds for NAT issues are in development, they only add complexity to what should be an end-to-end addressable network.

  • Flat routing infrastructure In the early Internet, network IDs were not allocated to create a summarizable, hierarchical routing infrastructure. Instead, individual network IDs were assigned and each network ID became a new route in the routing tables of the Internet backbone routers. Today's Internet is a mixture of flat and hierarchical routing, but there are still more than 80,000 routes in the routing tables of Internet backbone routers, resulting in slower forwarding of Internet traffic.
  • Configuration IPv4 must be configured, either manually or through the Dynamic Host Configuration Protocol (DHCP). DHCP allows IPv4 configuration to scale, but you must also configure and manage a DHCP infrastructure.
  • Security Security for IPv4 is specified by the use of IPSec. However, IPSec is optional for IPv4 implementations. Because an application cannot rely on IPSec being present to secure traffic, an application might resort to other security standards or a proprietary security scheme. The need for built-in security is even more important today, when we face an increasingly hostile environment on the Internet.
  • Quality of service (QoS) Nonstandard packet delivery for a specified QoS, such as special handling parameters for low delay and low variance in delay for voice or video traffic, is possible with IPv4. However, it relies on a new interpretation of the IPv4 Type Of Service (TOS) field, which is not supported for all the devices on the network. Additionally, identification of the packet flow must be done using an upper layer protocol identifier such as a TCP or User Datagram Protocol (UDP) port. This additional processing of the packet by intermediate routers makes forwarding less efficient.
  • Mobility Mobility is a new requirement for Internet-connected devices, in which a node can change its address as it changes its physical attachment to the Internet and still maintain existing connections. Although there is a specification for IPv4 mobility, due to a lack of infrastructure, communications with an IPv4 mobile node are inefficient.

All of these issues and others prompted the Internet Engineering Task Force (IETF) to begin the development of a replacement protocol for IPv4 that would solve the problems of IPv4 and be extensible to solve additional problems in the future. This replacement for IPv4 is IPv6.

The version number 5 was reserved for a different replacement protocol for IPv4 that was never implemented.

IPv6 solves the problems of IPv4 in the following ways:

  • Huge address space IPv6 addresses are 128 bits long, creating an address space with 3.4 X 1038 possible addresses. This is plenty of address space for the foreseeable future and allows all manner of devices to connect to the Internet without the use of NATs. Address space can also be allocated internationally in a more equitable manner.
  • Hierarchical routing infrastructure IPv6 public addresses, known as global addresses, are designed to have a structure that fits the typical global-regional-local hierarchy of Internet service providers (ISPs) that typically exist between an organization or home and the backbone of the Internet. Global addresses are designed to be summarizable and hierarchical, resulting in relatively few routing entries in the routing tables of Internet backbone routers.
  • Automatic configuration IPv6 hosts can automatically configure their own IPv6 addresses and other configuration parameters, even in the absence of an automatic configuration infrastructure such as DHCP.
  • Built-in security Unlike IPv4, IPv6 support for IPSec is required. Applications can always rely on industry standard security services for data sent and received.
  • Better support for QoS IPv6 has an equivalent to the IPv4 TOS field that will have a single interpretation for nonstandard delivery. Additionally, a Flow Label field in the IPv6 header indicates the packet flow, making the determination of forwarding for nondefault delivery services more efficient at intermediate routers.
  • Built-in mobility Rather than attempting to add mobility to an established protocol with an established infrastructure (as with IPv4), IPv6 has built-in mobility support.
IPv6 is not designed to be a superset of IPv4 functionality and is not backward compatible with IPv4.


IPv6 Addressing

The IPv6 address is 128 bits long, creating an address space of almost inconceivable size. With 128 bits you can express more than 3.4 X 1038 combinations. Unlike IPv4 unicast addresses, the structure of an IPv6 unicast address is very simple: The first 64 bits are used to express a subnet identifier and the last 64 bits are used to express an interface identifier. Although you can perform variable-length subnetting within the 64 bits of the subnet identifier, the host ID equivalent for IPv6 is always the same size. The 64 bits of subnet identifier are used to provide enough addressing space to enumerate networks from the Internet backbone to the subnets within an organization's site. The 64 bits of interface identifier are used to map 48-bit media access control (MAC) addresses used by today's network adapters and 64-bit MAC addresses used by tomorrow's network adapters.

Basics of Address Syntax

With such a large address space, expressing an individual address became problematic. The designers of IPv6 settled on colon-hexadecimal notation. The 128-bit address is divided into 16-bit blocks and delimited by colons. Each 16-bit block is expressed in hexadecimal format (rather than decimal format for IPv4). The result is the IPv6 address.

The following are some examples of IPv6 unicast addresses:

  • 3FFE:FFFF:2A:41CD:2AA:FF:FE5F:47D1
  • FE80:0:0:0:2AA:FF:FE5F:47D1
  • FEC0:0:0:41CD:2AA:FF:FE5F:47D1

Notice that the leading zeros within each block are suppressed, as long as each block contains at least one hexadecimal digit.

There are many IPv6 addresses that have a sequence of blocks set to 0. To further compress IPv6 addresses, a single contiguous set of 0 blocks can be expressed as "::", a notation known as double-colon. For example:

  • FE80:0:0:0:2AA:FF:FE5F:47D1 becomes FE80::2AA:FF:FE5F:47D1
  • FEC0:0:0:41CD:2AA:FF:FE5F:47D1 becomes FEC0::41CD:2AA:FF:FE5F:47D1
  • FF02:0:0:0:0:0:0:1 (a multicast address) becomes FF02::1

To express a subnet identifier, a route, or an address range, IPv6 uses the network prefix length notation (also used for Classless Inter-Domain Routing [CIDR] for IPv4). There are no subnet masks in IPv6. For example, 3FFE:FFFF:2A:41CD::/64 is a subnet identifier; 3FFE:FFFF:2A::/48 is a route; and FF::/8 is an address range (the range of all IPv6 multicast addresses).

Types of Addresses

IPv6 defines three types of addresses: unicast, multicast, and anycast. Unicast and multicast addresses work in the same way as they do for IPv4. An anycast address, however, is a strange mixture of unicast and multicast. Whereas a unicast address is used for one-to-one delivery and a multicast address is used for one-to-many delivery, an anycast address is used for one-to-one-of-many delivery. A set of interfaces, known as an anycast group, listens on the anycast address. When a sending host sends packets to an anycast address, the packets are delivered to the anycast group member that is topologically closest to the sending host. This delivery to the closest anycast group member is facilitated by host routes in the routing infrastructure that indicate with routing metrics where the closest group member is located. This new type of address allows some types of network resources, such as Domain Name System (DNS) servers, to be scattered across an organization's network. For example, when a DNS query is sent, it is sent to a reserved DNS Servers anycast address and delivered to the DNS server that is closest to the querying node.

Types of Unicast Addresses

Just as there are different types of IPv4 unicast addresses (such as public and private), there are different types of IPv6 unicast addresses.

Global

Aggregatable global unicast addresses, also known as global addresses, are the equivalent of IPv4 public addresses. Global addresses are globally reachable on the IPv6 Internet. Unlike public IPv4 network IDs, which are a combination of flat and summarizable address spaces, IPv6 global addresses have a defined structure that makes them easy to aggregate and summarize at address space boundaries. This results in fewer routes in the various routing domains of the Internet.

Local-Use Unicast Addresses

Local-use unicast addresses are those unicast addresses that are not globally reachable on the IPv6 Internet. These addresses are designed to be used within the site or on the link.

Site-local addresses, which are used within the same site, are equivalent to IPv4 public addresses. Organizations can use them internally without conflicting with global addresses and these addresses can be safely used even when the organization has a direct, routed connection to the IPv6 Internet. Site-local addresses always begin with "FEC0".

Link-local addresses, which are used on the same link, are equivalent to Automatic Private IP Addressing (APIPA) addresses used by current Microsoft desktop and server operating systems. Link-local addresses are automatically configured and can be used to provide automatic addressing for nodes connected to the same network segment when there is no router present. Link-local addresses always begin with "FE80".

IPv6 Interface Identifiers

The interface identifier, the last 64 bits of an IPv6 unicast address, is determined in the following ways:

  • Derived from the MAC address of the network adapter to which the address is assigned
  • Randomly generated to provide IPv4-equivalent anonymity
  • Assigned during a Point-to-Point Protocol (PPP) connection
  • Assigned during DHCP configuration

DNS Support

To resolve domain names to IPv6 addresses, RFC 1886 defines the use of the AAAA (or quad-A) DNS resource record to resolve a DNS name to an IPv6 address. The AAAA record is analogous to the address (A) record that exists for resolving a DNS name to an IPv4 address. To obtain an AAAA record in a DNS query response, a querying host must specify either AAAA records or all records in its DNS query.

For reverse name resolution, RFC 1886 also describes the use of pointer (PTR) records to determine the name of an IPv6 node from its address. The IP6.ARPA reverse name domain is used as the root of the reverse namespace rather than IN-ADDR.ARPA. To create the reverse query name, the IPv6 address is fully expressed as a sequence of hexadecimal digits (including all 0 digits), and then each hexadecimal digit in reverse order becomes a separate level in the reverse domain namespace.

For example, for the IPv6 address FEC0:0:0:41CD:2AA:FF:FE5F:47D1 (fully expressed as FEC0:0000:0000:41CD:02AA:00FF:FE5F:47D1), the name in the reverse domain namespace is 1.D.7.4.F.5.E.F.F.F.0.0.A.A.2.0.D.C.1.4.0.0.0.0.0.0.0.0.0.C.E.F.IP6.ARPA.


Core Protocols of IPv6

The core protocols of the IPv6 protocol suite consist of the following:

  • IPv6
  • Internet Control Message Protocol for IPv6 (ICMPv6)
  • Neighbor Discovery (ND)
  • Multicast Listener Discovery (MLD)

IPv6

The IPv6 header is described in RFC 2460. It has a new, streamlined design that removes unneeded fields and moves seldom-used fields to extension headers. Even with addresses that are four times larger than IPv4 addresses, the size of the IPv6 header is only twice as large as the IPv4 header, with a 40-byte fixed size. Although larger, the IPv6 header contains fewer fields and is more efficiently processed by routers. Like IPv4, IPv6 is connectionless and provides a best-effort delivery to the destination.

The IPv6 header is not compatible with the IPv4 header. An IPv4-only node silently discards IPv6 packets and an IPv6-only node silently discards IPv4 packets.

ICMPv6

ICMPv6, defined in RFC 2463, provides error reporting and diagnostic functions for IPv6. Additionally, ICMPv6 provides a common packet structure for the messages of ND and MLD. Analogous to ICMP for IPv4, ICMPv6 provides the following types of messages:

  • Echo Request
  • Echo Reply
  • Destination Unreachable
  • Time Exceeded
  • Parameter Problem

ICMPv6 also includes a Packet Too Big message that is equivalent to the RFC 1191-defined Destination Unreachable-Fragmentation Needed and DF Set message. The ICMPv6 Packet Too Big message is used for IPv6-based path maximum transmission unit (PMTU) discovery.

Neighbor Discovery

ND, defined in RFC 2461, consists of a set of ICMPv6 messages, message options, and defined processes that allow neighboring nodes to discover each other, discover the routers on the link, and provide support for host redirection. ND replaces the following facilities in IPv4:

  • Address Resolution Protocol (ARP)
  • ICMP Router Discovery
  • ICMP Redirect

The five ND messages are as follows:

  • Neighbor Solicitation
  • Neighbor Advertisement
  • Router Solicitation
  • Router Advertisement
  • Redirect

ND defines the following processes:

  • Address resolution Instead of sending a broadcast ARP Request message and receiving a unicast ARP Reply message, an IPv6 node sends a multicast Neighbor Solicitation and receives a unicast Neighbor Advertisement.
  • Duplicate address detection Just like the sending of gratuitous ARP frames in IPv4, an IPv6 node performs address resolution on addresses it attempts to use before initializing them on an interface.
  • Router discovery When nodes start up on a link, they send a multicast Router Solicitation message. Routers on the link send a unicast or multicast Router Advertisement message that contains address prefixes and other configuration options so that the host can automatically configure global and site-local addresses. With proper configuration of routers, a DHCP infrastructure is unnecessary.
  • Redirect Just as in IPv4, if an IPv6 host sends traffic to the wrong router, the router forwards the packet and sends the sending host a Redirect message, informing the host of the better next-hop address of the optimal router.
  • Neighbor unreachability detection New to IPv6 is the ongoing tracking of whether neighboring nodes are reachable. If a neighboring node becomes unreachable, an IPv6 node detects the problem and makes adjustments, such as automatically choosing a new default router, or indicating the error to upper layer protocols.

Multicast Listener Discovery

MLD, defined in RFC 2710, is the IPv6 equivalent to Internet Group Management Protocol (IGMP) version 2 for IPv4. MLD defines ICMPv6 messages that are used by hosts to register group membership, by hosts to leave a group, and by routers to query the subnet for group membership.


Differences Between IPv4 and IPv6

There are many differences between IPv4 and IPv6, and Table 10-1 lists some of the more obvious differences.

Table 10-1. Differences Between IPv4 and IPv6
Category | IPv4 | IPv6
Address length | 32 bits | 128 bits
Header size | 20-60 bytes | 40 bytes
IPSec support | Optional | Required
QoS support | Limited | Better
Fragmentation | Done by hosts and routers | Done by hosts only
Is a header checksum present? | Yes | No
Does the header include options? | Yes | No
Link-layer address resolution | Broadcast ARP frames | Multicast Neighbor Solicitation messages
Error reporting and diagnostic protocol | ICMP (for IPv4) | ICMPv6
Multicast group membership protocol | IGMP | MLD
Router discovery support | Optional | Required
Network layer broadcast addresses? | Yes | No
Host configuration | DHCP or manual | Automatic, DHCP, or manual
DNS record type for name resolution | A record | AAAA record
DNS record type and location for reverse name resolution | PTR records in IN-ADDR.ARPA domain | PTR records in IP6.INT domain


Summary

The IPv6 suite of protocols is a revision of the Internet Layer protocols of the current TCP/IP protocol suite and replaces IP, ICMP, IGMP, and ARP. IPv6 attempts to solve the problems of IPv4 with efficient and plentiful addressing, a streamlined Internet Layer header that is easier for routers to process, and more efficient neighboring node interaction.


User Datagram Protocol

Part III
Transport Layer Protocols
Chapter 11
User Datagram Protocol

There are two protocols at the Transport Layer that Application Layer protocols typically use for transporting data: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). UDP is the Transport Layer protocol that offers a minimum of services, but also has the minimum overhead for Application Layer protocols that do not require an end-to-end reliable delivery service.


Introduction to UDP

UDP is a minimal Transport Layer protocol that is a direct reflection of the datagram services of IP, except that UDP provides a method to pass the message portion of the UDP message to the Application Layer protocol. UDP has the following characteristics:

  • Connectionless UDP messages are sent without a UDP-based connection establishment negotiation.
  • Unreliable UDP messages are sent as datagrams without sequencing or acknowledgment. The Application Layer protocol must recover lost messages. Typical UDP-based Application Layer protocols either provide their own reliable service or retransmit UDP messages periodically or after a defined time-out value.
  • Provides identification of Application Layer protocols UDP provides a mechanism to send messages to a specific Application Layer protocol or process on an internetwork host. The UDP header provides both source and destination process identification.
  • Provides checksum of UDP message The UDP header provides a 16-bit checksum over the entire UDP message.

UDP does not provide the following services for end-to-end delivery:

  • Buffering UDP does not provide any buffering of incoming or outgoing data. The Application Layer protocol must provide all buffering.
  • Segmentation UDP does not provide any segmentation of large blocks of data. Therefore, the application must send data in small enough blocks so that the IP datagrams for the UDP messages are no larger than the Maximum Transmission Unit (MTU) of the interface on which they are sent; otherwise IP on the sending host fragments the UDP message.
  • Flow control UDP does not provide any sender-side or receiver-side flow control. UDP message senders can react to the receipt of an Internet Control Message Protocol (ICMP) Source Quench message, but it is not required.

Uses for UDP

Because UDP does not provide any services beyond Application Layer protocol identification and a checksum, it is hard to imagine why UDP is needed at all. However, the following are specific uses for sending data using UDP:

  • Lightweight protocol To conserve memory and processor resources, some Application Layer protocols require the use of a lightweight protocol that performs a specific function using a simple exchange of messages. A good example of a lightweight protocol is Domain Name System (DNS) name queries. Typically, a DNS client sends a DNS Name Query message to a DNS server. The DNS server responds with a DNS Name Query Response message. If the DNS server does not respond, the DNS client retransmits the DNS Name Query.

    Imagine the resources required at the DNS server if all the DNS clients used TCP rather than UDP. All DNS interactions would be sent reliably, but the DNS server would have to support hundreds or, on the Internet, thousands of TCP connections. The low-overhead solution of using UDP is the best choice for simple request-reply-based Application Layer protocols.

  • Reliability provided by the Application Layer protocol If the Application Layer protocol provides its own reliable data transfer service, there is no need for the reliable services of TCP. Examples of reliable Application Layer protocols are Trivial File Transfer Protocol (TFTP) and Network File System (NFS).
  • Reliability not required due to periodic advertisement process If the Application Layer protocol periodically advertises information, reliable delivery is not required. If an advertisement is lost, it is announced again at the period interval. An example of an Application Layer protocol that uses periodic advertisements is the Routing Information Protocol (RIP).
  • One-to-many delivery UDP is used as the Transport Layer protocol whenever Application Layer data must be sent to multiple destinations using an IP multicast or broadcast address. TCP can be used only for one-to-one delivery. For example, a broadcast NetBIOS Name Query is sent using UDP.


The UDP Message

UDP messages are sent as IP datagrams. A UDP message consisting of a UDP header and a message is encapsulated with an IP header using IP Protocol number 17 (0x11). The message can be a maximum size of 65,507 bytes: 65,535 minus the minimum-size IP header (20 bytes) and the UDP header (8 bytes). The resulting IP datagram is then encapsulated with the appropriate Network Interface Layer header and trailer. Figure 11-1 shows the resulting frame. UDP is described in RFC 768.

Figure 11-1. UDP message encapsulation showing the IP header and Network Interface Layer header and trailer.

In the IP header of UDP messages, the Source IP Address field is set to the host interface that sent the UDP message. The Destination IP Address field is set to the unicast address of a specific host, an IP broadcast address, or an IP multicast address.


The UDP Header

The UDP header is a fixed-length size of 8 bytes consisting of four fixed-length fields, as Figure 11-2 shows.

Figure 11-2. The structure of the UDP header.

The fields in the UDP header are defined as follows:

  • Source Port A 2-byte field used to identify the source Application Layer protocol sending the UDP message. The use of a source port is optional and, when not used, is set to 0. IP multicast traffic, such as videocasts sent using UDP, can use 0 because no reply to the video traffic is assumed. Typical Application Layer protocols use the source port of the incoming UDP message as the destination port for replies.
  • Destination Port A 2-byte field used to identify the destination Application Layer protocol. The combination of the IP header's destination IP address and the UDP header's destination port provides a unique, globally significant address for the process to which the message is sent.
  • Length A 2-byte field used to indicate the length in bytes of the UDP message (UDP header and message). The minimum length is 8 bytes (the UDP header's size), and the maximum is 65,515 bytes (maximum-sized IP datagram of 65,535 bytes minus the minimum-sized IP header of 20 bytes). The actual maximum length is confined by the MTU of the link on which the UDP message is sent. The Length field is a redundant field. The UDP length can always be calculated from the Total Length and the IP Header Length fields in the IP header (UDP length = payload length = total length - 4
  • Checksum A 2-byte field that provides a bit-level integrity check for the UDP message (UDP header and message). The UDP checksum calculation uses the same method as the IP header checksum over the UDP pseudo header, the UDP header, the message, and, if needed, a padding byte of 0x00. The padding byte is used only if the message's length is an odd number of bytes. The use of the UDP Checksum field is optional. If not used, the UDP Checksum field is set to 0. For details on the checksum calculation, see Chapter 5, "Internet Protocol Basics."
TCP/IP for the Microsoft Windows Server 2003 family and Windows XP always calculates a value for the UDP checksum.

The following Network Monitor trace (Capture 11-01 in the \Captures folder on the companion CD-ROM) shows the structure of the UDP header for a DNS Name Query:

+		ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol
+ IP: ID = 0x4001; Proto = UDP; Len: 58

        UDP: Src Port: DNS, (53); Dst Port: DNS (53); Length = 38 (0x26)

            UDP: Source Port = DNS

            UDP: Destination Port = DNS

            UDP: Total length = 38 (0x26) bytes

            UDP: UDP Checksum = 0x6AA1

            UDP: Data: Number of data bytes remaining = 30 (0x001E)

+ DNS: 0x2:Std Qry for www.acme.com. of type Host Addr on class INET addr.
The last item in the Network Monitor display of the UDP header (UDP: Data: Number of data bytes remaining) is a Network Monitor information field and does not correspond to a field in the UDP header.

The UDP Pseudo Header

The UDP pseudo header is used to associate the UDP message with the IP header. The UDP pseudo header is added to the beginning of the UDP message only for the checksum calculation, and is not sent as part of the UDP message. The UDP pseudo header assures that a routing or fragmentation process did not improperly modify the IP header's key fields.

The UDP pseudo header consists of the Source IP Address field, the Destination IP Address field, the Protocol field for UDP (17 or 0x11), an Unused field set to 0, and the UDP Length field. When sending a UDP message, UDP is aware of all of these values. When receiving a UDP message, IP indicates all of these values to UDP. Figure 11-3 shows the UDP pseudo header.

Figure 11-3. The structure of the UDP pseudo header.

The UDP Checksum field is calculated over the combination of the UDP pseudo header, the UDP message, and a 0x00 padding byte if needed. The checksum calculation relies on summing 16-bit words. Therefore, the checksum quantity must be an even number of bytes. The padding byte is used only if the length of the message is an odd number of bytes. The padding byte is not included in the UDP length and is not sent as part of the UDP message. Figure 11-4 shows the resulting quantity for the calculation of the UDP Checksum field.

Figure 11-4. The resulting quantity used for the UDP Checksum calculation.
The UDP pseudo header and Checksum field are not providing data authentication and integrity as the IP Security (IPsec) Authentication header does. IP header fields can be modified as long as the UDP Checksum field is updated. This is how a Network Address Translator (NAT) works. An NAT is a router that translates public and private addresses during the forwarding process. For example, when translating a source IP address from a private address to a public address, the NAT also recalculates the UDP checksum.


UDP Ports

A UDP port defines a location or message queue for the delivery of messages for Application Layer protocols using UDP services. Included in each UDP message is the source port (the message queue from which the message was sent) and a destination port (the message queue to which the message was sent). The Internet Assigned Numbers Authority (IANA) assigns port numbers, known as well-known port numbers, to specific Application Layer protocols. Table 11-1 shows well-known UDP port numbers used by the Windows Server 2003 family and Windows XP components.

Table 11-1. Well-Known UDP Port Numbers
Port Number | Application Layer Protocol
53 | DNS
67 | BOOTP client (Dynamic Host Configuration Protocol [DHCP])
68 | BOOTP server (DHCP)
69 | TFTP
137 | NetBIOS Name Service
138 | NetBIOS Datagram Service
161 | Simple Network Management Protocol (SNMP)
445 | Direct hosting of Server Message Block (SMB) datagrams over TCP/IP
520 | RIP
1812, 1813 | Remote Authentication Dial-In User Service (RADIUS)

See http://www.iana.org/assignments/port-numbers for the most current list of IANA- assigned UDP port numbers.

Typically, the server side of an Application Layer protocol listens on the well-known port number. The client side of Application Layer protocols uses either the well-known port number or, more commonly, a dynamically allocated port number. These dynamically allocated port numbers are used for the duration of the process and are also known as ephemeral or short-lived ports. The following registry setting determines the range of TCP and UDP port numbers for TCP/IP for the Windows Server 2003 family and Windows XP:

MaxUserPort

Location:  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 5000-65534

Default: 5000

Present by default: No

By default, the maximum port number is 5000. Dynamically allocated port numbers are within the range of 1024 through 5000 (0 through 1023 are reserved for well-known ports controlled by the IANA).

A UDP port number can be referenced by name by a Microsoft Windows Sockets application using the GetServByName() function. The name is resolved to a UDP port number through the Services file stored in the %SystemRoot%\System32\Drivers\Etc folder.

A sending node determines the destination port (using either a specified value or the GetServByName() function) and the source port (either specified or by obtaining a dynamically allocated port through Windows Sockets). The sending node then indicates the source IP address, destination IP address, source port, destination port, and the message to be sent to TCP/IP. The UDP module calculates the length and the checksum, and indicates the UDP message with the appropriate source IP address and destination IP address to the IP module.

When receiving a UDP message at the destination, IP verifies the IP header and, based on the value of 17 (0x11) in the Protocol field, passes the UDP message, the source IP address, and the destination IP address to the UDP module. After verifying the UDP checksum, the UDP module verifies the destination port. If a process is listening on the port, the UDP message is passed to the application. If no process is listening on the port, UDP informs the ICMP module, an ICMP Destination Unreachable-Port Unreachable message is sent to the sender, and the UDP message is discarded.

Figure 11-5 shows the process of demultiplexing an incoming UDP message.

Figure 11-5. The demultiplexing of a UDP message to the appropriate Application Layer protocol using the IP Protocol field and the UDP Destination Port field.

Best Practice UDP ports are separate from TCP ports, even for the same port number. A UDP port represents a UDP message queue for an Application Layer protocol. A TCP port represents one side of a TCP connection for an Application Layer protocol. The Application Layer protocol using the UDP port is not necessarily the same Application Layer protocol using the TCP port. A good example of the differentiation between TCP and UDP Application Layer protocols is the Extended Filename Server (EFS) protocol, which uses TCP port 520, and RIP, which uses UDP port 520. Clearly these are separate Application Layer protocols. Therefore, it is good practice to never refer to a port by just its port number because the port number alone is ambiguous. Always refer to either a TCP port number or a UDP port number.


Summary

UDP provides a connectionless and unreliable delivery service for applications that do not require the guaranteed delivery service of TCP. Application Layer protocols use UDP for lightweight interaction, for broadcast or multicast traffic, or when the Application Layer protocol provides its own reliable delivery service. The UDP header provides a checksum and the identification of source and destination port numbers to multiplex UDP message data to the proper Application Layer protocol.


Transmission Control Protocol (TCP) Basics

Chapter 12
Transmission Control Protocol (TCP) Basics

At the Transport Layer are two protocols that Application Layer protocols typically use for transporting data: TCP and User Datagram Protocol (UDP). TCP is the Transport Layer protocol that provides end-to-end reliable delivery service.


Introduction to TCP

TCP is a fully formed Transport Layer protocol that provides a reliable data-transfer service and a method to pass TCP-encapsulated data to an Application Layer protocol. TCP has the following characteristics:

  • Connection-oriented Before data can be transferred, two Application Layer processes must formally negotiate a TCP connection using the TCP connection establishment process. TCP connections are formally closed using the TCP connection termination process. For more information on TCP connection processes, see Chapter 13, "Transmission Control Protocol (TCP) Connections."
  • Full duplex For each TCP peer, the TCP connection consists of two logical pipes: an outgoing pipe and an incoming pipe. With the appropriate Network Interface Layer technology, data can be flowing out of the outgoing pipe and into the incoming pipe simultaneously. The TCP header contains both the sequence number of the outgoing data and an acknowledgment of the incoming data.
  • Reliable Data sent on a TCP connection is sequenced and a positive acknow-ledgment is expected from the receiver. If no acknowledgment is received, the segment is retransmitted. At the receiver, duplicate segments are dis- carded and segments arriving out of sequence are placed back in the proper sequence. A TCP checksum is always used to verify the bit-level integrity of the TCP segment.
  • Byte stream TCP views the data sent over the incoming and outgoing logical pipes as a continuous stream of bytes. The sequence number and acknowledgment number in each TCP header are defined along byte boundaries. TCP is not aware of record or message boundaries within the byte stream. The Application Layer protocol must provide the proper parsing of the incoming byte stream.
  • Sender- and receiver-side flow control To avoid sending too much data at one time and congesting the routers of the IP internetwork, TCP implements sender-side flow control that gradually scales the amount of data sent at one time. To avoid having the sender send data that the receiver cannot buffer, TCP implements receiver-side flow control that indicates the amount of space left in the receiver's buffer. For more information on how TCP implements sender- and receiver-side flow control, see Chapter 14, "Transmission Control Protocol (TCP) Data Flow."
  • Segmentation of Application Layer data TCP segments data obtained from the Application Layer process so that it will fit within an IP datagram sent on the Network Interface Layer link. TCP peers exchange the maximum-sized segment that each can receive and adjust the TCP maximum segment size using Path Maximum Transmission Unit (PMTU) discovery.
  • One-to-one delivery TCP connections are a logical point-to-point circuit between two Application Layer protocols. TCP does not provide a one-to-many delivery service.

TCP typically is used when the Application Layer protocol requires a reliable data transfer service and such a service is not provided by the Application Layer protocol itself.


The TCP Segment

TCP segments are sent as IP datagrams. A TCP segment, consisting of a TCP header and a segment, is encapsulated with an IP header using IP Protocol number 6. The segment can be a maximum size of 65,495 bytes: 65,535 minus the minimum-size IP header (20 bytes) and the minimum-size TCP header (20 bytes). The resulting IP datagram is then encapsulated with the appropriate Network Interface Layer header and trailer. Figure 12-1 displays the resulting frame.

Figure 12-1. TCP segment encapsulation showing the IP header and Network Interface Layer header and trailer.

In the IP header of TCP segments, the Source IP Address field is set to the unicast address of the host interface that sent the TCP segment. The Destination IP Address field is set to the unicast address of a specific host.


The TCP Header

The TCP header is of variable length, consisting of the fields shown in Figure 12-2. When TCP options are not present, the TCP header is 20 bytes long.

Figure 12-2. The structure of the TCP header.

The fields in the TCP header are defined as follows:

  • Source Port A 2-byte field that indicates the source Application Layer protocol sending the TCP segment. The combination of the source IP address in the IP header and the source port in the TCP header provides a source socket—a unique, globally significant address from which the segment was sent.
  • Destination Port A 2-byte field that indicates the destination Application Layer protocol. The combination of the destination IP address in the IP header and the destination port in the TCP header provides a destination socket—a unique, globally significant address to which the segment is sent.
  • Sequence Number A 4-byte field that indicates the outgoing byte-stream-based sequence number of the segment's first octet. The Sequence Number field is always set, even when there is no data in the segment. In this case, the Sequence Number field is set to the number of the outgoing byte stream's next octet. When establishing a TCP connection, TCP segments with a SYN (Synchronization) flag value of 1 set the Sequence Number field to the Initial Sequence Number (ISN). This indicates that the first octet in the outgoing byte stream sent on the connection is ISN + 1.
  • Acknowledgment Number A 4-byte field that indicates the sequence number of the next octet in the incoming byte stream that the receiver expects to receive. The acknowledgment number provides a positive acknowledgment of all octets in the incoming byte stream up to, but not including, the acknowledgment number. The acknowledgment number is significant in all TCP segments with the ACK (Acknowledgment) flag set.
  • Data Offset A 4-bit field that indicates where the TCP segment data begins. The Data Offset field is also the TCP header's size. Just as in the IP header's Header Length field, the Data Offset field is the number of 32-bit words (4-byte blocks) in the TCP header. For the smallest TCP header (no options), the Data Offset field is set to 5 (0x5), indicating that the segment data begins in the twentieth octet offset starting from the beginning of the TCP segment (the offset starts its count at 0). With a Data Offset field set to its maximum value of 15 (0xF), the largest TCP header, including TCP options, can be 60 bytes long.
  • Reserved A 6-bit field that is reserved for future use. The sender sets these bits to 0.
  • Flags A 6-bit field that indicates six TCP flags. The six TCP flags, known as URG (Urgent), ACK, PSH (Push), RST (Reset), SYN, and FIN (Finish), are discussed in greater detail in the "TCP Flags" section of this chapter.
  • Window A 2-byte field that indicates the number of bytes of available space in the receive buffer of the sender of this segment. The receive buffer is used to store the incoming byte stream. By advertising the window size with each segment, a TCP receiver is telling the sender how much data can be sent and successfully buffered. The sender should not be sending more data than can fit in the receiver's buffer. If there is no more space in the receiver's buffer, a window size of 0 bytes is advertised. With a window size of 0, the sender cannot send any more data until the window size is a nonzero value. The advertisement of the window size is an implementation of receiver-side flow control.
  • Checksum A 2-byte field that provides a bit-level integrity check for the TCP segment (TCP header and segment). The Checksum field's value is calculated in the same way as the IP header checksum, over all the 16-bit words in a TCP pseudo header, the TCP header, the segment, and, if needed, a padding byte of 0x00. The padding byte is used only if the segment length is an odd number of octets. The value of the Checksum field is set to 0 during the checksum calculation.
  • Urgent Pointer A 2-byte field that indicates the location of urgent data in the segment. The Urgent Pointer field and urgent data are discussed in the "TCP Urgent Data" section of this chapter.
  • Options One or more TCP options can be added to the TCP header but must be done in 4-byte increments so that the TCP header size can be indicated with the Data Offset field. TCP options are discussed in the section entitled "TCP Options," later in this chapter.

The following Network Monitor trace (Capture 12-01 in the \Captures folder on the companion CD-ROM) shows the TCP header structure for File Transfer Protocol (FTP) traffic:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xDFC8; Proto = TCP; Len: 1500

    TCP: .A...., len: 1460, seq:1038577021-1038578481, ack:3930983524,
                            win:17520, src:   20  dst: 1163

        TCP: Source Port = FTP [default data]

        TCP: Destination Port = 0x048B

        TCP: Sequence Number = 1038577021 (0x3DE76D7D)

        TCP: Acknowledgement Number = 3930983524 (0xEA4E0C64)

        TCP: Data Offset = 20 (0x14)

        TCP: Reserved = 0 (0x0000)

        TCP: Flags = 0x10 : .A....

            TCP:..0.....=No urgent data

            TCP:...1....=Acknowledgement field significant

            TCP:....0...=No Push function

            TCP:.....0..=No Reset

            TCP:......0.=No Synchronize

            TCP:.......0=No Fin

        TCP: Window = 17520 (0x4470)

        TCP: Checksum = 0xB489

        TCP: Urgent Pointer = 0 (0x0)

        TCP: Data: Number of data bytes remaining = 1460 (0x05B4)

+ FTP: Data Transfer To Client, Port = 1163, size 1460


TCP Ports

A TCP port defines a location for the delivery of TCP connection data. Included in each TCP segment is the source port that indicates the Application Layer process from which the segment was sent, and a destination port that indicates the Application Layer process to which the segment was sent. There are port numbers that are assigned by the Internet Assigned Numbers Authority (IANA) to specific Application Layer protocols. Table 12-1 shows assigned TCP port numbers used by the Microsoft Windows Server 2003 family and Windows XP components.

Table 12-1. Well-Known TCP Port Numbers
Port Number | Application Layer Protocol
19 | Network News Transfer Protocol (NNTP)
20 | FTP Server (data channel)
21 | FTP Server (control channel)
23 | Telnet Server
25 | Simple Mail Transfer Protocol (SMTP)
69 | Trivial File Transfer Protocol (TFTP)
80 | Hypertext Transfer Protocol (HTTP; Web server)
139 | NetBIOS Session Service
339 | Lightweight Directory Access Protocol (LDAP)
445 | Direct-Hosted Server Message Block (SMB)

See http://www.iana.org/assignments/port-numbers for the most current list of IANA- assigned TCP port numbers.

Typically, the server side of an Application Layer protocol listens on the well-known port number. The client side of an Application Layer protocol uses either the well-known port number or, more commonly, a dynamically allocated port number. These dynamically allocated port numbers are used for the duration of the process and are known also as ephemeral or short-lived ports. The following registry setting determines the range of port numbers that TCP/IP for the Windows Server 2003 family and Windows XP uses:

MaxUserPort

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 5000-65534

Default: 5000

Present by default: No

By default, the maximum port number is 5000. Dynamically allocated port numbers are within the range of 1024 through 5000 (0-1023 are reserved for well-known ports controlled by the IANA).

A TCP port number can be referenced, by name, by a Windows Sockets application using the GetServByName() function. The name is resolved to a TCP port number through the Services file stored in the %SystemRoot%\System32\Drivers\Etc folder.

A sending node determines the destination port (using either a specified value or the GetServByName() function) and the source port (using either a specified value, or by obtaining a dynamically allocated port through Windows Sockets). The sending node then passes the source IP address, destination IP address, source port, destination port, and the segment to be sent to TCP/IP. The TCP module calculates the Checksum field and indicates the TCP segment with the appropriate source IP address and destination IP address to the IP module.

When receiving a TCP segment at the destination, IP verifies the IP header. Then, based on the value of 6 in the Protocol field, IP passes the TCP segment, the source IP address, and the destination IP address to the TCP module. After verifying the TCP Checksum field, the TCP module verifies the destination port. If a process is listening on the port, the TCP segment is passed to the application. If no process is listening on the port, TCP sends a TCP Connection Reset segment to the sender. See Chapter 13, "Transmission Control Protocol (TCP) Connections," for a detailed discussion of the TCP Connection Reset segment.

Figure 12-3 shows the demultiplexing of received TCP connection data based on the TCP destination port.

Figure 12-3. The demultiplexing of a TCP segment to the appropriate Application Layer protocol using the IP Protocol field and the TCP Destination Port field.

Best Practice TCP ports are separate from UDP ports, even for the same port number. A TCP port represents one side of a TCP connection for an Application Layer protocol. A UDP port represents a UDP message queue for an Application Layer protocol. The Application Layer protocol using the TCP port is not necessarily the same Application Layer protocol using the UDP port. For example, the Extended Filename Server (EFS) protocol uses TCP port 520, and the Routing Information Protocol (RIP) uses UDP port 520. Clearly these are separate Application Layer protocols. Therefore, it is good practice to never refer to a port by just its port number, which is ambiguous. Always refer to either a TCP port number or a UDP port number.


TCP Flags

Figure 12-4 shows the six TCP flags in the Flags field of the TCP header.

Figure 12-4. The six TCP flags in the Flags field of the TCP header.

The TCP flags are defined as follows:

  • URG (Urgent Pointer field is significant) Indicates that the segment portion of the TCP segment contains urgent data and the Urgent Pointer field should be used to determine the location of the urgent data in the segment. Urgent data is discussed in more detail in the section "TCP Urgent Data," later in this chapter.
  • ACK (Acknowledgment field is significant) Indicates that the Acknowledgment field contains the next octet expected on the connection. The ACK flag is always set, except for the first segment of a TCP connection establishment.
  • PSH (the Push function) Indicates that the contents of the TCP receive buffer should be passed to the Application Layer protocol. The data in the receive buffer must consist of a contiguous block of data from the left edge of the buffer. In other words, there cannot be any missing segments of the byte stream up to the segment containing the PSH flag; the data cannot be passed to the Application Layer protocol until missing segments arrive. Normally, the TCP receive buffer is flushed (the contents are passed to the Application Layer protocol) when the receive buffer fills with contiguous data or during normal TCP connection maintenance processes. The PSH flag overrides this default behavior and immediately flushes the TCP receive buffer. The PSH flag is used also for interactive Application Layer protocols such as Telnet, in which each keystroke in the virtual terminal session is sent with the PSH flag set. Another example of using the PSH flag is the setting of the PSH flag on the last segment of a file transferred with FTP. Data sent with the PSH flag does not have to be immediately acknowledged.
  • RST (Reset the connection) Indicates that the connection is being aborted. For active connections, a TCP segment with the RST flag set is sent in response to a TCP segment received on the connection that is incorrect, causing the connection to fail. The sending of an RST segment for an active connection forcibly terminates the connection, causing data stored in send and receive buffers or in transit to be lost. For TCP connections being established, an RST segment is sent in response to a connection establishment request to deny the connection attempt.
  • SYN (Synchronize sequence number) Indicates that the segment contains an ISN. During the TCP connection establishment process, TCP sends a TCP segment with the SYN flag set. Each TCP peer acknowledges the receipt of the SYN flag by treating the SYN flag as if it were a single byte of data. The Acknowledgment Number field for the acknowledgment of the SYN segment is set to ISN + 1.
  • FIN (Finish sending data) Indicates that the TCP segment sender is finished sending data on the connection. When a TCP connection is gracefully terminated, each TCP peer sends a TCP segment with the FIN flag set. A TCP peer does not send a TCP segment with the FIN flag set until all outstanding data to the other TCP peer has been sent and acknowledged. Each peer acknowledges receipt of the FIN flag by treating it as if it were a single byte of data. When both TCP peers have sent segments with the FIN flag set and received acknowledgment of their receipt, the TCP connection is terminated.


The TCP Pseudo Header

The TCP pseudo header is used to associate the TCP segment with the IP header. The TCP pseudo header is added to the beginning of the TCP segment only during the checksum calculation and is not sent as part of the TCP segment. The use of the TCP pseudo header assures the receiver that a routing or fragmentation process did not improperly modify key fields in the IP header.

The TCP pseudo header consists of the Source IP Address field, the Destination IP Address field, an Unused field set to 0x00, the Protocol field for TCP (set to 6), and the length of the TCP segment. When sending a TCP segment, TCP knows all of these values. When receiving a TCP segment, IP indicates all of these values to TCP. Figure 12-5 illustrates the TCP pseudo header.

Figure 12-5. The structure of the TCP pseudo header.

The TCP checksum is calculated over the combination of the TCP pseudo header, the TCP segment, and, if needed, a 0x00 padding byte. The checksum calculation relies on summing 16-bit words. Therefore, the quantity over which the checksum is calculated must be an even number of octets. The padding byte is used only if the segment length is an odd number of octets. The padding byte is not included in the IP length and is not sent as part of the TCP segment. Figure 12-6 shows the resulting quantity for the calculation of the TCP Checksum field.

Figure 12-6. The resulting quantity used for the TCP checksum calculation.
The TCP pseudo header and Checksum field are not providing data authentication and integrity as the IP Security (IPSec) Authentication header does. Key fields in the IP header can be modified as long as the TCP checksum is updated. This is how a Network Address Translator (NAT) works. A NAT is a router that translates public and private addresses during the forwarding process. For example, when translating a source IP address from a private address to a public address, the NAT also recalculates the TCP Checksum field.


TCP Urgent Data

Normal data sent on a TCP connection is data corresponding to the incoming and outgoing byte stream data. In some data-transfer situations, there must be a method of sending control data to interrupt a process or inform the Application Layer protocol of asynchronous events. This control data is known as out of band data—data that is not part of the TCP byte stream but is needed to control the data flow. Out of band data for TCP connections can be implemented in the following ways:

  • Use a separate TCP connection for the out of band data. The separate TCP connection sends control commands and status information without being combined on the data stream of the data connection. This is the method used by FTP. FTP uses a TCP connection on port 21 for control commands such as logins, gets (downloading files to the FTP client), and puts (uploading files to the FTP server), and a separate TCP connection on port 20 for the sending or receiving of file data.
  • Use TCP urgent data. TCP urgent data is sent on the same TCP connection as the data. TCP urgent data is indicated by setting the URG flag, and the urgent data is distinguished from the nonurgent data using the Urgent Pointer field. Urgent data within the TCP segment must be processed before the nonurgent data. Urgent data is used by the Telnet protocol to send control commands, even though the advertised receive window of the Telnet server is 0.

The interpretation of the Urgent Pointer value depends on the TCP implementation's adherence to either RFC 793, the original TCP RFC, or RFC 1122, which defines requirements for Internet hosts.

  • RFC 793 defines the value of the Urgent Pointer field as the positive offset from the beginning of the TCP segment to the first byte of nonurgent data.
  • RFC 1122 defines the value of the Urgent Pointer field as the positive offset from the beginning of the TCP segment to the last byte of urgent data.

These two definitions of the Urgent Pointer field differ by one byte. Both hosts on a TCP connection must use the same interpretation, otherwise data corruption could occur. There is no interoperability of these two interpretations, nor is there a mechanism to negotiate the interpretation during the TCP connection establishment process.

The definition of the Urgent Pointer field in RFC 793 was made in error (the correct interpretation is actually given later in the RFC during the discussion of event processing in Section 3.9). The correct use of the Urgent Pointer field is the RFC 1122 version, but numerous implementations of TCP use the RFC 793 definition.

The use of the TCP Urgent Pointer field is documented in RFCs 793 and 1122, which can be found in the \Rfc folder on the companion CD-ROM.

Figure 12-7 shows the placement of urgent data within the TCP segment and the RFC 793 and RFC 1122 interpretation of the Urgent Pointer field.

Figure 12-7. The location of TCP urgent data within a TCP segment.

The following registry setting for the Windows Server 2003 family and Windows XP allows you to configure the interpretation of the TCP Urgent Pointer field:

TcpUseRFC1122UrgentPointer

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value type: REG_DWORD

Valid range: 0-1

Default: 0

Present by default: No

Set this value to 1 to use the RFC 1122 interpretation of the Urgent Pointer field, or set it to 0 to use the RFC 793 interpretation, which is the default.


TCP Options

Just like options in the IP header extend IP functionality, TCP options are used to extend TCP functionality. There are a variety of defined TCP options used for negotiating maximum segment sizes, scaling window sizes, performing selective acknowledgments, recording timestamps, and providing padding for 4-byte boundaries. A node is not required to support all TCP options; however, the support for processing TCP options is required. The presence of TCP options is indicated by a Data Offset field with a value greater than 5 (0x5). A TCP header with a size greater than 20 bytes contains TCP options.

A TCP option is either a single octet or multiple octets. For multiple-octet options, the TCP option is in type-length-value format, as shown in Figure 12-8, where the length is the length in octets of the entire option. A TCP option type is known as an option kind.

Figure 12-8. The Format for a Multiple-Octet TCP Option.

End Of Option List and No Operation

To implement 4-byte boundary support for TCP options, the following single-octet TCP options are defined:

  • The End Of Option List TCP option is a single octet with the option kind set to 0 (0x00), which indicates that no other options follow. The End Of Option List option is not used to delimit TCP options. If the set of TCP options falls along a 4-byte boundary, this option is not needed.
  • The No Operation TCP option is a single octet with the option kind set to 1 (0x01), which is used between TCP options for 4-byte alignment. The No Operation option is not required, so TCP implementations must be able to correctly interpret TCP options that are not on 4-byte boundaries.

Maximum Segment Size Option

The TCP maximum segment size (MSS) is the largest segment that can be sent on the connection. To obtain the MSS value, take the IP Maximum Transmission Unit (MTU) and subtract the IP header size and the TCP header size. For a typical IP header (without options) and a typical TCP header (without options), the MSS is 40 octets less than the IP MTU, as shown in Figure 12-9.

Figure 12-9. The TCP MSS defined in terms of the IP MTU and the TCP and IP header sizes.

The MSS TCP option is used to communicate a receiver's MSS. The MSS TCP option is included only in TCP segments with the SYN flag set during the TCP connection establishment process. Figure 12-10 shows the MSS TCP option structure.

Figure 12-10. The structure of the TCP MSS option.

The fields in the TCP MSS option are defined as follows:

  • Option Kind Set to 2 (0x02) to indicate the MSS option kind.
  • Option Length Set to 4 (0x04) to indicate that the size of the entire TCP option is 4 bytes.
  • Maximum Segment Size Two bytes that indicate the maximum receive segment size of the sender of this TCP segment. For IP datagrams sent on an Ethernet network segment using Ethernet II encapsulation, the MSS is 1460 (an IP MTU of 1500 minus 40 bytes for minimum-sized IP and TCP headers).

The following Network Monitor trace (Capture 12-02 in the \Captures folder on the companion CD-ROM) shows the MSS TCP option at the end of the TCP header for a SYN segment on an Ethernet network:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0x28EA; Proto = TCP; Len: 48

    TCP: ....S.,	len: 0, seq:3928116524-3928116524, ack: 0, win:16384, src: 1162
                            dst: 21 (FTP)

        TCP: Source Port = 0x048A

        TCP: Destination Port = FTP [control]

        TCP: Sequence Number = 3928116524 (0xEA224D2C)

        TCP: Acknowledgement Number = 0 (0x0)

        TCP: Data Offset = 28 (0x1C)

        TCP: Reserved = 0 (0x0000)

    +	TCP: Flags = 0x02 : ....S.

        TCP: Window = 16384 (0x4000)

        TCP: Checksum = 0x854E

        TCP: Urgent Pointer = 0 (0x0)

        TCP: Options

            TCP: Maximum Segment Size Option

                TCP: Option Type = Maximum Segment Size

                TCP: Option Length = 4 (0x4)

                TCP: Maximum Segment Size = 1460 (0x5B4)

            TCP: Option Nop = 1 (0x1)

            TCP: Option Nop = 1 (0x1)

        +	TCP: SACK Permitted Option

When two TCP peers exchange their MSS during the connection establishment process, both peers adjust their initial MSS to the minimum value reported by both. For example, when an Ethernet node sends an MSS of 1460 and a Fiber Distributed Data Interface (FDDI) node sends an MSS of 4312 (the FDDI IP MTU of 4352, minus 40 octets), both nodes agree to send maximum-sized TCP segments of 1460 octets. The initial MSS is adjusted on an ongoing basis through PMTU discovery. For example, two FDDI nodes on two separate FDDI rings—connected by routers over Ethernet network segments—exchange a TCP MSS of 4312. However, after TCP segments of 4312 octets are sent, PMTU discovery messages adjust the MSS for the connection to 1460. For more information on PMTU, see Chapter 8, "Internet Control Message Protocol (ICMP)."

The MSS TCP option does not prevent problems that could occur between two hosts on the same network segment that are separated by a Network Interface Layer technology with a lower IP MTU size. For example, consider Hosts A and B in Figure 12-11. They are on separate FDDI rings connected by a Fast Ethernet backbone.

Both FDDI rings and the Ethernet backbone are on the same network segment as the router. Therefore, when Hosts A and B exchange MSS, both agree to send maximum-sized TCP segments with a size of 4312 octets. However, when they begin to send bulk data with maximum-sized segments, the translating bridges implemented by the Layer 2 switches have no facilities for translating 4352-octet FDDI payloads to 1500-octet Ethernet payloads. Therefore, the Layer 2 switch silently drops the maximum-sized TCP segments. Because the switch is not an IP router, no PMTU discovery messages are sent to the TCP peers to lower the MSS. The connection fails after one peer retransmits a maximum-sized TCP segment for the maximum allowable times.

Figure 12-11. Hosts on two FDDI rings connected by an Ethernet backbone.

If Host A were an FTP server and Host B were an FTP client, the user at Host B would be able to connect and log in to the FTP server. However, when the user issued a get or put instruction to send a file, the connection would hang and eventually terminate.

The only solution to this problem is to adjust the IP MTU on the FDDI nodes to the lowest value supported by all the Network Interface Layer technologies on the network segment. In this case, you would use the MTU registry setting described in Chapter 5, "Internet Protocol (IP) Basics," to lower the IP MTU of the two FDDI adapters to 1500.

TCP Window Scale Option

The TCP window size defined in RFC 793 is a 16-bit field for a maximum receive window size of 65,535 bytes. This means that a sender can have only 65,535 bytes of data in transit before having to wait for an acknowledgment. This is not an issue on typical local area network (LAN) and wide area network (WAN) links, but it is possible on newer LAN and WAN technologies operating at gigabit-per-second speeds with a sizable transit delay to have more than 65,535 bytes in transit. If TCP cannot fill the pipe and keep it filled, it is operating at lower efficiency.

The TCP Window Scale option described in RFC 1323 allows the receiver to advertise a larger window size than 65,535 bytes. The Window Scale option includes a window scaling factor that, when exponentially combined with the 16-bit window size in the TCP header, increases the receive window size to a maximum of 1,073,725,440 bytes (approximately 1 GB). The Window Size option is sent only in a SYN segment during the connection establishment process. Both TCP peers selectively indicate different window scaling factors used for their receive window sizes. The receiver of the TCP connection establishment request (the SYN segment) cannot send a Window Scale option unless the initial SYN segment contains it.

Figure 12-12 illustrates the TCP Window Scale option structure.

Figure 12-12. The structure of the TCP Window Scale option.

The fields in the TCP Window Scale option are defined as follows:

  • Option Kind Set to 3 (0x03) to indicate the Window Scale option kind.
  • Option Length Set to 3 (0x03) to indicate that the size of the entire TCP option is three octets.
  • Shift Count One byte that indicates the scaling factor as the exponent of 2. For example, for a Shift Count of 5, the scaling factor is 25, or 32. The exponent is used rather than a whole number so that implementations can take advantage of binary shift programming techniques to quickly calculate the actual window size. For example, for a Shift Count of 5, the actual window size is the binary value of the Window field with five zeros added (the Window field is left-shifted by 5). The maximum value of the Shift Count is 14 for a window scaling factor of 214, or 16,384.

The following Network Monitor trace (Capture 12-03 in the \Captures folder on the companion CD-ROM) shows the Window Scale TCP option at the end of the TCP header for a SYN segment:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0x2A1A; Proto = TCP; Len: 64

    TCP: ....S.,	len:    0,	seq:   6727680-6727680, ack:   0, win:65528,
                            src: 1049	dst:   21 (FTP)

        TCP: Source Port = 0x0419

        TCP: Destination Port = FTP [control]

         TCP: Sequence Number = 6727680 (0x66A800)

        TCP: Acknowledgement Number = 0 (0x0)

        TCP: Data Offset = 44 (0x2C)

        TCP: Reserved = 0 (0x0000)

    +	TCP: Flags = 0x02 : ....S.

        TCP: Window = 65528 (0xFFF8)

        TCP: Checksum = 0xBDC5

         TCP: Urgent Pointer = 0 (0x0)

        TCP: Options

               +	TCP: Maximum Segment Size Option

                TCP: Option Nop = 1 (0x1)

                 TCP: Window Scale Option

                    TCP: Option Type = Window Scale

                    TCP: Option Length = 3 (0x3)

                    TCP: Window Scale = 3 (0x3)

                TCP: Option Nop = 1 (0x1)

                TCP: Option Nop = 1 (0x1)

            +	TCP: Timestamps Option

                TCP: Option Nop = 1 (0x1)

                 TCP: Option Nop = 1 (0x1)

              +	TCP: SACK Permitted Option

Notice the use of the No Operation TCP option (Nop) preceding the Window Scale option to align the Window Scale option on 4-byte boundaries.

When the Window Scale option is used, the window size advertised in each TCP segment for the connection is scaled by the factor indicated in the peer's SYN segment. Therefore, the TCP header's Window field is no longer a byte counter of the amount of space left in the receive buffer. Rather, the Window field is a block counter in which the block size in bytes is the scaling factor. For example, for a TCP peer using a Shift Count of 3, the Window field in outgoing TCP segments is actually indicating the number of 8-byte blocks remaining in the receive buffer.

The use of scaling windows is controlled through the following registry setting:

Tcp1323Opts

Key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value type: REG_DWORD

Valid range: 0-3

Present by default: No

Set this value to 0 to disable both window scaling and timestamps. Set this value to 1 to enable only window scaling. Set this value to 2 to only enable timestamps. Set this value to 3 to enable both window scaling and timestamps. By default, the value is not set—TCP/IP does not initiate connections with window scaling or timestamp options but does provide them if requested.

When tracing TCP connection data, make sure that you also look at the connection establishment process to determine whether window scaling is being used. Otherwise, you might misinterpret the Window field value during the connection.

Selective Acknowledgment Option

The acknowledgment scheme for TCP was originally designed as a positive cumulative acknowledgment scheme in which the receiver sends a segment with the ACK flag set and the Acknowledgment field set to the next octet the receiver expects to receive. This use of the Acknowledgment field provides an acknowledgment of all bytes up to, but not including, the sequence number in the Acknowledgment field. This scheme provides reliable byte-stream data transfer, but can result in lower TCP throughput in environments with high packet losses.

If a segment at the beginning of the current send window is not received and all other segments are, the data received cannot be acknowledged until the missing segment arrives. The sender begins to retransmit the segments of the current send window until the acknowledgment for all the segments received has arrived. The sender needlessly retransmits some segments, consequently wasting network bandwidth. This problem is exacerbated in environments such as satellite links, with high bandwidth and high delay, when TCP has a large window size. The more segments in the send window, the more segments can be retransmitted unnecessarily when segments are lost.

RFC 2018 describes a method of selective acknowledgment using TCP options that selectively acknowledges the noncontiguous data blocks that have been received. When the sender receives a selective acknowledgment, it can retransmit just the missing blocks, preventing the sender from waiting for the retransmission time-out for the unacknowledged segments and retransmitting segments that have successfully arrived.

The selective acknowledgment scheme defines the following two different TCP options:

  • The Selective Acknowledgment (SACK)-Permitted option to negotiate the use of selective acknowledgments during the connection establishment process
  • The SACK option to indicate the noncontiguous data blocks that have been received
Selective acknowledgment is described in RFC 2018, which can be found in the \Rfc folder on the companion CD-ROM.

The SACK-Permitted Option

The SACK-Permitted option is sent in segments with the SYN flag set and indicates that the TCP peer can receive and interpret the TCP SACK option when data is flowing on the connection. The SACK-Permitted option is 2 bytes consisting of an Option Kind set to 4 (0x04) and an Option Length set to 2 (0x02), as shown in Figure 12-13.

Figure 12-13. The structure of the TCP SACK-Permitted option.

The following Network Monitor trace (Capture 12-04 in the \Captures folder on the companion CD-ROM) shows the TCP SACK-Permitted option at the end of the TCP header for a SYN segment:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0x28EA; Proto = TCP; Len: 48

    TCP: ....S., 	len: 0, seq:3928116524-3928116524, ack: 0, win:16384, src: 1162
                            dst: 21 (FTP)

        TCP: Source Port = 0x048A

        TCP: Destination Port = FTP [control]

        TCP: Sequence Number = 3928116524 (0xEA224D2C)

        TCP: Acknowledgement Number = 0 (0x0)

        TCP: Data Offset = 28 (0x1C)

        TCP: Reserved = 0 (0x0000)

    +	TCP: Flags = 0x02 : ....S.

        TCP: Window = 16384 (0x4000)

        TCP: Checksum = 0x854E

        TCP: Urgent Pointer = 0 (0x0)

        TCP: Options

            +	TCP: Maximum Segment Size Option

                TCP: Option Nop = 1 (0x1)

                TCP: Option Nop = 1 (0x1)

                TCP: SACK Permitted Option

                    TCP: Option Type = Sack Permitted

                    TCP: Option Length = 2 (0x2)

Notice the use of the two No Operation TCP option (Nop) fields preceding the SACK-Permitted option to align the SACK-Permitted option on 4-byte boundaries.

The SACK Option

The SACK option is sent as needed in segments of the open connection with the ACK flag set. As Figure 12-14 illustrates, the SACK option is a variable-size option, depending on how many contiguous blocks are being acknowledged.

Figure 12-14. The structure of the TCP SACK option.

The fields in the TCP SACK option are defined as follows:

  • Option Kind Set to 5 (0x05) to indicate the SACK option kind.
  • Option Length Set to 10 (a single noncontiguous block), 18 (two noncontiguous blocks), 26 (three noncontiguous blocks), or 34 (four noncontiguous blocks) octets to indicate the size of the entire TCP option.
  • Left Edge of Nth Block A 4-byte field that indicates the sequence number of this block's first octet.
  • Right Edge of Nth Block A 4-byte field that indicates the next sequence number expected to be received immediately following this block.

The following Network Monitor trace (Capture 12-05 in the \Captures folder on the companion CD-ROM) shows the TCP SACK option at the end of the TCP header for data being acknowledged:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xFA0D; Proto = TCP; Len: 64

    TCP: .A...., 	len:    0, seq:    925293-925293, ack:  55053434, win:32767,
                            src: 1242  dst:139 (NBT Session)

        TCP: Source Port = 0x04DA

        TCP: Destination Port = NETBIOS Session Service

        TCP: Sequence Number = 925293 (0xE1E6D)

        TCP: Acknowledgement Number = 55053434 (0x3480C7A)

        TCP: Data Offset = 44 (0x2C)

        TCP: Reserved = 0 (0x0000)

    +	TCP: Flags = 0x10 : .A....

        TCP: Window = 32767 (0x7FFF)

        TCP: Checksum = 0x436E

        TCP: Urgent Pointer = 0 (0x0)

        TCP: Options

            TCP: Option Nop = 1 (0x1)

            TCP: Option Nop = 1 (0x1)

        +	TCP: Timestamps Option

            TCP: Option Nop = 1 (0x1)

            TCP: Option Nop = 1 (0x1)

            TCP: SACK Option

                TCP: Option Type = SACK

                TCP: Option Length = 10 (0xA)

                TCP: Left Edge of Block  = 55054882 (0x3481222)

                TCP: Right Edge of Block = 55059226 (0x348231A)

In the trace, the sender of this segment is acknowledging the receipt of all contiguous octets in the byte stream up to, but not including, octet 55053434, and the receipt of the block of contiguous data from octets 55054882 through 55059225. There is a missing segment consisting of the octets 55053434 through 55054881. Notice the use of the Nop options to align the SACK option on 4-byte boundaries.

The use of selective acknowledgments and the SACK options are controlled through the following registry setting:

SackOpts

Key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value type: REG_DWORD

Valid range: 0-1

Default: 1

Present by default: No

SackOpts either enables (when set to 1) or disables (when set to 0) the use of selective acknowledgments and the SACK options. SackOpts is enabled by default.

For more information on the use of selective acknowledgments to retransmit data, see Chapter 15, "Transmission Control Protocol (TCP) Retransmission and Time-Out."

TCP Timestamps Option

To set the retransmission time-out (RTO) on TCP segments sent, TCP monitors the round-trip time (RTT) on an ongoing basis. Normally, TCP calculates the RTT of a TCP segment and its acknowledgment once for every full send window of data. Although this works well in many environments, for high-bandwidth and high-delay environments such as satellite links with large window sizes, the sampling rate of one segment for each window size cannot monitor the RTT to determine the current RTO and prevent unnecessary retransmissions.

To calculate the RTT on any TCP segment, the segment is sent with the TCP Timestamps option described in RFC 1323. This option places a timestamp value based on a local clock on an outgoing TCP segment. The acknowledgment for the data in the TCP segment echoes back the timestamp, and the RTT can be calculated from the segment's echoed timestamp and the time (relative to the local clock) that the segment's acknowledgment arrived.

The TCP Timestamps option is described in RFC 1323, which can be found in the \Rfc folder on the companion CD-ROM.

Including the Timestamps option in the SYN segment during the connection establishment process indicates its use for the connection. Both sides of the TCP connection can selectively use timestamps. Once indicated during connection establishment, the timestamp can be included in TCP segments at the discretion of the sending TCP peer.

Figure 12-15 shows the TCP Timestamps option structure.

Figure 12-15. The structure of the TCP Timestamps option.

The fields in the TCP Timestamps option are defined as follows:

  • Option Kind Set to 8 (0x08) to indicate the Timestamps option kind.
  • Option Length Set to 10 (0x0A) to indicate that the size of the entire TCP option is 10 octets.
  • TS Value A 4-byte field that indicates the timestamp value of this TCP segment. The TS Value is calculated from an internal clock that is based on real time. The TS Value increases over time and wraps around when needed.
  • TS Echo Reply A 4-byte field set on a TCP segment that acknowledges data received (with the ACK flag set) that is set to the same value as the TS Value for the received segment being acknowledged. In other words, the TS Echo Reply is an echo of the TS Value of the acknowledged segment.

Figure 12-16 illustrates an example of the values of the TS Value and TS Echo Reply for an exchange of data between two hosts.

Figure 12-16. An example of the use of the TCP Timestamps option.

Host A's internal clock starts its TS Value at 100. Host B's internal clock starts its TS Value at 9000. Segments 1 through 4 are for two data blocks sent by Host A. Segments 5 and 6 are for a data block sent by Host B. Notice how the TS Echo Reply value for the acknowledgments is set to the TS Value of the segments they are acknowledging. To prevent gaps in the sending of data from increasing the RTT, the TS Echo Reply is used for RTT measurement only if the segment is an acknowledgment of new data sent.

The following Network Monitor trace (Capture 12-06 in the \Captures folder on the companion CD-ROM) shows two frames—a frame of data containing the TCP Timestamps option and its corresponding acknowledgment:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0x1A15; Proto = TCP; Len: 1500

    TCP: .A...., len: 1448, seq:  55050538-55051986, ack: 925293, win:16564,
                            src:  139 (NBT Session)  dst: 1242

        TCP: Source Port = NETBIOS Session Service

        TCP: Destination Port = 0x04DA

        TCP: Sequence Number = 55050538 (0x348012A)

        TCP: Acknowledgement Number = 925293 (0xE1E6D)

        TCP: Data Offset = 32 (0x20)

        TCP: Reserved = 0 (0x0000)

    +	TCP: Flags = 0x10 : .A....

         TCP: Window = 16564 (0x40B4)

        TCP: Checksum = 0xBD81

        TCP: Urgent Pointer = 0 (0x0)

        TCP: Options

            TCP: Option Nop = 1 (0x1)

            TCP: Option Nop = 1 (0x1)

            TCP: Timestamps Option

                TCP: Option Type = Timestamps

                TCP: Option Length = 10 (0xA)

                TCP: Timestamp = 4677 (0x1245)

                TCP: Reply Timestamp = 7114 (0x1BCA)

        TCP: Data: Number of data bytes remaining = 1448 (0x05A8)

+	NBT: SS: Session Message Cont., 1448 Bytes

________________________________________________________________________________

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xF60D; Proto = TCP; Len: 52

    TCP: .A...., 	len:    0, seq:    925293-925293, ack:  55051986, win:32722,
                            src: 1242  dst:139 (NBT Session)

        TCP: Source Port = 0x04DA

        TCP: Destination Port = NETBIOS Session Service

        TCP: Sequence Number = 925293 (0xE1E6D)

        TCP: Acknowledgement Number = 55051986 (0x34806D2)

        TCP: Data Offset = 32 (0x20)

        TCP: Reserved = 0 (0x0000)

    +	TCP: Flags = 0x10 : .A....

        TCP: Window = 32722 (0x7FD2)

        TCP: Checksum = 0x84D1

         TCP: Urgent Pointer = 0 (0x0)

        TCP: Options

            TCP: Option Nop = 1 (0x1)

            TCP: Option Nop = 1 (0x1)

            TCP: Timestamps Option

                TCP: Option Type = Timestamps

                TCP: Option Length = 10 (0xA)

                TCP: Timestamp = 7126 (0x1BD6)

                TCP: Reply Timestamp = 4677 (0x1245)

Notice that in the second frame the Reply Timestamp (TS Echo Reply) field is set to 4677, echoing the Timestamp (TS Value) field of the first frame.

The use of TCP timestamps for the Windows .NET Server 2003 family and Windows XP is controlled through the Tcp1323Opts registry setting discussed in the section "TCP Window Scale Option," earlier in this chapter.

For more information on RTT, RTO, and retransmission behavior, see Chapter 15, "Transmission Control Protocol (TCP) Retransmission and Time-Out."


Summary

TCP provides connection-oriented and reliable data transfer for applications that require end-to-end guaranteed delivery service. Application Layer protocols use TCP for one-to-one traffic. The TCP header provides sequencing, acknowledgment, a checksum, and the identification of source and destination port numbers to multiplex TCP segment data to the proper Application Layer protocol. TCP options are used to indicate maximum segment sizes, indicate window scaling, indicate and provide selective acknowledgments, and provide timestamps for better RTT determination.


Transmission Control Protocol (TCP) Connections

Chapter 13
Transmission Control Protocol (TCP) Connections

TCP is a connection-oriented protocol. Before data can flow on a TCP connection, the connection must be formally established through a handshake process. To gracefully stop the flow of data on a TCP connection and release the resources of the connection, it must be terminated through a similar handshake process.


The TCP Connection

A TCP connection is a bidirectional, full-duplex logical circuit between two processes (Application Layer protocols) in an IP internetwork. The TCP connection's endpoints are identified by an [IP address, TCP port] pair. The connection is uniquely identified by both endpoints: [IP address 1, TCP port 1, IP address 2, TCP port 2]. TCP uses those four numbers to demultiplex the data portion of the TCP segment to the proper Application Layer process.

A TCP connection can be visualized as a bidirectional data pipe containing two logical pipes between the two TCP peers, as Figure 13-1 illustrates. One logical pipe is used for outbound data and the other logical pipe is used for inbound data (relative to the TCP peer). The outbound data pipe for one TCP peer is the inbound data pipe for the other TCP peer.

Figure 13-1. A TCP connection showing both inbound and outbound logical pipes.

TCP connections are:

  • Established through a handshake process in which both TCP peers agree to create a TCP connection
  • Maintained through a periodic keepalive process that ensures that both TCP peers are active on the connection
  • Terminated through a handshake process in which both TCP peers agree to close the TCP connection

TCP connections can also be reset by either TCP peer.


TCP Connection Establishment

To create a TCP connection over which full-duplex data can begin to flow, each TCP peer must learn the following information from the other TCP peer:

  • The starting sequence number for data sent on the inbound pipe
  • The size of the buffer to receive data sent on the outbound pipe (the receive window size of the other TCP peer)
  • The maximum segment size (MSS) that can be received
  • The TCP options that are supported

This information is learned through an exchange of three TCP segments called the TCP connection establishment process, or the TCP three-way handshake.

To create a TCP connection, a server system must allow a TCP connection, and a client system must initiate a TCP connection. The server system issues a passive OPEN function call to permit incoming connection requests on a specific port number. This function call does not create any TCP traffic. The client system issues an active OPEN function call, which creates and sends the first segment of the TCP three-way handshake.

Figure 13-2 displays the TCP connection establishment process, showing the three TCP segments that are exchanged and the information in the TCP header that is vital to the connection establishment. Prior to segment 1, TCP Peer 2 issued a passive OPEN to receive TCP connection requests. TCP Peer 1 issues an active OPEN and creates segment 1. Segments 2 and 3 complete the connection establishment process. The vertical arrows show the passage of time during the connection establishment process.

Figure 13-2. The TCP connection establishment process, showing the exchange of three TCP segments.

Segment 1: The Synchronize (SYN) Segment

TCP Peer 1 sends the first TCP segment, known as the SYN segment, to TCP Peer 2. The SYN segment establishes TCP connection parameters, such as the Initial Sequence Number (ISN) that TCP Peer 1 uses. The SYN segment as sent by a computer running a member of the Microsoft Windows Server 2003 family or Windows XP contains the following fields in the TCP header:

  • Destination Port Set to the TCP port number of the passive OPEN on TCP Peer 2. For typical TCP connections, the destination port in the SYN segment is a well-known TCP port in the range of 1 to 1023.
  • Source Port Set to the local TCP port number of the active OPEN on TCP Peer 1. For typical TCP connections, the source port is a dynamically allocated port in the range of 1024 to 5000.
  • Sequence Number Set to the ISN for data to be sent by TCP Peer 1 for the outbound data pipe (ISN1 in Figure 13-2). A TCP peer running a member of the Windows Server 2003 family or Windows XP chooses the ISN based on a startup-derived, 2048-bit random key and an RC4-based random number to reduce the predictability of the next TCP connection's ISN.
  • Acknowledgment Number Set to 0. Because the Acknowledgment (ACK) flag is not set, the Acknowledgment Number field is not significant. Only after a TCP peer learns the sequence number for inbound data on the connection can the ACK flag be set and the Acknowledgment Number field set to the appropriate value.
  • SYN Flag Indicates that the segment contains the ISN for data sent by TCP Peer 1.
  • Window Set to a default value, indicating an initial value for the size of TCP Peer 1's receive buffer.
  • MSS in the MSS TCP Option Set to the maximum-sized TCP segment that TCP Peer 1 can receive.
  • Selective Acknowledgment (SACK)-Permitted TCP Option Included to indicate that TCP Peer 1 can receive and interpret the SACK option included in TCP segments that TCP Peer 2 sends.

The following Network Monitor trace (Frame 1 of Capture 13-01, included in the \Captures folder on the companion CD-ROM) shows a SYN segment for a File Transfer Protocol (FTP) session:

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0x28EA; Proto = TCP; Len: 48

    TCP: ....S., 	len: 0, seq:3928116524-3928116524, ack: 0, win:16384, src: 1162
                            dst: 21 (FTP)

        TCP: Source Port = 0x048A

        TCP: Destination Port = FTP [control]

        TCP: Sequence Number = 3928116524 (0xEA224D2C)

        TCP: Acknowledgment Number = 0 (0x0)

        TCP: Data Offset = 28 (0x1C)

        TCP: Reserved = 0 (0x0000)

        TCP: Flags = 0x02 : ....S.

            TCP: ..0..... = No urgent data

            TCP: ...0.... = Acknowledgment field not significant

            TCP: ....0... = No Push function

            TCP: .....0.. = No Reset

            TCP: ......1. = Synchronize sequence numbers

            TCP: .......0 = No Fin

        TCP: Window = 16384 (0x4000)

        TCP: Checksum = 0x854E

        TCP: Urgent Pointer = 0 (0x0)

        TCP: Options

            TCP: Maximum Segment Size Option

                TCP: Option Type = Maximum Segment Size

                TCP: Option Length = 4 (0x4)

                 TCP: Maximum Segment Size = 1460 (0x5B4)

            TCP: Option Nop = 1 (0x1)

            TCP: Option Nop = 1 (0x1)

            TCP: SACK Permitted Option

                TCP: Option Type = Sack Permitted

                 TCP: Option Length = 2 (0x2)

Segment 2: The SYN-ACK Segment

After receipt of the SYN segment, TCP Peer 2 sends the second TCP segment known as the SYN-ACK segment to TCP Peer 1. The SYN-ACK segment establishes TCP connection parameters that TCP Peer 2 uses, such as the ISN, and acknowledges TCP connection parameters used by TCP Peer 1. The SYN-ACK segment as sent by a computer running a member of the Windows Server 2003 family or Windows XP contains the following fields in the TCP header:

  • Destination Port Set to the Source Port of the SYN segment.
  • Source Port Set to the local TCP port number of the passive OPEN on TCP Peer 2 as indicated by the Destination Port number of the SYN segment.
  • Sequence Number Set to the ISN for data to be sent by TCP Peer 2 for the outbound data pipe (ISN2 in Figure 13-2). A TCP peer running a member of the Windows Server 2003 family or Windows XP chooses the ISN based on a startup-derived, 2048-bit random key and an RC4-based random number to reduce the predictability of the next TCP connection's ISN.
  • Acknowledgment Number Set to the value of the TCP Peer 1's ISN plus 1 (ISN1 + 1). The SYN flag occupies a single octet of the sequence space of Peer 1. The acknowledgment number is the next octet in the byte stream that TCP Peer 2 expects to receive. If the SYN flag acts as a single octet of nondata, the next octet that TCP Peer 2 expects to receive is actual data, and must therefore begin with ISN1 + 1.
  • SYN Flag Indicates that the segment contains the ISN for data sent by TCP Peer 2.
  • ACK Flag Indicates that the Acknowledgment Number field is significant.
  • Window Set to an application-specified value or the value of an integral number of MSS-sized segments according to an operating system default value. This value indicates an initial value for the size of TCP Peer 2's receive buffer (n*MSS in Figure 13-2). For Windows Server 2003 family- or Windows XP-based TCP/IP hosts using Ethernet, the default receive window size is 17,520 octets, or 12 MSS segments (at 1460 octets per segment).
  • MSS in the MSS TCP Option Set to the maximum-sized TCP segment that TCP Peer 2 can receive.
  • SACK-Permitted TCP Option Indicates that TCP Peer 2 can receive and interpret the SACK option included in TCP segments that TCP Peer 1 sends.

The following Network Monitor trace (Frame 2 of Capture 13-01, included in the \Captures folder on the companion CD-ROM) shows a SYN-ACK segment for an FTP session (continued from the previous SYN segment):

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xDFAB; Proto = TCP; Len: 48

    TCP: .A..S., 	len:    0, seq:1035688768-1035688768, ack:3928116525,
                            win:17520, src:   21 (FTP)  dst: 1162

        TCP: Source Port = FTP [control]

        TCP: Destination Port = 0x048A

          TCP: Sequence Number = 1035688768 (0x3DBB5B40)

        TCP: Acknowledgment Number = 3928116525 (0xEA224D2D)

        TCP: Data Offset = 28 (0x1C)

        TCP: Reserved = 0 (0x0000)

        TCP: Flags = 0x12 : .A..S.

              TCP: ..0..... = No urgent data

            TCP: ...1.... = Acknowledgment field significant

            TCP: ....0... = No Push function

            TCP: .....0.. = No Reset

            TCP: ......1. = Synchronize sequence numbers

            TCP: .......0 = No Fin

        TCP: Window = 17520 (0x4470)

        TCP: Checksum = 0xE7D1

        TCP: Urgent Pointer = 0 (0x0)

        TCP: Options

            TCP: Maximum Segment Size Option

                TCP: Option Type = Maximum Segment Size

                TCP: Option Length = 4 (0x4)

                TCP: Maximum Segment Size = 1460 (0x5B4)

            TCP: Option Nop = 1 (0x1)

            TCP: Option Nop = 1 (0x1)

            TCP: SACK Permitted Option

                TCP: Option Type = Sack Permitted

                TCP: Option Length = 2 (0x2)

Segment 3: The ACK Segment

After receipt of the SYN-ACK segment, TCP Peer 1 sends the third TCP segment, known as the ACK segment, to TCP Peer 2. The ACK segment establishes the final TCP connection parameters used by TCP Peer 1 and acknowledges TCP connection parameters that TCP Peer 2 uses. The ACK segment, as sent by a computer running a member of the Windows Server 2003 family or Windows XP, contains the following fields in the TCP header:

  • Destination Port Set to the Source Port of the SYN-ACK segment.
  • Source Port Set to the local TCP port number of the active OPEN on TCP Peer 1 as indicated by the Destination Port number of the SYN-ACK segment.
  • Sequence Number Set to ISN1 + 1.
  • Acknowledgment Number Set to the value of the TCP Peer 2's ISN plus 1 (ISN2 + 1). The SYN flag occupies a single octet of the sequence space of TCP Peer 2. The acknowledgment number is the next octet in the byte stream that TCP Peer 1 expects to receive. If the SYN flag is acting as a single octet of nondata, the next octet that TCP Peer 1 expects to receive is actual data, and must therefore begin with ISN2 + 1.
  • ACK Flag Indicates that the Acknowledgment Number field is significant.
  • Window Set to an application-specified value, or the value of an integral number of MSS-sized segments, according to an operating system default value. This value indicates an initial value for the size of TCP Peer 1's receive buffer (n*MSS in Figure 13-2). For Windows Server 2003- or Windows XP-based TCP/IP hosts using Ethernet, the default receive window size is 17,520 octets, or 12 MSS segments (at 1460 octets per segment).

The following Network Monitor trace (Frame 3 of Capture 13-01, included in the \Captures folder on the companion CD-ROM) shows an ACK segment for an FTP session (continued from the previous SYN-ACK segment):

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0x28EB; Proto = TCP; Len: 40

    TCP: .A...., 	len:    0, seq:3928116525-3928116525, ack:1035688769,
                            win:17520, src: 1162  dst:   21 (FTP)

        TCP: Source Port = 0x048A

        TCP: Destination Port = FTP [control]

        TCP: Sequence Number = 3928116525 (0xEA224D2D)

        TCP: Acknowledgment Number = 1035688769 (0x3DBB5B41)

        TCP: Data Offset = 20 (0x14)

        TCP: Reserved = 0 (0x0000)

        TCP: Flags = 0x10 : .A....

            TCP: ..0..... = No urgent data

            TCP: ...1.... = Acknowledgment field significant

            TCP: ....0... = No Push function

            TCP: .....0.. = No Reset

            TCP: ......0. = No Synchronize

            TCP: .......0 = No Fin

                TCP: Window = 17520 (0x4470)

                TCP: Checksum = 0x1496

                TCP: Urgent Pointer = 0 (0x0)

Results of the TCP Connection

The results of the TCP connection establishment process are as follows:

  • Each TCP peer knows the sequence number of the first octet of data to be sent on the connection (TCP Peer 1's Acknowledgment Number field is set to TCP Peer 2's Sequence Number field; TCP Peer 2's Acknowledgment Number field is set to TCP Peer 1's Sequence Number field).
  • Each TCP peer knows the MSS that can be sent on the connection. The connection's MSS is the minimum of the two MSSs advertised by TCP Peer 1 and TCP Peer 2. Path Maximum Transmission Unit (PMTU) Discovery adjusts the initial MSS for the duration of connection. For more information on PMTU Discovery, see Chapter 8, "Internet Control Message Protocol (ICMP)."
  • Each TCP peer knows the size of the other peer's receive buffer (the window size) indicating the maximum amount of data that can be sent without waiting for an ACK and updated window size. Although a large amount of data can be sent, TCP peers use the slow start and congestion avoidance algorithms to slowly scale the amount of data sent to avoid congesting the internetwork.
  • Each TCP peer is aware that the other peer is capable of receiving selective acknowledgments using the SACK TCP option. For more information on selective acknowledgment, see Chapter 14, "Transmission Control Protocol (TCP) Data Flow."

Registry Settings for TCP Connections

The TCP connection establishment process is controlled by the following registry settings:

TcpMaxConnectRetransmissions

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-255

Default value: 2

Present by default: No

TcpMaxConnectRetransmissions sets how many SYN segment retransmissions are sent when attempting to establish a TCP connection. The retransmission time-out (RTO) is doubled between each retransmission. With the initial RTO of 3 seconds and the default value of TcpMaxConnectRetransmissions of 2, it takes 21 seconds to time out a TCP connection attempt (initial SYN, wait 3 seconds, first retransmitted SYN, wait 6 seconds, second transmitted SYN, wait 12 seconds).

The following summary of a Network Monitor trace (Capture 13-02, included in the \Captures folder on the companion CD-ROM) shows this behavior:

1	0.000	TCP_Peer_1	Intel 123456	TCP	....S.,	len:	0,	seq:
                        748701-748704,	ack:	0

2	2.923	TCP_Peer_1	Intel 123456	TCP	....S.,	len:	0,	seq:
                        748701-748704,	ack:	0

3	6.009	TCP_Peer_1	Intel 123456	TCP	....S.,	len:	0,	seq:
                        748701-748704,	ack:	0

This summary trace displays the elapsed time between successive frames.

TcpNumConnections

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-0xFFFFFE

Default value: 0xFFFFFE

Present by default: No

TcpNumConnections sets the maximum number of TCP connections that can be open. By default, 16,777,214 (0xFFFFFE) connections can be open.


TCP Half-Open Connections

A TCP half-open connection, illustrated in Figure 13-3, is a TCP connection that has not completed the connection establishment process. A SYN segment has been received and a SYN-ACK has been sent, but the final ACK has not been received. Until the final ACK is received, data cannot be sent on the connection.

Figure 13-3. A TCP half-open connection showing the SYN segment and retransmissions of the SYN-ACK segment.

Although the SYN-ACK segment contains no data, the SYN flag occupies a single byte of the sequence space and is treated as data. Therefore, TCP retransmission and time-out behaviors used for recovering from lost data are used to recover from a lost SYN-ACK segment. In the case of retransmitting a SYN-ACK segment, the default time-out is 3 seconds and the SYN-ACK is retransmitted twice by default. Therefore, the first SYN-ACK is sent, 3 seconds later the first retransmission is sent, and 6 seconds later the second retransmission is sent. After waiting 12 seconds for a response to the final retransmission, the connection is abandoned and the memory and the connection's internal table entries are released. A total of 21 seconds elapse from the time the first SYN-ACK is sent until the connection is abandoned.

The SYN Attack

The SYN attack is a denial-of-service attack that exploits the retransmission and time-out behavior of the SYN-ACK to create a large number of half-open connections. Depending on the TCP/IP protocol implementation, a large number of half-open connections could do any of the following:

  • Use all available memory.
  • Use all possible entries in the TCP Transmission Control Block (TCB), an internal table used to track TCP connections. Once the half-open connections use all the entries, further connection attempts are responded to with a TCP connection reset. TCP connection resets are discussed in the section "TCP Connection Reset," later in this chapter.
  • Use all available half-open connections. After all the half-open connections are used, further connection attempts are responded to with a TCP connection reset.

To create a large number of TCP half-open connections, malicious users send a large number of SYN segments from a spoofed IP address and TCP port number. The spoofed IP address and TCP port number are for a process that does not respond to the SYN-ACKs being sent by the attacked host. SYN attacks typically are used to render Internet servers inoperative.

To see a SYN attack in progress on a computer running a member of the Windows Server 2003 family or Windows XP, use the NETSTAT command to display the active TCP connections. For example:

c:\>netstat -n -p tcp

    Active Connections

        Proto 	Local Address	Foreign Address	State

        TCP	127.0.0.1:1030	127.0.0.1:1032	ESTABLISHED

        TCP	127.0.0.1:1032	127.0.0.1:1030	ESTABLISHED

        TCP	10.1.1.5:21	192.168.0.1:1025	SYN_RECEIVED

        TCP	10.1.1.5:21	192.168.0.1:1026	SYN_RECEIVED

        TCP	10.1.1.5:21	192.168.0.1:1027	SYN_RECEIVED

        TCP	10.1.1.5:21	192.168.0.1:1028	SYN_RECEIVED

        TCP	10.1.1.5:21	192.168.0.1:1029	SYN_RECEIVED

        TCP	10.1.1.5:21	192.168.0.1:1030	SYN_RECEIVED

        TCP	10.1.1.5:21	192.168.0.1:1031	SYN_RECEIVED

        TCP	10.1.1.5:21	192.168.0.1:1032	SYN_RECEIVED

        TCP	10.1.1.5:21	192.168.0.1:1033	SYN_RECEIVED

        TCP	10.1.1.5:21	192.168.0.1:1034	SYN_RECEIVED

        TCP	10.1.1.5:21	192.168.0.1:1035	SYN_RECEIVED

This is an example of a SYN attack. There are a number of TCP connections in the SYN_ RECEIVED state, and the foreign address is a spoofed private address with incrementally increasing TCP port numbers. The SYN_RECEIVED is the state of a TCP connection that has received a SYN, sent a SYN-ACK, and is waiting for the final ACK. TCP connection states are discussed in greater detail later in this chapter in the section "TCP Connection States."

TCP/IP for the Windows Server 2003 family and Windows XP has been modified from previous versions to detect and defend against a SYN attack in progress by using the following registry settings:

TcpMaxConnectResponseRetransmissions

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-255

Default value: 2

Present by default: No

TcpMaxConnectResponseRetransmissions sets the number of retransmissions of a SYN-ACK for half-open connections. For values greater than 1, TCP/IP uses SYN attack protection.

SynAttackProtect

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-2

Default value: 0

Present by default: No

SynAttackProtect disables SYN attack protection (when the value is 0), enables SYN attack protection (when the value is 1), or enables SYN attack protection but delays indicating the connection to Windows Sockets until the three-way handshake is complete (when the value is 2). When enabled, half-open connections time out more quickly if a SYN attack is detected.

TcpMaxHalfOpen

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 100-65535

Default value: 100 for Windows XP; Windows Server 2003, Web Edition; and Windows Server 2003, Standard Edition; and 500 for Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition

Present by default: No

TcpMaxHalfOpen sets the maximum number of TCP connections in the SYN_RECEIVED state before SYN attack protection takes effect.

TcpMaxHalfOpenRetried

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 80-65535

Default value: 80 for Windows XP; Windows Server 2003, Web Edition; and Windows Server 2003, Standard Edition; 400 for Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition

Present by default: No

TcpMaxHalfOpenRetried sets the maximum number of TCP connections in the SYN_RECEIVED state for which at least one retransmission has been sent before SYN attack protection takes effect.


TCP Connection Maintenance

A TCP connection can be maintained through the periodic exchange of a TCP keepalive segment, which is an ACK segment containing no data. The Sequence Number field in the TCP header of the keepalive segment is set to 1 less than the current sequence number for the outbound data stream. For example, if a TCP peer's next octet of data is 18745323, the TCP keepalive sent by the TCP peer has the Sequence Number field set to 18745322.

After receiving this ACK segment, the other TCP peer sends back an ACK segment with the Acknowledgment Number field set to the next octet that it expects to receive. In this example, the TCP peer sends an ACK segment with the Acknowledgment Number field set to 18745323. This simple exchange confirms that both TCP peers are still participating in the TCP connection.

Figure 13-4 shows the TCP keepalive.

Figure 13-4. A TCP keepalive showing the sending of an exchange of ACK segments to confirm both ends of the connection are still present.

TCP keepalives for TCP/IP for the Windows Server 2003 family and Windows XP are disabled by default. If enabled through the use of the setsockopt() Windows Sockets function, a keepalive segment is sent every two hours by default, as controlled by the KeepAliveTime registry setting. Even if enabled, other upper layer protocols such as NetBIOS send their own keepalive. If the keepalive interval that the upper layer protocol uses is less than the TCP keepalive interval, TCP keepalives are never sent. For example, NetBIOS sessions over TCP/IP send a NetBIOS keepalive every 60 minutes. Therefore, TCP keepalives enabled for a NetBIOS session are never used.

The following registry settings control TCP keepalive behavior:

KeepAliveTime

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-0xFFFFFFFF

Default value: 0x6DDD00 (7,200,000)

Present by default: No

KeepAliveTime sets the number of milliseconds between each TCP keepalive segment if no data has been sent on the connection and if keepalives have been enabled on the connection. The default value of 7,200,000 milliseconds corresponds to two hours.

KeepAliveInterval

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-0xFFFFFFFF

Default value: 0x3E8 (1000)

Present by default: No

KeepAliveInterval sets the number of milliseconds between successive retransmissions of the keepalive segment when a response to the initial keepalive is not received. The number of TCP keepalive retransmissions is controlled by the TcpMaxDataRetransmissions registry setting, which has a default value of 5. After sending five TCP keepalive retransmissions, the connection is abandoned.

Therefore, with the default values of KeepAliveTime, KeepAliveInterval, and TcpMaxData-Retransmissions, a TCP connection on which keepalives have been enabled by the application is abandoned after two hours and six seconds.

Notice that for keepalives, the exponential backoff behavior between successive retransmissions is not done. For more information on the retransmission behavior of TCP, see Chapter 15, "Transmission Control Protocol (TCP) Retransmission and Time-Out."


TCP Connection Termination

Just as the TCP connection establishment process requires the sending of a SYN segment and its acknowledgment, the TCP connection termination process requires the sending of a FIN (Finish) segment, a TCP segment in which the FIN flag is set, and its acknowledgment. The FIN segment indicates that the FIN segment sender will send no more data on the connection. Because a TCP connection is made of two logical pipes (an outbound and inbound pipe for each TCP peer), both pipes must be closed and the closure must be acknowledged.

Figure 13-5 shows a TCP connection termination.

Figure 13-5. A TCP connection termination showing the exchange of four TCP segments.

Typical TCP connection termination processes consist of the exchange of four TCP segments.

Segment 1: The FIN-ACK from TCP Peer 1

A TCP peer (TCP Peer 1) that wants to terminate outbound data flow sends a TCP segment that contains no data with the following:

  • The Sequence Number field set to the current sequence number for outbound data. When closing the connection, the current sequence number is the final sequence number for outbound data (FSN1 in Figure 13-5).
  • The Acknowledgment Number field set to the next byte of inbound data that the TCP peer expects to receive. This number also corresponds to the current sequence number of TCP Peer 2 (CSN2 in Figure 13-5).
  • The ACK flag is set, indicating that the Acknowledgment Number field is significant.
  • The FIN flag is set, indicating that no more data will be sent from this TCP peer on the connection.

The following Network Monitor trace (Frame 1 of Capture 13-03, included in the \Captures folder on the companion CD-ROM) shows a FIN-ACK segment for an FTP session being closed by an FTP server:

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xDFF9; Proto = TCP; Len: 40

    TCP: .A...F, 	len:    0, seq:1035689055-1035689055, ack:3928116597,
                            win:17448, src:   21 (FTP)  dst: 1162

        TCP: Source Port = FTP [control]

        TCP: Destination Port = 0x048A

        TCP: Sequence Number = 1035689055 (0x3DBB5C5F)

        TCP: Acknowledgment Number = 3928116597 (0xEA224D75)

        TCP: Data Offset = 20 (0x14)

        TCP: Reserved = 0 (0x0000)

        TCP: Flags = 0x11 : .A...F

            TCP: ..0..... = No urgent data

            TCP: ...1.... = Acknowledgment field significant

            TCP: ....0... = No Push function

            TCP: .....0.. = No Reset

            TCP: ......0. = No Synchronize

            TCP: .......1 = No more data from sender

        TCP: Window = 17448 (0x4428)

        TCP: Checksum = 0x1377

        TCP: Urgent Pointer = 0 (0x0)

Segment 2: The ACK from TCP Peer 2

Similar to the SYN flag, the FIN flag occupies a byte of the TCP sequence space and therefore must be acknowledged as if it were a byte of data. Therefore, the TCP peer receiving the FIN-ACK segment (TCP Peer 2) sends an ACK with the following:

  • The Sequence Number field set to the current sequence number for outbound data (CSN2 in Figure 13-5).
  • The Acknowledgment Number field set to 1 more than the final sequence number for inbound data on the connection (FSN1 + 1).
  • The ACK flag is set, indicating that the Acknowledgment Number field is significant.

The following Network Monitor trace (Frame 2 of Capture 13-03, included in the \Captures folder on the companion CD-ROM) shows an ACK segment sent from the FTP client in response to a FIN-ACK sent by the FTP server:

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0x291E; Proto = TCP; Len: 40

    TCP: .A...., 	len:    0, seq:3928116597-3928116597, ack:1035689056,
                            win:17234, src: 1162  dst:   21 (FTP)

        TCP: Source Port = 0x048A

        TCP: Destination Port = FTP [control]

        TCP: Sequence Number = 3928116597 (0xEA224D75)

        TCP: Acknowledgment Number = 1035689056 (0x3DBB5C60)

        TCP: Data Offset = 20 (0x14)

        TCP: Reserved = 0 (0x0000)

        TCP: Flags = 0x10 : .A....

            TCP: ..0..... = No urgent data

            TCP: ...1.... = Acknowledgment field significant

             TCP: ....0... = No Push function

            TCP: .....0.. = No Reset

            TCP: ......0. = No Synchronize

            TCP: .......0 = No Fin

        TCP: Window = 17234 (0x4352)

        TCP: Checksum = 0x144D

        TCP: Urgent Pointer = 0 (0x0)

Notice how the acknowledgment number is 1 more (1035689056) than the sequence number of the previous FIN-ACK (1035689055), explicitly acknowledging the receipt of the FIN-ACK segment.

Once the FIN is acknowledged, the TCP peer that sent the initial FIN-ACK segment cannot send data (TCP Peer 1). However, only one logical pipe has been terminated. The inbound data pipe for TCP Peer 1 is still open and data can still flow and be acknowledged with ACK segments that contain no data.

Segment 3: The FIN-ACK from TCP Peer 2

If the TCP peer with the open outbound data pipe (TCP Peer 2) still has data to send, data can be sent and acknowledged by TCP Peer 1. This is known as a TCP half-close. For example, a TCP half-close occurs when a client application sends the FIN-ACK segment and the server application still has data to send to the client before it can terminate its side of the connection.

Once all outstanding data from TCP Peer 2 is sent and acknowledged, TCP Peer 2 can close its outbound logical pipe to TCP Peer 1. TCP Peer 2 sends a segment with the following:

  • The Sequence Number field set to the current sequence number for outbound data. When closing the connection, the current sequence number is the final sequence number for outbound data (FSN2 in Figure 13-5).
  • The Acknowledgment Number field set to the next byte of inbound data that the TCP peer expects to receive. In this case, the acknowledgment number is the same as that acknowledged in Segment 2 (FSN1 + 1).
  • The ACK flag is set, indicating that the Acknowledgment Number field is significant.
  • The FIN flag is set, indicating that no more data will be sent from this TCP peer on the connection.

The following Network Monitor trace (Frame 3 of Capture 13-03, included in the \Captures folder on the companion CD-ROM) shows a FIN-ACK segment for the FTP client closing its outbound pipe:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0x291F; Proto = TCP; Len: 40

    TCP: .A...F, 	len:    0, seq:3928116597-3928116597, ack:1035689056,
                            win:17234, src: 1162  dst:   21 (FTP)

        TCP: Source Port = 0x048A

        TCP: Destination Port = FTP [control]

        TCP: Sequence Number = 3928116597 (0xEA224D75)

        TCP: Acknowledgment Number = 1035689056 (0x3DBB5C60)

        TCP: Data Offset = 20 (0x14)

        TCP: Reserved = 0 (0x0000)

        TCP: Flags = 0x11 : .A...F

            TCP: ..0..... = No urgent data

            TCP: ...1.... = Acknowledgment field significant

            TCP: ....0... = No Push function

            TCP: .....0.. = No Reset

            TCP: ......0. = No Synchronize

            TCP: .......1 = No more data from sender

        TCP: Window = 17234 (0x4352)

        TCP: Checksum = 0x144C

        TCP: Urgent Pointer = 0 (0x0)

Segment 4: The ACK from TCP Peer 1

The FIN flag of Segment 3 occupies a byte of the TCP sequence space and therefore must be acknowledged as a byte of data. Therefore, the TCP peer receiving the FIN-ACK segment (TCP Peer 1) sends an ACK with the following:

  • The Sequence Number field set to the current sequence number for outbound data (FSN1 + 1).
  • The Acknowledgment Number field set to 1 more than the final sequence number for inbound data on the connection (FSN2 + 1).
  • The ACK flag is set, indicating that the Acknowledgment Number field is significant.

The following Network Monitor trace (Frame 4 of Capture 13-03, included in the \Captures folder on the companion CD-ROM) shows an ACK segment that the FTP server sent in response to a FIN-ACK sent by the FTP client:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xDFFA; Proto = TCP; Len: 40

    TCP: .A...., 	len:    0, seq:1035689056-1035689056, ack:3928116598,
                            win:17448, src:   21 (FTP)  dst: 1162

        TCP: Source Port = FTP [control]

        TCP: Destination Port = 0x048A

        TCP: Sequence Number = 1035689056 (0x3DBB5C60)

        TCP: Acknowledgment Number = 3928116598 (0xEA224D76)

        TCP: Data Offset = 20 (0x14)

        TCP: Reserved = 0 (0x0000)

        TCP: Flags = 0x10 : .A....

            TCP: ..0..... = No urgent data

            TCP: ...1.... = Acknowledgment field significant

            TCP: ....0... = No Push function

            TCP: .....0.. = No Reset

            TCP: ......0. = No Synchronize

            TCP: .......0 = No Fin

        TCP: Window = 17448 (0x4428)

        TCP: Checksum = 0x1376

        TCP: Urgent Pointer = 0 (0x0)

Notice how the acknowledgment number is 1 more (3928116598) than the sequence number of the previous FIN-ACK (3928116597), explicitly acknowledging the receipt of the FIN-ACK segment.

TCP Peer 2's outbound pipe is terminated when the ACK segment is received. The TCP connection, with both logical pipes gracefully terminated, is closed.

TCP connection terminations do not have to use four segments. In some cases, Segments 2 and 3 are combined. The result is a FIN-ACK/FIN-ACK/ACK sequence.


TCP Connection Reset

The TCP connection termination process is for the graceful, mutually agreed closure of both pipes of a TCP connection. Both TCP peers exchange FIN segments that are acknowledged explicitly, indicating that all data on each outbound pipe has been sent and acknowledged. Another way to terminate a TCP connection is through a TCP connection reset—a TCP segment with the RST (Reset) flag set.

A TCP connection reset is sent when a parameter problem exists in the TCP header of an inbound TCP segment that cannot be reconciled. For example, an improper source or destination IP address or TCP port number could cause an established connection to be aborted.

Aborting an established TCP connection through a TCP reset also can be intentionally done through Windows Sockets. However, aborting a TCP connection causes the discarding of all TCP data that is either in transit or in buffers waiting to be sent.

A TCP connection reset is used also to reject a TCP connection attempt in response to the receipt of a SYN segment. The most common reason a TCP peer denies a connection attempt with a connection reset is that the destination port in the SYN segment does not correspond to an Application Layer process running at the recipient of the SYN segment. Connection attempts also can be denied when the maximum number of allowed TCP connections is reached. Figure 13-6 shows a TCP connection reset.

When a User Datagram Protocol (UDP) message arrives at a destination port that does not correspond to an Application Layer process, an Internet Control Message Protocol (ICMP) Destination Unreachable-Port Unreachable message is sent to the sender of the UDP message.
Figure 13-6. A TCP connection reset showing the SYN and RST segments.

The following Network Monitor trace (Capture 13-04, included in the \Captures folder on the companion CD-ROM) shows the sequence of packets sent between a host running an FTP client and a host that is not an FTP server. Frame 1 is a SYN segment to the FTP control port; Frame 2 is the connection reset.

Frame 1

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0x2927; Proto = TCP; Len: 48

    TCP: ....S., 	len: 0, seq:4065871748-4065871748, ack: 0, win:16384, src: 1164
                            dst:   21 (FTP)

        TCP: Source Port = 0x048C

        TCP: Destination Port = FTP [control]

        TCP: Sequence Number = 4065871748 (0xF2584784)

        TCP: Acknowledgment Number = 0 (0x0)

        TCP: Data Offset = 28 (0x1C)

        TCP: Reserved = 0 (0x0000)

        TCP: Flags = 0x02 : ....S.

            TCP: ..0..... = No urgent data

            TCP: ...0.... = Acknowledgment field not significant

            TCP: ....0... = No Push function

            TCP: .....0.. = No Reset

            TCP: ......1. = Synchronize sequence numbers

            TCP: .......0 = No Fin

        TCP: Window = 16384 (0x4000)

        TCP: Checksum = 0x82BE

        TCP: Urgent Pointer = 0 (0x0)

    +	TCP: Options

__________________________________________________________________________________

Frame 2

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xE18A; Proto = TCP; Len: 40

    TCP: .A.R.., 	len: 0, seq: 0-0, ack:4065871749, win: 0, src: 21 (FTP)
                            dst: 1164

        TCP: Source Port = FTP [control]

        TCP: Destination Port = 0x048C

        TCP: Sequence Number = 0 (0x0)

        TCP: Acknowledgment Number = 4065871749 (0xF2584785)

        TCP: Data Offset = 20 (0x14)

        TCP: Reserved = 0 (0x0000)

        TCP: Flags = 0x14 : .A.R..

            TCP: ..0..... = No urgent data

            TCP: ...1.... = Acknowledgment field significant

            TCP: ....0... = No Push function

            TCP: .....1.. = Reset the connection

            TCP: ......0. = No Synchronize

            TCP: .......0 = No Fin

        TCP: Window = 0 (0x0)

        TCP: Checksum = 0xEF6E

        TCP: Urgent Pointer = 0 (0x0)

In the connection reset segment:

  • The RST and ACK flags are set.
  • The sequence number is 0.
  • The acknowledgment number is 1 more than the sequence number of the SYN segment (ISN1 + 1). As in the SYN-ACK segment of a connection establishment process, the SYN flag occupies a byte of sequence space and is explicitly acknowledged as if it were a byte of data.
  • The window size is 0.

After receipt of a connection reset, the initiating peer can either try again (in practice, three attempts are made) or abandon the connection attempt.


TCP Connection States

A TCP connection exists in one of the states listed in Table 13-1.

Table 13-1. TCP Connection States
State | Description
CLOSED | No TCP connection exists.
LISTEN | An Application Layer protocol has issued a passive open and is willing to accept TCP connection attempts.
SYN SENT | An Application Layer protocol has issued an active open and a SYN segment is sent.
SYN RCVD | A SYN segment is received and a SYN-ACK is sent.
ESTABLISHED | The final ACK for the TCP connection establishment process is sent and received. Data can now be transferred in both directions.
FIN WAIT-1 | The initial FIN-ACK segment to close one side of the connection is sent.
FIN WAIT-2 | The ACK in response to the initial FIN-ACK is received.
CLOSING | A FIN-ACK is received but the ACK is not for the FIN-ACK sent. This is known as a simultaneous close, when both TCP peers send FIN-ACKs at the same time.
TIME WAIT | FIN-ACKs have been sent and acknowledged by both TCP peers and the TCP connection termination process is completed. Once the TIME WAIT state is reached, TCP must wait twice the maximum segment lifetime (MSL) before the connection's TCP port number can be reused. The MSL is the maximum amount of time a TCP segment can exist in an internetwork, and its recommended value is 240 seconds. This delay prevents a new connection's TCP segments using the same port numbers from being confused with duplicated TCP segments of the old connection.
CLOSE WAIT | A FIN-ACK has been received and a FIN-ACK has been sent.
LAST ACK | The ACK in response to the FIN-ACK has been received.

Figure 13-7 shows the states of a TCP connection.

The connection states that a TCP peer goes through depend on whether the TCP peer is the initiator of the TCP connection establishment or the initiator of the TCP connection termination.

Figure 13-7. The states of a TCP connection.

Figure 13-8 shows the connection states of two TCP peers during the connection establishment process.

Figure 13-8. The states of a TCP connection during TCP connection establishment.

Figure 13-9 shows the connection states of two TCP peers during the connection termination process.

Figure 13-9. The states of a TCP connection during TCP connection termination.

Controlling TCP Connection Terminations in the Windows Server 2003 Family and Windows XP

The TIME WAIT state is used to delay the reuse of the same parameters for a TCP connection, ensuring that duplicates of the old connection's TCP segments in transit are not confused with a new connection's TCP segments. The RFC 793 recommended value for the MSL is two minutes. Therefore, the time that the TCP connection is in the TIME WAIT state is four minutes (2*MSL).

TCP connections in the TIME WAIT state are controlled by the following registry settings:

TcpTimedWaitDelay

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 30-300

Default value: 240

Present by default: No

The value of TcpTimedWaitDelay is the number of seconds that a TCP connection remains in the TIME WAIT state. The default is the RFC 793 recommended value of 240 seconds (four minutes).

MaxFreeTWTcbs

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 1-0xFFFFFFFF

Default value: 0x3E8 (1000)

Present by default: No

The value of the MaxFreeTWTcbs is the number of TCP connections allowed in the TIME WAIT state. If the number of TCP connections in the TIME WAIT state exceeds this value, the oldest TCP connection is immediately released.

The default values for TcpTimedWaitDelay and MaxFreeTWTcbs work well for many situations. However, for some situations that require the opening and closing of many outbound connections in a short amount of time, the large delay before a TCP port number can be reused can result in the use of all possible TCP ports. Once this state of full capacity is reached, new TCP connections cannot be made until existing TCP connections go from the TIME WAIT state to the CLOSED state.

There are three methods that can prevent this problem from occurring:

  1. Set the value of TcpTimedWaitDelay to a lower value to free TCP port numbers more quickly. The TcpTimedWaitDelay can be set as low as 30 seconds.
  2. Set the value of MaxFreeTWTcbs to a lower value to force the freeing of TCP connections in the TIME WAIT state more quickly.
  3. Set the value of MaxUserPort to a higher value. MaxUserPort specifies the maximum port number that can be used when an application requests an available port using Windows Sockets. The default value of MaxUserPort is 5000. Dynamically allocated ports start at 1024. Therefore, with the default setting of 5000, only 3977 dynamic TCP ports are available. In a high-traffic, high-use environment such as a proxy server on the Internet, it is possible to have 3977 TCP ports in either an established or TIME WAIT state. Setting this value higher allows more TCP ports to be in use simultaneously.


Summary

TCP connections are created through the TCP connection establishment process, where two TCP peers exchange SYN segments and determine starting sequence numbers, window sizes, maximum segment sizes, and other TCP options. TCP connections can be maintained through the exchange of periodic keepalive segments, although this is not common. To terminate a TCP connection gracefully, each TCP peer must send a FIN segment and have it acknowledged. A TCP connection reset segment is used to either abort a current connection or refuse a connection attempt.


Transmission Control Protocol (TCP) Data Flow

Chapter 14
Transmission Control Protocol (TCP) Data Flow

TCP data flow provides reliable data transfer through the sequencing of outbound data and the acknowledgment of inbound data. Along with reliability, TCP data transfer includes behaviors to prevent inefficient use of the network and provide sender-side and receiver-side flow control.


Basic TCP Data Flow Behavior

The following mechanisms govern TCP data flow, whether for interactive traffic, such as Telnet sessions, or for bulk data transfer, such as the downloading of a large file with the File Transfer Protocol (FTP):

  • Acknowledgments TCP acknowledgments are delayed and cumulative for contiguous data and selective for noncontiguous data.
  • Sliding send and receive windows A send window for the sender and a receive window for the receiver control the amount of data that can be sent. Send and receive windows provide receiver-side flow control. As data is sent and acknowledged, the send and receive windows slide along the sequence space of the sender's byte stream.
  • Avoidance of small segments Small segments—TCP segments that are not at the TCP maximum segment size (MSS)—are allowed, but are governed to avoid inefficient internetwork use.
  • Sender-side flow control TCP sliding windows provide a way for the receiver to determine flow control, but the sender also uses flow control algorithms to avoid sending too much data and congesting the internetwork.


TCP Acknowledgments

A TCP acknowledgment (ACK) is a TCP segment with the ACK flag set. In an ACK, the Acknowledgment Number field indicates the next byte in the contiguous byte stream that the ACK's sender expects to receive. Additionally, if the TCP Selective Acknowledgment (SACK) option is present, the ACK indicates up to four blocks of noncontiguous data received.

Delayed Acknowledgments

When a TCP peer receives a segment, the acknowledgment for the segment (either cumulative or selective) is not sent immediately. The TCP peer delays the sending of the ACK segment for the following reasons:

  • If, during the delay, additional TCP segments are received, a single ACK segment can acknowledge the receipt of multiple TCP segments.
  • For full-duplex data flow, delaying the ACK makes it possible for the ACK segment to contain data. This is known as piggybacking the data on the ACK, or piggyback ACKs. If the incoming TCP segment contains data that requires a response from the receiver, the response can be sent along with the ACK. This is common for Telnet traffic, in which each keystroke of the Telnet client is sent to the Telnet server process. The received Telnet keystroke must be echoed back to the Telnet client. Rather than sending an ACK for the keystroke received and then sending the echoed keystroke, a single TCP segment containing the ACK and the echoed keystroke is sent.
  • TCP has the time to perform general connection maintenance. The Application Layer protocol has additional time to retrieve data from the TCP receive buffer and an updated window size can be sent with ACK.

RFC 1122 specifies that the acknowledgment delay should be no longer than 0.5 seconds. By default, TCP/IP for the Microsoft Windows Server 2003 family and Windows XP uses an acknowledgment delay of 200 ms (0.2 seconds), which can be configured per interface by the TcpDelAckTicks registry setting.

TcpDelAckTicks

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\InterfaceGUID

Data type: REG_DWORD

Valid range: 0-6

Default value: 2

Present by default: No

TcpDelAckTicks sets the delayed acknowledgment timer (in 100-ms intervals) of an interface. Setting TcpDelAckTicks to zero disables delayed acknowledgments. The default value of 2 specifies a 200-ms delayed acknowledgment timer.

Cumulative for Contiguous Data

As originally defined in RFC 793, the TCP acknowledgment scheme is cumulative. The presence of the ACK flag and the value of the Acknowledgment Number field explicitly acknowledge all bytes in the received byte stream from the Initial Sequence Number (ISN) + 1 (the first byte of data sent on the connection), up to but not including the number in the Acknowledgment Number field (Acknowledgment Number - 1). Figure 14-1 illustrates the cumulative acknowledgment scheme of TCP.

Figure 14-1. The cumulative acknowledgment scheme of TCP.

An ACK with a new Acknowledgment Number field is sent when a TCP segment is received containing data that is contiguous with previous data received. TCP segments received that are not contiguous with the previous segments received are not acknowledged. Only when the missing segments are retransmitted and received, creating a contiguous block of one or more TCP segments, is an ACK segment sent with the new Acknowledgment Number field.

Although the original cumulative acknowledgment scheme for TCP works well and provides reliable data transfer, in high-loss environments this relatively simple acknowledgment scheme can slow throughput and use additional network bandwidth.

For example, a TCP peer sends six TCP segments. If the first of the six segments is dropped and the last five segments arrive, no ACK for the five received segments is sent. With normal TCP retransmission behavior, after the retransmission time-out (RTO), the sending TCP peer begins to retransmit all six segments. When the retransmission of the first TCP segment arrives, the receiving TCP peer sends an ACK segment confirming receipt of all six segments. Although the dropped first segment was successfully recovered, TCP needlessly sent duplicates of segments that successfully arrived.

Selective for Noncontiguous Data

With selective acknowledgments, the Acknowledgment Number field still indicates the last contiguous byte received, but the TCP SACK option can acknowledge noncontiguous received segments. With the TCP SACK option, the left and right edges of the blocks of noncontiguous data received are explicitly acknowledged, preventing needless retransmission. Figure 14-2 illustrates TCP's selective acknowledgment scheme.

Figure 14-2. The selective acknowledgment scheme of TCP.

Using the previous example, if six TCP segments are sent and the first segment is dropped, the receiving TCP peer sends an ACK segment with the following settings: the Acknowledgment Number field is set to the first byte of the missing TCP segment, and the TCP SACK option is set with the left and right edge of the block consisting of the second through the sixth received TCP segments. After receipt of the ACK with the TCP SACK option, the sender marks the selectively acknowledged TCP segments and does not retransmit them. The sending TCP peer retransmits the first TCP segment after its RTO. After receipt, the receiving TCP peer sends an ACK segment with the Acknowledgment Number field set to the first octet past the sixth TCP segment.

Selective acknowledgments are especially important for the recovery of data on a TCP connection with a large window size. The previous example has a window size of six segments. Imagine a high-bandwidth, high-delay link such as a satellite channel with a window size of 200 segments. The sender transmits 200 segments at a time. If cumulative acknowledgments are used and the first segment is dropped, the sender needlessly retransmits many of the successfully received segments before the dropped segment is recovered. Selective acknowledgments eliminate needless retransmissions of successfully received segments.


TCP Sliding Windows

To govern the amount of data that can be sent at any one time and to provide receiver-side flow control, data transfer between TCP peers is performed using a window. The window is the span of data on the byte stream that the receiver permits the sender to send. The sender can send only the bytes of the byte stream that lie within the window. New data can be sent only with the receiver's permission. The window slides along the sender's outbound byte stream and the receiver's inbound byte stream.

The values of the Acknowledgment Number and Window fields in ACKs that the receiver sends determine the actual bytes within the window. The Acknowledgment Number field indicates the next byte of data that the receiver expects to receive. The Window field indicates the amount of space left in a receive buffer to store incoming TCP data on this connection. The span of data within the window is from Acknowledgment Number through the value of Acknowledgment Number + Window - 1.

For a given logical pipe—one direction of the full-duplex TCP connection—the sender maintains a send window and the receiver maintains a receive window. When there are no data or ACK segments in transit, a logical pipe's send window and receive window are matched. In other words, the span of data that the sender is permitted to send is matched to the span of data that the receiver is able to receive.

Send Window

To maintain the send window, the sender must account for the bytes in the outbound byte stream that have been

  • Sent and acknowledged (Sent/ACKed)
  • Sent but not acknowledged (Sent/UnACKed)
  • Unsent but fit within the current send window (Unsent/Inside)
  • Unsent but lie beyond the current send window (Unsent/Outside)

Figure 14-3 illustrates the types of data that exist for the send window.

Figure 14-3. The types of data for the TCP send window.

The span of data that lies within the send window is the Sent/UnACKed and Unsent/Inside data.

Sent/ACKed Data

Sent/ACKed data is data that has been sent and acknowledged as received. The first byte of Sent/ACKed data is the value of ISN + 1. Recall from the TCP connection establishment process that the TCP peer chooses an ISN that is explicitly acknowledged as if it were a data byte. Therefore, the first byte of user data sent on the connection is ISN + 1. Recall also that the acknowledgment number is the next byte of data the receiver expects to receive, explicitly acknowledging all bytes received up to but not including the acknowledgment number. Therefore, the last byte of ACKed data is the value of Acknowledgment Number - 1.

Sent/UnACKed Data

Sent/UnACKed data is data that has been sent but for which no acknowledgments have been received. The Sent/UnACKed data is either in transit, dropped from the internetwork, has arrived at the receiver but no ACK has been sent (because of delayed acknowledgments), or the ACK for the Sent/UnACKed data is in transit.

To distinguish Sent/UnACKed data from Unsent/Inside data, TCP maintains a variable known as SND.NXT, which is the value of the next byte to be sent. The value of SND.NXT becomes the value of the Sequence Number field for the next TCP segment sent.

The first byte of Sent/UnACKed data is the Acknowledgment Number field's value of the last ACK segment received from the receiver. The last byte of Sent/UnACKed data is the value of SND.NXT - 1.

Unsent/Inside Data

Unsent/Inside data is data that has not yet been sent but is within the current send window. Unsent/Inside data can be sent because the receiver has permitted it. It is natural to assume that if the data has been permitted, the sender will send all data within the send window before waiting for an acknowledgment and an updated window size from the receiver. In other words, there is no Unsent/Inside data when waiting for an acknowledgment.

However, as discussed later in this chapter, when starting the initial data flow and when encountering congestion, the sender-side flow control mechanisms of slow start and congestion avoidance prevent the sender from sending all the data that falls within the receiver's send window. In such cases, these mechanisms govern the amount of data sent before waiting for an acknowledgment.

The first byte of Unsent/Inside data is the value of the SND.NXT variable. The last byte of Unsent/Inside data is the last byte of data within the send window, the value of Acknowledgment Number + Window - 1.

Unsent/Outside

Unsent/Outside data is data that is unsent and outside the current send window, representing future data to be sent. Unsent/Outside data relative to the current send window should never be sent because it falls outside the receive window. The receiver's receive window is a direct reflection of buffer space remaining to store incoming data. The receiver discards data that cannot be stored in the receive buffer for the connection, and sends an ACK segment with the current acknowledgment number. The first byte of Unsent/Outside data is the value of Acknowledgment Number + Window.

Sliding the Send Window

The send window has a left edge (defined by the boundary between Sent/ACKed and Sent/UnACKed data) and a right edge (defined by the boundary between Unsent/Inside and Unsent/Outside data). When an ACK is received with a higher acknowledgment number, the send window closes and the left edge advances to the right. When an ACK is received in which the value of Acknowledgment Number + Window is greater than the previous value of Acknowledgment Number + Window, the send window opens and the right edge advances to the right. The sum of the Acknowledgment Number + Window fields in an ACK is the acknowledgment number of the ACK for the last TCP segment that fits within the current send window. Figure 14-4 illustrates the sliding of the send window.

Figure 14-4. The sliding of the send window showing window closing and opening.

It is possible for the send window to close but not open—for the left edge of the send window to advance while the right edge does not. For example, the sender receives an ACK with an increased acknowledgment number but a decreased window, such that the sum of Acknowledgment Number + Window does not change. This can happen when the receiver receives the data, which is acknowledged, but the received data has not been passed to the Application Layer protocol on the receiver. Therefore, the value of the Acknowledgment Number field in the ACK increases because of the contiguous data arriving, but the window decreases by the same amount, keeping the value of Acknowledgment Number + Window the same.

Zero Send Window

When the receiver advertises a window size of zero, the left and right edges of the send window are at the same boundary—the boundary between Sent/ACKed data and Unsent/Outside data. A zero window size can occur when the receiver's receive buffer fills with acknowledged data but the data has not yet been retrieved by the Application Layer protocol. This can happen when TCP has not yet indicated the data to the Application Layer protocol or when the Application Layer protocol has not explicitly informed TCP that it is ready to receive the next block of data from the TCP receive buffer.

With a zero send window, no new data can be sent until an ACK with a nonzero window size is received. However, because no new data is sent, the receiver is not sending any new ACKs. This can produce a deadlock situation in which the sender waits to receive a new window size and the receiver does not send a new window size because there are no new ACKs to send. Consequently, receiver and sender behaviors are defined to prevent the deadlock.

When the data in the TCP receive buffer is passed to the Application Layer protocol, the receiver sends an ACK segment with the current acknowledgment number and new nonzero window size. However, this segment is an ACK containing no data. ACK segments without data are not sent reliably; the receiver does not acknowledge them, nor does the sender retransmit the ACK segments when it does not receive acknowledgment of their receipt. Therefore, if an ACK sent by the sender to update the window size is lost, the sender would have no notification that new data can be sent. The TCP connection is indefinitely deadlocked; the receiver has informed the sender that new data can be sent, but the sender still considers the window size to be zero.

To prevent the deadlock of the dropped ACK that the receiver sent, the sender periodically sends a TCP segment containing 1 byte of new data for the connection. Because the data byte is Unsent/Outside data, the receiver discards the data and sends an ACK with the current acknowledgment number and window size. This sender-side mechanism is known as probing the window. The first window probe is sent after the current RTO, and the interval for successive probes is determined by doubling the timeout for the previous probe.

Receive Window

To maintain the receive window, the receiver must account for the bytes in the inbound byte stream that have been

  • Received, acknowledged, and retrieved by the Application Layer protocol (Rcvd/ACKed/Retr)
  • Received, acknowledged, and not retrieved by the Application Layer protocol (Rcvd/ACKed/NotRetr)
  • Received, but not acknowledged (Rcvd/UnACKed)
  • Not received, but inside the current receive window (NotRcvd/Inside)
  • Not received, but outside the current receive window (NotRcvd/Outside)

Figure 14-5 illustrates the types of data that exist for the receive window.

Figure 14-5. The types of data for the TCP receive window.

The span of data that lies within the maximum receive window is Rcvd/ACKed/NotRetr, Rcvd/UnACKed, and NotRcvd/Inside. The span of data that lies within the current receive window is Rcvd/UnACKed and NotRcvd/Inside.

Notice the difference between the maximum receive window and the current receive window. The maximum receive window is a fixed size and corresponds to a receive buffer used to store inbound TCP segments. The current receive window is of variable size and is the amount of space that is left in the receive buffer to store inbound TCP segments. The current receive window's size is the value of the Window field advertised in ACKs sent back to the sender, and is the difference between the maximum receive window size and the amount of data that has been received and acknowledged but not passed to the Application Layer protocol.

Rcvd/ACKed/Retr Data

Rcvd/ACKed/Retr data is data that has been received, acknowledged, and retrieved by the Application Layer protocol. The first byte of Rcvd/ACKed/Retr data is the value of ISN + 1. To track the next byte to be passed to the Application Layer protocol, TCP maintains a variable called RCV.USER. Therefore, the last byte of Rcvd/ACKed/Retr data is the value of RCV.USER - 1.

Rcvd/ACKed/NotRetr Data

Rcvd/ACKed/NotRetr data is data that has been received and acknowledged but has not been passed up to the Application Layer protocol. This category of data is the difference between the fixed-size maximum receive window and the variable-size current receive window. The first byte of Rcvd/ACKed/NotRetr data is the value of RCV.USER. The last byte of Rcvd/ACKed/NotRetr data is the value of Acknowledgment Number - 1.

Rcvd/UnACKed Data

Rcvd/UnACKed data is data that has been received but not acknowledged. To keep track of the next contiguous byte to be received, TCP maintains a variable called RCV.NEXT. When an ACK segment is sent, the ACK segment's Acknowledgment Number field is set to the value of RCV.NEXT. The first byte of Rcvd/UnACKed data is the current acknowledgment number. The last byte of Rcvd/UnACKed data is the value of RCV.NEXT - 1.

If there are no TCP segments in transit and the receiver has not yet sent the ACK for TCP segments received, the send window's Sent/UnACKed data is the same as the receive window's Rcvd/UnACKed data. In this situation, the value of RCV.NEXT kept by the receiver is equal to the value of SND.NEXT kept by the sender.

NotRcvd/Inside Data

NotRcvd/Inside data is data that can be received and will fit within the current receive window. The first byte of NotRcvd/Inside data is the value of RCV.NEXT. The last byte of NotRcvd/Inside data within the receive window is the value of Acknowledgment Number + Window - 1.

NotRcvd/Outside Data

NotRcvd/Outside data is data that has not been received and is outside the current receive window, representing future data to be received. NotRcvd/Outside data relative to the current receive window should never be received because it falls outside the current receive window. The receiver discards data that cannot be stored in the current receive window and sends an ACK with the current acknowledgment number. The first byte of NotRcvd/Outside data is the value of Acknowledgment Number + Window.

Sliding the Receive Window

The current receive window has a left edge (defined by the boundary between Rcvd/ACKed/NotRetr and Rcvd/UnACKed data) and a right edge (defined by the boundary between NotRcvd/Inside and NotRcvd/Outside data). When an ACK segment is sent with an acknowledgment number set to RCV.NEXT, the current receive window closes and the left edge advances to the right. When the Rcvd/ACKed/NotRetr data is passed up to the Application Layer protocol, the maximum receive window opens and the right edge advances to the right. When this occurs, space is made available in the fixed-size receive buffer and new data can be received. The maximum receive window slides to the right by the number of bytes passed to the Application Layer protocol. When the maximum receive window slides as a result of data being passed to the Application Layer protocol, the current receive window slides also, as the right edge of the maximum receive window and the current receive window are the same. The next ACK that the receiver sends contains an updated window size. The increase in the sum of the acknowledgment number and the window size indicates to the sender that more data can be sent.

Figure 14-6 illustrates the sliding of the receive window.

Figure 14-6. Sliding the receive window showing window closing, opening, and shrinking.

If the Application Layer protocol does not receive the data in a timely fashion, the receive window closes instead of sliding. This is indicated to the sender by increasing the acknowledgment number for new data received and decreasing the value of the Window field by the same amount, thereby keeping the value of Acknowledgment Number + Window the same. In an extreme situation, the maximum receive window is filled with Rcvd/ACKed/NotRetr data and the left and right edges are the same (a zero receive window).

Shrinking the Window

Shrinking the window is the movement of the right edge of the receive window to the left. To shrink the receive window, an ACK segment is sent where the value of Acknowledgment Number + Window decreases. Normally, the value of Acknowledgment Number + Window either increases or remains the same. RFC 1122 discourages shrinking the window. However, a sending TCP peer must be prepared to adjust its send window accordingly. The receiver discards any data sent that is suddenly outside the shrunken receive window.

TCP/IP for the Windows Server 2003 Family and Windows XP Maximum Receive Window Size

The TCP/IP for the Windows Server 2003 family and Windows XP maximum receive window size is set to 16,384 bytes by default. The default maximum receive window size and the MSS of the connection negotiated during the TCP connection establishment process determine the maximum receive window size. For maximum efficiency in bulk data transfers, the maximum receive window size is adjusted to be an integral multiple of the MSS for the connection.

The maximum receive window size is calculated using the following algorithm (based on the default maximum window size of 16,384 bytes):

  1. Assume a maximum receive window size of 16,384 bytes (16 KB). In the synchronize (SYN) segment sent to establish a TCP connection, include the TCP MSS option and set the window size to 16,384.
  2. When the SYN-ACK segment is returned, examine the TCP MSS option to determine the MSS for the connection (the minimum MSS of the two TCP peers).
  3. Based on the connection's MSS, divide 16,384 by the connection's MSS and round up to the next integer value.
  4. If the result of rounding up is not at least four times the connection's MSS, set the window size to four times the MSS (up to a maximum of 65,535). Window scaling must be in effect to use window sizes greater than 65,535.

Ethernet Example

For the maximum receive window size for an Ethernet-based TCP connection, the algorithm produces the following:

  1. Assume a maximum receive window size of 16,384 bytes (16 KB). In the SYN segment sent to establish a TCP connection, set the window size to 16,384.
  2. When the SYN-ACK segment is returned, examine the TCP MSS option to determine the connection's MSS (the minimum of the MSS of the two TCP peers). The MSS for two Ethernet-based TCP peers is 1460.
  3. Based on the connection's MSS, divide 16,384 by the connection's MSS and round up to the next integer value. Therefore, 16,384/1460 = 11.22, which, rounded up to the next integer value, is 12. Therefore, the maximum receive window size for two Ethernet TCP peers is 17,520 (12*1460).

The default of 17,520 for Ethernet assumes that additional TCP options, such as SACK and TCP timestamps, are not being used. If used, the maximum receive window size is adjusted accordingly.

Token Ring (4-Mbps Ring with an IP Maximum Transmission Unit of 4168)

For the maximum receive window size for a 4-Mbps Token Ring-based TCP connection, the algorithm produces the following:

  1. Assume a maximum receive window size of 16,384 bytes (16 KB). In the SYN segment sent to establish a TCP connection, set the window size to 16,384.
  2. When the SYN-ACK segment is returned, examine the TCP MSS option to determine the connection's MSS (the minimum of the MSS of the two TCP peers). The MSS for two 4-Mbps Token Ring TCP peers is 4128.
  3. Based on the connection's MSS, divide 16,384 by the connection's MSS and round up to the next integer value. Therefore, 16,384/4128 = 3.97, which, rounded up to the next integer value, is 4. Therefore, the maximum receive window size for two 4-Mbps Token Ring TCP peers is 16,512 (4*4128).

Token Ring (16-Mbps Ring with an IP MTU of 17,928)

For the maximum receive window size for a 16-Mbps Token Ring-based TCP connection, the algorithm produces the following:

  1. Assume a maximum receive window size of 16,384 bytes (16 KB). In the SYN segment sent to establish a TCP connection, set the window size to 16,384.
  2. When the SYN-ACK segment is returned, examine the TCP MSS option to determine the connection's MSS (the minimum of the MSS of the two TCP peers). The MSS for two 16-Mbps Token Ring TCP peers is 17,888.
  3. Based on the connection's MSS, divide 16,384 by the connection's MSS and round up to the next integer value. Therefore, 16,384/17,888 = 0.9, which, rounded up to the next integer value, is 1.
  4. The result of rounding up is not at least four times the connection's MSS. Therefore, the window size is set to four times the MSS, or 71,552 (17,888*4). However, without window scaling, this window size cannot be accommodated. Therefore, the maximum window size is set to a single MSS, or 17,888.

Changing the Default Maximum Receive Window Size

The default maximum receive window size can be set through the setsockopt() Windows Sockets function on a per socket basis or through the following registry settings:

GlobalMaxTcpWindowSize

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-0x3FFFFFFF

Present by default: No

GlobalMaxTcpWindowSize sets the number of bytes in the default maximum receive window for all interfaces (unless overridden per interface using the TcpWindowSize registry setting). Values greater than 65,535 can be used only in conjunction with enabling window scaling with the Tcp1323Opts registry setting and with TCP peers that sup- port window scaling. The maximum value, 0x3FFFFFFF, or 1,073,741,823, reflects the largest window size possible using window scaling.

TcpWindowSize

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

and

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
Interfaces\InterfaceGUID

Data type: REG_DWORD

Valid range: 0-0x3FFFFFFF

Present by default: No

TcpWindowSize (in Tcpip\Parameters) sets the number of bytes in the default maximum receive window for all interfaces unless overridden by the interface-based TcpWindowSize registry setting (in Tcpip\Parameters\Interfaces\InterfaceGUID). The default value is the smallest of the following values:

  • 0xFFFF (65,535)
  • GlobalMaxTcpWindowSize
  • Four times the connection MSS
  • 16,384 rounded up to an even multiple of the connection MSS

Values greater than 65,535 can be used only in conjunction with enabling window scaling (using the Tcp1323Opts registry setting), and with TCP peers that support window scaling. The maximum value, 0x3FFFFFFF, or 1,073,741,823, reflects the largest window size possible using window scaling. TCP also adjusts the window size based on the bit rate of the sending interface in the following way: below 1 Mbps, the window size is set to 8 KB; from 1 Mbps to 100 Mbps, the window size is set to 17 KB; and for 100 Mbps or higher, the window size is set to 64 KB.


Small Segments

A small segment is a TCP segment that is smaller than the MSS. To increase the efficiency of sending data, TCP avoids sending and receiving small segments by using the Nagle algorithm and by avoiding silly window syndrome.

The Nagle Algorithm

For interactive data, such as the data of a Telnet or Rlogin session, much of the traffic is made up of individual keystrokes sent by the client and echoed by the server. For each keystroke, a single byte of data is sent. This is a network efficiency of 2.5 percent (the number of bytes of data [1 byte] divided by the number of bytes of overhead needed to send the data [40 bytes]). For interactive sessions, such as Telnet, each typed character must be sent and echoed back to the Telnet client application to be displayed on the user's screen. Therefore, sending small segments cannot be avoided for interactive sessions. Preventing the sending of a small segment would mean that the user would not see the keystroke as entered on the keyboard.

In the case of Telnet and Rlogin, a single keystroke echoed back to the user generates the following three TCP segments:

  1. The client application sends the keystroke byte as a small TCP segment with the Push (PSH) flag set.
  2. The keystroke TCP segment is passed to the server application, which sends an echo of the keystroke back to the client application (along with an ACK of the keystroke byte) as a small TCP segment with the PSH flag set.
  3. The echoed keystroke TCP segment is passed to the client application, which sends an ACK of the echoed keystroke segment.

Typical interactive sessions consist of multiple keystrokes in rapid succession.

To minimize the sending of small TCP segments, TCP is required to use the Nagle algorithm, named after John Nagle, the author of RFC 896, which describes the algorithm. The Nagle algorithm's premise is that a TCP connection can send only a single unacknowledged small segment. If a small segment is sent and not acknowledged, no other small segments can be sent.

The Nagle algorithm is described in RFC 896, which can be found in the \Rfc folder on the companion CD-ROM.

In the case of interactive session traffic, such as Telnet and Rlogin, a keystroke segment is sent. Additional keystrokes entered by the user are accumulated in the TCP send buffer until the ACK for the outstanding small segment arrives. The next segment sent could contain multiple keystrokes. Depending on the average time to receive acknowledgments and the user's typing speed, this simple rule can decrease the number of TCP segments sent in the session by a factor of three or more.

The Nagle algorithm adapts itself to the environment in which the TCP segments are being sent. In a high-bandwidth, low-delay environment, such as a local area network (LAN), ACKs return more quickly and less accumulation occurs. However, in such an environment, lower efficiency can be tolerated because of the higher capacity of the LAN. In a low-bandwidth, high-delay environment, such as a wide area network (WAN), ACKs return less quickly, producing more accumulation. This results in more efficient data transfer for environments with less capacity.

TCP/IP for the Windows Server 2003 family and Windows XP uses the Nagle algorithm by default. The Nagle algorithm is disabled through the TCP_NODELAY Windows Sockets option. Developers should disable the Nagle algorithm only when the immediate sending of multiple small segments is required. To improve performance of file locking and manipulation, a computer running a member of the Windows Server 2003 family or Windows XP disables the Nagle algorithm for NetBIOS over TCP/IP (NetBT) and non-NetBIOS-based redirector and server communication.

Silly Window Syndrome

Whenever data is passed to the receiver's Application Layer protocol, the receive window opens and a new window size is advertised. Depending on how much data is retrieved from the receive buffer, this mechanism can cause the following behavior:

  1. The sender and receiver are in a zero window state. The sender has sent all the data it can. The receiver has acknowledged all the data in the receive buffer and is waiting for the Application Layer protocol to retrieve the data before it is free to advertise a nonzero window size.
  2. The Application Layer protocol retrieves a single byte of data from the receive buffer. The receive window advances by one byte.
  3. The receiver sends an ACK with the window size set to 1.
  4. The sender, realizing that the value of Acknowledgment Number + Window has increased, advances its send window by one byte. Because the receiver has permitted the sending of a single byte, the sender sends a single byte.

Each time the Application Layer protocol fetches a single byte of data from the buffer, the sender sends a single-byte TCP segment. The data sent on the TCP connection consists of a steady pattern of small segments. This behavior is known as the silly window syndrome (SWS). Both the sender and the receiver avoid SWS.

Receiver-Side SWS Avoidance

The receiver avoids SWS by not advertising a new window size unless it is at least either an MSS or half of the maximum receive window size. Figure 14-7 illustrates receiver-side SWS avoidance.

Figure 14-7. SWS avoidance as implemented by the receiver.

As data is passed to the application, the receive window advances. If the receive window advances n bytes, receiver-side SWS dictates that a new window size cannot be advertised unless n is at least MSS bytes or half the maximum receive window.

Sender-Side SWS Avoidance

The sender avoids SWS by not sending a TCP segment containing data unless the advertised receive window size is at least MSS bytes. However, as previously discussed, small segments must be allowed for interactive data. Therefore, small segments are allowed if either of the following is true:

  • The data is being pushed and adheres to the Nagle algorithm. Interactive data typically sets the TCP header's PSH flag. A single small segment can be sent according to the Nagle algorithm.
  • The data is at least half the size of the maximum receive window and adheres to the Nagle algorithm.


Sender-Side Flow Control

Receiver-side flow control is implemented through the send and receive windows. The receiver can inform the sender to stop sending data by reducing the advertised receive window to zero. However, once a nonzero receive window size is advertised, there is nothing in the TCP sliding window mechanism that prevents the sender from sending all possible segments in the send window.

For example, during the TCP connection process, the maximum receive window size is determined. If the TCP peers are Ethernet-based, the maximum receive window and the advertised receive window at the end of the TCP connection establishment process for two Windows Server 2003 family- or Windows XP-based hosts is 17,520 bytes, or 12 MSS-sized TCP segments (assuming no TCP options are present). According to the TCP sliding window mechanism, the sender can immediately send all 12 segments that fit within the receive window without waiting for any ACKs. Although this behavior is permitted, it also can lead to network congestion, especially when sending TCP segments across multiple routers.

To prevent the flooding of segments that fit within the advertised receive window, TCP implementations, including TCP/IP for the Windows Server 2003 family and Windows XP, use the following algorithms described in RFC 2001:

  • The slow start algorithm Increases the actual send window—the number of segments within the send window that the sender can send before waiting for an acknowledgment—for each ACK segment received that acknowledges new data.
  • The congestion avoidance algorithm Increases the actual send window for each round-trip time.

Although the slow start and congestion avoidance algorithms were developed to solve separate problems, they are used together to provide sender-side flow control.

Both the slow start and congestion avoidance algorithms maintain an additional variable called the congestion window (cwind) to help define how much data can be sent. For both algorithms, the size of the actual send window is the minimum of the advertised receive window and the congestion window (the value of cwind).

Slow Start Algorithm

The premise of the slow start algorithm is that TCP increases the cwind by the MSS (or one segment size) for every ACK received that acknowledges new data. Every time cwind is updated, it is compared to the current advertised receive window size, and the minimum of both values is used to update the actual send window size.

When TCP data begins to flow on a connection after the connection establishment process or after a prolonged idle time, the following slow start process is used to increase the actual send window size (assuming two Ethernet-based TCP peers):

  1. Set cwind's initial value to 2 MSS (two MSS-sized segments). Compare cwind's value and the currently advertised receive window size (17,520 or 12 MSS). Set the actual send window size to the minimum of cwind and the currently advertised receive window size. Result: cwind = 2 MSS, advertised receive window size = 12 MSS, actual send window = 2 MSS.
  2. Two TCP segments are sent. The sender waits for ACKs.
  3. When the sender receives an ACK, cwind is set to 3 MSS. Compare cwind's value and the currently advertised receive window size. Set the actual send window size to the minimum of cwind and the currently advertised receive window size. Result: cwind = 3 MSS, advertised receive window size = 12 MSS, actual send window = 3 MSS.
  4. Three TCP segments are sent. The sender waits for ACKs.
  5. When the sender receives an ACK, cwind is set to 4 MSS. Compare cwind's value and the currently advertised receive window size. Set the actual send window size to the minimum of cwind and the currently advertised receive window size. Result: cwind = 4 MSS, advertised receive window size = 12 MSS, actual send window = 4 MSS.
  6. Four TCP segments are sent. The sender waits for ACKs.

This process continues until cwind becomes greater than the currently advertised receive window (12 MSS), at which point the currently advertised receive window governs how much data can be sent at a time, and slow start is finished. There is no more sender-side flow control unless a TCP segment needs to be retransmitted.

The following Network Monitor trace (Capture 14-01, included in the \Captures folder on the companion CD-ROM) illustrates the slow start behavior for the downloading of a file using FTP up to 6 MSS:

17	FTP Server	FTP Client	....S.,	len:	0,	seq:	10482005-10482005,
                        ack:	0

18	FTP Client	FTP Server	.A..S.,	len:	0,	seq:	376829-376829,
                        ack:	10482006

19	FTP Server	FTP Client	.A...., 	len:	0,	seq:	10482006-10482006,
                        ack:	376830

20	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10482006-10483465,
                        ack:	376830

21	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10483466-10484925,
                        ack:	376830

22	FTP Client	FTP Server	.A....,	len:	0,	seq:	376830-376830,
                        ack:	10484926

23	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10484926-10486385,
                        ack:	376830

24	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10486386-10487845,
                        ack:	376830

25	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10487846-10489305,
                        ack:	376830

26	FTP Client	FTP Server	.A....,	len:	0,	seq:	376830-376830,
                        ack:	10489306

27	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10489306-10490765,
                        ack:	376830

28	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10490766-10492225,
                        ack:	376830

29	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10492226-10493685,
                        ack:	376830

30	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10493686-10495145,
                        ack:	376830

31	FTP Client	FTP Server	.A....,	len:	0, 	seq:	376830-376830,
                        ack:	10495146

32	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10495146-10496605,
                        ack:	376830

33	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10496606-10498065,
                        ack:	376830

34	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10498066-10499525,
                        ack:	376830

35	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10499526-10500985,
                        ack:	376830

36	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10500986-10502445,
                        ack:	376830

37	FTP Client	FTP Server	.A....,	len:	0,	seq:	376830-376830,
                        ack:	10500986

38	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10502446-10503905,
                        ack:	376830

39	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10503906-10505365,
                        ack:	376830

40	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10505366-10506825,
                        ack:	376830

41	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10506826-10508285,
                        ack:	376830

42	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10508286-10509745,
                        ack:	376830

43	FTP Server	FTP Client	.A....,	len:	1460,	seq:	10509746-10511205,
                        ack:	376830

The slow start algorithm for this data transfer is as follows:

  1. The TCP connection establishment process is done in Frames 17 through 19. cwind is set to 2 MSS.
  2. Frames 20 and 21 are the two segments corresponding to the current actual send window size of 2 MSS.
  3. Frame 22 is an ACK segment for Frames 20 and 21. cwind is set to 3 MSS.
  4. Frames 23 through 25 are the three segments corresponding to the current send actual window size of 3 MSS.
  5. Frame 26 is an ACK segment for Frames 23 to 25. cwind is set to 4 MSS.
  6. Frames 27 through 30 are the four segments corresponding to the current actual send window size of 4 MSS.
  7. Frame 31 is an ACK segment for Frames 27 through 30. cwind is set to 5 MSS.
  8. Frames 32 through 36 are the five segments corresponding to the current actual send window size of 5 MSS.
  9. Frame 37 is an ACK segment for Frames 21 through 35. cwind is set to 6 MSS.
  10. Frames 38 through 43 are the six segments corresponding to the current actual send window size of 6 MSS.

The rate at which the size of the actual send window increases depends on how quickly ACK segments are returned. In a high-bandwidth, low-delay environment such as a LAN, the actual send window opens quickly. In a low-bandwidth, high-delay environment such as a WAN, the actual send window opens more slowly.

Although called the slow start algorithm, the actual send window size can increase at an exponential rate based on the receipt of multiple ACKs for multiple segments sent. For example, when starting the actual send window at 2 MSS, two segments are sent. If an ACK is sent for each segment sent, the actual send window increases to 4 MSS; four segments are sent. If an ACK is sent for each segment sent, the actual send window increases to 8 MSS. The actual send window has quickly grown from 2 MSS to 4 MSS, and then to 8 MSS. The actual window growth depends on how many ACK segments are received.

Congestion Avoidance Algorithm

Once data is flowing on the TCP connection, the actual send window is governed by the currently advertised receive window and receiver-side flow control is in effect. When a TCP segment must be retransmitted, the assumption is that the packet loss is a result of congestion at a router, rather than damage to the packet causing a checksum verification to fail. If the packet loss is a result of congestion at a router, the sender's transmission rate must be immediately lowered and then gradually increased back to the rate at which data was being sent before the congestion occurred. For TCP connections, the transmission rate is the amount of data that the sender can send before having to wait for an ACK.

When the congestion occurs, the slow start algorithm is used to increase the size of the actual window size to half of the value of the advertised receive window size when the congestion occurred. The congestion avoidance algorithm then takes over. To keep track of when to use slow start and when to use congestion avoidance, an additional variable called the slow start threshold (ssthresh) is used. When a connection is established, ssthresh is set to 65,535. As with slow start, during congestion avoidance, the actual send window is the minimum of cwind and the currently advertised receive window.

The premise of the congestion avoidance algorithm is to increase cwind by 1 MSS for each round-trip time, which is the time it takes for a TCP segment to be sent and acknowledged. The congestion avoidance algorithm provides a smooth, linear increase in cwind, thereby increasing the actual send window. There are different ways of implementing the change in cwind for congestion avoidance, as follows:

  • One method is to increase cwind by MSS*MSS/cwind (integer division) for each segment that is acknowledged. For example, if cwind is set to 7 MSS, for each segment that is acknowledged, cwind is incremented by MSS*MSS/7*MSS, or MSS/7. Therefore, after seven acknowledged segments, cwind increases by 1 MSS. When cwind is incremented by a quantity that is not a full MSS, sender-side SWS prevents a small segment from being sent. Only after cwind is incremented to another MSS can another full segment be sent.
  • Another method is to track the current actual send window size in increments of the MSS. When the number of segments that correspond to the size of the current actual send window size are ACKed, increment cwind by an MSS. Thus, the actual send window grows by 1 MSS for each full window of data that has been acknowledged.

With slow start, the actual send window increases by an MSS for each ACK received in a round-trip time. With congestion avoidance, the actual send window increases by an MSS for multiple ACKs received in a round-trip time.

When congestion occurs (indicated when a TCP segment must be retransmitted or when a duplicate ACK is received), the combination of slow start and congestion avoidance for TCP/IP for the Windows Server 2003 family and Windows XP works as follows:

  1. Set ssthresh to half the value of the current send window with a minimum value of 2 MSS. cwind is set to the value of 2 MSS.
  2. Set the actual send window to the minimum of the currently advertised receive window and cwind.
  3. Send the appropriate number of TCP segments.
  4. As ACKs are received, increment cwind. If cwind ≤ ssthresh, increment cwind using slow start. If cwind > ssthresh, increment cwind using congestion avoidance.
  5. Return to step 2.

The result of using the combination of slow start and congestion avoidance is that when congestion occurs, the sender uses slow start to quickly increase the size of the actual send window size to half the size of the actual send window when the congestion occurred. Then, congestion avoidance is used to more slowly increase the size of the actual send window size up to the currently advertised receive window size. This gradual increase in the amount of data being sent allows the internetwork to clear its routing buffers and recover from the congestion.


Summary

TCP achieves reliable data transfer through the cumulative or selective acknowledgment of TCP segments received. Selective acknowledgments improve TCP performance in high-loss environments or for TCP connections with large window sizes. To provide receiver-side flow control, TCP uses sliding send and receive windows. With each ACK segment, the receiver indicates how much more data can be sent and successfully buffered. To avoid sending small segments, TCP uses the Nagle algorithm and SWS avoidance. To provide sender-side flow control, TCP uses the slow start and congestion avoidance algorithms. Slow start is used to increase the size of the actual send window by 1 MSS for each ACK segment received. Congestion avoidance is used to increase the size of the actual send window by 1 MSS for each round-trip time. Slow start and congestion avoidance are used to avoid congesting an IP internetwork when sending and retransmitting data.


Transmission Control Protocol (TCP) Retransmission and Time-Out

Chapter 15
Transmission Control Protocol (TCP) Retransmission and Time-Out

The reliable service of TCP requires that all segments containing data be acknowledged by the receiver. When an acknowledgment (ACK) for a segment is not received within a determined amount of time, the sender retransmits the segment. The sender might retransmit the segment multiple times before abandoning the connection. The retransmission and time-out behaviors of TCP directly affect TCP performance and can help prevent congestion on the internetwork.


Retransmission Time-Out and Round-Trip Time

For each connection, TCP maintains a variable called the retransmission time-out (RTO), which is the amount of time within which an ACK for the segment is expected. If TCP does not receive an ACK before the RTO expires, the segment is retransmitted.

The RTO must allow enough time for the following:

  1. The initially sent TCP segment to traverse the internetwork (the transit time from source to destination).
  2. The initially sent TCP segment to be received and processed by the destination node (the destination's inbound packet-processing time).
  3. The generation of an ACK for the segment (the ACK generation time). One component of the ACK generation time is the delayed acknowledgment time of the destination node. Rather than sending an ACK segment for each TCP data segment received, TCP delays ACKs. These delayed ACKs can contain data, include updated window sizes, and acknowledge multiple segments received.
  4. The generated ACK to traverse the internetwork (the transit time from destination to source).
  5. The generated ACK to be received and processed by the sending node (the source's inbound packet-processing time).

The sum of all these times is known as the round-trip time (RTT). The RTT varies over time and must be constantly measured throughout the TCP connection's life. The RTO is based on the currently known RTT and should always be greater than the currently known RTT to prevent unnecessary retransmissions.

The RTO should be neither too large nor too small to prevent the following behaviors:

  • When the RTO is too large, the sending TCP peer must wait too long before retransmitting a lost segment. This lowers throughput for connections with some degree of packet loss.
  • When the RTO is too small, segments are retransmitted unnecessarily. Retransmitted segments increase the load on the internetwork and waste internetwork capacity.

If the ACK for the initially sent segment does not arrive within the RTO, the ACK is either arriving late or not at all. The main causes of ACK segments arriving late are either an increase in the transit time from the source to the destination or an increase in the transit time from the destination to the source.

The following are reasons why the ACK is not received at all:

  • The initially sent TCP segment is dropped at a router because of congestion.
  • The initially sent TCP segment is dropped at a router or the destination because of damage to the packet, which occurs when electronic or optical errors corrupt the encoded signal, causing bits within the packet to change values. Damaged packets are silently discarded after failing checksum calculations.
  • The ACK for the TCP segment is dropped at a router because of congestion.
  • The ACK for the TCP segment is dropped at a router or the destination because of damage to the packet.

It is much more likely that the TCP segment or its ACK was discarded by a congested router rather than being damaged and silently discarded.

Unlike TCP segments containing data, ACKs that contain no data are not sent reliably. The ACK sender does not set an RTO for the ACK and does not retransmit the ACK segment. Therefore, a lost ACK is recovered by the sender retransmitting the segment(s) that the lost ACK is acknowledging, and not by the sender of the lost ACK retransmitting the ACK.

Congestion Collapse

The proper measurement of the RTT and determination of the RTO for sent TCP segments are important to prevent a phenomenon of routed internetworks known as congestion collapse. Congestion collapse occurs when the buffers of the internetwork routers fill to capacity and the routers begin to discard packets.

Congestion collapse begins with a steady increase in the load on the internetwork. As hosts send more data, more data is queued in the buffers of the internetwork routers. As this occurs, the transit time from the source to the destination and from the destination to the source increases. Therefore, the actual RTT grows larger than the currently known RTT of sending hosts.

The current RTO for sent segments is based on the currently known RTT. When the actual RTT increases to the extent that it is greater than the current RTO, sent TCP segments have ACKs that arrive late. When the ACKs do not arrive in the time based on the current RTO, the segments are retransmitted. There are then two copies of each retransmitted segment, effectively doubling the load on the internetwork at a time when the load needs to be decreased. As more TCP segments are retransmitted, eventually the buffers on the internetwork routers fill and the routers begin to discard packets.

Congestion collapse can be avoided through the ongoing determination of the current RTT, which is monitored on a per window or per segment basis. Changes in the current RTT are used to update the RTO.

The recurrence of congestion collapse is avoided through the combination of the slow start and congestion avoidance algorithms of the sending host, as discussed in Chapter 14, "Transmission Control Protocol (TCP) Data Flow." When the RTO for a segment expires, TCP assumes that RTO expiration is a result of the segment being discarded by a router experiencing congestion. Slow start and congestion avoidance are used to slowly scale the number of segments sent before waiting for an ACK up to the number of segments that fit in the receiver's advertised receive window.

Slow start and congestion avoidance are used together to prevent congestion collapse from recurring. Without slow start and congestion avoidance, once an internetwork becomes congested, it becomes congested again as the sending hosts begin transmitting new data and the internetwork oscillates between congested and uncongested states.


Retransmission Behavior

TCP uses the following exponential backoff behavior to determine the RTO of successive retransmissions of the same segment:

  1. When the TCP segment is initially sent, the RTO for the segment is set to the currently known RTO for the connection.
  2. After RTO number of seconds, when the RTO expires, the segment RTO is set to twice the RTO for the segment's previous transmission and retransmitted.

Step 2 is repeated for the maximum number of retransmissions before the TCP connection is abandoned. For TCP/IP for the Microsoft Windows Server 2003 family and Windows XP, the TcpMaxDataRetransmissions registry setting controls the maximum number of retransmissions.

TcpMaxDataRetransmissions

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-0xFFFFFFFF

Default value: 5

Present by default: No

TcpMaxDataRetransmissions sets the maximum number of retransmissions of a TCP segment containing data before the connection is abandoned.

The following Network Monitor trace (Capture 15-01, included in the \Captures folder on the companion CD-ROM) shows the maximum number of retransmissions and the doubling of the RTO between successive retransmissions:

1	 0.000000     LOCAL           0060083E4607    TCP         .A...., len:
     0, seq:   1311725-1311725, ack:23 FTP Server         FTP Client

2        0.000000     0060083E4607    LOCAL           FTP         Data
Transfer To Server, Port = 1296, size 1460   FTP Client         FTP Server

3        0.000000     0060083E4607    LOCAL           FTP         Data
Transfer To Server, Port = 1296, size 1460   FTP Client         FTP Server

4        0.000000     0060083E4607    LOCAL           FTP         Data
Transfer To Server, Port = 1296, size 1460   FTP Client         FTP Server

5        0.000000     0060083E4607    LOCAL           FTP         Data
Transfer To Server, Port = 1296, size 1460   FTP Client         FTP Server

6        0.000000     0060083E4607    LOCAL           FTP         Data
Transfer To Server, Port = 1296, size 1460   FTP Client         FTP Server

7        0.000000     0060083E4607    LOCAL           FTP         Data
Transfer To Server, Port = 1296, size 1460   FTP Client         FTP Server

8        0.500720     0060083E4607    LOCAL           FTP         Data
Transfer To Server, Port = 1296, size 1460   FTP Client         FTP Server

9        1.001440     0060083E4607    LOCAL           FTP         Data
Transfer To Server, Port = 1296, size 1460   FTP Client         FTP Server

10       2.002880     0060083E4607    LOCAL           FTP         Data
Transfer To Server, Port = 1296, size 1460   FTP Client         FTP Server

11       4.005760     0060083E4607    LOCAL           FTP         Data
Transfer To Server, Port = 1296, size 1460   FTP Client         FTP Server

12       8.011520     0060083E4607    LOCAL           FTP         Data
Transfer To Server, Port = 1296, size 1460   FTP Client         FTP Server

This Network Monitor trace was captured from a File Transfer Protocol (FTP) client on which the uploading of a file was in progress and the cable connecting the network adapter of the FTP server was pulled. Frames 8 through 12 show the retransmission behavior of TCP/IP for the Windows Server 2003 family and Windows XP. Notice how the initial RTO is 0.5 seconds and successive retransmissions have RTOs that are doubled. After the last retransmission, the FTP server waits 16 seconds before abandoning the connection and recovering the connection's resources. It takes a total of 31.5 seconds to abandon the connection. The connection abandonment time is 63 times the RTO for the connection (the sum of RTO for the initial segment sent, 2*RTO for the first retransmission, 4*RTO for the second retransmission, 8*RTO for the third retransmission, 16*RTO for the fourth retransmission, and 32*RTO for the fifth retransmission).

The RTOs are doubled, but the elapsed time for sending the retransmitted segment might not be exactly doubled for other Network Monitor traces because of delays in processing, queuing, and the physical transmission of network frames.

Retransmission Behavior for New Connections

For new connections initiated by a Windows Server 2003 family- or Windows XP-based host, the TcpMaxConnectRetransmissions registry setting determines the maximum number of retransmissions of the synchronize (SYN) segment.

TcpMaxConnectRetransmissions

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-255

Default value: 2

Present by default: No

TcpMaxConnectRetransmissions sets the maximum number of retransmissions of a SYN segment before the connection attempt is abandoned. Exponential backoff is used between successive retransmissions of the SYN segment. With an initial RTO value of 3 seconds, it takes 21 seconds to abandon a connection attempt (the sum of 3 seconds for the initial SYN, 6 seconds for the first retransmission, and 12 seconds for the second retransmission). The initial RTO's value is controlled using the TcpInitialRTT registry setting described in the section entitled "Calculating the RTO," later in this chapter.

For new connections initiated by a TCP peer for a Windows Server 2003 family- or Windows XP-based host, the TcpMaxConnectResponseRetransmissions registry setting determines the SYN-ACK segment's maximum number of retransmissions.

TcpMaxConnectResponseRetransmissions

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-255

Default value: 2

Present by default: No

TcpMaxConnectResponseRetransmissions sets the maximum number of retransmissions of a SYN-ACK segment sent in response to a SYN segment before the connection attempt is abandoned. Exponential backoff is used between successive retransmissions of the SYN-ACK segment. With an initial RTO value of 3 seconds, it takes 21 seconds to abandon the connection (the sum of 3 seconds for the first SYN, 6 seconds for the first retransmission, and 12 seconds for the second retransmission). If TcpMaxConnectResponseRetransmissions is greater than 1, SYN attack protection is used. See Chapter 13, "Transmission Control Protocol (TCP) Connections," for more information on the SYN attack.

Dead Gateway Detection

Dead gateway detection is an algorithm that detects the failure of the currently configured default gateway. If it detects a failure, dead gateway detection automatically switches to a new default gateway, provided there are multiple default gateways configured. Dead gateway detection uses TCP retransmission behavior to detect and recover from a downed router configured as the default gateway.

When an individual TCP connection retransmits a segment multiple times (half of TcpMaxDataRetransmissions), its next-hop IP address is changed to the next default gateway. When 25 percent of all TCP connections using the failed default gateway have been moved to the next default gateway, the default route in the IP routing table is updated with the next default gateway as the next-hop IP address.

If the new default gateway is unavailable, dead gateway detection is used to switch to the next default gateway in the configured list. When the last default gateway in the list is reached and becomes unavailable, the next default gateway is the first default gateway in the list. When the computer is restarted, the first default gateway in the list is used.

For a detailed example of how dead gateway detection works, consider a host with the following configuration:

  • The IP address of 10.0.0.99/24.
  • Two default gateways are configured: 10.0.0.1 and 10.0.0.2.
  • The default route 0.0.0.0/0 has 10.0.0.1 as its next-hop IP address.
  • There are currently 10 TCP connections for locations off the 10.0.0.0/24 subnet using 10.0.0.1 as their next-hop IP address.
  • TcpMaxDataRetransmissions is set at its default value of 5.

When the router at 10.0.0.1 fails, dead gateway detection uses the following process to change the default route to use the next-hop IP address of 10.0.0.2:

  1. A TCP connection (one of the 10 TCP connections at the host) sends a data segment. Because no ACK is received, the segment is retransmitted. After the third retransmission, the next-hop IP address for this specific TCP connection is changed to 10.0.0.2. At this point, 10 percent of the TCP connections using the next-hop IP address of 10.0.0.1 have been switched to 10.0.0.2.
  2. Another TCP connection sends a data segment. Because no ACK is received, the segment is retransmitted. After the third retransmission, the next-hop IP address for this specific TCP connection is changed to 10.0.0.2. At this point, 20 percent of the TCP connections using the next-hop IP address of 10.0.0.1 have been switched to 10.0.0.2.
  3. Another TCP connection sends a data segment. Because no ACK is received, the segment is retransmitted. After the third retransmission, the next-hop IP address for this specific TCP connection is changed to 10.0.0.2. At this point, 30 percent of the TCP connections using the next-hop IP address of 10.0.0.1 have been switched to 10.0.0.2.
  4. Because more than 25 percent of the TCP connections using 10.0.0.1 as their next-hop IP address have had their next-hop IP addresses changed, the default route in the IP routing table is updated to use 10.0.0.2 as the next-hop IP address.

The EnableDeadGWDetect registry setting controls dead gateway detection in TCP/IP for the Windows Server 2003 family and Windows XP.

EnableDeadGWDetect

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 0-1

Default value: 1

Present by default: Yes

EnableDeadGWDetect enables (when set to 1) or disables (when set to 0) dead gateway detection. Dead gateway detection is enabled by default.

Dead gateway detection can change the default gateway configuration even when the local default gateway is functioning and a remote router fails. If a remote router in the path of traffic for TCP connections fails, TCP retransmissions for multiple TCP connections can cause dead gateway detection to switch default gateways.

Using the Selective Acknowledgment (SACK) TCP Option

The SACK TCP option allows the receiver to selectively acknowledge noncontiguous blocks of data received. However, the sender should not discard selectively acknowledged segments from its transmission queue until the segments are included in a cumulative acknowledgment.

RFC 2018 allows the data receiver to discard noncontiguous segments even though they have been selectively acknowledged. This is known as reneging on a selective acknowledgment, and its practice is discouraged. To keep reneged data from being lost on a connection, the sender must retransmit selectively acknowledged data until it is acknowledged by the Acknowledgment Number field in an ACK from the receiver.

TCP selective acknowledgments are described in RFC 2018, which can be found in the \Rfc folder on the companion CD-ROM.

The retransmission behavior of selectively acknowledged segments is as follows:

  1. For each segment, maintain a selective acknowledgment flag that is enabled when the segment is selectively acknowledged.
  2. When initial RTO timers begin to expire, only retransmit the segments that have not been selectively acknowledged (segments for which the selective acknowledgment flag is disabled).
  3. If an ACK is received that cumulatively acknowledges the retransmitted segment, the send window closes and opens depending on the new Acknowledgment Number + Window sum and new segments can be sent. The selective acknowledgment flags on noncumulatively acknowledged segments are maintained.
  4. If a retransmitted segment times out, indicating that the receiver might have reneged on the selectively acknowledged segments, disable the selective acknowledgment flags of all segments in the current window and retransmit them normally.

This mechanism recovers from the possibility that the receiver discarded the noncontiguous received segments. If necessary, the entire window of data is resent.


Calculating the RTO

The determination of the RTO is an important function of TCP. The RTO must be adjusted to the internetwork's changing conditions. If the determined RTO is less than the RTT, segments are unnecessarily retransmitted.

In RFC 793, the suggested method of computing the RTO—known as the smoothed round-trip time (SRTT)—is based on the following formulas:

SRTT = (a*SRTT) + ((1-a)*RTT)

RTO = min[UpperBound, max[LowerBound,(b *SRTT)]]

Thus, the new RTO is based on the determination of the current RTT, the previous SRTT, a smoothing factor (a), and a variance factor (b). RFC 793 cited this formula as an example method of computing the RTO. In practice, this formula was found to be inadequate in determining the RTO in an environment in which the RTT changed suddenly. Instead, RFC 1122 states that TCP must use the following formulas as documented in "Congestion Avoidance and Control," a paper written by Van Jacobson and Michael J. Karels:

SRTT = RTT + 8*(New_RTT - RTT)

Dev = Dev + (|New_RTT - RTT| - Dev)/4

RTO = SRTT + Dev/4

This new way of calculating the RTO is based on the average and variance (Dev) of the RTT. The RTO is self-tuning for different environments (the low-delay local area network [LAN] and the high-delay wide area network [WAN]) and is sensitive to sudden changes in the RTT for environments such as the Internet.

RTO calculation is described in RFCs 793 and 1122, which can be found in the \Rfc folder on the companion CD-ROM.

For TCP/IP for the Windows Server 2003 family and Windows XP, the TcpInitialRTT registry setting controls the RTO's initial value for establishing connections or sending data on new connections.

TcpInitialRTT

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
\Interfaces\InterfaceGUID

Data type: REG_DWORD

Valid range: 0-0xffff

Default value: 3

Present by default: No

TcpInitialRTT sets the number of seconds for the initial RTO for SYN segments, SYN-ACK segments, and initial data segments sent on a new connection for each interface. Increasing this value from its default has a multiplicative effect on the amount of time it takes to time-out from a connection establishment or when sending data on a new connection.

For new connections being established by a host, the connection abandonment time is 7*TcpInitialRTT (assuming the default value of TcpMaxConnectRetransmissions). For arbitrary values of TcpInitialRTT and TcpMaxConnectRetransmissions, the connection abandonment time is

TcpInitialRTT*[2 (TcpMaxConnectRetransmissions+1) - 1]

For new connections being requested from a host, the connection abandonment time is 7*TcpInitialRTT (assuming the default value of TcpMaxConnectResponseRetransmissions). For arbitrary values of TcpInitialRTT and TcpMaxConnectResponseRetransmissions, the connection abandonment time is

TcpInitialRTT*[2 (TcpMaxConnectResponseRetransmissions+1) - 1]

As data segments are sent, the RTO is adjusted from the TcpInitialRTT to a value closer to the connection's RTT. By default, the connection's RTT is not sampled for each segment sent. Rather, the RTT is sampled once for every full send window of data sent. If the send window is 12*MSS (maximum segment size), the RTT is sampled once every 12 segments. For each sample of the RTT, the time that the sampled segment is sent is recorded based on the current value of an internal clock. When the ACK for the segment is received, the RTT is determined from the difference between the recorded value of when the segment was sent and the current value of the internal clock.

The RTT sampling rate is 1/(window size). For small window sizes, this sampling rate is adequate. However, for large windows, the sampling rate is inadequate and cannot keep up with rapid changes in the RTT. The result is increased network bandwidth utilization by unnecessary retransmissions when the currently known RTO is less than the current RTT. In these situations, the TCP Timestamps option is used to provide a sampling rate that is equal to the sending rate.

Using the TCP Timestamps Option

As described in Chapter 12, "Transmission Control Protocol (TCP) Basics," the TCP Timestamps option allows TCP peers to place a timestamp value on each segment. The TCP Timestamps option contains two 32-bit fields to track timestamps: TS Value and TS Echo Reply. The TS Value field stores the current timestamp value. The TS Echo Reply field stores the timestamp echo, the value of the TS Value field of the segment being acknowledged.

The use of TCP timestamps allows an RTT to be calculated by subtracting the timestamp echo in the ACK from the current time value of the timestamp clock.

As an example, TCP Peer A sends a data segment to TCP Peer B, which sends an ACK back. The data segment's TS Value is 1285458 when it is sent and is echoed in the ACK segment's TS Echo Reply field. When the ACK is received and processed, the current value of TCP Peer A's timestamp clock is 1286506. Therefore, the RTT for this segment is based on the TCP timestamp value of 1048, or 1286506 - 1285458.

This basic method of RTT determination is complicated by the following factors:

  • There might be pauses in sending data.
  • ACKs are delayed and can acknowledge multiple TCP segments.
  • Segments can arrive out of sequence.
  • Segments can be dropped and must be retransmitted.

Figure 15-1 illustrates the problem with pauses in sending data. TCP Peer A sends TCP Peer B a series of segments and then pauses. Then TCP Peer A sends more segments. The new segment after the pause has the TS Echo Reply field set to the TS Value field of the last ACK received. If TCP Peer B now calculates the RTT for the last ACK sent, the RTT is inflated by the time of the pause in sending data.

Figure 15-1. The behavior of TCP timestamps with pauses in data.

From Figure 15-1, the TCP timestamp interval calculated from TCP segment 5 is 1898 (10951 - 9053), clearly the wrong value, as it includes the pause in sending data. With an RTO adjusted to this higher value of the RTT, throughput for data sent by TCP Peer 2 is not optimal because the RTO is too high. To prevent this behavior, the RTT is calculated only for TCP segments that acknowledge new data sent. Therefore, in the example shown in Figure 15-1, the RTT is calculated only by TCP Peer A. TCP Peer B does not calculate RTT because the segments received by TCP Peer B do not acknowledge data sent by TCP Peer B.

For delayed ACKs, segments that arrive out of order, and retransmitted segments, the value of TS Echo Reply for ACKs is based on the following algorithm:

  1. For correct TCP timestamp behavior, TCP keeps track of two variables for each connection: tsrecent is the value of the TS Echo Reply that will be sent in the next ACK, and lastack is the value of the Acknowledgment Number field from the last ACK sent.
  2. After receipt of a new segment, if the segment contains the byte numbered lastack, which means that a contiguous segment has arrived, update tsrecent with the value of the TS Value field from the arriving segment. If the segment does not contain lastack, ignore the value of the TS Value field of the arriving segment.
  3. When sending a segment with the TCP Timestamp option, set the value of TS Echo Reply to the value of tsrecent.
  4. When sending an ACK, set the value of lastack to the value of the Acknowledgment Number field in the ACK.

For delayed acknowledgments, the RTT determination must include the acknowledgment delay. Therefore, when sending a delayed acknowledgment, the TS Echo Reply of the delayed ACK is set to the TS Value of the first segment being acknowledged. Figure 15-2 illustrates this behavior.

Prior to receiving any TCP segments, the value of tsrecent is 10 and the value of lastack is 1000. When TCP segment 1 arrives, it contains the lastack byte and therefore tsrecent is updated with the TS Value of 100. When TCP segment 2 arrives, it does not contain the lastack byte and tsrecent remains at the value of 100. When TCP segment 3 arrives, it does not contain the lastack byte and tsrecent remains at the value of 100. When the delayed ACK is sent, the value of TS Echo Reply is set to tsrecent and lastack is set to the value of the Acknowledgment Number field.

Figure 15-2. The behavior of TCP timestamps for delayed acknowledgments.

When segments arrive out of sequence, the value of tsrecent, and therefore the value of TS Echo Reply, is not updated. TS Echo Reply and tsrecent are updated only when the missing segment(s) arrives. Figure 15-3 illustrates this behavior.

Prior to receiving any TCP segments, the value of tsrecent is 10 and the value of lastack is 1000. When TCP segment 1 arrives, it contains the lastack byte and therefore tsrecent is updated with the TS Value field value of 100. When the ACK on segment 1 is sent, the value of TS Echo Reply field is set to tsrecent and lastack is set to the Acknowledgment Number field's value.

Figure 15-3. The behavior of TCP timestamps for out-of-order segments.

When TCP segment 3 arrives, it does not contain the lastack byte, and tsrecent remains at the value of 100. When TCP segment 2 arrives, it does contain the lastack byte and the value of tsrecent is updated.

When a segment is dropped and must be retransmitted and the segments arrive out of sequence, the value of tsrecent, and therefore the value of the TS Echo Reply field, is not updated. Because the RTT does not include the RTO for the retransmitted segment, tsrecent and TS Echo Reply are updated only when the missing retransmitted segment arrives. Figure 15-4 illustrates this behavior.

Prior to receiving any TCP segments, the value of tsrecent is 10 and the value of lastack is 1000. When TCP segment 1 arrives, it contains the lastack byte and therefore tsrecent is updated with the TS Value of 100. When the ACK on segment 1 is sent, the value of TS Echo Reply is set to tsrecent and lastack is set to the value of the Acknowledgment Number field.

When TCP segment 3 arrives, it does not contain the lastack byte and tsrecent remains at the value of 100. When the retransmitted TCP segment 2 arrives, it does contain the lastack byte and the value of tsrecent is updated.

Figure 15-4. The behavior of TCP timestamps for retransmitted segments.


Karn's Algorithm

When calculating the RTT for a TCP segment being sent, the time at which the segment is sent is recorded. If the RTO expires, an exact duplicate is sent and its time is recorded. When the ACK is received, how is the RTT computed? When the TCP Timestamps option is not being used, the ACK does not distinguish between the original TCP segment and its retransmitted copy. TCP has the problem of acknowledgment ambiguity. When multiple copies of a TCP segment are sent, the ACK does not identify a specific instance of the TCP segment being acknowledged.

If we choose to calculate the RTT based on the first instance of the segment and the first instance is lost, the measured RTT is larger than the actual RTT for the connection because it includes the RTO for retransmitting the segment. The measured RTT is the difference between the time the first segment was sent and the time the ACK for the retransmitted instance was received. The new RTO grows larger than it should, resulting in lowered throughput for retransmitted segments. As more TCP segments are lost, the RTO based on this method of RTT calculation grows larger.

If we choose to calculate the RTT based on the retransmitted instance of the segment, and the RTO expired as a result of a sudden increase in the RTT, the ACK for the first instance arrives soon after the retransmitted segment is sent. The measured RTT (the difference between the time the retransmitted segment was sent and the time the ACK for the first instance was received) is now smaller than the connection's actual RTT. The updated RTO gets smaller when it should get larger, eventually resulting in unnecessary retransmissions for subsequent segments.

To prevent these conditions from incorrectly changing the RTO, RTT measurements for TCP segments that have been retransmitted are ignored. Only the RTT for ACKs that are acknowledging a single instance of a TCP segment are considered. However, ignoring the RTT for retransmitted segments introduces a new problem. When the actual RTT increases suddenly, the RTO for a TCP segment is too small and results in a retransmission. Because the RTT is not calculated for the retransmitted segment, the RTO remains at its inadequate value. Subsequent TCP segments sent would also be retransmitted.

To keep subsequent TCP segments from being sent with an inadequate RTO when the actual RTT increases suddenly, TCP/IP implementations, including TCP/IP for the Windows Server 2003 family and Windows XP, use Karn's algorithm. Karn's algorithm is named after its creator, Phil Karn, in the paper "Improving Routing-Trip Time Estimates in Reliable Transport Protocols," by Phil Karn and Craig Partridge. Karn's algorithm states that when an ACK for a retransmitted segment arrives, it should not be used to update the RTO. However, the RTO of the retransmitted segment (that has been exponentially backed off) should be used as a temporary RTO for subsequent TCP segments. When an ACK for a nonretransmitted TCP segment arrives, use its RTT to update the RTO. Then, use the updated RTO for subsequent TCP segments.

For example, if the RTO for a TCP connection is 300 ms and the actual RTT for the connection suddenly rises to 400 ms, Karn's algorithm causes the following behavior:

  1. Segment A is sent and its RTO is set to 300 ms.
  2. Because the RTO for Segment A is lower than the connection's actual RTT, the RTO for Segment A expires. Segment A's RTO is set to 600 ms and retransmitted (using exponential backoff and a factor of 2).
  3. The ACK for Segment A arrives (400 ms after the first instance of Segment A was sent).
  4. Because the ACK is for a retransmitted segment, it is not used to update the RTO.
  5. TCP temporarily sets the RTO for subsequent segments to 600 ms (the RTO of the retransmitted Segment A).
  6. Segment B is transmitted and Segment B's RTO is set to 600 ms.
  7. The ACK for Segment B arrives in 400 ms.
  8. Because the ACK is for a segment that has not been retransmitted, its RTT is calculated and used to update the RTO.
  9. Subsequent segments are sent using the updated RTO.

Karn's Algorithm and the Timestamps Option

Karn's algorithm applies when the ACKs are ambiguous—when TCP cannot distinguish the original TCP segment from a retransmitted instance. However, with the TCP Timestamps option, each TCP segment has a steadily increasing timestamp clock value (the TS Value field in the TCP Timestamps option header) and is therefore unique within the time that segments are being retransmitted. The ACK for different instances of a TCP segment can be distinguished from another because the ACK contains the echo of the timestamp value of the segment being acknowledged. Therefore, Karn's algorithm does not apply when TCP timestamps are being used.

If a segment is retransmitted because of a segment loss, the ACK for the retransmitted segment contains the timestamp value for the retransmitted segment, and not the original segment. Therefore, the RTT is accurately calculated as the difference in the current TCP time clock and the ACK's timestamp echo.

If a segment is retransmitted because of a sudden increase in RTT, the ACK contains the timestamp value of the first instance. Therefore, the RTT is accurately calculated as the difference in the current TCP time clock and the timestamp echo in the ACK for the first segment.


Fast Retransmit

When a TCP segment arrives and the sequence number is not the next sequence number the receiver was expecting (a noncontiguous, out-of-order segment), an immediate ACK is sent with the Acknowledgment Number field set to the next sequence number the receiver was expecting. This ACK is a duplicate of an ACK that was previously sent and is not subject to the delayed acknowledgment behavior for new contiguous data received.

After receipt of this duplicate ACK, the sender cannot determine whether the duplicate ACK was sent by the receiver because of a TCP segment that arrived out of order or because a segment was lost.

  • If a TCP segment arrived out of order, the TCP segment that contains the next byte the receiver expects to receive should arrive at the receiver shortly thereafter and a cumulative ACK is sent. Therefore, for out-of-order segments, only one or two duplicate ACKs are likely to be sent.
  • If a TCP segment is lost, all of the segments beyond the contiguous segment that arrive at the receiver generate an immediate duplicate ACK. Therefore, if three or more duplicate ACKs arrive at the sender, the TCP segment containing the next byte the receiver expects is most likely lost and must be retransmitted.

Fast retransmit is the retransmission of a TCP segment before the RTO for the segment expires, based on the receipt of three duplicate ACKs where the ACK's acknowledgment number is the retransmitted segment's sequence number. The retransmitted segment is the missing segment.

Fast retransmit and fast recovery are described in RFC 2581, which can be found in the \Rfc folder on the companion CD-ROM.

As Figure 15-5 illustrates, TCP Peer A sends five TCP segments and the first segment is lost. As the noncontiguous segments arrive, TCP Peer B sends an immediate ACK with the ACK number it expects to receive. After the third duplicate ACK for sequence number 1000, TCP Peer A retransmits the first segment.

Figure 15-5. Fast retransmit behavior when the first of five segments is dropped.

For TCP/IP for the Windows Server 2003 family and Windows XP, the TcpMaxDupAcks registry value controls fast retransmit behavior.

TcpMaxDupAcks

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Data type: REG_DWORD

Valid range: 1-3

Default value: 2

Present by default: No

TcpMaxDupAcks sets the maximum number of duplicate ACKs (ACKs that are duplicates of an original ACK received) that must be received before fast retransmit is used to retransmit the missing segment. The default value of TcpMaxDupAcks is 2, rather than the value of 3 discussed in RFC 2581.

Fast Recovery

Fast retransmit causes the sender to retransmit the missing TCP segment before its RTO expires. If the RTO expires, slow start and congestion avoidance algorithms are used to gradually increase the actual send window up to the advertised receive window. Because the RTO did not expire, congestion avoidance is performed, but not slow start. This behavior is known as fast recovery, described in RFC 2581. For more information on slow start and congestion avoidance, see Chapter 14, "Transmission Control Protocol (TCP) Data Flow."

Fast recovery assumes that the arrival of duplicate ACKs indicates that segments sent before the missing TCP segment have already been received, and are not adding to the internetwork congestion. Therefore, TCP can scale the congestion window faster than when using slow start.

The fast recovery algorithm is defined as follows:

  1. After receipt of the third duplicate ACK, the value of the slow start threshold (ssthresh) is set to one half the value of the congestion window (cwind), with a minimum value of 2*MSS.
  2. The missing segment is retransmitted and cwind is set to (ssthresh + 3*MSS). This increases cwind to a value that reflects the receipt of three TCP segments at the receiver (based on the receipt of three duplicate ACKs).
  3. For each additional duplicate ACK, cwind is increased by MSS. Once again, cwind is being increased because of an additional segment that has arrived at the receiver.
  4. If allowed by the values of cwind and the advertised receive window size, the next TCP segment(s) is transmitted.
  5. When the ACK arrives that acknowledges the receipt of the missing new segment and all other contiguous segments, cwind is set to the value of ssthresh. At this value of cwind, slow start is avoided and congestion avoidance is performed.


Summary

To recover from lost TCP segments, TCP connections maintain an RTO for each segment. If the RTO expires, the segment is retransmitted and the RTO is doubled for the retransmitted segment. After a maximum number of retransmissions, the TCP connection is abandoned. The RTO is based on calculations from samples of the RTT, using either a single sample per window of data or TCP timestamps. When TCP segments are sent without timestamps, Karn's algorithm is used to update the RTO when an ACK for a retransmitted segment is received. Fast retransmit is used to resend a missing segment before its RTO expires, based on the receipt of multiple duplicate ACK segments. Fast recovery is used to increase the size of the actual send window more quickly when fast retransmit occurs.


Dynamic Host Configuration Protocol (DHCP) Server Service

Part IV
Application Layer Protocols and Services
Chapter 16
Dynamic Host Configuration Protocol (DHCP) Server Service

To communicate successfully with each other, all TCP/IP hosts must be properly configured. These hosts require a valid IP address that is unique on the host's internetwork, a subnet mask, and a default gateway. If the host is to communicate only on the local subnet, the default gateway can be omitted. For larger networks, additional configuration items are required, such as Domain Name System (DNS) server IP addresses, Windows Internet Name Service (WINS) server IP addresses, and NetBIOS node types.

In small networks, carrying out this configuration requires a degree of TCP/IP skill that might not be readily available. On large networks, ensuring that all hosts are properly configured can be a considerable management and administrative task, especially in a dynamic network with roaming users and laptops. Manual configuration or reconfiguration of a large number of computers can be time consuming, and errors in configuring an IP host can result in the host being unable to communicate with the rest of the network.

DHCP is a client/server protocol that simplifies the management of client IP configuration and the assignment of IP configuration data. With DHCP, administrators define all necessary configuration parameters on a central server or a set of servers, which are then able to provide hosts with all necessary IP configuration information.

DHCP provides four key benefits to those planning, designing, and maintaining an IP network:

  • Centralized administration of IP configuration The DHCP administrator can centrally manage all IP configuration information. This eliminates the need to manually configure individual hosts when TCP/IP is first deployed, or when IP infrastructure changes are required.
  • Seamless IP host configuration The use of DHCP ensures that DHCP clients get accurate and timely IP configuration parameters without user intervention. Because the configuration is automatic, troubleshooting is largely eliminated.
  • Flexibility Using DHCP gives the administrator increased flexibility over changes in IP configuration information, allowing the administrator to change IP configuration more simply as infrastructure changes are needed.
  • Scalability DHCP scales from small to large networks. For very small, isolated networks, Automatic Private IP Addressing (APIPA) can be used.


Overview of DHCP in Windows Server 2003

This section presents an overview of DHCP and defines key DHCP terms.

What Is DHCP?

DHCP is a client/server protocol that automatically provides an IP host with its IP address and other related configuration information such as the subnet mask and default gateway. RFCs 2131 and 2132 define DHCP as an Internet Engineering Task Force (IETF) standard based on the Boot Protocol (BOOTP), with which it shares many implementation details. DHCP allows hosts to obtain all necessary TCP/IP configuration information from a DHCP server.

DHCP is an IETF standard based on the BOOTP protocol and is defined in RFCs 2131 and 2132, which can be found in the \Rfc folder on the companion CD-ROM.

All Microsoft Windows Server 2003 products (including Standard Edition, Enterprise Edition, Web Edition, and Datacenter Edition) include a DHCP Server service, which is an optional installation. All Microsoft Windows clients automatically install the DHCP client service as part of TCP/IP, including Windows Server 2003, Windows XP, Windows 2000, Windows NT 4, Windows Millennium Edition (Windows Me), and Windows 98.

DHCP Overview and Key Terms

Before examining DHCP in detail, you should be familiar with the following key DHCP-related terms:

DHCP Clients and Servers

A computer that gets its configuration information from DHCP is known as a DHCP client. DHCP clients communicate with a DHCP server to obtain IP addresses and related TCP/IP configuration information. DHCP servers hold information about available IP addresses and related configuration information as defined by the DHCP administrator.

DHCP Scopes and Options

A set of IP addresses and associated configuration information that can be supplied to a DHCP client is known as a scope. A scope is a set of IP addresses that the server can issue to DHCP clients, along with one or more options. An option is a specific configuration item such as a subnet mask and a default gateway IP address, which the DHCP administrator wants the DHCP server to provide to the DHCP client.

A DHCP administrator can create one or more scopes on one or more Windows Server 2003 servers running the DHCP Server service. However, because DHCP servers do not communicate scope information with each other, the administrator must be careful to ensure that the scopes are defined carefully so that multiple DHCP servers are not handing out the same IP address to different clients, or handing out addresses that are taken by existing, manually configured IP hosts.

The IP addresses defined in a DHCP scope are continuous and are associated with a subnet mask. To allow for the possibility that some IP addresses in the scope might have been already assigned and in use, the DHCP administrator can specify an exclusion—one or more IP addresses in the scope that are not handed out to DHCP clients.

In networks with multiple subnets and multiple networks, it is useful to have standards for separating the dynamic IP addresses given out by DHCP from the addresses used by manually configured hosts.

DHCP options are defined in detail in RFC 2132, and key Windows DHCP options are described later in this chapter. In the DHCP protocol packet, each option begins with a single tag octet, which defines the option. An option can be fixed length, such as the NetBIOS Node Type (Option 46); variable length, such as the Domain Name System (DNS) Domain Name (Option 15); or an array of items, such as the list of DNS Servers (Option 6).

With the Windows Server 2003 DHCP Server service, the DHCP administrator can manage options at the following five levels:

  • Predefined options Allow the DHCP administrator to specify default option values for all options supported on the DHCP server and to create new option types for use on this server.
  • Server options Values assigned to all clients and scopes defined on the DHCP server (unless they are overridden by scope, class, or client-assigned options).
  • Scope options Values applied only to clients of a specific scope (unless they are overridden by class or client-assigned options).
  • Class options Allow the administrator to set user- or vendor-defined option classes, providing option data to a specified class of DHCP clients (for example, all Windows 2000 or later DHCP clients). Options set at this level are overridden only by options assigned at the client level.
  • Reserved client options Set for an individual reserved DHCP client. Only properties manually configured at the client computer can override options assigned at this level.

Options Classes

A DHCP options class is an additional set of options that can be provided to a DHCP client based on the computer being a member of a class of computers. The administrator can use these to submanage option values provided to DHCP clients. There are two types of options classes supported by the Windows Server 2003 DHCP server: vendor classes and user classes.

When an administrator configures options classes on a DHCP server, a client belonging to that class (for example, all Windows 2000 computers) can be provided with class-specific option types for its configuration. To support earlier DHCP clients that are unable to support sending of the class ID, the administrator can configure default classes to provide option values. This allows the administrator to leverage options specifically provided in a particular client class, simultaneously allowing the administrator to provide all necessary options for other clients.

A DHCP client can indicate in the DHCP protocol messages it sends to a server that the client is a member of a particular user or vendor class. The administrator can use DHCP to define option values that are returned only for this client class. For example, the administrator can configure options specific to computers running Windows 2000, which can be sent option values (for example, whether or not to release a DHCP lease when shutting down). Other clients that cannot support this feature would not receive these values.

For a DHCP client to receive option values for these extended options, the client must specify a user class string option, containing a string identifying the client type. The DHCP server can then use this to identify extra options to be sent to the client. The user class option is set using the Ipconfig command at the command prompt. For example:

C:\>ipconfig /setclassid 3com kapoho

Windows IP Configuration

Successfully set the class id for adapter 3com.

C:\>ipconfig

Windows IP Configuration

Ethernet adapter 3com:

    Connection-specific DNS Suffix  . :

    IP Address. . . . . . . . . . . . :	10.10.1.62

    Subnet Mask . . . . . . . . . . . :	255.255.255.0

    Default Gateway . . . . . . . . . :	10.10.1.100

    DHCP Class ID . . . . . . . . . . :	kapoho

DHCP Messages

DHCP clients communicate with DHCP servers by sending application layer messages to, and receiving messages from, a DHCP server. There are eight DHCP message types, which are sent using User Datagram Protocol (UDP). DHCP clients with a bound IP address and a valid lease communicate with the DHCP server using unicast IP datagrams, whereas clients in the process of obtaining an IP address communicate using broadcast packets, sent to the limited broadcast IP address 255.255.255.255. The DHCP client binds to UDP port 68, and the DHCP server binds to UDP port 67.

There are eight DHCP message types:

  • DHCPDISCOVER Sent by a DHCP client broadcast to locate a DHCP server.
  • DHCPOFFER Sent by a DHCP server to a DHCP client, in response to DHCPDISCOVER, along with offered configuration parameters.
  • DHCPREQUEST Sent by the DHCP client to DHCP servers to request parameters from one server while implicitly declining offers from other servers, and to confirm the validity of previously allocated addresses (for example, after a reboot or to extend an existing DHCP lease).
  • DHCPACK Sent by a DHCP server to a DHCP client to confirm an IP address and provide the client with those configuration parameters that the client has requested and the server is configured to provide.
  • DHCPNAK Sent by a DHCP server to a DHCP client denying the client's DHCPREQUEST. This might occur if the requested address is incorrect because of the client having moved to a new subnet or because the DHCP client's lease has expired and cannot be renewed.
  • DHCPDECLINE Sent by a DHCP client to a DHCP server, informing the server that the offered IP address is declined because it appears to be in use by another computer.
  • DHCPRELEASE Sent by a DHCP client to a DHCP server, relinquishing an IP address and canceling the remaining lease. This is sent to the server that provided the lease.
  • DHCPINFORM Sent from a DHCP client to a DHCP server, asking only for additional local configuration parameters; the client already has a configured IP address. This message type is also used for rogue server detection.

DHCP Leases and Reservations

The IP addresses acquired by DHCP generally are not permanent. When a DHCP client is configured using DHCP, it acquires a lease on the assigned address. The DHCP administrator defines the lease duration, either when the lease is created, or subsequently. In Windows Server 2003, the administrator can specify either a specific lease time, between 1 minute and 999 days, or an unlimited lease time.

Although most IP addresses are dynamically allocated, Windows Server 2003 allows a DHCP administrator to create a reservation, a permanent address lease that the DHCP administrator creates to assign a specific IP address (and DHCP options) to a specific DHCP client. The administrator creates the reservation by specifying the IP address to be allocated and the host's media access control (MAC) address. The reservation ensures that the DHCP client with a network interface card (NIC) having that MAC address always obtains the same IP address and options.

DHCP Relay Agents

When a Windows DHCP client computer is started, it broadcasts DHCP messages to obtain or renew a lease from a DHCP server. A DHCP relay agent, also referred to as a BOOTP relay agent, is either a host or an IP router that listens for DHCP client messages being broadcast on a subnet and then forwards those DHCP messages to a configured DHCP server. The DHCP server sends DHCP response messages back to the relay agent, which then broadcasts them onto the subnet for the DHCP client. The DHCP administrator uses DHCP relay agents to centralize DHCP servers, avoiding the need for a DHCP server on each subnet.

The Routing and Remote Access service of Windows Server 2003 includes a DHCP relay agent. A DHCP administrator needs to enable the Routing and Remote Access service and configure the DHCP relay agent with interfaces and the IP addresses of DHCP servers. In addition, most modern hardware routers can be configured to provide relay facilities. On some routers, the DHCP relay function is referred to as BOOTP forwarding.

Unauthorized DHCP Server Detection

Properly configured DHCP servers provide IP configuration information for IP networks. However, when an incorrectly configured DHCP server is introduced into a network, or any DHCP server is introduced into the wrong network, problems might arise. For example, if a client obtains a lease from an incorrectly configured DHCP server, the client might receive an invalid IP address, which prevents it from communicating on the network. This can prevent users from logging on. In Windows Server 2003, an unauthorized DHCP server is simply a DHCP server that has not explicitly been authorized. Unauthorized DHCP servers are also referred to as rogue DHCP servers.

In a Windows Server 2003 domain environment, the DHCP Server service on an unauthorized server fails to initialize. The administrator must explicitly authorize all Windows Server 2003 DHCP servers that operate in an Active Directory service domain environment. At initialization time, the DHCP Server service in Windows Server 2003 checks for authorization and does not start if the server detects that it is in a domain environment and the server has not been explicitly authorized.

APIPA

DHCP clients need to find a DHCP server to get an initial lease. In most cases, the DHCP client finds a server either on a local subnet or through a relay agent. To allow for the possibility that a DHCP server is unavailable, Windows Server 2003, Windows XP, Windows 2000, and Windows 98 provide APIPA. APIPA is a facility of the Windows TCP/IP implementation that allows a computer to determine IP configuration information without a DHCP server or manual configuration.

APIPA avoids the problem of IP hosts being unable to communicate if, for some reason, the DHCP server is unavailable. APIPA is also useful for small workgroup networks where no DHCP server is implemented. Because autoconfiguration does not support a default gateway, it works only with a single subnet and is not appropriate for larger networks.

If the DHCP client is unable to locate a DHCP server, the computer autoconfigures itself with an IP address randomly chosen from the Internet Assigned Numbers Authority (IANA)-reserved class B network 169.254.0.0, and with the subnet mask 255.255.0.0. The autoconfigured computer then tests to verify that the IP address it has chosen is not already in use, using a gratuitous Address Resolution Protocol (ARP) broadcast. If the chosen IP address is in use, the computer randomly selects another address. The computer makes up to 10 attempts to find an available IP address.

Once the selected address has been verified as available, the client is configured to use that address. The DHCP client continues to check for a DHCP server in the background every 5 minutes, and if a DHCP server is found, the configuration offered by the DHCP server is used.

Windows XP and Windows Server 2003 clients can be configured to use alternate configuration, which the DHCP client uses if a DHCP server cannot be contacted. The alternate configuration includes IP address, subnet mask, default gateway, and DNS and WINS server addresses. The alternate configuration is a solution for laptops that move between a corporate, DHCP-enabled network and a home network where static IP addressing is used.

DNS Integration

The DNS Server service, described in more detail in Chapter 17, "Domain Name System (DNS)," provides name resolution for DNS clients. Windows clients support DNS dynamic updates, which allows DHCP clients to automatically update their configured DNS servers with forward and reverse lookup information.

Routing and Remote Access Service Integration

The Windows Server 2003 Routing and Remote Access service includes a remote access server facility, which allows dial-up networking or virtual private network (VPN) clients to access a server running Routing and Remote Access and join a local network. To other computers on the local network, these clients appear to be peer clients. In this case, the remote access server acts as a gateway between the remote client and the local network. Remote access clients need IP addresses for the local network to operate. Although the remote access client can be manually configured with an appropriate IP address, this adds administrative overhead. Alternatively, the Windows Server 2003 Routing and Remote Access service can be configured to obtain any required IP addresses from a DHCP server.

When a Windows Server 2003 remote access server is configured to use DHCP to obtain IP addresses, the remote access server obtains 10 IP addresses from a DHCP server when the first remote access client connects. The remote access server uses the first IP address obtained from DHCP for itself and allocates subsequent addresses to TCP/IP-based remote access clients as they connect. IP addresses that are freed when remote access clients disconnect are reused. When all 10 IP addresses are used, the remote access server obtains 10 more addresses. When the Routing and Remote Access service is stopped, all IP addresses obtained through DHCP are released.

If a DHCP server is not available when the Routing and Remote Access service requests addresses, then APIPA addresses in the range from 169.254.0.1 through 169.254.255.254 are used.

Multicast Scopes

In addition to providing leases to unicast IP addresses, the Windows Server 2003 DHCP Server service supports multicast scopes. A multicast scope is a set of addresses in the class D range (224.0.0.0-239.255.255.255) for use by multicast applications. This feature allows the DHCP administrator to control the specific multicast addresses in use by multicast applications. Applications must be specifically written to DHCP to obtain leases for multicast IP addresses.

BOOTP Support

DHCP is based on BOOTP, an older protocol with similar functionality. BOOTP is an established protocol standard used for configuring IP hosts. BOOTP was originally designed to enable boot configuration for diskless workstations. Modern DHCP servers respond to both BOOTP requests and DHCP requests.

BOOTP clients initialize themselves in two distinct steps, as follows:

  1. The BOOTP client requests an IP address and other configuration information, such as a default gateway address, a DNS server IP address, and the like, from a BOOTP server. This information includes the boot image filename and the server name where an IP address should be obtained.
  2. The BOOTP client then contacts the server and downloads the boot image file using the Trivial File Transfer Protocol (TFTP).

Although DHCP has superseded BOOTP, the DHCP server in Windows Server 2003 provides support for BOOTP clients. The administrator can define a scope for use only by BOOTP clients. Alternatively, the administrator can define a scope to be used for both BOOTP and DHCP clients.

How DHCP Works

Hosts use the DHCP protocol to obtain an initial lease, to renew an existing lease, and to detect unauthorized DHCP servers.

Obtaining an Initial Lease

A DHCP client acquires an initial lease the first time the client boots up using a series of messages exchanged with a DHCP server. This is illustrated in Figure 16-1.

Figure 16-1. DHCP messages exchanged during initial lease acquisition.

The following Network Monitor trace (Capture 16-01, included in the \Captures folder on the companion CD-ROM) provides an example of this process:

1	4.426365	KAPOHO10	*BROADCAST	DHCP	Discover	(xid=43474883)	0.0.0.0 255.255.255.255   IP

2	4.426365	LOCAL	*BROADCAST	DHCP	Offer	(xid=43474883)	TALLGUY   255.255.255.255   IP

3	4.426365	KAPOHO10	*BROADCAST	DHCP	Request	(xid=43474883)	0.0.0.0 255.255.255.255   IP

4	4.436379	LOCAL	*BROADCAST	DHCP	ACK	(xid=43474883)	TALLGUY 255.255.255.255   IP

In this trace, the DHCP client broadcasts a DHCPDISCOVER message to find a DHCP server. Because the host does not have an IP address, it communicates with the DHCP server by means of a local area broadcast. On receipt of a DHCPDISCOVER message, a DHCP server responds with an offer of an IP lease by sending a DHCPOFFER message. If there is more than one DHCP server able to provide the DHCP client with a lease, the DHCP client could receive more than one DHCPOFFER response. If this occurs, the client chooses the "best" offer, which for Windows DHCP clients is the first offer received. To help other clients determine the best offer, the DHCPOFFER message contains values for options that the client has requested and that are configured on the offering DHCP server.

Any DHCP server that receives a DHCPREQUEST message and can assign the DHCP client a lease issues a DHCPOFFER message. This message contains an offered IP address and values for any option that the DHCP server has been configured to issue. If the client can accept an offered lease, it sends a DHCPREQUEST message to the offering DHCP server, requesting the offered IP address. This request also contains all the configuration options that the DHCP client wishes to obtain.

If it is still willing to offer the lease, the DHCP server sends a DHCPACK message to the DHCP client, confirming that the DHCP client now has the lease on the IP address. The DHCPACK also provides values for the requested options that were specified by the DHCP administrator on the server issuing the DHCPACK.

Renewing a Lease

Because the IP lease has a finite lifetime, the client must renew the lease at some point after obtaining it. As Figure 16-2 illustrates, Windows DHCP clients attempt to renew the lease, either at each reboot or at regular intervals after the DHCP client has initialized.

Figure 16-2. DHCP messages exchanged during lease renewal.

The following Network Monitor trace (Capture 16-02, included in the \Captures folder on the companion CD-ROM) demonstrates the renewal of a lease:

1	81.757561	KAPOHO10	*BROADCAST	DHCP	Request	(xid=492D15B9)	0.0.0.0
255.255.255.255    IP

2	81.767576	LOCA	*BROADCAST	DHCP	ACK	(xid=492D15B9)	TALLGUY
255.255.255.255    IP

As shown in the Network Monitor trace, a lease renewal involves just two DHCP messages—DHCPREQUEST and DHCPACK. If a Windows DHCP client renews a lease while booting up, broadcast IP packets are used to send these messages, as shown in Capture 16-2. If the lease renewal is made while the Windows DHCP client is running, the DHCP client and the DHCP server communicate using unicast messages.

When a client obtains a lease, DHCP provides values for the configuration options that were requested by the DHCP client and are configured on the DHCP server. By reducing the lease time, the DHCP administrator can force clients to regularly renew leases and obtain updated configuration details. This can be useful when the administrator wishes to change a scope's IP configuration or configuration options.

A DHCP client first attempts to reacquire its lease at half the lease time, known as T1. The DHCP client obtains the value of T1 from the DHCPACK messages that confirmed the IP lease. If the lease reacquisition fails, the DHCP client attempts a further lease renewal at 87.5 percent of the lease time, known as T2. Like T1, T2 is specified in the DHCPACK message. If the lease is not reacquired before it expires (if, for example, the DHCP server is unreachable for an extended period of time), as soon as the lease expires, the client immediately unbinds the IP address and attempts to acquire a new lease.

Changing Subnets and DHCP Servers

If the DHCP client requests a lease through a DHCPREQUEST message that the DHCP server cannot fulfill (for example, when a laptop is moved to a different subnet), the DHCP server sends a DHCPNAK message to the client. This informs the client that the requested IP lease will not be renewed. The client then acquires a new lease using the lease acquisition process described earlier. Figure 16-3 illustrates this sequence of DHCP messages.

Figure 16-3. DHCP messages exchanged when DHCP client boots in a new subnet.

The following Network Monitor trace (Capture 16-03, included in the \Captures folder on the companion CD-ROM) demonstrates a client that has moved subnets and as a result needs to acquire a different IP lease:

1	68.198064	KAPOHO10	*BROADCAST	DHCP	Request	(xid=2DBB2B8B)
0.0.0.0		255.255.255.255    IP

2	68.198064	LOCAL	*BROADCAST	DHCP	NACK	(xid=2DBB2B8B)
TALLGUY		255.255.255.255    IP

3	69.419821	KAPOHO10	*BROADCAST	DHCP	Discover	(xid=749C146A)
0.0.0.0		255.255.255.255    IP

4	69.419821	LOCAL	*BROADCAST	DHCP	Offer	(xid=749C146A)
TALLGUY		255.255.255.255    IP

5	69.429836	KAPOHO10	*BROADCAST	DHCP	Request	(xid=749C146A)
0.0.0.0		255.255.255.255    IP

6  69.429836	LOCAL	*BROADCAST	DHCP	ACK	(xid=749C146A)
TALLGUY		255.255.255.255    IP

When a Windows DHCP client boots up, it broadcasts a DHCPREQUEST message to renew its lease. This ensures that the DHCP renewal request is sent to the DHCP server that provides DHCP addresses for the subnet the client is currently on. This could be different from the server that provided the initial lease. When the DHCP server receives the broadcast, it compares the address the DHCP client is requesting with the scopes configured on the server and the subnet the DHCPREQUEST message was received from. If it is not possible to satisfy the client request, the DHCP server issues a DHCPNAK, and the DHCP client then acquires a new lease.

If the DHCP client is unable to locate any DHCP server when rebooting, to renew its lease, it issues an ARP broadcast for the default gateway that was previously obtained, if one was provided. If the IP address of the gateway is successfully resolved, the DHCP client assumes that it remains located on the same network where it obtained its current lease and continues to use this lease.

If the ARP broadcast that the client sent for the default gateway receives no response, the client assumes that it has been moved to a network that has no DHCP services currently available (such as a home network), and it autoconfigures itself using either APIPA or alternate configuration. Once it autoconfigures itself, the DHCP client tries to locate a DHCP server every 5 minutes.

Using the DHCP Relay Agent

The DHCP relay agent is configured with the address of a DHCP server. The DHCP relay agents listen for DHCPDISCOVER and DHCPREQUEST (and DHCPINFORM) messages that are broadcast. The DHCP relay agent then waits a configured amount of time and, if no response is detected, sends the message to the configured DHCP server using unicast. The server then acts on the message and sends the reply back to the DHCP relay agent. The relay agent then broadcasts the message on the local subnet, allowing the DHCP client to receive it.

Detecting Unauthorized DHCP Servers

As part of the initialization of the DHCP Server service, all DHCP servers perform rogue server detection. As Figure 16-4 illustrates, if the server is not authorized in Active Directory, it shuts down. This process can be seen in the Network Monitor trace in Capture 16-04 (included in the \Captures folder on the companion CD-ROM), which contains a trace of an unauthorized server performing successful rogue server detection.

Figure 16-4. A DHCP server performing rogue server detection.

Rogue server detection begins with the initializing DHCP server issuing DHCPINFORM queries to determine if there are other initialized DHCP servers on any attached network. If so, these servers respond with a DHCPACK message that contains the name of the domain in which they have been authorized. If other DHCP servers are found, as can be seen in the Network Monitor trace in Capture 16-4, a Windows Server 2003 DHCP Server service that is starting binds to Active Directory and issues a series of Lightweight Directory Access Protocol (LDAP) calls to discover whether or not it is authorized. If the server is not authorized, the service terminates. The DHCP server carries out this detection once per hour to detect newly deauthorized servers.

If DHCP event logging is enabled, a message is written to the DHCP event log. The event log message to accompany Capture 16-4 is as follows:

00,05/17/99,18:34:08,Started,,,

61,05/17/99,18:34:08,Server found that belongs to DS domain,10.10.1.200,kapoho.com,

01,05/17/99,18:34:08,Stopped,,,

In this example, the DHCP Server service started up and performed the unauthorized DHCP server detection. This authorization failed and the DHCP Server service, therefore, was stopped. Any attempts to restart the DHCP Server service would be unsuccessful until the DHCP server was authorized.

Updating DNS Entries

When a DHCP lease is granted to an IP host, it is important for the host name and IP address mapping to be provided to the DNS. Traditionally, this was a manual task that involved creating the DNS forward and reverse lookup entries.

Windows 2000, Windows XP, and Windows Server 2003 implement the DNS Dynamic update protocol described in RFC 2136. This protocol enables Windows clients to automatically update DNS entries on the DNS server. This RFC can be found in the \Rfc folder on the companion CD-ROM.

Each time a DHCP client receives a new lease or renews an existing lease, the client sends its fully qualified name to the DHCP server as part of the DHCPREQUEST message. The DHCPREQUEST message requests the DHCP server to register a reverse lookup address mapping in the DNS server on behalf of the client. The DHCP client usually handles the forward lookup registration on its own, if it is capable.

The DHCP administrator can configure the DHCP server to send DNS updates for both the forward and reverse lookup address mappings to the DNS server. This is useful for down-level DHCP clients that do not support DNS dynamic updates.

The Network Monitor trace in Capture 16-05 (included in the \Captures folder on the companion CD-ROM) illustrates a DHCP server registering both the forward and reverse lookup mappings for a new address lease. In the trace, the DHCP server queries for the DNS Start of Authority (SOA) record for the forward lookup zone, then updates the forward lookup entry for the DHCP client. The DHCP server then queries the DNS server for the reverse lookup zone and performs the update of the DHCP client's reverse lookup entry.

For the dynamic updates to be successful, the DNS server must support DNS dynamic updates and have the forward and reverse lookup zones configured to allow dynamic updates. The Windows Server 2003 DNS service supports DNS dynamic updates, but the default for new zones does not allow dynamic updates. If, for some reason, the dynamic updating of a zone is not configured when the DHCP server attempts to update the DNS entry, the server receives an error from the DNS server. This can be seen in the Network Monitor trace in Capture 16-06 (included in the \Captures folder on the companion CD-ROM), where the reverse lookup zone is configured to not allow dynamic updates. In this case, the DHCP server sends the update to the DNS service, but receives an error in return.


DHCP Messages

The format of DHCP messages is based on the message format used with the BOOTP protocol, as described in this section. The descriptions of the DHCP messages refer to DHCP options, which are described in more detail in the "DHCP Options" section of this chapter.

General Message Format

RFC 2131 defines the format of the messages sent between a DHCP client and a DHCP server. The basic message format is illustrated in Figure 16-5.

Figure 16-5. DHCP message format.

Table 16-1 displays the individual fields in the DHCP message and a short description of each.

Table 16-1. DHCP Message Fields and Descriptions
Field | Description
Message Type (Op) | Message type.
Hardware Address Type (Htype) | Hardware address type, as defined at: http//www.iana.org/assignments/arp-parameters (for example, "0x1" means 10 MB Ethernet).
Hardware Address Length (Hlen) | Hardware address length, in octets (for example, "0x6" for 10 MB Ethernet).
Hops (Hops) | DHCP client sets this to 0. The relay agent can use this optionally when the DHCP client is booting using a relay agent.
Transaction ID (Xid) | A random number used to denote a conversation between a DHCP client and a DHCP server (for example, a lease acquisition).
Seconds (Secs) | Filled in by DHCP client. Number of seconds elapsed since the DHCP client commenced the address acquisition process.
Flags (Flags) | Flags set by client. In RFC 2131, the Broadcast flag is the only flag defined. A DHCP client that cannot receive unicast IP datagrams until it has been configured with an IP address sets this Broadcast flag.
Client IP Address (Ciaddr) | Filled in only if the client has an IP address and can respond to ARP requests to defend this IP address.
Your IP Address (Yiaddr) | Address given by the DHCP server to the DHCP client.
DHCP Server IP Address (Siaddr) | IP address of the DHCP server that is offering a lease (returned by DHCPOFFER).
Gateway IP Address (Giaddr) | DHCP relay agent IP address, used when booting using a DHCP relay agent.
Client Hardware Address (Chaddr) | Client hardware address.
Server Host name (Sname) | Windows Server 2003 does not use this field.
Boot File Name (File) | The name of the file containing a boot image for a BOOTP client.
Options (Options) | A variable-length set of fields containing DHCP options.

As Figure 16-5 illustrates, DHCP messages consist of a fixed part—236 octets in length—plus a variable-length section, used to hold options. As DHCP messages are transmitted using UDP, all DHCP messages must fit fully into a UDP datagram, which limits the variable-length section to the IP maximum transmission unit (MTU) minus 264 bytes (allowing for the IP header of 20 bytes and the UDP header of 8 bytes). Thus, for Ethernet, this limit is 1236 bytes.

DHCPDISCOVER

A DHCP client that wants to find a DHCP server to provide a lease sends a DHCPDISCOVER message. Using DHCP, this is the first step in obtaining an IP address. Because the DHCP client does not have a valid IP address, the DHCPDISCOVER message is transmitted using the limited-broadcast IP address 255.255.255.255 and a source IP address of 0.0.0.0.

Before transmitting the DHCPDISCOVER message, the DHCP client fills in the fields (described earlier) in the fixed-length portion of the DHCP message as follows:

  • Op Set to 0x1
  • Htype, Hlen Set based on the type of network in use
  • Hops, Secs, Flags Set to 0
  • Xid Client selects a random 32-bit value as a transaction ID
  • Ciaddr, Yiaddr, Siaddr, Giaddr All set to 0
  • Chaddr Set to the client MAC address of the interface acquiring a DHCP lease, and is the address used in all subsequent DHCP messages to refer to this interface on this client
  • Cname, File Set to 0

Windows 2000, Windows XP, and Windows Server 2003 DHCP clients also set a series of options in the DHCPDISCOVER message as follows:

  • Magic Cookie Always set to 99.130.83.99 to indicate that vendor extensions follow.
  • Client Identifier Set to the DHCP client's hardware address.
  • Host Name Set to the client's host name.
  • Client Class Set to MSFT 5.0 to indicate that this is a Windows 2000 system (or later).
  • Parameter Request List Set to indicate the parameters the DHCP client wants to obtain from the server. For Windows 2000, Windows XP, and Windows Server 2003 clients, these are as follows:
    • 0x01 (subnet mask)
    • 0x0F (DNS domain name)
    • 0x03 (default gateway)
    • 0x06 (DNS servers)
    • 0x2C (WINS server address)
    • 0x2E (NetBIOS node type)
    • 0x2F (NetBIOS Scope ID)
    • 0x2B (vendor class information)
    • 0x1F (perform router discovery)
    • 0x21 (static routes)
The Windows 98 DHCPDISCOVER message does not send client class information and does not request vendor class information. In addition, the Windows 98 DHCPDISCOVER message sends an Option Request message for Option 57, a maximum DHCP message size that is not acted on by the Windows Server 2003 DHCP server.

The following Network Monitor trace (part of Capture 16-01, included in the \Captures folder on the companion CD-ROM) shows a DHCPDISCOVER message sent from a Windows 2000 client discovering available DHCP servers:

+	Frame:	Base frame properties

+	ETHERNET:	ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP:	ID = 0x120; Proto = UDP; Len: 328

+	UDP:	IP Multicast: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server

(67); Length = 308 (0x134)

        DHCP: Discover           (xid=43474883)

        DHCP:	Op Code	(op)	= 1 (0x1)

        DHCP:	Hardware Type	(htype)	= 1 (0x1) 10Mb Ethernet

        DHCP:	Hardware Address Length (hlen) = 6 (0x6)

        DHCP:	Hops	(hops)	= 0 (0x0)

        DHCP:	Transaction ID	(xid)	= 1128745091 (0x43474883)

        DHCP:	Seconds	(secs)	= 0 (0x0)

        +	DHCP:	Flags	(flags)	= 0 (0x0)

        DHCP:	Client IP Address	(ciaddr)	= 0.0.0.0

        DHCP:	Your   IP Address	(yiaddr)	= 0.0.0.0

        DHCP:	Server IP Address (siaddr)	= 0.0.0.0

        DHCP:	Relay  IP Address	(giaddr)	= 0.0.0.0

        DHCP: Client Ethernet Address (chaddr) = 00600801D303

        DHCP:	Server Host Name	(sname)	= <Blank>

        DHCP:	Boot File Name	(file)	= <Blank>

        DHCP:	Magic Cookie = 99.130.83.99

        DHCP:	Option Field      (options)

    DHCP:	DHCP Message Type	= DHCP Discover

    DHCP:	Unrecognized Option	= 251 (0xFB)

    DHCP:	Client-identifier	= (Type: 1) 00 60 08 01 d3 03

    DHCP:	Requested Address	= 12.12.12.12

    DHCP:	Host Name	= KAPOHO10

    DHCP:	Client Class information = (Length: 8) 4d 53 46 54 20 35 2e 30

    DHCP:	Parameter Request List	 = (Length: 10) 01 0f 03 06 2c 2e 2f 1f 21 2b

    DHCP:	End of this option field

DHCPOFFER

When a DHCP server receives a DHCPREQUEST, the server uses the Ciaddr field to identify the client requesting the DHCP lease. The server first checks its database to see if the DHCP client requesting the lease has an existing lease or a reservation for a lease. If it does not, the DHCP server then checks to see if it has a configured scope from which to allocate an IP address lease.

To determine which scope to use for address assignment, the DHCP server examines the Giaddr field in the DHCPDISCOVER message. If Giaddr is 0, the DHCP server uses the interface that the message was received on to determine the scope. If a DHCP relay agent sent the DHCPDISCOVER message to the DHCP server, the relay agent sets the Giaddr field to the relay agent's IP address. Thus, if the Giaddr field is not 0, the DHCP server uses the scope that corresponds to the subnet the DHCP relay agent resides in.

If there is no existing lease for the client, the DHCP server examines the chosen scope to find an IP address for the DHCP client. If the client had a previously assigned lease, but the lease expired, and the address is available, the DHCP server offers this address. Otherwise, the server picks an available address from the scope being used for the allocation.

If the DHCP server can offer a lease, it constructs a DHCPOFFER message with the following fields set in the fixed-length portion of the DHCP message:

  • Op Set to 0x2
  • Htype Set according to the network hardware in use
  • Xid Set to the xid in the received DHCPDISCOVER
  • Yiaddr Set to the IP address being offered to the DHCP client
  • Siaddr Set to the IP address of the DHCP server offering the lease
  • Chaddr Set to the client's hardware address as received in the DHCPDISCOVER message

The DHCP server also sets a series of options as follows:

  • Magic Cookie Set to 99.130.83.99
  • DHCP Message Type Set to 0x02 (DHCPOFFER)
  • Subnet Mask Obtained from the scope definition
  • Renewal Time (T1) Set to 50 percent of the lease time, in seconds
  • Rebinding Time (T2) Set to 87.5 percent of the lease time, in seconds
  • IP Address Lease Time The duration of the lease, in seconds
  • Server Identifier The IP address of the server offering the lease
  • Domain Name If requested in the DHCPDISCOVER message (and configured for the scope), the DNS domain name specified in the scope definition
  • Domain Name Server If requested in the DHCPDISCOVER message (and configured for the scope), the list of DNS servers specified in the scope definition
  • NetBIOS Name Server If requested in the DHCPDISCOVER message (and configured for the scope), the list of WINS servers specified in the scope definition
  • NetBIOS Node Type If requested in the DHCPDISCOVER message (and configured for the scope), the NetBIOS node type specified in the scope definition

The DHCP client, having issued a DHCPDISCOVER, might receive zero, one, or more DHCPOFFER messages. If no DHCPOFFER message is received, the DHCP client retransmits the DHCPOFFER message. If the DHCP client receives no offer after three attempts, the client initiates autoconfiguration using APIPA.

A DHCPOFFER message is shown in the following Network Monitor trace (part of Capture 16-01, included in the \Captures folder on the companion CD-ROM), which details a Windows 2000 client being offered a lease on the IP address 10.10.1.51:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xD8B; Proto = UDP; Len: 337

+	UDP: IP Multicast: Src Port: BOOTP Server, (67); Dst Port: BOOTP Client (68); Length = 317 (0x13D)

    DHCP: Offer              (xid=43474883)

            DHCP: Op Code	(op)	= 2 (0x2)

            DHCP: Hardware Type	(htype)	= 1 (0x1) 10Mb Ethernet

            DHCP:	Hardware Address Length (hlen) = 6 (0x6)

            DHCP:	Hops	(hops)	= 0 (0x0)

            DHCP:	Transaction ID	(xid)	= 1128745091 (0x43474883)

            DHCP:	Seconds	(secs)	= 0 (0x0)

        +	DHCP:	Flags	(flags)	= 0 (0x0)

            DHCP:	Client IP Address	(ciaddr)	= 0.0.0.0

            DHCP:	Your   IP Address	(yiaddr)	= 10.10.1.51

            DHCP:	Server IP Address	(siaddr)	= 10.10.1.100

            DHCP:	Relay  IP Address	(giaddr)	= 0.0.0.0

            DHCP:	Client Ethernet Address (chaddr) = 00600801D303

            DHCP:	Server Host Name	(sname)	= <Blank>

            DHCP:	Boot File Name	(file)	= <Blank>

            DHCP:	Magic Cookie = 99.130.83.99

              DHCP:	Option Field	(options)

                DHCP:	DHCP Message Type	= DHCP Offer

                  DHCP:	Subnet Mask		= 255.255.255.0

                     DHCP:	Renewal Time Value (T1)	= 4 Days,  0:00:00

                    DHCP:	Rebinding Time Value (T2) = 7 Days,  0:00:00

                    DHCP:	IP Address Lease Time	= 8 Days,  0:00:00

                    DHCP:	Server Identifier	= 10.10.1.100

                     DHCP:	Domain Name		= kapoho.com

                    DHCP:	Router		= 10.10.1.100

                    DHCP:	Domain Name Server	= 10.10.1.200 10.10.2.200

DHCPREQUEST

A DHCP client sends the DHCPREQUEST to a DHCP server, either as part of an initial lease acquisition (that is, responding to a DHCPOFFER) or as part of a subsequent lease renewal. A DHCP client can use it to confirm its previously allocated IP address and associated configuration parameters as well.

Based either on the information in a DHCPOFFER message or on the currently configured DHCP properties, the Windows client constructs a DHCPREQUEST message with the following fields set in the fixed-length portion of the DHCP message:

  • Op Set to 0x1.
  • Htype, Hlen Set according to the network hardware in use
  • Xid Set to either the xid in the original DHCPDISCOVER (for new leases) or a new transaction ID (for lease renewals and IP address confirmations)
  • Chaddr Set to the client's hardware address as specified in the original DHCPDISCOVER message
  • Ciaddr For new leases, this field is set to 0; for lease renewals, this is set to the IP address being renewed (or if the lease has expired, the IP address last leased by the DHCP client)

Windows DHCP clients also set a series of options in the DHCPREQUEST message as follows:

  • Magic Cookie Always set to 99.130.83.99.
  • DHCP Message Type Set to 0x03 (DHCPREQUEST).
  • Client Identifier Set to the DHCP client's hardware address.
  • Requested Address This is the address being requested. For new leases, this is the address offered in the DHCPOFFER message. If multiple offers were received, this is the address the client has chosen from the set of addresses that were offered and which the client is now requesting.
  • Server ID The client is addressing the DHCP request to this server.
  • Host Name This is the DHCP client's host name.
  • DNS Dynamic Updates This option, which is not defined in RFC 2131, contains the fully qualified host name that the DHCP server uses to format Dynamic DNS forward and reverse lookup updates.
  • Client Class Information Specifies the DHCP client's vendor class. For Windows 2000, Windows XP, and Windows Server 2003, the class-identifier string is MSFT 5.0. The DHCP server uses this to identify the client class type and to identify any vendor-specific information to be returned.
  • Parameter Request List The list of configuration parameters that the client wishes to obtain. For Windows clients this request list contains the following options:
    • 0x01 (subnet mask)
    • 0x03 (router)
    • 0x06 (DNS server list)
    • 0x0F (domain name)
    • 0x2B (vendor-specific information)
    • 0x2C (WINS server list)
    • 0x2E (NetBIOS node type)
    • 0x2F (NetBIOS scope)
Windows 98 DHCPREQUEST messages are similar to those sent by Windows 2000, Windows XP, and Windows Server 2003 DHCP clients. The Windows 98 client sends Option 57 (maximum DHCP message size), although the Windows Server 2003 DHCP server does not acknowledge this. The Windows 98 client, however, does not send the DNS Dynamic updates option or vendor class information in the Parameter Request List.

The following Network Monitor trace (part of Capture 16-01, included in the\Cap- tures folder on the companion CD-ROM) shows a DHCPREQUEST message with a Windows 2000 client requesting a lease on the IP address 10.10.1.51:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0x121; Proto = UDP; Len: 365

+	UDP: IP Multicast: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server (67); Length = 345 (0x159)

    DHCP: Request            (xid=43474883)

            DHCP:	Op Code	(op)	= 1 (0x1)

            DHCP:	Hardware Type	(htype)	= 1 (0x1) 10Mb Ethernet

            DHCP:	Hardware Address Length (hlen) = 6 (0x6)

               DHCP:	Hops	(hops)	= 0 (0x0)

            DHCP:	Transaction ID	(xid)	= 1128745091 (0x43474883)

            DHCP:	Seconds	(secs)	= 0 (0x0)

        +	DHCP:	Flags	(flags)	= 0 (0x0)

            DHCP:	Client IP Address	(ciaddr)	= 0.0.0.0

            DHCP:	Your   IP Address	(yiaddr)	= 0.0.0.0

            DHCP:	Server IP Address	(siaddr)	= 0.0.0.0

            DHCP:	Relay  IP Address	(giaddr)	= 0.0.0.0

            DHCP:	Client Ethernet Address (chaddr) = 00600801D303

            DHCP:	Server Host Name	(sname)	= <Blank>

            DHCP:	Boot File Name	(file)	= <Blank>

            DHCP:	Magic Cookie = 99.130.83.99

            DHCP:	Option Field      (options)

                DHCP:	DHCP Message Type	= DHCP Request

                DHCP:	Client-identifier	= (Type: 1) 00 60 08 01 d3 03

                DHCP:	Requested Address	= 10.10.1.51

                DHCP:	Server Identifier	= 10.10.1.100

                DHCP:	Host Name		= KAPOHO10

                DHCP:	DNS Dynamic updates	= (Length: 38) 00 00 00 4b 41 50 4f 48
4f 31 30 2e 72 65 64 6d ...

                DHCP:	Client Class information = (Length: 8) 4d 53 46 54 20 35 2e 30

                DHCP:	Parameter Request List	= (Length: 10) 01 0f 03 06 2c 2e 2f 1f 21 2b

          DHCP: End of this option field

DHCPACK

The DHCP server sends the DHCPACK message to the DHCP client in response to the DHCPREQUEST or DHCPINFORM message. The DHCPACK message is a confirmation by the DHCP server that it has issued the DHCP client with a lease on an IP address and provides values for any required options (as specified in the Parameter Request List of the DHCPREQUEST message).

The Windows Server 2003 DHCP server constructs a DHCPACK message with the following fields set in the fixed-length portion of the DHCP message:

  • Op Set to 0x2.
  • Htype, Hlen Set according to the network hardware in use.
  • Xid Set to either the xid in the original DHCPDISCOVER (for new leases) or a new transaction ID (for lease renewals and IP address confirmations).
  • Yiaddr Set to the client's IP address. The DHCP server issues this address to the client.
  • Chaddr Set to the client's hardware address as specified in the original DHCPDISCOVER message.

The Windows Server 2003 DHCP server also sets a series of options in the DHCPREQUEST message as follows:

  • Magic Cookie Always set to 99.130.83.99
  • DHCP Message Type Set to 0x05 (DHCPACK)
  • Renewal Time (T1) Set to 50 percent of the lease time, in seconds
  • Rebinding Time (T2) Set to 87.5 percent of the lease time, in seconds
  • IP Address Lease Time The duration of the lease, in seconds
  • Server ID The client is addressing the DHCP request to this server
  • Subnet Mask The client's subnet mask
  • DNS Dynamic Updates Sent in response to the DNS Dynamic updates in the DHCPREQUEST message

In addition, the DHCP server sends all option values for any of the options requested in the DHCPREQUEST message. The following Network Monitor trace (part of Capture 16-01, included in the \Captures folder on the companion CD-ROM) shows a Windows 2000 DHCP server confirming a lease on IP address 10.10.1.51 to a Windows 2000 client:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xD90; Proto = UDP; Len: 342

+	UDP: IP Multicast: Src Port: BOOTP Server, (67); Dst Port: BOOTP Client (68); Length = 322 (0x142)

    DHCP: ACK                (xid=43474883)

            DHCP:	Op Code	(op)	= 2 (0x2)

            DHCP:	Hardware Type	(htype)	= 1 (0x1) 10Mb Ethernet

            DHCP:	Hardware Address Length (hlen) = 6 (0x6)

            DHCP:	Hops	(hops)	= 0 (0x0)

            DHCP:	Transaction ID	(xid)	= 1128745091 (0x43474883)

            DHCP:	Seconds	(secs)	= 0 (0x0)

        +	DHCP:	Flags	(flags)	= 0 (0x0)

            DHCP:	Client IP Address	(ciaddr)	= 0.0.0.0

            DHCP:	Your   IP Address	(yiaddr)	= 10.10.1.51

            DHCP:	Server IP Address	(siaddr)	= 0.0.0.0

            DHCP:	Relay  IP Address	(giaddr)	= 0.0.0.0

            DHCP:	Client Ethernet Address (chaddr) = 00600801D303

            DHCP:	Server Host Name	(sname)	= <Blank>

            DHCP:	Boot File Name	(file)	= <Blank>

            DHCP:	Magic Cookie = 99.130.83.99

            DHCP:	Option Field      (options)

                 DHCP:	DHCP Message Type	= DHCP ACK

                DHCP:	Renewal Time Value (T1) = 4 Days,  0:00:00

                DHCP:	Rebinding Time Value (T2) = 7 Days,  0:00:00

                DHCP:	IP Address Lease Time	= 8 Days,  0:00:00

                  DHCP:	Server Identifier	= 10.10.1.100

                  DHCP:	Subnet Mask		= 255.255.255.0

                DHCP:	DNS Dynamic updates	= (Length: 3) 03 ff ff

                DHCP:	Domain Name		= kapoho.com

                DHCP:	Router		= 10.10.1.100

                DHCP:	Domain Name Server	= 10.10.1.200 10.10.2.200

DHCPDECLINE

When a DHCP client receives an IP address from a DHCP server, the client must determine whether the IP address is in use. The Windows 2000 and Windows Server 2003 DHCP servers can be configured to check that the address is in use before issuing the address. However, Windows clients also perform this check after receiving a DHCPACK. The client performs the check by issuing an ARP broadcast for the address.

If the DHCP client receives an ARP reply indicating that the address is in use, the client broadcasts a DHCPDECLINE to the DHCP server and unbinds the address. The Windows Server 2003 DHCP server marks the address as "bad" in the DHCP database. The client is then free to acquire a lease for another IP address.

The Network Monitor trace in Capture 16-07 (included in the \Captures folder on the companion CD-ROM) contains a trace of a Windows XP system acquiring a lease. In the trace, the DHCP server offers and acknowledges an IP address against which the DHCP client performs a gratuitous ARP. Because the address is in use, the ARP finds a host using the address, and the DHCP client broadcasts the DHCPDECLINE. This allows the DHCP server to mark the address as "bad_address" in the DHCP database. The DHCP client also writes an Event Log Warning message to the DHCP client's event log, as well as to the event log of the client currently holding the disputed IP address (if that client is a computer running Windows Server 2003).

The Windows DHCP client constructs a DHCPDECLINE message with the following fields set in the fixed-length portion of the DHCP message:

  • Op Set to 0x1
  • Htype, Hlen Set according to the network hardware in use
  • Xid Set to the xid in the original DHCPDISCOVER or DHCPREQUEST
  • Ciaddr Set to the IP address that is in dispute (that is, the one the client was issued but has determined is already in use)
  • Chaddr Set to the client's hardware address as specified in the original in the DHCPDISCOVER message

The Windows DHCP client also sets a series of options in the DHCPDECLINE message as follows:

  • Magic Cookie Always set to 99.130.83.99
  • DHCP Message Type Set to 0x04 (DHCPDECLINE)
  • Client Identifier The MAC address of the client issuing the DHCPDECLINE message
  • Requested Address The disputed IP address
  • Server ID The IP address of the server that issued the client with the disputed address

The following trace (part of Capture 16-07, included in the \Captures folder on the companion CD-ROM) shows the DHCPDECLINE message in detail:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xC58; Proto = UDP; Len: 328

+	UDP: IP Multicast: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server (67); Length = 308 (0x134)

    DHCP: Decline            (xid=3D136017)

            DHCP:	Op Code	(op)	= 1 (0x1)

            DHCP:	Hardware Type	(htype)	= 1 (0x1) 10Mb Ethernet

            DHCP:	Hardware Address Length (hlen) = 6 (0x6)

            DHCP:	Hops	(hops)	= 0 (0x0)

            DHCP:	Transaction ID	(xid)	= 1024679959 (0x3D136017)

            DHCP: Seconds	(secs)	= 0 (0x0)

        +	DHCP: Flags	(flags)	= 0 (0x0)

            DHCP:	Client IP Address	(ciaddr)	= 10.10.1.50

            DHCP:	Your   IP Address	(yiaddr)	= 0.0.0.0

            DHCP:	Server IP Address	(siaddr)	= 0.0.0.0

            DHCP:	Relay  IP Address	(giaddr)	= 0.0.0.0

            DHCP:	Client Ethernet Address (chaddr) = 00600801D303

            DHCP:	Server Host Name	(sname)	= <Blank>

            DHCP:	Boot File Name	(file)	= <Blank>

            DHCP:	Magic Cookie = 99.130.83.99

            DHCP:	Option Field      (options)

                DHCP:	DHCP Message Type	= DHCP Decline

                DHCP:	Client-identifier	= (Type: 1) 00 60 08 01 d3 03

                DHCP:	Requested Address	= 10.10.1.50

                    DHCP: Option MUST NOT be Present

                DHCP:	Server Identifier	= 10.10.1.100

                DHCP:	End of this option field

DHCPNAK

The DHCP server uses DHCPNAK messages to tell a DHCP client that an address it is requesting cannot be provided. This can occur when a client that has a lease is offline or, for administrative reasons, the DHCP administrator cancels the lease. In that case, the DHCP server could reallocate the address to another client. This can also occur on clients that move between different subnets.

If the requested address comes from a scope that does not match the scope of the value in the Giaddr field or the scope of the interface on which it was received (if the Giaddr field is 0), the DHCP server determines that the DHCP client has moved to a different subnet.

After receiving a DHCPNAK message, Windows DHCP clients immediately release the IP address and attempt to acquire a new IP address.

The following Network Monitor trace (part of Capture 16-03, included in the \Captures folder on the companion CD-ROM) illustrates the DHCPNAK. The trace shows a DHCPREQUEST for an address, followed by a DHCPNAK indicating that it is not available:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xAE; Proto = UDP; Len: 353

+	UDP: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server (67); Length = 333 (0x14D)

    DHCP: Request            (xid=199F7780)

            DHCP:	Op Code	(op)	= 1 (0x1)

            DHCP:	Hardware Type	(htype)	= 1 (0x1) 10Mb Ethernet

            DHCP:	Hardware Address Length (hlen) = 6 (0x6)

            DHCP:	Hops	(hops)	= 0 (0x0)

            DHCP:	Transaction ID	(xid)	= 429881216 (0x199F7780)

            DHCP:	Seconds	(secs)	= 0 (0x0)

        +	DHCP:	Flags	(flags)	= 0 (0x0)

            DHCP:	Client IP Address	(ciaddr)	= 10.10.1.50

            DHCP:	Your   IP Address	(yiaddr)	= 0.0.0.0

            DHCP:	Server IP Address	(siaddr)	= 0.0.0.0

            DHCP:	Relay  IP Address	(giaddr)	= 0.0.0.0

            DHCP:	Client Ethernet Address (chaddr) = 00600801D303

            DHCP:	Server Host Name	(sname)	= <Blank>

            DHCP:	Boot File Name	(file)	= <Blank>

            DHCP:	Magic Cookie = 99.130.83.99

            DHCP:	Option Field      (options)

                DHCP:	DHCP Message Type	= DHCP Request

                DHCP:	Client-identifier	= (Type: 1) 00 60 08 01 d3 03

                DHCP:	Host Name		= KAPOHO10

                DHCP:	DNS Dynamic updates	= (Length: 38) 00 00 00 4b 41 50 4f 48
4f 31 30 2e 72 65 64 6d ...

                DHCP:	Client Class information = (Length: 8) 4d 53 46 54 20 35 2e 30

                DHCP:	Parameter Request List	= (Length: 10) 01 0f 03 06 2c 2e 2f 1f 21 2b

                DHCP:	End of this option field

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xCBEA; Proto = UDP; Len: 328

+	UDP: Src Port: BOOTP Server, (67); Dst Port: BOOTP Client (68); Length = 308 (0x134)

    DHCP: NACK               (xid=199F7780)

            DHCP:	Op Code	(op)	= 2 (0x2)

            DHCP:	Hardware Type	(htype)	= 1 (0x1) 10Mb Ethernet

            DHCP:	Hardware Address Length (hlen) = 6 (0x6)

            DHCP:	Hops	(hops)	= 0 (0x0)

            DHCP:	Transaction ID	(xid)	= 429881216 (0x199F7780)

            DHCP:	Seconds	(secs)	= 0 (0x0)

        +	DHCP:	Flags	(flags)	= 128 (0x80)

            DHCP:	Client IP Address	(ciaddr)	= 0.0.0.0

            DHCP:	Your   IP Address	(yiaddr)	= 0.0.0.0

            DHCP:	Server IP Address	(siaddr)	= 0.0.0.0

            DHCP:	Relay  IP Address	(giaddr)	= 0.0.0.0

            DHCP:	Client Ethernet Address (chaddr) = 00600801D303

            DHCP:	Server Host Name	(sname)	= <Blank>

            DHCP:	Boot File Name	(file)	= <Blank>

            DHCP:	Magic Cookie = 99.130.83.99

            DHCP:	Option Field      (options)

                DHCP:	DHCP Message Type	= DHCP NACK

                DHCP:	Server Identifier	= 10.10.1.100

DHCPRELEASE

The DHCP client sends this message to the DHCP server releasing the IP address and canceling the lease. The released IP address can then be reused for other DHCP clients. The Windows Server 2003 DHCP server does not acknowledge the DHCPRELEASE. The DHCPRELEASE message is unicast from the DHCP client to the DHCP server that originally issued the lease that the client is releasing.

The Windows DHCP client constructs a DHCPRELEASE message with the following fields set in the fixed-length portion of the DHCP message:

  • Op Set to 0x1
  • Htype, Hlen Set according to the network hardware in use
  • Xid Set to a new transaction ID
  • Ciaddr Set to the client's IP address that's being released
  • Chaddr Set to the client's hardware address as specified in the original DHCPDISCOVER message

The Windows DHCP client also sets a series of options in the DHCPRELEASE message as follows:

  • Magic Cookie Always set to 99.130.83.99
  • DHCP Message Type Set to 0x07 (DHCPRELEASE)
  • Server Identifier The server that originally issued the lease
  • Client Identifier The DHCP client's MAC address

The following Network Monitor trace (Capture 16-08, included in the \Captures folder on the companion CD-ROM) shows a DHCPRELEASE message sent from a Windows 2000 computer, releasing the IP address 10.10.1.61:

+	Frame: Base frame properties

+	ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+	IP: ID = 0xFA; Proto = UDP; Len: 328

+	UDP: Src Port: BOOTP Client, (68); Dst Port: BOOTP Server (67); Length = 308 (0x134)

    DHCP: Release           (xid=771D3A02)

              DHCP:	Op Code	(op)	= 1 (0x1)

            DHCP:	Hardware Type	(htype)	= 1 (0x1) 10Mb Ethernet

            DHCP:	Hardware Address Length (hlen) = 6 (0x6)

            DHCP:	Hops	(hops)	= 0 (0x0)

            DHCP:	Transaction ID	(xid)	= 1998404098 (0x771D3A02)

            DHCP:	Seconds	(secs)	= 0 (0x0)

        +	DHCP:	Flags	(flags)	= 128 (0x80)

            DHCP:	Client IP Address	(ciaddr)	= 10.10.1.61

            DHCP:	Your   IP Address	(yiaddr)	= 0.0.0.0

            DHCP:	Server IP Address	(siaddr)	= 0.0.0.0

            DHCP:	Relay  IP Address	(giaddr)	= 0.0.0.0

            DHCP:	Client Ethernet Address (chaddr) = 00600801D303

            DHCP:	Server Host Name	(sname)	= <Blank>

            DHCP:	Boot File Name	(file)	= <Blank>

            DHCP:	Magic Cookie = 99.130.83.99

            DHCP:	Option Field      (options)

                DHCP:	DHCP Message Type	= DHCP Release

                DHCP:	Server Identifier	= 10.10.1.100

                DHCP:	Client-identifier	= (Type: 1) 00 60 08 01 d3 03

                DHCP:	End of this option field

DHCPINFORM

RFC 2131 defines the DHCPINFORM DHCP message type. DHCP clients can use the DHCPINFORM message to request additional configuration information, regardless of how the DHCP clients were originally configured. Thus, a DHCP client, configured with a static IP address, could use the DHCPINFORM messages to request additional local configuration parameters from a DHCP server. Windows Server 2003 remote access clients also use DHCPINFORM to automatically obtain a DNS domain name, after the Point-to-Point Protocol (PPP) connection is configured.

In Windows 2000 and later, the key use of the DHCPINFORM message is to enable a Windows DHCP server to discover the name of the Directory Services (DS) enterprise root on which each server is installed. This is performed as part of rogue DHCP server detection. This information is requested within the DHCPINFORM message by including information in the message's vendor-specific options area. When other DHCP servers running the Windows Server 2003 DHCP Server service receive the DHCPINFORM message, they process, acknowledge, and respond with the requested information about the DS enterprise root.

The server running Windows Server 2003 constructs a DHCPINFORM message with the following fields set in the fixed-length portion of the DHCP message:

  • Op Set to 0x1
  • Htype, Hlen Set according to the network hardware in use
  • Xid The DHCP server generates a new transaction ID
  • Ciaddr Set to the DHCP server's IP address

The Windows Server 2003 DHCP server also sets a series of options in the DHCPINFORM message as follows:

  • Magic Cookie Always set to 99.130.83.99
  • DHCP Message Type Set to 0x08 (DHCPINFORM)
  • Vendor-Specific Information For unauthorized server detection, this field is set to 0x5E


DHCP Options

The Windows Server 2003 DHCP Server service provides leases on IP addresses to DHCP clients. The lease includes an IP address, subnet mask, and values for specific options as requested by the DHCP client. This section defines the options that Windows Server 2003 DHCP servers support and that Windows clients can request.

What Are DHCP Options?

A DHCP option is an IP configuration parameter that a DHCP server can send to a DHCP client. These can be standard options, used in all DHCP messages or all messages of a particular type, such as the Magic Cookie option, or DHCP message types. Additionally, DHCP options can contain configuration parameters that are explicitly requested by DHCP clients, such as the default gateway IP address.

The Windows Server 2003 DHCP server supports the standard option types, defined in RFC 2132. Moreover, Windows Server 2003 supports additional vendor-specific options that the administrator can use to provide Windows 2000 and later DHCP clients with additional information.

Standard option types are defined in RFC 2131, which can be found in the \Rfc folder on the companion CD-ROM.

Option Formats

As defined by RFCs 2131 and 2132, options can be of either fixed length or variable length, and might or might not have associated data. As shown in Figure 16-6, all options begin with an octet holding the option code to identify it. Fixed-length options without data consist of only a single tag octet. The only fixed-length options without data are Option 0 (Pad) and Option 255 (End). All other options are of variable length and have a length octet following the tag octet. The length octet value excludes the two octets that specify the tag and length. The length value indicates the number of octets that the option contains. Some variable-length options have a fixed-length field but a length option is still specified.

Figure 16-6. DHCP option format.

The vendor option class is formatted slightly differently in that there is a single option (vendor-specific information) that consists of a list of suboptions.

Options Supported by Windows Server 2003

The Windows Server 2003 DHCP Server service supports all options specified in RFC 2132. However, most of the defined options are no longer in use or are not used by Windows or MS-DOS DHCP clients. For the full list of options that Windows Server 2003 DHCP Server service supports, refer to Windows Server 2003 Help. The options that the Windows Server 2003 DHCP Server service supports fall into the following three categories:

  • Options that are present in all messages (or all occurrences of a specific message type)
  • Standard options that clients can request and that the DHCP server provides, if the administrator at the DHCP server has defined the option value
  • Vendor options that are returned based on the client class

Options Present in All DHCP Messages

Table 16-2 displays the DHCP options that can appear in all DHCP messages (or in all occurrences of a particular DHCP message).

Table 16-2. DHCP Options Appearing in All DHCP Messages
Option Name | Option Code (Decimal) | Option Length | Option Description
Pad | 0 | 1 octet | Used to cause subsequent fields to align. Can be used in any DHCP message.
Subnet Mask | 1 | 4 octets | Used in conjunction with an offered IP address. Used in DHCPOFFER and DHCPACK messages.
Host Name | 12 | Variable length; | Specifies the name of the client. Used in minimum length DHCPDISCOVER, DHCPREQUEST, and is 1 octet DHCPNAK messages.
Vendor-Specific Information | 43 | Variable length | Used by clients and servers to exchange vendor-specific information. The definition of this information is vendor-specific and is not defined in RFC 2132. Used in DHCPINFORM messages.
Requested Address | 50 | 4 octets | The DHCP client is requesting (or declining) this address. This is used in DHCPREQUEST and DHCPDECLINE messages.
Lease Time | 51 | 4 octets | The length of the lease in seconds. This is present in only DHCPOFFER and DHCPACK messages.
DHCP Message Type | 53 | 1 octet | Used to define the DHCP Message type. The values are as follows: 0x01 DHCPDISCOVER 0x02 DHCPOFFER 0x03 DHCPREQUEST 0x04 DHCPDECLINE 0x05 DHCPACK 0x06 DHCPNAK 0x07 DHCPRELEASE 0x08 DHCPINFORM Used in all DHCP messages.
Server Identifier | 54 | 4 octets | The DHCP server's IP address. This is used in DHCPREQUEST, DHCPACK, DHCPDECLINE, and DHCPRELEASE messages.
Parameter Request List | 55 | Variable length; but for Windows clients, this is 8 octets in length | Used by a DHCP client to request values for specific configuration parameters. Each octet is a valid DHCP option code (defined in RFC RFC 2132) for options that the DHCP client is requesting values from the DHCP server. This occurs in DHCPDISCOVER, DHCPREQUEST, and DHCPINFORM messages.
Renewal Time (T1) | 58 | 4 octets | Length of time, in seconds, until the client enters renewal state. This is used in DHCPOFFER and DHCPACK messages.
Rebinding Time (T2) | 59 | 4 octets | Length of time, in seconds, until the client enters rebinding state. This is used in DHCPOFFER and DHCPACK messages.
Client | 61 | Variable length; minimum length is 2 octets; for Ethernet, the length is 6 octets | A value to identify the client uniquely. For Windows DHCP clients, this is the client's MAC address. This is used in DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE, DHCPNAK, and DHCPRELEASE messages.
Dynamic DNS Update | 81 | Variable length | This is the fully qualified domain name of the host and the DHCP server uses it to send DNS Dynamic updates to a DNS server. This is used in DHCPREQUEST messages.
End | 255 | 1 octet | Marks the end of the Options field in a DHCP message. This is used in all DHCP messages.

Options Requested by DHCP Clients

The options that clients can request and receive values for (assuming the administrator has specified values for them on the DHCP server) are shown in Table 16-3.

Table 16-3. Options for Which Clients Can Request and Receive Values
Option Name | Option Code (Decimal) | Option Length | Option Description
Router | 3 | Variable; but always a multiple of 4 octets | A list of IP addresses for routers on the client's subnet, which should be listed in order of preference. Generally, there is only one router—the default gateway—but multiple gateways can be specified.
Domain Name Servers | 6 | Variable; but always a multiple of 4 octets | A list of IP addresses for DNS servers (per RFC 1035) available to the client.
DNS Domain Name | 15 | Variable-length set of ASCII characters | The DNS domain name that the DHCP client should use when resolving host names using DNS.
WINS Server Names | 44 | Variable; but always a multiple of 4 | A list of WINS server IP addresses for client use. This is typically a primary and secondary server.
NetBIOS Over TCP/IP Node Type | 46 | 1 octet | Used to tell a TCP/IP client how NetBIOS names should be resolved, as follows: 0x1 B-node (broadcast) 0x2 P-node (point-to-point) 0x4 M-node (mixed) 0x8 H-node (hybrid) See Chapter 18, "Windows Internet Name Service (WINS)," for more detail on the NetBIOS Node Type.
NetBIOS Scope ID | 47 | Variable; minimum length is 1 | Specifies the NetBIOS over TCP/IP scope for the client, as specified in RFCs 1001 and 1002.

Vendor-Specific Options

In addition to the standard options already noted, the administrator can set specific options to be returned to clients of a particular class (such as Windows XP, Windows 2000, or Windows 98).

Table 16-4 shows the options that can be returned to a client running Windows 2000, Windows XP, and Windows Server 2003.

Table 16-4. Options That Can Be Returned to a Windows Client
Option Name | Option Code | Option Length | Option Description
Microsoft Disable NetBIOS Option | 1 | 4 | Informs the DHCP client whether or not to disable NetBIOS
Microsoft Release On Shutdown | 2 | 4 | Informs the DHCP client whether or not to release the DHCP lease on shutdown
Microsoft Default Router Metric Base | 2 | 4 | Specifies the default router metric base


Summary

DHCP is a simple client/server protocol that makes TCP/IP network configuration much simpler for the administrator. DHCP is based on the BOOTP protocol, which explains some of the message formats. Windows Server 2003 implements the latest RFCs that define both the DHCPINFORM message type and the new Vendor and User class options. The DHCP Server service in Windows Server 2003 supports all down-level Microsoft networking clients that support DHCP.


Domain Name System (DNS)

Chapter 17
Domain Name System (DNS)

Every host that runs TCP/IP must have a unique IP address that is used when communicating with other computers in a network. Computers operate easily with IP addresses, but people do not; users would rather identify systems by a name. To facilitate effective and efficient communication, users need to be able to refer to computers by name and still have their computer use IP addresses transparently.

In the early days of ARPANET, the forerunner to today's Internet, there were only a small number of computers attached to the network. The Network Information Center (NIC), located at the Stanford Research Institute (SRI), was responsible for compiling a single file named HOSTS.TXT that contained the names and addresses of every computer. Administrators would e-mail updates to SRI, which would then update the HOSTS.TXT file. ARPANET users would then download the new version of HOSTS.TXT using File Transfer Protocol (FTP) and convert it for local use (for example, copy HOSTS.TXT /Etc/Hosts on UNIX systems).

As ARPANET grew, it became obvious that this approach would not scale for the following three key reasons:

  • The bandwidth consumed in transmitting updated versions of an ARPANET-wide host file was proportional to the square of the number of hosts in the ARPANET. With the number of hosts growing at an exponential rate, the long-term impact was likely to be a load that no one host would be able to sustain.
  • The static flat host file also meant that no two computers on the entire ARPANET could have the same name. As the number of hosts grew, the risk of adding a duplicate name grew, as did the difficulty of trying to control this centrally.
  • The nature of the underlying network was changing—the large, time-sharing computers that had once made up the ARPANET were being superseded by networks of workstations, each of which needed to have a unique host name. This would be difficult, if not impossible, to control centrally.

As the ARPANET continued to grow, it became clear that a better solution was required. Several proposals were generated based on the concept of a distributed naming service, based on a hierarchical namespace. RFCs 882 and 883 emerged, which describe the design for a domain name system based on a distributed database containing generalized resource information. This design is described in RFCs 1034 and 1035. The service that is used in today's Internet has evolved beyond these early RFCs, and updates and refinements continue.


Overview of DNS

To facilitate communications between computers, computers can be given names within a namespace. The specific namespace defines the rules for naming a computer and for how names are resolved into IP addresses. When one computer communicates with other computers, it must resolve, or convert, a computer name into an IP address based on the rules of the namespace being used. This resolution is done by a name-resolution service.

There are two main namespaces, and name-resolution methods, used within Microsoft Windows Server 2003: NetBIOS, implemented by Windows Internet Naming Service (WINS; described in Chapter 18), and the Domain Name System (DNS), described in this chapter. Windows Server 2003 also provides support for other namespaces, such as Novell NetWare and Banyan Vines, although discussion of these is outside the scope of this book.

This section describes DNS and the DNS protocol that is used to provide name resolution.

What Is DNS?

DNS is an Internet Engineering Task Force (IETF) standard name service. The DNS service enables client computers on your network to register and resolve DNS domain names. These names are used to find and access resources offered by other computers on your network or other networks, such as the Internet. The following are the three main components of DNS:

  • Domain namespace and associated resource records (RRs) A distributed database of name-related information.
  • DNS name servers Servers that store the domain namespace and RRs and answer queries from DNS clients.
  • DNS resolvers The facility within a DNS client that contacts DNS name servers and issues name queries to obtain resource record information.

Key DNS Terms

This section describes the key components of DNS and defines important DNS terms.

Domain Namespace

The domain namespace is a hierarchical, tree-structured namespace, starting at an unnamed root used for all DNS operations. In the DNS namespace, each node and leaf in the domain namespace tree represents a named domain. Each domain can have additional child domains. Figure 17-1 illustrates the structure of an Internet domain namespace.

Domain Names

Each node in the DNS tree, as illustrated in Figure 17-1, has a separate name, referred to in RFC 1034 as a label. Each DNS label can be from 1 through 63 characters in length, with the root domain having a length of zero characters.

Figure 17-1. Domain namespace for the Internet.

A specific node's domain name is the list of the labels in the path from the node being named to the DNS namespace root. DNS convention is that the labels that compose a domain name are read left to right—from the most specific to the root (for example, www.kapoho.com). This full name is also known as the fully qualified domain name (FQDN).

Domain names can be stored as uppercase or lowercase, but all domain comparisons and domain functions are defined by RFC 1034 to be case-insensitive. Thus, www.kapoho.com is identical to WWW.KAPOHO.COM for domain naming operations.

Top-Level Domains

The domains directly below the root are called top-level domains (TLDs). Figure 17-1 illustrates some of the TLDs that have been defined for the Internet. Additional names (at least for the Internet) are difficult to create, although in 2000, the Internet Corporation for Assigned Names and Numbers (ICANN) did create an additional seven TLDs.

There are three categories of TLDs:

  • ARPA This is a special domain—it is only used today for reverse-name lookups.
  • Generic TLDs There are 14 TLDs, noted in Table 17-1. At one time the generic TLDs were all three characters long, but in November 2000, ICANN accepted seven new TLDs, some of which were longer (for example, .aero and .info).
  • Two-letter country-based domain names These country code domains are based on the International Organization for Standardization (ISO) country name, and are used principally by companies and organizations outside the United States. The exception is the United Kingdom, which uses .uk as the TLD, even though its ISO country code is GB.

Table 17-1 shows the TLDs in use today, as defined by RFC 1591.

Table 17-1. Top-Level Domains Used on the Internet
Domain Name | Use
aero | Exclusively reserved for the aviation community
biz | A TLD that is aimed at large and small companies around the world
com | Commercial organizations, such as microsoft.com for the Microsoft Corporation
coop | A TLD for cooperatives
edu | Educational institutions, now mainly four-year colleges and universities, such as cmu.edu for Carnegie Mellon University
gov | Agencies of the U.S. Federal Government, such as fbi.gov for the U.S. Federal Bureau of Investigation
info | An unrestricted domain aimed at providing information for worldwide consumption
int | Organizations established by international treaties, such as nato.int for NATO
mil | U.S. military, such as af.mil for the U.S. Air Force
museum | A domain restricted to museums and related organizations and individuals
name | A global domain for use by individuals, possibly developing into a global digital identity for users
net | Computers of network providers, organizations dedicated to the Internet, Internet service providers (ISPs), and so forth, such as internic.net for the Internet Network Information Center (InterNIC)
org | A TLD for groups that do not fit anywhere else, such as nongovernment or nonprofit organizations (for example, reiki.org for information about Reiki)
pro | A TLD for professionals such as doctors, lawyers, and accountants

Resource Records

A resource record (RR) is a record containing information relating to a domain that the DNS database can hold and that a DNS client can retrieve and use. For example, the host RR for a specific domain holds the IP address of that domain (host); a DNS client uses this RR to obtain the IP address for the domain (host).

Each DNS server contains the RRs relating to those portions of the DNS namespace for which it is authoritative (or for which it can answer queries sent by a host). When a DNS server is authoritative for a portion of the DNS namespace, those systems' administrators are responsible for ensuring that the information about that DNS namespace portion is correct. To increase efficiency, a given DNS server can cache the RRs relating to a domain in any part of the domain tree.

There are numerous RR types defined in RFCs 1034 and 1035, and in later RFCs. Most of the RR types are no longer needed or used, although all are fully supported by Windows Server 2003. Table 17-2 lists the key RRs that might be used in a Windows Server 2003 network. (For more detail on the contents of specific RRs, see the section entitled "DNS Resource Records," later in this chapter.)

Table 17-2. Key Resource Records as Used by a Windows Server 2003 Network
Resource Record Type | Contents | Use
A | Host Address | Used to hold a specific host's IP address.
CNAME | Canonical Name (alias) | Used to make an alias name for a host.
MX | Mail Exchanger | Provides message routing to a mail server, plus backup server(s) in case the target server is not active.
NS | Name Server | Provides a list of authoritative servers for a domain or indicates authoritative DNS servers for any delegated subdomains.
PTR | Pointer | Used for reverse lookup—resolving an IP address into a domain name using the in-addr.arpa domain.
SOA | Start of Authority | Used to determine the DNS server that is the primary server for a DNS zone and to store other zone property information.
SRV | Service Locator | Provides the ability to find the server providing a specific service. Active Directory service uses SRV records to locate domain controllers, global catalog servers, and Lightweight Directory Access Protocol (LDAP) servers.

RRs can be attached to any node in the DNS tree, although RRs are not provided in some domains. For example, Pointer (PTR) RRs are found only in domains below the in-addr.arpa domain. Thus, higher-level domains, such as microsoft.com, can have individual RRs (for example, Mail Exchanger [MX] records for mail to be sent to the Microsoft Corporation) as well as having subdomains that also might have individual RRs (for instance, eu.microsoft.com, which has a host record www.eu.microsoft.com).

Canonical Names

The Canonical Name (CNAME) RR enables the administrator to create an alias to another domain name. The use of CNAME RRs is recommended in the following scenarios:

  • When a host specified in an A RR in the same zone needs to be renamed. For example, if you need to rename kona.kapoho.com to hilo.kapoho.com, you could create a CNAME entry for kona.kapoho.com to point to hilo.kapoho.com.
  • When a generic name for a well-known service, such as ftp or www, needs to resolve to a group of individual computers (each with an individual A RR). For example, you might want www.kapoho.com to be an alias for kona.kapoho.com and hilo.kapoho.com. A user accessing www.kapoho.com is generally unaware of which computer is actually servicing the request.

DNS Query Operation

A DNS client issues a query operation against a DNS server to obtain some or all of the RR information relating to a specific domain, for instance, to determine which host A record or records are held for the domain named kapoho.com. If the domain exists and the requested RRs exist, the DNS server returns the requested information in a query reply message. The query reply message returns both the initial query and a reply containing the relevant records, assuming the DNS server can obtain the required RRs.

A DNS query, referred to in RFC 1034 as a standard query, contains a target domain name, a query type, and a query class. The query contains a request for the specific RR(s) that the resolver wishes to obtain (or a request to return all RRs relating to the domain).

DNS Update Operation

A DNS update operation is issued by a DNS client against a DNS server to update, add, or delete some or all of the RR information relating to a specific domain. A DNS client kona.kapoho.com could, for instance, update the host record for kona.kapoho.com to point to 10.10.1.100. The update operation is also referred to as a dynamic update.

DNS Zones

A DNS server that has complete information for part of the DNS namespace is said to be the authority for that part of the namespace. This authoritative information is organized into units called zones, which are the main units of replication in DNS. A zone contains one or more RRs for one or more related DNS domains.

The following are the four DNS zone types implemented in the DNS Server service for Windows Server 2003:

  • Standard primary Holds the master copy of a zone and can replicate it to secondary zones. All changes to a zone are made on the standard primary.
  • Standard secondary Contains a read-only copy of zone information that can provide increased performance and resilience. Information in a primary zone is replicated to the secondary zone by use of the zone transfer mechanism.
  • Active Directory-integrated A Microsoft proprietary zone type, where the zone information is held in the Windows Active Directory and replicated using Active Directory replication. Active Directory-integrated zones provide the administrator with considerable flexibility in terms of replication.
  • Stub A stub zone contains only the RRs needed to identify the authoritative DNS servers for the actual zone (SOA, NS, and Glue A records).

With traditional zones, the master copy of a zone is held in a primary zone on a single DNS server. On that server, the zone has a Start of Authority (SOA) RR that specifies it to be the primary zone. To improve performance and redundancy, the RRs contained in a primary zone can be automatically replicated to one or more secondary zones held on other (secondary) DNS servers. When changes are made to the zone, for instance, to add an A record, the changes are made to the primary zone and are transferred to the secondary zone. The transfer of zone information is handled by the zone replication process, which is described later in the section entitled "Zone Transfer."

When a zone is first created in Windows Server 2003, two RRs are created:

  • An SOA record, which provides some basic parameters for the zone, such as its name (for example, kapoho.com), as well as the IP address of the primary server, and so on.
  • An NS record, which identifies the server as one that is authoritative for this zone.

After the zone is created, the administrator can then add RRs to the zone, or can set the domain to be dynamically updated so that suitably configured hosts can automatically update this zone. For example, the administrator could add A records (host records) for hosts in the domain, and a computer capable of performing its own DNS dynamic updates—such as a computer running Windows 2000, Windows XP, or Windows Server 2003—can then directly update the A and PTR records on the DNS server. If the DNS client is also a Dynamic Host Configuration Protocol (DHCP) client, the administrator can configure a DHCP server to send the updates.

Once administrators have created the zone, they can add additional subdomains to the zone (for example, jh.kapoho.com). These might be added to delegate DNS services to a new building that is managed separately from the parent domain. This subdomain, which might reside in a separate zone on a separate DNS server, would have RRs added (for example, a host record for rebecca.jh.kapoho.com).

As Figure 17-2 illustrates, if you create subdomains, they can either be part of the same zone or belong to another zone on the same or a different DNS server. For example, the subdomain jh.kapoho.com, which is subordinate to kapoho.com, could be held in the same zone as kapoho.com or in a separate zone. This allows the subdomain to be managed and included as part of the original zone records, or to be delegated away to another zone created to support that subdomain.

Figure 17-2. Zones versus domains.

In this example, the domain kapoho.com has a subdomain of jh.kapoho.com. In addition, both domains contain a single host record. In this example, the domains jh.kapoho.com and kapoho.com are held in separate zones on different DNS servers. The kapoho.com zone holds one host record for kona.kapoho.com and the jh.kapoho.com domain holds the host record for the host rebecca.jh.kapoho.com.

Active Directory-Integrated Zones

An important feature of the DNS Server service for Windows Server 2003 is the ability to store DNS zones within Active Directory. An Active Directory-integrated zone is a primary DNS zone that is held within Active Directory and replicated to other domain controllers using Active Directory replication (and not traditional zone transfer). Although this method of storing zones is a Microsoft proprietary approach, it can provide some useful benefits.

The main advantage of Active Directory-integrated zones is that the zones become, in effect, multimaster, with the capability of updates being made to any DNS server. This can increase the fault tolerance of the DNS service. In addition, replication of zone information occurs using Active Directory replication, which can be more efficient across slow links because of the way that Active Directory compresses replication data between sites.

In Microsoft Windows 2000, all Active Directory-integrated zones were held in the domain name context of the Active Directory. This meant that any updates to an Active Directory zone would automatically be replicated to all domain controllers in that domain, whether or not they were DNS servers. For enterprises that had a large number of domain controllers in a domain, but not many DNS servers, this approach generated unnecessary replication. In addition, it meant some extra DNS replication planning for those organizations with multiple zones. This extra planning was needed to ensure, at a minimum, that all domain controllers were able to resolve the forest side locator records kept in the _msdcs subdomain of the organization's forest root domain name (for example, the _msdcs.kapoho.com domain for the organization's kapoho.com forest root domain).

With Windows Server 2003, the Active Directory-integrated zones can be held in one of three places:

  • All domain controllers in the domain (the Windows 2000 behavior).
  • All domain controllers that are DNS servers in the current domain; this eliminates DNS information being replicated to domain controllers that are not also DNS servers.
  • All domain controllers that are DNS servers in the entire forest; this simplifies DNS replication for larger organizations with multiple domains.

Reverse-Lookup Zones

Most queries sent to a DNS server involve a search based on the DNS name of another computer as stored in an address A RR. This type of query expects an IP address as the resource data for the answered response and it is generally referred to as a forward query. DNS also provides a reverse-lookup process, which enables a host to determine another host's name based on its IP address. For example, "What is the DNS domain name of the host at IP address 10.10.1.100?"

To allow for reverse queries, a special domain, in-addr.arpa, was defined and reserved in the Internet DNS namespace. Subdomains within the in-addr.arpa domain are named using the reverse ordering of the numbers in the dotted-decimal notation of IP addresses. The reverse ordering of the domain name is needed because, unlike DNS names, IP addresses are read from left to right, but are interpreted in the opposite manner (that is, the left-most part is more generalized than the right-most part). For this reason, the order of IP address octets is reversed when building the in-addr.arpa domain tree; for example, the reverse-lookup zone for the subnet 192.168.100.0 is 100.168.192.in-addr.arpa.

This approach enables the administration of lower limbs of the DNS in-addr.arpa tree to be delegated to an organization when it obtains a set of IP addresses from an IP registry.

The in-addr.arpa domain tree makes use of the PTR RR, which is used to associate the IP address with the owning domain name. This lookup should correspond to an A RR for the host in a forward-lookup zone.

The in-addr.arpa domain is used only for Internet Protocol version 4 (IPv4)-based networks. In the DNS Microsoft Management Console (MMC) snap-in for Windows Server 2003, the DNS server's New Zone Wizard uses this domain when it creates a new reverse-lookup zone. Internet Protocol version 6 (IPv6)-based reverse-lookup zones are based on the domain ip6.arpa.

Reverse DNS zones have the same SOA and NS records as forward lookup zones. You can also configure reverse lookup zones to be traditional primary or secondary zones or to be Active Directory-integrated. Active Directory-integrated reverse lookup zones replicate in the same manner as Active Directory-integrated forward lookup zones.

Reverse Queries

A reverse query is one in which the DNS server is requested to return the DNS domain name for a host at a particular IP address. Reverse-Lookup Query messages are, in effect, standard queries, but relating to the reverse-lookup zone. The reverse-lookup zone is based on the in-addr.arpa domain name and mainly holds PTR RRs.

The creation of reverse-lookup zones and the use of PTR RRs for identifying hosts are optional parts of the DNS standard. Reverse-lookup zones are not required to use Windows Server 2003, although some networked applications can be configured to use the reverse-lookup zones as a form of additional security. In addition, the Nslookup.exe tool displays an error if the reverse-lookup zone for a DNS server is not available.

Inverse Queries

Inverse queries, originally described in RFC 1034, look up a host name based on its IP address. Inverse queries use a nonstandard DNS query operation. Inverse queries are now outdated and are generally not used by modern applications and operating systems.

Some early versions of Nslookup.exe, a utility used to test and troubleshoot a DNS service, did attempt to issue inverse queries. A Windows Server 2003 DNS server recognizes and accepts inverse query messages and answers them with a "fake" inverse query response. The version of Nslookup.exe that ships with Windows Server 2003 does not support inverse queries.

DNS Query Classes

DNS queries fall into one of two classes: recursive queries and iterative queries.

A recursive query is a DNS query sent to a DNS server in which the querying host asks the DNS server to provide a complete answer to the query, even if that means contacting other servers to provide the answer. When sent a recursive query, the DNS server issues separate iterative queries to other DNS servers on behalf of the querying host to obtain an answer for the query.

An iterative query is a DNS query sent to a DNS server in which the querying host requests it to return the best answer it can provide without seeking further assistance from other DNS servers.

In general, host computers issue recursive queries against DNS servers. The host assumes that the DNS server either knows the answer to the query or can find the answer. On the other hand, a DNS server issues iterative queries against other DNS servers if it is unable to answer a recursive query from cached or locally stored information.

DNS Resolver

In Windows Server 2003, the DNS resolver is a system component on a DNS client that performs DNS queries against a DNS server (or servers). The administrator configures the Windows Server 2003 TCP/IP protocol with the IP address of at least one DNS server to which the resolver sends one or more queries for DNS information.

In Windows Server 2003, the resolver is part of the DNS Client service. This service is installed automatically when Windows Server 2003 is installed, and runs within one of the many SVCHOST processes. Like most Windows Server 2003 services, the DNS Client service logs on using the System account. You can see the DNS Client service named Dnscache in the SVCHOST process with PID 812, in the following output:

C:\Documents and Settings\Administrator>tasklist /svc

Image Name                   PID Services

========================= ====== =============================================

System Idle Process            0 N/A

System                         4 N/A

smss.exe                     288 N/A

csrss.exe                    356 N/A

winlogon.exe                 380 N/A

services.exe                 424 Eventlog, PlugPlay

lsass.exe                    436 HTTPFilter, kdc, Netlogon, NtLmSsp,

                                 PolicyAgent, ProtectedStorage, SamSs

svchost.exe                  572 RpcSs

svchost.exe                  608 TermService

svchost.exe                  812 Dhcp, Dnscache

svchost.exe                  876 LmHosts

svchost.exe                  888 AppMgmt, BITS, Browser, CryptSvc, dmserver,

                                 ERSvc, EventSystem, helpsvc, lanmanserver,

                                 lanmanworkstation, Netman, Nla, RasMan,

                                 Schedule, seclogon, SENS, ShellHWDetection,

                                 uploadmgr, W32Time, winmgmt, wuauserv, WZCSV

spoolsv.exe                 1132 Spooler

msdtc.exe                   1212 MSDTC

certsrv.exe                 1304 CertSvc

dfssvc.exe                  1332 Dfs

dns.exe                     1364 DNS

inetinfo.exe                1468 IISADMIN, NntpSvc, SMTPSVC

InoRpc.exe                  1504 InoRPC

InoRT.exe                   1676 InoRT

InoTask.exe                 1696 InoTask

ismserv.exe                 1784 IsmServ

llssrv.exe                  1812 LicenseService

ntfrs.exe                   1864 NtFrs

svchost.exe                  216 RemoteRegistry

locator.exe                  308 RpcLocator

wins.exe                     784 WINS

svchost.exe                 1360 W3SVC

explorer.exe                3108 N/A

svchost.exe                 3220 TapiSrv

Realmon.exe                 3228 N/A

cmd.exe                     3240 N/A

cmd.exe                     3248 N/A

mmc.exe                     2520 N/A

mmc.exe                     3636 N/A

notepad.exe                 2604 N/A

setiathome-3.03.i386-winn   3196 N/A

setiathome-3.03.i386-winn   2004 N/A

cmd.exe                     3016 N/A

wmiprvse.exe                2760 N/A

tasklist.exe                3020 N/A

DNS Resolver Cache

An IP host that needs to contact another host on a regular basis needs to resolve a particular DNS name many times (for example, the name of the mail server). To avoid having to send queries to a DNS server each time the host wants to resolve the name, the DNS Client service on Windows Server 2003 hosts implements a local cache of DNS information.

The DNS Client service caches RRs from query responses that the DNS Client service receives. The information is held for a set Time-To-Live (TTL) and, when present, is used to answer subsequent queries and avoid sending the query to a DNS server. By default, the TTL used for the local DNS cache is the TTL value received in the DNS query response. When a query is resolved, the authoritative DNS server for the resolved domain defines the TTL for a given RR.

You can use the IPCONFIG command with the /DISPLAYDNS option to display the current DNS resolver cache contents. The following output shows an example:

C:\>ipconfig /displaydns

Windows IP Configuration

    1.0.0.127.in-addr.arpa

    ————————————————————

    Record Name . . . . . : 1.0.0.127.in-addr.arpa.

    Record Type . . . . . : 12

    Time To Live  . . . . : 0

    Data Length . . . . . : 4

    Section . . . . . . . : Answer

    PTR Record  . . . . . : localhost

    7c5fa925-791e-4aa3-b8d0-ea70ed74adc4._msdcs.kapoho.com

    ————————————————————

    Record Name . . . . . : 7c5fa925-791e-4aa3-b8d0-ea70ed74adc4._msdcs.kapoho.com

    Record Type . . . . . : 5

    Time To Live  . . . . : 595

    Data Length . . . . . : 4

    Section . . . . . . . : Answer

    CNAME Record  . . . . : kapoho10.kapoho.com

    maui

    ————————————————————

    Record Name . . . . . : maui.kapoho.com

    Record Type . . . . . : 1

    Time To Live  . . . . : 1195

    Data Length . . . . . : 4

    Section . . . . . . . : Answer

    A (Host) Record . . . : 10.10.1.62

    localhost

    ————————————————————

    Record Name . . . . . : localhost

    Record Type . . . . . : 1

    Time To Live  . . . . : 0

    Data Length . . . . . : 4

    Section . . . . . . . : Answer

    A (Host) Record . . . : 127.0.0.11

Negative Caching

The DNS Client service for Windows Server 2003 provides negative caching support. Negative caching occurs when an RR for a queried domain name does not exist or when the domain name itself does not exist, in which case, the lack of resolution is stored. Negative caching prevents the repetition of additional queries for RRs or domains that do not exist.

If a query is made to a DNS server and the response is negative, subsequent queries for the same domain name are answered negatively, through the cache, for a default time of 300 seconds (5 minutes). To avoid the continued negative caching of stale information, any query information negatively cached is held for a shorter period than positive query responses. However, this negative caching time-out value can be changed in the registry using the following NegativeCacheTime registry value:

NegativeCacheTime

Location: HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\Dnscache\Parameters

Data type: REG_DWORD

Default value: 0x12c (300 seconds, or 5 minutes)

Valid range: 0-0xFFFFFFFF

Present by default: No

Negative Cache Time sets the number of seconds for the negative caching time-out. The recommended time is less than 1 day, which prevents very stale records. Negative caching reduces the load on DNS servers, but should the relevant RRs become available, later queries can be issued to obtain the information.

Zone Transfer

To improve the resilience and performance of the DNS resolution, it is normal to have at least one standard secondary zone for each standard primary zone, where the secondary zone is held on another DNS server. Depending on the exact nature of the organization, multiple standard secondary zones might be appropriate. When changes are made to the primary zone, it is important that the zone information is promptly replicated to all secondary zones. The process of transferring zone information from a primary to a secondary zone is called a zone transfer.

Zone transfers usually occur automatically at intervals defined in the zone's SOA record. Zone transfers can also be performed manually using the DNS MMC snap-in, which might be done if the administrator suspects the secondary zone has not been properly updated.

When a standard secondary zone is created on a Windows Server 2003 DNS server, the DNS server transfers all RRs from the standard primary zone to the new standard secondary zone. The DNS server does this to obtain a full copy of all RRs for the zone. In many of the early DNS server implementations, this same method of full transfer for a zone is used also when the secondary zone requires updating to align it with the primary zone, after changes are made to the primary zone. For large zones, this can be very time-consuming and wasteful of network resources. This can be an issue because a zone transfer is needed each time the primary zone is updated, such as when a new host is added to the domain or the IP address for a host is changed.

After the RRs have been replicated, the server on which the new standard secondary zone resides checks at regular intervals with the server on which the primary zone resides to determine if there are any changes to the primary zone. This is determined by polling the primary zone on a regular basis, defined by the network administrator in the Zone SOA record in the standard primary zone, and checking if the zone's version number has changed. If the version number has been incremented, a zone transfer is necessary. This process is shown in the following Network Monitor trace (Capture 17-06, included in the \Captures folder on the companion CD-ROM):

1   21.108471  Kapoho10   Mahimahi   DNS    0x6000:Std Qry for kapoho.com. of
type SOA on class INET addr. 10.10.1.74  10.10.1.200
2   21.108471  Mahimahi   Kapoho10   DNS    0x6000:Std Qry Resp. for
kapoho.com. of type SOA on class INET addr. 10.10.1.200  10.10.1.74
3   21.108471  Kapoho10   Mahimahi   DNS    0x4000:Std Qry for kapoho.com. of
type Req for incrmntl zn Xfer on class INET addr. 10.10.1.74  10.10.1.200
4   21.108471  Mahimahi   Kapoho10   DNS    0x4000:Std Qry Resp. for
kapoho.com. of type SOA on class INET addr. 10.10.1.200 10.10.1.74

In this trace, the DNS server holding the secondary zone (Kapoho10) queries the primary zone to obtain the primary's SOA record, which will tell the secondary zone the version number of the zone at the primary server. The secondary server discovers that the version number on the primary DNS server is higher and requests a zone transfer.

For manually maintained DNS servers, updating (or not) the SOA records version number traditionally has been a key troubleshooting issue—changes are made to a primary zone, but the version number is unchanged, and thus the changes are not replicated to the secondary zone. With Windows Server 2003, changes made to the zone, either by manual update using the DNS snap-in or by dynamic registration, trigger an update to the version number, thus enabling the secondary server to carry out the server transfer at the next poll interval.

Incremental Zone Transfers

For large zones, zone transfers can consume a significant amount of bandwidth, especially when a zone transfer is carried across slow wide area network (WAN) links. To improve the efficiency of zone transfers, the DNS Server service for Windows Server 2003 implements incremental zone transfer, as defined in RFC 1995. With incremental zone transfers, only the changes to the zone are transferred, rather than the entire zone. This can significantly reduce the traffic needed to keep a secondary zone current.

With incremental zone transfers, the differences between the source and replicated versions of the zone are first determined. If the zones are identified as the same version—as indicated by the serial number field in the SOA RR of each zone—no transfer is made.

If the serial number for the zone at the source is greater than at the requesting secondary server, a transfer is made of only those changes to RRs for each incremental zone version. For an incremental zone transfer query to succeed and changes to be sent, the zone's source DNS server must keep a history of incremental zone changes to use when answering these queries. Windows Server 2003 stores the incremental zone transfer information for each zone in a text file in the %Systemroot%\System32\Dns folder with a name based on the name of the file holding the zone data (which was specified when the zone was defined). Thus, if the zone information for the kapoho.com zone is held in the file Kapoho.com.dns, the incremental update log is held in Kapoho.com.dns.log. A part of this log, which was used by the DNS server on kapoho10 to perform the preceding zone transfer, is shown here:

$SOURCE  ADMIN

$VERSION 84

$ADD

rebecca                 A	10.10.1.199

$SOURCE  ADMIN

$VERSION 85

$DELETE

@                       IN  SOA mahimahi.kapoho.net. hostmaster. (

                            81           ; serial number

                            15           ; refresh

                            600          ; retry

                            86400        ; expire

                            3600       ) ; default TTL

$ADD

                        IN  SOA mahimahi.kapoho.net. hostmaster. (

                            85           ; serial number

                            15           ; refresh

                            600          ; retry

                            86400        ; expire

                            3600       ) ; default TTL

Active Directory-Integrated Zone Replication

Standard zones use traditional zone replication mechanisms to transfer zone information. Active Directory-integrated zones, however, use Active Directory replication to replicate updates. This provides the following three key benefits:

  • DNS servers become multimaster. With standard DNS zones, all updates need to be made to a single DNS server—in other words, to the server containing the primary zone. With Active Directory integration, any DNS server can accept the updates, which provide improved performance and scaling, as well as better fault tolerance.
  • Active Directory replication is both more efficient and quicker. It transfers updated-only properties, not the entire zone, which means only the changes are transmitted across the network. In addition, replication between sites, typically involving slower links, can be highly compressed.
  • The administrator only needs to plan and implement a single replication topology for Active Directory. This also replicates DNS changes but simplifies the planning and reduces bandwidth used.

For organizations using Active Directory, Active Directory-integrated zones are generally recommended. If the organization is, however, using third-party DNS servers, these servers are unlikely to support Active Directory-integrated zones.

Delegation of Domains

DNS is a distributed database of information designed specifically to overcome the limitations of the earlier HOSTS.TXT approach to name resolution. The key to scaling DNS to handle large namespaces or networks, such as the Internet, is the ability to delegate the administration of domains. Domain delegation occurs when the responsibility of the RRs of a subdomain is passed from the owner of the parent domain to the owner of the subdomain.

At the heart of the Internet are 13 root servers, named A.ROOT-SERVERS.NET through M.ROOT-SERVERS.NET. These root servers are widely distributed around the world, although most are located in the United States. The root servers hold data for all the generic TLDs, such as .com, .org, .net, and .name, as well as for geographical domains, such as .uk and .jp.

Below the root and TLDs are the domains and subdomains belonging to individual organizations. In some TLDs, additional hierarchy levels are provided. For example, in the .uk domain, there are subdomains co.uk for U.K.-based companies (for instance, psp.co.uk) and ac.uk for academic institutions (for instance, ic.ac.uk for Imperial College), and so forth.

As previously illustrated in Figure 17-2, there are boundaries between zones where responsibility for administration is delegated from zones closer to the TLDs to zones one degree farther from the TLDs. Within the kapoho.com domain there is a subdomain jh.kapoho.com. Responsibility for the subordinate domain can be delegated to a different set of DNS servers.

To implement a delegation, the parent zone must have both an A RR and a Name Service (NS) RR. Both should point to the new delegated domain's DNS servers. In the kapoho.com zone, illustrated in Figure 17-2, there must be an A and an NS record in the parent domain that point to a server authoritative for jh.kapoho.com. Windows Server 2003 has a Delegation Wizard to simplify the task of implementing a delegation.

Forwarder and Slave DNS Servers

When a resolver contacts a DNS server to resolve a domain name and return relevant RRs, the contacted DNS server first attempts to perform the lookup using zones defined on the server or information contained in its own cache. If this fails, by default the DNS server then starts to issue iterative queries to resolve the domain. This starts at the namespace root. If the DNS server is one of several at a site connected to the outside world by slow links, this default behavior might not be desirable.

As illustrated by Figure 17-3, a forwarder is a DNS server that other DNS servers contact before attempting to perform the necessary name resolution.

Figure 17-3. DNS forwarder.

In this example, when any of the DNS clients send recursive queries to DNS servers A, B, and C, each DNS server attempts to answer the query from locally held zones or from its local cache. If this is unsuccessful, these servers issue a recursive query to DNS server D, which has a better chance of answering the query from its own cache. This arrangement can reduce the external traffic needed to resolve host queries.

If the forwarder (server D in the example) is unable to answer the queries sent by DNS servers A, B, or C, these servers attempt to resolve the queries themselves by issuing iterative queries, which, again, might not be desirable.

A slave server is a DNS server that attempts to resolve name queries by checking its cache and local zone files, and then it forwards the query to a DNS forwarder. A slave server does not attempt to perform iterative queries if the DNS forwarder is unable to answer the query.

Round Robin Load Balancing

Round robin is an approach for performing DNS load balancing. It is used to share and distribute the network resource load. With round robin, the answers contained in a query, for which multiple RRs exist, are rotated each time the query is answered. Round robin is a very simple method for load balancing a client's use of Web servers and other frequently queried multihomed services.

For round robin to work, multiple A RRs for the queried name must exist in the zone being queried. For example, suppose there were three physical Web servers servicing www.kapoho.com, with the IP addresses of 10.1.1.151, 10.1.152, and 10.1.1.153 with three A records for www.kapoho.com pointing to the different servers. Round robin would need to be configured at the server. Round robin is enabled by default in Windows Server 2003. The first query for this domain would be returned in the order 10.1.1.151, 10.1.1.152, and 10.1.1.153. The following query would return 10.1.1.152, 10.1.1.153, and 10.1.1.151, and so on. Because the client usually takes the first IP address, the first query would use the IP address 10.1.1.151, and the second would use 10.1.1.152.

By default, the DNS Server service for Windows Server 2003 performs round robin for all RR types. You can specify that certain RR types do not have round robin rotation applied by setting the following registry entry:

DoNotRoundRobinTypes

Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters

Data type: REG_SZ

Default value: none

Present by default: No

The string for DoNotRoundRobinTypes is a comma-separated list of valid RR types. If you wanted to not round robin PTR, SRV, and NS records, the DoNotRoundRobinTypes value would be "ptr,srv,ns."

You can also turn off round robin entirely by using the DNS snap-in or by setting the following registry entry:

RoundRobin

Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters

Data type: REG_DWORD

Default value: 1

Valid range: 0-1 (1 - Enable round robin, 0 - Disable round robin)

Present by default: Yes

DNS Dynamic Updates

For large networks, getting all the necessary RR information into the DNS and keeping it current can be a significant task. To simplify the task, Windows Server 2003 includes support for dynamic updates to DNS, as described in RFC 2136.

With DNS dynamic updates, the client sends a DNS registration message to the DNS server, instructing the server to update the A record for the dynamic update host. Additionally, if the client is also a DHCP client of a Windows Server 2003 DHCP server, every time there is an address event (for instance, a new address or address renewal), as part of the DHCP lease-management process, the Windows DHCP client sends DHCP Option 81 to the DHCP server along with its fully qualified name. Option 81 instructs the DHCP server to register a PTR RR on its behalf. Windows Server 2003 computers that are statically configured register both the A RR and the PTR RR with the DNS server themselves.

If a Windows DHCP client talks to a lower level DHCP server that does not handle Option 81, the client registers a PTR RR on its own. The DNS Server service for Windows Server 2003 is capable of handling dynamic updates.

This approach (client updating the A record, DHCP server updating the PTR record) is taken because only the client knows which IP addresses on the host map to a given host name. The DHCP server might not be able to properly do the A RR registration because it has incomplete knowledge. If appropriate, the DHCP server also can be configured to register both records with the DNS.

IPv6 Support

IPv6 is a new version of IP. The DNS Server service for Windows Server 2003 provides support for IPv6 by implementing several additional pieces of functionality, including the following:

  • AAAA RR This new record type is defined to store a host's IPv6 address. A multihomed IPv6 host (for example, a host that has more than one IPv6 address) must have more than one AAAA record (known as a "quad A" record). The AAAA RR is similar to the A RR, using the larger IP address size. The 128-bit IPv6 address is encoded in the data portion of an AAAA RR in network byte order (high-order byte first).
  • AAAA query The AAAA query for a specified domain name in the Internet class returns all associated AAAA RRs in the answer section of a response. The AAAA query does not perform additional section processing.
  • IP6.ARPA domain This domain is used to provide reverse-lookup faculties for IPv6 hosts (as the in-addr.arpa domain does for IPv4 addresses).

Similar to the in-addr.arpa domain for IPv4, an IPv6 address is represented as a name in the IP6.ARPA domain by a sequence of nibbles (hexadecimal digits) separated by periods with the suffix .IP6.ARPA. The sequence of nibbles is encoded in reverse order; for instance, the low-order nibble is encoded first, with the highest order nibble last. A hexadecimal digit represents each nibble. For example, the inverse-lookup domain name corresponding to the address 3ffe:ffff:1:2:3:4:567:89ab would be

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.f.f.f.f.e.f.f.3.IP6.ARPA.

Finally, to support IPv6, all existing DNS query types that perform type A additional section processing—such as NS or MX query types—must support both A and AAAA records and must do any processing associated with both of these record types. This means the DNS server adds any relevant IPv4 addresses and any relevant IPv6 addresses available locally to the additional section of a response when processing any one of these queries.

DNS Extension Mechanism

The DNS protocol, on the wire, uses a number of fixed-length fields or fields with a set of possible values that is nearly used up. One example of this is the maximum allowable DNS packet size when using User Datagram Protocol (UDP), 512 bytes. To enable DNS clients and servers to use larger values, RFC 2671 defines a general extension model for DNS as well as the first extension (EDNS0). EDNS0 specifically provides a mechanism for clients and servers to use larger DNS messages over UDP. It is anticipated that further DNS extensions will be proposed and will be identified as EDNS1, EDNS2, and so forth.

EDNS0 enables DNS clients to advertise and support the transfer of DNS messages larger than 512 bytes. A DNS client that is capable of handling EDNS0 sends queries over UDP that contain a special pseudo-RR, the OPT resource record, to note the UDP packet size that the DNS client can support. This pseudo-RR enables servers that can also handle EDNS0 to increase the size of a DNS reply and send as many RRs as are allowed in the maximum UDP packet size (specified in the OPT RR).

The OPT RR is not an RR that you can add to the DNS database, but it is generated if and when a host can handle the DNS extensions. In addition, the OPT RR does not contain actual DNS data. Rather it contains the DNS client's maximum UDP payload size in its CLASS field, as well as the number of octets in the largest UDP payload that the client can deliver in the clients' network.

By default, the DNS server includes an OPT RR in the additional section of any query it sends if it is capable of supporting EDNS0. The OPT record gives the UDP maximum length of a DNS response. If a DNS server receives a DNS query that does not contain an OPT RR, the server assumes the querier's system does not support EDNS0 and all responses to this system are truncated if the maximum size is greater than 512 octets.

If the DNS Server service for Windows Server 2003 receives either a request or response from any host that has an OPT record, the DNS server caches this information, by default, for one week. In addition, if a request or a response does not contain an OPT record, this is also cached.

You can modify the EDNS cache time-out by modifying the following registry value:

EDNSCacheTimeout

Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters

Data type: REG_DWORD

Default value: 25200 (7 days)

Valid range: 3600 (1 hour) to 15724800 (182 days)

Present by default: No

If a DNS server does not support ENDS0, then queries containing the OPT resource might not be handled and might return an error code. The error codes that could be encountered are as follows:

  • FORMERR (1) The name server did not interpret the OPT RR.
  • SERVFAIL(2) The name server did not process the query because of a problem with the name server.
  • NOTIMPL(4) The name server does not support the kind of query requested.

DNS Security

RFC 2535 defines a set of facilities, known as DNS Security (DNSSEC), that provides authentication and data integrity of DNS data to resolvers. These extensions allow digital signatures to be encrypted using private keys. These signatures can then be sent as RRs from DNS servers hosting signed (DNSSEC-compliant) zones to resolvers. DNSSEC-aware revolvers can then authenticate these signatures using public keys. The digital signatures and public keys are added to a signed zone in the form of RRs.

With DNSSEC, a zone has a public and a private key. The private key, which is not loaded in the zone, is used to sign a zone or parts of a zone. The public key is used to validate this digital signature. The zone's private key can be used to sign each domain name in the zone (for example, rebecca.kapoho.com). These signatures can then be added to the zone and returned as part of a query to a DNSSEC-aware DNS resolver. Such a resolver can use the public key to authenticate the RRs.

With DNSSEC, a zone's public key is stored in a KEY RR. The digital signature is contained in a SIG RR. KEY RRs must be provided to the resolver before it can authenticate SIG RRs. DNSSEC introduces one further RR, the NXT record, which can be used to provide cryptographic assurance to a resolver that a particular RR does not exist.

DNSSEC is not fully supported in the DNS Server service for Windows Server 2003. The DNS Server service for Windows Server 2003 provides basic support of the DNSSEC protocol, as defined in RFC 2535. This would enable, for example, a Windows Server 2003 DNS server to operate as a secondary to a BIND server that fully supports DNSSEC. In particular, Windows Server 2003 provides no way to sign or verify the digital signatures. The Windows Server 2003 resolver does not validate any of the DNSSEC data returned as the result of a query.


How DNS Works

In this section, the DNS client and server functions are described in more detail.

Configuring DNS Client Functions

With Windows Server 2003, there is generally very little configuration to do for a client with respect to DNS. Generally, it is only necessary to configure the host with the IP address of a primary and secondary DNS server. This can be simplified by using DHCP to assign the IP address of the DNS servers.

Usually, DNS default client behavior is adequate. However, in certain cases, some change to the default behavior might be appropriate. The following registry keys can be used to change how the Windows Server 2003 family DNS client works.

Specifying a Default TTL

By default, the TTL for the A and PTR RR updates sent by a DNS client is 20 minutes. To change the TTL value, you can configure the following registry value:

DefaultRegistrationTTL

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value type: REG_DWORD

Default: 0x4B0 (1200 seconds, or 20 minutes)

Valid range: 0-0xffffffff

Present by default: No

After setting this registry key, you do not need to reboot your computer for the updated TTL to be used. All registration requests contain the new TTL set in the value entry.

Disabling Dynamic Updates

Although the automatic updating of DNS zones by a host can be useful, in some environments it might not be desirable. You can use the following registry key to disable DNS dynamic updates either for a computer running Windows Server 2003 as a whole, or for just one or more interfaces on that computer. This entry disables the DNS client from registering the A and PTR records for some or all interfaces on a computer running Windows Server 2003.

DisableDynamicUpdate

Key: KEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Or

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Tcpip\Parameters\Interfaces\<InterfaceGUID>

Value type: REG_DWORD—Boolean

Valid range: 0, 1 (False, True)

Default: 0

Present by default: No

Resolving Names

DNS name resolution occurs when a DNS resolver sends a DNS server a query message containing a request to find the name and return certain RRs. The query message contains the domain name to search for, plus a code indicating the records that should be returned.

The following Network Monitor trace (Capture 17-01, included in the \Captures folder on the companion CD-ROM) shows the process of issuing and resolving a name query.

1  7.014382  0050564050E1  3COM  6B15C7  DNS  0x1C:Std Qry for
kona.kapoho.com. of type Host Addr on class INET addr. 10.10.1.68  10.10.1.200

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0xCC5; Proto = UDP; Len: 61

+ UDP: Src Port: Unknown, (1026); Dst Port: DNS (53); Length = 41 (0x29)

  DNS: 0x1C:Std Qry for kona.kapoho.com. of type Host Addr on class INET addr.

      DNS: Query Identifier = 28 (0x1C)

      DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error

          DNS: 0............... = Request

          DNS: .0000........... = Standard Query

          DNS: .....0.......... = Server not authority for domain

          DNS: ......0......... = Message complete

          DNS: .......1........ = Recursive query desired

          DNS: ........0....... = No recursive queries

          DNS: .........000.... = Reserved

          DNS: ............0000 = No error

      DNS: Question Entry Count = 1 (1)

      DNS: Answer Entry Count = 0 (0)

      DNS: Name Server Count = 0 (0)

      DNS: Additional Records Count = 0 (0)

      DNS: Question Section: kona.kapoho.com. of type Host Addr on class INET addr.

          DNS: Question Name: kona.kapoho.com.

          DNS: Question Type = Host Address

          DNS: Question Class = Internet address class

2  7.024396  3COM  6B15C7  0050564050E1  DNS  0x1C:Std Qry Resp. for
kona.kapoho.com. of type Host Addr on class INET addr. 10.10.1.200  10.10.1.68

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x43AE; Proto = UDP; Len: 77

+ UDP: Src Port: DNS, (53); Dst Port: Unknown (1026); Length = 57 (0x39)

  DNS: 0x1C:Std Qry Resp. for kona.kapoho.com. of type Host Addr on class INET addr.

      DNS: Query Identifier = 28 (0x1C)

      DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - No error

          DNS: 1............... = Response

          DNS: .0000........... = Standard Query

          DNS: .....1.......... = Server authority for domain

          DNS: ......0......... = Message complete

          DNS: .......1........ = Recursive query desired

          DNS: ........1....... = Recursive queries supported by server

          DNS: .........000.... = Reserved

          DNS: ............0000 = No error

      DNS: Question Entry Count = 1 (1)

      DNS: Answer Entry Count = 1 (1)

      DNS: Name Server Count = 0 (0)

      DNS: Additional Records Count = 0 (0)

      DNS: Question Section: kona.kapoho.com. of type Host Addr on class INET addr.

          DNS: Question Name: kona.kapoho.com.

          DNS: Question Type = Host Address

          DNS: Question Class = Internet address class

      DNS: Answer section: kona.kapoho.com. of type Host Addr on class INET addr.

          DNS: Resource Name: kona.kapoho.com.

          DNS: Resource Type = Host Address

          DNS: Resource Class = Internet address class

          DNS: Time To Live = 1200 (0x4B0)

          DNS: Resource Data Length = 4 (0x4)

          DNS: IP address = 10.10.2.200

In this trace, a client sends a DNS query to request the DNS server to return all A RRs for kona.kapoho.com. The query response contains the question entry and the answer RRs. In this case, there is only one A record to return pointing to 10.10.2.200.

Network Monitor trace 17-2 (Capture 17-02, included in the \Captures folder on the companion CD-ROM) shows a Reverse-Lookup Query. In this trace, the querying host at 10.10.1.68 queries DNS for the host name for the host at 10.10.1.200. To determine this, the resolver queries for 200.1.10.10.in-addr.arpa and requests any PTR records. The DNS server then returns the PTR record, which shows the host to be mahimahi.kapoho.com.

Resolving Aliases

The CNAME RR allows you to create an alias for a host. For example, you could create an alias ns1.kapoho.com for the host mahimahi.kapoho.net. When a resolver performs forward name resolution, it does not know, in advance, whether the name relates to a Host Address (A) RR or to a CNAME. If it relates to the CNAME, the DNS server could just return the CNAME record. This would, however mean that the real host name still needs to be resolved. To avoid extra DNS traffic, when a DNS server returns a CNAME in response to an A RR lookup, a Windows Server 2003 DNS server also returns the A record relating to the CNAME.

The following Network Monitor trace (Capture 17-03, included in the \Captures folder on the companion CD-ROM) shows the process of issuing and resolving a canonical name.

1  0.000000  0050564050E1  3COM  6B15C7  DNS  0x57:Std Qry for ns1.kapoho.com.
of type Host Add 10.10.1.68  10.10.1.200

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x9C66; Proto = UDP; Len: 60

+ UDP: Src Port: Unknown, (1026); Dst Port: DNS (53); Length = 40 (0x28)

  DNS: 0x57:Std Qry for ns1.kapoho.com. of type Host Addr on class INET addr.

      DNS: Query Identifier = 87 (0x57)

    + DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error

      DNS: Question Entry Count = 1 (1)

      DNS: Answer Entry Count = 0 (0)

      DNS: Name Server Count = 0 (0)

      DNS: Additional Records Count = 0 (0)

      DNS: Question Section: ns1.kapoho.com. of type Host Addr on class INET
addr.

          DNS: Question Name: ns1.kapoho.com.

          DNS: Question Type = Host Address

          DNS: Question Class = Internet address class

2  0.000000  3COM  6B15C7  0050564050E1  DNS  0x57:Std Qry Resp. for
ns1.kapoho.com. of type Ca 10.10.1.200  10.10.1.68

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x4D06; Proto = UDP; Len: 99

+ UDP: Src Port: DNS, (53); Dst Port: Unknown (1026); Length = 79 (0x4F)

  DNS: 0x57:Std Qry Resp. for ns1.kapoho.com. of type Canonical name on class

       INET addr.

      DNS: Query Identifier = 87 (0x57)

    + DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode -
No error

      DNS: Question Entry Count = 1 (1)

      DNS: Answer Entry Count = 2 (0x2)

      DNS: Name Server Count = 0 (0)

      DNS: Additional Records Count = 0 (0)

      DNS: Question Section: ns1.kapoho.com. of type Host Addr on class INET
addr.

          DNS: Question Name: ns1.kapoho.com.

          DNS: Question Type = Host Address

          DNS: Question Class = Internet address class

      DNS: Answer section: ns1.kapoho.com. of type Canonical name on class
INET addr.

           (2 records present)

          DNS: Resource Record: ns1.kapoho.com. of type Canonical name on
class INET addr.

              DNS: Resource Name: ns1.kapoho.com.

              DNS: Resource Type = Canonical name for alias

              DNS: Resource Class = Internet address class

              DNS: Time To Live = 3600 (0xE10)

              DNS: Resource Data Length = 11 (0xB)

              DNS: Owner primary name: mahimahi.kapoho.com.

          DNS: Resource Record: mahimahi.kapoho.com. of type Host Addr on
class INET addr.

              DNS: Resource Name: mahimahi.kapoho.com.

              DNS: Resource Type = Host Address

              DNS: Resource Class = Internet address class

              DNS: Time To Live = 3600 (0xE10)

              DNS: Resource Data Length = 4 (0x4)

              DNS: IP address = 10.10.1.200

In this trace, the DNS client sends a DNS query to the DNS server requesting the A (host) record for ns1.kapoho.com, which is actually an alias for mahimahi.kapoho.com. In the DNS reply, there are two answer RRs. The first is the CNAME RR for ns1.kapoho.com, which contains the canonical name. The second answer RR is the A record for mahimahi.kapoho.com, which contains the IP address of this computer (10.10.1.200).

Dynamically Updating DNS

DNS dynamic updates, described in RFC 2136, are a mechanism that enables DNS clients to add or delete a specific RR or sets of RRs, known as RRSets, to any zone. Dynamic updates can simplify the process of managing the contents of a DNS zone.

Dynamic update requests can also state prerequisites specified separately from update operations. These can be tested before an update can occur. When prerequisites are used with dynamic updates, the updates are said to be atomic; that is, all prerequisites must be satisfied for the update operation to be carried out.

Windows Server 2003 fully supports DNS dynamic updates. From the client side, the Windows Server 2003 TCP/IP client and the DHCP server both issue DNS dynamic update requests to register A and PTR records. On the server side, the DNS Server service for Windows Server 2003 accepts DNS dynamic updates. DNS dynamic updates for AAAA records are also supported by Windows XP and Windows Server 2003 for both DNS clients and servers.

The following Network Monitor trace (Capture 17-04, included in the \Captures folder on the companion CD-ROM) shows the process of dynamically registering an A RR.

1  15.472248  KAPOHO11        MAHIMAHI        DNS  0x62:Dyn Upd PRE/UPD
records to kapoho11.kapoho.n KAPOHO11         MAHIMAHI          IP

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0xB1BD; Proto = UDP; Len: 115

+ UDP: Src Port: Unknown, (1026); Dst Port: DNS (53); Length = 95 (0x5F)

  DNS: 0x62:Dyn Upd PRE/UPD records to kapoho11.kapoho.net. of type

       Canonical name

     DNS: Query Identifier = 98 (0x62)

   + DNS: DNS Flags = Query, OpCode - Dyn Upd, RCode - No error

     DNS: Zone Count = 1 (1)

     DNS: Prerequisite Section Entry Count = 1 (1)

     DNS: Update Section Entry Count = 2 (0x2)

     DNS: Additional Records Count = 0 (0)

     DNS: Update Zone: kapoho.net. of type SOA on class INET addr.

        DNS: Update Zone Name: kapoho.net.

        DNS: Update Zone Type = Start of zone of authority

        DNS: Update Zone Class = Internet address class

     DNS: Prerequisite: kapoho11.kapoho.net. of type Canonical name on

          class Unknown Class

        DNS: Resource Name: kapoho11.kapoho.net.

        DNS: Resource Type = Canonical name for alias

        DNS: Resource Class = 0x00FE

        DNS: Time To Live = 0 (0)

        DNS: Resource Data Length = 0 (0)

     DNS: Update: kapoho11.kapoho.net. of type Host Addr on class Req. for
any(2 records present)

      + DNS: Resource Record: kapoho11.kapoho.net. of type Host Addr on class
Req. for any

      + DNS: Resource Record: kapoho11.kapoho.net. of type Host Addr on class
INET addr.

2  15.482263  MAHIMAHI        KAPOHO11        DNS  0x62:Dyn Upd Resp. PRE/UPD
records to kapoho11.ka MAHIMAHI          KAPOHO11         IP

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x942B; Proto = UDP; Len: 115

+ UDP: Src Port: DNS, (53); Dst Port: Unknown (1026); Length = 95 (0x5F)

  DNS: 0x62:Dyn Upd Resp. PRE/UPD records to kapoho11.kapoho.net. of type
Canonical name

     DNS: Query Identifier = 98 (0x62)

   + DNS: DNS Flags = Response, OpCode - Dyn Upd, RCode - No error

     DNS: Zone Count = 1 (1)

     DNS: Prerequisite Section Entry Count = 1 (1)

     DNS: Update Section Entry Count = 2 (0x2)

     DNS: Additional Records Count = 0 (0)

     DNS: Update Zone: kapoho.net. of type SOA on class INET addr.

        DNS: Update Zone Name: kapoho.net.

        DNS: Update Zone Type = Start of zone of authority

        DNS: Update Zone Class = Internet address class

     DNS: Prerequisite: kapoho11.kapoho.net. of type Canonical name on class
Unknown Class

        DNS: Resource Name: kapoho11.kapoho.net.

        DNS: Resource Type = Canonical name for alias

        DNS: Resource Class = 0x00FE

        DNS: Time To Live = 0 (0)

        DNS: Resource Data Length = 0 (0)

     DNS: Update: kapoho11.kapoho.net. of type Host Addr on class Req. for
any(2 records present)

      + DNS: Resource Record: kapoho11.kapoho.net. of type Host Addr on class
Req. for any

      + DNS: Resource Record: kapoho11.kapoho.net. of type Host Addr on class
INET addr.

In this trace, the DNS dynamic update message is sent from the DNS client to the DNS server to update the A RR for the host kapoholt.kapoho.com, which is now at IP address 10.10.1.52.

Transferring Zone Information

There are three methods of performing zone transfer:

  • Traditional zone transfer This approach, described in RFC 1034, involves the secondary server requesting a full copy of the zone from the primary server.
  • Incremental zone transfer This approach, defined in RFC 1995, requires the DNS server hosting the primary zone to keep a record of the changes that are made between each increment of the zone's sequence number. The secondary zone can thus request only the changes that occurred since the last time the secondary zone was updated.
  • Active Directory zone transfer Active Directory zones are replicated to all domain controllers in the Windows Server 2003 domain using Active Directory replication.

The traditional zone transfer mechanism can be wasteful of network resources if the change in the transferred RRs is small in relation to the overall zone. In such cases, incremental zone transfer is more efficient. The following Network Monitor trace (Capture 17-05, included in the \Captures folder on the companion CD-ROM) shows a traditional zone transfer:

1   78.603025  Secondary   Primary    TCP  ....S., len:    0, seq: 105565995-105565995, ack

2   78.603025  Primary     Secondary  TCP  .A..S., len:    0, seq:3198736198-3198736198, ack

3   78.603025  Secondary   Primary    TCP  .A...., len:    0, seq: 105565996-105565996, ack

4   78.613040  Secondary   Primary    DNS  0x0:Std Qry for kapoho.com. of type Req for zn Xfer on class INET addr.

5   78.613040  Primary     Secondary  DNS  0x0:Std Qry Resp. for kapoho.com. of type SOA on class INET addr.

6   78.613040  Primary     Secondary  DNS  0x6574:Std Qry for ÌÍ_ of type Unknown Type on class Unknown Class

7   78.613040  Secondary   Primary    TCP  .A...., len:    0, seq: 105566028-105566028, ack:

8   78.613040  Primary     Secondary  DNS  0x7200:Std Qry for X of type Unknown Type on class Unknown Class

9   78.643083  Secondary   Primary    TCP  .A...F, len:    0, seq: 105566028-105566028, ack

10  78.643083  Primary     Secondary  TCP  .A...., len:    0, seq:3198739143-3198739143, ack

11  78.643083  Primary     Secondary  TCP  .A...F, len:    0, seq:3198739143-3198739143, ack

12  78.643083  Secondary   Primary    TCP  .A...., len:    0, seq: 105566029-105566029, ack

This trace shows a zone transfer of the zone kapoho.com from the primary to a secondary server. In this trace, the secondary DNS server first initiates a TCP connection with the primary server and issues a zone transfer message. The primary zone's DNS server then transfers the zone RRs. In a standard zone transfer, the first and last record transferred is always the zone's SOA record. After all the records are transferred, the TCP connection is terminated.

Incremental zone transfers, described in RFC 1995, can be more efficient than traditional zone transfers for both large and dynamic zones. However, they place additional processing requirements on the DNS server, which needs to keep track of the zone differences and sends only the changed records. By default, the DNS Server service for Windows Server 2003 uses incremental transfers when possible.

The following Network Monitor trace (Capture 17-06, included in the \Captures folder on the companion CD-ROM) shows an incremental zone transfer:

1   21.108471  Secondary  Primary    DNS  0x6000:Std Qry for kapoho.com. of type SOA on class INET addr.

2   21.108471  Primary    Secondary  DNS  0x6000:Std Qry Resp. for kapoho.com. of type SOA on class INET addr.

3   21.108471  Secondary  Primary    DNS  0x4000:Std Qry for kapoho.com. of type Req for incrmntl zn Xfer on class INET addr.

4   21.108471  Primary    Secondary  DNS  0x4000:Std Qry Resp. for kapoho.com. of type SOA on class INET addr.

In this trace, the DNS server initiating the zone transfer first queries for the SOA record, then requests an incremental zone transfer. In this example, the reply, contained in the fourth packet, fully fits inside a single UDP datagram. Had this not been the case, the reply message would have indicated that the reply was truncated, and the requesting server would have created a TCP session to the other DNS server and requested the zone transfer using TCP.

Active Directory replication is a proprietary solution that can be used only with Microsoft Windows 2000 or Windows Server 2003 domain controllers. Normal DNS zone transfers are pull in nature—the secondary DNS servers pull the zone or zone changes from the primary server. Active Directory replication, on the other hand, is push in nature—the directory changes are pushed from the domain controller on which the change occurred to the other domain controllers. For zones that change little, Active Directory replication ensures that all DNS servers storing the zone are updated quickly. For more dynamic zones this tends to smooth the replication traffic. Active Directory replication is beyond the scope of this book.


DNS Resource Records

This section describes the contents of the DNS RRs.

What Are Resource Records?

An RR is information related to a DNS domain; for example, the host record defining a host IP address. Each RR contains a common set of information, as follows:

  • Owner Indicates the DNS domain in which the RR is found.
  • TTL The length of time used by other DNS servers to determine how long to cache information for a record before discarding it. For most RRs, this field is optional. The TTL value is measured in seconds, with a TTL value of 0 indicating that the RR contains volatile data that is not to be cached. As an example, SOA records have a default TTL of 3600 seconds (1 hour). This prevents these records from being cached by other DNS servers for a longer period, which would delay the propagation of changes.
  • Class For most RRs, this field is optional. Where it is used, it contains standard mnemonic text indicating the class of an RR. For example, a class setting of IN indicates the record belongs to the Internet (IN) class. At one time there were multiple classes (such as CH for Chaos Net), but today, only the IN class is used.
  • Type This required field holds a standard mnemonic text indicating the type for an RR. For example, a mnemonic of A indicates that the RR stores host address information.
  • Record-Specific Data This is a variable-length field containing information describing the resource. This information's format varies according to the type and class of the RR.
With Windows Server 2003, most DNS information is either automatically added to the server or can be left to a default value. For most organizations running Windows 2000, Windows XP, and Windows Server 2003, DNS is self-maintaining once the DNS servers are installed and the relevant zones are created. However, the details on RR types can be useful for those integrating Windows Server 2003 with a non-Windows DNS server, or for troubleshooting.

Standard DNS zone files contain the set of RRs for that zone as a text file. In this text file, each RR is on a separate line and contains all the just-mentioned data items, as a set of text fields separated by white space. In the zone file, each RR consists of these data items, although different records contain slightly differently formatted record-specific data.

Sample Zone Data

The zone data for the kapoho.com zone noted earlier in this chapter is as follows:

;

;  Database file kapoho.com.dns for kapoho.com zone.

;      Zone version:  93

@                       IN  SOA mahimahi.kapoho.com. hostmaster. (

                            93           ; serial number

                            15           ; refresh

                            600          ; retry

                            86400        ; expire

                            3600       ) ; default TTL

;  Zone NS records

;  There are 2 DNS servers for this zone

@                       NS	kapoho10.kapoho.com.

@                       NS	mahimahi.kapoho.com.

;  Zone records

@                       600	A	10.10.1.74

@                       600	A	10.10.1.200

kapoho10                35	A	10.10.1.74

kona                    1200	A	10.10.2.200

mahimahi                        A	10.10.1.200

maui                    1200	A	10.10.1.62

tallguy                 1200	A	10.10.2.100

                        1200	A	10.10.1.100

waimea                  1200	A	10.10.1.67

; Aliases

news                    CNAME	kona2.kapoho.com.

ns1                     CNAME	mahimahi.kapoho.com.

Zone data for Active Directory-integrated zones are held as a series of Active Directory objects representing this data. For more detail on how Active Directory holds DNS-integrated zones, see Windows Server 2003 Help And Support.

Where Are RRs Located?

RRs for standard zones are stored in the folder %Systemroot%\System32\Dns. The RRs for each zone are held in a separate text file, which is named after the zone with an extension of .dns; for example, kapoho.com.dns.

Active Directory-Integrated Zone RRs

RRs for Active Directory-integrated DNS zones are stored within Active Directory itself. Active Directory uses the following two main object classes to hold this DNS information:

  • dnsZone Represents an Active Directory-integrated zone that contains dnsNode objects. This object class is the Active Directory equivalent of a standard zone held as a text file. The dnsZone objects have a dnsProperty attribute that defines key details about the zone, such as whether it can be dynamically updated.
  • dnsNode Corresponds to the individual RRs in the zone. Each dnsNode object has a dnsRecord attribute containing the resource information.

RRs Supported by Windows Server 2003

The DNS Server service for Windows Server 2003 supports all RFC-compliant RRs. Many of these are not commonly, or ever, used. The following sections list the most commonly used RRs. For the RR syntax and an example, see the topic entitled "Resource Records Reference" in Windows Server 2003 Help And Support.

  • Host Address (A) This RR contains a host address RR that maps a DNS domain name to an IPv4 32-bit address.
  • IPv6 Host Record (AAAA) This RR contains a host address RR that maps a DNS domain name to an IPv6 128-bit address.
  • Canonical Name (CNAME) This RR maps an alias or alternate DNS domain name in the Owner field to a canonical or actual DNS domain name. There must also be an A RR for the canonical DNS domain name, which must resolve to a valid DNS domain name in the namespace. The fully qualified canonical name should end with a full stop (".").
  • KEY (KEY) The KEY record holds a public key for a DNSSEC-aware zone. KEY RRs are signed by the key from their parent zone.
  • Mail Exchanger (MX) The MX record provides message routing to a mail-exchanger host for any mail that is to be sent to the target domain. This RR also contains a two-digit preference value to indicate the preferred ordering of hosts, if multiple exchanger hosts are specified. Each exchanger host specified in an MX record must have a corresponding host A address RR in the current zone.
  • Next (NXT) This record is used as part of DNSSEC. The NXT record is used to indicate the next RR in the zone. In conjunction with a SIG record, this can provide cryptographic assurance of the nonexistence of a name in a zone. For a given domain name, such as puna.kapoho.com, the NXT record points to the next record in the zone, (for example, waimea.kapoho.com) and states which RRs exist at the domain name (for example, NS, SOA, and so on). If the DNS server receives a request for, say, sunshine.kapoho.com, the negative reply would contain the reply code NXDOMAIN. The authority section of the reply would include the NXT and SIG records for the domain name after and before the name that did not exist.
  • Option (OPT) This is a pseudo-RR, used to provide the extended DNS functionality provided by EDNS0. An OPT RR can be in any DNS query response. The OPT record relates to the underlying transport-level message (that is, the UDP datagram's payload) and not to the DNS data.

    In an OPT pseudo-RR, the Name field is always empty (that is, the root domain), and the Class value holds the sender's maximum UDP payload size. This value signifies the largest UDP payload that can be delivered and reassembled in the sender's network stack. RFC 2671 suggests for Ethernet that a value of 1280 is considered reasonable; this is the default value used by Windows Server 2003.

  • Pointer (PTR) The PTR record is used to store the FQDN for an IP address for reverse name queries. The PTR record is used only within the in-addr.arpa domain.
  • Signature (SIG) The SIG record is used by DNSSEC to hold the digital signature for an RR or set of RRs.
  • Service Locator (SRV) The SRV RR enables a computer to locate a host providing a specific service, such as a Windows Server 2003 Active Directory domain controller. This enables the administrator to have multiple servers, each providing a similar TCP/IP-based service to be located using a single DNS query operation. This record is mainly used to support the Windows Server 2003 Active Directory, where all relevant SRV RRs are automatically populated into the DNS.


DNS Messages

DNS messages are sent between a DNS client and a DNS server or between two DNS servers. These messages are usually transmitted using UDP with the DNS server binding to UDP port 53. In some cases, the message length, particularly for responses, might exceed the maximum size of a UDP datagram. In such cases, an initial response is sent with as much data as fits into the UDP datagram. The DNS server sets a flag to indicate a truncated response. The client can then contact the server using TCP (port 53) and reissue the request—taking advantage of TCP's capability to reliably handle longer streams of data. This approach uses UDP's performance for most queries while providing a simple mechanism to handle longer queries. If the client and server support EDNS0, they can exchange larger UDP datagrams.

DNS Message Types

DNS originally provided dynamic name resolution for essentially static, manually updated data, such as host records manually added to a zone. The original DNS messages involved sending a query to a DNS server and getting a response. RFC 2136 defines the DNS dynamic update facility, which makes use of update messages, whose format is similar to and derived from query messages. Both message types are described next.

DNS Query Message Format

All DNS query messages share a common basic format, as Figure 17-4 illustrates.

Figure 17-4. Generic DNS query message format.

As can be seen from Figure 17-4, the DNS query message consists of a fixed-length 12-byte header, plus a variable portion holding question, answer, authority, and additional DNS RRs.

DNS Query Message Header

The DNS message header consists of the following fields:

  • Transaction ID A 16-bit field used to identify a specific DNS transaction. The originator creates the transaction ID and the responder copies it into a reply message. This enables the client to match responses received from a DNS server to the requests that were sent to the server.
  • Flags A 16-bit field containing various service flags, described in more detail later in this chapter.
  • Question RR Count A 16-bit field indicating the number of entries in the question section in the DNS message.
  • Answer RR Count A 16-bit field indicating the number of entries in the answer RRs section of the DNS message.
  • Authority RR Count A 16-bit field indicating the number of authority RRs in the DNS message.
  • Additional RR Count A 16-bit field indicating the number of additional RRs in the DNS message.

The DNS header is shown in Figure 17-5.

Figure 17-5. DNS message header.

The Flags field contains a number of status fields that are communicated between client and server. Figure 17-6 shows the format of the Flags field.

Figure 17-6. DNS message Flags field.

The individual fields in the Flags field are as follows:

  • Request/Response This 1-bit field is set to 0 indicate a name service request and 1 to indicate a name service response.
  • Operation Code This 4-bit field indicates the specific name service operation of the name service packet, as listed in Table 17-3.
    Table 17-3. Operation Codes
    Operation Code Operation

    0x0

    Query

    1

    Inverse Query

    0x2

    Server Status Request

  • Authoritative Answer This flag is set in a reply when the responder is authoritative for the domain name in the question section.
  • Truncation This flag is set to 1 if the total number of responses could not fit into the UDP datagram (for instance, if the total number exceeds 512 bytes). In this case, only the first 512 bytes of the reply are returned unless EDNS0 and longer UDP datagrams are being used.
  • Recursion Desired This flag is set to 1 to indicate a recursive query. For queries, if this bit is set to 0 and the name server contacted is not authoritative for the query, the DNS server returns a list of other name servers that can be contacted for the answer. This is how iterative queries are handled during name resolution.
  • Recursion Available DNS servers set this flag to 1 to indicate that they can handle recursive queries.
  • Reserved These 3 bits are reserved, and set to 0.
  • Return Code A 4-bit field holding the return code. A value of 0 indicates a successful response (for instance, for name queries, this means the answer is in the reply message). A value of 0x3 indicates a name error, which is returned from an authoritative DNS server to indicate that the domain name being queried for does not exist.

DNS Query Question Entries

In a DNS query, the question entry contains the domain name being queried. Figure 17-7 displays the format of a Question entry.

Figure 17-7. Question entry format.

The question entry is made up of the following three fields:

  • Question Name The domain name being queried. The format of this field is discussed below.
  • Question Type This field indicates the records that should be returned, expressed as a 16-bit integer, as shown in Table 17-4.
    Table 17-4. Records Returned for Each Type Value
    Type Value Record(s) Returned

    0x01

    Host record

    0x02

    Name server (A) record

    0x05

    Alias (CNAME) record

    0x0C (12)

    Reverse-lookup (PTR) record

    0x0F (15)

    Mail exchanger (MX) record

    0x21 (33)

    Service (SRV) record

    0xFB (251)

    Incremental zone transfer (IXFR) record

    0xFC (252)

    Standard zone transfer (AXFR) record

    0xFF (255)

    All records

  • Question Class Normally set to 0x00-01. This represents the IN (Internet) question class.

The Question Name field holds the name of the domain being queried. In DNS, these domain names are expressed as a sequence of labels using a length-value format. The domain kapoho.com, for example, consists of two labels (kapoho and com). In the Question Name field, the domain name is encoded as a series of length-value pairs consisting of a 1-byte field that indicates the length of the value, followed by the value (the label). The domain kapoho.com, therefore, would be expressed as 0x06kapoho0x03com0x00, where the hexadecimal digits represent the length of each label, the ASCII characters represent the individual labels, and the final 0 indicates the end of the name.

RRs

When a DNS server sends a query response back to a DNS client, the answer, authority, and additional information sections of the DNS message can contain RRs, which answer the question in the question section. Figure 17-8 illustrates the format of these RRs.

The fields in an RR are as follows:

  • RR Name The DNS domain name held as a variable-length field. The format of this field is the same as the format of the Question Name field, described in the previous section.
  • Record Type The RR type value, as previously noted.
  • Record Class The RR class code; there is only one record class used currently: 0x00-01, Internet Class.
  • Time-To-Live TTL, expressed in seconds held in a 32-bit unsigned field.
  • Resource Data Length A 2-byte field that indicates the length of the resource data.
  • Resource Data Variable-length data corresponding to the RR type.
Figure 17-8. DNS RR format.

The RR Name field is encoded in the same way as the Question Name field described earlier. However, if the name is already present elsewhere in the DNS message, then a 2-byte field that acts as a pointer to the name already present is used in place of a length-value encoded name. A pointer, instead of an encoded name, is indicated by setting the two high-order bits in the first byte of the RR Name field to 11. The RR Name field is then interpreted as a 16-bit field: the first 2 bits are fixed at 11, and the last 14 bits are used as a byte offset pointer (starting at 0) indicating where the previously stored name is located in the DNS message.

For a simple DNS Query Response message, the RR Name for an Answer RR is the same as the Resource Name for the Question entry, which begins in the 12th byte position (starting at 0) from the beginning of the DNS message. Therefore, the RR Name field is a 2-byte field containing 0xC0-0C. Figure 17-9 shows this relationship.

Figure 17-9. The RR Name as a pointer to a name stored elsewhere in the DNS message.

DNS Update Message Format

The format of a DNS Update message is very similar to DNS Query messages, and many of the fields are the same. The DNS Update message contains a header defining the update operation to be performed and a set of RRs that contain the update. Figure 17-10 displays the general format of the DNS Update message.

Figure 17-10. General Update message format.

DNS Update Message Flags

The DNS Update message has a Flags field, similar to DNS Query messages but with a slightly different format. Figure 17-11 shows the format of the Flags field for DNS Update messages.

Figure 17-11. The Flags field of a DNS Update message.

The DNS Update message flags are used as follows:

  • Request/Response A 1-bit field, set to 0 to indicate an update request and 1 to indicate an update response.
  • Operation Code Set to 0x5 for DNS updates.
  • Reserved These 7 bits are reserved and set to 0.
  • Return Code For update responses, indicates the result of the query. The defined result codes are shown in Table 17-5.
Table 17-5. Defined Result Return Code Flags for Update Responses
Result Code Value | Meaning
0 | No error; the update was successful.
1 | Format error; the DNS server was unable to understand the update request.
0x2 | The name server encountered an internal failure while processing this request.
0x3 | Some name that should exist does not exist.
0x4 | The operation code is not supported.
0x5 | The name server refuses to perform the operation for policy or security reasons.
0x6 | Some name that should not exist does exist.
0x7 | Some RR set that should not exist does exist.
0x8 | Some RR set that should exist does not exist.
0x9 | The server is not authoritative for the zone named in the Zone section.
0xA | A name used in the Prerequisite or Update section is not within the zone denoted by the Zone section.

Name Query Message

A Name Query message uses the DNS message format defined in RFC 1034 and described in the section entitled "DNS Query Message Format," earlier in this chapter. Network Monitor trace 17-1 (Capture 17-01, included in the \Captures folder on the companion CD-ROM) shows an example name query. In this trace, the following fields are set:

  • Query Identifier Set to a unique number so that the resolver can match the response to the query
  • Flags Set to indicate a standard query, with recursion if necessary
  • Question Count Set to 1
  • Question Entry Set to the domain name to resolve (kona.kapoho.com) and the RR to return (the host A record)

Name Query Response Message

A Name Query Response message is sent in response to a Name Query and is sent using the same query message format as the query response. Network Monitor trace 17-1 (Capture 17-01, included in the \Captures folder on the companion CD-ROM) displays an example of a query response in which the following fields are set:

  • Query Identifier Set to the unique number set in the query, to allow the resolver to match the response to the original query
  • Flags Set to indicate a response and a successful lookup
  • Question Count Set to 1
  • Answer Count Set to 1
  • Question Entry Set to the question contained in the query message
  • Answer Entry The RR requested in the query (the host record, containing the IP address of the queried domain)

Network Monitor trace 17-3 (Capture 17-03, included in the \Captures folder on the companion CD-ROM) shows a slightly different response message. In this trace, a resolver is attempting to resolve the A RR for ns1.kapoho.com. There is no host A RR for this name, but there is an alias (CNAME). In the response, the replying DNS server returns two RRs: the CNAME RR, as well as the A RR for the canonical name (kona.kapoho.com).

Reverse Name Query Message

Reverse Name Query messages use the same message format as normal queries. The only differences in the contents are as follows:

  • The domain name being queried is different. For a reverse lookup, the resolver constructs a domain name in the in-addr.arpa domain based on the IP address that is being queried.
  • The queried record is a PTR record, rather than an A record.

The Reverse Name Query Response message is also the same as a Query Response message, except that a PTR record, rather than a host record, is returned. A reverse lookup can be seen in Network Monitor trace 17-2, shown earlier in this chapter. In the trace, the resolver is looking for the host name of the host at 10.10.1.52, and thus queries for the domain 52.1.10.10.in-addr.arpa. The Reverse Name Query Response returns the requested PTR record, which shows the host name at this IP address to be kapoholt.kapoho.com.

Name Update Message

Name Update messages use the Name Update message format defined in RFC 2136 and described in the section entitled "DNS Update Message Format," earlier in this chapter. Network Monitor trace 17-4 shows an example of a Name Update message. In this update, the key update message fields are set as follows:

  • Query Identifier Like query messages, update messages contain an identifier to enable the sender to match the response to the original update.
  • Flags Set to indicate a request and a dynamic update.
  • Update Zone Set to 1, and the zone section contains the zone to be updated.
  • Prerequisites Zone Set to 2, with two prerequisite records specified.
  • Update Zone Contains the RR that is to be updated.

Name Update Response Message

A Name Update Response message is issued in response to a Name Update Request. Network Monitor trace 17-4 contains an example of this in which the response can be seen to be identical to the request, except that the DNS flags in the message header are set to indicate this is a successful response. If the response had been unsuccessful, the response message would have contained an error code.


Summary

DNS was once an option for most Microsoft Windows NT networks that used NetBIOS names and WINS for most domain operations, and as the basis of file and print sharing. DNS is now a key component in Windows Server 2003 networks and is required in those networks that deploy Windows Server 2003 Active Directory. In this chapter we have examined what DNS is and how it works, including DNS message formats and how the message appears on the wire. The chapter also has shown a number of Network Monitor captures, which are contained on the companion CD-ROM for further study.


Windows Internet Name Service (WINS)

Chapter 18
Windows Internet Name Service (WINS)

In the early days of personal computing, both IBM and Microsoft used NetBIOS to provide programmers and applications with access to networking functions and features. NetBIOS was originally developed for IBM by Sytek Corporation as an extension to the BIOS, which an application could access by making BIOS calls.

In Microsoft Windows Server 2003, as with earlier versions of Windows, NetBIOS is both a transport-independent network interface and a session management and data transport protocol. NetBIOS can work over any of the Windows network transport protocols, including NWLink (IPX) and TCP/IP. Applications using NetBIOS can run over any of the configured transport protocols. Windows networking clients traditionally have used NetBIOS for a variety of functions, including file and printer sharing and browsing.

RFCs 1001 and 1002 define the functions and features of a NetBIOS service on a TCP/UDP transport, also known as NetBIOS over TCP/IP (NetBT). These RFCs, which were published in 1987, document the following three principal services for NetBIOS applications running over TCP/IP:

  • Name service Provides computers with the ability to acquire and defend NetBIOS names and locate the holders of those names
  • Session service Provides reliable message exchange, conducted between a pair of NetBIOS applications typically running on separate computers
  • Datagram service Provides an unreliable, nonsequenced, connectionless message-passing service for NetBIOS applications

The NetBIOS session and datagram services enable NetBIOS applications to send messages to each other. These services are based on individual computers having NetBIOS names. The NetBIOS name service provides these applications with the ability to acquire and register a name, locate computers holding a specific name, and resolve a given NetBIOS name into an IP address. The datagram and session functions are outside the scope of this chapter.

WINS is a NetBIOS name server that NetBIOS clients can use to register, defend, and resolve NetBIOS names. WINS provides several benefits to an organization:

  • Name registration and name resolution facilities for down-level NetBIOS-based computers
  • Dynamic database maintenance to support computer name registration and resolution
  • Centralized management of a scalable NetBIOS name database

WINS implements the name service features of a NetBIOS name server, as defined in RFCs 1001 and 1002. However, to scale for larger networks, WINS also provides replication facilities, although these are not defined in RFCs 1001 and 1002.

In earlier versions of Microsoft Windows NT, WINS played a critical role in enabling clients to locate servers and services. This included the Windows NT directory services, where clients used NetBIOS to locate Windows NT 4.0 domain controllers. NetBIOS session and datagram services were used as the basis of NT Directory services (Directory operations in Windows Server 2003 do not use NetBIOS). File and print sharing also makes use of NetBIOS.

An organization that uses all Microsoft Windows XP, Windows 2000, and Windows Server 2003 computers or a mixture of these computers and third-party operating systems such as UNIX, and whose applications fully support the use of Domain Name System (DNS), can largely eliminate NetBIOS, having little or no need for WINS. However, doing so would mean any application reliant on NetBIOS, such as the computer browser service, would not function.

Most organizations, however, need to support older computers—down-level clients—as well as other services and applications that require NetBIOS network names. This includes computers that run Microsoft Windows 98, Windows Millennium Edition (Windows Me), and all versions of Windows NT. Organizations supporting computers running these operating systems can continue to find WINS an important service during the deployment of Windows Server 2003.


Overview of WINS in Windows Server 2003

The following sections describe the characteristics of WINS in the Windows Server 2003 family.

What Is WINS?

WINS is a NetBIOS name server that enables a client to register NetBIOS names and IP addresses in a central database and to resolve NetBIOS names into IP addresses. WINS consists of two components: Windows Internet Name Service (WINS), which runs on Windows Server 2003 (as well as earlier versions of Windows Server), and a WINS client service that runs on TCP/IP-based clients. The WINS server manages a database of NetBIOS names, and replicates this database to other WINS servers. The WINS client uses the WINS server to register names and to provide name resolution facilities (converting NetBIOS names into IP addresses). In functional terms, WINS is much like DNS, with clients registering names and performing name lookups, and servers handling the registration and resolution. The key difference is that WINS is based on NetBIOS names, rather than on DNS domain names.

RFCs 1001 and 1002 define the functions of a NetBIOS name server in some detail. In this respect, the WINS server is an RFC-compliant NetBIOS name server providing name registration and name resolution facilities. The WINS server is scalable, able to function well in networks of all sizes.

Read about the functions of a NetBIOS name server in RFCs 1001 and 1002, which can be found in the \Rfc folder on the companion CD-ROM.

All servers running members of the Windows Server 2003 family (including Standard Edition, Enterprise Edition, Web Edition, and Datacenter Edition) include a WINS service, although this service is not installed by default. All Windows clients include a WINS client, including Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0, Windows Me, and Windows 98. For Windows 2000, Windows XP, and Windows Server 2003 clients, the WINS client function is automatically installed.

Key WINS Terms

In Windows Server 2003, NetBIOS is a network interface, allowing applications and key system components to communicate across a network, and a protocol for allowing that communication. System processes that make use of NetBIOS include the Workstation, Server, and Computer Browser services. The following is an explanation of key terms relating to WINS and an overview of WINS operations.

Network Resources and End-Nodes

A network resource is a process running on a specific computer. This could be the Server service running on a file server, for example. The specific computer that runs the network resource process is referred to as an end-node. For applications to interoperate and for users to access key resources, every network resource needs a name.

NetBIOS Names

Each network resource in Windows is identified by a NetBIOS name. In Windows, each NetBIOS name can be up to 15 characters in length. The final, sixteenth character, which is allowed in RFCs 1001 and 1002, is reserved by Windows for the NetBIOS name suffix. The NetBIOS name cannot start with an *, and the NetBIOS name is not case-sensitive.

NetBIOS Name Types

A NetBIOS name can be either a unique name, owned by just one end-node, or part of an Internet group, which can include multiple end-nodes. Each computer running Windows Server 2003 has a Server service and a Workstation service for the purposes of sharing files. These services each have a unique NetBIOS name that allows clients to find and use these services. The set of domain controllers within a single domain would all share an Internet group NetBIOS name. When resolving a NetBIOS address to an IP address, unique names resolve to a single IP address, whereas Internet group addresses typically resolve to multiple addresses.

The NetBIOS namespace is flat, unlike DNS, which is hierarchical. This means that a unique NetBIOS name can be used only once within a network. Multiple computers can belong to a NetBIOS Internet group. Two computers with a Server service running, for example, cannot have the same NetBIOS computer name. This can pose problems for very large organizations, and the NetBIOS scope identifier (ID) provides one solution to this issue.

NetBIOS Name Suffix

Although RFCs 1001 and 1002 allow NetBIOS names to be 16 characters, as noted earlier, the sixteenth character in the Windows NetBIOS name is reserved for the NetBIOS name suffix. This suffix is used by Windows networking software to identify and locate specific network resources. Thus, an end-node can register multiple names, based on the computer, domain, or user name, and a suffix to indicate the services available on that machine. WINS clients can then construct a NetBIOS name based on computer, user, or domain name, and the appropriate suffix to locate those relevant network resources.

For example, the Messenger service has the suffix 0x03. To send a message to COMPUTER42, the client would send a message to the Workstation service on Computer42, or COMPUTER42[03]. Note that in the full 16-character NetBIOS name notation, the first 9 characters of the NetBIOS name would be COMPUTER42, the next 6 characters would be " " (blank), and the final character would be 0x03.

Table 18-1 lists common NetBIOS suffixes used with Windows Server 2003. The suffixes are listed in hexadecimal format because many of them are unprintable otherwise.

Table 18-1. Common NetBios Suffixes Used with Windows Networking
Name | NetBIOS Suffix (Hex) | Type | Usage
<computername> | 00 | U | Workstation service
<computername> | 03 | U | Messenger service
<computername> | 20 | U | Server service
<username> | 03 | U | Messenger service
<domain> | 00 | G | Domain name
<domain> | 1B | U | Domain master browser and primary domain controller emulator
<domain> | 1C | G | Domain controllers
<domain> | 1E | G | Browser service elections
<..—__MSBROWSE__> | 01 | G | Master browser

In addition to these common NetBIOS suffixes used by Windows Server 2003, other applications such as Microsoft Exchange, Lotus Notes, and others also register NetBIOS names. See knowledge base articles Q314104, Q163409, and Q194338 for more details on these names.

Microsoft produces a series of Knowledge Base articles describing features and functions of the various Windows operating systems. Some of these knowledge base articles can be found on Technet, and the full Microsoft Knowledge Base is available on the Web at http://support.microsoft.com/search. At the Web site, you can search for an article by its ID number, such as Q314104.

NetBIOS Name Service Operations

NetBIOS name service operations involve registering, defending, querying, and releasing NetBIOS names. Additionally, NetBIOS session and datagram services use these name service operations to locate resources. For example, if a Windows Server 2003 computer user wants to access a file share on a remote system, that user enters the remote computer name and share name using Microsoft Explorer. Explorer uses NetBIOS name services to determine the remote server's IP address, and can then issue NetBIOS session-level commands to access the shared resource.

NetBIOS name service operations are carried out on the wire, using either IP broadcasts or a NetBIOS name server. The use of broadcasts might be acceptable for small local area networks (LANs). However, in larger networks, the use of broadcasts, which could result in broadcast storms, is undesirable. Such networks should implement WINS.

NetBIOS Scope

The NetBIOS namespace is flat, meaning that all names must be unique on an internetwork. If you have a computer called KAPOHO and it is properly defending its computer name, no other network computer can call itself KAPOHO. This limitation can cause difficulties for larger organizations.

As RFC 1001 describes, an approach to resolving this flat namespace is the use of an additional qualifier for the NetBIOS name. RFC 1001 defines the NetBIOS scope as "the population of computers across which a registered NetBIOS name is known." To identify the NetBIOS scope, the NetBIOS scope identifier is used. The NetBIOS scope identifier is a character string, similar in format and function to the DNS domain name.

The use of the NetBIOS scope in the Windows Server 2003 family, however, is limited in that a user cannot specify the scope directly by using Control Panel or a command-line tool. The NetBIOS scope of a Windows 2000, Windows XP, or Windows Server 2003 computer can be provided as part of the computer's IP parameters received from a Dynamic Host Configuration Protocol (DHCP) server or using a change to the computer's registry. If configured in this way, the NetBIOS scope is automatically appended to all NetBIOS names when name commands are invoked. The effect is that an end-node with a given NetBIOS scope can communicate only with other end-nodes configured with the same NetBIOS scope.

You can set the NetBIOS scope either by specifying a scope as part of a DHCP scope or by editing the registry. The registry key used to change the NetBIOS scope manually is as follows:

Key:	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters or

Key:	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\

    Adapters\Interfaces\InterfaceGUID

Value name: ScopeId

Value type: REG_SZ - Character string

Valid range: Any valid DNS domain name consisting of two dot-separated parts, or an

asterisk (*)

Default: None

Present by default: No
Although the use of the NetBIOS scope identifier might offer some benefits, it also might complicate communication with other systems. In addition, the inadvertent use of a NetBIOS scope identifier can make troubleshooting problems that arise from such use more difficult to resolve. In general, you should avoid using this feature.

NetBIOS Node Types

To allow for the various sizes of NetBIOS networks, RFCs 1001 and 1002 use the concept of node type to determine how a particular computer should perform name service functions. The node type defines how name service operations are to be performed.

An end-node can be one of the following four node types:

  • B-Node (Broadcast Node) Name registration and name resolution operations are performed using broadcasts only. This is usually the best option for a very small, single subnet network.
  • P-Node (Point-to-Point Node) Name registration and name resolution operations are done using a NetBIOS name server (WINS) only. This node type can be used to eliminate local subnet broadcasts, but might cause network resources on the local subnet to not be resolved unless the computers have updated the WINS server.
  • M-Node (Mixed Node) A combination of B-Node and P-Node, where name registration and resolution are done initially using broadcasts. If name resolution is not successful using broadcasts, then a NetBIOS name server is used. This is useful in cases where the WINS server is on a remote network, as the client first attempts to resolve the name locally before using wide area network (WAN) resources for the resolution.
  • H-Node (Hybrid Node) A combination of P-Node and B-Node, where name registration and resolution are done initially using a WINS server. If the name resolution is not successful using the WINS server, broadcasts are used. This is the default node type for Windows-based WINS clients.

By default, computers running Windows Server 2003 are B-Node. If you configure your Windows Server 2003 computer to use a WINS server, it becomes H-Node. You can configure your computer to be P-Node or M-Node by manually editing the registry. In addition, the administrator can set DHCP parameters to set the node type for a DHCP client.

The registry key used to manually change node type is as follows:

Key:	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters or

Key:	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\
    Adapters\Interfaces\InterfaceGUID

Value name: NodeType

Value type: REG_DWORD - Number

Valid range: 1,2,4,8 (B-Node, P-Node, M-Node, H-Node)

Default: 1 or 8 based on the WINS server configuration

Present by default: No

Microsoft Modified B-Node

Because it is based on broadcasting, NetBIOS B-Node behavior does not generally scale beyond a single subnet. This can be partially overcome by configuring routers to forward NetBIOS broadcasts, but this also does not scale, and is rarely done. To overcome these inherent limitations of RFC-compliant B-Node, Microsoft has extended the B-Node for name service operations. Known as modified B-Node, these extensions add two name-lookup facilities to B-Node:

  • The NetBIOS name cache An in-memory cache of recently resolved names that can be searched before other name resolution methods are attempted
  • The LMHOSTS file A flat file, contained in %systemroot%\System32\Drivers\Etc, that contains a static list of NetBIOS names and their IP addresses

If using LMHOSTS is, for some reason, undesirable, you can disable this from the advanced properties of the TCP/IP protocol.

Name Registration

Whenever a network resource becomes available for use—for example, when a file server starts up—the network resource registers its relevant NetBIOS name to enable clients (for example, file server clients) to locate that network resource. The registration procedure also ensures that the name being registered is not already in use by another computer. For WINS clients configured to use P-Node, M-Node, and H-Node, the client also informs the WINS server of the name and IP address.

Time To Live (TTL)

In general, NetBIOS names are not held or owned permanently. Each name registered successfully in WINS has a limited time to live (TTL). When the TTL for a NetBIOS name expires, it is up to the network resource to reregister that name. If a network resource registers a name with a WINS server and the TTL expires, the name can be removed from the WINS server. Windows client computers attempt to reregister their NetBIOS names at one-half of the TTL, or when the computer is rebooted.

Name Defense

Once registered, all unique NetBIOS names need to be defended to ensure that two different network resources do not claim the same NetBIOS name. If a computer attempts to register a NetBIOS name that is already being used by another computer, the name's owner needs to defend the name. If a network resource finds that the name it is attempting to resister is already in use—for example, a computer booting up is configured with a computer name of one that is already running—the network resource should fail gracefully. Windows Server 2003 processes, such as the Server service, also write an error event to the event log for later analysis and troubleshooting.

If the name's owner is a B-Node client, the owner must accept responsibility for defending the name by listening for a Name Registration Request and broadcasting a negative Name Registration Response.

For P-Node clients, name defense is more complicated. If a P-Node client attempts to register a name with a WINS server that the WINS server believes to be in use, the WINS server first attempts to contact the computer that has previously registered the NetBIOS name. If the WINS server successfully contacts the registered owner, the WINS server sends a negative Name Registration message to the client attempting to register the name. If, on the other hand, the WINS server cannot reach the previously registered owner of the name, it sends a positive Name Registration Response.

NetBIOS Name Resolution

When a computer wishes to communicate with another using NetBIOS, it must determine the remote computer's IP address before communications can be established. Name resolution is the process of determining a computer's IP address based on a NetBIOS name. The general approach a WINS client takes to resolving names using NetBIOS is as follows:

  • The client checks to see if the name is in the local NetBIOS name cache. For more information on the NetBIOS name cache, see the section entitiled "NetBIOS Name Cache," later in this chapter.
  • The client attemps to resolve the name using a WINS server, a broadcast, or both, depending on the node type.
  • If the computer is configured to use LMHOSTS, this file is consulted for the name's IP address.
  • If all attempts to resolve the NetBIOS name fail, the NetBIOS name is converted into a host name and all the host name resolution methods are attempted.

Windows WINS clients attempt the following name resolution steps that vary depending on the NetBIOS node type and whether a WINS proxy has been configured, as follows:

  • B-Node clients broadcast NetBIOS Name Request messages to the local subnet. If a computer holding the name is on that local subnet, the computer issues a positive Name Query response, containing the required IP address. If there is a WINS proxy agent on the subnet when a NetBIOS Name Request message is broadcast, and there is no reply from other computers on the subnet, the WINS proxy agent attempts to resolve the name on behalf of the client. This is a good approach for very small networks (possibly with no WINS servers) and is the default for a computer with no WINS server configured.
  • P-Node clients unicast NetBIOS Name Request messages to the configured WINS server. If the WINS server has the required name, it sends a positive Name Query Response, containing the required IP address; otherwise, the WINS server sends a negative Name Query Response. If the WINS client gets no response from its WINS server, and is configured with the IP addresses of additional WINS servers, the client tries these additional WINS servers. This approach minimizes broadcasts on the local network but can cause WAN resolution traffic, even if the network resource is local to the WINS client.
  • M-Node clients first attempt to use B-Node behavior to resolve the name, and if this is not successful, M-Node clients attempt P-Node behavior. This is particularly useful when the client is on the other side of a WAN link to the network resource, but can cause additional broadcast traffic on the local subnet.
  • H-Node clients first attempt to use P-Node behavior to resolve the name, and if this is not successful, H-Node clients then attempt to use B-Node behavior. As with P-Node, this approach reduces local broadcast traffic for names held by the WINS server, but uses the local broadcast to attempt to resolve the name.
Early WINS clients supported a maximum of only two WINS servers (a primary and a secondary). To provide additional fault tolerance for clients' computers, Windows Server 2003, Windows XP, Windows 2000, Windows Me, and Windows 98 allow you to specify up to 12 WINS servers per interface. These extra WINS server addresses are used only if the primary and secondary WINS servers fail to respond.

If none of these steps is successful in resolving the NetBIOS name, the WINS client computer continues attempting to use host name resolution, first checking the local HOSTS file, and then contacting configured DNS servers. If, after all these steps, the name still cannot be resolved, Windows indicates an error to the application.

This series of steps is intended both to provide the maximum amount of fault tolerance to the client and to accommodate incorrectly configured systems. It is all too easy, for example, for a new administrator to add NetBIOS names to the HOSTS file instead of the LMHOSTS file.

If a computer uses broadcasting to resolve a NetBIOS name, it cannot be sure that a lack of response is significant. Because User Datagram Protocol (UDP) is used as the transport for NetBIOS name operations, the packet could have been dropped. To compensate for the potential unreliability, the client resolving a name, by default, broadcasts the name resolution request three times, with a 750-millisecond interval between each attempt. Use the following registry entry to change the number of broadcasts attempted:

Key:	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters

Or

Key:	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters\

    Adapters\Interfaces\InterfaceGUID

Value name: BcastNameQueryCount

Value type: REG_DWORD-Number

Valid range: 1-0xFFFF

Default: 3

Present by default: Yes

Use the following registry entry to change the interval between broadcasts:

Key:	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters\

    Adapters\Interfaces\InterfaceGUID

Value name: BcastQueryTimeout

Value type: REG_DWORD-Time in milliseconds

Valid range: 100-0xFFFFFFFF

Default: 0x2ee (750 decimal)

Present by default: Yes
Although it might seem like a good idea to reduce the number of broadcasts, if you reduce the number to one, or make the time interval between broadcasts too small, you might increase the possibility that a busy WINS server would not be able to respond quickly enough. In that case, the client would fail to resolve a name for a system that otherwise might have been able to respond (using the default values). Test any changes to these parameters carefully.

NetBIOS Name Cache

To minimize the use of NetBIOS Name Resolution Queries, WINS clients use a NetBIOS name cache that holds recently resolved NetBIOS names. If a WINS client needs to resolve a NetBIOS name, it examines this cache before issuing a Name Query Request.

By default, the NetBIOS name cache holds 16 resolved names, each for 10 minutes. This is probably adequate for most client computers although you can modify both the size and time-out values. If a client resolves more NetBIOS names than the cache can hold, the oldest entries are discarded, and the new name (and IP address) is added to the name cache.

By making a registry change, you can configure the name cache to be one of the following three sizes:

  • Small Holds 16 entries (this is the default)
  • Medium Holds 128 entries
  • Large Holds 256 entries

Use the following registry entry to modify the NetBIOS name cache size:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters

Value name: Size/Small/Medium/Large

Value type: REG_DWORD

Valid range: 1, 2, 3 (Small, Medium, Large)

Default: 1 (Small)

Present by default: Yes

By default, entries in the NetBIOS name cache time out and are deleted after 10 minutes. To adjust this time-out period, use the following registry entry:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters

Value name: CacheTimeout

Value type: REG_DWORD

Valid range: 60000-0xFFFFFFFF

Default: 0x927c0 (600000 milliseconds = 10 minutes)

Present by default: Yes

The value holds the length of time, in milliseconds, for which a NetBIOS lookup is cached. You can use the NBTSTAT -c command from the Windows Server 2003 command prompt to view the entries in the local NetBIOS name cache.

By increasing the size of the NetBIOS name cache and increasing the cache time-out value, you can reduce the number of lookups performed against a busy server. For many environments with largely static IP addresses for all key servers, this change might be appropriate. However, by making this change, you also increase the probability that an entry in the cache is no longer accurate (which could occur in a highly dynamic TCP/IP network). This trade-off between accuracy and amount of lookup traffic should be considered carefully and tested thoroughly.

Name Release

If the network resource terminates gracefully, it can no longer defend the name, and the resource performs name release. For B-Node clients, this is done simply by stopping the name defense of the name being released. For P-Node clients, name release is accomplished by sending a Name Release message to the WINS server.

WINS Proxy

A WINS proxy is a WINS client that can perform NetBIOS name operations (register, release) on behalf of other non-WINS clients. Older, or third-party, NetBIOS clients might not be configured or might not be able to be configured to use WINS. Instead, they would rely on B-Node behavior. To provide these clients with use of a WINS server's resources, you can use a WINS proxy to act on behalf of other computers that are unable to use WINS. A WINS proxy can also be used during the migration from a broadcast environment to a WINS environment. You can set up a WINS server and a WINS proxy, then migrate systems over one by one without affecting name resolution for the systems that have not yet been converted.

The WINS proxy functions as follows:

  • When a B-Node WINS client issues a name registration broadcast for a NetBIOS name, the WINS proxy performs a name lookup, first using its local NetBIOS name cache and, if necessary, sending a Name Query Request to the WINS server. If the name is found, the proxy sends a negative Name Registration Response back to the B-Node client attempting to register the name.
  • When a B-Node client broadcasts a name resolution, the proxy attempts to resolve the name, first by using information locally contained in its cache of remote names and then by sending a Name Query Request to the WINS server. If the name lookup is successful, the proxy sends a Name Query Response. If it is not successful, the proxy sends a negative Name Query Response.

You can configure a system to act as a WINS proxy for B-Node clients on the local subnet by editing the following registry key:

Key:	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters Or

Key:	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters\

    Adapters\Interfaces\InterfaceGUID

Value name: EnableProxy

Value type: REG_DWORD - Boolean

Valid range: 0, 1 (False, True)

Default: 0 (False)

Present by default: No

Setting this value entry to 1 enables the system to act as a proxy NetBIOS name server for the networks to which NetBT is bound (or to the chosen interface). A WINS proxy listens for broadcast Name Query Requests, resolves them using WINS (or the proxy's NetBIOS name cache), and broadcasts the result back to the client. The WINS proxy provides B-Node WINS clients with the ability to interoperate with WINS servers.

WINS Database Entries

When a name is registered, or released, the WINS server updates its internal database. A WINS database entry holds the name of the network resource, its associated IP address, TTL, and version number. The version number is the basis for WINS server replication.

WINS Server Replication

In large enterprise networks, having a single WINS server is not generally advisable. A single server providing a service to a large number of clients would represent a single point of failure. Also, it could require clients to use WAN links to resolve names of network resources that might turn out to be local.

To provide redundancy, load balancing, and scalability, and to reduce the WAN traffic involved with Name Registration and Name Query options, WINS servers can be configured for replication, which replicates WINS database entries from one server to another. WINS server replication enables a WINS client computer to register NetBIOS names on one WINS server, and to have that WINS server replicate the name so that it is available to all WINS servers, and to all WINS clients, in an organization. This can expedite client name resolution because the use of WAN links for WINS queries is avoided.

For a WINS server to replicate its information, the server must be configured with at least one other WINS server as a replication partner. WINS replication partners replicate names known on one server to the other partner servers. There are two replication roles for a WINS server: pull partner and push partner. A pull partner is a WINS server that pulls WINS entries from its configured partner(s). A push partner is a WINS server that pushes updated WINS entries to its configured partner(s).

All replication traffic is pulled, with one partner requesting updates from a configured partner. The main difference between push and pull partners is who and what triggers the replication event. Pull partners pull name-to-IP-address mapping updates from their replication partners, either when the WINS service starts or at intervals configured by the administrator. On the other hand, push partners inform configured partners that updates exist, either when the WINS service starts or after a certain number of updates have accumulated. After the partner has received the notification that updates exist, the partner can pull these changes down to update its local WINS database.

The WINS replication topology for an organization is determined by an administrator based on the business needs for NetBIOS name resolution. Replication involves pairs of servers replicating from one to the other, which can involve WAN traffic. Microsoft recommends making all replication push/pull, which is a good default, especially for LAN-connected WINS servers. When replicating across WAN links, pull replication (where each partner pulls at a predefined interval) might be a better alternative.

Adapter Status

NetBIOS end-nodes can query the status of another system. This status is known as the adapter status. The NBTSTAT.EXE command, which is provided on Windows 2000, Windows XP, and Windows Server 2003, can be used to issue a node status query against another computer. In Windows Server 2003, this returns only the NetBIOS names owned by the remote computer. RFC 1002 defines a number of statistics that are returned in an Adapter Status message, but in Windows Server 2003 these are not returned or displayed by NBTSTAT.EXE.


How WINS Works

To understand how WINS itself works, you also must understand how WINS clients operate and how NetBT, in general, works. This section describes key functions and features of both NetBIOS name services and WINS clients and servers.

Registering NetBIOS Names

The process of registering and renewing NetBIOS names by an end-node varies depending on the NetBIOS node type configured for the end-node. In general, an end-node that wants to register the NetBIOS name issues a NetBIOS Name Registration Request to register the name. Once a NETBIOS name is registered, other computers can then resolve that name and use the resulting IP address to communicate with the end-node. When the network resource terminates, it releases the name, although in the case of a nongraceful termination, a name release might not be performed.

Name Registration Request

When a network resource starts up, it attempts to register the related NetBIOS names by issuing a NetBIOS Name Registration Request. This depends on the node type as follows:

  • B-Node When a B-Node client registers a name, it broadcasts a name registration packet to the local network. If the name is currently in use by another node, the name's owner sends a negative Name Registration Reply. A B-Node client that does not receive a negative Name Registration Reply then considers itself the owner of the name and carries out name defense of that name.
  • P-Node When a P-Node client registers a name, it sends the name to the configured WINS server as a unicast packet. If the name being registered has previously been registered, the WINS server attempts to contact the registered owner to check whether the name is actively being used. If the name is still in use, the WINS server sends a negative Name Registration Reply to the client. If the name is not in use, the WINS server sends a positive Name Registration Reply. The WINS server might also send a Wait Acknowledgment (WACK) message to the client attempting to register the name. This message indicates that the WINS server is still attempting to determine whether the name can, in fact, be registered.
  • M-Node An M-Node client attempts to register the name using broadcasts, as for a B-Node client. In the absence of an objection, the client attempts to register the name with the configured WINS server. Although the broadcast approach might yield an owner of the name, and therefore would terminate the name registration process, it is insufficient to confirm name ownership for an M-Node client.
  • H-Node A Windows .NET Server H-Node client registers the name using WINS. If this is successful, the registering client assumes ownership of the name.

The Network Monitor trace in Capture 18-01 (included in the \Captures folder on the companion CD-ROM) shows a name registration by an H-Node client for the name KAPOHO10[00]. The Network Monitor trace in Capture 18-02 (in the \Captures folder on the companion CD-ROM) shows a name registration by a B-Node client for the name KAPOHO10[00].

Positive Name Registration Reply

Positive Name Registration Replies are sent from a WINS server to a WINS client on successfully registering a NetBIOS name. If a WINS client sends a WINS server a request to register a unique NetBIOS name, and that name is not presently registered, the WINS server registers the name and sends a positive Name Registration message to the computer that registered the name. Computers that send NetBIOS Name Registration Requests using broadcasts, such as a B-Node client, do not receive a positive Name Registration Reply.

If a WINS client sends a WINS server a request to register an Internet group name, the WINS server always sends a positive Name Registration Reply. B-Node clients send NetBIOS Name Registration messages. A B-Node client broadcasts multiple Name Registration messages, and if no negative Name Registration Replies are received, it assumes ownership of the NetBIOS name. The Network Monitor trace in Capture 18-1 shows a successful name registration by an H-Node client, including a positive Name Registration message.

Negative Name Registration Reply

A WINS server that receives a request to register a unique NetBIOS name that is already registered should reject the request by issuing a negative Name Registration Reply message, provided that the end-node owning that name is able to defend the name. Before sending the negative Name Registration Response, the WINS server checks with the current owner of the NetBIOS name to determine whether that computer is still active. This situation could occur, for example, if a laptop is moved to a different subnet, or for some reason is reconfigured to have a new IP address.

A computer sending NetBIOS Name Registration Requests using broadcasts (for example, a B-Node client) also receives a negative Name Registration Reply if another computer active on that subnet currently owns the name. A computer registering NetBIOS names using WINS sends its Registration Request messages using unicast. The WINS server sends a negative Name Response message if the name being registered has previously been registered by some other end-node, and if that other end-node can defend the name.

The Network Monitor trace in Capture 18-03 (included in the \Captures folder on the companion CD-ROM) shows a computer attempting to register the NetBIOS name KAPOHO10 with a WINS server. This name is in use on another computer and the second packet in this trace shows the negative Name Response message.

Wait Acknowledgment

If a WINS server receives a request to register a unique NetBIOS name that is already registered, it checks with the registered owner of that name. In this case, it might issue a WACK message to the computer attempting to register the name. The purpose of this is to inform the client that the WINS server might not yet be able to provide a name reply. To enable the client to be aware that the server has not failed (and is not performing name service operations), a WINS server sends a WACK message if it cannot answer the query immediately.

The Network Monitor trace in Capture 18-04 (included in the \Captures folder on the companion CD-ROM) shows a WACK message. The WINS server has to contact another system, and issues the WACK while that contact is accomplished. This message is part of a name resolution failure, which is discussed in the section entitled "Resolving NetBIOS Name Registration Conflicts," later in this chapter.

Name Renewal Request

Like DHCP leases, NetBIOS names registered with a WINS server have a limited life, or TTL, and must be refreshed before that life expires. In Windows Server 2003, the default TTL for NetBIOS name entries held in WINS is 6 days. The WINS administrator can change this to any time between one minute and 365 days. When an end-node registers a NetBIOS name with a WINS server, the end-node receives a positive Name Query Response, which contains a TTL for the name.

Much like DHCP clients, a WINS client attempts to renew any NetBIOS names it holds at half the TTL, for instance, every three days. Additionally, each time the computer is restarted, or the Windows service that registers a NetBIOS name restarts, a new Name Registration message is sent to the WINS server, renewing the name (assuming, of course, that the WINS server successfully registers the name).

The Network Monitor trace in Capture 18-05 (included in the \Captures folder on the companion CD-ROM) shows a name refresh for the name KAPOHO10[00]. In this trace, the TTL for the record, as returned from the WINS server, is 2400 milliseconds.

Resolving NetBIOS Name Registration Conflicts

A name conflict occurs when two (or more) end-nodes want to register the same unique NetBIOS name. In most cases, this is caused by a configuration error, such as giving two computers the same name. When two computers attempt to register a unique NetBIOS name, the second end-node attempting to register the NetBIOS name fails, and an error is logged.

The Network Monitor trace in Capture 18-04 (included in the \Captures folder on the companion CD-ROM) shows a computer (IP address 10.10.1.52) attempting to register the name JASMINE[00]. However, the WINS server already has a registration for that name. The WINS server first issues a WACK to the computer at 10.10.1.52, and then queries the registered owner of the NetBIOS name JASMINE[00]. The query is a simple Name Query Request sent to the registered owner at IP address 10.10.1.102. This computer is active and responds to the request with a Name Query Response. Because WINS has ascertained that the registered owner still owns the name, WINS sends a registration response back to 10.10.1.52 with an error code set, indicating that the name is active.

Releasing NetBIOS Names

A name can be released either actively or silently. A Windows Server 2003 P-node client releases a held NetBIOS name by sending the WINS server a Name Release message containing the NetBIOS name to release. Alternatively, if an end-node fails to renew the name, after the name's TTL has expired, the name becomes available for use by another end-node. B-Node clients can effectively release a name by no longer defending it.

With Windows Server 2003, the NBTSTAT.EXE command, used with the -RR switch, releases all currently registered NetBIOS names and then reregisters them. This can be useful for diagnostic purposes.

Name Release Request and Name Release Response

When an end-node that is configured to use a WINS server wants to release a registered NetBIOS name, the end-node sends a Name Release Request message to the WINS server. The WINS server responds with a Name Release Response. Usually, the release response has a result code of 0, indicating that the name was successfully released. The WINS server could send a negative Name Release message, although it would be ignored by the end-node sending the Name Release message.

The Network Monitor trace in Capture 18-06 (included in the \Captures folder on the companion CD-ROM) shows the computer at IP address 10.10.1.52 releasing the NetBIOS names it owns. It does this by sending the WINS server, at 10.10.1.200, a Name Release message. For each name released, the WINS server sends a Release Response.

Resolving NetBIOS Names

When a Windows Server 2003 computer needs to resolve a NetBIOS name, it issues a NetBIOS Name Query Request, either using a broadcast or sending the request directly to a WINS server, depending on node type. If the Name Query Request is sent to a WINS server and is one that can be resolved, the WINS server sends a Name Query Response to the computer issuing the query. If the WINS server cannot resolve the name, it issues a negative Name Query Response. If the computer performing the name resolution is using B-Node behavior, it issues a Name Query Request; and if the end-node owning the name is on the local subnet, it responds. However, if there is no end-node owning that name on the local subnet, the host that is querying the name times out, although this can take longer than getting a negative Name Query Response from a WINS server.

Name Query Request

A Name Query message contains the NetBIOS name to be resolved and is sent either to the local network or to the WINS server, or both, depending on the NetBIOS node type. If the end-node uses broadcast to find the name, it issues three broadcasts, by default, before failing.

When a user performs some operation using names on a Windows Server 2003 computer—such as typing NET VIEW \\XXX at the Windows Server 2003 command prompt, or typing \\XXX in Windows Explorer's Address box—it is not always clear to Windows just what type of name is being resolved: host name or NetBIOS name; nor is it clear which name resolution method gives the fastest results.

In Windows NT 4.0, the operating system first attempts one name resolution (such as NetBIOS resolution or host name resolution), and if that does not succeed, the operating system tries the other method. This results in delays if the wrong method is chosen. To reduce the delay, Windows Server 2003 attempts to resolve the names using both methods simultaneously.

The Network Monitor trace in Capture 18-07 (included in the \Captures folder on the companion CD-ROM) shows an M-Node client attempting to resolve the name XXX. The Network Monitor trace in Capture 18-08 (included in the \Captures folder on the companion CD-ROM) shows the same attempted resolution by an H-Node client. The same computer generated both traces when the user typed NET VIEW \\XXX at the Windows Server 2003 command prompt.

Notice that, in both of these traces, a DNS Query is attempted before any NetBIOS name resolution is performed. Also note that in Capture 18-07, the M-Node client first attempts to resolve the name by broadcasting on the local network. When this fails, the client contacts the WINS server. In Capture 18-08, the H-Node client first attempts to contact WINS. When this fails to resolve the name, the H-Node client then broadcasts the Name Query Request message.

Positive Name Query Response

When a NetBIOS host or a WINS server receives a Name Query Request for a NetBIOS name that can be resolved, the receiving system returns a Name Query Response. The Name Query Response has the return code set to 0 (indicating successful resolution) and includes a resource record (RR) giving the IP address of the system owning the name. If the name being queried is a unique name, only one IP address is returned. If the name being queried is a group name, one or more IP addresses can be returned.

The Network Monitor trace in Capture 18-09 (included in the \Captures folder on the companion CD-ROM) shows WINS successfully resolving the NetBIOS name KONA[00]. The response contains an RR, with the IP address of the end-node holding the NetBIOS name 10.10.2.200.

Negative Name Query Response

When a WINS server receives a Name Query Request for a NetBIOS name that cannot be resolved, the WINS server returns a negative Name Query Response. The negative Name Query Response has the return code set to indicate that the requested name does not exist. The Answer count in the returned Name Query Response is also set to 0.

The Network Monitor trace in Capture 18-10 shows a negative Name Query Response.

Refreshing NetBIOS Names

Each registered NetBIOS name has a TTL. If the owning end-node wants to continue using the NetBIOS name, it must refresh the name before that TTL expires. For names registered with WINS, the administrator configures the TTL value. Windows 2000, Windows XP, and Windows Server 2003 computers attempt to reregister each NetBIOS name at half the TTL.

The Network Monitor trace in Capture 18-05 (included in the \Captures folder on the companion CD-ROM) shows an end-node reregistering the NetBIOS name KAPOHO10[00] using a Name Refresh message. In this trace, the refresh is successful, therefore the WINS server responds with a Registration Response message.

Determining Adapter Status

RFCs 1001 and 1002 provide for a mechanism so that an end-node can determine the status of a local or remote adapter of another end-node. The adapter status information includes the NetBIOS names registered at that end-node and counts of various statistics.

In Windows Server 2003, you can use the NBTSTAT.EXE command, with the -A or -a switch to obtain a remote computer's NetBIOS adapter status. If the local or remote host has NetBT disabled, however, this command does not succeed.

The Network Monitor trace in Capture 18-11 (included in the \Captures folder on the companion CD-ROM) shows a trace of an adapter status Request and Response message. The command used to generate this trace, along with its output, is as follows:

C:\>nbtstat -a 10.10.1.66

Local Area Connection:

Node IpAddress: [10.10.1.68] Scope Id: []

           NetBIOS Remote Machine Name Table

    Name                 Type        Status

      ——————————————————————————————————————————

    KAPOHO11       <00>  UNIQUE      Registered

    KAPORG         <00>  GROUP       Registered

    KAPOHO11       <20>  UNIQUE      Registered

    KAPORG         <1E>  GROUP       Registered

    MAC Address = 00-50-56-40-50-C1


NetBIOS Name Service Messages

Most interactions between a WINS client and a WINS server consist of a request (such as a Name Registration Request) sent from a client to a server, and a subsequent response sent in the opposite direction. For example, when a WINS client needs to resolve a NetBIOS name, it sends a Name Request message to the WINS server and receives either a negative Name Query Response or a positive Name Query Response message in return.

NetBIOS Name Service messages are sent using UDP, with UDP port 137 on both the client and the server. Because all Name Service messages use UDP, which is an inherently unreliable transport protocol, there might not be a strict one-to-one relationship between requests and responses. However, there is never more than one response generated for any given request. This means, for example, that a WINS client might send more than one Name Resolution Request before it receives a response. If the WINS server cannot answer the question promptly, it might send one or more WACK messages back to the client.

As Figure 18-1 illustrates, the general format of a Name Service message is similar to DNS messages, described in Chapter 17, "Domain Name System (DNS)."

Figure 18-1. NetBIOS Name Service message format.

A NetBIOS Name Service message consists of the following five sections:

  • Name Service header Fixed length (12 octets long), holding information about the type of NetBIOS Name Service message, plus counts of the other records in the message.
  • Question entries Variable length (length defined in Name Service header) for NetBIOS Name Registration, Refresh, or Release messages; this field holds the NetBIOS name being acted on by the message.
  • Answer resource records Variable length (length defined in Name Service header) holding RRs returned in response to a question.
  • Authority resource records Variable length (length defined in Name Service header) holding RRs used to indicate the authority for the question being asked. These are not used in Windows Server 2003.
  • Additional resource records Variable length (length defined in Name Service header) holding other RRs, not provided in direct answer to a question.

NetBIOS Name Service messages contain a header and one or more additional entries, depending on the Name Service messages. The specific entries that are included in each NetBIOS Name Service record are given in the description of each NetBIOS Name Service message.

Name Service Header

Figure 18-2 displays the format of the Name Service header.

Figure 18-2. NetBIOS Name Service message header layout.

The Name Service header is a fixed-length set of fields that identifies the type of name service packet and the number of question entries, answer records, authority RRs, and additional records existing in the message. The other sections of a Name Query message carry either the NetBIOS names to be used in the name operation or RRs (such as the IP address) returned by a Name Service Query.

The Name Service header section consists of the following fields:

  • Transaction ID A 16-bit field used to identify a specific name service transaction. The originator creates the transaction ID when it sends the request to the responder, and the responder copies the transaction ID into the reply message. If a WINS client is, for example, registering multiple names, each Name Registration Request has a different transaction ID.
  • Flags A 16-bit field containing various Name Service flags.
  • Question Count A 16-bit field indicating the number of entries in the question section of a name service packet. The sender of a NetBIOS Name Service Request (for example, a WINS client attempting to register a name) always sets this value to 0-01 or more, although typically it is set at 0-01. The responder for a Name Service Request always sets this field to 0.
  • Answer Count A 16-bit field indicating the number of entries in the answer RRs section of a name service packet. The sender of a Name Service Request sets this count to 0. The responder for a Name Service Request sets this to indicate the number of answers returned. This is generally 1 for unique NetBIOS name lookups, and a larger number for Internet group name lookups.
  • RR Count A 16-bit field indicating the number of entries in the authority RR section of a name service packet. This number is used for recursive NetBIOS name queries, which are not implemented in Windows Server 2003. This field is set to 0 in NetBIOS Name Service messages to indicate that there are no authority records present.
  • Additional RR Count A 16-bit field indicating the number of entries in the additional RRs section of a name service packet. These records are used when an RR needs to be included in any name service operation that is not a response to a Name Query Request, such as a name release (the additional RR includes the name being released).

Name Service Header Flags Field

The Flags field, contained in the NetBIOS Name Service header, contains details about the purpose of each Name Service message. Figure 18-3 displays this field's format.

Figure 18-3. NetBIOS Name Service Flags field layout.

The Flags field holds the following fields:

  • Request/Response A 1-bit field set to 0 to indicate a Name Service Request, and set to 1 to indicate a Name Service Response.
  • Operation Code A 4-bit field that indicates the specific name service operation of the name service packet, as shown in Table 18-2.
    Table 18-2. Name Service Operation Codes and Meanings
    Operation Code Operation

    0

    Name Query Request

    0x5

    Name Registration Request

    0x6

    Name Release

    0x7

    Wait Acknowledgment

    0x8

    Name Refresh

  • Authoritative Answer Indicates whether the responder is authoritative. For Name Service requests, this is always set to 0. For responses, the computer responding to the request sets it to 1 if it is authoritative for a NetBIOS name.
  • Truncation Set to 1 if the total number of responses cannot fit into the UDP datagram (for instance, the total number exceeds 576 bytes). RFC 1001 offers the possibility of using TCP to obtain the full answers, but Windows Server 2003 does not support the use of TCP in conjunction with NetBIOS name operations.
  • Recursion Desired Set to 1 by the sender of a Name Query, Name Registration, or Name Release if the sender wishes the receiver to iterate on the query. Windows Server 2003 WINS clients set this flag to 1 for all name queries. If the flag was set in a Name Service message sent to a Windows Server 2003 WINS server, the WINS server sets it in the corresponding reply. However, Windows Server 2003 does not support recursion.
  • Recursion Available Set to 0 on all Name Request messages. The Windows Server 2003 WINS server sets this field to 1 in Name Service Replies to indicate that it can perform recursive Name Query, Name Registration, and Name Release messages. If set to 0 in a Name Service Response, the client must iterate for Name Service Queries and perform challenges for any name registrations.
  • Reserved Two reserved bits set to 0.
  • Broadcast Set to 0 if the Name Service message is being sent using a unicast packet (for instance, to a WINS server), or 1 if it is being broadcast.
  • Return Code A 4-bit field holding the return code. All Name Service Requests set the value to 0, which indicates a successful response. For Name Query Requests, this means the answer is in the Reply message; for Name Registrations, it means the registration was successful.

NetBIOS Name Representation

NetBIOS names sent in name service packets are encoded using a scheme that was originally designed to make NetBIOS names contained in Name Service message packets, similar to DNS names. This was considered important because the DNS specifications, at the time that RFCs 1001 and 1002 were written, were more restrictive in terms of the range of characters that could be used in the name. The full name of the network resource is the concatenation of the encoded 16-character NetBIOS name, the period (.) character, and the NetBIOS scope identifier if one is configured.

Creating the full NetBIOS resource name involves the following three steps:

  1. The 16-character NetBIOS name is converted into a 32-bit unicode representation.
  2. The period (.) character and the NetBIOS scope identifier are appended to the encoded 16-character NetBIOS name.
  3. The resulting name is then encoded according to the rules for DNS Name Query.

The first step involves converting the original 16-byte NetBIOS name into a 32-byte string by mapping each 4-bit (half-byte) nibble to an ASCII character, as shown in Table 18-3.

Table 18-3. Converting an Original 16-Byte NetBIOS Name into a 32-Byte String
Nibble Value (in Hex) | Encoded ASCII Character
0 | A
1 | B
2 | C
3 | D
4 | E
5 | F
6 | G
7 | H
8 | I
9 | J
A | K
B | L
C | M
D | N
E | O
F | P

This conversion results in a name string that contains only the characters A through P, thus providing compatibility with DNS names, which were more restrictive about the content of names than NetBIOS.

As an example, consider the name of the Workstation service on the server KAPOHO (KAPOHO[03]). The full 16-character name would be "KAPOHO [03]"; that is, the name KAPOHO followed by nine spaces (or 0x20), and terminated by the hexadecimal value 0x03. Expressed in hex format, this name becomes:

4B-41-50-4F-48-4F-20-20-20-20-20-20-20-20-20-03

Converting this name into nibbles, the string would then become:

4-B-4-1-5-0-4-F-4-8-4-F-2-0-2-0-2-0-2-0-2-0-2-0-2-0-2-0-2-0-0-3

Using Table 18-3, this nibble string is then encoded into a 32-byte ASCII string, which is

ELEBFAEPEIEPCACACACACACACACACAAA

The third step involves converting the name into the DNS name format. In DNS, domain names are expressed as a sequence of labels. If the DNS name is kapoho.com, for example, this DNS name would consist of two labels (kapoho and com). Each label in a DNS message is formatted with a 1-byte length field followed by the label. The domain kapoho.com, therefore, would be expressed as 0x06kapoho0x03com0x00, where the hexadecimal digits represent the length of each label, the ASCII characters represent the individual labels, and the final hex 0 indicates the end of the name.

To complete the NetBIOS name encoding, the first label is the encoded 16-character NetBIOS name, with additional labels for the NetBIOS scope identifier, if this is used. In the example, if there is no NetBIOS scope identifier, the name would be:

0x20ELEBFAEPEIEPCACACACACACACACACAAA0x00

If a NetBIOS scope identifier, for example KAPOHO.COM, were to be used, the name would become:

0x20ELEBFAEPEIEPCACACACACACACACACAAA0x06kapoho0x03com0x00
This encoding scheme seems quite complicated at first sight. It was originally designed to be compatible with the emerging DNS standards and to make it easier for computers to parse. Fortunately, Microsoft Network Monitor decodes the NetBIOS name, thus simplifying viewing NetBIOS names in Network Monitor traces.

Question Entries

In a NetBIOS name packet, a question entry represents the NetBIOS name being registered, refreshed, released, or queried. The format of a NetBIOS Name Service Question entry is based on DNS question entries. Figure 18-4 displays the Question field layout.

Figure 18-4. Name Service Question entry field layout.

The Question entry is made up of the following three fields:

  • Question Name The NetBIOS name being registered, refreshed, and so forth. The name is encoded using the NetBIOS name representation scheme described earlier in the NetBIOS Name Representation section.
  • Question Type The type of question. Set to either 0-20, indicating that the question name is a NetBIOS name, or 0-21.
  • Question Class The question class. Set to 0-01. This represents the IN (Internet) question class. No other question classes are supported.

RRs

RRs are used to send resource information between a client and server. Figure 18-5 displays the layout of an RR.

Figure 18-5. Name Service RR field layout.

The fields in an RR are as follows:

  • Resource Record Name The NetBIOS name, represented in the compressed name format described later in this chapter.
  • Record Type The RR type code.
  • Record Class The RR class code; there is only one record class, 0-01, the Internet Class.
  • Time To Live The RR's TTL, expressed in seconds.
  • Resource Data Length A 2-byte field holding the resource data's length.
  • Resource Data Variable-length data corresponding to the RR type. RFC 1002 defines values for Record Type fields as shown in Table 18-4.
Table 18-4. Values for Record Type Fields
Value | Description
0-00 | IP Address RR
0-02 | Name Server RR
0-0A | Null RR
0-20 | NetBIOS General Name Service RR
0-21 | NetBIOS Node Status RR

Most Name Service records are either NetBIOS General Name Service RRs (record type 0-20) or NetBIOS Node Status RRs (record type 0-21).

Figure 18-6 displays the layout for the RR data used in General Name Service RRs (record type 0-20).

Figure 18-6. RR data layout for record type 0-20.

As Figure 18-6 shows, the RR contains a length of 6 bytes, an RDATA flags field, and the IP address relating to this name. For instance, in a Name Registration message, this is the IP address of the owner registering the name.

Figure 18-7 displays the layout of the RDATA flags field.

Figure 18-7. RDATA flags field layout.

The RDATA contains the following three fields:

  • Group Flag Set to 1 if the name is a group name; otherwise set to 0
  • Owner Node Type A 2-bit field, formatted as follows: 0 - B-Node; 1 - P-Node; 0x2 - M-Node; 0x3 - H-Node
  • Reserved 13 bits set to binary 0

With respect to the owner node type, RFC 1002 defines the value of 11 as "Reserved for future use." In Windows Server 2003, this indicates H-Node.

Figure 18-8 displays the RDATA field for node status response RRs (Name Service record type 0x21).

Figure 18-8. RDATA layout for node status response.

As Figure 18-8 shows, the RDATA field for node status responses contains the following fields:

  • Length 16 bits holding the total length of the RDATA section
  • Number Of Names 8 bits holding the number of names in the node name array
  • Node Name Array A variable-length array of the NetBIOS names owned by the node responding to the node status request
  • Node Statistics A set of statistics about the node's NetBIOS service

The Network Monitor trace in Capture 18-11 (included in the \Captures folder on the companion CD-ROM) illustrates the Statistics field. The values for this field, however, are not displayed by the NBTSTAT command. Windows Server 2003 returns all zeros in the statistics field.

Resource Record Name Compression

To help ensure that Name Service Request and Response messages fit into a single UDP packet, NetBT uses a compression mechanism for NetBIOS Name Service messages in which a given NetBIOS name appears more than once. For example, in Name RegistrationRequest messages, the NetBIOS name being registered is held both in the Question fields (the Question Name field) and in the Additional RR field (which contains both the NetBIOS name and IP address of the end-node that is registering the NetBIOS name).

In these cases, the name registration information contained in the Additional Resource Name field of the NetBIOS Name Service records uses the compressed label pointer technique that DNS uses, as defined in RFC 883.

Name Registration Message

A Name Registration message contains a header, a question record, and an additional RR holding the IP address of the node registering the name.

The fields are set as follows:

  • Transaction ID Set to a random number.
  • Response Flag Set to 0 (indicating a request).
  • Op Code Set to 0x5 (indicating registration).
  • Recursion Desired Set to 1.
  • Broadcast Flag Set if name registration packet is being broadcast.
  • Question Count Set to 1.
  • Answer Resource Set to 0.
  • Name Service Resource Record Count Set to 0.
  • Additional Resource Record Count Set to 1.
  • Question Record Section Contains the NetBIOS name being registered.
  • Additional Resource Record The format is described in the following list.

The additional RR field in a Name Registration Request message contains details regarding this RR, and includes the following fields:

  • Resource Record Name in compressed pointer format
  • Resource Record Type Set to 0-20
  • Requested TTL By default, set to 300,000 milliseconds
  • RDATA Flags Indicates the name type (group, unique) and the node type of the node registering the name
  • IP Address Belongs to the end-node registering this name

A Name Registration message can be seen in the Network Monitor trace in Capture 18-01 (included in the \Captures folder on the companion CD-ROM).

Positive Name Registration Response

A positive Name Registration Response contains a header and an answer record. In a positive Name Registration Response message returned by a Windows Server 2003 WINS server, the header fields are set as follows:

  • Transaction ID Set to the Transaction ID in the Name Registration Request message
  • Response Flag Set to 1 to indicate a response
  • Op Code Set to 0x5 (registration)
  • Authoritative Answer Flag Set to 1
  • Recursion Desired Set to 1
  • Recursion Available Set to 1
  • Broadcast Flag Set to 0
  • Question Count Set to 0
  • Return Code Set to 0 to indicate the name was successfully registered
  • Question Count Set to 0
  • Answer Resource Record Count Set to 1
  • Name Service Resource Record Count Set to 0
  • Additional Resource Record Count Set to 0
  • Answer Resource Record The answer RR confirms the details of the NetBIOS name that were registered with the WINS server, and contains the following fields:
    • Resource Record Name Such as the registered NetBIOS name (in coded format)
    • Resource Record Type Set to 0-20
    • Actual TTL For The Record Registered Set based on the TTL configured at the WINS server
    • IP Address Set to the IP address that belongs to the end-node that registered this name

A positive Name Registration Response message can be seen in the Network Monitor trace in Capture 18-01 (included in the \Captures folder on the companion CD-ROM).

Negative Name Registration Response

A negative Name Registration Response is returned when the WINS server is unable to register the requested NetBIOS name. This usually occurs when an end-node attempts to register a unique NetBIOS name that is owned by another end-node.

The negative Name Registration record is formatted as follows:

  • Transaction ID Set to the Transaction ID in the Name Registration Request message
  • Response Set to 1 to indicate a response
  • Op Code Set to 0x5
  • Authoritative Answer Flag Set to 1
  • Recursion Desired Set to 1
  • Recursion Available Set to 1
  • Result Code Indicates why the NetBIOS name could not be registered
  • Broadcast Flag Set to 0
  • Question Count Set to 0
  • Answer Resource Record Count Set to 1
  • Name Service Resource Record Count Set to 0
  • Additional Resource Record Count Set to 0
  • Answer Resource Record Confirms the details of the name that failed to be registered

RFC 1001 defines the following values for the return code field, as Table 18-5 displays.

Table 18-5. Values for the Return Code Field
Return Code Value | Reason for the Error
1 | Format error: The request was improperly formatted.
0x2 | Server failure: There is a problem with the name server, such that it cannot process the Name Registration Request.
0x4 | Unsupported: The request is not supported by the NetBIOS name server (not used by WINS).
0x5 | Registration Request refused: For policy reasons, the NetBIOS name service cannot register this name from this host (not used by WINS in Windows Server 2003).
0x6 | Name active: Another node owns the name.
0x7 | Name conflict: More than one end-node owns a unique NetBIOS name.

The most common return code is 0x6, name active. This occurs whenever the name that the end-node is requesting WINS to register has already been registered by another end-node. This can be seen in the Network Monitor trace in Capture 18-03 (included in the \Captures folder on the companion CD-ROM).

Name Refresh Message

As noted earlier, the end-node owning a NetBIOS name attempts to refresh the name (essentially re-leasing the NetBIOS name) at half the TTL by issuing a Name Refresh message to the WINS server. The Name Refresh message is similar to a Name Registration Request message and is formatted as follows:

  • Transaction ID Set to a random number.
  • Response Set to 0x0 to indicate a request.
  • Op Code Set to 0x4, indicating a name refresh. RFC 1002 defines the name refresh op code as 0x09, but Windows Server 2003 clients set this to 0x04.
  • Authoritative Answer Flag Set to 0.
  • Recursion Desired Set to 1.
  • Recursion Available Set to 0.
  • Result Code Set to 0.
  • Broadcast Flag Set to 0.
  • Question Record Count Set to 1.
  • Answer Resource Record Count Set to 0.
  • Name Service Resource Record Count Set to 0.
  • Additional Resource Record Count Set to 1.
  • Question Record Contains the NetBIOS name being refreshed. The format is the same as for the question record in a Name Registration Request.
  • Additional Resource Record Confirms the details of the name to be refreshed. The format is the same as for the additional RR in a Name Registration Request.

WINS usually responds to a Name Refresh message with a positive Name Registration Response record, as seen in the Network Monitor trace in Capture 18-05 (included in the \Captures folder on the companion CD-ROM).

Name Release Request Message

A Name Release Request message is sent when an end-node releases a NetBIOS name. This usually happens when a Windows Server 2003 service that used NetBIOS names is stopped or is being shut down. A Name Release Request message is formatted as follows:

  • Transaction ID Set to a random number.
  • Response Set to 0 to indicate a request.
  • Op Code Set to 0x6, meaning name release.
  • Authoritative Answer Flag Set to 0.
  • Recursion Desired Set to 0.
  • Recursion Available Set to 0.
  • Broadcast Flag Set to 0.
  • Result Code Set to 0.
  • Question Record Count Set to 1.
  • Answer Resource Record Count Set to 0.
  • Name Service Resource Record Count Set to 0.
  • Additional Resource Record Count Set to 1.
  • Question Record Contains the NetBIOS name being released. The format is the same as for the question record in a Name Registration Request.
  • Additional Resource Record Confirms the details of the name that is to be released. The format is the same (such as the DNS pointer format) as for the additional RR in a Name Registration Request.

The Network Monitor trace in Capture 18-06 (included in the \Captures folder on the companion CD-ROM) illustrates the Name Release Request message. When an end-node sends a Name Release Request message to a WINS server, the WINS server usually responds with a positive Name Release Response message, although an error can occur at the WINS server and result in the WINS server sending a negative Name Release Response message. The end-node sending the original name release message does not take any action on a negative Name Release Response message.

Name Release Response Message

A WINS server sends a Name Release Response message in response to a Name Release Request message. A positive Name Release Response is indicated by the result code 0. A negative Name Release Response has the same format as a positive Name Release Response, except that the result code contains details of the error.

A Name Release Response message is formatted as follows:

  • Transaction ID Set to the same transaction ID contained in the Name Release Request message.
  • Response Set to 1 to indicate a response.
  • Op Code Set to 0x6, meaning name release.
  • Authoritative Answer Flag Set to 0.
  • Recursion Desired Set to 0.
  • Recursion Available Set to 0.
  • Broadcast Flag Set to 0.
  • Result Code Set to 0 (success) or to indicate reason for the failure.
  • Question Record Count Set to 0.
  • Answer Resource Record Count Set to 1.
  • Name Service Resource Record Count Set to 0.
  • Additional Resource Record Count Set to 0.
  • Answer Resource Record Contains the NetBIOS name that has been released. The format is the same as for the question record in a Name Registration Request.

If the WINS server successfully releases the NetBIOS name, the return code is 0. Table 18-6 indicates what the return codes are if the WINS server cannot release the name.

Table 18-6. Explanation of Return Code Value and Error
Return Code Value | Reason for the Error
1 | Format error: The request was improperly formatted.
0x2 | Server failure: There is a problem with the name server, such that it cannot process the Name Release Request.
0x5 | Registration Request refused: For policy reasons, the NetBIOS name server could not release this name from this host (not used by WINS in Windows Server 2003).
0x6 | Name active: Another node owns the name; only the node owning the name can release it.

A Name Release Response message can be seen in the Network Monitor trace in Capture 18-06 (included in the \Captures folder on the companion CD-ROM).

Name Query Request Message

A computer that wants to resolve a NetBIOS name sends a Name Query Request message. This message, which can be sent using broadcast or direct to a WINS server, is formatted as follows:

  • Transaction ID Set to a random 16-bit value
  • Response Set to 0 to indicate a request
  • Op Code Set to 0, meaning Name Query
  • Authoritative Answer Flag Set to 0
  • Recursion Desired Set to 1
  • Recursion Available Set to 0
  • Broadcast Flag Set to 1 if broadcast, and 0 if sent to a WINS server
  • Result Code Set to 0
  • Question Record Count Set to 1
  • Answer Resource Record Count Set to 0
  • Name-Service Resource Record Count Set to 0
  • Additional Resource Record Count Set to 0
  • Question Record Contains the NetBIOS name that the sender wishes to resolve

The Network Monitor trace in Capture 18-09 (included in the \Captures folder on the companion CD-ROM) illustrates a Name Query Request, and shows a query being sent to a WINS server.

Positive Name Query Response Message

If the node that has received a Name Query can resolve the name, it formats and sends a positive Name Query Response to the node that issued the original Name Query message. The positive Name Query message contains the IP address of the system owning the NetBIOS node and is formatted as follows:

  • Transaction ID Set to the transaction ID specified in the Name Query Request message
  • Response Set to 1 to indicate a response
  • Op Code Set to 0, meaning Name Query
  • Authoritative Answer Flag Set to 1
  • Recursion Desired Set to 1
  • Recursion Available Set to 1
  • Broadcast Flag Set to 1 if broadcast, and to 0 if sent from a WINS server
  • Result Code Set to 0
  • Question Record Count Set to 0
  • Answer Resource Record Count Set to 1
  • Name Service Resource Record Count Set to 0
  • Additional Resource Record Count Set to 0
  • Answer Resource Record Contains details of the name including the name type (unique, group) and the name TTL; also contains details of the node that owns the name (the IP address and the node type)

A positive Name Query Response message can be seen in the Network Monitor trace in Capture 18-09 (included in the \Captures folder on the companion CD-ROM).

Negative Name Response Message

When a WINS server gets a Name Query Response that it cannot resolve, it sends a negative Name Response message to the node that sent the original Name Query message. The negative Name Response message is formatted as follows:

  • Transaction ID Set to the transaction ID specified in the Name Query message
  • Response Set to 1 to indicate a response
  • Op Code Set to 0, meaning Name Query
  • Authoritative Answer Flag Set to 1
  • Recursion Desired Set to 1
  • Recursion Available Set to 1
  • Broadcast Flag Set to 1 if broadcast, and to 0 if sent from a WINS server
  • Result Code Set to 0
  • Question Record Count Set to 0
  • Answer Resource Record Count Set to 1
  • Name Service Resource Record Count Set to 0
  • Additional Resource Record Count Set to 0
  • Answer Resource Record Contains details of the name including the name type (unique, group) and the name TTL; also contains details of the node that owns the name (the IP address and the node type).

A negative Name Query Response message can be seen in the Network Monitor trace in Capture 18-10 (included in the \Captures folder on the companion CD-ROM).

Wait Acknowledgment Message

A WINS server sends a WACK message to a client asking it to wait for the completion of a name service operation. The format of a WACK message is as follows:

  • Transaction ID Set to the transaction ID specified in the name message previously sent to the WINS server
  • Response Set to 1 to indicate a response
  • Op Code Set to 0x7, meaning WACK message
  • Authoritative Answer Flag Set to 1
  • Recursion Desired Set to 0
  • Recursion Available Set to 0
  • Broadcast Flag Set to 0
  • Result Code Set to 0
  • Question Record Count Set to 0
  • Answer Resource Record Count Set to 1
  • Name Service Resource Record Count Set to 0
  • Additional Resource Record Count Set to 0
  • Answer Resource Record Contains details of the name service operation that the WINS server is asking the receiver of this message to wait for

The Network Monitor trace in Capture 18-04 (included in the \Captures folder on the companion CD-ROM) illustrates a WACK message.


Summary

WINS provides NetBIOS name resolution for networks of any size, although it is most likely to be used in networks that span multiple subnets. Windows Server 2003, Windows XP, and Windows 2000 make heavier use of DNS than Windows NT 4.0, but the need for WINS continues until all down-level clients and applications that rely on NetBIOS are replaced.


File and Printer Sharing

Chapter 19
File and Printer Sharing

One of the key functions provided in the Microsoft Windows Server 2003 family is the ability to share files and printers. The Windows Server 2003 family provides both the Common Internet File System (CIFS), based on the Server Message Block (SMB) file and printer sharing protocol, and the Internet Printing Protocol (IPP), which allows clients to install printer drivers over their intranet or the Internet, as well as to send print jobs using IPP encapsulated in Hypertext Transfer Protocol version 1.1 (HTTP/1.1).

CIFS is an operating-system-independent protocol that evolved from the SMB and NetBIOS file- and printer-sharing mechanisms of earlier versions of Windows. The SMB protocol was created in the 1980s by IBM and later enhanced and extended by IBM, 3Com, Intel, and Microsoft. SMB is now also known by the name CIFS.

CIFS allows clients to access files and printers over their corporate LAN as well as over the Internet. Microsoft and several other vendors are jointly developing CIFS specifications, and a specification draft was submitted to the Internet Engineering Task Force (IETF) in expectation that it might be adopted as an informational RFC (this Internet draft has now expired). Copies of the early drafts of this material are contained in the \Cifs folder on the companion CD-ROM.

One problem with CIFS is that there is no up-to-date formally published specification. The draft RFC documents contained in the folder were written in 1997 and have not been significantly updated since. They are largely accurate, although they are not complete and appear inaccurate in some areas. There is an active CIFS mailing list; see http://discuss.microsoft.com/archives/cifs.html for the list's archive and for instructions on how to join the list.

IPP is a method of performing printing operations across a network based on using HTTP/1.1. With Windows Server 2003, IPP also requires the IPP server to be running Microsoft Internet Information Services (IIS) 6, which is not installed by default.


Introduction to CIFS

CIFS is a cross-platform mechanism allowing clients to request file and print services from a network server based on the widely used SMB protocol.

The SMB protocol was invented by Dr. Barry Feigenbaum of IBM's Boca Raton lab during the early Microsoft Disk Operating System (MS-DOS) days. It was extended by 3Com, IBM, Intel, and Microsoft during the mid- to late 1980s. During late 1996, Microsoft relaunched the Microsoft Windows NT 4.0 extensions of the SMB protocol as CIFS and released a draft RFC. Some of the enhancements that were most visible were the addition of Andrew File System/Distributed File System (AFS/DFS), or Transarc, style referrals and the use of port 445 (to avoid reliance on the RFC 1001 NetBIOS service). To ensure compatibility between older and newer systems, the client and server negotiate which variant of the SMB protocol to use, the highest version that both client and server support.

The version of CIFS included with Windows Server 2003 remains backward- compatible with previous versions of Windows. CIFS is an open protocol, which means that all aspects of communication are publicly documented, although the documentation that is publicly available is incorrect and lacking in places.

The chief advantage that CIFS provides over file access protocols such as HTTP and File Transfer Protocol (FTP) is that it allows simultaneous read and write access to a file, as opposed to the simple file transfer capabilities provided by HTTP and FTP. CIFS supports distributed, replicated virtual volumes such as Distributed File System (Dfs), file and record locking, file change notification, read-ahead and write-behind operations, and most of the functionality typically associated only with direct connections to a corporate network. CIFS functions over any IP-based network, including the Internet.

The SMB protocol was originally based on NetBIOS as a transport protocol, running on top of TCP/IP, IPX/SPX, or NetBEUI. Using TCP/IP, a CIFS client wanting access to a file or print server would first create a TCP connection to the server (assuming that both client and server shared a compatible transport connection). Next, the client would establish a NetBIOS session over the previous transport session. The client would finally use the NetBIOS session to create and then utilize a file and print sharing session with the server. When TCP/IP is used as the transport protocol for the NetBIOS session, the client initiates the NetBIOS session over TCP, using server port 139.

With Windows Server, the file server can directly host the file and print sharing and does not require NetBIOS. A client opening a direct host connection sets up a TCP session using TCP port 445.

File and print sharing sessions can also be established and used with NetBIOS running over IPX/SPX and NetBEUI. However, details of such sessions are outside the scope of this book, which concentrates only on the use of TCP/IP.

CIFS Operation

The steps involved in CIFS file sharing can be summarized as follows:

  1. The client determines the IP address of the server and makes a connection to either TCP port 445 or TCP port 139 (if NetBIOS is being used) on the server.
  2. If the client is using NetBIOS, then a NetBIOS session is set up over the existing TCP connection.
  3. The client then negotiates the SMB dialect to use. The server chooses the most functional dialect that both client and server understand and returns a list of capabilities to the client.
  4. The client then requests a session with the server, providing some security information. The exchanges relating to security will be dependent on the specific security mechanisms in use. If the session can be created, the server responds with the User ID (UID).
  5. The client attaches to a share using the UID. The server responds with the Tree ID (TID) relating to that share.
  6. The client opens a file using the TID and UID. The server responds with a File ID (FID) to identify the open file.
  7. The client then uses the UID, TID, and FID to perform file operations on the file.
  8. When complete, the client closes the file, closes the session, and finally closes the TCP connection, which terminates the file sharing session. If the connection has been made using NetBIOS, closing the underlying TCP connection also closes the NetBIOS session.

These steps are shown in Figure 19-1 and discussed in more detail in the following pages.

Figure 19-1. CIFS file sharing.

Name Resolution and Connection Establishment

The CIFS server registers its name with a name resolution service, using either a fully qualified domain name and the Domain Name System (DNS) or a NetBIOS name and Windows Internet Naming Service (WINS). A client wishing to connect to the CIFS server can query a DNS or WINS server to obtain the IP address of the CIFS server. Capture 19-01, included in the \Captures folder on the companion CD-ROM, demonstrates the CIFS protocol. This is a trace of a client, Kapoho11, accessing a file on a share contained on the server Kapoho10.

The first step made by the client is to resolve the name to the IP address of the CIFS server. The client establishes a connection to the CIFS server using TCP port 445 (assuming direct hosting is used). If a NetBIOS-based connection is being used, the client next sets up a NetBIOS session. In the trace, NetBIOS hosting is used.

Once the basic connection is established, the CIFS client negotiates which variant of the SMB protocol is to be used. Clients and servers can understand multiple variants of the SMB protocol and need to negotiate which specific variant to use for this connection. The client performs this by issuing an SMB session request message over TCP port 139 (the NetBIOS session service) or over TCP port 445 (direct hosting).

The client begins the session negotiation by sending a NEGOTIATE packet to the server. This packet contains a list of the dialects the client is able to use. Table 19-1 lists the full set of SMB dialects, with those understood by Windows Server 2003 noted.

Table 19-1. SMB Dialects
Dialect Name | Comment
PC NETWORK PROGRAM 1.0 | The original MSNET SMB protocol (sometimes referred to as a "core protocol").
PCLAN1.0 | Some versions of the original MSNET defined this as an alternate to the core protocol name (not supported by Windows Server 2003).
MICROSOFT NETWORKS 1.03 | This is used for the MS-NET 1.03 product. It defines Lock & Read, Write & Unlock, and a special version of raw read and raw write (not supported by Windows Server 2003).
MICROSOFT NETWORKS 3.0 | This is the DOS LANMAN 1.0 specific protocol. It is equivalent to the LANMAN 1.0 protocol, except the server is required to map errors from the OS/2 error to an appropriate DOS error (this dialect is not supported by Windows Server 2003).
LANMAN1.0 | This is the first version of the full LANMAN 1.0 protocol.
LM1.2X002 | This is the first version of the full LANMAN 2.0 protocol (this dialect is not supported by Windows Server 2003).
DOS LM1.2X002 | This is the DOS equivalent of the LM1.2X002 protocol. It is identical to the LM1.2X002 protocol, but the server will perform error mapping to appropriate DOS errors (this dialect is not supported by Windows Server 2003).
DOS LANMAN2.1 | DOS LANMAN2.1 (this dialect is not supported by Windows Server 2003).
LANMAN2.1 | OS/2 LANMAN2.1 (this dialect is not supported by Windows Server 2003).
Windows for Workgroups 3.1a | Windows for Workgroups Version 1.
NT LM 0.12 | This is the latest version of the SMB protocol designed for Windows NT networking. This has special SMBs that duplicate Windows NT, Windows 2000, and Windows Server 2003 file-handling semantics.

Windows Server 2003 clients and servers attempt to negotiate NT LM 0.12, which allows the server to issue parameters that specify things such as encryption key lengths, maximum message sizes, and whether the server is Dfs-aware.

The server responds to the client with a NEGOTIATE packet identifying the highest dialect that both machines understand, as well as parameters specific to that dialect. Table 19-2 describes the components of a CIFS server NEGOTIATE response.

Table 19-2. Components of a CIFS Server NEGOTIATE Response
Server Response | Description
WordCount | A count of the parameter words in the packet (17 in the case of NT LM 0.12 dialect).
DialectIndex | The index of the selected dialect. For example, if the client offered six dialects, numbered 0-5, with 5 representing NT LM 0.12, the index would be 5.
SecurityMode | Security Mode of the selected dialect consists of 4 bits, as follows: Bit 0 Set to 0 to indicate share-level security or set to 1 to indicate user-level security. Bit 1 If set to 1 this indicates that passwords must be encrypted. Bit 2 Set to 1 to indicate that SMB signatures are enabled. Bit 3 Set to 1 to indicate that SMB signatures are required.
MaxMpxCount | Maximum number of pending multiplexed requests (default is 50).
MaxNumberVcs | Maximum number of virtual circuits between client and server (the default is 1).
MaxBufferSize | This is the size of the largest message that the client can transmit to the server. The default value is 4356 bytes.
MaxRawSize | Maximum raw-buffer size. This is the maximum message size that the server can send or receive for SMB_COM_WRITE_RAW or SMB_COM_READ_RAW operations. The default is 65,536 bytes.
SessionKey | The unique key identifying this session.
Capabilities | Server capabilities. These parameters are listed in Table 19-3.
SystemTimeLow | System (Universal Time Coordinate [UTC]) time of the server (low).
SystemTimeHigh | System (UTC) time of the server (high).
ServerTimeZone | Time zone of the server (minutes from UTC).
EncryptionKeyLength | Length of the encryption key.
ByteCount | Count of data bytes.
Server Guid | A globally unique identifier (GUID) uniquely identifying the server.
Security BLOB | An opaque security object.

By returning a list of its capabilities, the server informs the client which operations might or might not be performed at the client's request. Table 19-3 lists the bit definitions of the server's capabilities.

Table 19-3. Bit Definitions of Server Capabilities
Capability | Encoding | Description
CAP_RAW_MODE | 0x0001 | The server supports SMB_COM_READ_RAW and SMB_COM_WRITE_RAW.
CAP_MPX_MODE | 0x0002 | The server supports SMB_COM_READ_MPX and SMB_COM_WRITE_MPX.
CAP_UNICODE | 0x0004 | The server supports Unicode strings.
CAP_LARGE_FILES | 0x0008 | The server supports large files with 64-bit offsets.
CAP_NT_SMBS | 0x0010 | The server supports the SMBs particular to the NT LM 0.12 dialect.
CAP_RPC_REMOTE_APIS | 0x0020 | The server supports remote application programming interface (API) requests using remote procedure calls (RPCs).
CAP_STATUS32 | 0x0040 | The server can respond with 32-bit status codes.
CAP_LEVEL_II_OPLOCKS | 0x0080 | The server supports level 2 oplocks.
CAP_LOCK_AND_READ | 0x0100 | The server supports the SMB_COM_LOCK_AND_READ SMB.
CAP_NT_FIND | 0x0200 | The server supports NT Find.
CAP_DFS | 0x1000 | The server is Dfs-aware.
CAP_LARGE_READX | 0x4000 | The server supports SMB_COM_READ_ANDX requests that exceed the negotiated buffer size.

Once the CIFS client receives a NEGOTIATE PROTOCOL response, it completes the session negotiation by issuing a SESSION SETUP ANDX SMB to the server. Table 19-4 describes the components of a SESSION SETUP ANDX SMB.

Table 19-4. Components of a SESSION SETUP ANDX SMB
Client Request | Description
Word Count | A count of the parameter words in the packet (17 in the case of NT LM 0.12 dialect)
AndXCommand | Secondary (X) command; set to 0xFF = none
Reserved | Two octets, set to 0x0000
AndXOffset | Offset to next command WordCount
Max Buffer | Maximum buffer at the client
Max MPX Count | Actual maximum multiplexed pending requests
VC Number | 0 = first (only), nonzero = additional VC number
Session Key | Session key
Security Blob Length | Length of opaque security blob
Reserved | Four octets set to 0x000000
Capabilities | Client capabilities
ByteCount | Count of data bytes; minimum = 0
SecurityBlob | The opaque security blob
NativeOS | Client's native operating system in Unicode
NativeLanMan | Client's native LAN Manager type in Unicode

The CIFS server then responds with a SESSION SETUP ANDX response message. This message contains a UID to the client session. Additional sessions can be set up over the same connection without prompting the user for a password. CIFS can use any authentication supported by client and server, including Windows 2000 or Windows Server 2003 Kerberos authentication mechanisms.

The connection between client and server in an SMB session is called a virtual circuit (VC), which is formed over the transport service, typically TCP. Within a VC, the server assigns a TID that provides a unique identifier for each file sharing session and defines the types of access allowed over that connection. A process ID (PID) identifies the process environment for that session, and an FID is assigned to each file opened during the session. If a VC is closed, all environments within the VC (TID, PID, FID) are also closed. However, the closing of a single FID might not result in the closing of the VC, as multiple operations can be requested over a single VC.

Session Operations

Once a session has been established, a client can request four basic sets of operations against the file server:

  • File management requests The client can request the server to create (or open), read from, write to, and lock and close a file or create a temporary file. The client can delete, rename, move, or copy a file. In addition, clients can query and set both file and path information.
  • Directory management requests Clients can create, delete, and search directory entries.
  • Dfs operations Clients can request a Dfs referral from a Dfs server to a target server.
  • Miscellaneous operations Clients can request device and file system control functions to be transferred transparently to the server, as well as query and set the security descriptor on a file or directory.

Session Disconnection

When a client wishes to disconnect its session to a CIFS server, it follows a teardown process that is essentially the reverse of the session-establishment process. Any open files are closed and their associated FIDs and PIDs then can be disconnected. The TID is disconnected and the user logs off, which results in the server discarding that client's UID. If the client should reconnect, the user is again prompted for credentials because the UID assigned during the last session no longer exists.

Connection Management

CIFS provides mechanisms that allow for efficient disconnections when a client and server have completed all session traffic or when a connection is lost or malfunctioning. A client can issue a connection request only once to a CIFS server in any given session. If the CIFS server receives another connection request from a client with whom it already has an established session, the server disconnects the original session with the client to help ensure that a client that was unexpectedly disconnected from its session can effectively establish another session with the server. If a client is generating malformed or illegal requests to the CIFS server, the server can issue an error to the client and then disconnect the session, again potentially allowing the client to correct the problem and reconnect. A server can also disconnect a session with a client in the case of hard transport errors or if the client has been inactive for a long period of time and the server needs the connection.

File and Printer Access

After a client has established an SMB session with a CIFS server, the client can begin requesting files by issuing open SMBs to the server for the files it wishes to access. A file can be opened for read access, write access, or both. Accessing a printer is accomplished using a read request to the printer. Printing is accomplished using a write request to the printer.

Distributed File System Operations

Any client and CIFS server that supports dialects NT LM 0.12 and later supports Dfs operations. Using Dfs, the CIFS server can represent multiple shares on multiple servers in a single namespace that appears to the client to be located on a single server. The CIFS server can redirect the client software to another location on the network to access a resource, but the client will believe the resource is local to the server with which it originally negotiated a connection.

When a client wants to access a file that is contained in a Dfs share, it will issue a normal set of SMBs, because the client is not initially aware that part of a file path represents a Dfs share. The client sets a flag in the request SMB header indicating that the client wants the server to resolve this SMB's paths within the Dfs known to the server. The server then attempts to resolve the requested name to a file contained within the local directory tree indicated by the TID of the request. If this succeeds, then processing proceeds normally. If, however, the request path name resolves to a file on a different system, the server returns the error STATUS_DFS_PATH_NOT_COVERED. This indicates that the server does not support the part of the Dfs namespace needed to resolve the path name in the request. The client should request a referral from this server for further information.

The client can then ask for a referral using the TRANS2_DFS_GET_REFERRAL request containing the Dfs path name of interest. The response from the server indicates the server and share that the Dfs client should now attempt to access.

Read-Ahead and Write-Behind

To improve performance, CIFS supports read-ahead and write-behind operations. Read-ahead allows a client to cache read data locally so that it does not have to incur traffic over its connection to the server to obtain the next block of data it wants to read. Write-behind allows a client to perform and cache write operations on a file that then can be uploaded to the server, rather than having to submit each read/write operation separately.

Files on the server can also be called locked or unlocked. An unlocked file is a file to which no client has been granted exclusive access for either read or write purposes. CIFS supports caching, read-ahead, and write-behind, even for unlocked files, because the files are said to be "safe" as long as no client is actively writing to the file. If a client wants to write to a file, it must either submit the write data to the server for the server to write, or it can request a lock from the server.

Opportunistic Locks

When a client is actively writing to a file on the server, it can be more efficient for the client to locally buffer its data and submit it as a batched request. However, this increases the possibility that the same file might be opened by another client and data might also be written by that client. To help a client increase the efficiency of its data buffering, CIFS allows for opportunistic locks (referred to as oplocks), which allow the client to "lock" the file, or part of a file, so that it can't be written to simultaneously by another client. The following are three types of oplocks used in CIFS:

  • Exclusive oplocks In an exclusive oplock, a client (Client A) requests exclusive access to a file, where Client A is the only client permitted to write data to the file. When Client A opens the file, it requests an exclusive oplock from the server. If another client (Client B) has already opened the file, the server refuses to issue the oplock to the requesting client (Client A). When this occurs, Client A is does not buffer any data and does not perform any read-ahead. If there are no other clients currently accessing the file, the exclusive oplock will be granted to Client A and it can both read-ahead and buffer data that is to be written to the file. If Client C opens the file while Client A has an exclusive oplock, the server instructs Client A to break its lock. Breaking the lock requires Client A to submit any buffered lock or write data it's currently holding, acknowledge receipt of the notification, and purge its read-ahead buffer so that the file can be released for access by Client C.
  • Level II oplocks Level II oplocks allow multiple clients to open the same file, provided that no client is writing to that file. In a level II oplock, Client A can open a file and request an exclusive oplock to it. If it is the only client accessing the file, the server grants the oplock. When Client B requests access to the same file, the server contacts Client A and requests that it break its lock to a level II oplock if Client A hasn't been writing to the file. This is a result of the fact that some down-level client applications request read/write access to files even when they don't intend to perform write operations. After the server has synchronized with Client A to ensure that Client A has no locked buffer data, access to the file is granted to Client B at a level II oplock status. This informs Client B that it can't buffer any locks to the file, although it has been granted access. Either client can eventually write to the file; should this occur, the server notifies all level II oplock clients to break their locks, thus allowing the data to be written by a single client and ensuring that the server does not have to synchronize with all connected clients to allow this.
  • Batch oplocks Batch oplocks are commonly used by applications that run command batches requiring them to repeatedly open and close multiple files to read and execute their command sequences. When Client A wants to obtain a batch oplock to server files, it requests the oplock from the server. If other clients do not have the files open, the batch oplock is granted. Client A can now open the files, leave them open while executing its command sequences, and buffer data as needed. If Client B requests access to one of the files while Client A has a batch oplock, the server notifies Client A to clean up its data and synchronize with the server. In most cases, this results in Client A finishing its current batch operation and closing the file in question, allowing Client B to open the file.


Introduction to Internet Printing

Internet printing in the Windows Server 2003 family allows you to install, use, and monitor a printer over an internet. This can, but probably will not include the Internet and might include using a corporate intranet. Using IPP, you can install a printer using a Web browser or the Add Printer Wizard, but you can specify a Uniform Resource Locator (URL) or IP address instead of a Universal Naming Convention (UNC) path to the printer. When submitting a print request, the user can then use the installed printer interface to print directly to the URL. The print server must, however, be running IIS to accept these print requests. Because the print server uses the HTTP functionality of IIS, it can return information regarding the print job in browser-ready format. The underlying protocol that allows Internet printing to function is the IPP, which is sent encapsulated in an HTTP/1.1 request to the print server. The implementation of IPP in the Windows Server 2003 family is unchanged, functionally, from IPP in Windows 2000.

IPP Operation

IPP is defined in the following RFCs:

  • RFC 2567, Design Goals for an Internet Printing Protocol This RFC looks at the features that would be needed in a printing protocol for the Internet.
  • RFC 2568, Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol This RFC provides a high-level overview to the functions and features of IPP.
  • RFC 2911, Internet Printing Protocol/1.1: Model and Semantics This RFC describes IPP from a high-level viewpoint.
  • RFC 2910, Internet Printing Protocol/1.1: Encoding and Transport This RFC formally maps IPP onto HTTP/1.1 and defines the encoding rules for a new Internet Multipurpose Internet Mail Extensions (MIME) media type called application/ipp.
  • RFC 2569, Mapping between LPD and IPP This RFC gives some advice to implementers of gateways between IPP and line printer daemon (LPD) implementations.

IPP presents a very simplified model of printing that can be implemented on top of a variety of architectures. IPP defines two principal objects as the basis for Internet printing: a printer and a job. The printer object is the server-side component of the IPP protocol. In the Windows Server 2003 family, the IPP printer can be any printer that is installed on a computer running IIS. IPP also requires an underlying directory that can be used to store and retrieve definitions of IPP printers. However, the printer object shouldn't be confused with the output device. The output device is the physical device, which can be a simple printer, fax printer, or software, such as desktop publishing programs, document archive software, or a CD writer. The physical output device does not need to be IPP-aware or IPP-compliant as long as the printer object (the IPP server) handles the IPP.

With the Windows Server 2003 family, a user can query the Active Directory service to locate a printer object based on a printer's attributes, such as its location or capabilities. When a user sends a document for printing using IPP, the client computer submits the document as a print job, which contains a listing of the document's print attributes. The print submission is sent to the printer object, which validates the submission's attributes and creates a new job object. The newly created job object can then be queried. This facilitates reporting on print status and errors.

An IPP client is a computer running an HTTP/1.1-compatible browser, such as Microsoft Internet Explorer, and an installed printer software interface representing the print object. The user at the client computer installs the printer by entering its URL or IP address in either a Web browser or the Add Printer Wizard. After the printer has been added on the client computer, the user can submit print jobs from any application as if the printer were a network printer. When you try to print from a Windows Server 2003 client, the client attempts to use normal SMB print sharing before using IPP.

When you are printing, the client IPP software processes the print job in the appropriate format for the printer object. The IPP client then submits the job as an encapsulated HTTP/1.1 request to the printer object, which might be a print server or the actual output device. RFC 2566 specifies three different scenarios for setup of the printer objects and output devices. Figures 19-2, 19-3, and 19-4 diagram each of these scenarios.

Hosted Printing

In hosted printing, the IPP client sends a print job to the printer object, which is represented in Active Directory. The client locates the printer object by querying Active Directory for printers that are capable of specific functionality. However, queries for dynamic information, such as job status and queue length, are submitted to the printer object itself. The printer object in this scenario, as shown in Figure 19-2, is a print server running the IPP service (IIS, for example). The output device is a physical print device or software application that can be installed directly on the print server network. The output device does not need to support any IPP functionality, because the printer object, in this case the IIS server, performs all processing related to IPP and sends the job to the output device as it would any locally submitted print job. The printer object is also responsible for providing status monitoring and notification functionality to the requesting client using HTTP/1.1, which is why the server must be running IIS to serve as an IPP printer object.

Figure 19-2. IPP hosted printing.

Fan Out Printing

Fan out printing is very similar to hosted printing, except that the print object can transparently direct the print job to any of a number of physical output devices (as shown in Figure 19-3). These devices can be physical print devices, fax printers, or software on the local computer or another computer on the network. As with hosted printing, the output device does not need to use IPP, because the IPP server or printer object handles that functionality. Client queries relating to job status are submitted to the printer object, not to the output devices.

Figure 19-3. IPP fan out printing.

Embedded Printing

In embedded printing, the printer object and the output device are the same entity, and might or might not be represented in Active Directory. Unlike hosted and fan out printing, there is no intermediary server acting as the print object and print server for the output device (as shown in Figure 19-4). Embedded printing requires that the output device be capable of receiving and processing IPP client requests, as well as returning information to the client over HTTP. Therefore, this implementation requires additional functionality on the part of the output device, which is already provided by some printer vendors.

Figure 19-4. IPP embedded printing.

IPP Specifications

IPP structure and semantics are defined in a series of RFCs, as noted earlier in this chapter. The IPP specifications define two layers to the protocol: transport and operation. The transport layer of the protocol consists of HTTP/1.1 requests and responses, defined in Chapter 21, "Internet Information Services (IIS) and the Internet Protocols." The operation layer is a message body embedded in the HTTP/1.1 requests and responses. Each request or response message contains a sequence of attributes that describe the capabilities and characteristics of the objects involved in the printing operation. These object attributes are as follows:

  • Printer attributes Printer object attributes fall into two categories: printer description attributes and printer job template attributes. Printer description attributes are those that define properties, such as the printer object's location and state. Printer job template attributes describe the printer object's capabilities, such as the types of jobs it can handle and its default settings.
  • Job attributes Job attributes are properties of a print job that has been processed by the printer object and assigned to a job object. Job attributes can come from job template attributes, or attributes that the client submits to override default printer job template attributes. For example, a printer object can, by default, assign a specific priority to a print job. However, for a particular job, the client might need to override these defaults. Job attributes can also be job description attributes, which provide parameters, such as the job's size, state, and identification. Clients provide some job description attributes when they request the print job, and other attributes are provided by the print object as it processes the print request. For example, a requesting client can provide information regarding the number of pages in a print request (client-side job description attributes), and the printer object can assign a job a Uniform Resource Identifier (URI) when it accepts the job for printing (server-side job description attributes).
  • Operation attributes Unlike printer object and job object attributes, which provide characteristics relating to the objects involved in a print transaction, operation attributes describe the transaction itself. These attributes identify properties, such as where the job is being sent and what localization parameters might need to be defined in the transaction.
  • Unsupported attributes Because IPP attributes are extensible, a client from a particular vendor can issue a request containing attributes that are only supported by the print object provided by the same vendor. If the same attributes are sent to an IPP of another vendor, then these attributes might not be supported. If this is the case, the IPP server returns a message to the client listing which attributes it does not support. This enables the IPP client to issue only those requests that the print object can fulfill. This process allows the client and server to "negotiate" job parameters during the request and response sequences.
IPP structure and semantics are defined primarily in RFCs 2565 and 2566, which can be found in the \Rfc folder on the companion CD-ROM.

IPP Request/Response Mechanisms

IPP operations are passed between client and server as a series of HTTP/1.1 request and response messages. When a client submits a print request to a print object (IPP server), the client sends a request message to the printer object URI. This message contains operation attributes, object attributes, and the document to be printed. Each request message is followed by a response message from the IPP server. The response message contains a code indicating the success or failure of the requested operation, as well as operation attributes, object attributes, and status messages that the server generated.

After the server has accepted the print request and created a job object with its own URI, the client can request the addition of further documents to the same job object. Although a printer is not required to support job objects that contain more than one document, allowing the submission of multiple documents to a single job object increases printing efficiency and allows print requests to be "batched." Because each job object can be queried, the client can use a single job URI to obtain status reports on multiple documents if the server supports this mechanism.

Each operation request issued by the IPP client must contain a Version-Number, an Operation-ID, a Request-ID, and any attributes required by the specific request type. Each server response message must contain a Version-Number, a Status-Code, the Request-ID that the client issued, and any attributes that are specific to that request type. Figure 19-5 illustrates the format for these requests and responses.

Figure 19-5. Request/Response format.

As Figure 19-5 demonstrates, the Version-Number is the version identifier for the request/response sequence. The Operation-ID is used in a request message to specify what operation the client wants to request of the print object, and the Status-ID is sent in the server's response message to indicate whether that operation was successfully received and processed. The Request-ID is used to assign a number to the request for tracking purposes. The 1-byte Attributes field identifies the type of attributes being sent in this request or response message (printer, job, operation, or unsupported), and the variable-length Attributes sequence lists the attributes particular to that type. The end of the Attributes sequence is indicated by a 1-byte End-Of-Attributes tag, and the remaining bytes might or might not consist of the actual print data being sent.

Operations

An IPP client requests submission of a print job by sending an HTTP Request message containing an operation request and attributes to the printer's URI. The printer uses the information provided by the client to construct a new job object, the URI of which is then passed back to the client so that the client can use it for purposes of querying or adding to the job. IPP version 1 defines certain operations, listed in Table 19-5, which can be requested of a printer or a job.

Table 19-5. IPP Operations
Operation | Type (Printer or Job) | Description
Print-Job | Printer | Required. Allows a client to submit a print job and supply the document data, which is not considered a separate rate object and therefore has no attributes of its own. Includes the operation attributes, character set and natural language attributes, and printer URI.
Print-URI | Printer | Identical to a Print-Job operation except that the client supplies a job URI reference to the print data as opposed to submitting the data itself. The printer then validates the job URI before responding to the client.
Validate-Job | Printer | Required. Similar to a Print-Job operation except that no data is supplied in the request/response process. The client uses it to verify that a print job submitted to this printer would be accepted and processed.
Create-Job | Printer | Similar to Print-Job, except that the client sends no document data in the operation, but issues attributes for multiple print requests to submit them to a single job object.
Get-Printer-Attributes | Printer | Required. Allows the client to request printer attributes to determine the capabilities of the printer.
Get-Jobs | Printer | Required. Allows the client to request a list of job objects owned by the printer object.
Send-Document | Job | Allows the client to send a multidocument job object request, so that multiple requests can be submitted under a single job.
Send-URI | Job | Identical to the Send-Document operation, except that the client supplies a document URI operation attribute rather than the document data itself.
Cancel-Job | Job | Required. Allows a client to request cancellation of a print job.
Get-Job | Job | Required. Allows a client to request the attributes of the Attributes job object identified in the message.

Each of these operations can be sent as part of either a request or response message between IPP client and printer. Each operation includes attributes that identify the details of the request or response. Printer attributes can be sent as part of a printer operation message, and job object attributes can be sent as part of a job operation.

Attributes

Attributes are extensible characteristics or properties of any object in IPP, such as printer objects, job objects, and operations. Attribute specifications include the name of the attribute, followed by its syntax in parentheses. Tables 19-6, 19-7, 19-8, and 19-9 describe these attributes.

Table 19-6. IPP Operation Attributes
Attribute | Description
Attributes-charset | Required. Must be supplied as the first attribute in any request or response to define the character set that the client or the IPP server uses.
Attributes-natural-language | Required. Must be supplied as the second attribute in any request or response message to define the natural language that the client or IPP server uses.
Table 19-7. IPP Job Template Attributes
Attribute | Description
Job-priority (integer (1:100)) | Priority for job scheduling; 1 is the lowest priority and 100 is the highest.
Job-hold-until (type3 keyword | name (MAX)) | Named time frame during which the job must become eligible for printing; values include the following: no-hold (immediately); day-time (during the day); evening (evening); night (night); weekend (weekend); second-shift (after close of business); third-shift (after midnight); and indefinite.
Job-sheets (type3 keyword | name (MAX)) | Job start/end sheets that must be printed with the job (if any). Keyword values: none (no job sheet printed); standard (site-specific standard sheets are printed,administrator-defined values).
Multiple-document handling (type2 keyword) | If a job consists of more than one document, this controls the placement of pages onto media sheets (such as large sheets of paper used in commercial printing). Keywords: single-document (multiple documents must be treated as a single media sheet); separate-documents-uncollated-copies (each document is treated as a single, noncollated media sheet); separate-documents-collated-copies (each document is treated as a single media sheet and the media sheets are collated); single-document-new-sheet (each document instance in the job must be forced onto a new sheet).
Copies (integer (1:MAX)) | Number of copies to be printed, ranging from 1 through the maximum number supported by the output device (such as number of collation trays for collated copies, or the maximum number of noncollated copies allowed by the output device).
Finishings (1setOf type2 enum) | Identifies the finishing operations used for each copy of each document in the job. Enum values: 3 = no finishing; 4 = staple; 5 = punch; 6 = cover (used to specify a cover sheet); 7 = bind (specifies site-defined binding operations).
Page-ranges (1setOf rangeOfInteger (1:MAX)) | Range of pages to be printed for a document. A page range of 1:5, 24:24 would specify pages 1-5 and page 24 should be printed.
Page-ranges-supported (Boolean) | Indicates whether the printer supports printing of ranges (0 = No, 1 = Yes).
Sides (type2 keyword) | Specifies whether printing is one-sided or two-sided. Keyword values: one-sided; two-sided-long-edge; duplex or head-to-head; two-sided-short-edge.
Number-up (integer (1:MAX)) | Number of pages to place on a single side of the selected medium.
Orientation-requested (type2 enum) | Page orientation, such as portrait, landscape, reverse landscape, or reverse portrait (used in commercial printing).
Media (type3 keyword | name (MAX)) | Media type used by the printer, such as paper type, paper size, paper tray, or electronic form.
Printer-resolution (resolution) | The resolution used by the printer for the job.
Print-quality (type2 enum) | Print quality used by the printer for the job. Enum values: 3 = draft; 4 = normal; 5 = high.
Table 19-8. IPP Job Description Attributes
Attribute | Description
Job-uri (URI) | Required. The URI for this print job.
Job-id (integer (1:MAX)) | Required. Job ID generated by the print object on receipt of a new job and returned to the requesting client for identification purposes.
Job-printer-uri (URI) | Required. Identifies the printer object that created the job object.
Job-more-info (URI) | Contains the URI referencing a resource that has more information about the job object (such as a Hypertext Markup Language [HTML] page listing job status information).
Job-name (name (MAX)) | Required. User-friendly name assigned to the print job. Generated by the print object and returned to the client.
Job-originating-user-name (name (MAX)) | Required. Name of the user who submitted the print job. Can be used for authentication purposes in access-controlled print environments.
Job-state (type1 enum) | Required. Identifies the current job state. Values: 3 = pending; 4 = pending-held; 5 = processing; 6 = processing-stopped; 7 = canceled; 8 = aborted; 9 = completed.
Job-state-reasons (1setOf type2 keyword) | Provides additional information about the job-state attribute, such as none, job-incoming, submission-interrupted, job-outgoing, and so forth.
Job-state-message (text (MAX)) | Job-state and job-state-reasons information provided in friendly message format.
Number-of-documents (integer (0:MAX)) | Indicates the number of documents in the job.
Output-device-assigned (name (127)) | Identifies the output device to which the printer object assigned the print job. If this is an embedded printer object, this attribute is unnecessary.
Time-at-creation (integer (0:MAX)) | Time at which the job object was created.
Time-at-processing (integer (0:MAX)) | Time at which the job object began processing.
Time-at-completed (integer (0:MAX)) | Time at which the job object was completed, canceled or aborted.
Number-of-intervening-jobs (integer (0:MAX)) | The number of jobs "ahead" of this job in the queue.
Job-message-from-operator (text (127)) | Message sent to the client from an operator or administrator of the printer.
Job-k-octets (integer (0:MAX)) | Total size in k octets (units of 1024 octets, or kilobytes) of the document.
Job-impressions (integer (0:MAX)) | Total size of the document in number of impressions (pages as chosen by the client, such as letter or legal).
Job-media-sheets (integer (0:MAX)) | Total number of media sheets to be produced for the job.
Job-k-octets-processed (integer (0:MAX)) | The total number of k octets processed so far.
Job-impressions-completed (integer (0:MAX)) | Number of impressions completed, which includes interpreting, marking, and stacking the output, and both sides of the impression.
Job-media-sheets-completed (integer (0:MAX)) | The media sheets completed for the job, whether both sides of the sheet have been processed or not.
Attributes-charset (charset) | Required. Identifies the character set used in the job.
Attributes-natural-language (naturalLanguage) | Required. Identifies the natural language of the job (English, French, and so forth).
Table 19-9. IPP Printer Description Attributes
Attribute | Description
Printer-uri-supported (1setOf uri) | Required. Contains one or more URIs used to submit print jobs to this print object. Multiple URIs allow the print object to be represented as multiple objects in a directory service, but represent a single IPP server.
Uri-security-supported (1setOf type2 keyword) | Required. Identifies the security mechanisms for each of the URIs that identify a printer object (such as none or SSL3).
Printer-name (name (127)) | Required. Friendly name of the printer object.
Printer-location (text (127)) | Friendly text identifying the location of the printer.
Printer-info (text (127)) | Friendly description of the printer.
Printer-more-info (URI) | Specifies a URI where more information about the printer can be obtained, such as an HTML page listing the printer's capabilities.
Printer-driver-installer (URI) | URI used to locate the driver installer for the printer object.
Printer-make-and-model (text (127)) | The make and model of the printer object.
Printer-more-info-manufacturer (URI) | Manufacturer's information about this printer.
Printer-state (type1 enum) | Required. Identifies whether the printer is idle, pending, processing, or stopped.
Printer-state-reasons (1setOf type2 keyword) | Provides more information about the reported state of the printer, such as paused or shutdown.
Printer-state-message (text (MAX)) | Friendly message that represents the printer state to the user.
Operations-supported (1setOf type2 enum) | Required. Operations that are supported by the printer for its job objects.
Charset-configured (charset) | Required. The configured character set of the printer.
Charset-supported (1setOf charset) | Required. A list of character sets supported by the printer.
Natural-language-configured (naturalLanguage) | Required. The configured natural language of the printer.
Generated-natural-language- supported (1setOf naturalLanguage108) | Required. A list of natural languages supported by the printer.
Document-format-default (mimeMediaType) | Required. The default document format that the printer assumes if the client does not specify a particular format.
Document-format-supported (1setOf mimeMediaType) | Required. MIME media types supported by the printer.
Printer-is-accepting-jobs (Boolean) | Required. Indicates whether the printer is currently accepting job requests.
Queued-job-count (integer (0:MAX)) | Recommended. The number of jobs in the print queue for this printer object.
Printer-message-from-operator (text (127)) | Text sent from an administrator or operator to the client.
Color-supported (Boolean) | Indicates whether the printer is capable of color printing.
Reference-uri-schemes- supported (1setOf uriScheme) | List of URI schemes that the printer can accept jobs from, such as FTP and HTTP.
Pdl-override-supported (type2 keyword) | Required. Specifies whether the printer object is capable of overriding document defaults as supplied by the application that requested the print job with IPP settings.
Printer-up-time (integer (1:MAX)) | Required. Amount of time, in seconds, that the printer has been up and running.
Printer-current-time (dateTime) | The current date and time where the printer is located.
Multiple-operation-time-out (integer (1:MAX)) | Maximum time, in seconds, that the printer waits for additional instructions on a multidocument job before taking recovery action.
Compression-supported (1setOf type3 keyword) | Printer-supported HTTP compression types, such as none, gzip, deflate, and compress.
Job-k-octets-supported (rangeOfInteger (0:MAX)) | Upper and lower boundaries of k octets that the printer can accept in a single job.
Job-impressions-supported (rangeOfInteger (0:MAX)) | Upper and lower bounds for the number of impressions per job.
Job-media-sheets-supported (rangeOfInteger (0:MAX)) | Upper and lower bounds of the number of media sheets supported per job.

Internet Printing Security

Because a printer object can be represented by more than one URI, an administrator has very flexible control options. For example, a printer can be represented by one URI that accepts unsecured HTTP connections and another URI that only accepts Secure Sockets Layer (SSL) connections. The printer administrator can grant specific permissions to each of the URIs, thereby permitting some clients to print over an unsecured connection and forcing others to print only over a secured connection. Additionally, because the printer object can be published in Active Directory, all Windows 2000 security mechanisms can be applied to the printer. Although IPP provides mechanisms for printing using HTTP, it does not provide full file-sharing functionality; CIFS provides that functionality.


Summary

CIFS enables platform-independent file and printing sharing sessions to be established between a client and a server over the Internet or an intranet. CIFS clients use these connections to access file and print resources including Dfs. IPP can extend the functionality and ease of printing in the Windows Server 2003 family. Using IPP, installing and using a printer can be as simple as typing a URL into a Web browser. The IPP functions of IIS also allow you to query individual printers and to view and manage the printer queue using an Internet browser.


RADIUS and Internet Authentication Service

Chapter 20
RADIUS and Internet Authentication Service

Internet service providers (ISPs) and other larger organizations have the challenge of managing all types of network access and network accounting from a single point of administration, regardless of the type of network access equipment used.

RFC 2865 and RFC 2866 define the Remote Authentication Dial-In User Service (RADIUS) protocol. The RADIUS protocol carries authentication, authorization, configuration, and accounting information between a network access server (NAS) or any other similar device that needs to authenticate, authorize, and account for the usage of the device, and shared authentication and accounting servers.

RADIUS clients communicate with a RADIUS server over User Datagram Protocol (UDP) ports 1812 and 1813, although earlier versions of RADIUS used UDP ports 1645 and 1646. RADIUS is not supported over TCP.


RADIUS and IAS Server in Windows Server 2003

With RADIUS, a device such as a NAS can be configured to authenticate and authorize a user of its services through the use of the RADIUS protocol. An ISP, for example, needs to authenticate the user of a dial-in network port and then ensure that this user is authorized to use the port. The NAS might also need to get configuration information for this connection, which the RADIUS server can be configured to provide. Once a connection has commenced, the NAS device might need to provide accounting information that can be used for charge-back purposes. These RADIUS access control and accounting functions are shown in Figure 20-1.

Figure 20-1. Overview of RADIUS.

To support more complex networking architectures, you can deploy a RADIUS proxy, which receives RADIUS information from a RADIUS client and relays it to a RADIUS server. RADIUS server responses are sent to the client via the RADIUS proxy. The RADIUS proxy functions are shown in Figure 20-2. Note that both authorization and accounting information can be transferred using a RADIUS proxy.

Figure 20-2. The RADIUS proxy functions.

In the Microsoft Windows Server 2003 family, the Internet Authentication Service (IAS) implements an RFC-compliant RADIUS server and proxy. In Microsoft Windows 2000, IAS only implements the RADIUS server features. In addition, Windows Server 2003 servers running the Routing and Remote Access service can be configured to be a RADIUS client, enabling dial-in or virtual private network (VPN) clients to be authenticated using a RADIUS server.

The RADIUS server component of IAS can authenticate RADIUS client requests against a local account database, a Windows NT 4.0 domain, or Active Desktop. IAS saves RADIUS accounting details, provided by the RADIUS client, to either a text file or a Structured Query Language (SQL) database. The RADIUS proxy feature in IAS can forward both authentication and accounting messages to other RADIUS servers. IAS fully supports the Internet Engineering Task Force (IETF) standards for RADIUS described in RFCs 2865 and 2866. You can configure an IAS server to handle authentication (including authorization), accounting, or both, and you can configure your RADIUS clients or RADIUS proxies to use additional servers for fault tolerance.

IAS has access to user account information held either on the IAS server or from a domain controller (if the IAS server is a member of a domain). This enables the IAS server to check network access authentication credentials and dial-in properties of accounts and, as appropriate, authorize and configure the connection. If configured, a RADIUS client can also log details of the connection for accounting purposes.

Access and accounting transactions between client and server are authenticated and secured through the use of a shared secret. This shared secret is never sent on the wire but is used in conjunction with the Authenticator field to provide a level of security over the RADIUS message. If additional security is required, the RADIUS server and client could use IPSec to encrypt RADIUS messages, although this is outside the scope of the RADIUS protocol.


RADIUS in Operation

The operation of RADIUS uses a simple client/server protocol, both for authorization and for accounting. The client sends information, encapsulated in UDP, to a server, which then responds as appropriate. There are some differences, however, as described in the following sections.

RADIUS Authentication

When a NAS or other device needs to authenticate and authorize a connection prior to allowing the connection to complete, the device must first obtain the user details with which to perform the authentication and authorization. The credentials for authorization can be obtained from a logon dialog box, where the user would enter a user name and a password, or by use of a link framing protocol, for example, Point-to-Point Protocol (PPP), which can carry authentication credentials from the client.

Once the NAS device has obtained the necessary authentication information, it constructs an Access-Request message and sends it to the RADIUS server. The Access-Request message contains one or more attributes, information that enables the RADIUS server to authorize the use of the NAS and to return certain configuration details for the connection. This information, contained within RADIUS message attributes, includes the user's name, password (which is encrypted), and a RADIUS client port identifier.

After sending the Access-Request message to the server, the RADIUS client waits for a response. If no response is received within a certain amount of time, the RADIUS client retransmits it. A RADIUS client can additionally be configured with the address of multiple RADIUS servers and should the first configured server fail, the client can use a different server. This provides fault tolerance and delivers a measure of load balancing. RFC 2865 suggests that the alternate server can be used either after a number of tries to the primary server fail or using a round-robin scheme. The retry and fallback algorithms are not specified in RFC 2865 and are, at present, vendor-specific.

After the RADIUS server receives the Access-Request, it first validates the RADIUS client. An Access-Request message that is received from a RADIUS client for which the server is not configured is silently discarded. If the Access-Request message came from a valid RADIUS client, the server can then validate the connection and return an Access-Accept or Access-Reject message, based on the success or failure of the validation. The validation of a connection typically includes password verification, but can also be based on other information included in the Access-Request message, such as the NAS port that the connection request was received on or the type of connection.

When the RADIUS server returns an Access-Accept message, the server can return additional configuration information, specified as additional attributes. These can be generic RADIUS attributes or vendor-specific attributes used to configure a particular vendor's NAS (or other) device.

If the RADIUS server is unable to authenticate and authorize the connection, it sends an Access-Reject message back to the client saying that the connection request has failed. The client could then re-request user identity details or simply fail the initial service request. The RADIUS server can include a text message in the Access-Reject message.

RADIUS Accounting

The purpose of RADIUS accounting is to provide details of the resources used by the connections to a NAS to a central accounting server. RADIUS accounting is defined in RFC 2866.

Each service that the RADIUS client provides to an end user constitutes a session. The session begins when the service is first provided and completed when the service is ended. A NAS device, for example, provides a session for a dial-in user that begins once the authentication and authorization has been successfully negotiated and ends when the service ceases to be provided. An end user could have multiple parallel sessions active at the same time, for example using multilink remote access services with Integrated Services Digital Network (ISDN). The RADIUS accounting information can then be used for chargeback or for general usage analysis.

If a RADIUS client is configured to use RADIUS accounting, then it generates an Accounting Start message at the beginning of each session and an Accounting Stop message at the end. The Accounting Start message is used to describe the type of service being provided and to identify the user of the service. The Accounting Stop message contains usage statistics such as the total session time, the number of packets sent and received, and the number of octets sent and received.

The RADIUS server acknowledges receipt of the Accounting Start and Accounting Stop messages by sending the RADIUS accounting client an Accounting-Response message, which tells the accounting client that the Accounting-Request message has been received by the RADIUS accounting server. Unlike the Access-Accept message, an Accounting-Response message does not normally contain attributes.

If a RADIUS accounting server is unable to record the information in the Accounting messages, it does not send a response. If, for whatever reason, the client does not receive an Accounting Response message, the client retransmits the message at regular intervals until it receives an Accounting-Response message or a configured timeout period is reached. The RADIUS accounting client can also be configured to use additional servers to provide load balancing and fault tolerance.

RADIUS Proxy

A RADIUS proxy is a RADIUS server that can relay access and accounting messages from a RADIUS client to another RADIUS server, as previously illustrated in Figure 20-2. The RADIUS proxy forwards the request to a remote RADIUS server, receives the reply from the remote server, and sends that reply to the RADIUS client. A RADIUS proxy can be used to support dial-in user roaming. Roaming enables the user of one ISP to access another ISP's network. The RADIUS server at the called ISP can use a RADIUS proxy to forward the connection request to a RADIUS server at the user's home ISP. With roaming, a user can access multiple ISPs simultaneously, while maintaining a business client relationship with a single ISP. This can be highly useful for "road warriors" who need Internet access around the globe.

With RADIUS proxy, the NAS sends the RADIUS Access-Request message to the RADIUS proxy, which then forwards it to the target RADIUS server (for example, the user's home ISP). The target RADIUS server can then send appropriate responses (for example, Access-Accept, Access-Reject, and Accounting-Response messages) to the RADIUS proxy, which then sends the response to the NAS.

When a RADIUS proxy sends a message from a RADIUS client to a RADIUS server, it adds an additional attribute into the message, Proxy-State, which informs the server that the RADIUS message was received from a proxy and not from the RADIUS client. When the server sends a response back to the RADIUS proxy, this attribute is copied, unmodified, into the response. The RADIUS proxy removes this attribute when sending the response back to a client.

A server can function as both a RADIUS proxy and a RADIUS server, enabling the server to proxy some requests to a remote RADIUS server and process others locally. In addition, it is possible to have multiple proxies, as shown in Figure 20-3. If multiple proxies exist, each proxy server adds an additional Proxy-State attribute to the RADIUS message when it is passed toward the RADIUS server and removes this when responses are sent back to the original RADIUS client.

Figure 20-3. Multiple RADIUS proxies.

RADIUS Attributes

RADIUS clients and servers communicate by sending messages to each other. The specific message type is defined in the message header. The details of each message are contained as a set of three fields: type, length, and value 3-tuples. Each 3-tuple is collectively known as an attribute. An attribute's type and length fields have a fixed length, whereas the variable-length value field has its length indicated in the length field. An attribute represents a specific data item, such as a user name or the tunneling protocol in use, sent between the RADIUS client and server. RADIUS messages consist of a header followed by a variable number of attributes, where each attribute can be of a variable length. The structure of attribute fields is shown later in this chapter.

Two types of RADIUS attributes are contained in RADIUS messages: standard attributes and vendor-specific attributes. Standard attributes are defined in RFCs 2865 through 2869 and are used by all RADIUS clients and servers. Vendor-specific attributes are proprietary. Not all RADIUS clients and servers implement all vendor attributes.

Vendor-specific attributes are identified with a vendor attribute, which includes the vendor's enterprise number and a vendor attribute ID. The assigned enterprise numbers were originally defined in RFC 1700, but to avoid regular reissues of this RFC, vendor IDs are now specified at http://www.iana.org/assignments/enterprise-numbers. For example, Microsoft's enterprise ID is 0x137 (311 in decimal format). Microsoft-specific vendor extensions have been submitted for RFC status in RFC 2548, although this RFC documents earlier versions of RADIUS; extra attributes have been added in Window Server 2003 that are not described in RFC 2548.

If a RADIUS server cannot make use of a vendor-specific attribute, it is ignored. The RADIUS server can create log entries regarding the ignored attribute, but this is not required. If a RADIUS client receives a vendor-specific attribute that is not supported, the client should attempt to work without the information, although doing so could result in degraded service to the end user.


RADIUS in Windows Server 2003

The Windows Server 2003 family of products implements RADIUS client, server, and proxy functions. The Windows Server 2003 Routing and Remote Access service can be configured to be a RADIUS client, enabling authentication of dial-in and VPN clients against a RADIUS server. The IAS service in Windows Server 2003 provides both RADIUS server and proxy facilities.

RADIUS Authentication in Routing and Remote Access

The Routing and Remote Access service in Windows Server 2003 can be configured to perform authentication using RADIUS. When configured this way, the Routing and Remote Access service obtains the necessary user credentials through several PPP configurable authentication protocols and can then pass these details to the RADIUS server, along with other connection connection attributes.

The Routing and Remote Access service can also be configured to send authentication and accounting messages to multiple RADIUS servers. Microsoft's Routing and Remote Access service uses a proprietary scoring method to determine the RADIUS server to which RADIUS messages should be sent. In this scheme, the Routing and Remote Access service maintains a quality rating, known as the score, for each configured RADIUS server. It then uses the scores to determine the best RADIUS server to use at any given moment.

The scoring method used by Routing and Remote Access works as follows:

  • The client initially assigns each configured RADIUS server a default value of 30.
  • Each time a RADIUS message is sent to a RADIUS server and no response is received, the score decreases by 3, to a minimum of 0.
  • Each time a RADIUS message is sent to a RADIUS server and a response is received, the server's score is increased by 1, to a maximum of 30.
  • Routing and Remote Access service sends RADIUS messages to the RADIUS server that has the highest score.
  • If only one RADIUS server is configured, or if all servers are nonresponsive, Routing and Remote Access retransmits the RADIUS message every 5 seconds.

The administrator can configure Windows Server 2003 Routing and Remote Access service either to require no authentication or to authenticate the end user of a dial-in or VPN connection using the following protocols:

  • Password Authentication Protocol (PAP), which sends passwords unencrypted between the access client and the NAS
  • Shiva Password Authentication Protocol (SPAP)
  • Challenge Handshake Authentication Protocol (CHAP)
  • Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
  • Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2), which provides mutual authentication
  • Extensible Authentication Protocol (EAP), which supports authentication using an MD5 challenge, smart card, or certificate

The specific attributes transmitted by Routing and Remote Access service to the RADIUS server are based on the particular authentication protocol being used. You can see the attributes being exchanged in the following Network Monitor trace (Capture 20-01 in the \Captures folder on the companion CD-ROM). The following trace illustrates the Access-Request and Access-Accept messages sent between a Routing and Remote Access server and a Windows Server 2003 RADIUS server:

Frame   Time   Src MAC Addr   Dst MAC Addr   Protocol   Description   Src
Other Addr   Dst Other Addr   Type Other Addr

1   6.479317   005056404FAB   0050DABA49EE   RADIUS   Message Type: Access
Request(1)   10.10.1.150   10.10.1.201

+ IP: ID = 0x78A2; Proto = UDP; Len: 277

+ UDP: Src Port: Unknown, (3065); Dst Port: Unknown (1812); Length = 257 (0x101)

  RADIUS: Message Type: Access Request(1)

      RADIUS: Message Type = Access Request

      RADIUS: Identifier = 12 (0xC)

      RADIUS: Length = 249 (0xF9)

      RADIUS: Authenticator = DB 60 44 6A 2B 19 83 57 FF 75 F1 1D 19 2C 1A 7F

    + RADIUS: Attribute Type: NAS IP Address(4)

    + RADIUS: Attribute Type: Service Type(6)

    + RADIUS: Attribute Type: Framed Protocol(7)

    + RADIUS: Attribute Type: NAS Port(5)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: NAS Port Type(61)

    + RADIUS: Attribute Type: Tunnel Type(64)

    + RADIUS: Attribute Type: Tunnel Media Type(65)

    + RADIUS: Attribute Type: Calling Station ID(31)

    + RADIUS: Attribute Type: Tunnel Client Endpoint(66)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: User Name(1)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

************************************************************************************************************

Frame   Time   Src MAC Addr   Dst MAC Addr   Protocol   Description   Src
Other Addr   Dst Other Addr   Type Other Addr

2  6.549418  0050DABA49EE  005056404FAB  RADIUS  Message Type: Access
Accept(2)  10.10.1.201  10.10.1.150

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x9ABF; Proto = UDP; Len: 242

+ UDP: Src Port: Unknown, (1812); Dst Port: Unknown (3065); Length = 222 (0xDE)

  RADIUS: Message Type: Access Accept(2)

      RADIUS: Message Type = Access Accept

      RADIUS: Identifier = 12 (0xC)

      RADIUS: Length = 214 (0xD6)

      RADIUS: Authenticator = 5F C7 93 40 22 EA 31 7A A3 4F 82 B1 FA DE 15 77

    + RADIUS: Attribute Type: Framed Protocol(7)

    + RADIUS: Attribute Type: Service Type(6)

    + RADIUS: Attribute Type: Class(25)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

As noted in this trace, the Routing and Remote Access service sends both standard and vendor attributes in the Access-Request message and receives a combination in the Access-Accept message. The specific attributes sent by Routing and Remote Access service are based on the specific method used for authentication (the preceding example was based on a connection using PAP).

The following trace (part of Capture 20-02 in the \Captures folder on the companion CD-ROM) illustrates an Access-Reject message being returned to the RADIUS client denying the attempted connection:

Frame   Time   Src MAC Addr   Dst MAC Addr   Protocol   Description   Src Other Addr   Dst
Other Addr   Type Other Addr

1  22.001636  005056404FAB  0050DABA49EE  RADIUS  Message Type: Access
Request(1)  10.10.1.150  10.10.1.201

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x72D9; Proto = UDP; Len: 277

+ UDP: Src Port: Unknown, (2938); Dst Port: Unknown (1812); Length = 257 (0x101)

  RADIUS: Message Type: Access Request(1)

      RADIUS: Message Type = Access Request

      RADIUS: Identifier = 7 (0x7)

      RADIUS: Length = 249 (0xF9)

      RADIUS: Authenticator = 96 54 C5 23 F6 5E 17 1E C3 0D 07 7A 17 7C 40 77

    + RADIUS: Attribute Type: NAS IP Address(4)

    + RADIUS: Attribute Type: Service Type(6)

    + RADIUS: Attribute Type: Framed Protocol(7)

    + RADIUS: Attribute Type: NAS Port(5)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: NAS Port Type(61)

    + RADIUS: Attribute Type: Tunnel Type(64)

    + RADIUS: Attribute Type: Tunnel Media Type(65)

    + RADIUS: Attribute Type: Calling Station ID(31)

    + RADIUS: Attribute Type: Tunnel Client Endpoint(66)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: User Name(1)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

*************************************************************************************************************

2  22.011651  0050DABA49EE  005056404FAB  RADIUS  Message Type: Access
Reject (3)  10.10.1.201  10.10.1.150

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x2EA; Proto = UDP; Len: 70

+ UDP: Src Port: Unknown, (1812); Dst Port: Unknown (2938); Length = 50 (0x32)

  RADIUS: Message Type: Access Reject(3)

      RADIUS: Message Type = Access Reject

      RADIUS: Identifier = 7 (0x7)

      RADIUS: Length = 42 (0x2A)

      RADIUS: Authenticator = 14 BF A3 62 F1 6C 88 42 19 A8 8C 3F 4F 83 7F 4C

    + RADIUS: Attribute Type: Vendor Specific(26)

RADIUS Accounting in Windows Server 2003

The Routing and Remote Access service can be configured to send accounting messages to a RADIUS server independently of how user authentication and authorization are performed; the Routing and Remote Access service can be configured to use Windows for authentication and authorization and use RADIUS for accounting. The start and stop of each session, for accounting purposes, is indicated by an Accounting-Request message: the value of the Acct-Status-Type attribute defines if the accounting request is for the start or stop of a connection.

The following trace (Capture 20-03 in the \Captures folder on the companion CD-ROM) shows the messages exchanged at the start and end of a VPN connection. Routing and Remote Access service transmits an accounting request message when the VPN connection is created and another message when the VPN connection is dropped:

Frame   Time   Src MAC Addr   Dst MAC Addr   Protocol   Description   Src
Other Addr   Dst Other Addr   Type Other Addr

1  10.314832  005056404FAB  0050DABA49EE  RADIUS  Message Type: Accounting
Request(4)  10.10.1.150  10.10.1.201

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x78B3; Proto = UDP; Len: 303

+ UDP: Src Port: Unknown, (3066); Dst Port: Unknown (1813); Length = 283 	(0x11B)

  RADIUS: Message Type: Accounting Request(4)

     RADIUS: Message Type = Accounting Request

     RADIUS: Identifier = 3 (0x3)

     RADIUS: Length = 275 (0x113)

     RADIUS: Authenticator = EA BB 33 E2 85 8D F8 D5 A6 5C 40 76 54 73 49 09

   + RADIUS: Attribute Type: Acct Status Type(40)

   + RADIUS: Attribute Type: Acct Delay Time(41)

   + RADIUS: Attribute Type: NAS IP Address(4)

   + RADIUS: Attribute Type: Service Type(6)

   + RADIUS: Attribute Type: Framed Protocol(7)

   + RADIUS: Attribute Type: NAS Port(5)

   + RADIUS: Attribute Type: Vendor Specific(26)

   + RADIUS: Attribute Type: Vendor Specific(26)

   + RADIUS: Attribute Type: NAS Port Type(61)

   + RADIUS: Attribute Type: Tunnel Type(64)

   + RADIUS: Attribute Type: Tunnel Media Type(65)

   + RADIUS: Attribute Type: Calling Station ID(31)

   + RADIUS: Attribute Type: Tunnel Client Endpoint(66)

   + RADIUS: Attribute Type: Vendor Specific(26)

   + RADIUS: Attribute Type: Vendor Specific(26)

   + RADIUS: Attribute Type: Class(25)

   + RADIUS: Attribute Type: Vendor Specific(26)

   + RADIUS: Attribute Type: Acct Session ID(44)

   + RADIUS: Attribute Type: User Name(1)

   + RADIUS: Attribute Type: Framed IP Address(8)

   + RADIUS: Attribute Type: Framed MTU(12)

   + RADIUS: Attribute Type: Acct Multi-Session ID(50)

   + RADIUS: Attribute Type: Acct Link Count(51)

   + RADIUS: Attribute Type: Unknown(55)

   + RADIUS: Attribute Type: Acct Authentic(45)

   + RADIUS: Attribute Type: Vendor Specific(26)

*******************************************************************************************************************

2  10.324846  0050DABA49EE  005056404FAB  RADIUS  Message Type: Accounting
Response(5)  10.10.1.201  10.10.1.150

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x9C57; Proto = UDP; Len: 48

+ UDP: Src Port: Unknown, (1813); Dst Port: Unknown (3066); Length = 28 (0x1C)

  RADIUS: Message Type: Accounting Response(5)

     RADIUS: Message Type = Accounting Response

     RADIUS: Identifier = 3 (0x3)

     RADIUS: Length = 20 (0x14)

     RADIUS: Authenticator = F0 A9 27 34 0D 42 36 4B 7E C7 8A 83 E4 B6 98 41

******************************************************************************************************************

3  21.160427  005056404FAB  0050DABA49EE  RADIUS  Message Type: Accounting
Request(4)  10.10.1.150  10.10.1.201

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x78CD; Proto = UDP; Len: 339

+ UDP: Src Port: Unknown, (3068); Dst Port: Unknown (1813); Length = 319 	(0x13F)

  RADIUS: Message Type: Accounting Request(4)

     RADIUS: Message Type = Accounting Request

     RADIUS: Identifier = 4 (0x4)

     RADIUS: Length = 311 (0x137)

     RADIUS: Authenticator = D1 D8 B8 45 DB 6D 4C C9 0D 84 83 27 7E A9 DF A9

   + RADIUS: Attribute Type: Acct Status Type(40)

   + RADIUS: Attribute Type: Acct Delay Time(41)

   + RADIUS: Attribute Type: NAS IP Address(4)

   + RADIUS: Attribute Type: Service Type(6)

   + RADIUS: Attribute Type: Framed Protocol(7)

   + RADIUS: Attribute Type: NAS Port(5)

   + RADIUS: Attribute Type: Vendor Specific(26)

   + RADIUS: Attribute Type: Vendor Specific(26)

   + RADIUS: Attribute Type: NAS Port Type(61)

   + RADIUS: Attribute Type: Tunnel Type(64)

   + RADIUS: Attribute Type: Tunnel Media Type(65)

   + RADIUS: Attribute Type: Calling Station ID(31)

   + RADIUS: Attribute Type: Tunnel Client Endpoint(66)

   + RADIUS: Attribute Type: Vendor Specific(26)

   + RADIUS: Attribute Type: Vendor Specific(26)

   + RADIUS: Attribute Type: Class(25)

   + RADIUS: Attribute Type: Vendor Specific(26)

   + RADIUS: Attribute Type: Acct Session ID(44)

   + RADIUS: Attribute Type: User Name(1)

   + RADIUS: Attribute Type: Framed IP Address(8)

   + RADIUS: Attribute Type: Framed MTU(12)

   + RADIUS: Attribute Type: Acct Multi-Session ID(50)

   + RADIUS: Attribute Type: Acct Link Count(51)

   + RADIUS: Attribute Type: Unknown(55)

   + RADIUS: Attribute Type: Acct Authentic(45)

   + RADIUS: Attribute Type: Vendor Specific(26)

   + RADIUS: Attribute Type: Acct Session Time(46)

   + RADIUS: Attribute Type: Acct Output Octets(43)

   + RADIUS: Attribute Type: Acct Input Octets(42)

   + RADIUS: Attribute Type: Acct Output Packets(48)

   + RADIUS: Attribute Type: Acct Input Packets(47)

   + RADIUS: Attribute Type: Acct Terminate Cause(49)

*******************************************************************************************************************

4  21.160427  0050DABA49EE  005056404FAB  RADIUS  Message Type: Accounting
Response(5)  10.10.1.201  10.10.1.150

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0xA04D; Proto = UDP; Len: 48

+ UDP: Src Port: Unknown, (1813); Dst Port: Unknown (3068); Length = 28 (0x1C)

  RADIUS: Message Type: Accounting Response(5)

     RADIUS: Message Type = Accounting Response

     RADIUS: Identifier = 4 (0x4)

     RADIUS: Length = 20 (0x14)

     RADIUS: Authenticator = 36 D6 7D D5 7E 26 9A EF 3E 0A B4 73 5C 52 FD D5

Unlike authentication, the Routing and Remote Access service sends the same attributes to the RADIUS server irrespective of the authentication method. The Routing and Remote Access service sends the following standard attributes in an Accounting Start message:

  • Accounting Status Type Indicates the type of accounting request (connection start or stop).
  • Acct Delay Time Indicates how long the client has been attempting to send the message.
  • NAS IP Address Gives the IP address of the NAS (Routing and Remote Access server).
  • Service Type Gives the type of service (for example, Framed).
  • Framed Protocol If Service Type is Framed, then this is the framed protocol used (typically this is PPP).
  • NAS Port Indicates a port ID on the NAS that the connection is being made through.
  • NAS Port Type Set to Virtual for VPN connections.
  • Tunnel Type (for VPN Connections) The VPN protocol (for example, Point-to-Point Tunneling Protocol [PPTP]).
  • Calling Station ID The IP address or phone number of the remote access client.
  • Tunnel Client Endpoint For VPN connections, this is the IP address of the VPN client.
  • Class A string whose format and usage is not defined in RFC 2865.
  • Accounting Session ID A unique ID for a session, used to enable matching of session start and stop records.
  • User Name The name of the authenticated user of the service.
  • Framed IP Address The user's IP address assigned by the Routing and Remote Access service.
  • Framed MTU Maximum transmission unit for this connection.
  • Multi-Session ID A unique accounting ID that helps to link multiple related sessions (for example, when the client is using multilink and ISDN).
  • Link Count The number of links that are known to have been used in a multilink session at the time the accounting message is generated.
  • Accounting Authentic Used to indicate how the user was authenticated (using RADIUS, locally or remotely).
  • Event Timestamp Indicates the time that this event occurred on the NAS.

The Routing and Remote Access service also sends the following vendor-specific attributes, each of which are identified with the Microsoft Vendor ID of 0x127 (311 decimal) in an Accounting Start message:

  • Microsoft Vendor attribute 0x08 Microsoft Point-to-Point Encryption (MPPE) encryption type
  • Microsoft Vendor attribute 0x09 Routing and Remote Access vendor ID
  • Microsoft Vendor attribute 0x0A MS-CHAP domain
  • Microsoft Vendor attribute 0x12 Identifies the name and version number of the Routing and Remote Access service (MSRASV5.10)
  • Microsoft Vendor attribute 0x23 Identifies the name and version number of the Routing and Remote Access service (MSRASV5.10)
  • Microsoft Vendor attribute 0x22 Identifies the machine name of the Routing and Remote Access client

When the session has completed, the Routing and Remote Access service sends the same attributes that were included in an Accounting Start message in the Accounting Stop message, plus the following additional attributes:

  • Acct Session Time The length of the user session, in seconds
  • Acct Output Octets Number of octets sent to the remote access client from the Routing and Remote Access service
  • Acct Input Octets Number of octets received from the remote access client by the Routing and Remote Access service
  • Acct Output Packets Number of packets sent to the remote access client from the Routing and Remote Access service
  • Acct Input Packets Number of packets received from the remote access client by the Routing and Remote Access service
  • Acct Terminate Cause The reason the session was terminated (for example, user hung up)

The Routing and Remote Access service also sends the following vendor-specific attributes, each of which are identified with the Microsoft vendor ID of 0x127 (311 decimal) in an Accounting Stop message:

  • Microsoft Vendor attribute 0x08 MS-MPPE encryption type
  • Microsoft Vendor attribute 0x09 MS Routing and Remote Access service vendor
  • Microsoft Vendor attribute 0x0A MS-CHAP domain
  • Microsoft Vendor attribute 0x12 MS Routing and Remote Access service version, which identifies the name and version number of the Routing and Remote Access service (MSRASV5.10)
  • Microsoft Vendor attribute 0x23 Identifies the name and version number of the Routing and Remote Access service (MSRASV5.10)
  • Microsoft Vendor attribute 0x22 Identifies the computer name of the remote access client

RADIUS Proxy in Windows Server 2003

In Windows Server 2003, IAS supports RADIUS proxy, and can support proxying of both authentication and accounting messages, as previously shown in Figure 20-2. The IAS service in Windows 2000 did not support RADIUS proxy functions, although the Routing and Remote Access service could send RADIUS messages to a RADIUS proxy.

The administrator can configure a connection request policy on IAS so that all specified RADIUS requests are forwarded to a specific remote RADIUS server group. A remote RADIUS server group is a set of one or more RADIUS servers to which requests can be forwarded. This remote RADIUS server group enables the administrator to nominate both a primary RADIUS server and one or more backup RADIUS servers. The administrator can also configure IAS to use the backup servers only if the primary server cannot be contacted, or to distribute the RADIUS messages across all servers in the group.

An IAS server can evaluate an Access-Request message against the connection request policies that have been configured to determine whether to forward the RADIUS message, and if so, to which remote RADIUS server group. The administrator can specify a condition on the connection request policy that is specific to the realm or domain name within the User Name attribute of an incoming message. Based on the realm name in the message, the portion of the user name that identifies the location of the account (such as a domain name), IAS can forward RADIUS messages to one server group for one realm, and to other server groups for other realm names.

When IAS, acting as a RADIUS proxy, forwards a RADIUS message to another RADIUS server, it adds a Proxy-State attribute to the forwarded RADIUS message. This indicates to the target RADIUS server that the original request has been proxied.

In the following trace (part of Capture 20-03 in the \Captures folder on the companion CD-ROM), a RADIUS client sends a RADIUS Access-Request to a RADIUS proxy (Frame 1). The RADIUS proxy adds the Proxy-State attribute and sends the Access-Request to a RADIUS server (Frame 2). The server authenticates the request and sends the successful Access-Accept message back to the RADIUS proxy (Frame 3), which sends it back to the RADIUS client (Frame 4).

Frame   Time   Src MAC Addr   Dst MAC Addr   Protocol   Description   Src
Other Addr   Dst Other Addr   Type Other Addr

1   1.843750   005056404FAB   0050DABA49EE   RADIUS   Message Type: Access
Request(1)   10.10.1.150   10.10.1.201

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x1D8F; Proto = UDP; Len: 278

+ UDP: Src Port: Unknown, (1711); Dst Port: Unknown (1812); Length = 258 	(0x102)

  RADIUS: Message Type: Access Request(1)

      RADIUS: Message Type = Access Request

      RADIUS: Identifier = 8 (0x8)

      RADIUS: Length = 250 (0xFA)

      RADIUS: Authenticator = B2 3F 8A 21 54 25 F4 14 4C 30 08 4E 34 5A 82 27

    + RADIUS: Attribute Type: NAS IP Address(4)

    + RADIUS: Attribute Type: Service Type(6)

    + RADIUS: Attribute Type: Framed Protocol(7)

    + RADIUS: Attribute Type: NAS Port(5)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: NAS Port Type(61)

    + RADIUS: Attribute Type: Tunnel Type(64)

    + RADIUS: Attribute Type: Tunnel Media Type(65)

    + RADIUS: Attribute Type: Calling Station ID(31)

    + RADIUS: Attribute Type: Tunnel Client Endpoint(66)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: User Name(1)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

******************************************************************************

Frame   Time   Src MAC Addr   Dst MAC Addr   Protocol   Description   Src
Other Addr   Dst Other Addr   Type Other Addr

2   1.843750   0050DABA49EE   0003FF4D34F0   RADIUS   Message Type: Access
Request(1)   10.10.1.201   10.10.1.151

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0xB4E; Proto = UDP; Len: 288

+ UDP: Src Port: Unknown, (2203); Dst Port: Unknown (1812); Length = 268 	(0x10C)

  RADIUS: Message Type: Access Request(1)

      RADIUS: Message Type = Access Request

      RADIUS: Identifier = 2 (0x2)

      RADIUS: Length = 260 (0x104)

      RADIUS: Authenticator = B2 3F 8A 21 54 25 F4 14 4C 30 08 4E 34 5A 82 27

    + RADIUS: Attribute Type: NAS IP Address(4)

    + RADIUS: Attribute Type: Service Type(6)

    + RADIUS: Attribute Type: Framed Protocol(7)

    + RADIUS: Attribute Type: NAS Port(5)

    + RADIUS: Attribute Type: NAS Port Type(61)

    + RADIUS: Attribute Type: Tunnel Type(64)

    + RADIUS: Attribute Type: Tunnel Media Type(65)

    + RADIUS: Attribute Type: Calling Station ID(31)

    + RADIUS: Attribute Type: Tunnel Client Endpoint(66)

    + RADIUS: Attribute Type: User Name(1)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Proxy State(33)

******************************************************************************

Frame   Time   Src MAC Addr   Dst MAC Addr   Protocol   Description   Src
Other Addr   Dst Other Addr   Type Other Addr

3   1.937500   0003FF4D34F0   0050DABA49EE   RADIUS   Message Type: Access
Accept(2)   10.10.1.151   10.10.1.201

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x1447; Proto = UDP; Len: 250

+ UDP: Src Port: Unknown, (1812); Dst Port: Unknown (2203); Length = 230 	(0xE6)

  RADIUS: Message Type: Access Accept (2)

      RADIUS: Message Type = Access Accept

      RADIUS: Identifier = 2 (0x2)

      RADIUS: Length = 222 (0xDE)

      RADIUS: Authenticator = B7 87 6F 17 EC 00 8B 66 0B E9 33 5C 61 B8 BF 72

    + RADIUS: Attribute Type: Proxy State(33)

    + RADIUS: Attribute Type: Framed Protocol(7)

    + RADIUS: Attribute Type: Service Type(6)

    + RADIUS: Attribute Type: Class(25)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

******************************************************************************

Frame   Time   Src MAC Addr   Dst MAC Addr   Protocol   Description   Src
Other Addr   Dst Other Addr   Type Other Addr

4   1.937500   0050DABA49EE   005056404FAB   RADIUS   Message Type: Access
Accept(2)   10.10.1.201   10.10.1.150

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0xB50; Proto = UDP; Len: 240

+ UDP: Src Port: Unknown, (1812); Dst Port: Unknown (1711); Length = 220 (0xDC)

  RADIUS: Message Type: Access Accept(2)

      RADIUS: Message Type = Access Accept

      RADIUS: Identifier = 8 (0x8)

      RADIUS: Length = 212 (0xD4)

      RADIUS: Authenticator = DF 3D 1B DB 9E 9F D8 B0 B3 B1 5C 2C C0 F9 5B BA

    + RADIUS: Attribute Type: Framed Protocol(7)

    + RADIUS: Attribute Type: Service Type(6)

    + RADIUS: Attribute Type: Class(25)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)

    + RADIUS: Attribute Type: Vendor Specific(26)


RADIUS Message Structure

All RADIUS messages are transmitted using UDP. Each UDP datagram contains a single RADIUS message. The RADIUS message is contained in the UDP datagram's message field. RADIUS access messages are sent by default, from the client to the server (and from a proxy to a server) using a UDP destination port field of 1812 and an ephemeral UDP source port. RADIUS accounting messages are sent using UDP destination port 1813 and an ephemeral UDP source port. When responses are sent, the source and destination ports are reversed.

All RADIUS messages have a common structure, illustrated in Figure 20-4.

Figure 20-4. RADIUS message structure.

Earlier implementation of RADIUS used UDP port 1645 for access messages and UDP port 1656 for accounting messages. However, this conflicted with two other existing protocols: Diametrics, which used UDP port 1645, and Sa-msg-port, which used UDP port 1646. To avoid potential conflicts, RADIUS now uses UDP ports 1812 and 1813. Most RADIUS servers, including IAS in Windows Server 2003, allow the administrator to choose the port that the RADIUS server uses for authentication and accounting messages.

Common RADIUS Header

Each RADIUS message has a common header, indicating the purpose of the message and a variable number of attributes that comprise the data of the message. The common header consists of the following fields:

  • Code Indicates the RADIUS message type
  • Identifier Helps match a RADIUS request and its related reply
  • Length The length of the RADIUS message
  • Authenticator Used to authenticate a reply from the RADIUS server and to ensure that the RADIUS client and server or proxy have the same shared secret

The Code field is a single octet to RADIUS message type. If a RADIUS client, proxy, or server receives a RADIUS message with an invalid, unassigned code, the message is discarded silently. Assigned RADIUS message types and their uses are shown in Table 20-1.

Table 20-1. RADIUS Attributes and Usage
RADIUS Code (Decimal) | Message | Used for
1 | Access-Request | Used by a NAS to request authorization and authentication of a connection
2 | Access-Accept | Used by a RADIUS server to accept a connection request and sent in response to an Access-Request message
3 | Access-Reject | Used by a RADIUS server to reject a connection request and sent in response to an Access-Request message
4 | Accounting-Request | Used by a NAS to send accounting information to a RADIUS server
5 | Accounting- Response | Sent by a RADIUS server to indicate that an Accounting-Request message has been received
11 | Access-Challenge | Used by the RADIUS server to direct the RADIUS client to obtain more information about the connection (typically user credentials)
12 | Status-Server | Experimental and not supported by IAS
13 | Status-Client | Experimental and not supported by IAS
255 | Reserved | Reserved

The 1-octet Identifier field is used by RADIUS clients and proxies to match requests with replies. This field also enables a RADIUS server to detect a duplicate request—a request that came within a short span of time from the same client source IP address and source UDP port and with the same identifier. The Routing and Remote Access service, as a RADIUS client, starts with an initial identifier of 1 and increases it by 1 for each new RADIUS request.

When a RADIUS proxy sends a message to a RADIUS server, the proxy creates a new value for the Identifier field. The RADIUS proxy sends replies back to a RADIUS client with the value of the identifier corresponding to the initial request. This can be seen in Capture 20-04, which shows a RADIUS proxy receiving a message from a RADIUS client and sending it on to a RADIUS server. Each proxied message has an identifier different from that in the initial request.

The 16-bit Length field indicates the entire length, in octets, of the RADIUS message, which includes the common header and all attributes. If, for some reason, a RADIUS message is shorter than the Length field indicates, it is silently discarded. Should there be additional data octets contained in the UDP Data field that are outside the range indicated by the Length field, they are ignored. The Length field has a minimum value of 20 octets and maximum value of 4096 octets.

The Authenticator field is 16 octets long and is used by a RADIUS client to authenticate a reply received from a RADIUS server. The Authenticator field provides proof of knowledge of a shared secret configured between a RADIUS client and its RADIUS server, whether that server is a RADIUS proxy or a RADIUS server.

Attributes

RADIUS attributes carry data values that are used in the authentication, authorization, and accounting functions carried out by RADIUS clients, servers, and proxies. These attributes can appear in access and accounting requests and in response messages. Some attributes can be included more than once, the effect of which is dependent on the specific attribute. When used as a RADIUS proxy, IAS preserves the order of the attributes received from the client in messages transmitted to a RADIUS server.

The layout of RADIUS attributes is shown in Figure 20-5.

Figure 20-5. RADIUS attribute structure.

The Type field in the RADIUS attribute structure is a 1-octet field that defines the specific RADIUS attribute. You can find up-to-date values for the RADIUS Attribute Type field on the Internet Assigned Numbers Authority's Web site at http://www.iana.org/assignments/radius-types. Common RADIUS attributes are listed in Table 20-2, along with their purposes.

Table 20-2. Common RADIUS Attributes
Attribute Type (Decimal) Attribute Name Purpose of Attribute

1

User-Name

Sent in Access-Request messages, this attribute indicates the name of the user that is to be authenticated.

2

User-Password

Sent in Access-Request messages, when authentication is by PAP, this field is the password to be used to authenticate the user. The password is encrypted in Access-Request messages. The password is first padded at the end with nulls (0x00) to a multiple of 16 octets. Next, a one-way MD5 hash is calculated over a stream of octets consisting of the RADIUS shared secret followed by the Request Authenticator. This value is XORed with the first 16-octet segment of the password and placed in the first 16 octets of the String field of the User-Password attribute. If the password is longer than 16 characters, a second one-way MD5 hash is calculated over a stream of octets consisting of the RADIUS shared secret followed by the result of the first XOR. That hash is XORed with the second 16-octet segment of the password and placed in the second 16 octets of the String field of the User-Password attribute. If necessary, this operation is repeated, with each XOR result being used along with the shared secret to generate the next hash, to no more than 128 characters.

3

CHAP-Password

This attribute is sent in Access-Request messages to indicate the response value provided by a PPP CHAP user in response to a CHAP challenge. The value of the CHAP challenge is also included in Access-Request messages sent by the Routing and Remote Access service.

4

NAS-IP-Address

This attribute is sent in Access-Request messages to indicate the IP address of the RADIUS client that is requesting authentication.

5

NAS-Port

This attribute is sent in Access-Request messages to indicate the physical port of the RADIUS client that is requesting authentication.

6

Service-Type

This attribute is sent in Access-Request and Access-Accept messages to indicate the type of service the RADIUS client has requested, or the type of service to be provided.

The Value field is 4 octets long and can have the following values:

1 Login

2 Framed

3 Callback Login

4 Callback Framed

5 Outbound

6 Administrative

7 NAS Prompt

8 Authenticate Only

9 Callback NAS Prompt

10 Call Check

11 Callback Administrative

7

Framed-Protocol

This attribute is contained in Access-Request messages to indicate the specific framed protocol being requested. Possible values for this attribute are as follows:

1 PPP

2 Serial Line Internet Protocol (SLIP)

3 AppleTalk Remote Access Protocol (ARAP)

4 Gandalf proprietary SingleLink/MultiLink protocol

5 Xylogics proprietary IPX/SLIP

6 X.75 Synchronous

8

Framed-IP-Address

This attribute is included in accounting requests and indicates the IP address of the access client.

12

Framed-MTU

This attribute is included in Routing and Remote Access accounting requests and indicates the MTU configured for the RADIUS client.

25

Class

This attribute is available to be sent by the server to the client in an Access-Accept message and is then sent, unmodified, by the RADIUS client to the RADIUS accounting server as part of any accountingrecords. This attribute contains a string identifying the NAS originating the Access-Request message.

31

Calling-Station-Id

This attribute is used only in Access-Request messages. The NAS (or other device) uses this attribute to send either the phone number that the call came from for dial-up connections, or the IP address of the VPN client for VPN connections.

32

NAS-Identifier

This attribute is used only in the Access-Request message to contain a string identifying the NAS originating the Access-Request. The NAS-Identifier is not used to select the shared secret used to authenticate the request.

33

Proxy-State

This attribute is added to an Access-Request by a RADIUS proxy and is returned unmodified in the Access-Accept, Access-Reject, or Access-Challenge message. When a RADIUS proxy receives a response to its request, it removes its own Proxy-State (the last Proxy-State in the message) before forwarding the response to the NAS. If a Proxy-State attribute is added when forwarding a RADIUS message, the Proxy-State attribute is added after any existing Proxy-State attributes (which allows chaining RADIUS proxy servers).

40

Acct-Status-Type

This is sent in an Accounting-Request message to indicate the beginning or end of the user session or an interim update. Possible values include the following:

1 Start

2 Stop

3 Interim-Update

7 Accounting-On

8 Accounting-Off

9-14 Reserved for Tunnel Accounting

15 Reserved for Failed

41

Acct-Delay-Time

This is sent in an Accounting-Request message to indicate for how many seconds the RADIUS client has been trying to send this request. By subtracting this value from the time of arrival on the RADIUS server, the server can approximate the time of the event generating this Accounting-Request message.

42

Acct-Input-Octets

This is sent in an Accounting-Request message in which Acct-Status-Type is set to Stop. It contains the number of data octets that have been received from the port during the accounting session.

43

Acct-Output-Octets

This is sent in an Accounting-Request message where Acct-Status-Type is set to Stop. It contains the number of data octets that have been sent to the port during the accounting session.

44

Acct-Session-Id

This attribute is sent in Accounting Start and Accounting Stop messages and contains a unique ID to identify a session. This makes it easier to match start and stop records in RADIUS log files, because the start and stop records for a given session have the same Acct-Session-Id. A RADIUS client can send send this attribute in an Access-Request message. If so, the NAS must send same Acct-Session-Id in Accounting-Request messages for that session.

46

Acct-Session-Time

This attribute is contained in Accounting Stop messages to indicate how many seconds the NAS has provided the service (that is, the time of the connection).

47

Acct-Input-Packets

This attribute is contained in Accounting Stop messages to indicate how many IP datagrams the NAS has received.

48

Acct-Output-Packets

This attribute is contained in Accounting Stop packets to indicate how many IP datagrams the NAS has sent.

49

Acct-Terminate-Cause

This attribute is contained in Accounting Stop messages to indicate the reason for the session being terminated. Possible values are as follows:

1 User Request

2 Lost Carrier

3 Lost Service

4 Idle Timeout

5 Session Timeout

6 Admin Reset

7 Admin Reboot

8 Port Error

9 NAS Error

10 NAS Request

11 NAS Reboot

12 Port Unneeded

13 Port Preempted

14 Port Suspended

15 Service Unavailable

16 Callback

17 User Error

18 Host Request

50

Acct-Multi-Session-Id

This attribute is sent in accounting messages to enable the RADIUS accounting server to link together multiple related sessions in the RADIUS logs. Each session linked together would have a unique Acct-Session-Id but the same Acct-Multi-Session-Id.

51

Acct-Link-Count

This attribute is sent in accounting messages to enable the RADIUS accounting server to record the number of links that are used in a multilink session at the time the accounting record is generated. The NAS might include the Acct-Link-Count attribute in any Accounting-Request that might have multiple links.

55

Event-Timestamp

This attribute is included in an Accounting-Request message. It records the time that this event occurred on the NAS, in seconds since January 1, 1970 00:00 UTC (Coordinated Universal Time).

60

CHAP-Challenge

This attribute contains the CHAP Challenge sent by the NAS to the access client. It is only used in Access-Request messages.

61

NAS-Port-Type

This attribute indicates the type of the physical port of the NAS that is authenticating the user and is contained in Access-Request packets. Possible values include the following:

0 Async

1 Sync

2 ISDN Sync

3 ISDN Async V.120

4 ISDN Async V.110

5 Virtual

6 PIAFS

7 HDLC Clear Channel

8 X.25

9 X.75

10 G.3 Fax

11 Symmetric DSL (SDSL)

12 Asymmetric DSL, Carrierless Amplitude Phase (ADSL-CAP) modulation

13 Asymmetric DSL, Discrete Multi-Tone (ADSL-DMT)

14 ISDN Digital Subscriber Line (IDSL)

15 Ethernet

16 Digital Subscriber Line of unknown type (xDSL)

17 Cable

18 Wireless-Other

19 Wireless-IEEE 802.11

64

Tunnel-Type

This attribute is used in Access-Request messages to indicate the type of VPN tunnel that the NAS is attempting to set up. Possible values include the following:

1 PPTP

2 Layer Two Forwarding (L2F)

3 Layer Two Tunneling Protocol (L2TP)

4 Ascend Tunnel Management Protocol (ATMP)

5 Virtual Tunneling Protocol (VTP)

6 IP Authentication Header in the Tunnel-mode (AH)

7 IP-in-IP encapsulation (IP-IP)

8 Minimal IP-in-IP encapsulation (MIN-IP-IP)

9 IP Encapsulating Security Payload in the Tunnel-mode (ESP)

10 Generic Route Encapsulation (GRE)

11 Bay Dial Virtual Services (DVS)

12 IP-in-IP Tunneling [10]

65

Tunnel-Medium-Type

This attribute is used when authenticating a VPN connection and indicates the transport medium that is being used when creating a tunnel for those protocols (such as L2TP) that can operate over multiple transports. Possible values are as follows:

1 IPv4 (IP version 4)

2 IPv6 (IP version 6)

3 Network Service Access Point (NSAP)

4 High-level Datalink Control (HDLC) (8-bit multidrop)

5 BBN 1822

6 802 (includes all 802 media plus Ethernet canonical format)

7 E.163 (Plain Old Telephone Service [POTS])

8 E.164 (Switched Multimegabit Data Service [SMDS], Frame Relay, Asynchronous Transfer Mode [ATM])

9 F.69 (Telex)

10 X.121 (X.25, Frame Relay)

11 IPX

12 AppleTalk

13 Decnet IV

14 Banyan Vines

15 E.164 with NSAP format subaddress

66

Tunnel Client Endpoint

This attribute contains the address of the VPN client and can be included in both Access-Request and Access-Accept messages when a VPN tunnel is being set up.

80

Message Authenticator

This attribute is used in RADIUS Access-Request messages to provide proof of the knowledge of the RADIUS shared secret.

Vendor-Specific Attributes

RFC 2865 provides a mechanism to enable vendors to extend the range of attributes that are implemented. This enables vendors to provide their own attributes for use on their hardware.

If a RADIUS client sends vendor-specific attributes to a RADIUS server that the server cannot interpret, the server ignores them. Likewise, if a client receives vendor-specific attributes from a RADIUS server, it should attempt to operate without using them, although this could result in degraded performance, depending on the specific attribute.

Vendor-specific attributes are encoded in RADIUS messages as normal attributes with an attribute type of 26. As shown in Figure 20-6, there are two formats for vendor-specific attributes, with the second format preferred. In Windows Server 2003, both Routing and Remote Access and IAS use the preferred format.

Figure 20-6. Vendor-specific attribute structure.

RFC 2548 defines the Microsoft-specific attributes that are supported by Routing and Remote Access and IAS. This RFC was originally written for the Routing and Remote Access service for Microsoft Windows NT 4.0 Server, but these vendor-specific attributes are valid with Windows Server 2003. Both IAS and Routing and Remote Access set the Vendor-ID field of the Vendor-Specific attribute to 311 (0x0137), which denotes Microsoft.

Table 20-3 contains the most common vendor-specific attributes that Routing and Remote Access and IAS use.

Table 20-3. Common Vendor-Specific Attributes
Vendor Attribute ID (Decimal) | Attribute Name | Purpose of Attribute
1 | MS-CHAP-Response | Sent in authentication requests that use CHAP to contain the CHAP response received from the access client.
9 | MS-RAS-Vendor | Sent in authentication requests to identify the vendor (Microsoft).
10 | MS-CHAP-Domain | This attribute, which can be in both Access-Accept and Accounting-Request messages, indicates the Windows Server 2003 domain in which the user has been authenticated.
11 | MS-CHAP-Challenge | The CHAP challenges used in authentication requests that use CHAP, MS-CHAP, or MS-CHAP v2.
16 | MS-MPPE-Send-Key | This attribute holds a session key for use by MPPE. This key is intended for encrypting messages sent from the NAS to the access client and is sent only in Access-Accept messages. This attribute is encrypted using the shared secret.
17 | MS-MPPE-Recv-Key | This attribute contains a session key for use by MPPE. This key is intended for encrypting packets received by the NAS from the access client and is used only in Access-Accept messages.
18 | MS-RAS-Version | The version of Routing and Remote Access sending the RADIUS message. This is sent in Access-Request and Accounting-Request messages. This attribute is encrypted using the shared secret.
25 | MS-CHAP2-Response | For Authentication requests that use MS-CHAP v2, the CHAP response received from the Access client.
26 | MS-CHAP2-Success | For authentication requests that use MS-CHAP v2, the indication that the authentication was successful.


RADIUS Messages

RADIUS clients, such as a NAS device or the Routing and Remote Access service in Window Server 2003, send two types of messages to a RADIUS server:

  • Authentication messages Defined in RFC 2865, these enable the RADIUS client to authenticate and authorize connection attempts.
  • Accounting messages Defined in RFC 2866, these messages enable the NAS or other RADIUS client to record details of the resources used by the Access client.

When a RADIUS server receives a valid authentication or accounting message, it sends a response back to the RADIUS client indicating the success, failure, or a request for more information for the authentication request or the success of an accounting request.

Authentication

There are four RADIUS Authentication messages sent between RADIUS clients and servers, described in the following sections.

Access-Request

An Access-Request message is sent by a RADIUS client to the RADIUS server to determine whether a connection to the RADIUS client (the NAS) is allowed. The message also enables the RADIUS client to enquire whether there are any special requirements for the use of that service. The Access-Request message contains the information needed to identify the RADIUS client's users to perform the authentication and to enable the RADIUS server to ascertain whether any special requirements exist for this request.

When the RADIUS server receives the Access-Request message, it first checks that the message came from a known client. The server then attempts to perform the requested authentication and authorization and responds with an appropriate reply.

Access-Request messages contain the following fields:

  • Code field set to 1 to indicate an Access-Request.
  • Identifier field set to a value that identifies this specific request. This field is changed whenever the content of the attribute's field changes and when a valid reply has been received for a previous request. If the RADIUS client needs to retransmit an Access-Request, this field is not changed.
  • A Request Authenticator field to enable the client to authenticate the server in the server's response.
  • NAS-IP-Address attribute or a NAS-Identifier attribute (or both).
  • A User-Name attribute to identify the user to be authenticated.
  • Either a User-Password or a CHAP-Password (but not both). When a User-Password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5.

An Access-Request can also contain additional attributes as a hint to the RADIUS server, but the server is not required to honor the hint. The Routing and Remote Access service, for example, sends several Microsoft vendor attributes, including the version of Routing and Remote Access service in use.

Access-Challenge

An Access-Challenge message is sent by a RADIUS server to the RADIUS client, requesting that the RADIUS client obtain additional information from the access client to complete the authentication. Access-Challenge messages are used when EAP is the authentication method, in which each Access-Challenge message is an EAP message from the RADIUS server to the access client.

If the connection requires additional information that can be obtained by an Access-Challenge message, the server responds to an Access-Request message by transmitting an Access-Challenge message. When the RADIUS client receives an Access-Challenge message, it matches the Identifier field of a pending Access-Request and verifies that the Response Authenticator field contains the correct response for the pending Access Request. Invalid messages are silently discarded.

A RADIUS client that does not support challenge and response treats the Access-Challenge as though it had received an Access-Reject message instead. This has the effect of denying the requested access. If the RADIUS client supports challenge and response, the receipt of a valid Access-Challenge message indicates that a new Access-Request is to be sent, which should contain updated request information. The RADIUS client can display a text message to the user and then prompt the user for a response. The RADIUS client then sends its original Access-Request with a new request ID and Request Authenticator, with the User-Password attribute replaced by the user's response to the challenge, suitably encrypted. If the Access-Challenge contained a State attribute from the Access-Challenge, this is also returned. Note that the Access-Request messages can contain, at most, one instance of the State attribute.

Access-Challenge messages contain the following fields:

  • Code field set to 11 to indicate an Access-Challenge message.
  • Identifier field is a copy of the Identifier field of the Access-Request message that caused this Access-Challenge message.
  • Response Authenticator is calculated from the Authenticator field in the Access-Request message and the shared secret, as described earlier.
  • Vendor-Specific, Idle-Timeout, Session-Timeout, and Proxy-State are the only attributes that can be included in an Access-Challenge message, although these are optional.

Access-Accept

An Access-Accept message is sent by a RADIUS server to a RADIUS client to allow a connection request and optionally to provide configuration information necessary for the connection.

When the RADIUS client receives an Access-Accept message, the client matches the Identifier field with a pending Access-Request and ensures that the Response Authenticator field contains the correct response for this pending Access-Request message. Invalid messages are silently discarded. The Identifier field in an Access-Accept message is a copy of the Identifier field of the Access-Request that caused this Access-Accept message.

Access-Accept messages contain the following fields:

  • Code field set to 2 to indicate an Access-Accept message.
  • Identifier field is a copy of the Identifier field of the Access-Request message that caused this Access-Accept message.
  • Response Authenticator is calculated from the Access-Request value, as described earlier.

In addition to these fields, a RADIUS server can send zero or more attributes back to the RADIUS client. With IAS the administrator can configure the RADIUS server to return a large variety of RADIUS attributes to the RADIUS client, based on the remote access policies set at the IAS server.

Access-Reject

An Access-Reject message is sent by a RADIUS server to a RADIUS client to deny a connection request. If the RADIUS server receives an Access-Request message but either cannot authenticate the user credentials or cannot authorize the connection, it returns an Access-Reject message to the RADIUS client. The RADIUS client can then either send a message to the client denying the request for service or re-request credentials and then attempt the authentication by sending a new Access-Request message.

Access-Reject messages contain the following fields:

  • Code field set to 3 to indicate an Access-Reject message.
  • Identifier field is a copy of the Identifier field of the Access-Request that caused this Access-Reject.
  • Response Authenticator is calculated from the Access-Request message.
  • Accounting Status Type attribute is set to indicate whether this request is for the start or stop of an accounting record.

If the authentication was performed using CHAP, MS-CHAP, or MS-CHAP v2, an IAS server sends an MS-Chap-Error attribute back to the RADIUS client to indicate the failure.

RADIUS Authentication Message Exchanges

There are two primary sets of authentication message exchanges that are normally seen between a RADIUS client and a RADIUS server:

  • Access-Request, followed by Access-Accept This occurs when a RADIUS server successfully authenticates and authorizes a connection on behalf of a RADIUS client. Once the authentication has been successfully completed, the RADIUS client (for example, Routing and Remote Access service) can then commence service to a client (that is, a Routing and Remote Access server can provide remote access service to a dial-up or VPN client).
  • Access-Request, followed by Access-Reject This occurs when a RADIUS server does not successfully authenticate and authorize a connection on behalf of a RADIUS client. The RADIUS client can then attempt to get new credentials, which it can resubmit in a new Access-Request message.

A third, less frequently seen type of exchange involves an Access-Challenge. In this exchange, the RADIUS client first sends an Access-Request to the RADIUS server, which responds with the RADIUS Access-Challenge. The RADIUS client obtains additional information from the access client, and then sends another Access-Request to the server. There can be multiple Access-Challenge messages sent by the RADIUS server.

Presence of RADIUS Proxy

A RADIUS proxy that forwards RADIUS messages between RADIUS clients and RADIUS servers, as illustrated in Figure 20-2. When a RADIUS proxy is used, the RADIUS proxy adds an additional attribute, Proxy-State, to the original Access-Request message before sending it to the RADIUS server. The response (Access-Accept, Access-Reject, or Access-Challenge) is sent from the RADIUS server to the RADIUS proxy with the Proxy-State attribute. The RADIUS proxy then removes the Proxy-State attribute and sends the remainder of the RADIUS message back to the RADIUS client. In all cases, the RADIUS client is unaware of the presence, or absence, of the RADIUS proxy.

Accounting

There are two RADIUS Accounting messages sent between RADIUS clients and RADIUS servers: Accounting-Request and Accounting-Response. The RADIUS client sends an Accounting-Request message to a RADIUS server. This message indicates that an accounting session has started, describes the type of service being delivered, and identifies the user receiving the service. The RADIUS server responds with an Accounting-Response message indicating that the accounting start was received and recorded.

When the service being provided by the RADIUS client (for example, remote access) has been completed, the RADIUS client generates a further Accounting-Request message called an Accounting Stop message. This describes the type of service that was delivered and statistics such as elapsed time, input and output octets, or input and output packets, which could be used for billing or charge-back purposes. The RADIUS server then sends the client an Accounting-Response message to indicate that the message was received and recorded.

Accounting-Request

An Accounting-Request message is sent by a RADIUS client to inform a RADIUS accounting server of an accounting event. The Accounting-Request message holds the information needed to provide accounting for the service being provided for the RADIUS client. When the RADIUS server receives an Accounting-Request message, it records the accounting information and replies with an Accounting-Response message. If the server cannot record the accounting information, no Accounting-Response message is sent.

The RADIUS client can send any valid RADIUS attribute in the Accounting-Request message, except for User-Password, CHAP-Password, Reply-Message, and State. A RADIUS client always includes either the NAS-IP-Address or NAS-Identifier in the Accounting-Request. If the Accounting-Request message includes a Framed-IP-Address, this attribute contains the IP address assigned to the connection.

Accounting-Request messages contain the following fields:

  • Code field set to 4 to indicate an Accounting-Request.
  • Identifier field is one octet to identify this Accounting-Request.
  • Length field is 2 octets, which defines the length of the message, including the Code field.
  • Authenticator is a 16-octet value used to authenticate the messages between the client and RADIUS accounting server. This field contains a one-way MD5 hash calculated over a stream of octets consisting of the concatenation of the Code, Identifier, Length, a field of 16 zero octets, all request attributes, and the shared secret.
  • Acct-Status-Type is used to indicate whether this Accounting-Request message is the start or stop of a connection. The RADIUS client can also send interim updates and can indicate the start and stop of accounting (for example, the client can indicate to the RADIUS server that accounting has started after booting and that accounting has stopped just prior to a reboot).

As can be seen in Capture 20-03, the Routing and Remote Access service sends the following standard attributes in an Accounting Start request:

  • User Name (attribute value 1) The user name and domain of the user requesting the service.
  • NAS IP Address (4) Set to the IP address of the RADIUS client.
  • NAS Port (5) The port on the NAS relating to this Accounting-Request.
  • Service Type (6) The same as for RADIUS authentication.
  • Framed Protocol (7) Indicates the framing protocol to be used for framed access.
  • Framed IP Address (8) For a VPN, this holds the client IP address allocated by the VPN server.
  • Framed MTU (12) The MTU for the connection.
  • Class (25) Defines the class of the authentication request. Its usage is not defined in RFC 2865.
  • Calling Station ID (31) Set to the IP address of the access client.
  • Acct-Status-Type (40) Set to 1 to indicate accounting start.
  • Acct-Delay-Time (41) Indicates how many seconds the RADIUS client has been trying to send this accounting request.
  • Acct-Session-Id (44) Used to identify a particular session and to match up the session start and end messages.
  • Acct-Authentic (45) Indicates how the user was authenticated. This is set to 0x01 to indicate RADIUS authentication.
  • Acct-Multi-Session-Id (50) Identification field used to link multiple related sessions together. This is typically used for dial-up sessions using multilink ISDN.
  • Acct-Link-Count (51) The count of the links in a given multilink session.
  • Event-Timestamp (55) Records the time that the accounting event occurred on the NAS, in seconds since midnight January 1, 1970 (UTC).
  • NAS-Port-Type (61) Indicates that this is a VPN connection.
  • Tunnel-Type (64) For VPNs, the VPN protocol (for example, PPTP).
  • Tunnel-Medium-Type (65) For VPNs, denotes the transport medium used when creating the VPN tunnel.

The Routing and Remote Access service, when acting as a RADIUS client, also sends the following vendor-specific attributes to the RADIUS server:

  • MS-MPPE-Encryption-Type (8) Indicates the MPPE encryption type used.
  • MS-RAS-Vendor (9) Identifies the vendor (Microsoft).
  • MS-RAS-Version (18) Indicates the version of Routing and Remote Access service (for Windows Server 2003, MSRASVS5.10).

When the RADIUS client (for example, the Routing and Remote Access service) completes offering its service, it sends an Accounting Stop message. This is similar to the Accounting Start message, noted earlier, but with the Acct-Status-Type attribute set to 2 and with extra attributes to reflect the usage of the NAS or other device.

In addition to the attributes sent in an Accounting Start message, the Routing and Remote Access service sends the following attributes:

  • Acct-Input-Octets (42) Indicates how many octets have been received by the NAS while the service was being provided.
  • Acct Output Octets (43) Indicates how many octets have been sent to the NAS while the service was being provided.
  • Acct Session Time (46) Indicates how long (in seconds) the service was provided.
  • Acct-Input-Packets (47) Indicates how many packets have been received by the NAS while the service was being provided.
  • Acct-Output-Packets (48) Indicates how many packets have been sent to the NAS while the service was being provided.
  • Acct-Terminate-Cause (49) Specifies how the session was terminated. Values can include the following:
    • 1 User Request
    • 2 Lost Carrier
    • 3 Lost Service
    • 4 Idle Timeout
    • 5 Session Timeout
    • 6 Admin Reset
    • 7 Admin Reboot
    • 8 Port Error
    • 9 NAS Error
    • 10 NAS Request
    • 11 NAS Reboot
    • 12 Port Unneeded
    • 13 Port Preempted
    • 14 Port Suspended
    • 15 Service Unavailable
    • 16 Callback
    • 17 User Error
    • 18 Host Request

Accounting-Response

An Accounting-Response message is sent by the RADIUS accounting server to the RADIUS client to acknowledge that the Accounting-Request has been received and recorded successfully. When the RADIUS client receives the Accounting-Response message, it matches the response with a pending Accounting-Request to complete the accounting for this event. If no Accounting-Response is received, the RADIUS client retransmits the Accounting-Request.

As with other RADIUS messages, the Response Authenticator field holds the authenticator that relates to the pending Accounting-Request. Additionally, invalid packets, which can include those in which the authenticator cannot be validated, are silently discarded.

A RADIUS Accounting-Response is not required to contain any attributes. The IAS server does not send any attributes in an Accounting-Response message, as can be seen in Capture 20-03.

RADIUS Accounting Message Exchanges

There is only one type of message exchange with RADIUS accounting: an Accounting-Request followed by an Accounting-Response. The Accounting-Request can indicate the start or completion of a user session (for example, a VPN connection to a Routing and Remote Access server). Additionally, RADIUS clients can post interim accounting records and are able to indicate the start and stop of accounting (for example, an Accounting-On message can be sent after the NAS boots and an Accounting-Off message sent just prior to a scheduled reboot).

If the RADIUS client sends an Accounting-Request, but no Accounting-Response is received, the administrator can configure the client to send the request to alternate servers if the original server is not responsive. The retransmission technique used by the Routing and Remote Access service was described earlier in this chapter.

Presence of RADIUS Proxy with RADIUS Accounting Messages

As with RADIUS authentication messages, the administrator can configure a RADIUS server to serve as a proxy that forwards the accounting message to another server. The accounting proxy works in the same manner as the authentication proxy, as described earlier in this chapter.


Summary

RADIUS is a mature and powerful protocol for authentication, authorization, and accounting and is used extensively on the Internet and for authenticated access to private networks (dial-up, VPN, and wireless connections). RADIUS provides authentication and authorization for NAS connections through an exchange of Access-Request/Access-Accept messages between a RADIUS client and a RADIUS server. RADIUS provides accounting for NAS connections through an exchange of Accounting-Request/Accounting-Response messages between a RADIUS client and a RADIUS server. A RADIUS proxy can be used to forward RADIUS messages between RADIUS clients and RADIUS servers.


Internet Information Services (IIS) and the Internet Protocols

Chapter 21
Internet Information Services (IIS) and the Internet Protocols

IIS 6 is an integrated set of Internet services available in Microsoft Windows Server 2003 that provides Web publishing, file transfer, network news, and mail services. IIS 6 includes servers for Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Network News Transfer Protocol (NNTP), and Simple Mail Transfer Protocol (SMTP). In this chapter, we look at each protocol and the functionality it provides.


HTTP

HTTP is an application-level protocol used for communications and data transmission between client computers and HTTP servers. Client requests are frequently submitted from browser software such as Microsoft Internet Explorer and Netscape Navigator to HTTP servers such as IIS. HTTP is the protocol underlying today's World Wide Web.

Early versions of HTTP, referred to as HTTP/0.9, have existed since 1990. Between 1990 and 1996, HTTP continued to evolve in an uncontrolled manner. It was common for different vendors to modify the protocol to suit their own needs. RFC 1945 was the first formal HTTP specification. To some degree, a major objective of RFC 1945 was to summarize and unify the implementation details. As a result, the industry generally expected it to be replaced rather quickly. For example, HTTP/1 lacked sufficient definition for caching, hierarchical proxies, virtual hosts, and persistent connections. A more stringent version, HTTP/1.1, was defined in RFC 2068, which has been updated in RFC 2616. IIS 6 contains an HTTP/1.1-compliant server.

Before analyzing HTTP in depth, you must understand certain basic terms as they relate to the protocol:

  • Message The basic unit of communication between a client and a server. Messages are usually sent as part of a TCP connection between a short-lived TCP port on the client to TCP port 80 on the server, although administrators can configure the server to use other TCP ports.
  • Resource An object or service available on the server that is identified in a message. Typically, this will be a Hypertext Markup Language (HTML) or Extensible Markup Language (XML) page, but it can be any sort of object, including a text document, graph, or sound file.
  • Request A message from the client to the server that requests a resource. Most HTTP interactions involve a client sending a GET request message to the server.
  • Response A message from the server to the client that returns information initiated by a request message. This is the contents of the page or file requested by the client.
  • Method The action to be performed on the requested resource. Also known as a request method, this is the specific action that the HTTP server is being requested to perform. Usually, this is a GET, but there are other methods a client can request.
  • Client Any program that establishes a connection to an HTTP server to issue requests. Typically this is a Web browser such as Internet Explorer, Opera, or Mozilla. There are other applications that can act as HTTP clients.
  • Server A process that accepts HTTP requests for connections from client programs, and provides response data. A single program can utilize both client and server components. In Windows Server 2003, the HTTP server is a component of IIS 6.
  • Cache A client proxy or server's store of response messages, used to retain resources that are designated as cacheable. By caching responses, retrieval of data that has been recently requested does not require additional network traffic, as the request can be fulfilled locally. Internet Explorer holds a cache of recently accessed resources.
  • Cacheable A response message that is permitted to be stored by the requestor, as determined by a set of rules governing caching. By default, resources are cacheable.
  • Tunnel A Transport-Layer intermediary between client and server programs that does not take part in the request/response process, except to relay information between the programs. A tunnel is closed when both endpoint parties to the communication have closed their connections.
  • Gateway An HTTP server that receives requests on behalf of another server, often appearing to the client to be the server that was queried.
  • Proxy A program that acts as both client and server in HTTP communication, receiving request messages from a client program, repackaging the requests as if the proxy were the client, and returning the responses to the original requestor. Microsoft Internet Security and Acceleration (ISA) Server provides a secure, high-performance proxy facility.
  • Uniform Resource Identifier (URI) A standard format used to describe a resource requested from a server.
  • Uniform Resource Locator (URL) A standard naming method used to define the location of any resource on the Internet. URLs take the format protocol://hostname:port/filename, for example, http://kapoho.com:80/tcp/default.html.
  • Range HTTP messages are represented in sequences, or ranges, of bytes. When a client wishes to retrieve a resource from an HTTP server, it might need to specify a range of the total bytes that make up the resource, as the entire resource might be too large to transfer in a single transaction. Servers might also specify the range measurement that they are capable of accepting, such as bytes.
  • Entity A resource, or portion of a resource, that is being referred to in a request/response exchange between HTTP clients, proxies, and servers.
  • Variant Resources can be represented by more than one name; additional names for a single resource are called variants.

HTTP in Operation

HTTP is a request/response protocol. A client wishing to retrieve a resource from an HTTP server issues a request message containing a request method, URI, protocol version ID, and resource-specific information. The following is a trace of a simple request and response between an HTTP client and server. The full content of Capture 21-01 is provided on the companion CD-ROM.

12       1.838983     0050564050E1    0050564050EA    HTTP       GET Request
(from client using port 4283)  10.10.1.68       10.10.1.74

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x9BAB; Proto = TCP; Len: 314

+ TCP: .AP..., len:  274, seq:1182807736-1182808010, ack:3591543841,
    win:17520, src: 4283  dst:   80

  HTTP: GET Request (from client using port 4283)

     HTTP: Request Method = GET

     HTTP: Uniform Resource Identifier = /rebecca.htm

     HTTP: Protocol Version = HTTP/1.1

     HTTP: Accept = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

     HTTP: Accept-Language = en-us

     HTTP: Accept-Encoding = gzip, deflate

     HTTP: User-Agent = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; 	.NET CLR 1.0.3

     HTTP: Host = kapoho10

     HTTP: Connection = Keep-Alive

13       1.848998     0050564050EA    0050564050E1    HTTP       Response
(to client using port 4283) 10.10.1.74       10.10.1.68

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0xA119; Proto = TCP; Len: 441

+ TCP: .AP..., len:  401, seq:3591543841-3591544242, ack:1182808010,
    win:17246, src:   80  dst: 4283

  HTTP: Response (to client using port 4283)

     HTTP: Protocol Version = HTTP/1.1

     HTTP: Status Code = OK

     HTTP: Reason = OK

     HTTP: Content-Length = 176

     HTTP: Content-Type = text/html

     HTTP: Last-Modified = Tue, 27 Aug 2002 22:05:16 GMT

   + HTTP: Undocumented Header = Accept-Ranges: bytes

   + HTTP: Undocumented Header = ETag: "0b23ed3154ec21:68a"

     HTTP: Server = Microsoft-IIS/6.0

     HTTP: Date = Tue, 27 Aug 2002 22:06:49 GMT

     HTTP: Data: Number of data bytes remaining = 176 (0x00B0)

In this trace, a client, kapoho10, issues a GET method request to the server with the intention of getting the page \rebecca.htm. The server then responds with the page (contained in the data field). The preceding summary omits the necessary name resolution and TCP connection overhead, although Capture 21-01 (found in the \Captures folder on the companion CD-ROM) includes these exchanges.

An HTTP request can be issued to the server, a tunneling agent, a proxy, or a gateway. Each participant in the transaction can simultaneously process multiple HTTP connections, which are typically issued over TCP port 80, although the participant applications can specify other ports.

One restriction of most implementations of HTTP/1 was that a separate connection had to be established for each request. With HTTP/1.1, multiple transactions can be processed over a single connection, which is kept open. This is called a keep-alive, which can improve protocol performance and reduce server overhead. You can see the keep-alive request in the preceding trace. HTTP provides no mechanisms for guaranteed delivery of messages. HTTP relies on TCP to provide this functionality.

After receiving a request message, an HTTP server responds with a message indicating success or error, as well as protocol-version information and possible resource-specific data, including the data itself. In the preceding example, the server returns the page \rebecca.htm to the client.

The protocol version is sent in the format "HTTP/x.y," where x is the "major" version identifier and y is the "minor" version identifier (in the preceding example, this is HTTP/1.1). By sending version numbers as part of the HTTP message, clients and servers negotiate communication format, with both client and server sending the highest protocol version they both understand. With the exception of tunnels, which do not maintain any awareness of the contents of HTTP data, each party in the process can potentially cache message content to facilitate faster retrieval for future requests.

A proxy is not permitted to send a request message in a protocol version higher than the proxy itself supports. In addition, it is required to do one of three things: downgrade any incoming request message with a higher version than its own, respond to the client with an error message, or switch to tunnel mode. Proxies are also required to upgrade any lower protocol version requests to match their own, but return the response to the client in the same major version as the original request.

URIs

A URI is simply a standard format for defining a retrievable resource. A familiar term, the URL, is actually a subset of the URI, as is the less familiar Uniform Resource Name (URN). A retrievable item can be requested by referencing the item's location, as in the case of a URL, or by referencing the item's distinguished name, as in the case of a URN. The HTTP protocol does not limit the length of URIs, and servers are required to be capable of receiving a URI with a length that is at least as long as that of any resource they serve.

URI Syntax

URIs can be absolute or relative to a base URI. Although RFC 2396 defines generic syntax, several RFCs define the syntax of a URI. An absolute URI lists the entire scheme (this is usually the name of the protocol used in this request) and path that will be used to request the resource, whereas relative URIs build on a previously established base location and scheme. A typical URI construction is as follows:

<scheme>://<hostname>:<port>/<absolute_path>?<query>

It might appear as:

http://search.msn.com/results.asp?q=Thomas+Lee+Joseph+Davies+TCP%2FIP

In this example, the scheme is http:, indicating that the request will be passed over HTTP. The slashes are reserved characters that serve as separators between scheme and scheme-specific details. The host name given here is search.msn.com, so the request is issued over TCP port 80 to the server at search.msn.com. If a port were specified, the TCP connection would be opened over that port. If for some reason the target server is not listening for requests over this port number, an error results. The absolute path given here is to the search facility, with the rest of the URI being parameters to send to this search engine. The presence of a question mark following this path indicates that a query is being performed, and the remainder of the URI is query parameter information (in this case, the keywords that should be searched for).

HTTP Messages

As noted earlier, HTTP clients and servers use HTTP messages as the basic form of communication. These messages are designed to support a heterogeneous collection of servers and follow a well-defined syntax.

Message Types

RFC 822 defines HTTP request and response messages as being used to transfer data and resources, called entities, from client to server, and vice versa. These messages are comprised of a start line that might or might not be followed by header fields, which are often simply referred to as headers. An end-of-line marker (carriage return line feed [CRLF]) indicates the end of the headers, and message body data might follow. HTTP/1.1 dictates that no more than one CRLF be used sequentially in any HTTP message to eliminate unnecessary parsing on the part of either the server or client, although flawed implementations of HTTP often issue multiple CRLFs in succession. If a CRLF is received where none is expected, it is ignored. Syntax of a typical HTTP message is the following:

Request-Line|Response-Line *((general-header|request-header|response-header|entity-header)CRLF)CRLF [message-body]
HTTP request and response messages are defined in RFC 822, which can be found in the \Rfc folder on the companion CD-ROM.

Message Headers

HTTP header fields are used to define parameters regarding the message being transmitted, whether the message is general, request, response, or entity information. Header fields can be preceded by any amount of linear white space (LWS), and consist simply of the header name followed by a colon (:) and the header value. General header fields apply to both request and response messages but do not relate to the entity being transferred. Request and response header fields are specific to their respective message types, and entity header fields provide additional information about the resource being passed in the message.

Request Messages

Client programs issue request messages both to establish communication parameters and to initiate resource transfer and manipulation. The following example shows the headers of the message generated by a client requesting a resource from a server (as demonstrated in Capture 21-01):

HTTP: GET Request (from client using port 4283)

     HTTP: Request Method = GET

     HTTP: Uniform Resource Identifier = /rebecca.htm

     HTTP: Protocol Version = HTTP/1.1

     HTTP: Accept = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

     HTTP: Accept-Language = en-us

     HTTP: Accept-Encoding = gzip, deflate

     HTTP: User-Agent = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; 	.NET CLR 1.0.3

     HTTP: Host = kapoho10

     HTTP: Connection = Keep-Alive

This output is a single line in the HTTP message, with spaces separating the individual elements, and terminated with a CRLF sequence. This line identifies several criteria: the general type of request being made (a GET, in this case); the method token, or action to perform on the requested resource (again a GET); the URI of the requested resource (/Rebecca.htm); and the protocol version number (HTTP/1.1). There are extra header fields to inform the server what type of object the client will accept, the client's language, the user agent in use, and whether to keep connections alive between client and server. The client HTTP port number listed in this request, 4283, is unrelated to the server TCP port. Although the client made its HTTP request over TCP/port 4283, the request was issued to TCP port 80. This can be seen in the TCP header of the HTTP GET message, as follows:

TCP: .AP..., len:  274, seq:1182807736-1182808010, ack:3591543841, win:17520, src: 4283  dst:   80

      TCP: Source Port = 0x10BB

      TCP: Destination Port = Hypertext Transfer Protocol

      TCP: Sequence Number = 1182807736 (0x468036B8)

      TCP: Acknowledgement Number = 3591543841 (0xD6129C21)

      TCP: Data Offset = 20 (0x14)

      TCP: Reserved = 0 (0x0000)

    + TCP: Flags = 0x18 : .AP...

      TCP: Window = 17520 (0x4470)

      TCP: Checksum = 0xDB66

      TCP: Urgent Pointer = 0 (0x0)

      TCP: Data: Number of data bytes remaining = 274 (0x0112)

Request Message Methods

Methods are actions that a request message can ask to be performed at the server or applied to a resource entity. Table 21-1 lists common HTTP/1.1 methods and the actions that they request.

Table 21-1. Common HTTP/1.1 Method Codes
Method | Description
OPTIONS | Requests information regarding the server capabilities or what actions can be performed on a specified resource. This is an information-gathering method only; no action is performed on the resource. Results of this method cannot be cached. If the request URI is an asterisk (*), the client is testing the capabilities of the server to facilitate further action. If the request URI is anything other than an asterisk, the client can retrieve information only about the capabilities of the resource specified.
GET | Requests the HTTP server to return some object. GET methods can also be conditional, where the retrieval is performed only if specified conditions are completely or partially met. For example, the client can specify that it has already received and cached some portion of the requested data, and needs to retrieve the portions that it does not yet have. Web proxy servers, such as Microsoft ISA Server, use partial GETs to keep their Web cache up to date while minimizing data retrieved from a server.
HEAD | The HEAD method is identical to the GET method, except that the server does not return the actual resource in its response, but merely information about the resource. This method is often used to test validity of hypertext links so as not to request a resource that might not actually be available.
POST | A client uses a POST method to send data to the server. The POST command is often used to supply a server with information that a user has input into an HTML form. The POST method uses a specific file on the server as part of the URI—the file named is generally a server-side script or executable that is capable of processing the data the client is sending.
PUT | The PUT method is used to create an entity on the HTTP server under the requested URI. Generally, PUT is used as a simple method of uploading a file to the server. PUT might create new files, or might replace files that already exist and have the same name as the entity named in the PUT request.
DELETE | The DELETE method requests that a specific resource be deleted from the server. Even though the server might respond with a message indicating success, the client does not know if the deletion actually occurred, as it might be halted by human intervention.
TRACE | The TRACE method is used to request a loopback of the request message. This is used primarily as a troubleshooting tool to determine which data is actually being received at the other end of the request. No entities are passed in a TRACE method.
CONNECT | CONNECT is used for proxies that can dynamically become tunnels, as is required by Secure Sockets Layer (SSL) tunneling.

Safe Methods

Methods can be said to be safe, meaning that if they are properly implemented, they should cause no ill effects to the server. For example, the GET and HEAD methods are considered safe methods because they retrieve only data from the server and do not actually manipulate that data while it resides on the server.

Response Messages

After a server receives a client request message, it returns an HTTP response message, similar in construction to the client request, in the following format:

Status line *(( general header | response header | entity header ) CRLF) CRLF [message body]

Each of these components is analyzed in further detail in this section.

Response Message Status Lines

When a server receives a request message from a client, it evaluates the request method and might or might not perform an action on the requested resource as a result. Regardless of whether or not the action is performed, the server must respond to the requesting client. The response is sent in the form of a status line with the following syntax:

Status Line <space> HTTP version <space> Status code <space> Reason phrase <CRLF>

Status codes are organized into classes that identify the generic response type. Table 21-2 lists the classes and meanings of status codes defined in HTTP/1.1.

Table 21-2. HTTP/1.1 Status Code Classes and Meanings
Number | Class | Indication
1xx | Informational | This indicates a provisional response and returns only a status line indicating status and optional headers. Essen tially, this is the server's method of responding with an acknowledgment message.
2xx | Successful | The server understands and accepts the client's request.
3xx | Redirection | The client needs to take further action to retrieve the requested resource. If the method used in the subsequent request message is GET or HEAD, the redirect can occur without any user intervention.
4xx | Client Error | The server believes that the client has performed an error. The server should provide an explanation of the error and indicate whether this is a permanent or temporary error. In addition, the server should wait for TCP acknowledgment of client receipt of the error message so it does not close the connection prematurely.
5xx | Server Error | The server is incapable of performing the request, the client is not allowed access to the resource, or a server error has occurred. The server should include an explanation of the error and indicate whether it is temporary or permanent.

Each class of status response has codes that the server returns to the client indicating specific information. Table 21-3 summarizes the individual codes that a server can return to a requesting client, as defined in RFC 2616. The messages listed are merely recommendations and can be customized without affecting the protocol.

Table 21-3. HTTP/1.1 Status Codes
Code | Message | Meaning
100 | Continue | The client should continue sending the remainder of the request; if the entire request has already been sent, the client ignores the message on receipt.
101 | Switching Protocols | The client has requested to switch to anotherapplication protocol by issuing an Upgrade message header.
200 | OK | The client's request has been successfully processed; remaining information returned varies according to the type of client request.
201 | Created | A new resource has been successfully created at the client's request.
202 | Accepted | The client's request has been accepted, but not yet processed. The server should indicate to the client when the request might be fulfilled or provide a pointer to a status monitor for the request.
203 | Non-Authoritative Information | The server would normally issue a 200 (OK) response, but the server is not authoritative for the information returned in the message. This indicates that the information was gathered from another source, and therefore this server cannot verify it.
204 | No Content | The server has fulfilled the client request, but does not need to return a new object. The server can, however, return information that causes the user interface to be updated.
205 | Reset Content | The server has fulfilled the client request and is instructing the user agent (client software) to reset the current document view. This is commonly used to allow a user to input form data, then clear the form so that more data can be entered.
206 | Partial Content | The client has issued a partial GET request, and the server has fulfilled that request. The server must indicate what portion of the requested data it has fulfilled for this particular GET.
300 | Multiple Choices | The requested resource exists in multiple locations, and the server is providing a list of these locations to the client. The server can indicate preference for a specific location, but the client chooses what it deems the appropriate location.
301 | Moved Permanently | The requested resource has been moved perma- nently and future requests for the resource should be directed to the location the server returns.
302 | Found | The requested resource exists elsewhere, but its location might change and the client should therefore continue to use the same request URI. Most browsers do not implement this correctly and treat a 302 response in the same manner as a 301 response.
303 | See Other | The response to the request exists under a different URI and should be retrieved using a GET method. The 303 response should not be cached, although the response received from the redirection location can potentially be cached.
304 | Not Modified | The client has performed a conditional GET, but the document has not been modified.
305 | Use Proxy | This response must be issued only by the server, and indicates that the requested resource must be accessed using the proxy provided in the response.
306 | Unused | This status code was used in previous implemen- tations of HTTP, has no function in HTTP/1.1, and is reserved.
307 | Temporary Redirect | The requested resource temporarily exists under a different URI, which should be provided to the client as a hyperlink to the new URI (for pre- HTTP/1.1 clients that do not understand the 307 code). Automatic redirection without user input should occur only if the client issued a GET or HEAD request that triggered this message.
400 | Bad Request | The client issued a malformed request that the server could not interpret and one that should not be issued again without modification.
401 | Unauthorized | The requested resource requires authentication; the server must issue a WWW-Authenticate challenge. If the client has already responded to a challenge response, this message indicates that the credentials presented do not have permission to access the resource.
402 | Payment Required | Reserved for future use.
403 | Forbidden | The server refuses to fulfill the request made by the client. The server can indicate why the refusal has been generated with this message, or can disguise the reason by issuing a 404 message instead.
404 | Not Found | The requested URI was not found on the server; the server is not required to give an indication as to whether this condition is temporary or permanent. This message is typically used when the server does not wish to reveal or does not know why the resource is unavailable.
405 | Method Not Allowed | The request method is not permitted on this URI. A list of valid methods for the URI must be returned as part of the response.
406 | Not Acceptable | The resource identified in the request is capable of generating responses only to the accept headers that it returns to the client, and not to the accept header that the client originally sent.
407 | Proxy Authentication Required | Similar to a 401 response, but indicates that the client must authenticate with the proxy that forwarded the request.
408 | Request Timeout | The server did not receive a request from the client within the time that the server was prepared to wait. The client can reissue the request later.
409 | Conflict | The request made by the client could not be ful- filled because it conflicts with the current state of the resource. Information can be returned that allows the user to correct the condition causing the conflict and then resubmit the request. This message is seen most often in response to PUT requests that can cause version conflicts in a resource.
410 | Gone | The requested resource is no longer available and its new location is unknown.
411 | Length Required | The server will not accept the request unless the client reissues the request with the addition of a valid Content-Length header field.
412 | Precondition Failed | The client issued a request containing precondition header fields and one or more of the fields evaluated to false. This allows the client to perform conditional requests.
413 | Request Entity Too Large | The request is larger than the server is capable of processing and is being refused. The server is permitted to close the connection with the client so that the request cannot be resubmitted.
414 | Request URI Too Long | The request URI is longer than the server is capable of accepting. This typically occurs when the user has input too much data into a form that is sent using a GET request.
415 | Unsupported Media Type | The client issued a request method that is not supported for the resource in question.
416 | Requested Range Not Satisfiable | The request included a Range Request header field that does not overlap with any of the values for the requested resource.
417 | Expectation Failed | The request included an Expect Request header that the server cannot fulfill.
500 | Internal Server Error | The server cannot fulfill the request because of an unexpected error.
501 | Not Implemented | The server does not recognize the request method and is incapable of fulfilling it.
502 | Bad Gateway | The server is acting as a gateway and received an invalid response from the requested server.
503 | Service Unavailable | The server is experiencing a temporary condition that causes it to be unable to fulfill the request, such as overloading or maintenance being performed.
504 | Gateway Timeout | The server is acting as a gateway or proxy and did not receive a response from the upstream server in time to process the request. Some proxies return this as a result of Domain Name System (DNS) timeout errors.
505 | HTTP Version Not Supported | This server does not support the HTTP version specified in the request message.
HTTP/1.1 status codes are defined in RFC 2616, which can be found in the \Rfc folder on the companion CD-ROM.

A typical server response line might appear as follows:

HTTP: Response (to client using port 4283)

     HTTP: Protocol Version = HTTP/1.1

     HTTP: Status Code = OK

     HTTP: Reason = OK

     HTTP: Content-Length = 176

     HTTP: Content-Type = text/html

     HTTP: Last-Modified = Tue, 27 Aug 2002 22:05:16 GMT

   + HTTP: Undocumented Header = Accept-Ranges: bytes

   + HTTP: Undocumented Header = ETag: "0b23ed3154ec21:68a"

     HTTP: Server = Microsoft-IIS/6.0

     HTTP: Date = Tue, 27 Aug 2002 22:06:49 GMT

     HTTP: Data: Number of data bytes remaining = 176 (0x00B0)

Note that this data does not appear to list the actual code number returned by the server to the client. However, analysis of the raw data sent shows that the following information was actually sent:

HTTP/1.1 200 OK

Status codes are extensible, meaning that server implementations can issue codes not listed in the preceding tables. Because the client might or might not understand the meaning of a particular extended status code, the code must be issued as an extension of an existing class. If the specific code number is unrecognized, the client responds as if it received a generic code from that class. For example, if the server issues error code 509 and the client does not recognize this code, it treats the error as a 500 error.

Header Fields

A client can generate request headers to query parameters regarding a resource or to negotiate content with the server. A server can issue response headers to provide information that cannot be included in the status line. Both request and response headers can indicate the presence of an entity to be transferred by including entity header fields and possible entity data. Although these field names cannot be universally extended without an accompanying change in the protocol version, extension headers can be used, provided both the client and the server understand them. Any header that is not recognized by the recipient is ignored. Internet Explorer sends nonstandard header fields to IIS 6, which is capable of utilizing them.

Headers can be either end-to-end headers or hop-by-hop headers. End-to-end headers are transmitted to the final message recipient, and must be stored as part of a cached entry. Proxies are forbidden to modify many end-to-end headers, cautioned against modifying others, and might or might not be permitted to add headers to a message. Hop-by-hop headers are useful only to the next recipient on a path, and proxies neither cache nor forward these headers.

Headers defined in RFC 2616 are summarized in Tables 21-4, 21-5, 21-6, and 21-7. Sender and recipient can refer to either the client or the server in these tables, as both can send messages containing header fields during the transaction.

Table 21-4. Request Header Fields
Header Name | Type | Interpretation | Example
Accept | End-to-end | Used to specify which media types are considered acceptable for the response. These might be limited to specific types of media, or might list groups of acceptable media. If no Accept header is present, it is assumed that all media types are acceptable. If the client issues an Accept header that the server is not capable of fulfilling, the server issues a 406 (Not Acceptable) response. | Accept: image/gif; image/x-xbitmap; image/jpeg; image/ pjpeg; */*. Gifs, bitmaps, and jpegs are acceptable media types; "*/*" indicates that all media are acceptable. "Image/*" would indicate that all image types are acceptable.
Accept-Charset | End-to-end | Indicates acceptable response character sets. If no Accept-Charset header is present, it is assumed that all character sets are acceptable. Character sets can be given an associated quality value, representing use preference for a given character set. | Accept-Charset: iso-8859-5, Unicode-1-1;q=0.8. Indicates that this client accepts both character sets listed, with a preference as indicated by codes assigned to the q value.
Accept-Encoding | End-to-end | Used to designate acceptable content codings, such as compress or gzip. Content coding is discussed later in this chapter. | Accept-Encoding: gzip, compress. Indicates that both gzip and compress codings are acceptable.
Accept-Language | End-to-end | Defines acceptable languages, such as English, German, and Japanese. | Accept-Language: en-us U.S. English will be accepted.
Authorization | End-to-end | Clients attempting to authenticate with a server will issue their credentials in the Authorization header. Results can be cached. | Authorization: Basic bWNO0Tg6bWN0ND-MyPQ==.
Expect | End-to-end | The client expects specific behavior from the server; if the server does not understand the Expect header, it must return a 417 (Expectation Failed) error. | Expect: 100-continue. Indicates that the client expects the server to continue the message exchange.
From | End-to-end | Used to identify the user that initiated this sequence of messages. Typically, this is utilized by robots that gather information. By providing the e-mail address of the robot's owner, the user can be contacted if the robot causes server problems. | From: owner@microsoft.com.
Host | End-to-end | Identifies the host name and port number of the owner of the requested resource. If no port number is specified, port 80 is assumed. This header is used to allow the server to distinguish between multiple sites responding to the same IP and TCP port. | Host: technet.microsoft.com.
If-Match | End-to-end | Used to make the request message conditional; generally, this is used to verify that the client's resource is current. | If-Match: *. Indicates that this allows a match with any current version of the resource, rather than a specific entity tag.
If-Modi fied-Since | End-to-end | Used to make a method conditional on whether the specified resource has been modified since a particular date. Used by the browser to determine if a specific resource has been updated since it was last cached. | If-Modified-Since: Sat, 11 Sept 1999 12:26:31 GMT.
If-None- Match | End-to-end | Used to facilitate efficient caching by verifying that there is no match on the server for the specified resource; also used by clients to ensure that a PUT method does not inadvertently replace a resource. | If-None-Match: "a0cde3e0c444be1:18e2." Indicates this value could be followed with a PUT method to place the resource on the server.
If-Range | End-to-end | A client can use this tag to determine whether a resource it has a partial copy of has changed. If the resource has not changed, the client might then be able to request the remainder of the entity range to obtain the complete resource. | If-Range: "a0cde3e0c444be1:18e2."
If-Unmodified-Since | End-to-end | Used to make a method conditional; the converse of the If-Modified-Since header field. | If-Unmodified-Since: Sat, 11 Sept 1999 12:26:31 GMT.
Max-Forwards | End-to-end | Used in conjunction with the Trace and Options headers to limit the number of proxies that can forward the request message. This is generally used to troubleshoot paths that are suspected to be looping back on themselves. | Max Forwards: 3.
Proxy-Authorization | Hop-by-hop | Used by a client to identify itself to a proxy that requires authentication. The proxy indicates this by the return of a 407 (Proxy Authentication Required) message to the client. | Proxy Authorization: Basic bQR0OTg6b-WN0NDMyNP==.
Range | End-to-end | Used to specify the portion of a resource that the client wants to retrieve. In some cases, this header can be used in conjunction with the If-Range header. This header allows a client to obtain part of a resource, rather than the entire resource. | Range: "a0cde3e0c444be1:18e2."
Referer | End-to-end | A client uses the Referer [sic] header (misspelled throughout the HTTP RFCs as well as in actual implementation) to inform a server where the client received the reference that directed it to the server for the Request URI message. | Referer: http://partnering.microsoft.com/exchange/pf/root.asp.
TE | Hop-by-hop | Indicates the extension transfer codings that the client is willing to accept in a response message. If this is accompanied by a trailers keyword, the client will accept the resource in chunked transfer coding, which means that it will accept the response as a series of pieces of the requested entity. This header applies only to the current connection and must be reissued as necessary. | TE: trailers, deflate. Indicates the client's willingness to accept resources in chunks that are deflate encoded.
User-Agent | End-to-end | Used to pass information regarding the software that the client is using to send its requests. Servers can then tailor their responses to the limitations or capabilities of this software. | User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Microsoft Windows NT; DigExt). Indicates that the browser software being used is Internet Explorer 5, and lists its capabilities.
Vary | End-to-end | Used to specify header fields that dictate whether a future response to a request for this resource can be issued from cache, rather than being re-retrieved from a server. | Vary: *. Can be issued by a server to dictate that a proxy cannot issue a response from its cache, as the server wishes to negotiate all content itself.
Table 21-5. Response Header Fields
Header Name | Type | Interpretation | Example
Accept-Ranges | End-to-end | Allows the server to specify whether it will accept range requests from a client, and in what format. | Accept-Ranges: bytes. Indicates that the server will accept range requests that are specified in bytes.
Age | End-to-end | The sender's estimate of the amount of time elapsed since it cached the named resource received from an origin server. Essentially, how old a cached entity is. | Age: 86,400. Indicates that the resource was cached 86,400 seconds previously.
ETag | End-to-end | The entity tag identifier; might be used to compare against other entities received from this source. | ETag: "077d777c8f1be1:189e."
Location | End-to-end | Used to redirect a client to another location for a requested resource, or, if it is part of a 201 (Created) response, to indicate where the new resource is located. | Location: /exchange/pf/root.asp.
Proxy-Authenticate | Hop-by-hop | Must be included as part of a 407 (Proxy Authentication Required) response, and includes the authentication scheme for the requested URI. This header is not passed farther down the path, as the authentication is to occur between the client and the proxy. | Proxy-Authenticate: Basic realm="Enterprise Server." RFC 2617, "HTTP Authentication: Basic and Digest Access Authentication," extensively describes authentication mechanisms.
Retry-After | End-to-end | Used by a server to inform a client as to how long a service is expected to be unavailable. Usually part of a 503 (Service Unavailable) response message or a 3xx (Redirection) response to direct the client to wait a specified amount of time before attempting to retrieve the requested entity. | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT. Tells the client to wait until a specified date before attempting to retrieve the resource, while the following example specifies a wait time in seconds: Retry-After: 240.
Server | End-to-end | Used by the server to indicate what software it uses to service HTTP requests. | Server: Microsoft-IIS/5.0.
WWW-Authenticate | End-to-end | Always issued as part of a 401 (Unauthorized) message to indicate the authorization scheme that the server requires the client to pass. | WWW-Authenticate: Basic realm="partnering. microsoft.com."
Table 21-6. Entity Header Fields
Header Name | Type | Interpretation | Example
Allow | End-to-end | List of methods allowed for the resource identified by the Request-URI message. This does not prevent a client from requesting a disallowed method. If a client requests a method that is not allowed for a resource, the server issues a 405 (Method Not Allowed) error and must include an Allow header in the response so that the client can adjust its request. | Allow: GET, HEAD, PUT, POST. Specifies that the GET, HEAD, PUT, and POST methods are acceptable for the identified resource.
Content-Encoding | End-to-end | Specifies encoding methods applied to the resource specified in the Request-URI message so that the message recipient knows which decoding mechanisms to apply. | Content-Encoding: gzip. Specifies the type of encoding used to compress the requested resource.
Content-Language | End-to-end | Defines the natural language of the entity being transferred. | Content-Language: en-us. Language content is U.S. English.
Content-Length | End-to-end | Specifies the length of the entity body in a decimal number of octets. | Content-Length: 4110. Indicates a length of 4110 octets.
Content-Location | End-to-end | A server can use this to specify the resource location that the client requested, particularly if the resource is accessible from a separate location than was originally requested in the client message. This value is also used to set the base URI. | Content-Location: http://192.168.0.1/Default.htm. Specifies Default.htm at the listed IP address as the base URI for the requested resource.
Content-Range | End-to-end | When a server returns a partial entity body in its response, it uses Content-Range to specify the range of the full entity that is covered by this partial partial entity. Essentially, this is a marker to identify the portion of the resource being sent. Servers returning status codes 206 (Partial Content) or 416 (Requested Range Not Satisfiable) utilize the Content-Range header field. | Content-Range: bytes 500-999/1500. Informs the client that the range encompasses bytes 500-999 of a 1500-byte resource.
Content-Type | End-to-end | Identifies the media type of the entity being sent. | Content-Type: text/html. Indicates the message being sent consists of HTML text.
Expires | End-to-end | The resource specified is considered stale at its expiration date and should not be returned from the cache at that point; rather, the resource should again be retrieved from the server. | Expires: Mon, Nov 16 1999 17:38:01 GMT.
Last- Modified | End-to-end | Indicates the date that the server believes to be the last modification date for the resource in question. | Last-Modified: Sun, 29 Aug 1999 02:44:51 GMT.
Table 21-7. General Header Fields
Header Name | Type | Interpretation | Example
Cache-Control | End-to-end | Issues directives regarding cacheability of this information that must be obeyed by all points along the request chain. HTTP/1 caches that do not implement Cache-Control can simply assume the entity is not cacheable. | Cache-Control: private. Indicates that the server is issuing a message that cannot be cached by any intermediary points, as the content is privately cacheable only by the client that requested it.
Connection | Hop-by-hop | Used to specify options for a single connection along the path; must not be propagated farther along the path. Any headers included in the connection header must not include end-to-end headers. | Connection: keepalive. Indicates that the connection between these two points is to be kept open after this message is forwarded. An HTTP/1 recipient might not be capable of interpreting a keepalive, and therefore might remove and ignore the header fields pertaining to the keepalive.
Date | End-to-end | Indicates the date and time that this message originated. | Date: Fri, 03 Sep 1999 00:58:28 GMT.
Pragma | End-to-end | Used to provide instructions to each recipient of the message along the path. These directives are implementation-specific, and therefore might be ignored by proxies that do not understand their meaning. However, the proxy is required to forward the header whether or not it understands its directives. | Pragma: no-cache. Specifies that a proxy is expected to pass the request message on to a server even though the proxy might already have the requested item in its own cache.
Trailer | Hop-by-hop | Used to inform a client that there are header fields in this message pertaining to chunked transfer encoding, so that the client can know that it needs to use these for decoding and reassembly. | Trailer: Range. Indicates the presence of a Range header in this message.
Transfer-Encoding | Hop-by-hop | Used to indicate what type of encoding has been applied to the body of the message, so that the recipient can determine how to decode it. | Transfer-Encoding: Chunked, deflate. Indicates the encoding applied to this message, in the order in which it was applied.
Upgrade | Hop-by-hop | Frequently issued by a server as part of a 101 (Switching Protocols) message to indicate additional communication protocols that it supports. The client can also use this header for negotiating the protocols to be used. Because this header applies only to the current connection, it must be supplied as part of a Connection header. | Upgrade: HTTP/1.2, SHTTP/1.3, IRC/7.0.
Via | End-to-end | Must be used by proxies and gateways to indicate the protocols and intermediate recipients between the requesting client and the issuing server. This is used for purposes of tracking the path of a request/response transaction. | Via: 1.0 microsoft.com, 1.1 technet.microsoft.com (Microsoft-IIS/5.0). Specifies the order of the hops made and the HTTP server program running at those hops, in this case, IIS 5.
Warning | End-to-end | Used to issue warnings regarding message content. These warnings are issued in human-readable language. | Warning: 110 Response is stale. Indicates that the message has exceeded its freshness lifetime, or the indicator of how long the entity can be considered accurate.

HTTP Codings

HTTP uses content codings to specify data transformation mechanisms, such as compression, that have been applied to an entity. By specifying the coding method in header fields, client and server applications can determine how to decode the entity to make it legible. Content codings are registered with the Internet Assigned Numbers Authority (IANA), and include the following:

  • GNU's Not Unix (GNU) Zip (Gzip) A file compression format defined in RFC 1952.
  • Compress A UNIX compression-encoding format.
  • Deflate A combination of the zlib and deflate encoding and compression mechanisms defined in RFCs 1950 and 1951.
  • Identity The default encoding mechanism, which indicates that there is no encoding performed on the entity.

Transfer Codings

Transfer codings are used to ensure safe passage of an entity through the request/response path. Transfer coding is not an entity property, as is content coding. Rather, transfer coding is applied to the entire entity message body. Transfer coding values indicate whether encoding has been or can be applied to the message. If transfer coding is applied to a message, the values must indicate whether the data has been chunked, or broken into more manageable pieces. This coding must not be applied more than once to the message body so that a client can accurately determine message transfer length. Any server that receives transfer coding values it does not understand should return a 501 (Not Implemented) response so that the client can request or apply a different encoding mechanism. The encoding formats used for transfer encoding are the same as those listed for content coding, with the addition of the chunked value.

Chunked Transfer Coding

Chunked transfer coding is used to modify the body of a message so that it can be sent as a series of smaller pieces. Each chunk is sent with its own size information and, possibly, entity headers, so that the recipient can accurately determine whether it has received all the chunks that comprise the message. HTTP/1.1-compliant applications are required to be capable of receipt and decoding of chunked transfer coding, and must ignore any extensions to transfer coding values that they do not understand.

HTTP Content Negotiation

Content negotiation is the process by which the HTTP client and server determine the preferred representation for a response. Client software might be able to interpret only specific entity media types, as might also be the case at the server. Additionally, user preferences for parameters, such as language and file format, affect the negotiation process. Content negotiation can be said to be agent-driven, wherein the client chooses the best media representation after receiving a response from a server; server-driven, meaning that the server specifies preferred representations; or transparent, which is a combination of both agent-driven and server-driven negotiation.

Agent-Driven Content Negotiation

In agent-driven negotiation, the client software, called a user agent, issues a request message to a server that indicates its own capabilities by means of header fields, such as Accept, Accept-Charset, and Accept-Language. When the server receives this request, it responds with a message indicating its own capabilities, and the user agent then responds with its own choice of representation from the list provided by the server.

Agent-driven negotiation is advantageous when the user wants to dictate certain content parameters, such as the language used to display a Web page, or when the server cannot ascertain the client's capabilities by analyzing its request message. Additionally, load balancing for heavily trafficked servers can be provided using public caches (additional servers or proxies that maintain cached copies of the information on the origin server), and agent-driven negotiation can be used to determine message parameters with the computers providing these caches. However, agent-driven negotiation has the disadvantage of requiring additional message transfer between client and server, because the client must first request a listing of the server's capabilities before choosing a message format.

Most Web client interactions, as illustrated in Capture 21-01, do not use agent-driven content negotiation.

Server-Driven Content Negotiation

In server-driven content negotiation, the server uses an algorithm to select what it considers to be the best format for messages between itself and the client. The server can base its determination on parameters it receives in the client's request message, as well as on its own capabilities, and even parameters such as the requesting client's network address. Server-driven negotiation allows the server to send the requested entity in its initial response package, as determined by its best guess as to which media type the client prefers (based on header fields such as Accept, Accept-Charset, and Accept-Language), rather than waiting for another request after the client has received a response and chosen from the list of available formats.

Server-driven negotiation reduces the number of messages that need to be transferred to determine acceptable media types, but also has several disadvantages. First, this type of negotiation requires the server to guess what the preferred format on the client's end is, which might or might not match what the user prefers. Second, because this negotiation type requires the user agent to describe its capabilities in each request it makes to the server, it might be inefficient and might also violate the user's privacy. Third, the server must perform additional processing for each response to determine the optimal format for that response. Last, servers that are providing public caches to facilitate load balancing for another server might not be able to service requests for different users from their caches, because each user agent might provide different parameters.

Transparent Content Negotiation

Transparent content negotiation provides a combination of both agent-driven and server-driven negotiation mechanisms. When a cache receives a client request containing parameters that it can fulfill, it can negotiate the content format itself, rather than forwarding the request parameters to the origin server. In this case, the cache is acting as the server would in server-driven negotiation, thus saving work at the server that originally provides a resource. HTTP/1.1 does not provide any guidelines for transparent negotiation, although many implementations provide their own mechanisms as extensions of HTTP/1.1.

HTTP Caching

To make HTTP as efficient as possible, clients, servers, proxies, and gateways can cache content retrieved as part of the request/response process. The server specifies caching in HTTP/1.1. The originating server for any resource decides whether or not other machines along the path should cache a message. Servers might specify that a message cannot be cached by any computer, must be cached by these computers, or can be cached based on variables, such as the age of the message. Originating servers do not, however, always assign dictates as to whether or not, or for how long a message can be cached, so caches also use a mechanism called heuristic expiration. In heuristic expiration, a cache uses information contained in message headers to estimate the point at which the message can be considered stale, and thus would need to be re-retrieved, should it be requested. Microsoft ISA Server, for example, enables the administrator to set time to live (TTL) values on cache content based on headers or static settings.

Because this is inherently unreliable in providing accurate gauges for message freshness, HTTP/1.1 strongly encourages servers to provide explicit expiration on any responses they send. RFC 2616 outlines implementation details for caching and content expiration.


FTP

FTP, defined in RFC 959, is one of the older application protocols. Although HTTP is perhaps better known, FTP has been a mainstay of file transfer on the Internet for a considerable time. Microsoft IIS 6 implements a full-featured FTP server service and Windows .NET Server 2003 includes a simple command-line FTP client and FTP functionality in Internet Explorer. Although additions to FTP have been proposed in several RFCs and drafts, its core functionality remains largely unchanged. This chapter does not provide instruction in how to use the FTP client, but instead defines the protocol itself.

User documentation and instructions for using FTP are found in RFCs 412, 959, and 1635, which can be found in the \Rfc folder on the companion CD-ROM.

FTP is used to share and transfer files between computers, as well as use other computers for remote storage purposes. As is the case with HTTP, FTP is an Application Layer protocol that relies on TCP to ensure guaranteed delivery of data. Although the RFC definition of FTP does not provide any true method for recovering a lost connection and picking up file transfer where it left off, IIS 6 implements a process called FTP restart to add this functionality.

FTP is an inherently nonsecure protocol because it transmits user passwords as clear text. To help provide secure mechanisms to be used in FTP transmissions, security extensions to the FTP protocol are defined in RFC 2228, although IIS 6 does not implement these.

As with HTTP, FTP has its own unique terminology, some of which is defined in the following list:

  • FTP commands Commands issued between two computers in an FTP session to control the flow of information from one computer to the other.
  • Control connection A connection established between client and server components for the exchange of FTP commands and replies.
  • Reply An acknowledgment sent by the server over the control connection in response to client commands.
  • Data connection A full-duplex connection established for the purpose of transferring data between two computers, whether they are made up of a client and a server or two servers. This connection is separate and distinct from the control connection.
  • Data Transfer Process (DTP) The entity that establishes data connections, as well as managing connections once they have been opened. A DTP can be active, meaning that it is listening for connections between client and server, or passive, meaning that data is currently being passed and the DTP is idle.
  • Protocol Interpreter (PI) On the client side of an FTP session, the user PI initiates a control connection from the client port to the server FTP process, as well as issuing commands from client to server. On the server side of an FTP session, the server PI listens for a user PI connection and commands, and governs the issuing of responses and the server DTP. The server PI and server DTP comprise the server FTP process.

These components are shown in Figure 21-1.

Figure 21-1. FTP components.

FTP Operation

FTP is a client/server protocol that uses two connections between client and server, unlike SMTP, HTTP, and NNTP, which use a single connection. With FTP, a control connection is established to communicate between client and server, and data connections are established to transfer files between an FTP client and server.

FTP Connections

FTP connections are established between an FTP client and an FTP server. An FTP session between client and server can be initiated either by a user, through an FTP client interface, or programmatically on Windows Server 2003 using the Win32 application programming interface (API). In any case, the user PI initiates the actual connection. The user PI is responsible for opening a TCP connection to the FTP server and for sending a command to the server PI requesting that an FTP connection be opened between them. The server PI listens for connection requests on TCP port 21 by default, and after receiving a connection request from a user PI, begins the process of establishing a control connection.

Every FTP session actually consists of two separate connections—a control connection and a data connection. The control connection follows Telnet specifications, and it is used to negotiate communication parameters, issue commands and responses, and monitor the status of any data connection that is opened between the two computers. The task of opening and monitoring the data connection is handled by the DTP components on both the FTP client and server. The data connection is the actual mechanism over which data transfer occurs. Whereas a data connection can be dynamically opened and closed in a single session between the two computers, the control connection always remains open for the duration of a single session.

A user can initiate an FTP session between a client and server by using FTP client software. Windows Server 2003 includes a simple command-line FTP client, and Internet Explorer provides GUI-based FTP features. The client FTP program includes both the user PI and user DTP components shown in Figure 21-1. This enables the client to initiate a control connection between the client and the FTP server (comprised of the server PI and server DTP).

In Windows Server 2003, you can use a Web browser, such as Internet Explorer, to make and utilize an FTP connection to an FTP server. You can also use the built-in FTP tool simply by typing FTP <hostname or IP address of an FTP server> from the command prompt.

After the control connection has been established between FTP client and server, the user can issue commands to the server that open a data connection between the two computers. Data is then passed bidirectionally (full-duplexed) over this connection. When the data transfer is complete, the data connection can be closed, although the control connection remains open until the user initiates its disconnection and the server performs the actual process of closing the connection. Figure 21-2 diagrams this process.

Figure 21-2. A client/server FTP session.

The following trace shows a simple FTP session between an FTP client and server, in which the client connects, downloads a single file, and then disconnects:

C:\>ftp kapoho10.kapoho.com

Connected to kapoho10.kapoho.com.

220-Microsoft FTP Service

220 KAPOHO10 FTP

User (kapoho10.kapoho.com:(none)): ftp

331 Anonymous access allowed, send identity (e-mail name) as password.

Password:

230-Welcome to FTP service at Kapoho10

230 Anonymous user logged in.

ftp> get rebecca.txt

200 PORT command successful.

150 Opening ASCII mode data connection for rebecca.txt(16 bytes).

226 Transfer complete.

ftp: 16 bytes received in 0.00Seconds 16000.00Kbytes/sec.

ftp> quit

221

C:\>

The trace for this short FTP session is in Capture 21-02 on the companion CD-ROM.

In theory, an FTP client can request an FTP server to create a data connection to another FTP server. This process is allowed in the FTP RFC, but it is rarely implemented. Most popular FTP clients create data connections only between the FTP client and server systems.

FTP Data

FTP data transfer occurs over the data connection between the FTP server and FTP client. The control connection is reserved for passing and receiving FTP commands that control the session, as well as exchanging data transfer parameters. The sender and receiver in any FTP session negotiate the data transfer format to ensure that the receiving end can correctly reconstruct the data that is sent.

Because each computer can store its data in its own specific logical byte sizes (the number of bits that comprise a data byte on the disk), mechanisms must be in place to ensure that the data sent to the receiving computer is transmitted in an agreed-on format. The FTP specification provides for specific data structures and data type representation, although most FTP servers and clients only use ASCII or binary data transfer.

Data Structures

FTP classifies three different data structures, or characteristics, of a file stored on the computer. Some systems store data as a series of fixed-length records, whereas other computers store data as a series of characters and separators. Because of the disparity in storage formats, transfers of data must be made in a format that the sending and receiving computers can both reconstruct and write appropriately to their own disks. In FTP, these structures are defined as file structure, record structure, and page structure, as described here:

  • File structure This data is stored as a continuous series of bytes that have no internal structure, such as record markers. File structure is the default data structure used in FTP transfers and is assumed by both parties unless a command is issued specifying one of the other structures.
  • Record structure This data is stored on disk as a series of sequential records. All FTP implementations are required to accept record structures for text files, whether the text is in ASCII or Extended Binary Coded Decimal Interchange Code (EBCDIC) format.
  • Page structure These files can be discontinuous data, containing sections of file data interspersed with descriptors of that data. FTP refers to these file sections as pages.

When page structure data is sent between two hosts using FTP, each page must be sent with a page header comprised of 1-byte fields that provide informational parameters. Each header begins with a Header Length field that defines the number of bytes comprising the header. Following this is a page index, or number, that identifies this page's place in the overall file, and a Data Length field that specifies the length of the page data itself. The next field in the header identifies the page type, which can be a normal data page; a descriptor page that defines properties for the file; an access-controlled page, which provides information about access control to the file; or the last page in the file. There might also be optional header fields that define properties, such as access control to the individual page.

Data Types

Within each of the data structures defined in FTP, data can be stored as different data types. These data types define the on-disk byte size of the file data. Some data types provide explicit definition of data byte size, whereas others provide implicit definition by using logical byte size. Acceptable data types in IIS FTP transfers are defined in the following list:

  • ASCII type Default data type used in FTP transfers, which must be accepted by all compliant implementations of FTP. ASCII is most often used for the transmission of text files. In an ASCII transfer, the sending computer retrieves the requested file from its own disk in whatever format was used to store it. The file is then converted to ASCII, which dictates 8-bit character bytes, and transmitted in 8-bit increments (transfer byte size is always 8 bits, regardless of data type). The receiving computer reassembles the 8-bit ASCII text and stores it to disk in its own native format.
  • Image type Sent as a continuous stream of bits that the receiving computer must store as a series of contiguous bits. The recipient might need to pad the end of each file or record (depending on its own internal storage mechanisms) with 0s that are stripped off when the file is retrieved. This data type is most efficient for files that need to be stored in binary format, as opposed to ASCII text (executable files versus text documents, for example).

Connections and Transmission Modes

To transmit data between a client and server using FTP, both a control connection and a data connection must be established. The control connection is used both to set parameters for the data connection and to monitor the passage of data over the data connection. Although the control connection remains open during the entire client/server FTP session, multiple data connections can be dynamically opened and closed.

Data Connection Establishment and Management

FTP connections between client and server are initiated by the user PI. The FTP server listens on TCP port 21 (by default) for connection requests. When the server PI hears a connection request from a user PI, it opens a control connection. The use of nondefault ports for connections can only be initiated by the user PI, and not the server PI. When the client issues a command that initiates data transfer, the server DTP opens a data connection and data transfer begins. Both user DTP and server DTP monitor the connection to determine which computer might be sending or receiving at any given time.

The initial connection, logon, and data transfer process, based on the earlier FTP session and shown in Capture 21-02, is as follows:

1   1.791683   FTP Client  DNS Server  DNS  0xA2A:Std Qry for
kapoho10.kapoho.com. of type Ho 10.10.1.68  10.10.1.200

2   1.791683   DNS Server  FTP Client  DNS  0xA2A:Std Qry Resp. for
kapoho10.kapoho.com. of t 10.10.1.200  10.10.1.68

3   1.801697   FTP Client  FTP Server  TCP  ....S., len:    0, seq: 476820006-
476820006, ack: 10.10.1.68  10.10.1.74

4   1.811712   FTP Server  FTP Client  TCP  .A..S., len:    0, seq:2161805281-
2161805281, ack 10.10.1.74  10.10.1.68

5   1.811712   FTP Client  FTP Server  TCP  .A...., len:    0, seq: 476820007-
476820007, ack: 10.10.1.68  10.10.1.74

6   1.811712   FTP Server  FTP Client  FTP  Resp. to Port 2413, `220-Microsoft
FTP Service'  10.10.1.74  10.10.1.68

7   2.012000   FTP Client  FTP Server  TCP  .A...., len:    0, seq: 476820007-
476820007, ack: 10.10.1.68  10.10.1.74

8   2.032029   FTP Server  FTP Client  FTP  Resp. to Port 2413, `220 KAPOHO10
FTP'  10.10.1.74  10.10.1.68

9   2.212288   FTP Client  FTP Server  TCP  .A...., len:    0, seq: 476820007-
476820007, ack: 10.10.1.68  10.10.1.74

10  3.053497   FTP Client  FTP Server  FTP  Req. from Port 2413, `USER ftp'
10.10.1.68  10.10.1.74

11  3.063512   FTP Server  FTP Client  FTP  Resp. to Port 2413, `331 Anonymous
access allowed 10.10.1.74  10.10.1.68

12  3.213728   FTP Client  FTP Server  TCP  .A...., len:    0, seq: 476820017-
476820017, ack: 10.10.1.68  10.10.1.74

13  9.953419   FTP Client  FTP Server  FTP  Req. from Port 2413, `PASS
tfl@kapoho.com'  10.10.1.68  10.10.1.74

14  9.963433   FTP Server  FTP Client  FTP  Resp. to Port 2413, `230-Welcome
to FTP service a 10.10.1.74  10.10.1.68

15  10.123664  FTP Client  FTP Server  TCP  .A...., len:    0, seq: 476820038-
476820038, ack: 10.10.1.68  10.10.1.74

16  10.123664  FTP Server  FTP Client  FTP  Resp. to Port 2413, `230 Anonymous
user logged in 10.10.1.74  10.10.1.68

17  10.323952  FTP Client  FTP Server  TCP  .A...., len:    0, seq: 476820038-
476820038, ack: 10.10.1.68  10.10.1.74

18  15.180936  FTP Client  FTP Server  FTP  Req. from Port 2413, `PORT
10,10,1,68,9,111'  10.10.1.68  10.10.1.74

19  15.190950  FTP Server  FTP Client  FTP  Resp. to Port 2413, `200 PORT
command successful. 10.10.1.74  10.10.1.68

20  15.190950  FTP Client  FTP Server  FTP  Req. from Port 2413, `RETR
rebecca.txt'  10.10.1.68  10.10.1.74

21  15.190950  FTP Server  FTP Client  FTP  Resp. to Port 2413, `150 Opening
ASCII mode data  10.10.1.74  10.10.1.68

22  15.200965  FTP Server  FTP Client  TCP  ....S., len:    0, seq:1569488684-
1569488684, ack 10.10.1.74  10.10.1.68

23  15.200965  FTP Client  FTP Server  TCP  .A..S., len:    0, seq:3313623390-
3313623390, ack 10.10.1.68  10.10.1.74

24  15.200965  FTP Server  FTP Client  TCP  .A...., len:    0, seq:1569488685-
1569488685, ack 10.10.1.74  10.10.1.68

25  15.200965  FTP Server  FTP Client  FTP  Data Transfer To Client, Port =
2415, size 16  10.10.1.74  10.10.1.68

26  15.200965  FTP Server  FTP Client  TCP  .A...F, len:    0, seq:1569488701-
1569488701, ack 10.10.1.74  10.10.1.68

27  15.200965  FTP Client  FTP Server  TCP  .A...., len:    0, seq:3313623391-
3313623391, ack 10.10.1.68  10.10.1.74

28  15.220993  FTP Client  FTP Server  TCP  .A...F, len:    0, seq:3313623391-
3313623391, ack 10.10.1.68  10.10.1.74

29  15.231008  FTP Server  FTP Client  TCP  .A...., len:    0, seq:1569488702-
1569488702, ack 10.10.1.74  10.10.1.68

30  15.331152  FTP Client  FTP Server  TCP  .A...., len:    0, seq: 476820079-
476820079, ack: 10.10.1.68  10.10.1.74

31  15.331152  FTP Server  FTP Client  FTP  Resp. to Port 2413, `226 Transfer
complete.'  10.10.1.74  10.10.1.68

32  15.531440  FTP Client  FTP Server  TCP  .A...., len:    0, seq: 476820079-
476820079, ack: 10.10.1.68  10.10.1.74

33  17.654493  FTP Client  FTP Server  FTP  Req. from Port 2413, `QUIT'
10.10.1.68  10.10.1.74

34  17.654493  FTP Server  FTP Client  FTP  Resp. to Port 2413, `221  `
10.10.1.74  10.10.1.68

35  17.664507  FTP Client  FTP Server  TCP  .A...F, len:    0, seq: 476820085-
476820085, ack: 10.10.1.68  10.10.1.74

36  17.674521  FTP Server  FTP Client  TCP  .A...., len:    0, seq:2161805598-
2161805598, ack 10.10.1.74  10.10.1.68

37  17.674521  FTP Server  FTP Client  TCP  .A...F, len:    0, seq:2161805598-
2161805598, ack 10.10.1.74  10.10.1.68

38  17.674521  FTP Client  FTP Server  TCP  .A...., len:    0, seq: 476820086-
476820086, ack: 10.10.1.68  10.10.1.74

When an active transfer is occurring, the DTP on the receiving computer is passive and the DTP on the sending computer is actively controlling data transfer. Because the data connection is automatically closed after completion of a data transfer, a data connection can be kept open either by negotiating a nondefault port before beginning transfer, or by switching to a different transfer mode for the file(s) in question.

FTP defines the three transfer modes covered in the following list.

  • Stream mode In stream mode data transfer, the data is sent as a series of bytes, with little or no processing performed on the data before it is sent. Data that is sent in stream mode can be of any representation type (file, record, or image). If file structure data is sent, the end of the file is indicated when the sending computer closes the data connection. If the data being sent is record structure, each record is followed by a two-character control code that indicates the end of the record; the end of the file itself is indicated by a similar control code.
  • Block mode Block mode data is sent as a series of data blocks with no filler bits, preceded by header bytes that contain a Count field and possible descriptor code. The Count field indicates each block's length in bytes. The descriptor code indicates whether this is the last block in either the record or the file, whether the data is suspected to contain errors (possibly because of bad media), or to identify a restart marker, which is described later in this section. Any data representation type can be used in block mode, and record structures are permitted.
  • Compressed mode Compressed mode data is sent as three types of information: regular data, compressed data, and control information. Regular data is sent as a simple byte string. Compressed data uses an algorithm to compress filler bytes and represent them with a single filler byte, thus decreasing the actual number of bytes that need to be sent. Control information is sent as a 2-byte escape sequence and descriptor code, which are the same codes used in block mode data transfer, including a possible restart marker.

FTP Restart

FTP restart provides a mechanism for resuming file transfers that were interrupted before completion. FTP restart is a feature of the FTP service in Windows Server 2003. FTP itself provides little in terms of recovery mechanisms, but it does provide for the insertion of restart markers in both block and compressed data modes. When an FTP server implements FTP restart, it periodically sends a restart marker (essentially a place marker) in the data being transferred to the receiving computer.

The receiver collects these restart markers, and if the data connection is lost, it can use them to resume the file transfer where it was interrupted. After resuming the connection between itself and the server, the client first queries the server to determine if the file has changed since the interruption of the transfer. If the file has not changed, the client issues the last restart marker value to the server and requests that the transfer be resumed at that point. If the file has changed since the data transfer interruption, the client requests that the entire file be transmitted from the beginning.

Although the server inserts restart markers only in transmission of block or compressed data, stream data can also be recovered if the connection is lost. Because stream data is sent simply as a series of bytes, the client need only calculate the byte offset of the last data it received and then request the server to resume the file transfer at that offset point.

FTP restart commands are not used only when a connection has been broken. Some FTP clients send the command REST 0 before downloading a new file from a server. This command is used to ensure that the data transfer begins with the first byte of the requested file.

FTP Commands and Responses

FTP communication between an FTP client and server is transmitted as a series of commands that the client needs fulfilled, and responses from the server. This process is similar to the HTTP request/response functionality in HTTP communication.

FTP Commands

The user PI issues commands over the control connection to initiate file transfer. FTP commands can be commands that verify the user's identity with the FTP server, such as USER, ACCT, and PASS; commands that navigate the file system on the remote host, such as CDUP, XCUP, and CWD; session origination and termination commands, such as QUIT, BYE, and REIN; or commands that control the parameters of file transfer as well as the transfer itself, such as PORT, TYPE, MODE, GET, PUT, RETR, and STOR.

FTP Replies

Similar to other Internet type services, FTP servers issue reply codes in response to client commands. These extensible reply codes are sent in the form of a three-digit number, with the value of the first and second digits indicating the type of response.

  • The first digit in an FTP response code indicates the general type of response the server wants to pass to the client.
  • The second digit is used to provide a more specific indication of the meaning of the response.
  • Values for the third digit in a response code are extensible, meaning that they can be customized for specific implementations.

Tables 21-8 and 21-9 describe the representations of the first and second digits in response codes. As an example of response-code meanings, a server issuing code 250 would indicate that the requested file system action was successfully completed; the 2 indicates success, and the 5 indicates a file system operation.

Table 21-8. FTP Response Codes—First-Digit Values
First-Digit Value | Indicator | Description
1yz | Positive Preliminary Reply | The requested action is being processed; another command cannot be sent until another reply is received from the server.
2yz | Positive Completion Reply | The requested action has been completed and a new command can now be sent.
3yz | Positive Intermediate Reply | The requested action is accepted, and continues processing pending further information from the client, which should now be issued.
4yz | Transient Negative Completion Reply | A temporary error has occurred that prevented processing of the command, and the user should now reissue the command (or command sequence).
5yz | Permanent Negative Completion Reply | An error has occurred that prevented processing of the command; the command should not be reissued without modification. This modification might be as simple as correcting a misspelling, or this error might indicate a nontransient server error.
Table 21-9. FTP Response Codes—Second-Digit Values
Second-Digit Value | Indicator | Description
x0z | Syntax | There is a syntax error, the issued command is unimplemented by the server, or the server does not recognize the command category.
x1z | Information | Replies to information requests, such as help.
x2z | Connections | Refers to control and data connections.
x3z | Authentication and Accounting | Replies to user logon or accounting procedures.
x4z | Unspecified | Unspecified.
x5z | File System | File system status as it relates to the requested transfer or command.


NNTP

NNTP provides a user with the ability to submit news articles to a news server. NNTP also enables these articles to be propagated to other news servers, thus providing peer-to-peer discussion groups that are global in nature.

The network news facility was a feature of ARPANET, which preceded today's Internet. Almost all Internet service providers (ISPs) today allow access to some form of news, and there are third-party companies that run news servers for individual subscribers as well as for smaller ISPs that outsource their news provision.

In the early days, "news" included bulletins about the ARPANET, details supporting information, and actual data. Today, there are tens of thousands of newsgroups available that cover just about any human activity. Some of the news servers are private and require specific permission to access. Some news servers are provided by individual companies (for example, news.microsoft.com) as part of the support of their products. Most ISPs provide news access to their customers.

The basic operation of NNTP is described in RFC 977. Some common extensions to NNTP are described in RFC 2980. The format of NNTP news articles is described in RFC 1036. Although never issued as a formal RFC, Henry Spencer's "Son of 1036" is considered best practice for newsreaders and servers in terms of message formats. You can obtain this document from ftp://ftp.zoo.toronto.edu/pub/news.txt.Z (for the text version) or ftp://ftp.zoo.toronto.edu/pub/news.ps.Z (for the PostScript version).

NNTP is a client/server protocol that runs over TCP. It has many similarities to FTP and SMTP. NNTP is used in two different situations. The first enables an NNTP client program to post and retrieve news messages from a news server's news base. The second enables two NNTP servers to transfer articles, thus propagating them across a network of NNTP servers.

As with other Internet protocols, NNTP has its own unique terminology, some of which is defined in the following list:

  • News client A news client is a program run on a client computer that enables a user to read and compose news articles. Some news clients require the user to be actively connected to a news server. Other news clients allow the user to read and compose offline, which is popular for dial-up users because it can reduce their online time. Microsoft provides Outlook Express as a newsreader client in most recent versions of Windows.
  • News server A news server is a server process that manages a set of news articles and enables news clients to read existing articles and compose new ones. IIS 6 includes a basic news server product. Microsoft Exchange 2000 provides a fuller news service.
  • News article A news article is a single item of news not dissimilar to an e-mail message. It is composed on a news client and sent to the news server using NNTP. The news server on which the post was first made can be configured to replicate this message to other news servers that do not already have it. A news article consists of several header lines, followed by a blank line, followed by the body of the news article.
  • Article headers Each news article has a series of header lines that consist of a keyword, a colon, a blank, and some additional information. The FROM: header, for example indicates who the article is from. The details of the news message format are contained in RFC 1036 (and the "Son of 1036" document mentioned earlier).
  • Article body The article body is the content of the article, the information the sender wishes to propagate to the other users of a particular newsgroup.
  • Article number NNTP servers are expected to include an article number. This is a monotonically increasing number starting with 1. A given server for a given group might have some of the articles that have been posted to the group, the first of which might be greater than 1. It is also possible that there could be gaps.
  • Internal current article pointer When a news client is accessing a news server and retrieving news articles, the server maintains a current article pointer. Set to the start of a group when the group is first selected, this pointer is automatically advanced as articles are read. This feature is used in online newsreaders to simplify their communication with the server.
  • Newsgroup A newsgroup is a collection of articles, generally on a single subject. Newsgroups are stored in a folder on the news server, typically with each article being a separate file. The server can then provide articles in this group to a news client when requested.
  • News hierarchy The news hierarchy is a set of groups with a common root. For example, the hierarchy uk.* consists of a set of groups about or relating to the United Kingdom, and comp.* is a large hierarchy that relates to computing matters. Hierarchies vary in how well groups propagate, with some hierarchies being truly global and others being more regional. Hierarchies can have specific rules and guidelines about how new groups are created. For uk.*, the rules are set out at http://www.usenet.org.uk. There are hundreds of news hierarchies available. See http://www.magmacom.com/~leisen/mlnh/mlnhtables.html for a reasonably up-to-date list of existing global and regional news hierarchies.
  • News base The news base is the set of all the articles in all the hierarchies held by a single news server. This is sometimes referred to as the news spool.
  • Usenet Usenet is a set of eight news hierarchies. Often referred to as the Big 8, Usenet formally consists of the hierarchies biz.*, comp.*,humanities.*, misc.*, news.*, rec.*, sci.*, and soc.*. Usenet is often thought of as incorporating the alt.* hierarchy as well. Most ISPs provide unrestricted access to all of the groups in the main Usenet hierarchy as well as some or all of the alt.* hierarchies.
  • Propagation For hierarchies or groups that are held on more than one news server , you can configure your server to propagate the articles to peer servers. Through propagation, articles are transferred to all news servers configured to carry the specific group.
  • Expiry Expiry is the process a news server goes through to purge older articles.
  • Peer server A peer server is a news server that another news server can send articles to or obtain articles from. ISPs offering a news service could have a large number of peers.
  • Cross post In some cases, a poster might want to send an article to two or more newsgroups. To avoid posting the same article multiple times, you can send one copy with multiple newsgroups contained in the newsgroup header. Any news client that reads any of the groups can retrieve the article.
  • Flood fill Flood fill refers to the mechanism that NNTP servers use to propagate articles. When an article is posted on a server, that server attempts to offer it to all news peers. These peers in turn offer it to all their peers, and so on. This offers fast propagation but can be wasteful on bandwidth when servers are offering articles to another server that already includes that article. The flood fill algorithm used today in Usenet means that a message can be posted and propagated within minutes.
  • Control messages Control messages are standard news messages with a special header. Control messages are sent to servers to create or delete newsgroups or to request that an article be cancelled (removed from a server's news base).

NNTP Operation

The basic operation of NNTP is similar to SMTP. Connections are made between a news client and server or between two servers. Once this connection is established, the client (or the initiating server) sends commands to the server, which might include data, such as a news message the client is posting to the server. The server attempts to perform the command and then sends back a response, which might include data, such as a news article that is retrieved and sent to the client.

NNTP Connections

As noted earlier, NNTP connections are initiated over TCP either by a news client (to post or retrieve news) or between two servers (to propagate articles and control messages). NNTP clients use an ephemeral TCP port, whereas the NNTP server port is TCP port 119. When a server contacts a peer, it uses a local ephemeral TCP port as well.

In Windows Server 2003, you can use the built-in program Outlook Express as a news client. Outlook Express is installed automatically, but before you can use it as an NNTP client, you need to configure it using the built-in configuration wizard. There are a large range of Windows-based news clients, including both free and commercial products.

After the client has created the TCP connection with the server, it can issue commands to the news server. Once the client has completed sending commands and receiving responses, it can issue a final command to the server to terminate the news session.

The following trace shows a simple NNTP session between a client and a news server:

Collecting Usenet News from news2.kapoho.net

<- 200 NNTP Service 6.0.3621.0 Version: 6.0.3621.0 Posting Allowed

-> MODE READER

<- 200 NNTP Service 6.0.3621.0 Version: 6.0.3621.0 Posting Allowed

-> XHDR Message-ID

-> XOVER

-> GROUP mct.mentor.announce

-> GROUP mct.mentor.discussion

-> STAT 80

<- 211 0 5 4 mct.mentor.announce

<- 211 38 44 81 mct.mentor.discussion

<- 223 80 USTw+JYDu7b9EAXe@mail.psp.co.uks

-> GROUP mct.mentor.discussion

-> XHDR Message-ID 81

-> NEWGROUPS 020911 230405 GMT

<- 211 38 44 81 mct.mentor.discussion

<- 221 Xhdr information follows

<- 81 <q31vXMSJx8f9EAji@mail.psp.co.uk>

<- .

-> ARTICLE <q31vXMSJx8f9EAji@mail.psp.co.uk>

<- 231 New newsgroups follow.

<- .

-> QUIT

<- 220 0 article <q31vXMSJx8f9EAji@mail.psp.co.uk>

<- 205 closing connection - goodbye!

News connection to news2.kapoho.net closed - filing continues

News from news2.kapoho.net completed, 1 articles fetched, 0 posted

This session is from the log of a news client. The corresponding NNTP traffic can be seen in Capture 21-03 on the companion CD-ROM.

NNTP Commands and Responses

NNTP communication occurs between a news client or news server and another news server. The communication comprises one or more commands sent from the initiating system to the news server plus responses received back from the server. The communication can also include news articles being sent from client to server, from server to client, and from server to server.

NNTP Commands

The NNTP client issues commands to the server across the active connection. NNTP commands are a single word followed by, in some cases, a parameter. In command lines that have parameters, the command is separated from the parameter by one or more space or tab characters. The command line must be complete with all parameters and must not contain more than one command. Each command line is terminated by a CRLF pair. A command line can be, at most, 512 characters long (510 characters plus the CRLF pair), and there is no provision for the continuation of command lines.

Table 21-10 sets out the NNTP commands defined in RFC 850, RFC 977, and RFC 2980 and describes their functions.

Table 21-10. NNTP Commands
Command and RFC Where Defined Purpose/Function

ARTICLE (RFC 977)

Sent by the news client to the server to retrieve an article. If the message exists, the server responds with the article's header, a blank line, and then the body of the article.

There are two forms of this command:

ARTICLE [nnn]

This form requests the server to request a specific article based on the internal article number. For example:

ARTICLE 23

This form of the command sets the internal current article pointer to the article if it exists.

ARTICLE [message-id]

This form of the command requests the message with the specified message ID. For example:

ARTICLE q31vXMSJx8f9EAji@mail.psp.co.uk

This form of the command does not change the internal current article pointer.

AUTHINFO (RFC 2980)

This command informs a news server of the identity of a user of the server. News clients are required to provide this information when requested by the server and servers are not required to accept authentication information that is volunteered by the client. News clients must be able to accommodate servers that reject any authentication information volunteered by the client.

There are several forms of this command as listed next.

AUTHINFO USER (RFC 2980)

This command is used by a news client to provide the user name; for example:

AUTHINFO USER thomaslee

AUTHINFO PASS (RFC 2980)

This command is used to transmit a user's password to the news server. This password is transmitted in clear text; for example:

AUTHINFO PASS !sugarmagnolia

AUTHINFO SIMPLE (RFC 2980)

This version of AUTHINFO was a refinement of the original AUTHINFO command and was part of a proposed NNTP version 2 specification. This specification, which was started in 1991, was never completed. This command is implemented in some servers and clients, but it is not supported by IIS 6 or used by Outlook Express.

BODY (RFC 850)

The BODY command is identical to the ARTICLE command except that it returns only the body of the news article.

GROUP (RFC 850)

This command is sent by the client to the news server to inform the server to which specific news-groups any future commands relate. The server responds with the article numbers of the first and last articles in the group and an estimate of the total number of messages that are held by the server for that group. This command also sets the internal current article pointer to point to the first article in the group.

For example:

group mct.mentor.discussion

211 42 44 85 mct.mentor.discussion

CHECK (RFC 2980)

The CHECK command is used by a news peer to discover if an article with a specified message ID should be sent to the server using the TAKETHIS command. For example:

CHECK <q31vXMSJx8f9EAji@mail.psp.co.uk>

HEAD (RFC 850)

The HEAD command is identical to the ARTICLE command except that it returns only the article's header.

IHAVE (RFC 850)

The IHAVE command is sent by the client to the server to inform the server that the client has an article that it can offer to the server. If the news server does not have the article (and is configured to request it), the server returns a response requesting the entire article (header and body). If the server does not want the article (for example, if that article is already held by the news server), a suitable response is sent.

This command is similar to POST, but differs in that it is intended to be used between servers for propagation. Outlook Express, for example, does not use this command. When this command is used to transfer news articles, changes are made in the PATH: header to ensure that the path the article travels is recorded.

LAST (RFC 850)

This command moves the current article pointer to the previous article in the current group. If the pointer is already at the start of the group, an error is returned.

LIST (RFC 850)

This command is sent to the news server to retrieve a list of all newsgroups held by the server as well as information about the messages held for each group.

The server returns the information as a series of single lines of information per newsgroup held. The format of this information is:

group-name last  first  p

where group is the full name of the newsgroup, last is the article number of the last article held in that group, first is the article number of the first article held in that group, and p is set to either Y or N depending on whether the server will allow posting to the group (Y) or not (N).

LIST ACTIVE (RFC 2980)

This command is the same as the LIST command except with an additional parameter. If the optional matching parameter is specified, the list is limited to only the groups that match the pattern. When the display is completed, the server sends a period on a line by itself. If no groups match the pattern, an empty list is returned. For example:

200 NNTP Service 6.0.3621.0 Version: 6.0.3621.0 Posting Allowed

list active

215 list of newsgroups follow

control.cancel 0 1 y

control.newgroup 0 1 y

control.rmgroup 0 1 y

mct.mentor.announce 4 5 y

mct.mentor.discussion 85 44 y

.

LIST ACTIVE.TIMES (RFC 2980)

The active.times file is used by some news servers to contain information about who created a particular news-group and when.

IIS 6 does not support this command.

LIST DISTRIBUTIONS (RFC 2980)

Some news servers maintain a distributions file that contains information about valid values for the Distribution: line in a news article header and what the values mean. Each line contains two fields, the value and a short explanation of the meaning of the value. When the display is completed, the server sends a period on a line by itself. If the information is not available, the server returns the 503 error response.

IIS 6 does not keep this information, and it returns a 503 message when the command is sent.

LIST DISTRIB.PATS (RFC 2980)

The distrib.pats file is maintained by some news transport systems to contain default values for the Distribution: line in a news article header when posting to particular newsgroups.

IIS 6 does not keep this information.

LIST NEWSGROUPS (RFC 2980)

Most news servers maintain a newsgroups file that contains the name and description of each newsgroup active on the news server. Each line in the file contains two fields, the newsgroup name and a short explanation of the purpose of that newsgroup. When the display is completed, the server sends a period on a line by itself.

For example:

list newsgroups mct*

215 descriptions follow

mct.mentor.announce MCT Mentoring Announcements

mct.mentor.discussion MCT Mentoring general discussion group

.

LIST OVERVIEW.FMT (RFC 2980)

The overview.fmt file is maintained by some news transport systems to contain the order in which header information is stored in the overview databases for each newsgroup. When the display is completed, the server sends a period on a line by itself.

For example:

list overview.fmt

215 Order of fields in overview database.

Subject:

From:

Date:

Message-ID:

References:

Bytes:

Lines:

Xref:full

.

LIST SUBSCRIPTIONS (RFC 2980)

This command is used to get a default subscription list for new users of this server.

This command is not supported by IIS 6.

LISTGROUP (RFC 2980)

This command is used to get a listing of all the article numbers in a particular newsgroup. When a valid group is selected by means of this command, the internal current article pointer is set to the first article in the group. The successful selection response is a list of the article numbers in the group followed by a period on a line by itself.

For example:

listgroup mct.mentor.discussion

211

84

85

.

MODE READER (RFC 2980)

This command is used by a news client to indicate to the server that it is a newsreading client. Some news servers can make use of this information to reconfigure themselves for better performance in responding to newsreader commands. This command is similar to the SLAVE command described in RFC 977, which was not widely implemented.

MODE STREAM (RFC 2980)

MODE STREAM is used by a news peer to indicate to the server that it would like to suspend the lock-step conversational nature of NNTP and send commands in streams.

IIS 6 does not support this command.

NEWGROUPS (RFC 977)

This command returns a list of newsgroups created since a specified date and time. The server lists this information in the same format as the LIST command.

For example:

NEWGROUPS 020911 230405 GMT

231 New newsgroups follow.

tcpip.news 0 1 y

.

NEWNEWS (RFC 977)

This command returns a list of message IDs of the articles posted or received to the specified newsgroup since a specific date. The format of the listing is one message ID per line with a single line consisting solely of one period followed by CRLF at the end of the list.

For example:

NEWNEWS * 020911 000000 GMT

230 list of new articles by message-id follows.

<3BqIqTeIrZg9EAL8@mail.kapoho.com>

<fIw5oUsWCHA.1836@kona2.kapoho.com>

<MPG.17ea850c60310b77989681@news.kapoho.com>

<dVpIArmWCHA.1836@kona2.kapoho.com>

<q31vXMSJx8f9EAji@mail.kapoho.com>

.

POST (RFC 977)

The POST command is used to post a news article to a news server.

QUIT (RFC 977)

This command is sent by the client to the news server to complete the news session and to tear down the TCP connection between server and client. No further commands are accepted after the server receives this command.

SLAVE (RFC 977)

Indicates to the server that this client connection is to a slave server, rather than a user. This command was meant to help a server separate end user connections from peer server connections.

IIS 6 does not support this command.

STAT (RFC 977)

The STAT command is similar to the ARTICLE command except that no text is returned. When selecting by message number within a group, the STAT command sets the current article pointer without sending text. The returned acknowledgment response contains a message ID, which might be of some value to the news client. Most news clients do not use this command.

TAKETHIS (RFC 2980)

News servers use this command to send articles to a peer server when in streaming mode. The header and body are sent immediately after the peer sends the TAKETHIS command. The sender of the TAKETHIS command peer does not have to wait for a response from the peer server before sending the next command and the associated article. During transmission of the article, the peer sends the entire article, including header and body, in the manner specified for text transmission from the server.

XGTITLE (RFC 2980)

The XGTITLE command is used to retrieve newsgroup descriptions for specific newsgroups.

This command is not recognized by IIS 6.

XHDR (RFC 2980)

The XHDR command is used to retrieve specific headers from specific articles. This command takes two parameters. The first is a name of a header line in a news article. The second parameter, which is optional, is either the message ID of a specific message or a range of articles, expressed as an article number, followed by a dash (to indicate all following articles) or an article number followed by a dash followed by another article number.

Each line returned contains an article number (or message ID, if a message ID was specified in the command), one or more spaces, and then the value of the requested header in that article. Once the output is complete, a period is sent on a line by itself.

XINDEX (RFC 2980)

The XINDEX command is used to retrieve an index file in the format originally created for use by the TIN newsreader.

This command is not supported by IIS 6.

XOVER (RFC 2980)

The XOVER command returns information from the overview database for the articles specified. Each line of output is formatted with the article number, followed by each of the headers in the overview database or the article

itself (when the data is not available in the overview database) for that article separated by a tab character. The sequence of fields must be in this order: subject, author, date, message ID, references, byte count, and line count.

For example:

group tcpip.news

211 3 1 3 tcpip.news

xover

224 Overview information follows

1       test    Thomas Lee <tfl@kapoho.com>
Fri, 13 Sep 2002 12:22:50 +0100
<7vqrhnyKqcg9EA4f@mail.kapoho.com>

.

XPAT (RFC 2980)

The XPAT command is used to retrieve specific headers from specific articles, based on pattern matching on the contents of the header.

XPATH (RFC 2980)

The XPATH command is used to determine the file names in which an article is filed.

This command is not supported by IIS 6.

XREPLIC (RFC 2980)

The XREPLIC command makes it possible to exactly duplicate the news spool structure of one server in another server. This command works similarly to the IHAVE command specified in RFC 977 and uses the same response codes. The command-line arguments consist of entries separated by a single comma. Each entry consists of a newsgroup name, a colon, and an article number.

This command is generally only used in servers when a receiving server is being fed by only one other server.

XROVER (RFC 2980)

The XROVER command returns reference information from the overview database for the articles specified.

This command is not supported by IIS 6.

XTHREAD (RFC 2980)

The XTHREAD command is used to retrieve threading information in a format originally created for use by the TRN newsreader.

This command is not supported by IIS 6.

NNTP Responses

A news server issues two types of responses to client commands: textual messages and numeric status codes. The intention of command/status responses was that the news client program would interpret them before any possible display is done. The text messages, on the other hand, are meant to be displayed by the news client at the user's computer.

The textual responses are sent only after a numeric status response line has been sent to the client to indicate that text will follow. Text is sent as a series of successive lines of textual matter, each terminated with a CRLF pair. Usually just one line is sent, but RFC 977 allows for longer textual responses. A single line containing only a period (.) is sent to indicate the end of the text (that is, the server sends a CRLF pair at the end of the last line of text, a period, and another CRLF pair). You can see the text messages in the command examples previously shown in Table 21-10.

Like other Internet-type services, NNTP servers issue numeric codes in response to client commands. These extensible reply codes are sent in the form of a three-digit number, with the value of the first and second digits indicating the type of response.

  • The first digit in an NNTP response code indicates the general type of response the server wants to pass to the client. See Table 21-11 for more details on the meaning of the first digit.
  • The second digit is used to provide a more specific indication of the meaning of the response. See Table 21-12 for more details on the meaning of the second digit.
  • Values for the third digit in a response code are extensible and can be customized for specific implementations.

Tables 21-11 and 21-12 list and describe the first- and second-digit values.

Table 21-11. NNTP Response Codes—First-Digit Values
First-Digit Value Indicator Description

1yz

Informative message.

These are general information messages.

2yz

Command OK.

The command was accepted and has been acted on. A 2yz command might be followed by output.

3yz

The server indicates that the command is OK so far and that the remainder can be sent.

The command was accepted but the server is expecting more, which can now be sent. For example, after a POST command is sent by a client, the server is waiting for the rest of the news article. For example:

POST

340 Continue posting - terminate with period

4yz

Command was correct, but could not be performed for some reason.

These are usually transient errors.

5yz

Command unimplemented, incorrect, or a serious program error occurred.

These are either transient server errors (for example, no more news can be posted because the server is temporarily out of disk space) or more serious (for example, if a client sends a server a command that is not implemented to which IIS 6 responds with a 500 Command Not Recognized response).

Table 21-12. NNTP Response Codes—Second-Digit Values
Second-Digit Value Indicator Description

x0z

Connection, setup, and miscellaneous messages

Typically issued when a news client connects to a news server, for example at initial connection or after a mode reader command is sent.

For example:

mode reader

200 NNTP Service 6.0.3621.0

Version: 6.0.3621.0 Posting Allowed

x1z

Newsgroup selection

Relates to an article and is seen, for example, when sending the GROUP command or LIST command.

For example:

group tcpip.news

211 3 1 3 tcpip.news

x2z

Article selection

Relates to commands that select a particular article, such as the STAT command.

For example:

stat

223 1 <7vqrhnyKqcg9EA4f@mail.psp.co.uk>

x3z

Distribution functions

These are typically seen relating to distribution type commands.

For example:

NEWGROUPS 020911 230405 GMT

231 New newsgroups follow.

tcpip.news 3 1 y

.

x4z

Posting

These reply codes relate to the process of posting a news message, such as with the POST command.

For example:

POST

340 Continue posting - terminate with

period

<message header,followed by message body>

.

240 Article Posted OK

x8z

Private vendor extensions

These replies allow vendors to create additional commands.

x9z

Debugging output

These replies are for debugging purposes, typically for debugging news server programs.


SMTP

For many users, e-mail has replaced traditional mail as a form of communication. The contents of this book were sent among the authors, editors, and publisher using e-mail. E-mail is seen by some to be the killer application for the Internet. SMTP is used to transmit mail between mail servers and from mail clients to mail servers. Most mail clients use a different protocol, either Post Office Protocol 3 (POP3) or Internet Message Access Protocol (IMAP), to retrieve mail.

SMTP is designed to do exactly what its name implies—provide reliable, efficient mechanisms for the transfer of electronic mail. SMTP transfers messages from a mail client to a mail server and between mail servers. SMTP is not, however, responsible for managing mailboxes or for allowing a client to download incoming mail. RFC 821 defines SMTP, although features and refinements have been added in numerous subsequent RFCs. Although SMTP uses familiar terminology, a few terms might be unknown and are defined here:

  • SMTP client The program that initiates an SMTP connection to a receiver SMTP process to send mail. The SMTP client process controls the transfer of mail between itself and the SMTP server, issues commands, and receives replies from the SMTP server.
  • SMTP server process The process that waits for an SMTP client process to establish a connection, then receives commands from the client and carries out the operations specified in those commands.
  • Transmission channel The full-duplex channel opened between SMTP client and server processes for the purposes of command/reply sequences and mail transfer.
  • Reverse-path Specifies the mail's sender. The reverse-path can be simply the name of the user who is sending the mail, or it can include a list of hosts that relayed this mail from its original sender. The first host listed is the most recent relay, and the last host listed is the first relay.
  • Forward-path Specifies the mail's recipients. Optionally, the forward-path can specify a list of relays to be used to route the mail to its intended recipients, with the current SMTP server being the first relay in the list and the final destination being the last.
  • Reverse-path buffer Used to hold the list of reverse-path parameters for a transaction, possibly including a list of hosts who relayed the mail. This can be cleared as a result of various commands being issued.
  • Forward-path buffer Used to hold the list of forward-path parameters for a transaction, possibly including a list of relay hosts to whom the mail is to be routed. This can also be cleared as a result of various commands.
SMTP is defined in RFC 821, which can be found in the \Rfc folder on the companion CD-ROM.

SMTP Operation

Although numerous enhancements have been added to SMTP since RFC 821, it remains a fairly simple client/server protocol. SMTP, like HTTP and FTP, is an Application Layer protocol that relies on underlying protocols to ensure data delivery. Although SMTP can in theory utilize other protocols, TCP is the most common and can be assumed to be the underlying protocol throughout this section.

SMTP communication is initiated by a user's mail system, the SMTP client. The SMTP client establishes a mail session with an SMTP server by opening a TCP connection to the server, then issuing either a HELO or EHLO SMTP command to begin a session. Extended implementations of SMTP, such as that included with IIS 6, can be configured to require the client to provide authentication credentials that verify the client is permitted to use the SMTP server. Most often, these are simply a user name and password that are recognized by the receiving system.

After the transmission channel has been established, the SMTP client issues a MAIL command that informs the SMTP server that it wants to send mail. If the server is capable of receiving mail at that time, it responds with an OK reply. The SMTP client then issues one or more RCPT commands that identify the recipients of the messages it wants to send; each RCPT command represents a single mail recipient. The recipients can be other users in the same mail system or users in external domains.

If the SMTP server is capable of receiving mail addressed to the recipient named in the RCPT command, it issues an OK reply to the client and the client is free to issue another RCPT command. If the SMTP server is not capable of delivering mail to the designated recipient, it returns an error reply to the client and the client can then move on to the next command. The command/reply sequence is strictly ordered; the client must receive a single reply before the server can issue another command, and a server is not permitted to issue more than one reply to any command.

Because not all recipients can be using the same SMTP system, the client must provide the name of the ultimate destination host as well as the mailbox name in that mail system. The syntax of SMTP mail addresses is the familiar username@domain format, where information to the right of the "@" symbol identifies the destination host, and the user name identifies the name of the mailbox to which the mail should be delivered. SMTP differentiates between sending and mailing: if mail is sent, the client is designating that the mail should be delivered immediately to the recipient's mail interface, provided the recipient is online and using a mail system that uses this functionality. More often, however, mail is mailed, which designates that it should be delivered to the recipient's mailbox on a receiving server. In addition, the send functionality is not a required SMTP implementation, and it can be assumed that this chapter refers to the mail functionality unless specified otherwise.

SMTP mail has both a forward-path and a reverse-path. The forward-path is the path that the mail must take to reach its final destination, whether it uses a direct path or a series of relays. It is important not to confuse SMTP relays with routers; SMTP relays are SMTP servers that can receive mail from one SMTP host and forward that mail to another SMTP host, independent of underlying routing mechanisms. The reverse-path in an SMTP mail message is the name of the sender, which can be as simple as username@domain.

It could otherwise consist of a list of relay hosts between the original sender and the current receiver SMTP. The MAIL command uses the reverse-path as its argument, and the RCPT command uses the forward-path. If multiple recipients' mailboxes reside on the same SMTP host, SMTP encourages the sending of a single copy of the mail to the destination SMTP host.

Once the receiver SMTP has accepted the recipient addresses and provided the appropriate reply, the client is free to begin issuing the DATA command, which informs the server of its intent to begin transferring the mail message. The server replies with a code accepting the sender's intent, and the client then issues the data. The mail data includes not only the body of the mail, but also the memo header information, such as the To:, cc:, bcc:, and Subject lines. If the transfer of the mail data is successful, the server replies with a message indicating receipt and processing, and the client can then issue commands to terminate the transmission connection.

If the sender specifies invalid destination information in the forward-path of the mail, but the server knows the correct destination, the server can reply to the sender with a message allowing the client to correct the error. When the client wishes to terminate the SMTP session, it indicates this by issuing the QUIT command, and the server then closes the transmission connection.

A typical SMTP session might look similar to this:

220-mail.kapoho.com; Sun, 2115 Sep 2001 15:36:29 -0100 (BST)

HELO kapoho10.kapoho.com

250 Pleased to meet you

MAIL FROM: <tfl@kapoho.com>

250 <tfl@kapoho>... Sender ok

RCPT TO: <tfl@kapoho.com>

250 <tfl@kapoho.com>... Recipient ok

RCPT TO: <rebecca@kapoho.com>

250 <rebecca@kapoho.com>... Recipient ok

DATA

354 Enter mail, end with "." on a line by itself

 This is a test post.

.

Message accepted for delivery

QUIT

221 mail.kapoho.com closing connection

SMTP Commands

The SMTP client issues the SMTP commands to the SMTP server. The SMTP command follows a straightforward syntax, as shown here (brackets indicate optional command parameters):

<SMTP-COMMAND> [<space> <COMMAND-ARGUMENTS>] <crlf>

The SMTP client process issues commands to perform functions, such as opening a transmission channel or initiating a mail transfer. In turn, the SMTP server process attempts to execute the command and then returns the responses. Commands can be issued individually or as part of a series of commands, but each command must be followed by a reply from the SMTP server. Table 21-13 lists common SMTP commands, their descriptions, and their syntax.

Table 21-13. Common SMTP Commands, Descriptions, and Syntax
Command | Description | Syntax
ATRN | AUTHENTICATED TURN. If the session between an SMTP client and SMTP server has been authenticated (the user has provided valid identification credentials), this specifies that the SMTP client must either return an OK reply and assume the role of sender for the mail, or return a refusal (Bad Gateway, 502) and retain the role of SMTP client. | ATRN [<SP> domain name [","domain name]] <CRLF>
AUTH | AUTHENTICATE. Used to begin an authenticated mail transfer session (where a user can provide a user name and password to the SMTP server to continue the session). | AUTH LOGIN <CRLF>
DATA | DATA. The lines following this command are specified as mail data from the SMTP client to server. | DATA <CRLF>
EHLO | EXTENDED HELLO. A client that supports SMTP extensions issues this command rather than the HELO command when initiating a session. If the SMTP server receiving this command supports SMTP extensions, it returns a 250 (Requested Mail Action Okay, Completed) response. If the SMTP server receiving the message does not support SMTP extensions, it returns a 500 (Syntax Error, Command Unrecognized) message, which indicates to the sender that it cannot use extended SMTP commands. | EHLO <SP> <domain> <CRLF>
ETRN | EXTENDED TURN. An extended SMTP command that requests the server to begin processing its mail queues for messages waiting at the server to be delivered to the client. | ETRN <SP> [<option character>] <node-name> <CRLF>
EXPN | EXPAND. Asks the SMTP server to verify that the argument passed is a mailing list. If the argument does represent a mailing list, the membership of the list is returned to the SMTP client, in the form of users' full names and mailboxes. This can represent a security risk and many SMTP servers allow the administrator to disable this command. | EXPN <SP> <mailing list name> <CRLF>
HELO | HELLO. Used to identify the SMTP client to the SMTP server and begin a new session. | HELO <SP> <host name of SMTP client> <CRLF>
HELP | HELP. Causes the SMTP server to return help information to the sender; this command might or might not contain arguments. | HELP [<SP> <arguments>] <CRLF>
MAIL | MAIL. Used to initiate a mail transaction between SMTP client and server. It clears the reverse-path buffer, forward-path buffer, and mail buffer, and inserts the reverse-path argument from this command into the reverse-path buffer. | MAIL <SP> <reverse-path> <CRLF>
NOOP | NO OP. Has no effect on any buffers and specifies no action other than that the SMTP client return an OK reply. | NOOP <CRLF>
QUIT | QUIT. Specifies that the receiver return an OK reply and close the transmission channel. | QUIT <CRLF>
RCPT | RECIPIENT. Identifies the recipient of the mail being sent; multiple recipients are specified by repeated issuing of the command. | RCPT <SP> TO: <reverse-path> <CRLF>
RSET | RESET. Specifies that the current mail transaction be aborted and all buffers be cleared. The SMTP server responds with an OK message. | RSET <CRLF>
SAML | SEND AND MAIL. Initiates a transaction specifying mail data be delivered to any recipient named who is actively connected and capable of receiving mail, as well as delivering to the mailboxes of the specified recipients. Clears the reverse-path buffer, the forward-path buffer, and the mail buffer, and inserts the reverse-path information provided with the command into the reverse-path buffer. | SAML <SP> FROM:<reverse-path> <CRLF>
SEND | SEND. Initiates a transaction specifying that mail data be immediately delivered to any recipient named who is actively connected and capable of receiving mail. If a recipient is not connected or capable of receiving mail, a 450 (Mailbox Unavailable) response is returned. This clears the reverse-path buffer, the forward- path buffer, and the mail buffer, and inserts the reverse-path information provided with the command into the reverse-path buffer. | SEND <SP> FROM:<reverse-path> <CRLF>
SIZE | SIZE. Allows the sender to specify the mail size that it wants to send, which the server can refuse if the size is too large. Only valid in SMTP implementations that support service extensions. | SIZE <SP> 1000000 <CRLF> or MAIL <SP> FROM: <reverse-path> <SP> SIZE = 100000 <CRLF>
SOML | SEND OR MAIL. Initiates a transaction specifying that mail data be immediately delivered to any recipient named who is actively connected and capable of receiving mail. If a recipient is not connected or capable of receiving mail, specifies delivery to the recipient's mailbox. Clears the reverse-path buffer, the forward-path buffer, and the mail buffer, and inserts the reverse-path information provided with the command into the reverse-path buffer. | SOML <SP> FROM:<reverse-path> <CRLF>
TURN | TURN. Specifies that the SMTP server must either return an OK reply and assume the role of sender (SMTP client) for the mail, or return a refusal (502) and retain the role of SMTP server. | TURN <CRLF>
VRFY | VERIFY. Requests that the receiver SMTP verify the user name specified in the argument. If the user name is valid, the full name and mailbox of the user are returned This has no effect on reverse-path buffer, forward-path buffer, or mail buffer. | VRFY <SP> <username> <CRLF>

SMTP Replies

SMTP replies are issued by the SMTP server in response to commands sent by the SMTP client. Every command must generate one and only one reply. Similar to the response codes issued by FTP servers, SMTP receivers issue a three-digit code number followed by descriptive text. As in FTP, the first digit of the response code indicates the general type of response, and the second digit provides additional information within that response category. Tables 21-14 and 21-15 list the values and meanings of both first- and second-digit values.

Table 21-14. SMTP Response Codes—First-Digit Values
First-Digit Value | Indicator | Description
1yz | Positive Preliminary Reply | The command has been accepted and is awaiting confirmation of this reply and further instruction as to whether the receiver SMTP should continue or abort processing. However, there are no SMTP commands that allow this type of reply, so there are no continue or abort commands.
2yz | Positive Completion Reply | The requested action has been completed and another command can now be issued.
3yz | Positive Intermediate Reply | The command has been accepted and is being held, pending receipt of further information from the SMTP client.
4yz | Transient Negative Completion Reply | A transient error has occurred that prevented processing of the command, and the SMTP client should reissue the command (or command sequence).
5yz | Permanent Negative Completion Reply | An error has occurred that prevented processing of the command; the command (or command sequence) should not be reissued without modification. This modification can be as simple as correcting a misspelling, or this error might indicate a nontransient server error.
Table 21-15. SMTP Response Codes—Second-Digit Values
Second-Digit Value | Indicator | Description
x0z | Syntax | There is a syntax error, the command issued is unimplemented by the server, or the server does not recognize the command category.
x1z | Information | Replies to information requests, such as "Help."
x2z | Connections | Replies, referring to the transmission channel.
x5z | Mail System | Mail system status as it relates to the requested transfer or command.

Since RFC 821 was published, extensions to the protocol have been introduced, including the following:

  • Authentication
  • Message size declaration, which allows a server to limit the size of mail that it will accept
  • Turning of the transmission connection, so that sender and receiver switch roles
  • Delivery status notifications
The RFCs that describe these features have been included in the \Rfc folder on the companion CD-ROM.


Summary

IIS 6 provides enhanced support for Web-based services through its implementations of the HTTP/1.1, NNTP, SMTP, and FTP protocols. HTTP/1.1 improves on earlier implementations of HTTP in its support for multiple requests over a single connection, header compression, authentication mechanisms, and enhanced caching and proxy definitions. NNTP allows the transmission, storage, and replication of news messages. SMTP allows an IIS server to send and receive electronic messages on behalf of the clients it serves, facilitating e-mail communication for companies that might not require a full-fledged messaging system.

In IIS 6, SMTP is implemented as a secure protocol, allowing for authentication and verification mechanisms. The implementation of FTP in IIS 6 has also been improved, providing FTP restart, which allows a lost download connection to be resumed at the point at which it left off. By complying with the most recent standards for each of these protocols, IIS 6 ensures that Web services can be provided in the most quick and efficient manner possible.


Internet Protocol Security (IPSec)

Chapter 22
Internet Protocol Security (IPSec)

In the increasingly hostile modern-day world of private and public networking, security and protection of data are fundamental requirements. To provide the best protection, you must deploy defense in depth: Many layers of security are needed to repel the types of attacks you might encounter on the Internet, and more likely, from within your own network. One of the ways to provide this defense, beyond the typical measures to secure the network perimeter and secure access to resources by instituting authentication and access control, is to secure the actual IP packets and their contents.

As described in previous chapters, IP, TCP, and User Datagram Protocol (UDP) headers contain a checksum, which is used to provide a bit-level integrity check for portions of the IP packet. However, the checksum is only detecting corrupted data. Because the checksum algorithm is well known, a malicious user can intercept an IP packet, view and modify its contents, recompute the checksums, and forward the packet to its destination. Due to the limited functionality of the checksum, the destination node is not aware and cannot detect that the packet was modified.

Historically, applications that required security provided it for themselves, leading to a variety of separate and incompatible security standards. IP Security (IPSec) is a suite of protocols and cryptographic algorithms that provide security at the Internet layer, regardless of the application sending or receiving data. With IPSec, a single security standard is used and applications do not need to be modified to use it.


IPSec Overview

IPSec is an architectural framework of Internet Engineering Task Force (IETF) standards that provides cryptographic security services for IP packets. IPSec is an end-to-end security technology: the only nodes aware of the presence of IPSec are the two IPSec peers that are communicating. Intermediate routers have no knowledge of the security relationship and forward the IP packets, as they would any other, between the communicating peers.

Properties of Secure Communications

IPSec provides the following properties for secure communications:

  • Peer authentication IPSec verifies the identity of the peer computer before any data is sent. IPSec peer authentication for the Microsoft Windows Server 2003 family can be based on preshared keys, public keys (such as X.509 certificates), or Kerberos and the Active Directory service.
  • Data origin authentication Each packet protected with IPSec contains a cryptographic checksum in the form of a keyed hash. The cryptographic checksum is also known as an Integrity Check Value (ICV) or hash-based message authentication code (HMAC). A hash is a one-way, mathematical summary of a block of data. A keyed hash includes the secret key in its calculation. The cryptographic checksum ensures that only a computer with knowledge of the shared secret key could have sent the packet. A malicious user masquerading as the sender cannot calculate a correct cryptographic checksum. If the cryptographic checksum fails, the receiving peer discards the packet.
  • Data integrity By including the cryptographic checksum, IPSec protects the data in an IP datagram from unauthorized modification during transit, ensuring that the information that is received is the same as the information that was sent. A malicious user who modifies the packet contents must also properly update the cryptographic checksum, which is virtually impossible without knowledge of the shared key.
  • Data confidentiality By using conventional secret key encryption techniques, the sent data can be encrypted, providing data confidentiality. Even if the packet is intercepted and viewed, the interceptor can view only the encrypted data. Without knowledge of the secret key used to encrypt the data, the original data remains hidden. Because the secret key is shared between the sender and receiver, data confidentiality ensures that the data can be decrypted and disclosed only by the intended receiver.
  • Antireplay By using a sequence number on each protected packet sent between IPSec peers, a data exchange between IPSec peers cannot be captured and then portions replayed to establish a security relationship or gain unauthorized access to information or resources.
  • Key management Data origin authentication, data integrity, and data confidentiality depend on the shared knowledge of a secret key. If the key is compromised, the communication is no longer secure. To keep malicious users from determining the key through any method except brute force determination (trying all possible key combinations until the key is discovered), IPSec provides a secure way to derive initial keying material and to periodically change the keys used for secure communications.
IPSec does not provide the nonrepudiation security service for data. Nonrepudiation is the property of a data transmission such that the sender cannot later deny having sent it. Because IPSec uses a shared secret key, also known as a symmetric key, for its cryptographic functions, nonrepudiation cannot be done because there are two peers with knowledge of the secret key. An example of nonrepudiation is the use of public key cryptography and a private key to encrypt a hash of the data, creating a digital signature. Because only the sender has knowledge of the private key, only the sender could have created the digital signature. The sender cannot deny having sent a message with a correct digital signature.

Hashing and Encryption Algorithms

IPSec in the Windows Server 2003 family uses the following hash algorithms:

  • HMAC MD5 The Message Digest 5 (MD5) hash was developed by Ron Rivest. MD5 produces a 128-bit hash value and is described in RFC 1321. HMAC MD5 produces a 96-bit keyed hash value and is described in RFC 2403.
  • HMAC SHA1 Secure Hash Algorithm 1 (SHA1) was developed by the National Institute of Standards and Technology (NIST) and is described in Federal Information Processing Standard (FIPS) Publication 180-1. SHA1 produces a 160-bit hash value. SHA1 is stronger than MD5 because of the greater length of its hash value. HMAC SHA1 produces a 96-bit keyed hash value and is described in RFC 2404.

Both hash algorithms are well known and it would be a trivial task for a malicious user to create an MD5 or SHA1 implementation. Although they can calculate MD5 or SHA1 hashes of IP datagrams, because they do not have knowledge of the secret key, these malicious users cannot easily calculate the HMAC MD5 or HMAC SHA1 keyed hash value.

IPSec in the Windows Server 2003 family uses the following encryption algorithms:

  • DES The Data Encryption Standard (DES) algorithm is a symmetric key block cipher published in 1977 by the U.S. National Bureau of Standards. DES uses a 56-bit key and an initialization vector (IV) to encrypt data in 64-bit blocks. The IV is used to ensure that the same blocks of original plaintext, when encrypted, result in different blocks of ciphertext. This is a block encryption technique known as cipher block chaining (CBC).
  • 3DES Triple DES (3DES) is the DES encryption algorithm applied three times, with three different 56-bit keys in the following manner: encryption with key 1, decryption with key 2, encryption with key 3. The receiver uses the following process for decryption: decryption with key 3, encryption with key 2, decryption with key 1.

3DES is stronger than DES, but also requires much more processing time for encryption and decryption.

Key Management

To provide a secure method to determine the initial keying material from which the secret key for secured communications is derived, IPSec uses the Diffie-Hellman key exchange process. This technique derives a secret key known only to the two peers by exchanging two numbers over a public network. A malicious user who intercepts the key exchange packets can view the numbers, but cannot perform the same calculation as the negotiating peers to derive the shared secret key.

The Diffie-Hellman key exchange process does not prevent a man-in-the-middle attack, in which a malicious user between the negotiating peers performs two Diffie-Hellman exchanges, one with each peer. When both exchanges are complete, the malicious user has the secret keys to communicate with both peers. To prevent such an attack, IPSec for the Windows Server 2003 family performs an immediate authentication after the Diffie-Hellman key exchange is complete. If the IPSec peer cannot perform a valid authentication, the security negotiation is abandoned before any data is sent.

The Diffie-Hellman secret key is the keying material from which the secret keys for secure communications are derived. IPSec for the Windows Server 2003 family also supports dynamic rekeying, the determination of new keying material through a new Diffie-Hellman exchange. Dynamic rekeying is based on an elapsed time (by default, 480 minutes [8 hours]) or the number of data sessions created with the same set of keying material (by default, this number is unlimited).

Security Associations

A security association (SA) is the combination of security services, protection mechanisms, and cryptographic keys mutually agreed to by communicating peers. The SA, also known as the mode SA, contains the information needed to determine how the traffic is to be secured (the security services and protection mechanisms) and with what secret keys (cryptographic keys). There are two types of SAs that are created when IPSec peers communicate securely: the ISAKMP SA and the IPSec SA.

ISAKMP SA

The Internet Security Association and Key Management Protocol (ISAKMP) SA, also known as the main mode SA, is used to protect IPSec security negotiations. The ISAKMP SA is created by negotiating the ciphersuite used for protecting future ISAKMP traffic, exchanging key generation material, and then identifying and authenticating each IPSec peer. When the ISAKMP SA is complete, all future SA negotiations for both types of SAs are protected. This is an aspect of secure communications known as protected ciphersuite negotiation. Not only is the data protected, but the determination of the protection algorithms negotiated by the IPSec peers is also protected. To break IPSec protection, a malicious user must first determine the ciphersuite protecting the data, which represents another barrier. For IPSec, the only exception to complete protected ciphersuite negotiation is the negotiation of the ciphersuite of the initial ISAKMP SA, which is sent as plaintext.

IPSec SA

The IPSec SA, also known as the quick mode SA, is used to protect data sent between the IPSec peers. The IPSec SA ciphersuite negotiation is protected by the ISAKMP SA. No information about the type of traffic or the protection mechanisms is sent as plaintext. For a pair of IPSec peers, there are always two IPSec SAs: one is negotiated for inbound traffic and one is for outbound traffic. The inbound SA for one IPSec peer is the outbound SA for the other.

Security Parameters Index

For each IPSec session, IPSec peers must track the usage of three different SAs: the ISAKMP SA, the inbound IPSec SA, and the outbound IPSec SA. To identify a specific SA, a 32-bit pseudorandom number known as the Security Parameters Index (SPI) is used. The SPI is used for SA management at each IPSec peer and is a field in the IPSec headers protecting IPSec traffic and in the messages negotiating or managing SAs.

The node that initiates an IPSec session is known as the initiator. The node that responds to a request to perform IPSec protection is known as the responder. The initiator chooses the ISAKMP SA SPI and each IPSec peer chooses the IPSec SA SPIs for its outbound traffic.

Creating SAs

An IPSec session negotiation and determination of both ISAKMP and IPSec SAs occurs in two phases: the main mode phase (also known as Phase I) and the quick mode phase (also known as Phase II).

Main Mode

Main mode negotiation creates the ISAKMP SA. The initiator and responder exchange a series of ISAKMP messages to negotiate the ciphersuite for the ISAKMP SA (in plaintext), exchange key determination material (in plaintext), and identify and authenticate each other (in encrypted text). For more information about the details of main mode negotiation, see the section entitled "Main Mode Negotiation," later in this chapter.

Quick Mode

Quick mode negotiation creates the two IPSec SAs. The initiator and responder exchange a series of ISAKMP messages to negotiate the ciphersuite for both the inbound and outbound IPSec SAs. During quick mode negotiation, keying material is refreshed or, if necessary, new keys are generated. For more information about the details of quick mode negotiation, see the section entitled "Quick Mode Negotiation," later in this chapter.

For IPSec for the Windows Server 2003 family, a complete IPSec session negotiation including both main mode and quick mode requires 10 ISAKMP messages exchanged between IPSec peers.


IPSec Headers

IPSec provides its security services by wrapping the IP payload with an additional header or trailer containing the additional information to provide data origin authentication, data integrity, data confidentiality, and replay protection. IPSec headers consist of the following:

  • Authentication header (AH)
  • Encapsulating Security Payload (ESP) header and trailer

The result of applying the AH or ESP to an IP datagram transforms it to a secure datagram. Consequently, AH and ESP are sometimes referred to as transforms.

Authentication Header

The AH is a header that provides data origin authentication, data integrity, and replay protection for the entire IP datagram. Figure 22-1 shows the structure of the AH.

Figure 22-1. The IPSec Authentication header.

The AH consists of the following fields:

  • Next Header A 1-byte field that is used to identify the next header in the payload. This field uses the same values as the Protocol field in the IP header.
  • Payload Length A 1-byte field that specifies the number of bytes in the AH past the Payload Length field in 32-bit (4-byte) blocks, not counting the first 2 blocks.
  • Reserved A 2-byte field that is reserved and must be set to 0. The Reserved field is included in the Authentication Data field calculation, but otherwise ignored.
  • Security Parameters Index A 4-byte field that identifies, when used in combination with the Destination IP Address field and transform (AH), the specific SA for this datagram.
  • Sequence Number A 4-byte field that contains an incrementing counter value that starts at 0 when the SA is established. The first packet for the SA has a sequence number of 1. The Sequence Number field provides antireplay protection because its value is protected by the ICV calculation. When the Sequence Number counts up to its maximum value (4,294,967,295 or 232 - 1), a new IPSec SA is established to keep the Sequence Number from repeating for an SA. When the new IPSec SA is established, the Sequence Number for the new SA starts at 0. If the Sequence Number for an incoming packet is too far out of sequence or if it matches a recently received sequence number, the packet is discarded.
  • Authentication Data A variable-length field that contains the ICV calculation of the sender (the HMAC MD5 or HMAC SHA1 keyed hash value). The Authentication Data field provides data origin authentication and data integrity security services. The size of the Authentication Data field for both the HMAC MD5 and HMAC SHA1 is 12 bytes (96 bits) long. For an arbitrary ICV algorithm, the Authentication Data field size must be an integral number of 32-bit (4-byte) blocks. Padding is used if needed.
AH is defined in RFC 2402, which can be found in the \Rfc folder on the companion CD-ROM.

AH Transport Mode

IPSec has two main modes of operation: transport mode and tunnel mode.

  • Transport mode is typically used for IPSec peers doing end-to-end security. Transport mode provides protection for upper-layer protocol data units (PDUs) by adding an extra header or trailer between the original IP datagram and its payload. Transport mode is typically used within an organization.
  • Tunnel mode is typically used by network routers to protect IP datagrams when forwarding traffic over an insecure transit network. Tunnel mode provides protection for entire IP datagrams by encapsulating the IP datagram with an IPSec header/trailer and an additional IP header. Tunnel mode is typically used outside an organization when connecting sites across a public network such as the Internet.

Figure 22-2 shows AH transport mode for an IP datagram.

Figure 22-2. AH transport mode.

The AH header is added to the IP datagram just after the IP header. In the IP header, the Protocol field is set to 51 (0x33) to indicate that an AH is present. Other than changing the Protocol field, the original IP header is unmodified. Normal routers forward this traffic as any other IP packet. Firewalls, on the other hand, might need to be configured to allow the forwarding of IP protocol 51 traffic. The upper-layer PDU is also unmodified. Inserting an AH creates additional packet overhead, which lowers the effective maximum transmission unit (MTU) between the two endpoints. Calculating the ICV for the AH header also imposes additional processing overhead for each protected packet. Using network adapters that can perform cryptographic calculations in hardware can minimize this overhead.

For AH transport mode, the ICV calculation is performed over the following:

  • All the fields in the IP header except those that are allowed to change in transit. These fields are the Type of Service (TOS), Flags, Fragment Offset, Time to Live (TTL), and Header Checksum, all of which are set to 0 for the ICV calculation. For source-routed IP traffic, the final destination IP address is predictable and the appropriate fields within the Loose Source Route and Strict Source Route options are allowed to change.
  • All the fields in the AH (the Authentication Data field is set to 0).
  • The upper-layer PDU.

For AH transport mode, the AH protects the IP header, except the fields that are allowed to change, and the upper-layer PDU of the original IP datagram.

Frame 11 of Network Monitor Capture 22-01 (in the \Captures folder on the companion CD-ROM) provides an example of an AH-protected ICMP Echo message.

AH Tunnel Mode

Figure 22-3 shows AH tunnel mode for an IP datagram.

Figure 22-3. AH tunnel mode.

In AH tunnel mode, the entire original IP datagram is encapsulated with a new (outer) IP header and an AH. In the IP header, the Protocol field is set to 51 (0x33) to indicate that an AH is present. For tunnel mode, the original IP header and upper-layer PDU are unmodified.

The outer IP header is constructed from the configuration of the IPSec tunnel. For IPSec for the Windows Server 2003 family, the destination IP address in the outer header is configured in the Tunnel Setting tab from the properties of an IPSec rule using the IP Security Policies snap-in. The source IP address is the locally assigned IP address that is the best source to reach the tunnel destination address.

For AH tunnel mode, the ICV calculation is performed over the following:

  • All the fields in the outer IP header except those that are allowed to change in transit (TOS, Flags, Fragment Offset, TTL, Header Checksum), all of which are set to 0 for the calculation.
  • All the fields in the AH (the Authentication Data field is set to 0).
  • The original IP packet.

For AH tunnel mode, the AH protects the entire original IP packet (both the IP header and the upper-layer PDU) at the expense of an additional outer IP header.

Encapsulating Security Payload (ESP) Header

Encapsulating Security Payload (ESP) is a header and trailer combination that provides data origin authentication, data integrity, replay protection, and data confidentiality for the ESP-encapsulated portion of the packet. Figure 22-4 shows the structure of the ESP header and trailer.

Figure 22-4. The IPSec Encapsulating Security Payload header and trailer.

The ESP header consists of the following fields:

  • Security Parameters Index A 4-byte field that identifies, when used in combination with the Destination IP Address field and transform (ESP), the spe-cific SA for this datagram.
  • Sequence Number A 4-byte field that is the same field is the Sequence Number field of the AH.

The ESP trailer consists of the following fields:

  • Padding A variable-length field that is used to pad the encrypted payload to an appropriate length (depending on the encryption algorithm used), align the ESP portion of the packet along 4-byte boundaries, or deliberately obscure the encrypted payload's length.
  • Padding Length A 1-byte field that specifies the number of bytes in the Padding field.
  • Next Header A 1-byte field used to identify the next header in the payload. This field uses the same values as the Protocol field in the IP header.
  • Authentication Data A variable-length field that contains the ICV calculation of the sender (the HMAC MD5 or HMAC SHA1 value).

Because the use of a specific ICV algorithm is negotiated before data with an ESP header and trailer is sent, each peer knows the size of the Authentication Data portion of the ESP trailer and can determine the location of the end of the ESP-encapsulated payload.

Frame 11 of Network Monitor Capture 22-02 (in the \Captures folder on the companion CD-ROM) provides an example of an ESP-protected payload. Network Monitor cannot interpret the encrypted portions of an ESP-protected packet.

ESP Transport Mode

Figure 22-5 shows ESP transport mode for an IP datagram.

Figure 22-5. ESP transport mode.

For ESP transport mode, the ESP header is added to the IP datagram just after the IP header and the ESP trailer is added just after the upper-layer PDU. In the IP header, the Protocol field is set to 50 (0x32) to indicate that an ESP header is present. Other than changing the Protocol field, the original IP header is unmodified. Routers forward this traffic as any other IP packet. Firewalls, on the other hand, might need to be configured to allow the forwarding of IP protocol 50 traffic. The upper-layer PDU is also unmodified.

Like AH, inserting an ESP header and trailer creates additional packet overhead, which lowers the effective MTU between the two endpoints. Performing the data encryption and calculating the ICV for the ESP trailer imposes additional processing overhead for each protected packet. Using network adapters that can perform cryptographic calculations in hardware can minimize this overhead.

For ESP transport mode, the following portions of the packet are encrypted:

  • The upper-layer PDU
  • The Padding, Padding Length, and Next Header fields of the ESP trailer

For encryption algorithms such as DES that use CBC, there is an unencrypted field between the ESP header and the upper-layer PDU. This field is the IV for the CBC calculation performed at the receiver. This field cannot be encrypted because it is used to begin the decryption process. For DES and 3DES, the IV is 64 bits (8 bytes) long.

The inclusion of the IV as plaintext in the packet is not a security problem. The IV does not provide additional cryptographic strength, only a way to ensure that the encryption of the same block does not produce the same ciphertext. A malicious user might be able to view the IV, but without the encryption key, he or she cannot decrypt the ciphertext portion of the packet. To prevent a malicious user from modifying the IV and causing the receiver to produce garbled deciphered data, the IV is protected by the ICV.

For ESP transport mode, the ICV calculation is performed over the following:

  • All the fields in the ESP header
  • The upper-layer PDU (including the plaintext IV, if needed)
  • All the fields in the ESP trailer except the Authentication Data field

For ESP transport mode, the ESP trailer does not provide protection for the IP header and the Authentication Data field of the ESP trailer. To obtain protection for these elements, use both AH and ESP, as shown in Figure 22-6.

Figure 22-6. Using both AH and ESP to protect an IP packet.

In this situation, the ESP header and trailer wraps the upper-layer PDU, which then becomes the upper-layer PDU that is wrapped with an AH and the original IP header. Now the entire packet is protected (except the changeable fields in the IP header).

Frame 11 of Network Monitor Capture 22-03 (in the \Captures folder on the companion CD-ROM) provides an example of an AH- and ESP-protected IP payload.

ESP Tunnel Mode

Figure 22-7 shows ESP tunnel mode for an IP datagram.

Figure 22-7. ESP tunnel mode.

In ESP tunnel mode, the entire original IP datagram is encapsulated with a new (outer) IP header and an ESP header and trailer. In the outer IP header, the Protocol field is set to 50 (0x32) to indicate that an ESP header is present. For tunnel mode, the original IP header and upper-layer PDU are unmodified. Like AH tunnel mode, the outer IP header is constructed from the configuration of the IPSec tunnel.

For ESP tunnel mode, the following portions of the packet are encrypted:

  • The original IP datagram (IP header and upper-layer PDU)
  • The Padding, Padding Length, and Next Header fields of the ESP trailer

For ESP tunnel mode, the ICV calculation is performed over the following:

  • All the fields in the ESP header
  • The original IP datagram (IP header and upper-layer PDU), including the plaintext IV, if needed
  • All the fields in the ESP header except the Authentication Data field

For ESP tunnel mode, the ESP trailer does provide protection for the original IP header and upper-layer PDU, but does not provide protection for the outer IP header and the Authentication Data field of the ESP trailer.

ESP is defined in RFC 2406, which can be found in the \Rfc folder on the companion CD-ROM.


Internet Key Exchange

The Internet Key Exchange (IKE) is a standard that defines a mechanism to establish SAs. IKE, described in RFC 2409, combines ISAKMP and the Oakley Key Determination Protocol.

IPSec uses the ISAKMP protocol to negotiate SAs. ISAKMP includes facilities to identify and authenticate peers, manage SAs, and exchange key material. ISAKMP is a framework for negotiating secure communications independent of specific key exchange protocols, encryption and integrity algorithms, and authentication methods.

To generate secret key material for secure communications, IKE uses the Oakley Key Determination protocol. Oakley is based on the Diffie-Hellman key exchange algorithm, which allows two peers to determine a secret key by exchanging unencrypted values over a public network. The shared secret key becomes keying material from which secret keys for HMAC or encryption algorithms are derived.

The details of the Diffie-Hellman algorithm and the Oakley protocol are outside the scope of this book, but they are described in RFC 2412. IKE is defined in RFC 2407. Both of these RFCs can be found in the \Rfc folder on the companion CD-ROM.


ISAKMP Message Structure

ISAKMP messages are sent as the payload of UDP messages using UDP port 500. Figure 22-8 shows the format of an ISAKMP message.

Figure 22-8. An ISAKMP message.

The ISAKMP message consists of an ISAKMP header and one or more ISAKMP payloads. The ISAKMP payloads contain negotiation information and are encrypted for most ISAKMP messages. The encryption protects the negotiation from being viewed by malicious users who are capturing ISAKMP traffic. The encrypted portions of ISAKMP messages cannot be viewed with Network Monitor.

ISAKMP is defined in RFC 2408, which can be found in the \Rfc folder on the companion CD-ROM.

ISAKMP Header

The ISAKMP header is a standard header that is present for all ISAKMP messages and contains information about the message, including the type of packet. Figure 22-9 shows the format of the ISAKMP header.

Figure 22-9. The ISAKMP header.

The fields in the ISAKMP header are defined as follows:

  • Initiator Cookie An 8-byte field that is set to a nonzero random number chosen by the IPSec peer that initiated the SA, is performing a notification about an existing SA, or is deleting the SA.
  • Responder Cookie An 8-byte field that is set to a nonzero random number chosen by the IPSec peer responding to the peer that initiated an SA.
  • Next Payload A 1-byte field that indicates the type of the payload that follows the ISAKMP header. Table 22-1 lists the payload types defined in RFC 2408.
    Table 22-1. Values of the Next Payload Field
    Next Payload Value Next Payload Type

    0

    None

    1

    SA

    2

    Proposal

    3

    Transform

    4

    Key Exchange

    5

    Identification

    6

    Certificate

    7

    Certificate Request

    8

    Hash

    9

    Signature

    10

    Nonce

    11

    Notification

    12

    Delete

    13

    Vendor ID

    14-127

    Reserved

    128-255

    Private Use

  • Major Version A 4-bit field that indicates the major version of the ISAKMP protocol for this message. This field must be set to 1 if the implementation complies with RFC 2408. ISAKMP messages with a higher supported major version number are discarded.
  • Minor Version A 4-bit field that indicates the minor version of the major version of the ISAKMP protocol for this message. This field must be set to 0 if the implementation complies with RFC 2408. ISAKMP messages with a higher supported minor version number are discarded, within the same supported major version.
  • Exchange Type A 1-byte field that indicates the type of ISAKMP exchange being performed for this ISAKMP message. The type of exchange dictates the structure and the order of ISAKMP payloads. Table 22-2 lists the exchange types defined in RFC 2408.
    Table 22-2. Values of the Exchange Type Field
    Exchange Type Value Exchange Type

    0

    None

    1

    Base

    2

    Identity Protection

    3

    Authentication Only

    4

    Aggressive

    5

    Informational

    6-31

    ISAKMP Future Use

    32-127

    DOI Specific Use

    128-255

    Private Use

  • Flags A 1-byte field containing ISAKMP flags that are set for this ISAKMP message. There are three flags defined in RFC 2408. The low-order bit (bit 0) is the Encryption bit, which indicates that the ISAKMP payloads are encrypted (when set to 1) or not encrypted (when set to 0). Encryption is done using the algorithm negotiated for the ISAKMP SA, which is identified by the combination of the Initiator Cookie and Responder Cookie fields. The next low-order bit (bit 1) is the Commit bit, which indicates that the key exchange is synchronized (when set to 1) or not synchronized (when set to 0). The Commit bit is used to ensure that the SA completes its negotiation before encrypted data is sent. The next low-order bit (bit 2) is the Authentication Only bit, which is used to indicate that the message either contains (when set to 1) or does not contain (when set to 0) the entire Notify payload of the informational exchange type and it has been authenticated but not encrypted.
  • Message ID A 4-byte field that contains a unique identifier for the message. The Message ID is used to prevent collisions due to both IPSec peers attempting to simultaneously establish an IPSec SA. The Message ID field is set to 0 for the ISAKMP SA establishment.
  • Length A 4-byte field that indicates the length of the entire ISAKMP message.

SA Payload

The SA payload is used to indicate the domain of interpretation (DOI) and situation for the SA negotiation. The DOI is a set of definitions for payload formats, exchange types, and naming conventions for security-related information, such as the naming of policies and cryptographic algorithms. A situation is a set of information that identifies security services in the ISAKMP message. Figure 22-10 shows the format of the SA payload.

Figure 22-10. The SA payload.

The fields in the SA payload are defined as follows:

  • Next Payload A 1-byte field that indicates the next payload in the message. Next Payload is set to 0 for the last payload in the message. For the SA payload, the Next Payload field does not indicate the Proposal or Transform payloads because they are considered part of the SA payload.
  • Reserved A 1-byte field set to 0.
  • Payload Length A 2-byte field that indicates the length of the payload. For the SA payload, the length includes the Proposal and Transform payloads.
  • Domain of Interpretation A 4-byte field that indicates the DOI. For IPSec and ISAKMP, the DOI field is set to 1. RFC 2407 describes the IPSec DOI for ISAKMP.
  • Situation A variable-length field that identifies the situation for the negotiation. For IPSec, the values of the Situation field are defined in RFC 2407. For example, the Situation field is set to 1 for SIT_IDENTITY_ONLY, a situation that specifies that the identity of the sending source is contained in an Identification payload. See section 4 of RFC 2407 for additional situation definitions.
The Next Payload, Reserved, and Payload Length fields are common to all ISAKMP payloads. Therefore, they are not described in the payload sections that follow unless there are additional considerations for their use.

Proposal Payload

The Proposal payload contains security parameter information that is used to negotiate the security settings for either an ISAKMP or IPSec SA. The Proposal payload contains proposal settings and then a series of one or more Transform payloads that contain the specific security settings for encryption and authentication algorithms for the SA. Figure 22-11 shows the format of the Proposal payload.

Figure 22-11. The Proposal payload.

The fields in the Proposal payload are defined as follows:

  • Next Payload For the Proposal payload, the Next Payload field must be set to either 2 for additional Proposal payloads or 0 for no more Proposal payloads.
  • Payload Length For the Proposal payload, the Payload Length field indicates the length of the entire Proposal payload, which includes the Transform payloads for this Proposal payload.
  • Proposal # A 1-byte field that indicates the number of this proposal.
  • Protocol-ID A 1-byte field that specifies the protocol identifier for the traffic to be secured. The values are the same as the Protocol field in the IP header. For example, 1 for ICMP, 6 for TCP, 17 for UDP, and so on.
  • SPI Size A 1-byte field that indicates the length of the SPI for the protocol indicated by the Protocol-ID field. If the protocol indicated by the Protocol-ID field does not use a SPI, it is set to 0.
  • # of Transforms A 1-byte field that indicates the number of Transform payloads for this proposal.
  • SPI A variable-size field that contains the SPI. This field is only present if the SPI Size field is greater than 0.

Transform Payload

The Transform payload contains information that identifies a specific security mechanism, or transform, that is proposed to secure future traffic. The Transform payload also contains SA attributes, as defined in RFC 2407 for the IPSec DOI. Figure 22-12 shows the Transform payload.

Figure 22-12. The Transform payload.

The fields in the Transform payload are defined as follows:

  • Next Payload For the Transform payload, the Next Payload field must be set to either 3 for additional Transform payloads or 0 for no more Transform payloads for this proposal.
  • Payload Length For the Transform payload, the Payload Length field indicates the length of the entire Transform payload, which includes the SA attributes for this Transform payload.
  • Transform # A 1-byte field that indicates the number of this transform.
  • Transform-ID A 1-byte field that indicates the Transform identifier for the protocol of the proposal. Transform IDs are defined in RFC 2407 for the IPSec DOI.
  • Reserved2 A 2-byte field that is set to 0.
  • SA Attributes Variable-length fields that define the SA attributes for the transform. SA attributes are either in type-value or type-length (2 bytes)-value (TLV) format. In both cases, the Type field is 2 bytes in length. To distinguish type-value from TLV format, the high-order bit of the Attribute Type field is set to 1 for type-value format and 0 for TLV format. SA attributes for the IPSec DOI are defined in section 4.5 of RFC 2407.

The following Network Monitor frame (Frame 1 of Capture 22-01 in the \Captures folder on the companion CD-ROM) displays the relationship among the SA, Proposal, and Transform payloads, and the SA attributes within a Transform payload:

+ Frame: Base frame properties

+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol

+ IP: ID = 0x261A; Proto = UDP; Len: 304

+ UDP: Src Port: ISAKMP, (500); Dst Port: ISAKMP (500); Length = 284 (0x11C)

  ISAKMP: Major Version: 1  Minor Version: 0  Length: 276

      ISAKMP: Initiator cookie = 18 DE 7D 29 15 E6 06 71

      ISAKMP: Responder cookie = 00 00 00 00 00 00 00 00

      ISAKMP: Next payload = Security Association

      ISAKMP: Major version = 1 (0x1)

      ISAKMP: Minor version = 0 (0x0)

      ISAKMP: Exchange type = Identity Protection

    + ISAKMP: Flags summary = 0 (0x0)

      ISAKMP: Message ID = 0 (0x0)

      ISAKMP: Length = 276 (0x114)

      ISAKMP: Payload type = Security Association

          ISAKMP: Next payload = Vendor ID

          ISAKMP: Reserved = 0 (0x0)

          ISAKMP: Payload length = 164 (0xA4)

          ISAKMP: DOI = 1 (0x1)

          ISAKMP: Situation = SIT_INDENTITY_ONLY

          ISAKMP: Payload type = Proposal

              ISAKMP: Next payload = None

              ISAKMP: Reserved = 0 (0x0)

              ISAKMP: Payload length = 152 (0x98)

              ISAKMP: Proposal number = 1 (0x1)

              ISAKMP: Protocol ID = 1 (0x1)

              ISAKMP: SPI size = 0 (0x0)

              ISAKMP: Number of transforms = 4 (0x4)

              ISAKMP: Payload type = Transform

                  ISAKMP: Next payload = Transform

                  ISAKMP: Reserved = 0 (0x0)

                  ISAKMP: Payload length = 36 (0x24)

                  ISAKMP: Transform number = 1 (0x1)

                  ISAKMP: Transform ID = 1 (0x1)

                  ISAKMP: Reserved = 0 (0x0)

                + ISAKMP: SA attribute = 80 01 00 05

                + ISAKMP: SA attribute = 80 02 00 02

                + ISAKMP: SA attribute = 80 04 00 02

                + ISAKMP: SA attribute = 80 03 00 01

                + ISAKMP: SA attribute = 80 0B 00 01

                + ISAKMP: SA attribute = 00 0C 00 04 00 00 70 80

            + ISAKMP: Payload type = Transform

            + ISAKMP: Payload type = Transform

            + ISAKMP: Payload type = Transform

    + ISAKMP: Payload type = Vendor ID

    + ISAKMP: Payload type = Vendor ID

    + ISAKMP: Payload type = Vendor ID

    + ISAKMP: Payload type = Vendor ID

Vendor ID Payload

The Vendor ID payload contains a string or number that either indicates a specific capability or is defined by a vendor so that an IPSec implementation can recognize an IPSec peer running the same implementation. IPSec peers are not required to run the same implementation or support the same capabilities, so the sending of Vendor ID payloads and the actions taken when they are received are optional. If a receiver recognizes the Vendor ID, it can make use of the capability or use private payloads, which use the Payload ID numbers 128 through 255. For vendor identification, the Vendor ID value must be unique and is typically a hash of well-known text chosen by the designers of an IPSec implementation. For capability identification, the Vendor ID value must be unique and is typically chosen by the designers of the IPSec capability.

Figure 22-13 shows the format of the Vendor ID payload.

Figure 22-13. The Vendor ID payload.

The only field in the Vendor ID payload (besides the Next Header, Reserved, and Payload Length fields) is the Vendor ID field, a variable-length field that contains the Vendor ID value.

IPSec for the Windows Server 2003 family uses four different Vendor ID payloads: a Vendor ID payload to indicate a Microsoft IPSec peer, a Vendor ID payload to indicate Network Address Translator Traversal capability, a Vendor ID payload to indicate fragmentation support, and a Vendor ID payload to indicate support for network load balancing.

Nonce Payload

The Nonce payload contains a pseudorandom number that is used to ensure a live exchange and provide replay protection. Nonces are also used to calculate hashes in other payloads. Figure 22-14 shows the format of the Nonce payload.

Figure 22-14. The Nonce payload.

The only field in the Nonce payload (besides the Next Header, Reserved, and Payload Length fields) is the Nonce Data field, a variable-length field that contains the pseudorandom number determined by the sender of the ISAKMP message.

Key Exchange Payload

The Key Exchange payload contains information pertaining to the key exchange process. The key exchange process supported by IPSec for the Windows Server 2003 family is Diffie-Hellman. With Diffie-Hellman, two IPSec peers exchange key values that are sent in plaintext. From the key values, each IPSec peer calculates the same private key. What is interesting about the Diffie-Hellman exchange is that a malicious user between the IPSec peers can view the exchanged key values, but cannot easily calculate the same result as the IPSec peers. Figure 22-15 shows the format of the Key Exchange payload.

Figure 22-15. The Key Exchange payload.

The only field in the Key Exchange payload (besides the Next Header, Reserved, and Payload Length fields) is the Key Exchange Data field, a variable-length field that contains the key exchange value determined by the sender of the ISAKMP message.

Notification Payload

The Notification payload is used to transmit control information, such as an error condition, to an IPSec peer. A single ISAKMP message can contain multiple Notification payloads. For Notification payloads within a main mode message, the initiator and responder cookies identify the negotiation. Figure 22-16 shows the format of the Notification payload.

Figure 22-16. The Notification payload.

The fields in the Notification payload are defined as follows:

  • Domain of Interpretation A 4-byte field that identifies the DOI for the notification. For the ISAKMP DOI, the value is 0. For the IPSec DOI, the value is 1.
  • Protocol-ID A 1-byte value that indicates the protocol to which the notification applies.
  • SPI Size A 1-byte field that indicates the length of the SPI field. For ISAKMP, the security identifier is the initiator/responder cookie pair. Therefore, the SPI Size field is set to 16 and the SPI field contains the initiator/responder cookie pair.
  • Notify Message Type A 2-byte field that specifies the type of notification message.
  • SPI A variable-length field that specifies the SPI for the notification.
  • Notification Data A variable-length field that contains additional information or text for the notification message indicated by the Notify Message Type field.

Table 22-3 lists some of the notification error messages specified in RFC 2408. For a complete list, see section 3.14.1 of RFC 2408.

Table 22-3. Notification Error Messages
Notification Message Type Value | Notification Message
1 | INVALID-PAYLOAD-TYPE
2 | DOI-NOT-SUPPORTED
3 | SITUATION-NOT-SUPPORTED
4 | INVALID-COOKIE
5 | INVALID-MAJOR-VERSION
6 | INVALID-MINOR-VERSION

Table 22-4 lists some of the notification status messages specified in RFC 2408.

Table 22-4. Notification Status Messages
Notification Message Type Value | Notification Message
16384 | CONNECTED
16385-24575 | RESERVED (Future Use)
24576-32767 | DOI-specific codes
32768-40959 | Private Use
40960-65535 | RESERVED (Future Use)

Delete Payload

The Delete payload is used to inform an IPSec peer that an SA for a specific protocol has been deleted. The receiver should remove its corresponding SA. IPSec for the Windows Server 2003 family now supports verification of Delete payloads. If an ISAKMP message with a Delete payload is received, the receiver acknowledges it. If an acknowledgment is not received, the Delete payload is resent. Figure 22-17 shows the format of the Delete payload.

Figure 22-17. The Delete payload.

The fields in the Delete payload are defined as follows:

  • Domain of Interpretation A 4-byte field that identifies the DOI. The DOI is 0 for ISAKMP and 1 for IPSec.
  • Protocol-ID A 1-byte field that identifies the protocol for the SA that was deleted. The Protocol-ID indicates ISAKMP for main mode SA deletions and ESP or AH for quick mode SA deletions.
  • SPI Size A 1-byte field that indicates the length of the SPI field. For the ISAKMP protocol, the SPI is the initiator/responder cookie pair.
  • # of SPIs A 2-byte field that indicates the number of SPIs in this Delete payload.
  • Security Parameter Index(es) A variable-length field that identifies the SAs to delete. All of the SPIs have the same length, as indicated with the SPI Size field.

Identification Payload

The Identification payload is used to convey identification information and authenticate an IPSec peer.

Figure 22-18 shows the format of the Identification payload.

Figure 22-18. The Identification payload.

The fields in the Identification payload are defined as follows:

  • ID Type A 1-byte field that indicates the type of identification.
  • DOI Specific ID Data A 3-byte field that contains DOI-specific data. If not used, this is set to 0.
  • Identification Data A variable-length field that contains identity information.

Hash Payload

The Hash payload contains a hash value that is a result of a hash function computed over a set of fields or other parameters. The Hash payload can be used to provide integrity or authentication of negotiating peers. Figure 22-19 shows the format of the Hash payload.

Figure 22-19. The Hash payload.

The only field in the Hash payload (besides the Next Header, Reserved, and Payload Length fields) is the Hash Data field, a variable-length field that contains the hash value. Both IPSec peers must agree to the set of fields or other parameters over which the hash is calculated.

Certificate Request Payload

The Certificate Request payload is used to request certificates from an IPSec peer. After receipt of an ISAKMP message with a Certificate Request payload, an IPSec peer must send a certificate or certificates based on the contents of the Certificate Request payload. Figure 22-20 shows the format of the Certificate Request payload.

Figure 22-20. The Certificate Request payload.

The fields in the Certificate Request payload are defined as follows:

  • Certificate Type A 1-byte field that indicates the type of the certificate requested. Table 22-5 lists the certificate types defined in RFC 2408.
    Table 22-5. Certificate Type Values
    Certificate Type Value Certificate Type

    0

    None

    1

    PKCS #7 wrapped X.509 certificate

    2

    PGP Certificate

    3

    DNS Signed Key

    4

    X.509 Certificate: Signature

    5

    X.509 Certificate: Key Exchange

    6

    Kerberos Tokens

    7

    Certificate Revocation List (CRL)

    8

    Authority Revocation List (ARL)

    9

    SPKI Certificate

    10

    X.509 Certificate: Attribute

    11-255

    Reserved

  • Certificate Authority A variable-length field that contains an acceptable certification authority (CA) for the indicated type of certificate. For example, for an X.509 certificate, the distinguished name of the issuing CA is used. If there is no specific CA required by the sending IPSec peer, this field is not present.

Certificate Payload

The Certificate payload is used by an IPSec peer when sending its certificate. This is typically done during the authentication phase of main mode negotiation. Figure 22-21 shows the format of the Certificate payload.

Figure 22-21. The Certificate payload.

The fields in the Certificate payload are defined as follows:

  • Certificate Encoding A 1-byte field that indicates the method for encoding the certificate information in the Certificate Data field. Table 22-5 lists the values of the Certificate Encoding field defined in RFC 2408. The same values for the Certificate Type field of the Certificate Request payload are used for the Certificate Encoding field in the Certificate payload.
  • Certificate Data A variable-length field that contains the encoding of the certificate using the encoding method indicated in the Certificate Encoding field.

Signature Payload

The Signature payload is used to send digital signatures calculated over a set of fields or parameters. The Signature payload provides data integrity and nonrepudiation services during the authentication phase of main mode negotiation. Figure 22-22 shows the format of the Signature payload.

Figure 22-22. The Signature payload.

The only field in the Signature payload (besides the Next Header, Reserved, and Payload Length fields) is the Signature Data field, a variable-length field that contains the digital signature value. Both IPSec peers must agree on the set of fields and parameters over which the digital signature is calculated.


Main Mode Negotiation

Oakley main mode negotiation is used to determine encryption key material and security protection for use in protecting subsequent main mode or quick mode communications. Main mode negotiation occurs in the following steps:

  1. Negotiation of protection suites
  2. A Diffie-Hellman exchange
  3. Authentication
IPSec for the Windows Server 2003 family does not support aggressive mode negotiation.

Main mode negotiation consists of six ISAKMP messages: three sent by the initiator and three sent by the responder. Messages 1 and 2 are for the negotiation of protection suites. Messages 3 and 4 are for the Diffie-Hellman exchange. Messages 3 through 6 can be used for authentication. The specific contents of messages 3 through 6 depend on the authentication method.

Negotiation of Protection Suites

The first message in an IKE negotiation is sent by the initiator and contains the following payloads:

  • SA The SA payload contains a Proposal payload, which contains a series of Transform payloads, each of which contains a series of security attributes. The SA payload is the set of protection suites (which include allowed encryption algorithms, hash algorithms, authentication methods, and Diffie-Hellman Oakley groups) that are acceptable to the initiator. This set of protection suites is configured in the Key Exchange Security Methods dialog box in the IP Security Management snap-in. The authentication methods are configured in the Authentication Methods tab from the properties of an IPSec rule.
  • Vendor ID The Vendor ID payloads contain vendor identification and capability indication.

The second message in an IKE negotiation is sent by the responder and contains the following payloads:

  • SA The SA payload contains a Proposal payload, which contains a single Transform payload corresponding to the protection suite that was offered by the initiator in the first message and is acceptable to the responder. Because the responder might select the first transform in the first message that is acceptable, it is a good practice to configure the key exchange security settings in order of most to least secure.
  • Vendor ID The Vendor ID payloads contain vendor identification and capability indication.

Table 22-6 lists the protection suite attributes that are supported by IPSec for the Windows Server 2003 family.

Table 22-6. Main Mode Attribute Values Supported by the Windows Server 2003 Family
Attribute | Attribute Value
Encryption algorithm | DES, 3DES
Integrity algorithm | MD5, SHA-1
Authentication method | Kerberos, preshared key, certificate
Diffie-Hellman group | Group 1 (768-bit), Group 2 (1024-bit), 2048-bit

Key Exchange and Authentication

IPSec for the Windows Server 2003 family supports three methods of authentication:

  • Kerberos
  • Certificates
  • Preshared key

Unlike Point-to-Point Protocol (PPP) authentication for dial-up or virtual private network (VPN) connections, which authenticates the user using the computer at the time of the authentication negotiation, IPSec authentication authenticates only the computer at the time of the negotiation.

Kerberos Authentication

Kerberos authentication is the default authentication method. It is designed for use between computers in an Active Directory domain. Kerberos authentication for IPSec main mode is based on the Generic Security Service (GSS) API IKE authentication method, described in the Internet draft entitled "A GSS-API Authentication Method for IKE," which can be found in the \Ietf Drafts folder on the companion CD-ROM.

The third message for a Kerberos-authenticated main mode negotiation, sent by the initiator, contains the following payloads:

  • Key Exchange The Key Exchange payload contains Diffie-Hellman private key determination information as derived by the initiator.
  • Nonce The Nonce payload contains a pseudorandom number derived by the initiator.
  • Kerberos Token The Kerberos Token payload contains the initiator's Kerberos token to be validated by the responder.
  • NAT-Discovery Two NAT-Discovery payloads contain hashes of the initiator's source and destination addresses and ports. For more information, see the section "IPSec NAT Traversal," later in this chapter.

The fourth message for a Kerberos-authenticated main mode negotiation, sent by the responder, contains the following payloads:

  • Key Exchange The Key Exchange payload contains Diffie-Hellman private key determination information as derived by the responder. The initiator and responder use both sets of Diffie-Hellman key material and derive the same private key.
  • Nonce The Nonce payload contains a pseudorandom number derived by the responder.
  • Kerberos Token The Kerberos Token payload contains the responder's Kerberos token to be validated by the initiator.
  • NAT-Discovery Two NAT-Discovery payloads contain hashes of the responder's source and destination addresses and ports.

The fifth message for a Kerberos-authenticated main mode negotiation, which is sent by the initiator and encrypted, contains the following payloads:

  • Identification The Identification payload contains information that identifies the initiator.
  • Hash The Hash payload contains a hash result calculated by the initiator.

The sixth message for a Kerberos-authenticated main mode negotiation, which is sent by the responder and encrypted, contains the following payloads:

  • Identification The Identification payload contains information that identifies the responder.
  • Hash The Hash payload contains a hash result calculated by the responder.

Kerberos authentication is successful when each peer verifies the other peer's Kerberos token and hash value.

The hash calculation is performed over the following values:

  • The Diffie-Hellman key exchange values sent by both the initiator and responder
  • The initiator and responder cookies
  • The ISAKMP payloads of main mode message 2
  • The identity name string for the IPSec peer
  • The IPSec peer's Kerberos token

Network Monitor Capture 22-02 (in the \Captures folder on the companion CD-ROM) provides an example of Kerberos authentication.

Certificate Authentication

Certificate authentication involves the exchange of public key certificates for validation. IPSec for the Windows Server 2003 family supports X.509 version 3 certificates and certificate authentication must be configured in the Authentication Method tab for a rule within an IPSec policy. When configuring certificate authentication, the list of trusted root CAs is specified. You do not necessarily specify the root CA of the issuing CA of the certificate that will be sent, only the root CAs for the issuing CAs of the certificates that are acceptable to receive. Internally, IPSec for the Windows Server 2003 family uses the CryptoAPI to perform various certificate retrieval, verification, and digital signature creation functions.

The third message for a certificate-authenticated main mode negotiation, sent by the initiator, contains the following payloads:

  • Key Exchange The Key Exchange payload contains Diffie-Hellman private key determination information as derived by the initiator.
  • Nonce The Nonce payload contains a pseudorandom number derived by the initiator.
  • NAT Discovery Two NAT-Discovery payloads contain hashes of the initiator's source and destination addresses and ports.

The fourth message for a certificate-authenticated main mode negotiation, sent by the responder, contains the following payloads:

  • Key Exchange The Key Exchange payload contains Diffie-Hellman private key determination information as derived by the responder. The initiator and responder use both sets of Diffie-Hellman key material and derive the same private key.
  • Nonce The Nonce payload contains a pseudorandom number derived by the responder.
  • Certificate Request The Certificate Request payload contains a list of trusted root CAs from which a certificate is acceptable to the responder.
  • NAT Discovery Two NAT-Discovery payloads contain hashes of the responder's source and destination addresses and ports.

The fifth message for a certificate-authenticated main mode negotiation, which is sent by the initiator and is encrypted, contains the following payloads:

  • Identification The Identification payload contains information that identifies the initiator.
  • Certificate The Certificate payload contains a certificate acceptable to the responder.
  • Certificate Request The Certificate Request payload contains a list of trusted root CAs from which a certificate is acceptable to the initiator.
  • Signature The Signature payload contains a digital signature, providing proof that the initiator has access to the private key of the sent certificate. The digital signature is calculated over the Diffie-Hellman keys, the initiator and responder cookies, the SA, and the initiator's identity.

The sixth message for a certificate-authenticated main mode negotiation, which is sent by the responder and is encrypted, contains the following payloads:

  • Identification The Identification payload contains information that identifies the responder.
  • Certificate The Certificate payload contains a certificate acceptable to the initiator.
  • Signature The Signature payload contains a digital signature, providing proof that the responder has access to the private key of the sent certificate. The digital signature is calculated over the Diffie-Hellman keys, the initiator and responder cookies, the SA, and the responder's identity.

Certificate authentication is successful when each peer verifies the other peer's certificate and digital signature.

For Layer Two Tunneling Protocol with IPSec (L2TP/IPSec) connections, you cannot configure the list of trusted root CAs. The list of trusted root CAs is based on the root CAs for the issuing CAs for certificates installed in the Local Computer certificate store. To have a successful L2TP/IPSec connection, each IPSec peer must have an installed computer certificate that was issued by an issuing CA of a trusted root CA that also issued computer certificates to the other IPSec peer.

Network Monitor Capture 22-04 (in the \Captures folder on the companion CD-ROM) provides an example of certificate authentication.

Certificate Revocation Checking

By default, IPSec for the Windows Server 2003 family does not perform certificate revocation checking on the sent certificate or the chain of certificates from the issuing CA to the root CA of the issuing CA. Certificate revocation checking is done by verifying that each certificate in the chain is not on a certificate revocation list (CRL) that was created and published by the issuing CA. To enable certificate revocation checking, use the following registry setting:

StrongCrlCheck

Location:  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley

Data type: REG_DWORD

Valid range: 0-2

Default: 0

Present by default: No

Set StrongCrlCheck to 1 to fail certificate revocation checking if the certificate has been revoked by verifying its revoked status with the CRL. If the CRL distribution point is not available on the network or the creator of the CRL did not issue the certificate, the certificate is assumed to be valid. Set StrongCrlCheck to 2 to fail the certification validation for any certificate revocation check error. In this case, the CRL distribution point must be reachable on the network, and it must verify that it issued the certificate and that it is not revoked. By default, StrongCrlCheck is set to 0, indicating that no certificate revocation checking is done.

If you change this value, you must stop and start the IPSec services either through the Services snap-in or by running the net stop policyagent and net start policyagent commands at a command prompt. If the computer is running Routing and Remote Access, you should stop the Routing and Remote Access service before you stop the IPSec services and start the Routing and Remote Access service after you start the IPSec services.

Preshared Key Authentication

Preshared key authentication involves the exchange of the knowledge of a manually configured preshared key. IPSec for the Windows Server 2003 family includes preshared key authentication to adhere to the IPSec standards and provide interoperability with other IPSec implementations that do not support Kerberos or certificate authentication.

A preshared key is configured in the Authentication Methods tab in the properties of an IPSec rule in the IP Security Policies snap-in. Because the preshared key is visible to all those who can view the IPSec policy settings (users with local or domain administrator privileges), preshared key authentication is not a secure authentication method and is not recommended for use in production environments.

The third message for a preshared key-authenticated main mode negotiation, sent by the initiator, contains the following payloads:

  • Key Exchange The Key Exchange payload contains Diffie-Hellman private key determination information as derived by the initiator.
  • Nonce The Nonce payload contains a pseudorandom number derived by the initiator.
  • NAT Discovery Two NAT-Discovery payloads contain hashes of the initiator's source and destination addresses and ports.

The fourth message for a preshared key-authenticated main mode negotiation, sent by the responder, contains the following payloads:

  • Key Exchange The Key Exchange payload contains Diffie-Hellman private key determination information as derived by the responder. The initiator and responder use both sets of Diffie-Hellman key material and derive the same private key.
  • Nonce The Nonce payload contains a pseudorandom number derived by the responder.
  • NAT Discovery Two NAT-Discovery payloads contain hashes of the responder's source and destination addresses and ports.

The fifth message for a preshared key-authenticated main mode negotiation, which is sent by the initiator and is encrypted, contains the following payloads:

  • Identification The Identification payload contains information that identifies the initiator.
  • Hash The Hash payload contains a hash result calculated by the initiator that incorporates the preshared key.

The sixth message for a certificate-authenticated main mode negotiation, which is sent by the responder and is encrypted, contains the following payloads:

  • Identification The Identification payload contains information that identifies the responder.
  • Hash The Hash payload contains a hash result calculated by the responder that incorporates the preshared key.

Preshared key authentication is successful when each peer verifies the other peer's hash.

Network Monitor Capture 22-05 (in the \Captures folder on the companion CD-ROM) provides an example of preshared key authentication.


Quick Mode Negotiation

When the main mode negotiation is complete, each IPSec peer has selected a specific set of cryptographic algorithms for securing main mode and quick mode messages, exchanged key information to derive a shared secret key, and performed authentication. Before secure data is sent, a quick mode negotiation must occur to determine the type of traffic to be secured and how it will be secured. A quick mode negotiation is also done when a quick mode SA expires. Quick mode messages are ISAKMP messages that are encrypted using the ISAKMP SA. The result of a quick mode negotiation is two IPSec SAs: one for inbound traffic and one for outbound traffic.

Quick mode negotiation for IPSec for the Windows Server 2003 family consists of four ISAKMP Messages. The first Quick Mode ISAKMP message, sent by the initiator, contains the following payloads:

  • SA The SA payload contains a list of proposals and encryption and hashing algorithms for how to secure the traffic (AH vs. ESP, DES vs. 3DES, and MD5 vs. SHA1) and a description of the traffic that is protected (IP addresses, IP Protocol IDs, TCP ports, UDP ports, etc.). These settings are a combination of the filter action, filter list, and tunnel settings for the properties of a rule in the IP Security Policies snap-in.
  • Identification The Identification payload contains a description of the traffic to be secured.
  • Nonce The Nonce payload contains a pseudorandom number to be used in subsequent hash calculations.

The second quick mode ISAKMP message, sent by the responder, contains the following payloads:

  • SA The SA payload contains a Proposal payload, which contains a single Transform payload corresponding to the protection suite that was offered by the initiator in the first quick mode message and is acceptable to the responder for the traffic to be secured.
  • Identification The Identification payload contains a description of the traffic to be secured.
  • Nonce The Nonce payload contains a pseudorandom number to be used in subsequent hash calculations.

The second message has the Commit flag in the ISAKMP header set.

The third quick mode ISAKMP message, sent by the initiator, contains the following payload:

  • Hash The Hash payload contains a hash value to provide verification and replay protection.

The fourth quick mode ISAKMP message, sent by the responder, contains the following payload:

  • Notification The Notification payload contains the Notify Message Type set to 16384 (the CONNECTED status message), indicating that the SA negotiation is complete.

The setting of the Commit bit in quick mode message 2 and the sending of the CONNECTED status message in quick mode message 4 are not required by the ISAKMP or IKE standards. IPSec for the Windows Server 2003 family uses this facility to prevent the initiator from sending IPSec-protected packets to the responder before the responder is ready to receive them.


Retransmit Behavior

For main mode negotiations, the retransmit behavior of the initiator is the following:

  1. Send main mode message 1. Wait 1 second for a response.
  2. If a response is not received, retransmit main mode message 1 and wait 2 seconds for a response. If unsecured communication is allowed, unsecured traffic can be sent. Even though unsecured traffic is sent, the initiator continues to attempt a main mode negotiation.
  3. Retransmit main mode message 1 and wait 4 seconds for a response.
  4. Retransmit main mode message 1 and wait 8 seconds for a response.
  5. Retransmit main mode message 1 and wait 16 seconds for a response.
  6. Retransmit main mode message 1 and wait 32 seconds for a response.
  7. Abandon main mode negotiation.

It takes 63 seconds for a main mode negotiation to fail. This retransmit behavior is part of the IKE standard. For unsecured traffic, it takes 3 seconds before the initiator sends unsecured traffic.

For quick mode negotiations, the retransmit behavior for either IPSec peer is the following:

  1. Send quick mode message 1 and wait 1 second for a response.
  2. Retransmit quick mode message 1 and wait 2 seconds for a response.
  3. Retransmit quick mode message 1 and wait 4 seconds for a response.
  4. Retransmit quick mode message 1 and wait 8 seconds for a response.
  5. Retransmit quick mode message 1 and wait 16 seconds for a response.
  6. Retransmit quick mode message 1 and wait 32 seconds for a response.
  7. If this quick mode negotiation is not the first quick mode for the current main mode (a rekey), restart quick mode negotiation. Otherwise, abandon quick mode negotiation.

It takes 63 seconds for a quick mode negotiation to fail. This retransmit behavior is part of the IKE standard. The initiator of the main mode negotiation does the initial quick mode negotiation. After a successful quick mode negotiation, either IPSec peer can initiate a new quick mode negotiation.


IPSec NAT Traversal

IPSec was designed to provide end-to-end security for two computers located in the same address domain. If two computers are located in different address domains, such as private IP addresses used on a home network and public IP addresses used on the Internet, then the addresses must be translated for communication to occur. The translation of addresses and TCP or UDP ports for network address translation to connect users to the Internet invalidates the security services of IPSec. Specifically, address and port translation causes the following problems for ESP-based IPSec traffic:

  • For ESP-protected packets, the TCP and UDP ports are encrypted and therefore cannot be translated.
  • ISAKMP messages calculate hashes and signatures based on SA information, which includes IP addresses. Translating the IP address invalidates the hash or signature.

Network Address Translators (NATs) are very prevalent in today's public address-starved Internet. To allow IKE negotiation and ESP-encapsulated packets to work over NATs, IPSec for the Windows Server 2003 family supports IPSec NAT traversal (NAT-T) as described in version 2 of the Internet drafts titled "UDP Encapsulation of IPSec Packets" and "Negotiation of NAT-Traversal in the IKE." These drafts are included in the \Ietf Drafts folder on the companion CD-ROM. NAT-T is especially useful when making L2TP/IPSec connections from a VPN client that is behind a NAT.

NAT-T consists of the following elements used during main mode:

  • The sending of a NAT-T capability Vendor ID payload, which indicates that the IPSec peer is capable of performing NAT traversal. The NAT-T capability Vendor ID payload is sent in main mode messages 1 and 2.
  • The sending of a NAT-Discovery (NAT-D) payload that contains a hash of the original packet's address and port number so that the receiving node can determine whether a NAT changed the IP address or port. Two separate NAT-D payloads are included in main mode messages 3 and 4. One NAT-D payload is for the destination address and port and the other is for the source address and port.

A receiving IPSec peer validates both NAT-D payloads. If either does not validate correctly, then an intermediate NAT is present and NAT-T quick mode options are used. In addition, a new IKE message header format is defined that uses UDP port 4500. The NAT- T IKE header contains a new Non-ESP Marker field that allows the receiver to distinguish between UDP-encapsulated ESP-protected traffic and NAT-T IKE messages.

NAT-T consists of the following elements used during quick mode:

  • The inclusion of either UDP-Encapsulated-Tunnel or UDP-Encapsulated-Transport encapsulation mode in the proposals of the SA payload of quick mode message 1.
  • The sending of a NAT-Original Address (NAT-OA) payload to indicate the original source address to the IPSec peer. The NAT-Original Address (NAT-OA) payload is included in quick mode messages 1 and 2.

NAT-T for IKE and ESP consists of the following elements used when sending data:

  • The encapsulation of an ESP-protected payload with a UDP header that uses the same UDP ports as ISAKMP. By including a UDP header, the NAT can change the UDP port number and it is not part of the ESP-encrypted payload or the ISAKMP Hash or Signature payload calculation.
  • If the IPSec peer is behind a NAT, it sends a periodic NAT-Keepalive packet, which is a single-byte (0xFF) UDP message that uses the ISAKMP UDP ports. The NAT-Keepalive packet is used to persist the NAT's UDP port mapping for ISAKMP and UDP-encapsulated ESP traffic. Without the use of the NAT-Keepalive packet, the UDP port mapping in the NAT eventually times out and packets from the IPSec peer are silently discarded. The IKE module on the receiving IPSec peer immediately discards the NAT-Keepalive packets.

The combination of these elements and additional processing steps allows:

  • ISAKMP to detect a NAT-T-capable IPSec peer and the presence of NATs between the peers.
  • ISAKMP to complete main mode and quick mode negotiation despite the NAT's presence.
  • ESP-protected traffic to traverse a NAT.


Summary

IPSec is the standard method of providing security services for IP packets. The two protocols used for IP packet protection are AH and ESP. AH provides data origin authentication, data integrity, and replay protection for the entire IP packet, except for the fields in the IP header that are allowed to change. ESP provides data origin authentication, data integrity, data confidentiality, and replay protection for the ESP-encapsulated payload. To negotiate SAs for sending secure traffic, IPSec uses IKE, a combination of ISAKMP and the Oakley Key Determination Protocol. ISAKMP messages contain many types of payloads to exchange information during SA negotiation. Main mode negotiation is used to establish the ISAKMP SA, which is used to protect future main mode and all quick mode negotiations. Quick mode negotiation is used to establish the IPSec SA to protect data. IPSec NAT-T is a set of ISAKMP payloads and changes to the ISAKMP protocol that provides ESP protection for IPSec peers located behind a NAT.


Virtual Private Networks (VPNs)

Chapter 23
Virtual Private Networks (VPNs)

Computer networks have become a central part of the corporate infrastructure in organizations of all sizes. A challenge that continues to face organizations is how to connect remote sites and remote users in the most reliable, flexible, and cost-effective manner. A similar issue confronts individual corporate remote users who need to access their e-mail and internal servers while away from the office.

Traditionally, remote sites were connected to a central corporate hub by the use of leased lines, frame relay, or Asynchronous Transfer Mode (ATM) networks. Remote users were served by dial-in networking facilities, often using inbound free phone numbers. These approaches tend to be expensive and inflexible, however. The basic unit costs of leased lines and inbound free phone facilities continue to decline in real terms, but the bandwidth required and the overall costs to the organization rise. In addition, the infrastructure becomes harder to manage. These approaches can also lead to pressure on flexibility. The lead time required for a leased line can be substantial, depending on the source and destination, and often a minimum-length contract is required. Organizations today need greater flexibility.

A virtual private network (VPN) enables you to create a secure private network utilizing some other public network such as the Internet, which might be less secure. The data is kept private as it is traveling across the VPN by means of encapsulation, authentication, and encryption.

VPN technology provides a secure, scalable, cost-effective solution to the connectivity issue. It allows an organization to connect remote sites to a central site securely over the Internet and enables remote users to connect securely to the corporate network using local Internet service providers (ISPs). In these VPN usage scenarios, a physical connection is made using an ISP. The VPN connection appears to remote access users as though they are on a private network. The VPN connection appears as a private link to the routers of the remote site.

The subject of VPNs is extensive enough to warrant a complete book of its own, and therefore is not covered comprehensively in this book. For our purposes, this chapter gives an overview of VPNs and focuses on the two VPN protocols that the Microsoft Windows Server 2003 family implements: Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol with Internet Protocol Security (L2TP/IPSec). These two VPN protocols leverage the Point-to-Point Protocol (PPP) for authentication, compression, initial data encapsulation, and, for PPTP, data encryption.


Overview of VPNs

As Figure 23-1 illustrates, a VPN connection links either a single computer or a network to another network across an intermediate network, typically the Internet.

Figure 23-1. Virtual private networking.

When connecting a remote user using a VPN connection, the remote user first establishes a normal dial-up connection to a local ISP. Users with broadband Internet access or those who are connecting to a VPN server on an organization's network use their local network connection. After this connection is established, the remote user can establish a VPN connection between the remote computer and the organization's VPN server.

Connecting a remote network to the corporate network using a VPN connection is a similar process. In this scenario, the remote office's VPN-enabled router initiates the VPN connection on behalf of clients on the local area network (LAN). The type of connection between the remote router and the ISP is not important, as long as it can carry IP traffic.

VPN Clients and Servers

The computer initiating the VPN connection is referred to as the VPN client. The computer responding to the initiation of the VPN connection is referred to as the VPN server. In the remote access scenario, the remote computer is the VPN client that makes a remote access connection to the VPN server. This remote computer therefore has two active connections established (one to the ISP, the other for the VPN). In the remote office scenario, the remote office's router is the VPN client, which makes a router-to-router (also known as site-to-site) VPN connection to the VPN server. In both scenarios, the VPN server is a server in the organization that acts as the end point for the VPN connection.

Therefore, the following two types of VPN connections can be constructed:

  • The remote access VPN connection A remote access user connects to an organization's intranet.
  • The router-to-router VPN connection A router connects a remote network to an organization's intranet.

VPN Protocols

Connections between a VPN client and a VPN server are implemented through the use of one of two VPN protocols: PPTP or L2TP/IPSec. PPTP is a Layer 2 protocol that encapsulates IP datagrams in PPP frames, which are in turn encapsulated in IP datagrams for transmission over an IP internetwork. PPTP is an older VPN protocol that Microsoft helped develop. L2TP, on the other hand, is a newer Layer 2 protocol based on both Cisco's Layer 2 Forwarding (L2F) protocol and PPTP, which encapsulates IP datagrams in PPP frames to be sent over IP, X.25, frame relay, or ATM.

From an end user point of view, these protocols are functionally equivalent. The key technical differences between PPTP and L2TP are as follows:

  • PPTP requires that the transit network be IP-based. L2TP requires only that the transit network provide packet-level connectivity. L2TP can be used over IP (using UDP) or directly over frame relay, X.25, or ATM. PPTP can traverse these networks also, but additional protocol overhead is required because it must work within IP.
  • PPTP can support only a single tunnel between the VPN client and VPN server. L2TP allows for the use of multiple tunnels between end points. With L2TP, you can create different tunnels for different qualities of service or for different security requirements.
  • L2TP provides header compression. When header compression is enabled, L2TP operates with 4 bytes of overhead, as compared to 6 bytes for PPTP.

Historically, the preferred VPN protocol is PPTP, due to its early inclusion with Windows NT 4.0 and its support in all recent versions of Windows, including Windows Server 2003. However, L2TP/IPSec should become the predominant VPN protocol in the future due to the availability of Microsoft L2TP/IPSec VPN Client—a free download that enables computers running Windows 98, Windows Millennium Edition (Windows Me), and Windows NT Workstation 4.0 to make L2TP/IPSec connections—and the new IPSec Network Address Translator Traversal (NAT-T) support, which allows IPSec negotiations and Encapsulating Security Payload (ESP)-protected traffic to traverse a NAT.

Another method of creating VPN connections is to use IPSec tunnel mode. However, IPSec tunnel mode is not used for remote access connections because there is no standard mechanism for user-level authentication and IP address assignment. IPSec tunnel mode can be used for router-to-router VPN connections. However, an IPSec tunnel is not recognized as a routing interface by the Routing and Remote Access service. In contrast, PPTP and L2TP/IPSec demand-dial interfaces are recognized as a routing interface, by the Routing and Remote Access service. Routes can be assigned to use a PPTP or L2TP/IPSec interface, and routing protocols such as Routing Information Protocol (RIP) and Open Shortest Path First (OSPF) can operate over them. It is possible to create IPSec packet filters that emulate routes, but this is more difficult to configure and route changes must be done manually. Therefore, IPSec tunnel mode for router-to-router VPN connections is only recommended when connecting to a third-party router or security gateway that does not support PPTP or L2TP/IPSec.

Tunneling

Both L2TP and PPTP implement VPNs by means of tunneling, the encapsulation of an IP datagram within another datagram. As Figure 23-2 illustrates, the VPN client encapsulates the original IP datagram sent between two end systems, and sends it to the VPN server, where the datagram is unwrapped and forwarded on the local network.

As Figure 23-2 illustrates, an IP datagram to be sent between the VPN client and a VPN server is encapsulated inside a new IP datagram. This datagram is then sent from the VPN client to the VPN server. The new IP datagram has a header that provides the information necessary to enable the packet to be forwarded properly across the transit network.

Figure 23-2. Tunneling in VPNs.

At the VPN server, the datagram is unwrapped and the original IP datagram can then be forwarded from the VPN server. After the original datagram is unwrapped, the VPN server acts as a router and makes a forwarding decision on the original packet based on the configuration of the VPN server and the entries in the VPN server's routing table.

The VPN tunneling is achieved through the use of a Network Driver Interface Specification (NDIS) driver that becomes an IP client. This is illustrated in Figure 23-3, which shows the architecture of a VPN connection in the remote access scenario.

Figure 23-3. Tunneling architecture.

An application on the remote computer uses either NetBIOS or Windows Sockets to send a datagram to a remote computer. The payload is sent to the TCP/IP component in the Windows Server 2003 family, which creates an IP datagram. At this stage in the process, the source and destination IP addresses are set as if the two systems were communicating directly.

After the IP datagram has been constructed, it is sent to the NDIS miniport for the VPN protocol in use. The miniport driver then encapsulates the original IP datagram with the header for the VPN and sends it back to the TCP/IP driver. The TCP/IP driver then constructs a new IP datagram, which, for PPTP, is sent to the appropriate NDIS driver for the transit network. For L2TP, the packet is intercepted by the IPSec components, which protect the L2TP message with IPSec ESP. For more information about ESP protection, see Chapter 22, "Internet Protocol Security (IPSec)."

VPNs and PPP

Both PPTP and L2TP/IPSec leverage PPP for most of the underlying mechanisms, such as authentication and compression. For PPTP, PPP encryption is also leveraged (for L2TP/IPSec, IPSec provides encryption). In effect, the VPN connection is a PPP connection between the VPN client and VPN server. This allows the original IP datagram to be transmitted inside a PPP frame, which is then encapsulated in an outer IP datagram for transmission across the transit network.

PPTP connections must use Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), MS-CHAP version 2, Extensible Authentication Protocol-Transport Level Security (EAP-TLS) for authentication in order for the PPTP data to be encrypted with Microsoft Point-to-Point Encryption (MPPE). L2TP/IPSec connections can use any type of PPP authentication, but MS-CHAP v2 or EAP-TLS is recommended.

For more information about PPP encapsulation, establishing PPP connections, or PPP authentication protocols, see Chapter 4, "Point-to-Point Protocol (PPP)."

VPN Address Assignment

When the VPN connection has been established, the VPN client appears to be a part of a central network and requires an IP address based on the central network. This means the VPN client typically has two IP addresses: one for the transit network (such as the Internet or local network) and one for the VPN connection.

The Windows Server 2003 Routing and Remote Access service allows the IP addresses to be provided by the user (as part of the configuration of the VPN connection) or to be assigned dynamically as part of setting up the VPN connection. Dynamically assigned addresses can be based on either a static pool of addresses or obtained by the Routing and Remote Access server from a Dynamic Host Configuration Protocol (DHCP) server.

VPN Data Compression

The VPN protocols support a PPP-based compression scheme. For Windows Server 2003, both PPTP and L2TP/IPSec use Microsoft Point-to-Point Compression (MPPC), which is defined in RFC 2118. For Windows Server 2003 VPN clients, the use of MPPC is controlled by settings in the properties of the VPN connection in Network Connections.

MPPC is defined in RFC 2118, which can be found in the \Rfc folder on the companion CD-ROM.

MPPC can reduce the total amount of data being transferred across the transit network by as much as 50 to 60 percent for text data, although for binary data, the compression might only amount to 2 to 3 percent or less. As with all data compression schemes, the percentage by which the original data can be compressed varies with the nature of the data.

VPN Data Encryption

For the data to be transferred securely across an insecure transit network, data encryption is required. PPTP supports the use of MPPE. MPPE is based on the RSA/RC4 encryption algorithm and uses 40-, 56-, or 128-bit encryption keys derived from the authentication process. MPPE relies on the initial key generated during user authentication and typically changes it with each packet.

L2TP/IPSec uses Data Encryption Standard (DES) with a 56-bit key or Triple-DES encryption with three 56-bit keys to protect the data stream from the client to the VPN server. IPSec negotiates a common encryption key during the establishment of the main mode security association (SA), and also refreshes it periodically. For more information about IPSec SAs, see Chapter 22.


PPTP

PPTP is a VPN protocol implemented at Layer 2 in the Open Systems Interconnection (OSI) model. PPTP encapsulates VPN data inside PPP frames, which are then further encapsulated in IP datagrams for transmission over a transit IP internetwork such as the Internet.

PPTP is documented in RFC 2637, which can be found in the \Rfc folder on the companion CD-ROM.

Creation and maintenance of a PPTP tunnel is carried out using a TCP connection. The VPN client uses a dynamically allocated TCP port, and the PPTP server listens on TCP port 1723. Subsequent data is encapsulated using a modified Generic Routing Encapsulation (GRE) header.

PPTP Data Encapsulation

As noted earlier, PPTP encapsulates the original IP datagram when it is transmitted between the PPTP client and PPTP server. Figure 23-4 shows the structure of a PPTP packet.

Figure 23-4. PPTP packet structure.

In Figure 23-4, the original datagram is first formatted as a PPP frame. Using PPP, this part of the datagram can be compressed using MPPC and encrypted using MPPE. The PPP frame is then encapsulated with a GRE header, which then becomes the payload of an IP packet sent between the PPTP client and server. The source and destination IP addresses of this packet correspond to the IP addresses of the PPTP client and PPTP server. On the wire, this datagram will be further encapsulated in a Data Link Layer frame, with the appropriate header and trailer.

The GRE header used to encapsulate the PPP frame is modified for PPTP from its original definition in RFCs 1701 and 1702. The PPTP GRE header includes an Acknowledgment flag and a 32-bit Acknowledgment field, which is used to detect dropped PPTP packets. The PPTP GRE header also replaces the 32-bit Key field with a 16-bit Payload Length field and a 16-bit Call ID field. The Call ID field is used to indicate the PPTP tunnel through which the encapsulated data is traveling. GRE is a client protocol of IP using IP protocol 47.

Network Monitor Capture 23-01 (in the \Captures folder on the companion CD-ROM) provides an example of PPTP encapsulation for an unencrypted ICMP Echo and Echo Reply message.

PPTP Control Connection

The PPTP control connection is a TCP connection between the VPN client and the VPN server that is used for PPTP tunnel management. There are PPTP processes for the following:

  • PPTP control connection creation
  • PPTP control connection maintenance
  • PPTP control connection termination

PPTP control connections are managed by exchanging a series of PPTP messages. Each PPTP message is the payload of a TCP segment and has a different packet structure. For the details of the packet structure of PPTP control messages, see RFC 2637.

PPTP Control Connection Creation

The creation of a PPTP control connection between a Windows Server 2003 PPTP client and a Windows Server 2003 PPTP server consists of the following exchange of messages:

  1. A TCP connection is established from a dynamically allocated port used by the PPTP client to TCP port 1723 on the PPTP server.
  2. The PPTP client sends a PPTP Start-Control-Connection-Request message to establish a PPTP control connection.
  3. The PPTP server responds with a PPTP Start-Control-Connection-Reply message.
  4. The PPTP client sends a PPTP Outgoing-Call-Request message and selects a Call ID to identify the PPTP tunnel for data sent from the PPTP client to the PPTP server.
  5. The PPTP server responds with a PPTP Outgoing-Call-Reply message and selects its own Call ID to identify the PPTP tunnel for data sent from the PPTP server to the PPTP client.
  6. The PPTP client sends a PPTP Set-Link-Info message to indicate PPP-negotiated options.

After the PPTP control connection is established, the separate Call IDs selected by the PPTP client and PPTP server are used in the GRE header for sent data to identify the PPTP tunnel.

Network Monitor Capture 23-02 (in the \Captures folder on the companion CD-ROM) provides an example of the creation of a PPTP control connection and the subsequent PPP negotiation (unencrypted).

PPTP Control Connection Maintenance

PPTP control connections are maintained by the exchange of PPTP Echo-Request and PPTP Echo-Reply messages. Either the PPTP client or the PPTP server can send the initial PPTP Echo-Request message.

Network Monitor Capture 23-03 (in the \Captures folder on the companion CD-ROM) provides an example of PPTP control connection maintenance.

PPTP Control Connection Termination

The termination of a PPTP control connection between a Windows Server 2003 PPTP client and a Windows Server 2003 PPTP server consists of the following exchange of messages:

  1. The Link Control Protocol (LCP) connection between the PPTP client and PPTP server is terminated.
  2. The PPTP server sends a PPTP Clear-Call-Request message indicating that the PPTP control connection is to be terminated.
  3. The PPTP client responds with a PPTP Call-Disconnected-Notify message.
  4. The PPTP server sends a PPTP Stop-Control-Connection-Request message to terminate the PPTP control connection.
  5. The PPTP client responds with a PPTP Stop-Control-Connection-Reply message.
  6. The TCP connection is terminated in the normal way.

This example assumes that the PPTP client terminated the connection.

Network Monitor Capture 23-04 (in the \Captures folder on the companion CD-ROM) provides an example of a PPTP control connection termination.


L2TP/IPSec

L2TP operates, as its name suggests, at Layer 2 in the International Organization for Stand-ardization (ISO) model, and is a network protocol that creates a tunnel between an L2TP client and an L2TP server, and then encapsulates PPP frames to be sent over the tunnel. When using IP as the transport protocol, L2TP can be used as a VPN protocol over the Internet. L2TP was designed so that it can be used directly over various WAN media such as frame relay or X.25 without an IP transport layer. This can extend its usefulness in setting up corporate networks.

L2TP is documented in RFC 2661, which can be found in the \Rfc folder on the companion CD-ROM.

When L2TP is used over IP internetworks, it uses UDP for tunnel creation and maintenance, as well as for data transmission. With L2TP, both the tunneled data and the control messages share a single UDP stream, which can simplify the passing of VPN data through corporate firewalls. L2TP traffic sent by the Windows Server 2003 VPN client and server use UDP port 1701 for both the source and destination UDP ports.

L2TP in Windows Server 2003 and Windows XP relies on IPSec for encryption, and the combination of L2TP and IPSec is known as L2TP/IPSec. Both the VPN client and the VPN server must support both L2TP and IPSec. Before the first L2TP message is sent, a set of IPSec SAs is negotiated between the L2TP client and L2TP server to protect IPSec negotiation and L2TP traffic. By default, L2TP in Windows Server 2003 and Windows XP uses certificates for IPSec peer authentication. However, both Windows Server 2003 and Windows XP can be configured manually to use preshared keys for IPSec peer authentication.

For more information about IPSec, see Chapter 22.

L2TP/IPSec Data Encapsulation

As with PPTP, L2TP encapsulates a PPP frame containing an IP datagram when transferred across the transit network. Because IPSec provides the encryption facilities, L2TP/IPSec encapsulation takes place in two phases. Figure 23-5 illustrates the initial L2TP encapsulation and the IPSec encapsulation.

Figure 23-5. Two phases of encapsulation over L2TP.

As Figure 23-5 illustrates, the L2TP encapsulation involves the original datagram first being wrapped in a PPP frame, as with PPTP. The PPP frame is then inserted into a new IP datagram with a UDP header and an L2TP header. The L2TP client and the L2TP server for Windows Server 2003 and Windows XP both use UDP port 1701. However, the Windows Server 2003 L2TP server supports third-party L2TP clients that use a UDP port other than 1701.

The resulting IP datagram is then passed to the IPSec components, which add an IPSec ESP header and trailer. ESP protection provides data integrity, data origin authentication, data confidentiality (encryption), and replay protection. The outer IP header contains the source and destination IP addresses that correspond to the VPN client and server. Unlike normal IPSec policy, IPSec protection for L2TP traffic is provided by a rule that is automatically created by the remote access client and the Routing and Remote Access service.

Network Monitor Capture 23-05 (in the \Captures folder on the companion CD-ROM) provides an example of L2TP encapsulation for an ICMP Echo and Echo Reply message (without IPSec protection).

L2TP Control Connection

The L2TP control connection is a logical connection between the VPN client and the VPN server that is used to send UDP-encapsulated L2TP messages for L2TP tunnel management. There are L2TP processes for the following:

  • L2TP control connection creation
  • L2TP control connection maintenance
  • L2TP control connection termination

L2TP control connections are managed by exchanging a series of L2TP messages, each of which is the payload of a UDP message. For the details of the packet structure of the L2TP header and L2TP control messages, see RFC 2661.

Because the L2TP messages are sent over UDP, an unreliable protocol, L2TP provides its own sequencing through the use of a Next-Received (Nr) field, which indicates the next message number the sender is expecting to receive, and a Next-Sent (Ns) field, which indicates the message number of the sent message. Because L2TP supports multiple calls, or sessions, per tunnel, the L2TP header uses a Tunnel ID field that indicates the tunnel and a Session ID that indicates the session within the tunnel.

Because both L2TP-encapsulated data and L2TP control messages use an L2TP header, all L2TP control messages are encrypted with IPSec ESP for L2TP/IPSec.

L2TP Connection Creation

The creation of an L2TP control connection between a Windows Server 2003 L2TP client and a Windows Server 2003 L2TP server consists of the following exchange of messages:

  1. The L2TP client sends an L2TP Start-Control-Connection-Request message to establish an L2TP control connection.
  2. The L2TP server responds with an L2TP Start-Control-Connection-Reply message.
  3. The L2TP client sends an L2TP Start-Control-Connection-Connected message.
  4. The L2TP server responds with an L2TP Incoming-Call-Request message.
  5. The L2TP client sends an L2TP Incoming-Call-Connected message to indicate PPP-negotiated options.

After the L2TP control connection is established, the Tunnel ID and Session ID selected by the L2TP server in the L2TP Start-Control-Connection-Reply message is used in the L2TP header for encapsulated data to identify the L2TP session and tunnel.

Network Monitor Capture 23-06 (in the \Captures folder on the companion CD-ROM) provides an example of an L2TP connection creation (without IPSec protection).

L2TP Connection Maintenance

L2TP control connections are maintained by the sending of an L2TP Hello message by either the L2TP client or the L2TP server. The recipient of the L2TP Hello message sends an L2TP acknowledgment with an incremented Nr field.

Network Monitor Capture 23-07 (in the \Captures folder on the companion CD-ROM) provides an example of L2TP connection maintenance (without IPSec protection).

L2TP Connection Termination

The termination of an L2TP control connection between a Windows Server 2003 L2TP client and a Windows Server 2003 L2TP server consists of the following exchange of messages:

  1. The LCP connection between the L2TP client and L2TP server is terminated.
  2. The L2TP client responds with an L2TP Call-Disconnected-Notify message, which contains the Tunnel ID, which identifies the L2TP tunnel, and the Session ID, which identifies the session within the L2TP tunnel.
  3. The L2TP server acknowledges the receipt of the L2TP Call-Disconnected-Notify message, which includes an incremented Nr field.
  4. The L2TP client sends a PPTP Stop-Control-Connection-Notification message to terminate the L2TP control connection.
  5. The L2TP server acknowledges the receipt of the L2TP Stop-Control-Connection-Notification message, which includes an incremented Nr field.

This example assumes that the VPN client terminated the L2TP connection.

Network Monitor Capture 23-08 (in the \Captures folder on the companion CD-ROM) provides an example of an L2TP connection termination (without IPSec protection).


Summary

VPNs provide a good method of linking remote users or remote offices to corporate networks in a secure and scalable way. For remote access VPN connections, the Windows Server 2003 family supports PPTP and L2TP/IPSec. For router-to-router VPN connections, the Windows Server 2003 family supports PPTP, L2TP/IPSec, and IPSec tunneling. This wide range enables interoperability with RFC-compliant third-party solutions.


Glossary

A

Address Resolution Protocol (ARP) A protocol for resolving Internet Protocol (IP) addresses into media access control (MAC) addresses. See also inverse ARP (INARP) and reverse ARP (RARP)

AH See Authentication Header (AH)

APIPA See Automatic Private IP Addressing (APIPA)

ARP See Address Resolution Protocol (ARP)

ARP cache A table for each interface of static or dynamically resolved Internet Protocol (IP) addresses and their corresponding media access control (MAC) addresses.

Asynchronous Transfer Mode (ATM) A very high speed, connection-oriented networking technology, based on small 53-byte cells.

Authentication Header (AH) An IP Security (IPSec) header that provides data origin authentication, data integrity, and replay protection for the entire IP datagram, excluding fields in the IP header that are allowed to change in transit.

ATM See Asynchronous Transfer Mode (ATM)

Automatic Private IP Addressing (APIPA) A feature of Windows 2000, Windows 98, Windows Millennium Edition (Windows Me), Windows XP, and Windows Server 2003 that enables the system to self-configure an IP address and subnet mask from the range 169.254.0.0/16 when the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol is configured for automatic configuration and there is no DHCP server.

B

Bandwidth Allocation Protocol (BAP) A protocol that dynamically controls the use of multilinked lines, adding extra connections when additional bandwidth is required and dropping lines when it is not required.

BAP See Bandwidth Allocation Protocol (BAP)

Berkeley Internet Name Domain (BIND) A version of the Domain Name System (DNS) service, written initially for UNIX and ported to a wide variety of operating systems.

BIND See Berkeley Internet Name Domain (BIND)

C

CIDR See Classless Interdomain Routing (CIDR)

CIFS See Common Internet File System (CIFS)

Cipher block chaining (CBC) See initialization vector (IV)

Classless Interdomain Routing (CIDR) A route aggregation and address assignment technique that expresses routes and network IDs in the form of a prefix and prefix length, rather than in terms of the original Internet address classes.

Common Internet File System (CIFS) A cross-platform file sharing protocol that allows clients to request file and print services from a network server based on the widely used Server Message Block (SMB) protocol.

Compressed SLIP (C-SLIP) A simple compression scheme used to compress Internet Protocol (IP) and Transmission Control Protocol (TCP) headers to a 3- to 5-byte header on a Serial Line Internet Protocol (SLIP) link.

congestion avoidance A Transmission Control Protocol (TCP) algorithm that provides a linear scaling of the actual send window. The actual send window is increased by one Maximum Segment Size (MSS) for each full window of data that is acknowledged.

C-SLIP See Compressed SLIP (C-SLIP)

D

DHCP See Dynamic Host Configuration Protocol (DHCP)

DHCP Server A Windows Server 2003 service that provides Dynamic Host Configuration Protocol (DHCP)-based Internet Protocol (IP) addresses and configuration parameters to DHCP clients.

Diffie-Hellman Algorithm An algorithm for determining a shared secret key by exchanging two numerical values across an insecure medium, and a component of the Oakley key determination protocol.

Digital, Intel, and Xerox (DIX) A consortium that created the original 10-Mbps version of Ethernet (also known as DIX Ethernet).

DIX See Digital, Intel, and Xerox (DIX)

DNS See Domain Name System (DNS)

Domain Name System (DNS) A set of services for storing, updating, and resolving computer names and associated Internet Protocol (IP) addresses for computers and other resources on the Internet or on private Transmission Control Protocol/Internet Protocol (TCP/IP) networks.

Dynamic Host Configuration Protocol (DHCP) A protocol for providing computers with Internet Protocol (IP) addresses and other host configuration parameters. Also used to ensure DHCP servers are authorized.

E

Encapsulating Security Payload (ESP) An IP Security (IPSec) header and trailer combination that provides data origin authentication, data integrity, replay protection, and data confidentiality for the ESP-encapsulated portion of the packet.

ESP See Encapsulating Security Payload (ESP)

F

Fast Recovery A Transmission Control Protocol (TCP) algorithm that more quickly scales the TCP send window when a segment is retransmitted using Fast Retransmit.

Fast Retransmit A Transmission Control Protocol (TCP) algorithm that retransmits a segment before the retransmission time-out expires when multiple duplicate acknowledgments of the previously received contiguous segment are received.

FCS See Frame Check Sequence (FCS)

FDDI See Fiber Distributed Data Interface (FDDI)

Fiber Distributed Data Interface (FDDI) An optical fiber-based token passing ring local area network (LAN) technology with a bit rate of 100 megabits per second (Mbps).

File Transfer Protocol (FTP) A protocol for transferring files between heterogeneous servers and clients. Internet Explorer supports FTP. In addition, Windows Server 2003 includes a command-line FTP client and an FTP server as part of Internet Information Services (IIS).

Frame Check Sequence (FCS) A field in Network Interface Layer protocols, such as Ethernet and Point-to-Point Protocol (PPP), which is used to provide bit-level integrity services for a single frame.

frame relay A virtual circuit-based wide area network (WAN) technology designed for the transmission of data. Frame relay is a streamlined version of X.25.

FTP See File Transfer Protocol (FTP)

G

gateway A Transmission Control Protocol/Internet Protocol (TCP/IP) node that has routing capability. See also router

Gratuitous ARP An Address Resolution Protocol (ARP) Request message sent to a host's own Internet Protocol (IP) address. Gratuitous ARPs are used to check for duplicate IP addresses.

H

hash A one-way cryptographic algorithm that takes an input message of arbitrary length and produces a fixed-length digest. Two hash algorithms used by Windows Server 2003 are Secure Hash Algorithm 1 (SHA1) and Message Digest 5 (MD5).

host A Transmission Control Protocol/Internet Protocol (TCP/IP) node that does not have routing capability.

host group The set of nodes listening for Internet Protocol (IP) multicast traffic on a specific IP multicast address.

HTTP See Hypertext Transfer Protocol (HTTP)

Hypertext Transfer Protocol (HTTP) An application protocol for transferring text, graphics, and other data between an HTTP client and server. Windows Server 2003 includes an HTTP client, Internet Explorer, and an HTTP server as part of Internet Information Services (IIS).

I

IAS See Internet Authentication Service (IAS)

ICMP See Internet Control Message Protocol (ICMP)

IETF See Internet Engineering Task Force (IETF)

IGMP See Internet Group Management Protocol (IGMP)

IIS See Internet Information Services (IIS)

IKE See Internet Key Exchange (IKE)

INARP See inverse ARP (INARP)

initialization vector (IV) A number used to ensure that the same blocks of original plaintext result in different blocks of cipher-text when they are decrypted. This is a block encryption technique known as cipher block chaining (CBC).

Integrated Services Digital Network (ISDN) A method of carrying digital transmissions over traditional telephone copper wire to provide higher speed dial-up connections and other digital services.

Internet Authentication Service (IAS) The Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) server and proxy in Windows Server 2003.

Internet Control Message Protocol (ICMP) A protocol that works with Internet Protocol (IP) to report errors, provide diagnostics functions, and control the flow of data.

Internet Engineering Task Force (IETF) This is the body that defines the Internet Protocol (IP) and oversees the development of the Internet and the evolution of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. The standards developed by the IETF and IETF working parties are published as RFCs.

Internet Group Management Protocol (IGMP) A protocol for managing multicast group membership on a subnet.

Internet Information Services (IIS) A set of Windows Server 2003 services that provide Web, file transfer, newsgroup, and mail facilities. IIS also implements certain kernel mode drivers to improve the performance of Hypertext Transfer Protocol (HTTP). This product was named Internet Information Server prior to IIS version 5.

Internet Key Exchange (IKE) A standard method of negotiating security associations (SAs) used by Internet Protocol Security (IPSec), based on the Internet Security Association and Key Management Protocol (ISAKMP) and the Oakley key determination protocol.

Internet Protocol (IP) An unreliable, datagram delivery service that operates at the Internet Layer (the Network Layer of the OSI model).

Internet Security Association and Key Management Protocol (ISAKMP) A framework for managing keys within Internet Protocol Security (IPSec).

inverse ARP (INARP) Obtains a remote system's Internet Protocol (IP) address, based on its Network Interface Layer address. Used mainly in Frame Relay. See also Address Resolution Protocol (ARP) and reverse ARP (RARP)

IP See Internet Protocol (IP)

IPSec See IP Security (IPSec)

IP Security (IPSec) A suite of protocols and services that provide data origin authentication, data integrity, data confidentiality, and replay protection for Internet Protocol (IP) datagrams.

ISAKMP See Internet Security Association and Key Management Protocol (ISAKMP)

ISDN See Integrated Services Digital Network (ISDN)

IV See initialization vector (IV)

L

LAN See local area network (LAN)

LDAP See Lightweight Directory Access Protocol (LDAP)

Lightweight Directory Access Protocol (LDAP) A protocol for communication with a directory service. Windows Server 2003 Active Directory makes heavy use of LDAP.

link state advertisement (LSA) A packet sent by an Open Shortest Path First (OSPF) router to other OSPF routers to indicate the state of a router.

LLC See Logical Link Control (LLC)

local area network (LAN) A network of interconnected computers within a relatively small geographic area that does not use links provided by third-party telecommunications providers.

Logical Link Control (LLC) A sublayer of the OSI Data Link Layer, as defined by the Institute of Electrical and Electronics Engineers (IEEE).

LSA See link state advertisement (LSA)

M

MAC See Media Access Control (MAC)

MAC address The 48-bit address assigned to a network adapter. Also known as a physical address, an Ethernet address, a hardware address, or an IEEE 802 address.

main mode The portion of the Internet Protocol Security (IPSec) negotiation that creates the Internet Security Association and Key Management Protocol (ISAKMP) security association (SA). The ISAKMP SA is used to protect future main mode and quick mode IPSec negotiations.

Maximum Receive Unit (MRU) The maximum size of a Point-to-Point Protocol (PPP) frame.

Maximum Segment Size (MSS) The maximum size of a Transmission Control Protocol (TCP) segment.

Maximum Transmission Unit (MTU) The largest frame that can be sent in a packet- or frame-based network (for example, 1526 bytes for Ethernet).

Media Access Control (MAC) A sublayer of the OSI Data Link Layer, as defined by the Institute of Electrical and Electronics Engineers (IEEE). See also MAC address

MRU See Maximum Receive Unit (MRU)

MSS See Maximum Segment Size (MSS)

MTU See Maximum Transmission Unit (MTU)

N

NBMA See non-broadcast multiple access (NBMA)

NCP See Network Control Protocol (NCP)

NetBIOS A network interface for applications and a set of network protocols providing name services, session services, and datagram services for NetBIOS applications.

NetBIOS over TCP/IP (NetBT) The NetBIOS name, session, and datagram services operating over the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite.

NetBT See NetBIOS over TCP/IP (NetBT)

Network Control Protocol (NCP) A protocol for configuring a Network Layer protocol over a point-to-point connection. An example of an NCP is Internet Protocol Control Protocol (IPCP), which is used to configure an IP address and other settings during the establishment of an IP-based Point-to-Point Protocol (PPP) connection.

Network News Transfer Protocol (NNTP) A protocol used by computers for managing the articles posted on network news news-groups. Windows Server 2003 includes an NNTP client (Outlook Express) and an NNTP server (as part of Internet Information Services [IIS]).

NNTP See Network News Transfer Protocol (NNTP)

node A network device running the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol.

non-broadcast multiple access (NBMA) A Network Interface Layer technology that supports an Internet Protocol (IP) network segment with more than two nodes, but with no facility to broadcast a single packet to multiple locations. For example, X.25, Frame Relay, and Asynchronous Transfer Mode (ATM) are NBMA network types.

O

Oakley A protocol used by Internet Protocol Security (IPSec) for exchanging keys securely, using the Diffie-Hellman algorithm.

Open Shortest Path First (OSPF) A link state-based routing protocol for use within a single autonomous system.

OSPF See Open Shortest Path First (OSPF)

P

Packet InterNet Groper (PING) A troubleshooting utility that uses Internet Control Message Protocol (ICMP) Echo messages to provide information about reachability to a destination node.

Path MTU Discovery (PMTU) A method of dynamically discovering the highest Internet Protocol Maximum Transmission Unit (IP MTU) for all links between two hosts.

PDU See protocol data unit (PDU)

permanent virtual circuit (PVC) A path through a virtual circuit packet-switching network (for example, X.25) that is statically programmed into the switches of the network.

PING See Packet InterNet Groper (PING)

PMTU See Path MTU Discovery (PMTU)

Point-to-Point Protocol (PPP) A standard set of protocols that provide a Data Link Layer encapsulation method that supports multiple protocols simultaneously on the same link; a protocol for negotiating the Data Link Layer characteristics of the point-to-point connection called the Link Control Protocol (LCP); and a series of protocols for negotiating the Network Layer properties of Network Layer protocols over the point-to-point connection named Network Control Protocols (NCPs).

Point-to-Point Protocol over Ethernet (PPPoE) A standard method of encapsulating PPP frames so that they can be sent over an Ethernet network.

POP See Post Office Protocol (POP)

Post Office Protocol (POP) A protocol for retrieving e-mail from a mail server. The latest version of this protocol is known as POP3. Windows Server 2003 includes Outlook Express (a POP3 client) and a POP3 server.

PPP See Point-to-Point Protocol (PPP)

PPPoE See Point-to-Point Protocol over Ethernet (PPPoE)

protocol data unit (PDU) The unit of information that exists at any layer of a layered network architecture. The protocol data unit of layer n becomes the payload of layer n-1 (a lower layer).

PVC See permanent virtual circuit (PVC)

Q

quick mode The portion of the Internet Protocol Security (IPSec) negotiation that creates the two IPSec security associations (SAs), one for inbound traffic and one for outbound traffic. The IPSec SAs are used to protect data sent between the two IPSec peers.

R

RADIUS See Remote Authentication Dial-In User Service (RADIUS)

RARP See reverse ARP (RARP)

Remote Authentication Dial-In User Service (RADIUS) A standard protocol that is used to provide authentication, authorization, and accounting services for network access servers (NAS) or any other similar device that needs to authenticate, authorize, and account for the usage of the device. RADIUS clients (NASs) send RADIUS requests to RADIUS servers. A RADIUS proxy can be used to route RADIUS messages between RADIUS clients and RADIUS servers.

reverse ARP (RARP) Obtains an Internet Protocol (IP) address of a host from an RARP server, based on a Media Access Control (MAC) address. See also Address Resolution Protocol (ARP) and inverse ARP (INARP)

Request for Comments (RFC) A formal document or standard, developed by an individual, the Internet Engineering Task Force (IETF), or an IETF working group that defines some part of the Internet Protocol (IP) suite. Some RFCs are informational in nature and others are Internet standards. RFCs are never reissued, but they are superceded by new RFCs.

RFC See Request for Comments (RFC)

RIP See Routing Information Protocol (RIP)

router A Transmission Control Protocol/Internet Protocol (TCP/IP) node that has routing capability (also called a gateway).

Routing Information Protocol (RIP) A distance vector-based routing protocol used in small and medium-sized internetworks.

S

SA See security association (SA)

security association (SA) The combination of security services, protection mechanisms, and cryptographic keys mutually agreed to by communicating peers. The SA contains the information needed to determine how the traffic is to be secured (the security services and protection mechanisms) and with what secret keys (cryptographic keys).

Serial Line Internet Protocol (SLIP) A simple packet-framing protocol for use on point-to-point links that offers only frame delimitation services.

Simple Mail Transfer Protocol (SMTP) A protocol for exchanging mail, typically between mail servers. Internet Information Services (IIS) includes a limited-function SMTP server.

SLIP See Serial Line Internet Protocol (SLIP)

slow start A Transmission Control Protocol (TCP) algorithm that provides a quick scaling of the actual send window. The actual send window is increased by one Maximum Segment Size (MSS) for each acknowledgment segment that is received.

SMTP See Simple Mail Transfer Protocol (SMTP)

SONET See Synchronous Optical Network (SONET)

SVC See switched virtual circuit (SVC)

switched virtual circuit (SVC) A path through a virtual circuit packet-switching network (for example, X.25) that is negotiated using a signaling protocol each time a connection is initiated.

Synchronous Optical Network (SONET) An American National Standards Institute (ANSI) standard specification for synchronous data transmission on optical media. SONET provides standards for a number of line rates.

T

TCP See Transmission Control Protocol (TCP)

TCP/IP See Transmission Control Protocol/Internet Protocol (TCP/IP)

TDI See Transport Driver Interface (TDI)

Time-To-Live (TTL) A field in the Internet Protocol (IP) header of an IP datagram that is used to determine how many links on which the datagram can travel before being discarded by an IP router.

Transmission Control Protocol (TCP) A reliable, stream-based, full-duplex Transport Layer protocol that runs on top of the Internet Protocol (IP).

Transmission Control Protocol/Internet Protocol (TCP/IP) An industry-standard suite of protocols designed for large internet-works. TCP/IP is the foundation of today's Internet, as well as the foundation of many private computer networks. TCP/IP includes TCP, IP, and many other protocols, such as Internet Control Message Protocol (ICMP) and User Datagram Protocol (UDP).

Transport Driver Interface (TDI) A layer of the Windows Server 2003 network architecture that exists between kernel mode networking components (such as application programming interface [API] components) and protocol drivers (such as Transmission Control Protocol/Internet Protocol [TCP/IP]).

TTL See Time-To-Live (TTL)

U

UDP See User Datagram Protocol (UDP)

User Datagram Protocol (UDP) An unreliable, datagram-based Transport Layer protocol that runs on top of the Internet Protocol (IP). UDP provides Application Layer process identification and a checksum.

V

Variable Length Subnet Masks (VLSM) A technique of subnetting that produces subnets of different sizes, all derived from an original network ID.

VLSM See Variable Length Subnet Masks (VLSM)

W

WAN See wide area network (WAN)

wide area network (WAN) A geographically dispersed network, under private control, but which typically uses network connections from third-party telecommunications vendors. See also local area network (LAN)

Windows Internet Name Service (WINS) The Microsoft implementation of a NetBIOS name server (NBNS), which is used by NetBIOS over TCP/IP (NetBT) hosts to register NetBIOS names to Internet Protocol (IP) address mappings and to resolve NetBIOS names to IP addresses. WINS also refers to the name of the NBNS service in Windows Server 2003.

Windows Sockets (Winsock) A commonly used application programming interface (API) that Windows applications utilize to transfer data using Transmission Control Protocol/Internet Protocol (TCP/IP).

WINS See Windows Internet Name Service (WINS)

Winsock See Windows Sockets (Winsock)

World Wide Web (WWW) Refers to resources available on the Internet and accessed by the Hypertext Transfer Protocol (HTTP).

WWW See World Wide Web (WWW)

X

X.25 A wide area network (WAN) technology based on virtual circuit-based packet switching. X.25 was designed in the 1970s and provides a reliable, connection-oriented Network Interface Layer.


Bibliography

This bibliography provides a list of additional resources that might be helpful to readers. Some of the books, particularly those listed under the "TCP/IP" heading, cover more than one topic. To avoid duplication, these books are not listed twice.

All these books were available for sale at the time this bibliography was written; however, some books might be out of print, or might have been updated by new versions.

The books are listed by topic; within each topic, they are listed alphabetically by author.

DHCP

Alcott, Neall. DHCP for Windows 2000. Sebastopol, Calif.: O'Reilly & Associates, 2000. ISBN 1565928385.

Droms, Ralph, and Ted Lemon. The DHCP Handbook. 2d ed. Indianapolis: Sams, 2002. ISBN 0672323273.

DNS

Abell, Roger, Herman Knief, Andrew Daniels, and Jeffrey Graham. Windows 2000 DNS. Indianapolis: New Riders, 2000. ISBN 0735709734.

Albitz, Paul, and Cricket Liu. DNS and BIND. 4th ed. Sebastopol, Calif.: O'Reilly & Associates, 2001. ISBN 0596001584.

Larson, Matt, Cricket Liu, and Paul Albitz. DNS on Windows 2000. 2d ed. Sebastopol, Calif.: O'Reilly & Associates, 2001. ISBN 0596002300.

Liu, Cricket. DNS and BIND Cookbook. Sebastopol, Calif.: O'Reilly & Associates, 2002. ISBN 0596004109.

General Networking Concepts and Technologies

Microsoft Corporation. MCSE Training Kit: Networking Essentials Plus, Third Edition. Redmond, Wash.: Microsoft Press, 1999. ISBN 157231902X.

IP Security

Doraswamy, Naganand, and Dan Harkins. IPSec: The New Security Standard for the Internet, Intranets, and Virtual Private Networks. Upper Saddle River, N.J.: Prentice Hall PTR, 2000. ISBN 0130118982.

Network Security

Adams, Carlisle, and Steve Lloyd. Understanding PKI: Concepts, Standards, and Deployment Considerations. 2d ed. Indianapolis: Addison-Wesley Professional, 2002. ISBN 0672323915.

Black, Uyless D. Internet Security Protocols: Protecting IP Traffic. Upper Saddle River, N.J.: Prentice Hall PTR, 2001. ISBN 0130142492.

Burnett, Steve, and Stephen Paine. RSA Security's Official Guide to Cryptography. Berkeley, Calif.: Osborne/McGraw Hill, 2001. ISBN 007213139X.

Kaufman, Charles, Radia Perlman, and Mike Speciner. Network Security: Private Communication in a Public World. 2d ed. Upper Saddle River, N.J.: Prentice Hall PTR, 2002. ISBN 0130460192.

Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C. 2d ed. New York: John Wiley & Sons, 1995. ISBN 0471117099.

Stallings, William. Cryptography and Network Security: Principles and Practice. 3d ed. Upper Saddle River, N.J.: Prentice Hall PTR, 2003. ISBN 0130914290.

IP Version 6

Davies, Joseph Understanding IPv6. Redmond, Wash: Microsoft Press, 2003. ISBN 0735612455.

Hagen, Silvia. IPv6 Essentials. Sebastopol, Calif.: O'Reilly & Associates, 2002. ISBN 0596001258.

Huitema, Christian. IPv6: The New Internet Protocol. Upper Saddle River, N.J.: Prentice Hall PTR, 1998. ISBN 0138505055.

Miller, Mark A. Implementing IPv6: Supporting the Next Generation Internet Protocols. 2d ed. Foster City, Calif.: John Wiley & Sons, 1999. ISBN 0764545892.

L2TP

Black, Uyless D. PPP and L2TP: Remote Access Communications. Upper Saddle River, N.J.: Prentice Hall PTR, 2000. ISBN 0130224626.

Shea, Richard. L2TP: Implementation and Operation. New York: Addison-Wesley, 1999. ISBN 0201604485.

Microsoft Windows 2000

Solomon, David A., and Mark Russinovich. Inside Microsoft Windows 2000. 3d ed. Redmond, Wash: Microsoft Press, 2000. ISBN 0735610215.

PPP

Carlson, James D. PPP Design, Implementation, and Debugging. 2d ed. Indianapolis: Addison-Wesley Professional, 2000. ISBN 0201700530.

Sun, Andrew. Using and Managing PPP. Sebastopol, Calif.: O'Reilly & Associates, 1999. ISBN 1565923219.

RADIUS

Hassell, Jonathan. RADIUS. Sebastopol, Calif.: O'Reilly & Associates, 2002. ISBN 0596003226.

Routing

Charles, Kackie. Windows 2000 Routing and Remote Access Service. Indianapolis: New Riders, 2000. ISBN 0735709513.

Huitema, Christian. Routing in the Internet. 2d ed. Upper Saddle River, N.J.: Prentice Hall PTR, 2000. ISBN 0130226475.

Microsoft Corporation. Microsoft Windows 2000 Server Internetworking Guide. Redmond, Wash: Microsoft Press, 2002. ISBN 073561797X.

Perlman, Radia. Interconnections: Bridges, Routers, Switches, and Internetworking Protocols. 2d ed. Reading, Mass.: Addison-Wesley, 1999. ISBN 0201634481.

TCP/IP

Burk, Robin, Martin J. Bligh, and Thomas Lee. TCP/IP Blueprints. Indianapolis: Sams, 1997. ISBN 0672310554.

Comer, Douglas. Internetworking with TCP/IP: Vol. 1, Principles, Protocols, and Architecture. 4th ed. New York: Prentice Hall, 2000. ISBN 0130183806.

Houde, Dave, and Tim Hoffman. TCP/IP for Windows 2000. Upper Saddle River, N.J.: Prentice Hall PTR, 2001. ISBN 0130281603.

McLean, Ian. Windows 2000 TCP/IP Black Book: An Essential Guide to Enhanced TCP/IP in Microsoft Windows 2000. Phoenix: Paraglyph Press, 2002. ISBN 1932111417.

Microsoft Corporation. Microsoft Windows 2000 Server TCP/IP Core Networking Guide. Redmond, Wash: Microsoft Press, 2002. ISBN 0735617988.

Powell, Keith A. Microsoft TCP/IP for Windows 2000. Cincinnati: Premier Press, 2000. ISBN 0761529373.

Siyan, Karanjit S. Windows 2000 TCP/IP. Indianapolis: New Riders, 2000. ISBN 0735709920.

Stevens, W. Richard. TCP/IP Illustrated. Volume 1: The Protocols. Reading, Mass.: Addison-Wesley, 1993. ISBN 0201633469.

Virtual Private Networks

Fortenberry, Thaddeus. Windows 2000 Virtual Private Networking. Indianapolis: New Riders, 2000. ISBN 1578702461.

Kosiur, Dave. Building & Managing Virtual Private Networks. New York: John Wiley and Sons, 1998. ISBN 0471295264.


About the Authors

Joseph Davies is a Program Manager for Content Development on the Networking and Communications team in the Windows product group of Microsoft Corporation. He has been a technical writer about and instructor of TCP/IP and networking technology topics for 10 years. He has written Windows product documentation and Resource Kit chapters about TCP/IP, routing, remote access, virtual private networking, Internet Authentication Service, IPSec, and IPv6. Most recently, he has written many white papers about IEEE 802.11 wireless deployment, IPv6, and Windows XP home networking. He is the author of the online monthly TechNet Cable Guy column (http://www.microsoft.com/technet). In addition, he is co-author of Microsoft Windows 2000 TCP/IP Protocols and Services Technical Reference and author of Understanding IPv6, both published by Microsoft Press.

Thomas Lee is a Chief Technologist at QA, a leading provider of IT and personal development training in the United Kingdom. After graduating with a BS in Computer Problem Solving from Carnegie Mellon University, he worked on two successful operating system projects (Comshare's Commander II and ICL's VME) before joining Andersen Consulting in 1981 as a manager in the London office. He spent 15 years as an independent consultant and joined QA in 2002. He is also Windows Editor for ESM Magazine. He is a Fellow of the British Computer Society as well as a Microsoft Certified Systems Engineer (MCSE), Microsoft Certified Trainer (MCT), and Microsoft Valued Professional (MVP). Thomas lives in a cottage in the English countryside with his wife Susan and daughter Rebecca.


About This eBook

This eBook has been converted from the print version of this title. Every effort has been made to ensure the accuracy of this conversion. For readability and accessibility reasons, the eBook version may contain differences in formatting from the original print version. The content of the eBook is not updated to reflect any content changes made for reprint releases.

Figures and Images

The figures and screen shots throughout the book are converted to electronic format as 1:1 images. The eBook uses Microsoft Internet Explorer to shrink the images down to fit within the content pane. To see the larger 1:1 image, simply click on the image. The 1:1 image will open in a separate window. If you click on more than one image to view the 1:1 image, each image will open in a separate window, and remain open until that window is closed.

Search

The .CHM format allows full-text searching to better locate the information you need. To conduct a search, open the eBook and click the Search tab. In the Search Topics text box, type the word or topic on which you wish to search. Click List Topics to display the search results. To view a search result, either a) double-click on the result in the Select Topic list, or b) click on the result in the Select Topic list, and click Display. The topic will then display in the content pane. Search results are ranked by the number of times the words searched on occur within the topic results. The highest-ranked topic will include the most references to the search criteria.

For advanced search options, open the drop-down list next to the search input box to clarify multiple search terms with the parameters AND, OR, NEAR, or NOT.

Favorites

To save a topic for viewing later, select the topic so that it displays in the content pane. Select the Favorites tab. The topic title, or heading, will appear in the Current Topic box. Click Add and the topic title will appear in the Topics pane. To view a topic saved in Favorites, select the title, and click Display. To remove a Favorite topic at any time, select it from the topic pane, and click Remove.

External Links

This eBook may contain links to Web sites outside of the Microsoft domain. All hyperlinks within the text were valid at the time this eBook was published. Due to the nature of the World Wide Web, we cannot guarantee that all links to Web sites are still valid after the release date of the eBook.

Accessibility

This eBook utilizes Internet Explorer to display content. Internet Explorer offers many accessibility features, such as keyboard shortcuts and compatibility with Assistive Technology. To find out more about accessibility within Internet Explorer, go to www.microsoft.com/enable/products and select the version of Internet Explorer installed on your computer.

Tell Us What You Think

We need to hear from you regarding your experience with our eBooks. Tell us what you like, don't like; which features you use, and which features you would like to see in future versions of our eBooks. Send your comments to epublish@microsoft.com. Please note that technical support is not offered through this alias.

About Microsoft Press

Microsoft Press is a division of Microsoft Corporation and the leading source of comprehensive self-paced learning, training, evaluation, and support resources to help everyone from developers to IT professionals to end users get the most from Microsoft technology. Choose from hundreds of current titles in print, multimedia, and network-ready formats—learning solutions made by Microsoft, with the most timely and accurate information available. For more information, visit www.microsoft.com/mspress.


Application Layer Protocols and Services

Part IV
Application Layer Protocols and Services