Charles M. Kozierok The TCP-IP Guide

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

IPv6 Datagram Extension Headers

After the mandatory “main” header in an IPv6 datagram, one or more extension headers

may appear before the encapsulated payload. These headers were created in an attempt to

provide both flexibility and efficiency in the creation of IPv6 datagrams. All fields that are

needed only for special purposes are put into extension headers and placed in the

datagram when needed. This allows the size of the main datagram header to be made

small and streamlined, containing only those fields that really must be present all the time.

There is often confusion regarding the role of extension headers, especially compared to

datagram options. The IPv4 datagram had only one header, but it included a provision for

options, and IPv6 also has options, so why bother with extension headers? Good question.

It would have been possible to do everything using options. However, it was deemed a

better design to employ extension headers for certain sets of information that are needed

for common functions such as fragmenting. Options are indeed still supported in IPv6; they

are used to provide even more flexibility by providing variable-length fields that can be used

for any purpose. They are themselves defined using extension headers as we will see

below (and in their own topic, which follows.)

When extension headers are included in an IPv6 datagram, they appear one after the other

following the main header. Each extension header type has its own internal structure of

fields.

IPv6 Header Chaining Using the Next Header Field

The only field common to all extension header types is the Next Header field (which actually

appears at the end of one header type, the ESP header). The 8-bit Next Header field is

used to logically link all the headers in an IPv6 datagram as follows:

☯ The Next Header field in the main header contains a reference number for the first

extension header type.

☯ The Next Header field in the first extension header contains the number of the second

extension header type, if there is a second one. If there's a third, the second header's

Next Header points to it, and so on.

☯ The Next Header field of the last extension header contains the protocol number of the

encapsulated higher-layer protocol. In essence, this field points to the “next header”

within the payload itself.

For example, suppose a datagram that encapsulates TCP has a Hop-By-Hop Options

extension header and a Fragment extension header. Then, the Next Header fields of these

headers would contain the following values:

☯ The main header would have a Next Header value of 0, indicating the Hop-By-Hop

Options header.

☯ The Hop-By-Hop Options header would have a Next Header value of 44 (decimal), the

value for the Fragment extension header.

☯ The Fragment header would have a Next Header value of 6.

This is illustrated in Figure 106.

Key Concept: The IPv6 Next Header field is used to “chain together” the headers in

an IPv6 datagram. The Next Header field in the main header contains the number of

the first extension header; its Next Header contains the number of the second, and

so forth. The last header in the datagram contains the number of the encapsulated protocol

that begins the Data field.

Figure 106: IPv6 Extension Header Linking Using the Next Header Field

The Next Header field allows a device to more easily process the headers in a received IPv6 datagram. When

a datagram has no extension headers, the “next header” is actually the header at the start of the IP Data field,

in this case a TCP header with a value of 6. This is the same way the Protocol field is used in IPv4. When

extension headers do appear, the Next Header value of each header contains a number indicating the type of

the following header in the datagram, so they logically “chain together” the headers, as shown above.

IP Header

Hop-by-Hop

Options Header

Fragment

Header

IP Data

TCP

Header

TCP Segment Data

IP Header IP Data

TCP

Header

TCP Segment Data

IPv6 Datagram With No Extension Headers Carrying TCP Segment

IPv6 Datagram With Two Extension Headers Carrying TCP Segment

Next Header

Summary of IPv6 Extension Headers

Table 71 lists the different extension headers, showing its Next Header value, length and

defining RFC, and providing a brief description of how each is used.

Table 71: IPv6 Extension Headers

Header

Value

(decimal)

Extension

Header Name

Length

(bytes)

Description

Defining

RFC

Hop-By-Hop

Options

Variable

Defines an arbitrary set of options that are

intended to be examined by all devices on the path

from the source to destination device(s).

This is one of two extension headers used to

define variable-format options.

2460

43 Routing Variable

Defines a method for allowing a source device to

specify the route for a datagram. This header type

actually allows the definition of multiple routing

types. The IPv6 standard defines the Type 0

Routing extension header, which is equivalent to

the “loose” source routing option in IPv4 and used

in a similar way.

See below for the format of this extension header.

2460

44 Fragment 8

When a datagram contains only a fragment of the

original message, this extension header is

included. It contains the Fragment Offset, Identifi-

cation and More Fragment fields that were

removed from the main header.

See below for the format of this extension header,

and the topic on fragmentation and reassembly for

details on how the fields are used.

2460

Encapsulating

Security

Payload (ESP)

Variable

Carries encrypted data for secure communica-

tions. This header is described in detail in the

section on IPSec.

2406

Authentication

Header (AH)

Variable

Contains information used to verify the authenticity

of encrypted data. This header is described in

detail in the section on IPSec.

2402

Destination

Options

Variable

Defines an arbitrary set of options that are

intended to be examined only by the destination(s)

of the datagram.

This is one of two extension headers used to

define variable-format options.

2460

Note that the Next Header value of the IPv6 main header is 41; that of an IPv4 header is 4

(its protocol number). Note that there is also a “dummy” extension header called No Next

Header that has a value of 59. This is a placeholder that when found in the Next Header

field indicates that there is nothing after that extension header.

As I mentioned in the table, the formats for several of the headers are provided in other

topics. Two of them I will describe here, however.

IPv6 Routing Extension Header

The Routing extension header is used to perform source routing in IPv6. It is described in

Table 72, and illustrated in Figure 107.

Table 72: IPv6 Routing Extension Header Format

Field Name

Size

(bytes)

Description

Next Header 1

Next Header: Contains the protocol number of the next header after the

Routing header. Used to link headers together as described above.

Hdr Ext Len 1

Header Extension Length: The length of the Routing header in 8-byte

units, not including the first 8 bytes of the header. For a Routing Type of 0,

this value is thus two times the number addresses embedded in the

header.

Routing Type 1

Routing Type: This field allows multiple routing types to be defined; at

present, the only value used is 0.

Segments Left 1

Segments Left: Specifies the number of explicitly-named nodes remaining

in the route until the destination.

Reserved 4 Reserved: Not used; set to zeroes.

Address1 …

AddressN

Variable

(multiple

of 16)

Addresses: A set of IPv6 addresses that specify the route to be used.

IPv6 Fragment Extension Header

The Fragment extension header is included in fragmented datagrams to provide the infor-

mation necessary to allow the fragments to be reassembled. Its format can be found in

Table 73 and Figure 108.

Figure 107: IPv6 Routing Extension Header Format

Table 73: IPv6 Fragment Extension Header Format (Page 1 of 2)

Field Name

Size

(bytes)

Description

Next Header 1

Next Header: Contains the protocol number of the next header after the

Fragment header. Used to link headers together as described above.

Reserved 1 Reserved: Not used; set to zeroes.

Fragment Offset

13/8 (13

bits)

Fragment Offset: Specifies the offset, or position, in the overall message

where the data in this fragment goes. It is specified in units of 8 bytes (64

bits) and used in a manner very similar to the field of the same name in the

IPv4 header.

Next Header

Header Extension

Length

Routing Type (=0) Segments Left

Reserved

Address1

(128 bits)

AddressN

(128 bits)

4 8 12 16 20 24 28 320

...

IPv6 Extension Header Order

Each extension header appears only once in any datagram (with one exception; see

below). Also, extension headers are only examined by the final recipients of the datagram,

not intermediate devices (again with one exception, which we will get to momentarily). RFC

2460 specifies that when multiple headers appear, they should be in the following order

after the main header and before the higher-layer encapsulated header in the IPv6

datagram payload:

1. Hop-By-Hop Options

2. Destination Options (for options to be processed by the destination as well as devices

specified in a Routing header)

3. Routing

4. Fragmentation

Res

1/4 (2

bits)

Reserved: Not used; set to zeroes.

M Flag 1/8 (1 bit)

More Fragments Flag: Same as the flag of the same name in the IPv4

header—when set to 0, indicates the last fragment in a message; when set

to 1, indicates that more fragments are yet to come in the fragmented

message.

Identification 4

Identification: Same as the field of the same name in the IPv4 header, but

expanded to 32 bits. It contains a specific value that is common to each of

the fragments belonging to a particular message, to ensure that pieces

from different fragmented messages are not mixed together.

Figure 108: IPv6 Fragment Extension Header Format

Table 73: IPv6 Fragment Extension Header Format (Page 2 of 2)

Field Name

Size

(bytes)

Description

Next Header Reserved Fragment Offset Res

Identification

4 8 12 16 20 24 28 320

0 123

Reserved

Frag-

ments

5. Authentication Header

6. Encapsulating Security Payload

7. Destination Options (for options processed only by the final destination)

Now let's look at those exceptions. The only header that can appear twice is Destination

Options. Normally, it appears as the last header. However, a Destination Options header

may exist that contain options that must be examined by a list of devices specified in a

source route, in addition to the destination. In this case, the Destination Options header for

these options is placed before the Routing header. A second such header containing

options only for the final destination may also appear.

Key Concept: Each extension header may appear only once in an IPv6 datagram,

and they must appear in a fixed order. The exception is the Destination Options

header, which may appear twice; near the start of the datagram for options to be

processed by devices en route to the destination, and at the end of the extension headers

for options intended only for the final destination.

The only header normally examined by all intermediate devices is the Hop-By-Hop Options

extension header. It is used specifically to convey management information to all routers in

a route. The Hop-By-Hop Options extension header must appear as the first extension

header if present. Since it is the only one that must be read by every router (which repre-

sents a performance drain on routers) it is given “top billing” to make it easier and faster to

find and process.

Finally, note that all extension headers must be a multiple of 8 bytes in length for alignment

purposes. Also, remember that the Next Header value for a particular extension header

appears in the Next Header field of the preceding header, not the header itself.

IPv6 Datagram Options

In IPv4, all “extra” information required for various purposes is placed into the datagram in

the form of options that appear in the IPv4 header. In IPv6, the new concept of extension

headers is introduced; these headers take the place of many of the predefined IPv4

options. However, the concept of options is still maintained in IPv6, for a slightly different

purpose. Options allow the IPv6 datagram to be supplemented with arbitrary sets of infor-

mation that aren't defined in the regular extension headers. They provide maximum

flexibility, allowing the basic IPv6 protocol to be extended in ways the designers never antic-

ipated, with the goal of reducing the chances of the protocol becoming obsolete.

IPv6 Option Extension Header Types

I said that IPv6 options supplement extension headers; in fact, they are actually imple-

mented as extension headers. There are two different ones used to encode options. These

two headers only differ in terms of how the options they contain are to be processed by

devices; otherwise, they are formatted the same and used in the same way.

The two extension header types are:

☯ Destination Options: Contains options that are intended only for the ultimate desti-

nation of the datagram (and perhaps a set of routers specified in a Routing header, if

present).

☯ Hop-By-Hop Options: Contains options that carry information for every device

(router) between the source and destination

IPv6 Option Format

Each of these header types has a one-byte Next Header field, and a one-byte Header

Extension Length field that indicates the header’s overall length. The rest of the header has

one or more option fields. Figure 109 illustrates the overall format of these two headers.

The format of each option is similar to that of IPv4 options, and is shown in Table 74.

Table 74: IPv6 Option Format (Page 1 of 2)

Subfield Name

Size

(bytes)

Description

Option Type 1

ype:

Thi

ype o

on.

bit

s are

erpre

according to the following “sub-subfield” structure:

Sub-Subfield

Name

Size

(bytes)

Description

Unrecognized

Option Action

2/8

(2 bits)

Option

Change

Allowed Flag

1/8

(1 bit)

Set to 1 if the Option Data can change while the

datagram is en route, or left at 0 if it cannot.

Remainder of

Option Type

5/8

(5 bits)

Five remaining bits that allow the specification of

32 different combinations for each combination of

the three bits above.

bit

s spec

y w

on s

taken if the device processing the option doesn't

recognize the Option Type. The four values are:

Value Action on Unrecognized Option

00 Skip option; process rest of header.

01 Discard datagram; do nothing else.

Discard datagram and send an ICMP

Parameter Problem message with

code 2 back to the datagram source.

Discard datagram and send the

above ICMP message, only if desti-

nation was not a multicast address.

Opt Data Len 1

Option Data Length: Specifies the length of the Option Data subfield

below. Note that this is a change in semantics from IPv4, where the length

field indicated the size of the entire option; in IPv6 the length of the Option

Type and Option Data Length fields are not included.

Option Data Variable

Option Data: The data to be sent as part of the option, which is specific to

the option type. Also sometimes referred to as the Option Value.

Figure 109: IPv6 Hop-By-Hop Options and Destination Options Header Formats

Each of these extension headers begins with two fixed fields, Next Header and Header Extension Length. The

rest of the header consists of a sequence of variable-length options. Each option has the structure shown in

Table 74, consisting of a type / length / value triplet.

Table 74: IPv6 Option Format (Page 2 of 2)

Subfield Name

Size

(bytes)

Description

4 8 12 16 20 24 28 320

Next Header

Header Extension

Length

...

Option #N Data

Option #1 Type Option #1 Data Length

Option #1 Data

Option #2 Type Option #2 Data Length

Option #2 Data

Option #N Type

240

Option #N Data Length

Unrecognized

Option Action

Option

Change

Allow ed

Remainder of Option Type

Note: The Option Type subfield is a bit strange in terms of how it is interpreted.

Even though it has a substructure with three sub-subfields as shown in Table 74,

that structure is “informal”. What I mean by this is that the 8 bits of this field are

taken as a single entity. Despite the special meaning of the three highest-order bits, the

entire field is called the Option Type, not just the last five bits, and the whole is used as a

single value from 0 to 255. In fact, the “sub-subfield” names aren't even specified in the

standard; I made them up to help explain these fields.

Since each option has a subfield for type, length and value (data), they are sometimes said

to be TLV-encoded. If there are multiple options, they are placed one after each other in the

header. At the end of all the options in a Hop-By-Hop Options or Destination Options

extension header, padding may be placed to ensure that the header is a multiple of 8 bytes

in length.

Key Concept: Two IPv6 extension header types, Hop-By-Hop Options and Desti-

nation Options, are used to carry arbitrary optional information in IPv6 datagrams.

Each consists of a set of variable-length options that are defined using three

subfields indicating the option’s type, length and value.