- Shopping Bag ( 0 items )
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...
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.
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:
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.
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 firstname.lastname@example.org. In the body of the mail, include the following:
subscribe msripv6-users yourfirstname yourlastname
This chapter contains the following sections:
This chapter doesn't cover every detail of IPv6, nor does it attempt to fully describe its integration with Windows 2000 services.
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.
Any field containing leading zeros doesn't need to display the leading zeros, although no field can be left blank. For example:
could be represented as:
For example, an address might appear in any of these formats:
::188.8.131.52 (compressed format)
::FFFF:184.108.40.206 (compressed format)
ABCD:EF:12:34::220.127.116.11 (compressed format)
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 127.0.0.1 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.
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.
|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."
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.
Table 9-2 describes each of the fields in a multicast address.
|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.
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.
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.
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.
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....
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
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:
Posted July 18, 2002
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 NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
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 NoThank you for your feedback. Report this reviewThank you, this review has been flagged.