idnits 2.17.1 draft-ietf-ipngwg-ipv6-spec-v2-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1016 has weird spacing: '... one or more ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 748 -- Looks like a reference, but probably isn't: '2' on line 749 -- Looks like a reference, but probably isn't: '3' on line 750 == Unused Reference: 'RFC-1700' is defined on line 1520, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. 'ICMPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDRARCH' ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1548 (ref. 'RFC-1661') (Obsoleted by RFC 1661) Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Deering, Cisco Systems 2 November 21, 1997 R. Hinden, Ipsilon Networks 4 Internet Protocol, Version 6 (IPv6) 5 Specification 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 22 Please check the 1id-abstracts.txt listing contained in the internet- 23 drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 24 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 25 current status of any Internet Draft. 27 This internet draft will expire no later than May 31, 1998. 29 Abstract 31 This document specifies version 6 of the Internet Protocol (IPv6), 32 also sometimes referred to as IP Next Generation or IPng. 34 Table of Contents 36 Status of this Memo..............................................1 38 1. Introduction..................................................3 40 2. Terminology...................................................4 42 3. IPv6 Header Format............................................5 44 4. IPv6 Extension Headers........................................6 45 4.1 Extension Header Order...................................8 46 4.2 Options..................................................9 47 4.3 Hop-by-Hop Options Header...............................11 48 4.4 Routing Header..........................................13 49 4.5 Fragment Header.........................................19 50 4.6 Destination Options Header..............................24 51 4.7 No Next Header..........................................25 53 5. Packet Size Issues...........................................26 55 6. Flow Labels..................................................28 57 7. Traffic Classes..............................................30 59 8. Upper-Layer Protocol Issues..................................31 60 8.1 Upper-Layer Checksums...................................31 61 8.2 Maximum Packet Lifetime.................................32 62 8.3 Maximum Upper-Layer Payload Size........................32 63 8.4 Responding to Packets Carrying Routing Headers..........33 65 Appendix A. Formatting Guidelines for Options...................34 67 Security Considerations.........................................37 69 Acknowledgments.................................................37 71 Authors' Addresses..............................................37 73 References......................................................38 75 Changes Since RFC-1883..........................................39 77 1. Introduction 79 IP version 6 (IPv6) is a new version of the Internet Protocol, 80 designed as the successor to IP version 4 (IPv4) [RFC-791]. The 81 changes from IPv4 to IPv6 fall primarily into the following 82 categories: 84 o Expanded Addressing Capabilities 86 IPv6 increases the IP address size from 32 bits to 128 bits, to 87 support more levels of addressing hierarchy, a much greater 88 number of addressable nodes, and simpler auto-configuration of 89 addresses. The scalability of multicast routing is improved by 90 adding a "scope" field to multicast addresses. And a new type 91 of address called an "anycast address" is defined, used to send 92 a packet to any one of a group of nodes. 94 o Header Format Simplification 96 Some IPv4 header fields have been dropped or made optional, to 97 reduce the common-case processing cost of packet handling and 98 to limit the bandwidth cost of the IPv6 header. 100 o Improved Support for Extensions and Options 102 Changes in the way IP header options are encoded allows for 103 more efficient forwarding, less stringent limits on the length 104 of options, and greater flexibility for introducing new options 105 in the future. 107 o Flow Labeling Capability 109 A new capability is added to enable the labeling of packets 110 belonging to particular traffic "flows" for which the sender 111 requests special handling, such as non-default quality of 112 service or "real-time" service. 114 o Authentication and Privacy Capabilities 116 Extensions to support authentication, data integrity, and 117 (optional) data confidentiality are specified for IPv6. 119 This document specifies the basic IPv6 header and the initially- 120 defined IPv6 extension headers and options. It also discusses packet 121 size issues, the semantics of flow labels and traffic classes, and 122 the effects of IPv6 on upper-layer protocols. The format and 123 semantics of IPv6 addresses are specified separately in [ADDRARCH]. 124 The IPv6 version of ICMP, which all IPv6 implementations are required 125 to include, is specified in [ICMPv6]. 127 2. Terminology 129 node - a device that implements IPv6. 131 router - a node that forwards IPv6 packets not explicitly 132 addressed to itself. [See Note below]. 134 host - any node that is not a router. [See Note below]. 136 upper layer - a protocol layer immediately above IPv6. Examples are 137 transport protocols such as TCP and UDP, control 138 protocols such as ICMP, routing protocols such as OSPF, 139 and internet or lower-layer protocols being "tunneled" 140 over (i.e., encapsulated in) IPv6 such as IPX, 141 AppleTalk, or IPv6 itself. 143 link - a communication facility or medium over which nodes can 144 communicate at the link layer, i.e., the layer 145 immediately below IPv6. Examples are Ethernets (simple 146 or bridged); PPP links; X.25, Frame Relay, or ATM 147 networks; and internet (or higher) layer "tunnels", 148 such as tunnels over IPv4 or IPv6 itself. 150 neighbors - nodes attached to the same link. 152 interface - a node's attachment to a link. 154 address - an IPv6-layer identifier for an interface or a set of 155 interfaces. 157 packet - an IPv6 header plus payload. 159 link MTU - the maximum transmission unit, i.e., maximum packet 160 size in octets, that can be conveyed over a link. 162 path MTU - the minimum link MTU of all the links in a path between 163 a source node and a destination node. 165 Note: it is possible, though unusual, for a device with multiple 166 interfaces to be configured to forward non-self-destined packets 167 arriving from some set (fewer than all) of its interfaces, and to 168 discard non-self-destined packets arriving from its other interfaces. 169 Such a device must obey the protocol requirements for routers when 170 receiving packets from, and interacting with neighbors over, the 171 former (forwarding) interfaces. It must obey the protocol 172 requirements for hosts when receiving packets from, and interacting 173 with neighbors over, the latter (non-forwarding) interfaces. 175 3. IPv6 Header Format 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 |Version| Traffic Class | Flow Label | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Payload Length | Next Header | Hop Limit | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | | 183 + + 184 | | 185 + Source Address + 186 | | 187 + + 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 + + 192 | | 193 + Destination Address + 194 | | 195 + + 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Version 4-bit Internet Protocol version number = 6. 201 Traffic Class 8-bit traffic class field. See section 7. 203 Flow Label 20-bit flow label. See section 6. 205 Payload Length 16-bit unsigned integer. Length of the IPv6 206 payload, i.e., the rest of the packet 207 following this IPv6 header, in octets. 208 (Note that any extension headers [section 4] 209 present are considered part of the payload, 210 i.e., included in the length count.) 211 If this field is zero, it indicates that the 212 payload length is carried in a Jumbo Payload 213 hop-by-hop option. 215 Next Header 8-bit selector. Identifies the type of header 216 immediately following the IPv6 header. Uses 217 the same values as the IPv4 Protocol field 218 [RFC-1700 et seq.]. 220 Hop Limit 8-bit unsigned integer. Decremented by 1 by 221 each node that forwards the packet. The packet 222 is discarded if Hop Limit is decremented to 223 zero. 225 Source Address 128-bit address of the originator of the 226 packet. See [ADDRARCH]. 228 Destination Address 128-bit address of the intended recipient 229 of the packet (possibly not the ultimate 230 recipient, if a Routing header is present). 231 See [ADDRARCH] and section 4.4. 233 4. IPv6 Extension Headers 235 In IPv6, optional internet-layer information is encoded in separate 236 headers that may be placed between the IPv6 header and the upper- 237 layer header in a packet. There are a small number of such extension 238 headers, each identified by a distinct Next Header value. As 239 illustrated in these examples, an IPv6 packet may carry zero, one, or 240 more extension headers, each identified by the Next Header field of 241 the preceding header: 243 +---------------+------------------------ 244 | IPv6 header | TCP header + data 245 | | 246 | Next Header = | 247 | TCP | 248 +---------------+------------------------ 250 +---------------+----------------+------------------------ 251 | IPv6 header | Routing header | TCP header + data 252 | | | 253 | Next Header = | Next Header = | 254 | Routing | TCP | 255 +---------------+----------------+------------------------ 257 +---------------+----------------+-----------------+----------------- 258 | IPv6 header | Routing header | Fragment header | fragment of TCP 259 | | | | header + data 260 | Next Header = | Next Header = | Next Header = | 261 | Routing | Fragment | TCP | 262 +---------------+----------------+-----------------+----------------- 264 With one exception, extension headers are not examined or processed 265 by any node along a packet's delivery path, until the packet reaches 266 the node (or each of the set of nodes, in the case of multicast) 267 identified in the Destination Address field of the IPv6 header. 268 There, normal demultiplexing on the Next Header field of the IPv6 269 header invokes the module to process the first extension header, or 270 the upper-layer header if no extension header is present. The 271 contents and semantics of each extension header determine whether or 272 not to proceed to the next header. Therefore, extension headers must 273 be processed strictly in the order they appear in the packet; a 274 receiver must not, for example, scan through a packet looking for a 275 particular kind of extension header and process that header prior to 276 processing all preceding ones. 278 The exception referred to in the preceding paragraph is the Hop-by- 279 Hop Options header, which carries information that must be examined 280 and processed by every node along a packet's delivery path, including 281 the source and destination nodes. The Hop-by-Hop Options header, 282 when present, must immediately follow the IPv6 header. Its presence 283 is indicated by the value zero in the Next Header field of the IPv6 284 header. 286 If, as a result of processing a header, a node is required to proceed 287 to the next header but the Next Header value in the current header is 288 unrecognized by the node, it should discard the packet and send an 289 ICMP Parameter Problem message to the source of the packet, with an 290 ICMP Code value of 1 ("unrecognized Next Header type encountered") 291 and the ICMP Pointer field containing the offset of the unrecognized 292 value within the original packet. The same action should be taken if 293 a node encounters a Next Header value of zero in any header other 294 than an IPv6 header. 296 Each extension header is an integer multiple of 8 octets long, in 297 order to retain 8-octet alignment for subsequent headers. Multi- 298 octet fields within each extension header are aligned on their 299 natural boundaries, i.e., fields of width n octets are placed at an 300 integer multiple of n octets from the start of the header, for n = 1, 301 2, 4, or 8. 303 A full implementation of IPv6 includes implementation of the 304 following extension headers: 306 Hop-by-Hop Options 307 Routing (Type 0) 308 Fragment 309 Destination Options 310 Authentication 311 Encapsulating Security Payload 313 The first four are specified in this document; the last two are 314 specified in [RFC-1826] and [RFC-1827], respectively. 316 4.1 Extension Header Order 318 When more than one extension header is used in the same packet, it is 319 recommended that those headers appear in the following order: 321 IPv6 header 322 Hop-by-Hop Options header 323 Destination Options header (note 1) 324 Routing header 325 Fragment header 326 Authentication header (note 2) 327 Encapsulating Security Payload header (note 2) 328 Destination Options header (note 3) 329 upper-layer header 331 note 1: for options to be processed by the first destination 332 that appears in the IPv6 Destination Address field 333 plus subsequent destinations listed in the Routing 334 header. 336 note 2: additional recommendations regarding the relative 337 order of the Authentication and Encapsulating 338 Security Payload headers are given in [RFC-1827]. 340 note 3: for options to be processed only by the final 341 destination of the packet. 343 Each extension header should occur at most once, except for the 344 Destination Options header which should occur at most twice (once 345 before a Routing header and once before the upper-layer header). 347 If the upper-layer header is another IPv6 header (in the case of IPv6 348 being tunneled over or encapsulated in IPv6), it may be followed by 349 its own extension headers, which are separately subject to the same 350 ordering recommendations. 352 If and when other extension headers are defined, their ordering 353 constraints relative to the above listed headers must be specified. 355 IPv6 nodes must accept and attempt to process extension headers in 356 any order and occurring any number of times in the same packet, 357 except for the Hop-by-Hop Options header which is restricted to 358 appear immediately after an IPv6 header only. Nonetheless, it is 359 strongly advised that sources of IPv6 packets adhere to the above 360 recommended order until and unless subsequent specifications revise 361 that recommendation. 363 4.2 Options 365 Two of the currently-defined extension headers -- the Hop-by-Hop 366 Options header and the Destination Options header -- carry a variable 367 number of type-length-value (TLV) encoded "options", of the following 368 format: 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 371 | Option Type | Opt Data Len | Option Data 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 374 Option Type 8-bit identifier of the type of option. 376 Opt Data Len 8-bit unsigned integer. Length of the Option 377 Data field of this option, in octets. 379 Option Data Variable-length field. Option-Type-specific 380 data. 382 The sequence of options within a header must be processed strictly in 383 the order they appear in the header; a receiver must not, for 384 example, scan through the header looking for a particular kind of 385 option and process that option prior to processing all preceding 386 ones. 388 The Option Type identifiers are internally encoded such that their 389 highest-order two bits specify the action that must be taken if the 390 processing IPv6 node does not recognize the Option Type: 392 00 - skip over this option and continue processing the header. 394 01 - discard the packet. 396 10 - discard the packet and, regardless of whether or not the 397 packet's Destination Address was a multicast address, send an 398 ICMP Parameter Problem, Code 2, message to the packet's 399 Source Address, pointing to the unrecognized Option Type. 401 11 - discard the packet and, only if the packet's Destination 402 Address was not a multicast address, send an ICMP Parameter 403 Problem, Code 2, message to the packet's Source Address, 404 pointing to the unrecognized Option Type. 406 The third-highest-order bit of the Option Type specifies whether or 407 not the Option Data of that option can change en-route to the 408 packet's final destination. When an Authentication header is present 409 in the packet, for any option whose data may change en-route, its 410 entire Option Data field must be treated as zero-valued octets when 411 computing or verifying the packet's authenticating value. 413 0 - Option Data does not change en-route 415 1 - Option Data may change en-route 417 The three high-order bits described above are to be treated as part 418 of the Option Type, not independent of the Option Type. That is, a 419 particular option is identified by a full 8-bit Option Type, not just 420 the low-order 5 bits of an Option Type. 422 The same Option Type numbering space is used for both the Hop-by-Hop 423 Options header and the Destination Options header. However, the 424 specification of a particular option may restrict its use to only one 425 of those two headers. 427 Individual options may have specific alignment requirements, to 428 ensure that multi-octet values within Option Data fields fall on 429 natural boundaries. The alignment requirement of an option is 430 specified using the notation xn+y, meaning the Option Type must 431 appear at an integer multiple of x octets from the start of the 432 header, plus y octets. For example: 434 2n means any 2-octet offset from the start of the header. 435 8n+2 means any 8-octet offset from the start of the header, 436 plus 2 octets. 438 There are two padding options which are used when necessary to align 439 subsequent options and to pad out the containing header to a multiple 440 of 8 octets in length. These padding options must be recognized by 441 all IPv6 implementations: 443 Pad1 option (alignment requirement: none) 445 +-+-+-+-+-+-+-+-+ 446 | 0 | 447 +-+-+-+-+-+-+-+-+ 449 NOTE! the format of the Pad1 option is a special case -- it does 450 not have length and value fields. 452 The Pad1 option is used to insert one octet of padding into the 453 Options area of a header. If more than one octet of padding is 454 required, the PadN option, described next, should be used, 455 rather than multiple Pad1 options. 457 PadN option (alignment requirement: none) 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 460 | 1 | Opt Data Len | Option Data 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 463 The PadN option is used to insert two or more octets of padding 464 into the Options area of a header. For N octets of padding, 465 the Opt Data Len field contains the value N-2, and the Option 466 Data consists of N-2 zero-valued octets. 468 Appendix A contains formatting guidelines for designing new options. 470 4.3 Hop-by-Hop Options Header 472 The Hop-by-Hop Options header is used to carry optional information 473 that must be examined by every node along a packet's delivery path. 474 The Hop-by-Hop Options header is identified by a Next Header value of 475 0 in the IPv6 header, and has the following format: 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Next Header | Hdr Ext Len | | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 480 | | 481 . . 482 . Options . 483 . . 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Next Header 8-bit selector. Identifies the type of header 488 immediately following the Hop-by-Hop Options 489 header. Uses the same values as the IPv4 490 Protocol field [RFC-1700 et seq.]. 492 Hdr Ext Len 8-bit unsigned integer. Length of the 493 Hop-by-Hop Options header in 8-octet units, 494 not including the first 8 octets. 496 Options Variable-length field, of length such that the 497 complete Hop-by-Hop Options header is an integer 498 multiple of 8 octets long. Contains one or 499 more TLV-encoded options, as described in 500 section 4.2. 502 In addition to the Pad1 and PadN options specified in section 4.2, 503 the following hop-by-hop option is defined: 505 Jumbo Payload option (alignment requirement: 4n + 2) 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | 194 |Opt Data Len=4 | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Jumbo Payload Length | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 The Jumbo Payload option is used to send IPv6 packets with 514 payloads longer than 65,535 octets. The Jumbo Payload Length is 515 the length of the packet in octets, excluding the IPv6 header but 516 including the Hop-by-Hop Options header and any other extension 517 headers present; it must be greater than 65,535. If a packet is 518 received with a Jumbo Payload option containing a Jumbo Payload 519 Length less than or equal to 65,535, an ICMP Parameter Problem 520 message, Code 0, should be sent to the packet's source, pointing 521 to the high-order octet of the invalid Jumbo Payload Length field. 523 The Payload Length field in the IPv6 header must be set to zero 524 in every packet that carries the Jumbo Payload option. If a 525 packet is received with a valid Jumbo Payload option present and 526 a non-zero IPv6 Payload Length field, an ICMP Parameter Problem 527 message, Code 0, should be sent to the packet's source, pointing 528 to the Option Type field of the Jumbo Payload option. 530 The Jumbo Payload option must not be used in a packet that 531 carries a Fragment header. If a Fragment header is encountered 532 in a packet that contains a valid Jumbo Payload option, an ICMP 533 Parameter Problem message, Code 0, should be sent to the packet's 534 source, pointing to the first octet of the Fragment header. 536 An implementation that does not support the Jumbo Payload option 537 cannot have interfaces to links whose link MTU is greater than 538 65,575 (40 octets of IPv6 header plus 65,535 octets of payload). 540 4.4 Routing Header 542 The Routing header is used by an IPv6 source to list one or more 543 intermediate nodes to be "visited" on the way to a packet's 544 destination. This function is very similar to IPv4's Loose Source 545 and Record Route option. The Routing header is identified by a Next 546 Header value of 43 in the immediately preceding header, and has the 547 following format: 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | | 553 . . 554 . type-specific data . 555 . . 556 | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Next Header 8-bit selector. Identifies the type of header 560 immediately following the Routing header. 561 Uses the same values as the IPv4 Protocol field 562 [RFC-1700 et seq.]. 564 Hdr Ext Len 8-bit unsigned integer. Length of the 565 Routing header in 8-octet units, not including 566 the first 8 octets. 568 Routing Type 8-bit identifier of a particular Routing 569 header variant. 571 Segments Left 8-bit unsigned integer. Number of route 572 segments remaining, i.e., number of explicitly 573 listed intermediate nodes still to be visited 574 before reaching the final destination. 576 type-specific data Variable-length field, of format determined by 577 the Routing Type, and of length such that the 578 complete Routing header is an integer multiple 579 of 8 octets long. 581 If, while processing a received packet, a node encounters a Routing 582 header with an unrecognized Routing Type value, the required behavior 583 of the node depends on the value of the Segments Left field, as 584 follows: 586 If Segments Left is zero, the node must ignore the Routing header 587 and proceed to process the next header in the packet, whose type 588 is identified by the Next Header field in the Routing header. 590 If Segments Left is non-zero, the node must discard the packet and 591 send an ICMP Parameter Problem, Code 0, message to the packet's 592 Source Address, pointing to the unrecognized Routing Type. 594 If, after processing a Routing header of a received packet, an 595 intermediate node determines that the packet is to be forwarded onto 596 a link whose link MTU is less than the size of the packet, the node 597 must discard the packet and send an ICMP Packet Too Big message to 598 the packet's Source Address. 600 The Type 0 Routing header has the following format: 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Next Header | Hdr Ext Len | Routing Type=0| Segments Left | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Reserved | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | | 608 + + 609 | | 610 + Address[1] + 611 | | 612 + + 613 | | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | | 616 + + 617 | | 618 + Address[2] + 619 | | 620 + + 621 | | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 . . . 624 . . . 625 . . . 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | | 628 + + 629 | | 630 + Address[n] + 631 | | 632 + + 633 | | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 Next Header 8-bit selector. Identifies the type of header 637 immediately following the Routing header. 638 Uses the same values as the IPv4 Protocol field 639 [RFC-1700 et seq.]. 641 Hdr Ext Len 8-bit unsigned integer. Length of the 642 Routing header in 8-octet units, not including 643 the first 8 octets. For the Type 0 Routing 644 header, Hdr Ext Len is equal to two times the 645 number of addresses in the header. 647 Routing Type 0. 649 Segments Left 8-bit unsigned integer. Number of route 650 segments remaining, i.e., number of explicitly 651 listed intermediate nodes still to be visited 652 before reaching the final destination. 654 Reserved 32-bit reserved field. Initialized to zero for 655 transmission; ignored on reception. 657 Address[1..n] Vector of 128-bit addresses, numbered 1 to n. 659 Multicast addresses must not appear in a Routing header of Type 0, or 660 in the IPv6 Destination Address field of a packet carrying a Routing 661 header of Type 0. 663 A Routing header is not examined or processed until it reaches the 664 node identified in the Destination Address field of the IPv6 header. 665 In that node, dispatching on the Next Header field of the immediately 666 preceding header causes the Routing header module to be invoked, 667 which, in the case of Routing Type 0, performs the following 668 algorithm: 670 if Segments Left = 0 { 671 proceed to process the next header in the packet, whose type is 672 identified by the Next Header field in the Routing header 673 } 674 else if Hdr Ext Len is odd { 675 send an ICMP Parameter Problem, Code 0, message to the Source 676 Address, pointing to the Hdr Ext Len field, and discard the 677 packet 678 } 679 else { 680 compute n, the number of addresses in the Routing header, by 681 dividing Hdr Ext Len by 2 683 if Segments Left is greater than n { 684 send an ICMP Parameter Problem, Code 0, message to the Source 685 Address, pointing to the Segments Left field, and discard the 686 packet 687 } 688 else { 689 decrement Segments Left by 1; 690 compute i, the index of the next address to be visited in 691 the address vector, by subtracting Segments Left from n 693 if Address [i] or the IPv6 Destination Address is multicast { 694 discard the packet 695 } 696 else { 697 swap the IPv6 Destination Address and Address[i] 699 if the IPv6 Hop Limit is less than or equal to 1 { 700 send an ICMP Time Exceeded -- Hop Limit Exceeded in 701 Transit message to the Source Address and discard the 702 packet 703 } 704 else { 705 decrement the Hop Limit by 1 707 resubmit the packet to the IPv6 module for transmission 708 to the new destination 709 } 710 } 711 } 712 } 713 As an example of the effects of the above algorithm, consider the 714 case of a source node S sending a packet to destination node D, using 715 a Routing header to cause the packet to be routed via intermediate 716 nodes I1, I2, and I3. The values of the relevant IPv6 header and 717 Routing header fields on each segment of the delivery path would be 718 as follows: 720 As the packet travels from S to I1: 722 Source Address = S Hdr Ext Len = 6 723 Destination Address = I1 Segments Left = 3 724 Address[1] = I2 725 Address[2] = I3 726 Address[3] = D 728 As the packet travels from I1 to I2: 730 Source Address = S Hdr Ext Len = 6 731 Destination Address = I2 Segments Left = 2 732 Address[1] = I1 733 Address[2] = I3 734 Address[3] = D 736 As the packet travels from I2 to I3: 738 Source Address = S Hdr Ext Len = 6 739 Destination Address = I3 Segments Left = 1 740 Address[1] = I1 741 Address[2] = I2 742 Address[3] = D 744 As the packet travels from I3 to D: 746 Source Address = S Hdr Ext Len = 6 747 Destination Address = D Segments Left = 0 748 Address[1] = I1 749 Address[2] = I2 750 Address[3] = I3 752 4.5 Fragment Header 754 The Fragment header is used by an IPv6 source to send a packet larger 755 than would fit in the path MTU to its destination. (Note: unlike 756 IPv4, fragmentation in IPv6 is performed only by source nodes, not by 757 routers along a packet's delivery path -- see section 5.) The 758 Fragment header is identified by a Next Header value of 44 in the 759 immediately preceding header, and has the following format: 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Next Header | Reserved | Fragment Offset |Res|M| 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Identification | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 Next Header 8-bit selector. Identifies the initial header 768 type of the Fragmentable Part of the original 769 packet (defined below). Uses the same values 770 as the IPv4 Protocol field [RFC-1700 et seq.]. 772 Reserved 8-bit reserved field. Initialized to zero for 773 transmission; ignored on reception. 775 Fragment Offset 13-bit unsigned integer. The offset, in 8-octet 776 units, of the data following this header, 777 relative to the start of the Fragmentable Part 778 of the original packet. 780 Res 2-bit reserved field. Initialized to zero for 781 transmission; ignored on reception. 783 M flag 1 = more fragments; 0 = last fragment. 785 Identification 32 bits. See description below. 787 In order to send a packet that is too large to fit in the MTU of the 788 path to its destination, a source node may divide the packet into 789 fragments and send each fragment as a separate packet, to be 790 reassembled at the receiver. 792 For every packet that is to be fragmented, the source node generates 793 an Identification value. The Identification must be different than 794 that of any other fragmented packet sent recently* with the same 795 Source Address and Destination Address. If a Routing header is 796 present, the Destination Address of concern is that of the final 797 destination. 799 * "recently" means within the maximum likely lifetime of a packet, 800 including transit time from source to destination and time spent 801 awaiting reassembly with other fragments of the same packet. 802 However, it is not required that a source node know the maximum 803 packet lifetime. Rather, it is assumed that the requirement can 804 be met by maintaining the Identification value as a simple, 805 32-bit, "wrap-around" counter, incremented each time a packet 806 must be fragmented. It is an implementation choice whether to 807 maintain a single counter for the node or multiple counters, 808 e.g., one for each of the node's possible source addresses, or 809 one for each active (source address, destination address) 810 combination. 812 The initial, large, unfragmented packet is referred to as the 813 "original packet", and it is considered to consist of two parts, as 814 illustrated: 816 original packet: 818 +------------------+----------------------//-----------------------+ 819 | Unfragmentable | Fragmentable | 820 | Part | Part | 821 +------------------+----------------------//-----------------------+ 823 The Unfragmentable Part consists of the IPv6 header plus any 824 extension headers that must be processed by nodes en route to the 825 destination, that is, all headers up to and including the Routing 826 header if present, else the Hop-by-Hop Options header if present, 827 else no extension headers. 829 The Fragmentable Part consists of the rest of the packet, that is, 830 any extension headers that need be processed only by the final 831 destination node(s), plus the upper-layer header and data. 833 The Fragmentable Part of the original packet is divided into 834 fragments, each, except possibly the last ("rightmost") one, being an 835 integer multiple of 8 octets long. The fragments are transmitted in 836 separate "fragment packets" as illustrated: 838 original packet: 840 +------------------+--------------+--------------+--//--+----------+ 841 | Unfragmentable | first | second | | last | 842 | Part | fragment | fragment | .... | fragment | 843 +------------------+--------------+--------------+--//--+----------+ 844 fragment packets: 846 +------------------+--------+--------------+ 847 | Unfragmentable |Fragment| first | 848 | Part | Header | fragment | 849 +------------------+--------+--------------+ 851 +------------------+--------+--------------+ 852 | Unfragmentable |Fragment| second | 853 | Part | Header | fragment | 854 +------------------+--------+--------------+ 855 o 856 o 857 o 858 +------------------+--------+----------+ 859 | Unfragmentable |Fragment| last | 860 | Part | Header | fragment | 861 +------------------+--------+----------+ 863 Each fragment packet is composed of: 865 (1) The Unfragmentable Part of the original packet, with the 866 Payload Length of the original IPv6 header changed to contain 867 the length of this fragment packet only (excluding the length 868 of the IPv6 header itself), and the Next Header field of the 869 last header of the Unfragmentable Part changed to 44. 871 (2) A Fragment header containing: 873 The Next Header value that identifies the first header of 874 the Fragmentable Part of the original packet. 876 A Fragment Offset containing the offset of the fragment, 877 in 8-octet units, relative to the start of the 878 Fragmentable Part of the original packet. The Fragment 879 Offset of the first ("leftmost") fragment is 0. 881 An M flag value of 0 if the fragment is the last 882 ("rightmost") one, else an M flag value of 1. 884 The Identification value generated for the original 885 packet. 887 (3) The fragment itself. 889 The lengths of the fragments must be chosen such that the resulting 890 fragment packets fit within the MTU of the path to the packets' 891 destination(s). 893 At the destination, fragment packets are reassembled into their 894 original, unfragmented form, as illustrated: 896 reassembled original packet: 898 +------------------+----------------------//------------------------+ 899 | Unfragmentable | Fragmentable | 900 | Part | Part | 901 +------------------+----------------------//------------------------+ 903 The following rules govern reassembly: 905 An original packet is reassembled only from fragment packets that 906 have the same Source Address, Destination Address, and Fragment 907 Identification. 909 The Unfragmentable Part of the reassembled packet consists of all 910 headers up to, but not including, the Fragment header of the first 911 fragment packet (that is, the packet whose Fragment Offset is 912 zero), with the following two changes: 914 The Next Header field of the last header of the Unfragmentable 915 Part is obtained from the Next Header field of the first 916 fragment's Fragment header. 918 The Payload Length of the reassembled packet is computed from 919 the length of the Unfragmentable Part and the length and offset 920 of the last fragment. For example, a formula for computing the 921 Payload Length of the reassembled original packet is: 923 PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last 925 where 926 PL.orig = Payload Length field of reassembled packet. 927 PL.first = Payload Length field of first fragment packet. 928 FL.first = length of fragment following Fragment header of 929 first fragment packet. 930 FO.last = Fragment Offset field of Fragment header of 931 last fragment packet. 932 FL.last = length of fragment following Fragment header of 933 last fragment packet. 935 The Fragmentable Part of the reassembled packet is constructed 936 from the fragments following the Fragment headers in each of the 937 fragment packets. The length of each fragment is computed by 938 subtracting from the packet's Payload Length the length of the 939 headers between the IPv6 header and fragment itself; its relative 940 position in Fragmentable Part is computed from its Fragment Offset 941 value. 943 The Fragment header is not present in the final, reassembled 944 packet. 946 The following error conditions may arise when reassembling fragmented 947 packets: 949 If insufficient fragments are received to complete reassembly of a 950 packet within 60 seconds of the reception of the first-arriving 951 fragment of that packet, reassembly of that packet must be 952 abandoned and all the fragments that have been received for that 953 packet must be discarded. If the first fragment (i.e., the one 954 with a Fragment Offset of zero) has been received, an ICMP Time 955 Exceeded -- Fragment Reassembly Time Exceeded message should be 956 sent to the source of that fragment. 958 If the length of a fragment, as derived from the fragment packet's 959 Payload Length field, is not a multiple of 8 octets and the M flag 960 of that fragment is 1, then that fragment must be discarded and an 961 ICMP Parameter Problem, Code 0, message should be sent to the 962 source of the fragment, pointing to the Payload Length field of 963 the fragment packet. 965 If the length and offset of a fragment are such that the Payload 966 Length of the packet reassembled from that fragment would exceed 967 65,535 octets, then that fragment must be discarded and an ICMP 968 Parameter Problem, Code 0, message should be sent to the source of 969 the fragment, pointing to the Fragment Offset field of the 970 fragment packet. 972 The following conditions are not expected to occur, but are not 973 considered errors if they do: 975 The number and content of the headers preceding the Fragment 976 header of different fragments of the same original packet may 977 differ. Whatever headers are present, preceding the Fragment 978 header in each fragment packet, are processed when the packets 979 arrive, prior to queueing the fragments for reassembly. Only 980 those headers in the Offset zero fragment packet are retained in 981 the reassembled packet. 983 The Next Header values in the Fragment headers of different 984 fragments of the same original packet may differ. Only the value 985 from the Offset zero fragment packet is used for reassembly. 987 4.6 Destination Options Header 989 The Destination Options header is used to carry optional information 990 that need be examined only by a packet's destination node(s). The 991 Destination Options header is identified by a Next Header value of 60 992 in the immediately preceding header, and has the following format: 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Next Header | Hdr Ext Len | | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 997 | | 998 . . 999 . Options . 1000 . . 1001 | | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 Next Header 8-bit selector. Identifies the type of header 1005 immediately following the Destination Options 1006 header. Uses the same values as the IPv4 1007 Protocol field [RFC-1700 et seq.]. 1009 Hdr Ext Len 8-bit unsigned integer. Length of the 1010 Destination Options header in 8-octet units, 1011 not including the first 8 octets. 1013 Options Variable-length field, of length such that the 1014 complete Destination Options header is an 1015 integer multiple of 8 octets long. Contains 1016 one or more TLV-encoded options, as described 1017 in section 4.2. 1019 The only destination options defined in this document are the Pad1 1020 and PadN options specified in section 4.2. 1022 Note that there are two possible ways to encode optional destination 1023 information in an IPv6 packet: either as an option in the Destination 1024 Options header, or as a separate extension header. The Fragment 1025 header and the Authentication header are examples of the latter 1026 approach. Which approach can be used depends on what action is 1027 desired of a destination node that does not understand the optional 1028 information: 1030 o If the desired action is for the destination node to discard 1031 the packet and, only if the packet's Destination Address is not 1032 a multicast address, send an ICMP Unrecognized Type message to 1033 the packet's Source Address, then the information may be 1034 encoded either as a separate header or as an option in the 1035 Destination Options header whose Option Type has the value 11 1036 in its highest-order two bits. The choice may depend on such 1037 factors as which takes fewer octets, or which yields better 1038 alignment or more efficient parsing. 1040 o If any other action is desired, the information must be encoded 1041 as an option in the Destination Options header whose Option 1042 Type has the value 00, 01, or 10 in its highest-order two bits, 1043 specifying the desired action (see section 4.2). 1045 4.7 No Next Header 1047 The value 59 in the Next Header field of an IPv6 header or any 1048 extension header indicates that there is nothing following that 1049 header. If the Payload Length field of the IPv6 header indicates the 1050 presence of octets past the end of a header whose Next Header field 1051 contains 59, those octets must be ignored, and passed on unchanged if 1052 the packet is forwarded. 1054 5. Packet Size Issues 1056 IPv6 requires that every link in the internet have an MTU of 1280 1057 octets or greater. On any link that cannot convey a 1280-octet 1058 packet in one piece, link-specific fragmentation and reassembly must 1059 be provided at a layer below IPv6. 1061 Links that have a configurable MTU (for example, PPP links 1062 [RFC-1661]) must be configured to have an MTU of at least 1280 1063 octets; it is recommended that they be configured with an MTU of 1500 1064 octets or greater, to accommodate possible encapsulations (i.e., 1065 tunneling) without incurring IPv6-layer fragmentation. 1067 From each link to which a node is directly attached, the node must 1068 be able to accept packets as large as that link's MTU. 1070 It is strongly recommended that IPv6 nodes implement Path MTU 1071 Discovery [RFC-1981], in order to discover and take advantage of path 1072 MTUs greater than 1280 octets. However, a minimal IPv6 1073 implementation (e.g., in a boot ROM) may simply restrict itself to 1074 sending packets no larger than 1280 octets, and omit implementation 1075 of Path MTU Discovery. 1077 In order to send a packet larger than a path's MTU, a node may use 1078 the IPv6 Fragment header to fragment the packet at the source and 1079 have it reassembled at the destination(s). However, the use of such 1080 fragmentation is discouraged in any application that is able to 1081 adjust its packets to fit the measured path MTU (i.e., down to 1280 1082 octets). 1084 A node must be able to accept a fragmented packet that, after 1085 reassembly, is as large as 1500 octets. A node is permitted to 1086 accept fragmented packets that reassemble to more than 1500 octets. 1087 An upper-layer protocol or application that depends on IPv6 1088 fragmentation to send packets larger than the MTU of a path should 1089 not send packets larger than 1500 octets unless it has assurance that 1090 the destination is capable of reassembling packets of that larger 1091 size. 1093 In response to an IPv6 packet that is sent to an IPv4 destination 1094 (i.e., a packet that undergoes translation from IPv6 to IPv4), the 1095 originating IPv6 node may receive an ICMP Packet Too Big message 1096 reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node 1097 is not required to reduce the size of subsequent packets to less than 1098 1280, but must include a Fragment header in those packets so that the 1099 IPv6-to-IPv4 translating router can obtain a suitable Identification 1100 value to use in resulting IPv4 fragments. Note that this means the 1101 payload may have to be reduced to 1232 octets (1280 minus 40 for the 1102 IPv6 header and 8 for the Fragment header), and smaller still if 1103 additional extension headers are used. 1105 6. Flow Labels 1107 The 20-bit Flow Label field in the IPv6 header may be used by a 1108 source to label those packets for which it requests special handling 1109 by the IPv6 routers, such as non-default quality of service or "real- 1110 time" service. This aspect of IPv6 is, at the time of writing, still 1111 experimental and subject to change as the requirements for flow 1112 support in the Internet become clearer. Hosts or routers that do not 1113 support the functions of the Flow Label field are required to set the 1114 field to zero when originating a packet, pass the field on unchanged 1115 when forwarding a packet, and ignore the field when receiving a 1116 packet. 1118 A flow is a sequence of packets sent from a particular source to a 1119 particular (unicast or multicast) destination for which the source 1120 desires special handling by the intervening routers. The nature of 1121 that special handling might be conveyed to the routers by a control 1122 protocol, such as a resource reservation protocol, or by information 1123 within the flow's packets themselves, e.g., in a hop-by-hop option. 1124 The details of such control protocols or options are beyond the scope 1125 of this document. 1127 There may be multiple active flows from a source to a destination, as 1128 well as traffic that is not associated with any flow. A flow is 1129 uniquely identified by the combination of a source address and a non- 1130 zero flow label. Packets that do not belong to a flow carry a flow 1131 label of zero. 1133 A flow label is assigned to a flow by the flow's source node. New 1134 flow labels must be chosen (pseudo-)randomly and uniformly from the 1135 range 1 to FFFFFF hex. The purpose of the random allocation is to 1136 make any set of bits within the Flow Label field suitable for use as 1137 a hash key by routers, for looking up the state associated with the 1138 flow. 1140 All packets belonging to the same flow must be sent with the same 1141 source address, destination address, and flow label. If any of those 1142 packets includes a Hop-by-Hop Options header, then they all must be 1143 originated with the same Hop-by-Hop Options header contents 1144 (excluding the Next Header field of the Hop-by-Hop Options header). 1145 If any of those packets includes a Routing header, then they all must 1146 be originated with the same contents in all extension headers up to 1147 and including the Routing header (excluding the Next Header field in 1148 the Routing header). The routers or destinations are permitted, but 1149 not required, to verify that these conditions are satisfied. If a 1150 violation is detected, it should be reported to the source by an ICMP 1151 Parameter Problem message, Code 0, pointing to the high-order octet 1152 of the Flow Label field (i.e., offset 1 within the IPv6 packet). 1154 The maximum lifetime of any flow-handling state established along a 1155 flow's path must be specified as part of the description of the 1156 state-establishment mechanism, e.g., the resource reservation 1157 protocol or the flow-setup hop-by-hop option. A source must not re- 1158 use a flow label for a new flow within the maximum lifetime of any 1159 flow-handling state that might have been established for the prior 1160 use of that flow label. 1162 When a node stops and restarts (e.g., as a result of a "crash"), it 1163 must be careful not to use a flow label that it might have used for 1164 an earlier flow whose lifetime may not have expired yet. This may be 1165 accomplished by recording flow label usage on stable storage so that 1166 it can be remembered across crashes, or by refraining from using any 1167 flow labels until the maximum lifetime of any possible previously 1168 established flows has expired. If the minimum time for rebooting the 1169 node is known, that time can be deducted from the necessary waiting 1170 period before starting to allocate flow labels. 1172 There is no requirement that all, or even most, packets belong to 1173 flows, i.e., carry non-zero flow labels. This observation is placed 1174 here to remind protocol designers and implementors not to assume 1175 otherwise. For example, it would be unwise to design a router whose 1176 performance would be adequate only if most packets belonged to flows, 1177 or to design a header compression scheme that only worked on packets 1178 that belonged to flows. 1180 7. Traffic Classes 1182 The 8-bit Traffic Class field in the IPv6 header is available for use 1183 by originating nodes and/or forwarding routers to identify and 1184 distinguish between different classes or priorities of IPv6 packets. 1185 At the point in time at which this specification is being written, 1186 there are a number of experiments underway in the use of the IPv4 1187 Type of Service and/or Precedence bits to provide various forms of 1188 "differentiated service" for IP packets, other than through the use 1189 of explicit flow set-up. The Traffic Class field in the IPv6 header 1190 is intended to allow similar functionality to be supported in IPv6. 1191 It is hoped that those experiments will eventually lead to agreement 1192 on what sorts of traffic classifications are most useful for IP 1193 packets. Detailed definitions of the syntax and semantics of all or 1194 some of the IPv6 Traffic Class bits, whether experimental or intended 1195 for eventual standardization, are to be provided in separate 1196 documents. 1198 The following general requirements apply to the Traffic Class field: 1200 o The service interface to the IPv6 service within a node must 1201 provide a means for an upper-layer protocol to supply the value 1202 of the Traffic Class bits in packets originated by that upper- 1203 layer protocol. The default value must be zero for all 8 bits. 1205 o Nodes that support a specific (experimental or eventual 1206 standard) use of some or all of the Traffic Class bits are 1207 permitted to change the value of those bits in packets that 1208 they originate, forward, or receive, as required for that 1209 specific use. Nodes should ignore and leave unchanged any bits 1210 of the Traffic Class field for which they do not support a 1211 specific use. 1213 o An upper-layer protocol must not assume that the value of the 1214 Traffic Class bits in a received packet are the same as the 1215 value sent by the packet's source. 1217 8. Upper-Layer Protocol Issues 1219 8.1 Upper-Layer Checksums 1221 Any transport or other upper-layer protocol that includes the 1222 addresses from the IP header in its checksum computation must be 1223 modified for use over IPv6, to include the 128-bit IPv6 addresses 1224 instead of 32-bit IPv4 addresses. In particular, the following 1225 illustration shows the TCP and UDP "pseudo-header" for IPv6: 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | | 1229 + + 1230 | | 1231 + Source Address + 1232 | | 1233 + + 1234 | | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | | 1237 + + 1238 | | 1239 + Destination Address + 1240 | | 1241 + + 1242 | | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Upper-Layer Packet Length | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | zero | Next Header | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 o If the IPv6 packet contains a Routing header, the Destination 1250 Address used in the pseudo-header is that of the final 1251 destination. At the originating node, that address will be in 1252 the last element of the Routing header; at the recipient(s), 1253 that address will be in the Destination Address field of the 1254 IPv6 header. 1256 o The Next Header value in the pseudo-header identifies the 1257 upper-layer protocol (e.g., 6 for TCP, or 17 for UDP). It will 1258 differ from the Next Header value in the IPv6 header if there 1259 are extension headers between the IPv6 header and the upper- 1260 layer header. 1262 o The Upper-Layer Packet Length in the pseudo-header is the 1263 length of the upper-layer header and data (e.g., TCP header 1264 plus TCP data). Some upper-layer protocols carry their own 1265 length information (e.g., the Length field in the UDP header of 1266 non-jumbogram UDP packets); for such protocols, that is the 1267 length used in the pseudo-header. Other protocols (such as 1268 TCP) do not carry their own length information, in which case 1269 the length used in the pseudo-header is the Payload Length from 1270 the IPv6 header (or from the Jumbo Payload option), minus the 1271 length of any extension headers present between the IPv6 header 1272 and the upper-layer header. 1274 o Unlike IPv4, when UDP packets are originated by an IPv6 node, 1275 the UDP checksum is not optional. That is, whenever 1276 originating a UDP packet, an IPv6 node must compute a UDP 1277 checksum over the packet and the pseudo-header, and, if that 1278 computation yields a result of zero, it must be changed to hex 1279 FFFF for placement in the UDP header. IPv6 receivers must 1280 discard UDP packets containing a zero checksum, and should log 1281 the error. 1283 The IPv6 version of ICMP [ICMPv6] includes the above pseudo-header in 1284 its checksum computation; this is a change from the IPv4 version of 1285 ICMP, which does not include a pseudo-header in its checksum. The 1286 reason for the change is to protect ICMP from misdelivery or 1287 corruption of those fields of the IPv6 header on which it depends, 1288 which, unlike IPv4, are not covered by an internet-layer checksum. 1289 The Next Header field in the pseudo-header for ICMP contains the 1290 value 58, which identifies the IPv6 version of ICMP. 1292 8.2 Maximum Packet Lifetime 1294 Unlike IPv4, IPv6 nodes are not required to enforce maximum packet 1295 lifetime. That is the reason the IPv4 "Time to Live" field was 1296 renamed "Hop Limit" in IPv6. In practice, very few, if any, IPv4 1297 implementations conform to the requirement that they limit packet 1298 lifetime, so this is not a change in practice. Any upper-layer 1299 protocol that relies on the internet layer (whether IPv4 or IPv6) to 1300 limit packet lifetime ought to be upgraded to provide its own 1301 mechanisms for detecting and discarding obsolete packets. 1303 8.3 Maximum Upper-Layer Payload Size 1305 When computing the maximum payload size available for upper-layer 1306 data, an upper-layer protocol must take into account the larger size 1307 of the IPv6 header relative to the IPv4 header. For example, in 1308 IPv4, TCP's MSS option is computed as the maximum packet size (a 1309 default value or a value learned through Path MTU Discovery) minus 40 1310 octets (20 octets for the minimum-length IPv4 header and 20 octets 1311 for the minimum-length TCP header). When using TCP over IPv6, the 1312 MSS must be computed as the maximum packet size minus 60 octets, 1313 because the minimum-length IPv6 header (i.e., an IPv6 header with no 1314 extension headers) is 20 octets longer than a minimum-length IPv4 1315 header. 1317 8.4 Responding to Packets Carrying Routing Headers 1319 When an upper-layer protocol sends one or more packets in response to 1320 a received packet that included a Routing header, the response 1321 packet(s) must not include a Routing header that was automatically 1322 derived by "reversing" the received Routing header UNLESS the 1323 integrity and authenticity of the received Source Address and Routing 1324 header have been verified (e.g., via the use of an Authentication 1325 header in the received packet). In other words, only the following 1326 kinds of packets are permitted in response to a received packet 1327 bearing a Routing header: 1329 o Response packets that do not carry Routing headers. 1331 o Response packets that carry Routing headers that were NOT 1332 derived by reversing the Routing header of the received packet 1333 (for example, a Routing header supplied by local 1334 configuration). 1336 o Response packets that carry Routing headers that were derived 1337 by reversing the Routing header of the received packet IF AND 1338 ONLY IF the integrity and authenticity of the Source Address 1339 and Routing header from the received packet have been verified 1340 by the responder. 1342 Appendix A. Formatting Guidelines for Options 1344 This appendix gives some advice on how to lay out the fields when 1345 designing new options to be used in the Hop-by-Hop Options header or 1346 the Destination Options header, as described in section 4.2. These 1347 guidelines are based on the following assumptions: 1349 o One desirable feature is that any multi-octet fields within the 1350 Option Data area of an option be aligned on their natural 1351 boundaries, i.e., fields of width n octets should be placed at 1352 an integer multiple of n octets from the start of the Hop-by- 1353 Hop or Destination Options header, for n = 1, 2, 4, or 8. 1355 o Another desirable feature is that the Hop-by-Hop or Destination 1356 Options header take up as little space as possible, subject to 1357 the requirement that the header be an integer multiple of 8 1358 octets long. 1360 o It may be assumed that, when either of the option-bearing 1361 headers are present, they carry a very small number of options, 1362 usually only one. 1364 These assumptions suggest the following approach to laying out the 1365 fields of an option: order the fields from smallest to largest, with 1366 no interior padding, then derive the alignment requirement for the 1367 entire option based on the alignment requirement of the largest field 1368 (up to a maximum alignment of 8 octets). This approach is 1369 illustrated in the following examples: 1371 Example 1 1373 If an option X required two data fields, one of length 8 octets and 1374 one of length 4 octets, it would be laid out as follows: 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Option Type=X |Opt Data Len=12| 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | 4-octet field | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | | 1382 + 8-octet field + 1383 | | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 Its alignment requirement is 8n+2, to ensure that the 8-octet field 1387 starts at a multiple-of-8 offset from the start of the enclosing 1388 header. A complete Hop-by-Hop or Destination Options header 1389 containing this one option would look as follows: 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Next Header | Hdr Ext Len=1 | Option Type=X |Opt Data Len=12| 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | 4-octet field | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | | 1397 + 8-octet field + 1398 | | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 Example 2 1403 If an option Y required three data fields, one of length 4 octets, 1404 one of length 2 octets, and one of length 1 octet, it would be laid 1405 out as follows: 1407 +-+-+-+-+-+-+-+-+ 1408 | Option Type=Y | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 |Opt Data Len=7 | 1-octet field | 2-octet field | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | 4-octet field | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 Its alignment requirement is 4n+3, to ensure that the 4-octet field 1416 starts at a multiple-of-4 offset from the start of the enclosing 1417 header. A complete Hop-by-Hop or Destination Options header 1418 containing this one option would look as follows: 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | Next Header | Hdr Ext Len=1 | Pad1 Option=0 | Option Type=Y | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 |Opt Data Len=7 | 1-octet field | 2-octet field | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | 4-octet field | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | PadN Option=1 |Opt Data Len=2 | 0 | 0 | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 Example 3 1431 A Hop-by-Hop or Destination Options header containing both options X 1432 and Y from Examples 1 and 2 would have one of the two following 1433 formats, depending on which option appeared first: 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Next Header | Hdr Ext Len=3 | Option Type=X |Opt Data Len=12| 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | 4-octet field | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | | 1441 + 8-octet field + 1442 | | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | PadN Option=1 |Opt Data Len=1 | 0 | Option Type=Y | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 |Opt Data Len=7 | 1-octet field | 2-octet field | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | 4-octet field | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | PadN Option=1 |Opt Data Len=2 | 0 | 0 | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | Next Header | Hdr Ext Len=3 | Pad1 Option=0 | Option Type=Y | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 |Opt Data Len=7 | 1-octet field | 2-octet field | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | 4-octet field | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | PadN Option=1 |Opt Data Len=4 | 0 | 0 | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | 0 | 0 | Option Type=X |Opt Data Len=12| 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | 4-octet field | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | | 1467 + 8-octet field + 1468 | | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 Security Considerations 1473 This document specifies that the IP Authentication Header [RFC-1826] 1474 and the IP Encapsulating Security Payload [RFC-1827] be used with 1475 IPv6, in conformance with the Security Architecture for the Internet 1476 Protocol [RFC-1825]. 1478 Acknowledgments 1480 The authors gratefully acknowledge the many helpful suggestions of 1481 the members of the IPng working group, the End-to-End Protocols 1482 research group, and the Internet Community At Large. 1484 Authors' Addresses 1486 Stephen E. Deering Robert M. Hinden 1487 Cisco Systems, Inc. Ipsilon Networks, Inc. 1488 170 West Tasman Drive 232 Java Drive 1489 San Jose, CA 95134-1706 Sunnyvale, CA 94089 1490 USA USA 1492 phone: +1 408 527 8213 phone: +1 408 990-2004 1493 fax: +1 408 527 8254 fax: +1 408 743-5677 1494 email: deering@cisco.com email: hinden@ipsilon.com 1496 References 1498 [RFC-1825] Atkinson, R., Security Architecture for the Internet 1499 Protocol, RFC-1825, August 1995. 1501 [RFC-1826] Atkinson, R., IP Authentication Header, RFC-1826, August 1502 1995. 1504 [RFC-1827] Atkinson, R., IP Encapsulating Security Protocol (ESP), 1505 RFC-1827, August 1995. 1507 [ICMPv6] Conta, A. and S. Deering, ICMP for the Internet Protocol 1508 Version 6 (IPv6), Internet Draft, , October 1997. 1511 [ADDRARCH] Hinden, R., and S. Deering, IP Version 6 Addressing 1512 Architecture, Internet Draft, , November 1997. 1515 [RFC-1981] McCann, J., J. Mogul, and S. Deering, Path MTU Discovery 1516 for IP version 6, RFC-1981, August 1996. 1518 [RFC-791] Postel, J., Internet Protocol, RFC-791, September 1981. 1520 [RFC-1700] Reynolds, J., and J. Postel, Assigned Numbers, RFC-1700, 1521 October 1994. 1523 [RFC-1661] Simpson, W., The Point-to-Point Protocol (PPP), 1524 RFC-1548, April 1994. 1526 CHANGES SINCE RFC-1883 1528 This draft has the following changes from RFC-1883. Numbers identify 1529 the internet draft version in which the change was made. 1531 01) In section 3, changed field name "Class" to "Traffic Class" and 1532 increased its size from 4 to 8 bits. Decreased size of Flow 1533 Label field from 24 to 20 bits to compensate for increase in 1534 Traffic Class field. 1536 01) In section 4.1, restored the order of the Authentication Header 1537 and the ESP header, which were mistakenly swapped in the 00 1538 version of this draft. 1540 01) In section 4.4, deleted the Strict/Loose Bit Map field and the 1541 strict routing functionality from the Type 0 Routing header, and 1542 removed the restriction on number of addresses that may be 1543 carried in the Type 0 Routing header (was limited to 23 1544 addresses, because of the size of the strict/loose bit map). 1546 01) In section 5, changed the minimum IPv6 MTU from 576 to 1280 1547 octets, and added a recommendation that links with configurable 1548 MTU (e.g., PPP links) be configured to have an MTU of at least 1549 1500 octets. 1551 01) In section 5, deleted the requirement that a node must not send 1552 fragmented packets that reassemble to more than 1500 octets 1553 without knowledge of the destination reassembly buffer size, and 1554 replaced it with a recommendation that upper-layer protocols or 1555 applications should not do that. 1557 01) Replaced reference to the IPv4 Path MTU Discovery spec 1558 (RFC-1191) with reference to the IPv6 Path MTU Discovery spec 1559 (RFC-1981), and deleted the Notes at the end of section 5 1560 regarding Path MTU Discovery, since those details are now 1561 covered by RFC-1981. 1563 01) In section 6, deleted specification of "opportunistic" flow set- 1564 up, and removed all references to the 6-second maximum lifetime 1565 for opportunistically established flow state. 1567 01) In section 7, deleted the provisional description of the 1568 internal structure and semantics of the Traffic Class field, and 1569 specified that such descriptions be provided in separate 1570 documents. 1572 -------------- 1574 00) In section 4, corrected the Code value to indicate "unrecognized 1575 Next Header type encountered" in an ICMP Parameter Problem 1576 message (changed from 2 to 1). 1578 00) In the description of the Payload Length field in section 3, and 1579 of the Jumbo Payload Length field in section 4.3, made it 1580 clearer that extensions headers are included in the payload 1581 length count. 1583 00) In section 4.1., swapped the order of the Authentication header 1584 and the ESP header. (NOTE: this was a mistake, and the change 1585 was undone in version 01.) 1587 00) In section 4.2, made it clearer that options are identified by 1588 the full 8-bit Option Type, not by the low-order 5 bits of an 1589 Option Type. Also specified that the same Option Type numbering 1590 space is used for both Hop-by-Hop Options and Destination 1591 Options headers. 1593 00) In section 4.4, added a sentence requiring that nodes processing 1594 a Routing header must send an ICMP Packet Too Big message in 1595 response to a packet that is too big to fit in the next hop link 1596 (rather than, say, performing fragmentation). 1598 00) Changed the name of the IPv6 Priority field to "Class", and 1599 replaced the previous description of Priority in section 7 with 1600 a description of the Class field. Also, excluded this field 1601 from the set of fields that must remain the same for all packets 1602 in the same flow, as specified in section 6. 1604 00) In the pseudo-header in section 8.1, changed the name of the 1605 "Payload Length" field to "Upper-Layer Packet Length". Also 1606 clarified that, in the case of protocols that carry their own 1607 length info (like non-jumbogram UDP), it is the upper-layer- 1608 derived length, not the IP-layer-derived length, that is used in 1609 the pseudo-header. 1611 00) Added section 8.4, specifying that upper-layer protocols, when 1612 responding to a received packet that carried a Routing header, 1613 must not include the reverse of the Routing header in the 1614 response packet(s) unless the received Routing header was 1615 authenticated. 1617 00) Fixed some typos and grammatical errors. 1619 00) Authors' contact info updated.