Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

In our example above, 71.94.0.0/15 is the complete network, and subnetwork #0 is

71.94.0.0/16. They have a different prefix length (the number of network ID bits) but the

same base address. If a router has more than one match for a network ID in this manner, it

must use the match with the longest network identifier first, since it represents a more

specific network description.

IP Multicasting

The great bulk of TCP/IP communications uses the Internet Protocol to send messages

from one source device to one recipient device; this is called unicast communications. This

is the type of messaging we normally use TCP/IP for; when you use the Internet you are

using unicast for pretty much everything. For this reason, most of my discussion of IP has

been oriented around describing unicast messaging.

IP does, however, also support the ability to have one device send a message to a set of

recipients. This is called multicasting. IP multicasting has been “officially” supported since

IPv4 was first defined, but has not seen widespread use over the years, due largely to lack

of support for multicasting in many hardware devices. Interest in multicasting has increased

in recent years, and support for multicasting was made a standard part of the next gener-

ation IP version 6 protocol. Therefore, I felt it worthwhile to provide a brief overview of IP

multicasting. It's a large and very complex subject, so I will not be getting into it in detail—

you'll have to look elsewhere for a full description of IP multicasting. (Sorry, it was either a

brief summary or nothing; maybe I'll write more on multicasting in the future.)

The idea behind IP multicasting is to allow a device on an IP internetwork to send

datagrams not to just one recipient but to an arbitrary collection of other devices. IP multi-

casting is modeled after the similar function used in the data link layer to allow a single

hardware device to send to various members of a group. Multicasting is relatively easy at

the data link layer, however, because all the devices can communicate directly. In contrast,

at the network layer, we are connecting together devices that may be quite far away from

each other, and must route datagrams between these different networks. This necessarily

complicates multicasting when done using IP (except in the special case where we use IP

multicasting only between devices on the same data link layer network.)

There are three primary functions that must be performed to implement IP multicasting:

addressing, group management, and datagram processing / routing.

Multicast Addressing

Special addressing must be used for multicasting. These multicast addresses identify not

single devices but rather multicast groups of devices that listen for certain datagrams sent

to them. In IPv4, 1/16th of the entire address space was set aside for multicast addresses:

the Class D block of the original “classful” addressing scheme.

Special techniques are used to define the meaning of addresses within this block, and to

define a mapping between IP multicast and data link layer multicast addresses. This is all

described in the topic on IP multicast addressing; mapping of IP multicast addresses to

hardware layer multicast addresses is discussed in the section on address resolution.

Multicast Group Management

Group management encompasses all of the activities required to set up groups of devices.

They must be able to dynamically join groups and leave groups, and information about

groups must be propagated around the IP internetwork. To support these activities,

additional techniques are required. The Internet Group Management Protocol (IGMP) is the

chief tool used for this purpose. It defines a message format to allow information about

groups and group membership to be sent between devices and routers on the internet.

Multicast Datagram Processing and Routing

This is probably the most complicated: handling and routing datagrams in a multicast

environment. There are several issues here:

☯ Since we are sending from one device to many devices, we need to actually create

multiple copies of the datagram for delivery, in contrast to the single datagram used in

the unicast case. Routers must be able to tell when they need to create these copies.

☯ Routers must use special algorithms to determine how to forward multicast datagrams.

Since each one can lead to many copies being sent various places, efficiency is

important to avoid creating unnecessary volumes of traffic.

☯ Routers must be able to handle datagrams sent to a multicast group even if the source

is not a group member.

Routing in a multicast environment requires significantly more intelligence on the part of

router hardware. Several special protocols, such as the Distance Vector Multicast Routing

Protocol (DVMRP), and the multicast version of OSPF, are used to enable routers to

forward multicast traffic effectively. These algorithms must balance the need to ensure that

every device in a group receives a copy of all datagrams intended for that group, with the

need to prevent unnecessary traffic from moving across the internetwork.

Key Concept: IP multicasting allows special applications to be developed where one

device sends information to more than one other, across a private internet or the

global Internet. It is more complex than conventional unicast IP and requires special

attention particularly in the areas of addressing and routing.

This overview has only scratched the surface of IP multicasting. The complexity involved in

handling groups and forwarding messages to multicast groups is one reason why support

for the feature has been quite uneven and as a consequence, it is not used widely. Another

issue is the demanding nature of multicasting; it uses a great deal of network bandwidth for

copies of messages, and also requires more work of already-busy routers.

Internet Protocol Version 6 (IPv6) / IP Next Generation (IPng)

Since 1981, TCP/IP has been built on version 4 of the Internet Protocol. IPv4 was created

when the giant, world-wide Internet we take for granted today was just a small experimental

network. Considering how much the Internet has grown and changed over the course of

two decades, IPv4 has done its job admirably. At the same time, it has been apparent for

many years that certain limitations in this venerable protocol would hold back the future

growth of both Internet size and services if not addressed.

Due to the key role that IP plays, changing it is no simple feat. It means a substantial modifi-

cation to the way that nearly everything in TCP/IP operates. However, even though we find

change difficult, most of us know that it is necessary. For the last several years, devel-

opment of a new version of IP has been underway, officially called Internet Protocol version

6 (IPv6) and also sometimes referred to as IP Next Generation or IPng. IPv6 is poised to

take over from IPv4, and will be the basis for the Internet of the future.

In this section I provide a detailed description of IP version 6. Since IPv6 is still IP just like

IPv4, it performs the same functions: addressing, encapsulation, fragmentation and

reassembly, and datagram delivery and routing. For this reason, the subsections and topics

in this discussion of IPv6 are patterned after the subsections in the section on IPv4. They

include a discussion of IPv6 concepts and issues, coverage of IPv6 addressing and data

packaging, and a look at how version 6 does fragmentation, reassembly and routing.

Background Information: Since IPv6 represents the evolution of IP, many of its

concepts of operation are built upon those introduced in IPv4. To avoid unnec-

essary duplication, this section has been written with the assumption that the

reader is familiar with the operation of IPv4, especially addressing and how datagrams are

packaged and delivered. If you have not read the section on IPv4, reviewing it first would be

wise, because the description of IPv6 focuses on how it differs from the current IP version.

Related Information: You may wish to refer to the sections on ICMP (part of

which is ICMPv6—ICMP for IPv6) and the IPv6 Neighbor Discovery (ND) protocol,

since these are “companions” of sort to IPv6. However, it is not necessary.

Note: IPv6 is obviously still under development, and as such, writing a section

such as this one is like trying to hit a moving target. This is probably why most

TCP/IP guides don't say much about IPv6—it keeps changing! I think it is

important, so I have described it as defined on the date of publishing. However, since

changes are being made to both IPv6 standards and implementation every month, there is

a higher probability of information in this particular section being out of date. (I had to make

several revisions even prior to publishing the first version of this Guide!)

IPv6 Overview, Changes and Transition

IPv6 is destined to be the future of the Internet Protocol, and due to IP's critical importance,

it will form the basis for the future of TCP/IP and the Internet as well. In fact, it's been under

development since the middle of the last decade, and a real IPv6 internetwork has been

used for testing for a number of years as well. Despite this, many people don't know much

about IPv6, other than it's a newer version of IP. Some have never even heard of it at all!

We're going to rectify that, of course—but before we delve into the important changes made

in version 6 to how IP addressing, packaging, fragmentation and other functions, let's start

with a “bird's eye” view of IPv6.

In this section I provide a brief higher-level overview of IPv6, including a look at how it

differs from IPv4 in general terms. I begin with a brief overview of IPv6 and why it was

created. I list the major changes made in IPv6 and additions to the protocol from the current

version. I also explain some of the difficulties associated with transitioning the enormous

global Internet from IPv4 to IPv6.

IPv6 Motivation and Overview

“If it ain't broke, don't fix it.” I consider this one of my favorite pieces of folk wisdom. I

generally like to stick with what works, as do most people. And IP version 4 works pretty

darned well. It's been around for decades now and has survived the growth of the Internet

from a small research network into a globe-spanning powerhouse. So, like a trusty older car

that we've operated successfully for years, why should we replace it if it still gets the job

done?

Like that older car, we could continue to use IPv4 for the foreseeable future. The question

is: at what cost? An older car can be kept in good working order if you are willing to devote

the time and money it takes to maintain and service it. However, it will still be limited in

some of its capabilities. Its reliability may be suspect. It won't have the latest features. With

the exception of those who like to work on cars as a hobby, it eventually stops making

sense to keep fixing up an older vehicle.

In some ways, this isn't even that great of an analogy. Our highways aren’t all that much

different than they were in the 1970s, and most other issues related to driving a car haven't

changed all that much in the last 25 years either. The choice of updating a vehicle or not is

based on practical considerations more than necessity.

In contrast, look at what has happened to the computer and networking worlds in the last 25

years! Today's handheld PCs can do more than the most powerful servers could back then.

Networking technologies are 100 or even 1000 times as fast. The number of people

connecting to the global Internet has increased by an even larger factor. And the ways that

computers communicate have, in many cases, changed dramatically.

IPv4 could be considered in some ways like an older car that has been meticulously

maintained and repaired over time. It gets the job done, but its age is starting to show. The

main problem with IPv4 is its relatively small address space, a legacy of the decision to use

only 32 bits for the IP address. Under the original “classful” addressing allocation scheme,

we would have probably already run out of IPv4 addresses by now. Moving to classless

addressing has helped postpone this, as have technologies like IP Network Address Trans-

lation (NAT) that allow privately-addressed hosts to access the Internet.

In the end, however, these represent patch jobs and imperfect repairs applied to keep the

aging automobile that is IPv4 on the road. The core problem, the 32-bit address space that

is too small for the current and future size of the Internet, can only be addressed by moving

to a larger address space. This was the primary motivating factor in creating the next

version of the Internet Protocol, IPv6.

Note: The reason why the successor to IPv4 is version 6 and not version 5 is

because version number 5 was used to refer to an experimental protocol called

the Internet Stream Protocol, which was never widely deployed. See the topic on

IP history and versions for a full discussion.

IPv6 Standards

IPv6 represents the first major change to the Internet Protocol since IPv4 was formalized in

1981. For many years, its core operation was defined in a series of RFCs published in

1998, RFCs 2460 through 2467. The most notable of these are the main IPv6 standard,

RFC 2460 (Internet Protocol, Version 6 (IPv6) Specification

), and documents describing the

two “helper” protocols for IPv6: RFC 2461, which describes the IPv6 Neighbor Discovery

Protocol, and RFC 2463, which describes ICMP version 6 (ICMPv6) for IPv6.

In addition to these, two documents were also created in 1998 to discuss more about IP

addressing: RFC 2373 (IP Version 6 Addressing Architecture) and RFC 2374 (An IPv6

Aggregatable Global Unicast Address Format). Due to changes in how IPv6 addressing

was to be implemented, these were updated in 2003 by RFC 3513 (Internet Protocol

Version 6 (IPv6) Addressing Architecture) and RFC 3587 (IPv6 Global Unicast Address

Format).

Many other RFCs define more specifics of how IPv6 functions, and also describe IPv6-

compatible versions of other TCP/IP protocols like DNS and DHCP. IPv6 is still very much a

work in progress with new standards for it being proposed and adopted on a regular basis.

Since IPv6 is the version of IP designed for the next generation of the Internet, it is also

sometimes called IP Next Generation or IPng. Personally, I don't care for this name; it

reminds me too much of Star Trek: The Next Generation. A great show that my wife and I

watch regularly, but still. Regardless of its name, IPv6 or IPng was designed to take TCP/IP

and the Internet “where none have gone before”. (Sorry, I had to! ☺)

Design Goals of IPv6

The problem of addressing was the main motivation for creating IPv6. Unfortunately, this

has caused many people to think that the address space expansion is the only change

made in IP, which is definitely not the case. Since making a change to IP is such a big deal,

it's something done rarely. It made sense to correct not just the addressing issue but to

update the protocol in a number of other respects as well, to ensure its viability. In fact, even

the addressing changes in IPv6 go far beyond just adding more bits to IP address fields.

Some of the most important goals in designing IPv6 include:

☯ Larger Address Space: This is what we discussed earlier. IPv6 had to provide more

addresses for the growing Internet.

☯ Better Management of Address Space: It was desired that IPv6 not only include

more addresses, but a more capable way of dividing the address space and using the

bits in each address.

☯ Elimination of “Addressing Kludges”: Technologies like NAT are effectively

“kludges” that make up for the lack of address space in IPv4. IPv6 eliminates the need

for NAT and similar workarounds, allowing every TCP/IP device to have a public

address.

☯ Easier TCP/IP Administration: The designers of IPv6 hoped to resolve some of the

current labor-intensive requirements of IPv4, such as the need to configure IP

addresses. Even though tools like DHCP eliminate the need to manually configure

many hosts, it only partially solves the problem.

☯ Modern Design For Routing: In contrast to IPv4, which was designed before we all

had any idea what the modern Internet would be like, IPv6 was created specifically for

efficient routing in our current Internet, and with the flexibility for the future.

☯ Better Support For Multicasting: Multicasting was an option under IPv4 from the

start, but support for it has been slow in coming.

☯ Better Support For Security: IPv4 was designed at a time when security wasn't

much of an issue, because there were a relatively small number of networks on the

internet, and their administrators often knew each other. Today, security on the public

Internet is a big issue, and the future success of the Internet requires that security

concerns be resolved.

☯ Better Support For Mobility: When IPv4 was created, there really was no concept of

mobile IP devices. The problems associated with computers that move between

networks led to the need for Mobile IP. IPv6 builds on Mobile IP and provides mobility

support within IP itself.

IPv6: The Evolution of IP

At the same time that IPv6 was intended to address the issues above and many others with

traditional IP, we should keep in mind that its changes are evolutionary, not revolutionary.

During the many discussions in the IETF in the 1990s, there were some who said that while

we were updating IP, perhaps we should make a complete, radical change to a new type of

internetworking protocol completely. The end decision was not to do this, but to define a

more capable version of the IP we've been using all along.

The reason for this is simple: IP, like our trusted older car, works. IPv6 represents an

update that strives to add to the best characteristics of IPv4 rather than making everyone

start over from scratch with something new and unproven. This design ensures that

whatever pain may result from the change from IPv4 to IPv6 can be managed, and

hopefully, minimized.

Key Concept: The new version of the Internet Protocol is Internet Protocol Version 6

(IPv6). It was created to correct some of the significant problems of IPv4, especially

the looming exhaustion of the IPv4 address space, and to improve the operation of

the protocol as a whole, to take TCP/IP in to the future.

Major Changes And Additions In IPv6

In the preceding overview, I explained that the primary motivator for creating a new version

of IP was to fix the problems with addressing under IPv4. But as we also saw there,

numerous other design goals existed for the new protocol as well. Once the decision was

made to take the significant step of creating a new version of a protocol as important as IP,

it made sense to use the opportunity to make as many improvements as possible.

Of course, there is still the problem of the pain of change to worry about, so each potential

change or addition in IPv6 had to have benefits that would outweigh its costs. The resulting

design does a good job of providing useful advantages while maintaining most of the core

of the original Internet Protocol. The following list provides a summary of the most important

changes between IPv4 and IPv6, showing some of the ways that the IPv6 team met the

design goals for the new protocol:

☯ Larger Address Space: IPv6 addresses are 128 bits long instead of 32 bits. This

expands the address space from around 4 billion addresses to, well, an astronomic

number (over 300 trillion trillion trillion addresses).

☯ Hierarchical Address Space: One reason why the IPv6 address size was expanded

so much was to allow it to be hierarchically divided to provide a large number of each

of many classes of addresses.

☯ Hierarchical Assignment of Unicast Addresses: A special global unicast address

format was created to allow addresses to be easily allocated across the entire Internet.

It allows for multiple levels of network and subnetwork hierarchies both at the ISP and

organizational level. It also permits generating IP addresses based on underlying

hardware interface device IDs such as Ethernet MAC addresses.

☯ Better Support for Non-Unicast Addressing: Support for multicasting is improved,

and support is added for a new type of addressing: anycast addressing. This new kind

of addressing basically says “deliver this message to the easiest-to-reach member of

this group”, and potentially enables new types of messaging functionality.

☯ Autoconfiguration and Renumbering: A provision is included to allow easier

autoconfiguration of hosts and renumbering of the IP addresses in networks and

subnetworks as needed. A technique also exists for renumbering router addresses.

☯ New Datagram Format: The IP datagram format has been redefined and given new

capabilities. The main header of each IP datagram has been streamlined, and support

added for easily extending the header for datagrams requiring more control

information.

☯ Support for Quality of Service: IPv6 datagrams include QoS features, allowing

better support for multimedia and other applications requiring quality of service.

☯ Security Support: Security support is designed into IPv6 using the authentication and

encryption extension headers and other features.

☯ Updated Fragmentation and Reassembly Procedures: The way that fragmentation

and reassembly of datagrams works has been changed in IPv6, to improve efficiency

of routing and better reflect the realities of today's networks.

☯ Modernized Routing Support: The IPv6 protocol is designed to support modern

routing systems, and to allow expansion as the Internet grows.

☯ Transition Capabilities: Since it was recognized from the start that going from IPv4 to

IPv6 is a big move, support for the IPv4/IPv6 transition has been provided in numerous

areas. This includes a plan for interoperating IPv4 and IPv6 networks, mapping

between IPv4 and IPv6 addresses and more.

The rest of the sections on IPv6 provide much more detail on these changes and additions

to IP. You'll notice that the majority of these are related to addressing, since that is where

the greatest number of important changes have been made in IPv6. Of course, routing and

addressing are closely related, and the changes to addressing has had a big impact on

routing as well.

Another change that I should mention is that with the introduction of IPv6, several other

TCP/IP protocols that deal intimately with IP have also had to be updated. One of these is

ICMP, the most important support protocol for IPv4, which has been revised through the

creation of ICMPv6 for IPv6. An addition to TCP/IP is the Neighbor Discovery (ND) protocol,

which performs several functions for IPv6 that were done by ARP and ICMP in version 4.

Transition from IPv4 to IPv6

The Internet Protocol is the foundation of the TCP/IP protocol suite and the Internet, and

thus somewhat comparable to the foundation of a house in terms of its structural impor-

tance. Given this, changing IP is somewhat analogous to making a substantial modification

to the foundation of your house. Since IP is used to connect together many devices, it is in

fact, like changing not just your house, but every house in the world!

How do you change the foundation of a house? Very carefully. The same caution is required

with the implementation of IPv6. While to most people IPv6 is something “new”, the reality is

that the planning and development of IPv6 has been underway for nearly a full decade, and

if we were starting from scratch the protocol would have been ready for action years ago.

However, there is a truly enormous installed base of IPv4 hardware and software. This

means the folks who develop TCP/IP could not just “flip a switch” and have everyone move

over to using IPv6. Instead, a transition from IPv4 to IPv6 had to be planned.

IPv4-IPv6 Transition: Differences of Opinion

The transition is already underway, though most people don't know about it. As I said,

development of IPv6 itself is pretty much complete, though work continues on refining the

protocol and also on development of IPv6-compatible versions of other protocols. The

implementation of IPv6 began with the creation of development networks to test IPv6's

operation. These were connected together to form an experimental IPv6 internetwork called

the 6BONE (which is a contraction of the phrase “IPv6 backbone”.) This internetwork has

been in operation for several years.

Experimental networks are well and good, but of course the big issue is transitioning the

“real” Internet to IPv6—and here, opinion diverges rather quickly. In one camp are the

corporations, organizations and individuals who are quite eager to transition to IPv6 quickly,

to gain the many benefits it promises in the areas of addressing, routing and security.

Others are taking a much more cautious approach, noting that the dire predictions in the

mid-1990s of IPv4's imminent doom have not come to pass, and arguing that we should

take our time to make sure IPv6 is going to work on a large scale.

These two groups will continue to play tug-of-war for the next few years, but it seems that

the tide is now turning towards those who want to speed up the now-years-long transition.

The move towards adoption of IPv6 as a production protocol is being spearheaded by a

number of groups and organizations. IPv6 has a lot of support in areas outside the United

States, many of which are running short of IPv4 addresses due to small allocations relative

to their size. One such area is Asia, a region with billions of people, rapidly-growing Internet

use and a shortage of IPv4 addresses.

Within the United States, which has the lion's share of IPv4 addresses (due to the Internet

having been developed in the U.S.A.), there seems to be a bit less enthusiasm for rapid

IPv6 deployment. Even here, however, IPv6 got a major “shot in the arm” in July 2003 when

the United States Department of Defense (DoD) announced that starting in October of that

year, it would only purchase networking products that included compatibility with IPv6. The

DoD—which of course was responsible for the development of the Internet in the first

place—hopes to be fully transitioned to IPv6 by 2008. This will likely have a big impact on

the plans of other governmental and private organizations in the United States.

Of course, the creators of IPv6 knew from the start that transition was going to be an

important issue with the new protocol. IPv6 is not compatible with IPv4 because the

addressing system and datagram format are different. Yet the IPv6 designers knew that

since the transition would take many years, it was necessary that they provide a way for

IPv4 and IPv6 hosts to interoperate. Consider that in any transition there are always “strag-

glers”. Like the old Windows 3.11 PC in the corner that you still need to use once in a while,

even when most of the Internet is IPv6 there will still likely be some devices that are still on

IPv4 because they were never upgraded.