Microsoft Windows 2000 TCP/IP Protocols and Services: Technical Reference with CD-ROM


IT professionals get the technical drill-down they need to deploy and support TCP/IP protocols and services in the Windows 2000 environment. This authoritative Technical Reference explores TCP/IP protocols layer by layer in the OSI model — offering timely and in-depth information specific to Windows 2000-based network administration. It offers practical coverage for handling daily connectivity issues, and spans the more arcane topics necessary to ensure solid performance and reliability on Windows 2000-based wide...

See more details below
Available through our Marketplace sellers.
Other sellers (Paperback)
  • All (14) from $1.99   
  • New (2) from $11.88   
  • Used (12) from $1.99   
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any coupons and promotions
Seller since 2008

Feedback rating:



New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.


Ships from: fallbrook, CA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Seller since 2014

Feedback rating:


Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Sort by
Sending request ...


IT professionals get the technical drill-down they need to deploy and support TCP/IP protocols and services in the Windows 2000 environment. This authoritative Technical Reference explores TCP/IP protocols layer by layer in the OSI model — offering timely and in-depth information specific to Windows 2000-based network administration. It offers practical coverage for handling daily connectivity issues, and spans the more arcane topics necessary to ensure solid performance and reliability on Windows 2000-based wide area networks, even for large organizations.

Read More Show Less

Product Details

  • ISBN-13: 9780735605565
  • Publisher: Microsoft Press
  • Publication date: 2/5/2000
  • Series: Microsoft Technical Reference Series
  • Edition description: BK&CD-ROM
  • Pages: 800
  • Product dimensions: 7.61 (w) x 9.55 (h) x 1.71 (d)

Meet the Author

Joseph G. Davies is a Microsoft employee and technical writing lead for the Microsoftr Windows 2000 Server Resource Kit. He has been a technical writer and instructor of TCP/IP and networking technology topics for six years and has written a large amount of training material for both internal Microsoft training organizations and for a series of courses for a local community college. As a Microsoft instructor and course designer, he has written introductory and advanced courses on TCP/IP and a course on the Windows NT 4.0 Routing and Remote Access Service. More recently, he wrote the Windows 2000 product documentation and Resource Kit content for TCP/IP, routing, remote access, and virtual private networks. He has a Bachelor's degree in Engineering Physics and is a Microsoft Certified Systems Engineer (MCSE), Microsoft Certified Trainer (MCT) and Master Certified NetWare Engineer (MCNE).

Thomas Lee is an independent computer consultant who has been working with Windows NT since 1993. 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 where he was a manager in the London office. He has been an independent consultant since 1987. Most recently, he has worked in Redmond developing Windows 2000 Microsoft Official Curriculum (MOC) training material and is presently engaged in several consulting projects relating to Windows 2000. Thomas 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.

Read More Show Less

Read an Excerpt

Chapter 9: Internet Protocol Version 6 (IPv6)

Over the course of theevolution of the current IP version, version 4 (IPv4), the inevitable exhaustion of the address space has become increasingly apparent. While mechanisms such as Classless Inter-Domain Routing (CIDR) and the use of proxies have served to increase the longevity of IPv4, development of a larger, more flexible version of IP, version 6 (IPv6), is well underway.

In its original inception, the Internet (then ARPANET) was designed primarily to facilitate communication between research entities and military organizations. However, the extraordinary longevity and functionality of the TCP/IP protocol suite has allowed the Internet to become a communications mechanism of an enormity that couldn't have been foreseen in its early stages.

Now there are even newer arenas that require the addressing and routing capabilities that IP provides. Cellular phones, pagers, and personal digital assistants (PDAs) have become ubiquitous accessories whose nature dictates that mechanisms be available for secure, portable communication. Entertainment media such as digital television and real-time audio require similar connectivity, with the imperative of guaranteed delivery rates. Additionally, the still largely untapped area of power and device management will demand the same capabilities. The once fantastic "home of the future," with electronically controlled temperature, lighting, and gadgetry is fast approaching reality.

If these markets are to utilize IP rather than be forced into developing proprietary solutions, mechanisms will be required that aren't easily provided in IPv4. Rather than investigate methods to extend an already strapped address space with limited future potential, research has been heavily dedicated to devising a new version of IP--IPv6. To successfully meet current and future needs, the following are several key capabilities that must be addressed by this new IP version:

  • First and foremost, any new IP version must be capable of coexistence and interoperability with current IP specifications. Attempts to make a sweeping conversion from one version to the next would be both unrealistic and chaotic. Therefore, IPv6 must have inherent mechanisms for communicating with both IPv4 and IPv6 hosts.
  • IPv6 must support an exponentially larger address space than IPv4.
  • IPv6 packets must be as lightweight as possible to facilitate transmission of IPv6 over diverse media.
  • Quality of Service (QoS), or the ability to prioritize traffic and allocate bandwidth, must be built into IPv6 to accommodate functionality required by low-latency applications.
  • IPv6 routing capabilities must be designed so that intermediate nodes on a path can be specified in the packets themselves, similar to IPv4's Record Route and Loose Source routing options.
  • Mechanisms for secure transmission of data must be inherent in IPv6's structure.

With both an eye turned toward future needs and an awareness of past and current issues, the IETF IPv6 working group continues to work to develop a solution.

Chapter Contents

This chapter looks at the current specifications for IPv6. Related RFCs are included on the companion CD-ROM.

Microsoft Research IPv6

The most current version of the Microsoft Research IPv6 stack may be downloaded at This implementation runs as a separate protocol stack on both Microsoft Windows NT 4.0 and Microsoft Windows 2000. There are no plans to im.plement IPv6 for the Microsoft Windows 95 or Windows 98 operating systems at this time.

The stack currently supports the following: basic IPv6 header processing; hop-by-hop options; destination options; fragmentation and routing headers; neighbor discovery; stateless address autoconfiguration; Internet Control Message Protocol version 6 (ICMPv6); Ethernet and FDDI media; automatic and configured tunnels; IPv6 over IPv4; IPv6 to IPv4 tunneling; UDP and TCP over IPv6; correspondent node mobility; host and router functionality; and IP Security (IPSec) authentication. Version 1.3 doesn't yet support full mobility and encryption.

Also available for download at the research site are several IPv6 applications, including the following: ping6; tracert6; Test TCP 6 (ttcp6) (over both User Datagram Protocol [UDP] and TCP); File Transmission Protocol v6/File Transmission Protocol Daemon v6 (ftp6/ftpd6); wininet.dll, which adds IPv6 functionality to Microsoft Internet Explorer; multicast conferencing applications; an IPv6 FTP client; an IPv6/v4 translator; and a protocol parser for Network Monitor that allows the capture and display of IPv6 packets.

A mailing list is also available to help users keep abreast of developments in the implementation. To subscribe, send mail to In the body of the mail, include the following:

subscribe msripv6-users yourfirstname yourlastname

This chapter contains the following sections:

  • Introduction to IPv6  A description of IPv6 and its intended function, as well as an introduction to terminology in IPv6
  • IPv6 Addressing  An overview of addressing in IPv6
  • IPv6 Header Format  A look at header formats in IPv6
  • Transition Mechanisms  A brief description of the intended methodology for integration of IPv6 with current formats

This chapter doesn't cover every detail of IPv6, nor does it attempt to fully describe its integration with Windows 2000 services.

Introduction to IPv6

As RFC 2460 describes, IPv6 is the intended replacement for IPv4. It increases the size of IP addresses from 32 to 128 bits, allowing for 296 (2128-32) times the number of addresses in IPv4. This gives a total of 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses, a seemingly endless supply. This increase in the address space not only provides for more hosts, but also for an expanded addressing hierarchy.
IPv6 specifications are defined in RFC 2460, which can be found in the \RFC folder on the companion CD-ROM.

Packet headers have been improved by dropping some IPv4 header fields, making others optional, and utilizing extension headers. Extension headers are separate headers that, with one exception, aren't examined by any hosts on a path between the source and destination, helping to improve routing efficiency. Additionally, they allow for more flexibility in options encoding and expansion capabilities for future options.

Flow labeling is introduced in IPv6, which allows packets to be designated as belonging to a specific "flow" of traffic, thus allowing for QoS handling and bandwidth management without having to parse TCP and UDP headers. Extensions also have been introduced that allow for authentication, data integrity assurance, and optional packet encryption.

Before looking at IPv6 in detail, it's important to understand some of the basic terminology used in the protocol specifications.

Nodes, Routers, Hosts, and Interfaces

A node is any device that implements IPv6. It can be a router, which is a device that forwards packets that aren't directed specifically to it, or a host, which is a node that doesn't forward packets. An interface is the connection to a transmission medium through which IPv6 packets are sent. While a distinction is made between routers and hosts, it's possible, albeit unlikely, for a single node to have multiple interfaces, and potentially be forwarding packets addressed to other nodes on only a subset of its interfaces. Thus, this device would be acting both as a host (on its non-forwarding interfaces) and as a router (on its forwarding interfaces).

Links, Neighbors, Link MTUs, and Link Layer Addresses

A link is the medim over which IPv6 is carried. Neighbors are nodes that are connected to the same link. A link maximum transmission unit (MTU) is the maximum packet size that can be carried over a given link medium, and is expressed in octets. A Link Layer address is the "physical" address of an interface, such as media access control (MAC) addresses for Ethernet links.

Unicast, Multicast, and Anycast Addresses

In IPv6, all addressing is directed to interfaces rather than to nodes. A unicast address specifies that a packet be sent to a particular interface. A multicast address is sent to a set of interfaces, typically encompassing multiple nodes. An anycast address, while identifying multiple interfaces (and typically multiple nodes), is sent only to the interface that's determined to be "nearest" to the sender. Each of these types of addressing will be discussed in more detail later in this chapter.
Unless otherwise specified, terms used in this chapter refer to IPv6.


Text Representation of IPv6 Addresses

Perhaps the most obvious difference between IPv4 and IPv6 is the increase in the number of bits used for addressing. Instead of using 32-bit dotted-decimal notation, IPv6 uses 128-bit addressing expressed in hexadecimal format. Text depiction of these addresses might vary, with the following three acceptable representations:
  • In the preferred text representation, addresses are listed as eight 16-bit hexadecimal sections, separated by colons. For example, an IPv6 address for an interface would look like:


    Any field containing leading zeros doesn't need to display the leading zeros, although no field can be left blank. For example:


  • Because of the mechanisms for address allocation in IPv6, long strings of zero bits will be common. Consequently, an alternate form of address representation allows "::" to be used to represent a portion of the address containing zero bits. The "::" placeholder can be used to represent more than one section of zero bits, but may not be used more than once in an address.

    For example:


    could be represented as:




    but not


  • The third method of textually displaying addresses is used in environments with a mixture of IPv4 and IPv6 nodes. In this notation, the six high-order (leftmost) 16-bit sections are displayed in hexadecimal, but the remaining bits are displayed in the familiar dotted-decimal notation.

    For example, an address might appear in any of these formats:

    0:0:0:0:0:0: or

    :: (compressed format)

    0:0:0:0:0:FFFF: or

    ::FFFF: (compressed format)

    ABCD:EF:12:34:0:0: or

    ABCD:EF:12:34:: (compressed format)

IPv6 addressing architecture is described in detail in RFC 2373, which can be found in the \RFC folder on the companion CD-ROM.

Unicast Addresses

A variable-length field of leading bits, referred to as the Format Prefix (FP), identifies the type of address in IPv6. An FP value of 11111111 (FF) identifies an address as a multicast address. Any other value in the high-order bits identifies the address as a unicast address. Anycast addresses are taken from the unicast space, and will be discussed in the "Anycast Addresses" section of this chapter. Unicast addresses refer to a single node on the link; however, a single unicast address can be assigned to multiple interfaces on that node, provided that the interfaces are presented to upper layer protocols as a single entity. Unicast addresses can be of several types, including Aggregatable Global unicast addresses, link local unicast addresses, site local unicast addresses, and IPv6 Addresses with Embedded IPv4 Addresses.

Reserved Unicast Addresses

Currently, RFC 2373 defines two specialized reserved unicast addresses. The first is called the unspecified address. The unspecified address, 0:0:0:0:0:0:0:0, or :: in compressed format, can't be assigned to any node, nor can it be used as the source address in IPv6 packets or routing headers. Typically, it's used while nodes are initializing IPv6, and indicates that they haven't yet "learned" their own addresses. The second reserved unicast address, 0:0:0:0:0:0:0:1, or ::1 in compressed format, is the loopback address, which is used by a node to send a packet to itself--much like the loopback address of in IPv4.

Aggregatable Global Unicast Addresses

In IPv4, under Classless Inter-Domain Routing (CIDR), ISPs (Internet Service Providers) allocate addresses in "pools." Aggregatable Global unicast addresses in IPv6 function in a similar manner, and will be used for global communication on the IPv6-enabled portion of the Internet. The format of an Aggregatable Global unicast address is shown in Figure 9-1.

The format of an Aggregatable Global unicast address is defined in RFC 2374, which can be found in the RFC folder on the companion CD-ROM.

Figure 9-1. An Aggregatable Global unicast address format.

Before looking at the internal structure of an Aggregatable Global unicast address, it's important to understand the overall structure of these addresses. Aggregatable addresses will be organized into a three-tiered hierarchical structure. The top level of this hierarchy will be the Public Topology, or the portion of the address space that will be managed by entities that provide public Internet services. The Public Topology will provide a mechanism for what are referred to as long-haul transit providers and public exchanges to provide aggregates, or collections, of addresses. These providers will be responsible for providing routing that occurs outside an organization's internal corporate structure.

Because organizations maintain internal routing topologies, a portion of an aggregatable address is devoted to allowing for internal routing. This is the Site Topology portion of the address, and represents the bits that will identify internal routing paths. One of the chief advantages to this three-tiered approach to address allocation is that if a company changes long-haul transit providers, or uses multiple providers, that company won't need to obtain reassigned Site Topology addresses.

The interface identifier of an aggregatable address is the portion that identifies individual interfaces on the organization's physical links. Similar to how IPv4 addresses use network IDs and host IDs, IPv6 addresses will use Site and Interface identifiers. Table 9-1 summarizes the structure of an Aggregatable Global unicast address.

Table 9-1. 

Abbreviation Field Length Description
FP Format Prefix 3 bits "001" indicates that this is an Aggregatable Global unicast address.
TLA ID Top-Level Aggregation 13 bits TLAs will be responsible for maintaining the upper levels of the public routing hierarchy. The use of 13 Identifier bits for these IDs allows for 8192 TLAs.
RES Reserved 8 bits Reserving these bits allows for the expansion of TLA and NLA fields, should future needs dictate.
NLA ID Next-Level Aggregation Identifier 24 bits NLAs will be used by organizations that are assigned a TLA to create an internal addressing hierarchy, and to allow transit providers to identify sites that they service. The use of 24 bits for this identifier will allow each TLA to service approximately 16 million sites if used in a flat fashion, or roughly the equivalent of the entire IPv4 address space if used hierarchically.
SLA ID Site-Level Aggregation Identifier 16 bits SLAs allow organizations to create an internal routing structure independent of the external public routing topologies. Approximately 65,536 internal sub-nets will be supported by the use of 16 bits for SLAs.
Interface ID Interface Identifier 64 bits Interface IDs must be unique to the link, might often match the Link Layer address, and actually might be assigned to multiple interfaces on a single node, thus allowing for load balancing over multiple interfaces.

Local-Use Unicast Addresses

Link-local unicast addresses, shown in Figure 9-2, are used for communication within a single link. They are used on links where no routers are present, or for purposes such as address autoconfiguration (the process by which nodes obtain an IPv6 address) and neighbor discovery (a method used for finding other nodes on a link).

Site-local unicast addresses, shown in Figure 9-3, are the equivalent of IPv4 private addresses and are used for addressing and communication within a single private organization. Routers must not forward these packets outside the site where they're used.

IPv6 Addresses with Embedded IPv4 Addresses

To successfully facilitate the transition from IPv4 to IPv6, mechanisms have been developed for tunneling IPv6 packets over IPv4 infrastructures. One mechanism for encoding packets allows nodes to carry an IPv4 address in the low-order bits of the IPv6 packet, which uses a specialized unicast address. This type of packet is referred to as an IPv4-compatible IPv6 address, as seen in Figure 9-4, and zeros out all fields in the interface identifier except for the 32 low-order IPv4 bits. A second type of transition packet exists to allow nodes to specify addresses for nodes that don't use IPv6 in any form, and precedes the 32 bits of the IPv4 address with "FFFF" to indicate that this is what is termed an "IPv4-mapped IPv6 address."

Anycast Addresses

Anycast addresses are structurally identical to other unicast addresses, and are pulled from the pool of available unicast addresses in a given organization. However, rather than being assigned to a single node, as with unicast addresses, the anycast address is assigned to a group of nodes, typically routers on the site. Each of the routers is assigned the same address, and configured to use it as an anycast address.

When a source node wishes to send a packet to this address, it uses a discovery mechanism to find the nearest node that owns the address. Thus, the source node doesn't need to have knowledge that the address is an anycast address, as subsequent communication occurs only between the source node and the nearest router configured to use the anycast address.

As RFCs 2373 and 2526 state, anycast addresses are currently subject to certain limitations as research progresses. At this time, anycast addresses can't be used as the source address in any IPv6 packet, and can be used only by routers, not by hosts. Additionally, routers are required to support the anycast addresses for each subnet to which they are connected, to ensure that a local router will receive the packet sent to an anycast address on that subnet.

Multicast Addresses

As defined in RFCs 2373 and 2375, multicast addresses are used for IPv6 multicast traffic and replace broadcast addresses in IPv6. A multicast address is assigned to a group of nodes, but unlike an anycast address, all nodes configured with the multicast address will receive packets sent to that address. A node can belong to more than one multicast group; however, no node can use a multicast address as a source address in any packet; nor can a multicast address be used in routing headers. Figure 9-5 shows the format of an IPv6 multicast address.
Read about multicast addresses and IPv6 traffic in RFCs 2373 and 2375, which can be found in the \RFC folder on the companion CD-ROM.

Table 9-2 describes each of the fields in a multicast address.

Table 9-2. 

Abbreviation Field Length Description
FP Format Prefix 3 bits "11111111" indicates that this is a multicast.
Flgs Flags 4 bits The first 3 bits of the Flags field are reserved, and must be zeroed out. If the fourth flag is "0," this indicates a permanently assigned multicast address; if it's "1," the multicast address is "transient," or not assigned by the Internet Assigned Numbers Authority (IANA).
Scop Scope 4 bits Scope values limit the scope of the multicast group. Values of "0" or "F" are reserved; "1" indicates a node-local scope; "2" indicates a link-local scope; "5" indicates a site-local scope; "8" indicates an organization-local scope; "E" indicates a global scope; and all other values are currently unassigned.
Group ID Group 112 bits This is a unique identifier for the multicast group Identifier that will accept packets sent to this address.

For example, the following multicast addresses are used to address packets to groups of routers:

FF01:0:0:0:0:0:0:2 Node-local; all routers.

This address identifies all routing interfaces on a single node.

FF02:0:0:0:0:0:0:2 Link-local; all routers.

This address identifies all routers on a link.

FFO5:0:0:0:0:0:0:2 Site-local; all routers.

This address identifies all routers in a site.

Neighbor Discovery

"Discovery" can be a misleading term, as nodes use discovery mechanisms to both advertise their presence to other nodes on the network and to determine parameters such as node location, router availability, link MTU, and address configuration. Some discovery methods are specific to the physical link type, although RFC 2461 defines general discovery mechanisms. Discovery mechanisms are often implemented as multicasts, and replace IPv4 functionality such as ARP, ICMP router discovery, Internet Group Management Protocol (IGMP), and ICMP redirect.

Router Discovery Mechanisms

Routers use discovery for a multitude of purposes. Both at regular intervals and in response to router solicitation requests, routers issue router advertisements. These advertisements can include information that informs nodes of Link Layer router addresses, link prefixes (the approximate equivalent to the IPv4 netmask), suggested hop limits, and link MTU.

By advertising its own physical address, each router enables other nodes on the network to ascertain the router's existence. Router advertising of link prefixes allows nodes to determine to which subnet they're attached, and thus to build their internal routing tables. In IPv6, packets are now decremented by hop, rather than by Time-to-Live (TTL) values. By sending suggested hop limits, a router aids nodes in determining whether a destination is reachable by a given path. Additionally, for multicasting to function correctly on a link, all nodes must use the same MTU. Router advertisements enable nodes to configure their packets correctly for the link MTU.

Using Router Advertisement, routers also can be configured for inbound load balancing. A router can have multiple interfaces to a given link. However, these interfaces can be presented as a single interface with multiple bound addresses, and the router can omit the source address in its router advertisement packets. Consequently, hosts wanting to send packets to the router would use a neighbor solicitation request to obtain a router interface's address. The router can then provide different addresses in response to requests from different hosts. All hosts will believe that they're sending packets to a single interface with multiple addresses when, in reality, the router might divide incoming traffic over all connected interfaces.

Host Discovery

Hosts use discovery mechanisms primarily as an investigative tool, although they'll also respond to requests for information regarding their own configuration. Upon initializing, a host might use discovery to query a router as to whether it should configure its address via "stateless" or "stateful" configuration. Stateful autoconfiguration is used to issue host address parameters via Dynamic Host Configuration Protocol (DHCP). As defined in RFC 2462, stateless autoconfiguration enables the host to assign itself an address, issue a discovery packet to determine if the address is being used by any other node on the link, and configure remaining link and site parameters based on the information the host received in the router advertisement packet.

Stateless autoconfiguration is defined in RFC 2462, which can be found in the \RFC folder on the companion CD-ROM.

When a node wants to communicate with another node, it issues a neighbor solicitation to the solicited node multicast address of the target node requesting its Link Layer address. The source node includes its own Link Layer address in the solicitation packet so that the target node can cache the results and thus doesn't need to issue its own solicitation. In response, the target node issues a neighbor advertisement listing its own Link Layer address.

When communication between two nodes is actively occurring, each node relies on upper layer protocols to provide confirmation that packets are successfully being sent and received. If this confirmation isn't forthcoming, a node uses neighbor unreachability detection to determine if the other node is still functional by sending a unicast neighbor solicitation directly to its partner. If two-way connectivity isn't confirmed, the node will stop sending packets to the target.

RFC 2463 discusses how ICMP addresses error handling in IPv6. This RFC can be found in the \RFC folder on the companion CD-ROM.

Should a node's Link Layer address change, it will issue an unsolicited multicast neighbor advertisement to announce the change to other nodes on the network. By issuing the announcement immediately, other nodes can purge cached Link Layer addresses for that node, and thus decrease the likelihood that they will attempt communication with an unreachable node....

Read More Show Less

Table of Contents

Part I: The Network Interface Layer
1. Local Area Network (LAN) Technologies
2. Wide Area Network (WAN) Technologies
3. Address Resolution (ARP)
Part II: Internet Layer Protocols
4. Internet Protocol (IP) Basics
5. Internet Protocol (IP) Addressing
6. Internet Protocol (IP) Routing
7. Internet Control Message Protocol (CMP)
8. Internet Group Management Protocol (IGMP)
9. Internet Protocol Version 6 (IPv6)
Part III: Transport Layer Protocols
10. User Datagram Protocol (UDP)
11. Transmission Control Protocol (TCP) Basics
12. Transmission Control Protocol (TCP) Connections
13. Transmission Control Protocol (TCP) Data Flow
14. Transmission Control Protocol (TCP) Retransmission and Time-Out
Part IV: Application Layer Protocols and Services
15. Dynamic Host Configuration Protocol (DHCP) Service
16. Domain Name Service (DNS)
17. Windows Internet Name Service (WINS)
18. File and Printer Sharing
19. Internet Information Server (IIS) and the Internet Protocols
20. Securing IP Communications with IP Security (IPsec)
21. Virtual Private Networks (VPNs)
Read More Show Less


I can still remember picking up my first TCP/IP book in early 1994. Up to that point, I'd had several years of networking experience with Windows for Workgroups, Novell NetWare, and Windows NT 3.1, but knew little of UNIX or of TCP/IP. I had finally broken down and decided to get onto the Internet, but all the instructions my ISP gave me were totally foreign.

So I went out and bought a book-actually, I bought several. At first the concepts were foreign and seemed so contrary to what I knew. Reading W. Richard Steven's books really brought the subject to light, and gradually, like peeling an onion, I worked through the layers and discovered the wonderful world of TCP/IP

Why We Wrote This Book

I started thinking about writing this book many years ago. Most of the good TCP/IP books available then were either aimed at the UNIX market or were completely generic. As I did more and more with Microsoft's TCP/IP offerings and watched the Windows 2000 product slowly evolve, it was obvious a book focusing on TCP/IP with a Windows 2000 focus would be very useful.

Joe and I worked together several years ago as part of a team that was rolling out advanced TCP/IP training to Microsoft product support engineers. Joe was the course author and I was one of the many trainers who delivered this material to a very tough audience. It took time, and a lot of convincing by those nice people at Microsoft Press, but here we are.

We wrote this book as an in-depth reference to the TCP/IP protocol suite and the related network services. We explain how this suite of protocols and related services work and how they function in Windows 2000.

We have aimed this book at several differentaudiences:

  • General technical staff Anyone interested in learning the details of TCP/IP as implemented in Windows 2000.
  • TCP/IP administrators This book contains details of the protocols and services administrators need to do problem solving and TCP/IP infrastructure planning.
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 2 Customer Reviews
  • Anonymous

    Posted July 18, 2002

    Required for Win2K SysAdmins!

    If you do Win2K you gotta have this book. This book provides the educational background, the implementation information, and the customizing steps to help you administer either a single Win2K box or 400,000 of them! Excellent diagrams, easy-to-read text, and loads of good information.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted February 29, 2000


    This is a great book! It contains good descriptions of each of the TCP/IP protocols, with loads of network captures, from both an RFC and a Microsoft point of view. The captures are included on the companion CD showing along with all the RFCs and IETF drafts. The book is concise and clearly written, with lots of detail. Superb.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 2 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)