Charles M. Kozierok The TCP-IP Guide

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

☯ 80 bits consisting of 79 zeroes followed by a single one; this means that in colon

hexadecimal notation, the next five hexadecimal values are

“0000:0000:0000:0000:0001”, or more succinctly, “0:0:0:0:1”.

☯ 8 ones: “FF”.

☯ 24 bits taken from the bottom 24 bits of its unicast address.

So, these addresses start with “FF02:0:0:0:0:1:FF” followed by the bottom 24 bits of the

unicast address. So, the node with IP address 805B:2D9D:DC28:0:0:FC57:D4C8:1FFF

would have a solicited-node address of FF02:0:0:0:0:1:FFC8:1FFF (or

FF02::1:FFC8:1FFF).

Key Concept: Each unicast address has an equivalent solicited-node multicast

address, which is created from the unicast address and used when other devices

need to reach it on the local network.

IPv6 Anycast Addresses

Anycast addresses are a new, unique type of address that is new to IP in IPv6; the IPv6

implementation is based on the material in RFC 1546, Host Anycasting Service. Anycast

addresses can be considered a conceptual cross between unicast and multicast

addressing. Where unicast says “send to this one address” and multicast says “send to

every member of this group”, anycast says “send to any one member of this group”.

Naturally, in choosing which member to send to, we would for efficiency reasons normally

send to the closest one—closest in routing terms. So we can normally also consider

anycast to mean “send to the closest member of this group”.

The idea behind anycast is to enable functionality that was previously difficult to implement

in TCP/IP. Anycast was specifically intended to provide flexibility in situations where we

need a service that is provided by a number of different servers or routers but don't really

care which one provides it. In routing, anycast allows datagrams to be sent to whichever

router in a group of equivalent routers is closest, to allow load sharing amongst routers and

dynamic flexibility if certain routers go out of service. Datagrams sent to the anycast

address will automatically be delivered to the device that is easiest to reach.

Perhaps surprisingly, there is no special anycast addressing scheme: anycast addresses

are the same as unicast addresses. An anycast address is created “automatically” when a

unicast address is assigned to more than one interface.

Like multicast, anycast creates more work for routers; it is more complicated than unicast

addressing. In particular, the further apart the devices that share the anycast address are,

the more complexity is created. Anycasting across the global Internet would be potentially

difficult to implement, and IPv6 anycasting was designed for devices that are proximate to

each other, generally in the same network. Also, due to the relative inexperience of the

Internet community in using anycast, for the present time anycast addresses are used only

by routers and not individual hosts.

Key Concept: Anycast addresses are new in IPv6 and can be used to set up a

group of devices any one of which can respond to a request sent to a single IP

address.

IPv6 Autoconfiguration and Renumbering

One of the most interesting and potentially valuable addressing features implemented in

IPv6 is a facility to allow devices on an IPv6 to actually configure themselves independently.

In IPv4 hosts were originally configured manually. Later, host configuration protocols like

DHCP enabled servers to allocate IP addresses to hosts that joined the network. IPv6 takes

this a step further, by defining a method for some devices to automatically configure their IP

address and other parameters without the need for a server. It also defines a method

whereby the IP addresses on a network can be renumbered (changed en masse). These

are the sorts of features that make TCP/IP network administrators drool.

The IPv6 autoconfiguration and renumbering feature is defined in RFC 2462, IPv6 Stateless

Address Autoconfiguration. The word “stateless” contrasts this method to the server-based

method using something like DHCPv6, which is called “stateful”. (Another word like

“classful” that makes me cringe.) This method is called “stateless” because it begins from a

“dead start” with no information (or “state”) at all for the host to work with, and has no need

for a DHCP server.

IPv6 Stateless Autoconfiguration

Stateless autoconfiguration exploits several other new features in IPv6, including link-local

addresses, multicasting, the Neighbor Discovery (ND) protocol, and the ability to generate

the interface identifier of an address from the underlying data link layer address. The

general idea is to have a device generate a temporary address until it can determine the

characteristics of the network it is on, and then create a permanent address it can use

based on that information. In the case of multi-homed devices, autoconfiguration is

performed for each interface separately, as you would expect.

The following is a summary of the steps a device takes when using stateless

autoconfiguration:

1. Link-Local Address Generation: The device generates a link-local address. Recall

that this is one of the two types of local-use IPv6 addresses. Link-local addresses

have “1111 1110 10” for the first ten bits. The generated address uses those ten bits

followed by 54 zeroes and then the 64 bit interface identifier. Typically this will be

derived from the data link layer (MAC) address as explained in the topic on interface

identifiers, or it may be a “token” generated in some other manner.

2. Link-Local Address Uniqueness Test: The node tests to ensure that the address it

generated isn't for some reason already in use on the local network. (This is very

unlikely to be an issue if the link-local address came from a MAC address but more

likely if it was based on a generated token.) It sends a Neighbor Solicitation message

using the Neighbor Discovery (ND) protocol. It then listens for a Neighbor Adver-

tisement in response that indicates that another device is already using its link-local

address; if so, either a new address must be generated, or autoconfiguration fails and

another method must be employed.

3. Link-Local Address Assignment: Assuming the uniqueness test passes, the device

assigns the link-local address to its IP interface. This address can be used for commu-

nication on the local network, but not on the wider Internet (since link-local addresses

are not routed).

4. Router Contact: The node next attempts to contact a local router for more information

on continuing the configuration. This is done either by listening for Router Adver-

tisement messages sent periodically by routers, or by sending a specific Router

Solicitation to ask a router for information on what to do next. This process is

described in the section on the IPv6 Neighbor Discovery protocol.

5. Router Direction: The router provides direction to the node on how to proceed with

the autoconfiguration. It may tell the node that on this network “stateful” autoconfigu-

ration is in use, and tell it the address of a DHCP server to use. Alternately, it will tell

the host how to determine its global Internet address.

6. Global Address Configuration: Assuming that stateless autoconfiguration is in use

on the network, the host will configure itself with its globally-unique Internet address.

This address is generally formed from a network prefix provided to the host by the

router, combined with the device's identifier as generated in the first step.

Clearly, this method has numerous advantages over both manual and server-based config-

uration. It is particularly helpful in supporting mobility of IP devices, as they can move to

new networks and get a valid address without any knowledge of local servers or network

prefixes. At the same time, it still allows management of IP addresses using the (IPv6-

compatible) version of DHCP if that is desired. Routers on the local network will typically tell

hosts which type of autoconfiguration is supported using special flags in ICMPv6 Router

Advertisement messages.

Key Concept: IPv6 includes an interesting feature called stateless address autocon-

figuration, which allows a host to actually determine its own IPv6 address from its

layer two address by following a special procedure.

IPv6 Device Renumbering

Renumbering of devices is a method related to autoconfiguration. Like host configuration, it

can be implemented using protocols like DHCP, through the use of IP address “leases” that

expire after a period of time. Under IPv6, networks can be renumbered by having routers

specify an expiration interval for network prefixes when autoconfiguration is done. Later,

they can send a new prefix to tell devices to regenerate their IP addresses. Devices can

actually maintain the old “deprecated” address for a while and then move over to the new

address.

A similar technique was also defined for renumbering router addresses, in RFC 2894. It

uses special ICMPv6 messages and is described in a topic in that section.

IPv6 Datagram Encapsulation and Formatting

Delivery of data over IPv6 internetworks is accomplished by encapsulating higher-layer

data into IPv6 datagrams. These serve the same general purpose for IPv6 as IPv4

datagrams do in the older version of the protocol. However, they have been redesigned as

part of the overall changes represented by IPv6. IPv6 datagrams have a flexible structure

and their format better matches the needs of current IP networks.

In this section I take a look at the format used for IPv6 datagrams. I begin with an overview

of the general structure of IPv6 datagrams, describing the major changes and showing how

main and extension headers are arranged in the datagram. I then describe the format of the

main header, and define and describe the various extension header types. I conclude with a

brief explanation of IPv6 options and how they are implemented.

Background Information: This section assumes basic understanding of IPv6

addressing concepts, and also general familiarity with the IPv4 datagram format.

IPv6 Datagram Overview and General Structure

The method by which IPv6 encapsulates data received from higher-layer protocols for

transmission across the internetwork is basically the same as that used by IPv4. The data

received from the transport or higher layers is made the payload of an IPv6 datagram,

which has one or more headers that control the delivery of the message. These headers

provide information to routers to enable them to move the datagram across the network,

and also to hosts so they can tell which datagrams they are intended to receive.

Overview of Major Changes to Datagram Structure and Fields in IPv6

While the basic use of datagrams hasn't changed since IPv4, many modifications were

made to their structure and format when IPv6 was created. This was done partly out of

necessity: IPv6 addresses are different than IPv4 addresses and IP addresses go in the

datagram header. The increase in the size of IP addresses from 32 bits to 128 bits adds a

whopping extra 192 bits, or 24 bytes of information to the header. This in turn led to an effort

to remove fields that weren't strictly necessary, to compensate for the necessary increase in

size. However, changes were also made to IPv6 datagrams to add features to them and to

make them better suit the needs of modern internetworking.

The following is a list of the most significant overall changes to datagrams in IPv6:

☯ Multiple Header Structure: Rather than a single header that contains all fields for the

datagram (possibly including options), the IPv6 datagram supports a “main” header

and then extension headers for additional information when needed.

☯ Streamlined Header Format: Several fields have been removed from the main

header to reduce its size and increase efficiency. Only the fields that are truly required

for pretty much all datagrams remain in the main header; others are put into extension

headers and used as needed. Some were removed because they were no longer

needed, such as the Internet Header Length field; the IPv6 header is of fixed length.

This is discussed more thoroughly in the topic on the main IPv6 header.

☯ Renamed Fields: Some fields have been renamed to better reflect their actual use in

modern networks.

☯ Greater Flexibility: The extension headers allow a great deal of extra information to

accompany datagrams when needed. Options are also supported in IPv6.

☯ Elimination of Checksum Calculation: In IPv6, a checksum is no longer computed

on the header. This saves both the calculation time spent by every device that

packages IP datagrams (hosts and routers) and the space the checksum field took up

in the IPv4 header.

☯ Improved Quality of Service Support: A new field, the Flow Label, is defined to help

support the prioritization of traffic.

Key Concept: IPv6 datagrams use a general structure that begins with a mandatory

main header 40 bytes in length, followed by optional extension headers and then a

variable-length Data area. This structure was created to allow the main header to be

streamlined while allowing devices to add extra information to datagrams when needed.

IPv6 General Datagram Structure

As I mentioned above, IPv6 datagrams now includes a main header format (which has no

official name in the standards, it's just “the header”) and zero or more extension headers.

The overall structure therefore is as shown in Table 68 and Figure 104.

Note that as with IPv4, large payloads may be fragmented prior to encapsulation, to ensure

that the total size of the datagram doesn't exceed the maximum size permitted on an under-

lying network. However, the details of fragmentation in IPv6 are different than in IPv4.

Table 68: IPv6 General Datagram Structure

Component

Number of

Components

Per Datagram

Size

(bytes)

Description

Main Header 140

Contains the source and destination addresses, and

important information required for every datagram.

Extension

Headers

0 or more Variable

Each contains one type of extra information to support

various features, including fragmentation, source routing,

security and options.

Data 1 Variable

The payload from the upper layer to be transmitted in the

datagram.

IPv6 Datagram Main Header Format

As we saw in the previous topic, IPv6 datagrams use a structure that includes a regular

header and optionally, one or more extension headers. This regular header is like the

header of IPv4 datagrams, though it has a different format, as we will see shortly. The

standards don't give this header a name; it is just “the IPv6 header”. To differentiate it from

IPv6 extension headers, I call it the main header.

Main Header Format

The IPv6 main header is required for every datagram. It contains addressing and control

information that are used to manage the processing and routing of the datagram. The main

header format of IPv6 datagrams is described in Table 69 and illustrated in Figure 105.

Figure 104: IPv6 General Datagram Structure

Table 69: IPv6 Main Header Format (Page 1 of 2)

Field Name

Size

(bytes)

Description

Version

1/2

(4 bits)

Version: Identifies the version of IP used to generate the datagram. This

field is used the same way as in IPv4, except of course that it carries the

value 6 (0110 binary).

Traffic Class 1

Traffic Class: This field replaces the Type Of Service (TOS) field in the

IPv4 header. It is used not in the original way that the TOS field was

defined (with Precedence, D, T and R bits) but using the new Differentiated

Services (DS) method defined in RFC 2474. That RFC actually specifies

quality of service (QOS) techniques for both IPv4 and IPv6; see the IPv4

format description for a bit more information.

Main Header (40 bytes)

Extension Header #1

Extension Header #2

Extension Header #N

Data

...

IPv6 Next Header Field

The Next Header field is one of the most important additions to the IPv6 datagram format.

When an IPv6 datagram uses extension headers, this field contains an identifier for the first

extension header, which in turn uses its own Next Header to point to the next header, and

so on. The last extension header then references the encapsulated higher-layer protocol—

Flow Label

2 1/2

(20 bits)

Flow Label: This large field was created to provide additional support for

real-time datagram delivery and quality of service features. The concept of

a flow is defined in RFC 2460 as a sequence of datagrams sent from a

source device to one or more destination devices. A unique flow label is

used to identify all the datagrams in a particular flow, so that routers

between the source and destination all handle them the same way, to help

ensure uniformity in how the datagrams in the flow are delivered. For

example, if a video stream is being sent across an IP internetwork, the

datagrams containing the stream could be identified with a flow label to

ensure that they are delivered with minimal latency.

Not all devices and routers may support flow label handling, and use of the

field by a source device is entirely optional. Also, the field is still somewhat

experimental and may be refined over time.

Payload Length 2

Payload Length: This field replaces the Total Length field from the IPv4

header, but it is used differently. Rather than measuring the length of the

whole datagram, it only contains the number of bytes of the payload.

However, if extension headers are included, their length is counted here as

well.

In simpler terms, this field measures the length of the datagram less the 40

bytes of the main header itself.

Next Header 1

Next Header: This field replaces the Protocol field and has two uses.

When a datagram has extension headers, this field specifies the identity of

the first extension header, which is the next header in the datagram. When

a datagram has just this “main” header and no extension headers, it serves

the same purpose as the old IPv4 Protocol field and has the same values,

though new numbers are used for IPv6 versions of common protocols. In

this case the “next header” is the header of the upper layer message the

IPv6 datagram is carrying. See below for more details.

Hop Limit 1

Hop Limit: This replaces the Time To Live (TTL) field in the IPv4 header;

its name better reflects the way that TTL is used in modern networks (since

TTL is really used to count hops, not time.)

Source Address 16

Source Address: The 128-bit IP address of the originator of the datagram.

As with IPv4, this is always the device that originally sent the datagram.

Destination

Address

Destination Address: The 128-bit IP address of the intended recipient of

the datagram; unicast, anycast or multicast. Again, even though devices

such as routers may be the intermediate targets of the datagram, this field

is always for the ultimate destination.

Table 69: IPv6 Main Header Format (Page 2 of 2)

Field Name

Size

(bytes)

Description

since the higher-layer protocol’s header appears at the start of the IPv6 Data field, it is like

the “next header” to the device receiving the datagram. For some folks this is a bit tough to

see conceptually; much more detail on how the field works (including a useful illustration)

can be found in the next topic, describing extension headers. Some of the most common

values for Next Header in IPv6 are shown in Table 70.

Figure 105: IPv6 Main Header Format

Table 70: Common IPv6 Next Header Values (Page 1 of 2)

Value

(Hexadecimal)

Value

(Decimal)

Protocol / Extension Header

00 0

Hop-By-Hop Options Extension Header

(note that this value was “Reserved” in IPv4)

01 1 ICMPv4

02 2 IGMPv4

04 4 IP in IP Encapsulation

06 6 TCP

08 8 EGP

11 17 UDP

29 41 IPv6

Version Traffic Class Flow Label

Payload Length Next Header Hop Limit

Source Address

(128 bits)

Destination Address

(128 bits)

4 8 12 16 20 24 28 320

The total length of the main IPv6 header format is 40 bytes. This is double the size of the

IPv4 header without options, largely because of the extra 24 bytes needed for the

monstrous IPv6 addresses. There are only 8 bytes of non-address header fields in the IPv6

main header, compared to 12 in the IPv4 header.

Key Changes to Main Header Between IPv4 and IPv6

To summarize, the IPv6 main header compares to the IPv4 header as follows:

☯ Unchanged Fields: Three fields are used the same way and retain the same name

(though they have different content and/or size): Version, Source Address and Desti-

nation Address.

☯ Renamed Fields: Two fields are used the same way but renamed: Traffic Class and

Hop Limit.

☯ Modified Fields: Two fields are used in a way similar way to their IPv4 predecessors

but are slightly different in meaning and also renamed: Payload Length and Next

Header.

☯ Added Fields: There is one new field: Flow Label.

☯ Removed Fields: To cut down on header length and unnecessary work, five IPv4

header fields are removed from the IPv6 header:

☯ Internet Header Length: No longer needed, as the main IPv6 header is fixed in

length at 40 bytes.

☯ Identification, Flags, Fragment Offset: These are used for fragmentation,

which is done less in IPv6 than IPv4, so these fields are now found only when

needed in the Fragmentation extension header.

☯ Header Checksum: The decision was made to eliminate header checksum cal-

culations in IPv6. It was viewed as redundant with higher-layer error-checking

and data link layer CRC calculations. This saves processing time for routers and

2 bytes in the datagram header.

In addition, while options were formerly considered part of the main header in IPv4, they are

separate in IPv6.

2B 43 Routing Extension Header

2C 44 Fragmentation Extension Header

2E 46 Resource Reservation Protocol (RSVP)

32 50 Encrypted Security Payload (ESP) Extension Header

33 51 Authentication Header (AH) Extension Header

3A 58 ICMPv6

3B 59 No Next Header

3C 60 Destination Options Extension Header

Table 70: Common IPv6 Next Header Values (Page 2 of 2)

Value

(Hexadecimal)

Value

(Decimal)

Protocol / Extension Header