idnits 2.17.1 draft-ietf-ipngwg-ipv6-spec-v2-00.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 are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1046 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 777 -- Looks like a reference, but probably isn't: '2' on line 778 -- Looks like a reference, but probably isn't: '3' on line 779 == Unused Reference: 'RFC-1700' is defined on line 1650, 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) ** Obsolete normative reference: RFC 1885 (Obsoleted by RFC 2463) -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDRARCH' ** 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 (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Deering, Cisco Systems 2 July 30, 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 January 30, 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..............................................31 59 8. Upper-Layer Protocol Issues..................................33 60 8.1 Upper-Layer Checksums...................................33 61 8.2 Maximum Packet Lifetime.................................34 62 8.3 Maximum Upper-Layer Payload Size........................34 63 8.4 Responding to Packets Carrying Routing Headers..........35 65 Appendix A. Formatting Guidelines for Options...................36 67 Security Considerations.........................................39 69 Acknowledgments.................................................39 71 Authors' Addresses..............................................39 73 References......................................................40 75 Changes Since RFC-1883..........................................41 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 [RFC-1885]. 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 in one piece over 161 a link. 163 path MTU - the minimum link MTU of all the links in a path between 164 a source node and a destination node. 166 Note: it is possible, though unusual, for a device with multiple 167 interfaces to be configured to forward non-self-destined packets 168 arriving from some set (fewer than all) of its interfaces, and to 169 discard non-self-destined packets arriving from its other interfaces. 170 Such a device must obey the protocol requirements for routers when 171 receiving packets from, and interacting with neighbors over, the 172 former (forwarding) interfaces. It must obey the protocol 173 requirements for hosts when receiving packets from, and interacting 174 with neighbors over, the latter (non-forwarding) interfaces. 176 3. IPv6 Header Format 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 |Version| Class | Flow Label | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Payload Length | Next Header | Hop Limit | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 + + 185 | | 186 + Source Address + 187 | | 188 + + 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 + + 193 | | 194 + Destination Address + 195 | | 196 + + 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Version 4-bit Internet Protocol version number = 6. 202 Class 4-bit traffic class value. See section 7. 204 Flow Label 24-bit flow label. See section 6. 206 Payload Length 16-bit unsigned integer. Length of the IPv6 207 payload, i.e., the rest of the packet 208 following this IPv6 header, in octets. 209 (Note that any extension headers [section 4] 210 present are considered part of the payload, 211 i.e., included in the length count.) 212 If this field is zero, it indicates that the 213 payload length is carried in a Jumbo Payload 214 hop-by-hop option. 216 Next Header 8-bit selector. Identifies the type of header 217 immediately following the IPv6 header. Uses 218 the same values as the IPv4 Protocol field 219 [RFC-1700 et seq.]. 221 Hop Limit 8-bit unsigned integer. Decremented by 1 by 222 each node that forwards the packet. The packet 223 is discarded if Hop Limit is decremented to 224 zero. 226 Source Address 128-bit address of the originator of the 227 packet. See [ADDRARCH]. 229 Destination Address 128-bit address of the intended recipient 230 of the packet (possibly not the ultimate 231 recipient, if a Routing header is present). 232 See [ADDRARCH] and section 4.4. 234 4. IPv6 Extension Headers 236 In IPv6, optional internet-layer information is encoded in separate 237 headers that may be placed between the IPv6 header and the upper- 238 layer header in a packet. There are a small number of such extension 239 headers, each identified by a distinct Next Header value. As 240 illustrated in these examples, an IPv6 packet may carry zero, one, or 241 more extension headers, each identified by the Next Header field of 242 the preceding header: 244 +---------------+------------------------ 245 | IPv6 header | TCP header + data 246 | | 247 | Next Header = | 248 | TCP | 249 +---------------+------------------------ 251 +---------------+----------------+------------------------ 252 | IPv6 header | Routing header | TCP header + data 253 | | | 254 | Next Header = | Next Header = | 255 | Routing | TCP | 256 +---------------+----------------+------------------------ 258 +---------------+----------------+-----------------+----------------- 259 | IPv6 header | Routing header | Fragment header | fragment of TCP 260 | | | | header + data 261 | Next Header = | Next Header = | Next Header = | 262 | Routing | Fragment | TCP | 263 +---------------+----------------+-----------------+----------------- 265 With one exception, extension headers are not examined or processed 266 by any node along a packet's delivery path, until the packet reaches 267 the node (or each of the set of nodes, in the case of multicast) 268 identified in the Destination Address field of the IPv6 header. 269 There, normal demultiplexing on the Next Header field of the IPv6 270 header invokes the module to process the first extension header, or 271 the upper-layer header if no extension header is present. The 272 contents and semantics of each extension header determine whether or 273 not to proceed to the next header. Therefore, extension headers must 274 be processed strictly in the order they appear in the packet; a 275 receiver must not, for example, scan through a packet looking for a 276 particular kind of extension header and process that header prior to 277 processing all preceding ones. 279 The exception referred to in the preceding paragraph is the Hop-by- 280 Hop Options header, which carries information that must be examined 281 and processed by every node along a packet's delivery path, including 282 the source and destination nodes. The Hop-by-Hop Options header, 283 when present, must immediately follow the IPv6 header. Its presence 284 is indicated by the value zero in the Next Header field of the IPv6 285 header. 287 If, as a result of processing a header, a node is required to proceed 288 to the next header but the Next Header value in the current header is 289 unrecognized by the node, it should discard the packet and send an 290 ICMP Parameter Problem message to the source of the packet, with an 291 ICMP Code value of 1 ("unrecognized Next Header type encountered") 292 and the ICMP Pointer field containing the offset of the unrecognized 293 value within the original packet. The same action should be taken if 294 a node encounters a Next Header value of zero in any header other 295 than an IPv6 header. 297 Each extension header is an integer multiple of 8 octets long, in 298 order to retain 8-octet alignment for subsequent headers. Multi- 299 octet fields within each extension header are aligned on their 300 natural boundaries, i.e., fields of width n octets are placed at an 301 integer multiple of n octets from the start of the header, for n = 1, 302 2, 4, or 8. 304 A full implementation of IPv6 includes implementation of the 305 following extension headers: 307 Hop-by-Hop Options 308 Routing (Type 0) 309 Fragment 310 Destination Options 311 Authentication 312 Encapsulating Security Payload 314 The first four are specified in this document; the last two are 315 specified in [RFC-1826] and [RFC-1827], respectively. 317 4.1 Extension Header Order 319 When more than one extension header is used in the same packet, it is 320 recommended that those headers appear in the following order: 322 IPv6 header 323 Hop-by-Hop Options header 324 Destination Options header (note 1) 325 Routing header 326 Fragment header 327 Encapsulating Security Payload header (note 2) 328 Authentication header (note 2) 329 Destination Options header (note 3) 330 upper-layer header 332 note 1: for options to be processed by the first destination 333 that appears in the IPv6 Destination Address field 334 plus subsequent destinations listed in the Routing 335 header. 337 note 2: additional recommendations regarding the relative 338 order of the Authentication and Encapsulating 339 Security Payload headers are given in [RFC-1827]. 341 note 3: for options to be processed only by the final 342 destination of the packet. 344 Each extension header should occur at most once, except for the 345 Destination Options header which should occur at most twice (once 346 before a Routing header and once before the upper-layer header). 348 If the upper-layer header is another IPv6 header (in the case of IPv6 349 being tunneled over or encapsulated in IPv6), it may be followed by 350 its own extension headers, which are separately subject to the same 351 ordering recommendations. 353 If and when other extension headers are defined, their ordering 354 constraints relative to the above listed headers must be specified. 356 IPv6 nodes must accept and attempt to process extension headers in 357 any order and occurring any number of times in the same packet, 358 except for the Hop-by-Hop Options header which is restricted to 359 appear immediately after an IPv6 header only. Nonetheless, it is 360 strongly advised that sources of IPv6 packets adhere to the above 361 recommended order until and unless subsequent specifications revise 362 that recommendation. 364 4.2 Options 366 Two of the currently-defined extension headers -- the Hop-by-Hop 367 Options header and the Destination Options header -- carry a variable 368 number of type-length-value (TLV) encoded "options", of the following 369 format: 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 372 | Option Type | Opt Data Len | Option Data 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 375 Option Type 8-bit identifier of the type of option. 377 Opt Data Len 8-bit unsigned integer. Length of the Option 378 Data field of this option, in octets. 380 Option Data Variable-length field. Option-Type-specific 381 data. 383 The sequence of options within a header must be processed strictly in 384 the order they appear in the header; a receiver must not, for 385 example, scan through the header looking for a particular kind of 386 option and process that option prior to processing all preceding 387 ones. 389 The Option Type identifiers are internally encoded such that their 390 highest-order two bits specify the action that must be taken if the 391 processing IPv6 node does not recognize the Option Type: 393 00 - skip over this option and continue processing the header. 395 01 - discard the packet. 397 10 - discard the packet and, regardless of whether or not the 398 packet's Destination Address was a multicast address, send an 399 ICMP Parameter Problem, Code 2, message to the packet's 400 Source Address, pointing to the unrecognized Option Type. 402 11 - discard the packet and, only if the packet's Destination 403 Address was not a multicast address, send an ICMP Parameter 404 Problem, Code 2, message to the packet's Source Address, 405 pointing to the unrecognized Option Type. 407 The third-highest-order bit of the Option Type specifies whether or 408 not the Option Data of that option can change en-route to the 409 packet's final destination. When an Authentication header is present 410 in the packet, for any option whose data may change en-route, its 411 entire Option Data field must be treated as zero-valued octets when 412 computing or verifying the packet's authenticating value. 414 0 - Option Data does not change en-route 416 1 - Option Data may change en-route 418 The three high-order bits described above are to be treated as part 419 of the Option Type, not independent of the Option Type. That is, a 420 particular option is identified by a full 8-bit Option Type, not just 421 the low-order 5 bits of an Option Type. 423 The same Option Type numbering space is used for both the Hop-by-Hop 424 Options header and the Destination Options header. However, the 425 specification of a particular option may restrict its use to only one 426 of those two headers. 428 Individual options may have specific alignment requirements, to 429 ensure that multi-octet values within Option Data fields fall on 430 natural boundaries. The alignment requirement of an option is 431 specified using the notation xn+y, meaning the Option Type must 432 appear at an integer multiple of x octets from the start of the 433 header, plus y octets. For example: 435 2n means any 2-octet offset from the start of the header. 436 8n+2 means any 8-octet offset from the start of the header, 437 plus 2 octets. 439 There are two padding options which are used when necessary to align 440 subsequent options and to pad out the containing header to a multiple 441 of 8 octets in length. These padding options must be recognized by 442 all IPv6 implementations: 444 Pad1 option (alignment requirement: none) 446 +-+-+-+-+-+-+-+-+ 447 | 0 | 448 +-+-+-+-+-+-+-+-+ 450 NOTE! the format of the Pad1 option is a special case -- it does 451 not have length and value fields. 453 The Pad1 option is used to insert one octet of padding into the 454 Options area of a header. If more than one octet of padding is 455 required, the PadN option, described next, should be used, 456 rather than multiple Pad1 options. 458 PadN option (alignment requirement: none) 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 461 | 1 | Opt Data Len | Option Data 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 464 The PadN option is used to insert two or more octets of padding 465 into the Options area of a header. For N octets of padding, 466 the Opt Data Len field contains the value N-2, and the Option 467 Data consists of N-2 zero-valued octets. 469 Appendix A contains formatting guidelines for designing new options. 471 4.3 Hop-by-Hop Options Header 473 The Hop-by-Hop Options header is used to carry optional information 474 that must be examined by every node along a packet's delivery path. 475 The Hop-by-Hop Options header is identified by a Next Header value of 476 0 in the IPv6 header, and has the following format: 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Next Header | Hdr Ext Len | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 481 | | 482 . . 483 . Options . 484 . . 485 | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Next Header 8-bit selector. Identifies the type of header 489 immediately following the Hop-by-Hop Options 490 header. Uses the same values as the IPv4 491 Protocol field [RFC-1700 et seq.]. 493 Hdr Ext Len 8-bit unsigned integer. Length of the 494 Hop-by-Hop Options header in 8-octet units, 495 not including the first 8 octets. 497 Options Variable-length field, of length such that the 498 complete Hop-by-Hop Options header is an integer 499 multiple of 8 octets long. Contains one or 500 more TLV-encoded options, as described in 501 section 4.2. 503 In addition to the Pad1 and PadN options specified in section 4.2, 504 the following hop-by-hop option is defined: 506 Jumbo Payload option (alignment requirement: 4n + 2) 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | 194 |Opt Data Len=4 | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Jumbo Payload Length | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 The Jumbo Payload option is used to send IPv6 packets with 515 payloads longer than 65,535 octets. The Jumbo Payload Length is 516 the length of the packet in octets, excluding the IPv6 header but 517 including the Hop-by-Hop Options header and any other extension 518 headers present; it must be greater than 65,535. If a packet is 519 received with a Jumbo Payload option containing a Jumbo Payload 520 Length less than or equal to 65,535, an ICMP Parameter Problem 521 message, Code 0, should be sent to the packet's source, pointing 522 to the high-order octet of the invalid Jumbo Payload Length field. 524 The Payload Length field in the IPv6 header must be set to zero 525 in every packet that carries the Jumbo Payload option. If a 526 packet is received with a valid Jumbo Payload option present and 527 a non-zero IPv6 Payload Length field, an ICMP Parameter Problem 528 message, Code 0, should be sent to the packet's source, pointing 529 to the Option Type field of the Jumbo Payload option. 531 The Jumbo Payload option must not be used in a packet that 532 carries a Fragment header. If a Fragment header is encountered 533 in a packet that contains a valid Jumbo Payload option, an ICMP 534 Parameter Problem message, Code 0, should be sent to the packet's 535 source, pointing to the first octet of the Fragment header. 537 An implementation that does not support the Jumbo Payload option 538 cannot have interfaces to links whose link MTU is greater than 539 65,575 (40 octets of IPv6 header plus 65,535 octets of payload). 541 4.4 Routing Header 543 The Routing header is used by an IPv6 source to list one or more 544 intermediate nodes to be "visited" on the way to a packet's 545 destination. This function is very similar to IPv4's Source Route 546 options. The Routing header is identified by a Next Header value of 547 43 in the immediately preceding header, and has the 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 | Strict/Loose Bit Map | 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, and must 646 be an even number less than or equal to 46. 648 Routing Type 0. 650 Segments Left 8-bit unsigned integer. Number of route 651 segments remaining, i.e., number of explicitly 652 listed intermediate nodes still to be visited 653 before reaching the final destination. 654 Maximum legal value = 23. 656 Reserved 8-bit reserved field. Initialized to zero for 657 transmission; ignored on reception. 659 Strict/Loose Bit Map 660 24-bit bit map, numbered 0 to 23, left-to-right. 661 Indicates, for each segment of the route, whether 662 or not the next destination address must be a 663 neighbor of the preceding address: 1 means strict 664 (must be a neighbor), 0 means loose (need not be 665 a neighbor). 667 Address[1..n] Vector of 128-bit addresses, numbered 1 to n. 669 Multicast addresses must not appear in a Routing header of Type 0, or 670 in the IPv6 Destination Address field of a packet carrying a Routing 671 header of Type 0. 673 If bit number 0 of the Strict/Loose Bit Map has value 1, the 674 Destination Address field of the IPv6 header in the original packet 675 must identify a neighbor of the originating node. If bit number 0 676 has value 0, the originator may use any legal, non-multicast address 677 as the initial Destination Address. 679 Bits numbered greater than n, where n is the number of addresses in 680 the Routing header, must be set to 0 by the originator and ignored by 681 receivers. 683 A Routing header is not examined or processed until it reaches the 684 node identified in the Destination Address field of the IPv6 header. 685 In that node, dispatching on the Next Header field of the immediately 686 preceding header causes the Routing header module to be invoked, 687 which, in the case of Routing Type 0, performs the following 688 algorithm: 690 if Segments Left = 0 { 691 proceed to process the next header in the packet, whose type is 692 identified by the Next Header field in the Routing header 693 } 694 else if Hdr Ext Len is odd or greater than 46 { 695 send an ICMP Parameter Problem, Code 0, message to the Source 696 Address, pointing to the Hdr Ext Len field, and discard the 697 packet 698 } 699 else { 700 compute n, the number of addresses in the Routing header, by 701 dividing Hdr Ext Len by 2 703 if Segments Left is greater than n { 704 send an ICMP Parameter Problem, Code 0, message to the Source 705 Address, pointing to the Segments Left field, and discard the 706 packet 707 } 708 else { 709 decrement Segments Left by 1; 710 compute i, the index of the next address to be visited in 711 the address vector, by subtracting Segments Left from n 713 if Address [i] or the IPv6 Destination Address is multicast { 714 discard the packet 715 } 716 else { 717 swap the IPv6 Destination Address and Address[i] 719 if bit i of the Strict/Loose Bit Map has value 1 and the 720 new Destination Address is not the address of a neighbor 721 of this node { 722 send an ICMP Destination Unreachable -- Not a Neighbor 723 message to the Source Address and discard the packet 724 } 725 else if the IPv6 Hop Limit is less than or equal to 1 { 726 send an ICMP Time Exceeded -- Hop Limit Exceeded in 727 Transit message to the Source Address and discard the 728 packet 729 } 730 else { 731 decrement the Hop Limit by 1 733 resubmit the packet to the IPv6 module for transmission 734 to the new destination 735 } 736 } 737 } 738 } 739 As an example of the effects of the above algorithm, consider the 740 case of a source node S sending a packet to destination node D, using 741 a Routing header to cause the packet to be routed via intermediate 742 nodes I1, I2, and I3. The values of the relevant IPv6 header and 743 Routing header fields on each segment of the delivery path would be 744 as follows: 746 As the packet travels from S to I1: 748 Source Address = S Hdr Ext Len = 6 749 Destination Address = I1 Segments Left = 3 750 Address[1] = I2 751 (if bit 0 of the Bit Map is 1, Address[2] = I3 752 S and I1 must be neighbors; Address[3] = D 753 this is checked by S) 755 As the packet travels from I1 to I2: 757 Source Address = S Hdr Ext Len = 6 758 Destination Address = I2 Segments Left = 2 759 Address[1] = I1 760 (if bit 1 of the Bit Map is 1, Address[2] = I3 761 I1 and I2 must be neighbors; Address[3] = D 762 this is checked by I1) 764 As the packet travels from I2 to I3: 766 Source Address = S Hdr Ext Len = 6 767 Destination Address = I3 Segments Left = 1 768 Address[1] = I1 769 (if bit 2 of the Bit Map is 1, Address[2] = I2 770 I2 and I3 must be neighbors; Address[3] = D 771 this is checked by I2) 773 As the packet travels from I3 to D: 775 Source Address = S Hdr Ext Len = 6 776 Destination Address = D Segments Left = 0 777 Address[1] = I1 778 (if bit 3 of the Bit Map is 1, Address[2] = I2 779 I3 and D must be neighbors; Address[3] = I3 780 this is checked by I3) 782 4.5 Fragment Header 784 The Fragment header is used by an IPv6 source to send packets larger 785 than would fit in the path MTU to their destinations. (Note: unlike 786 IPv4, fragmentation in IPv6 is performed only by source nodes, not by 787 routers along a packet's delivery path -- see section 5.) The 788 Fragment header is identified by a Next Header value of 44 in the 789 immediately preceding header, and has the following format: 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Next Header | Reserved | Fragment Offset |Res|M| 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Identification | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 Next Header 8-bit selector. Identifies the initial header 798 type of the Fragmentable Part of the original 799 packet (defined below). Uses the same values 800 as the IPv4 Protocol field [RFC-1700 et seq.]. 802 Reserved 8-bit reserved field. Initialized to zero for 803 transmission; ignored on reception. 805 Fragment Offset 13-bit unsigned integer. The offset, in 8-octet 806 units, of the data following this header, 807 relative to the start of the Fragmentable Part 808 of the original packet. 810 Res 2-bit reserved field. Initialized to zero for 811 transmission; ignored on reception. 813 M flag 1 = more fragments; 0 = last fragment. 815 Identification 32 bits. See description below. 817 In order to send a packet that is too large to fit in the MTU of the 818 path to its destination, a source node may divide the packet into 819 fragments and send each fragment as a separate packet, to be 820 reassembled at the receiver. 822 For every packet that is to be fragmented, the source node generates 823 an Identification value. The Identification must be different than 824 that of any other fragmented packet sent recently* with the same 825 Source Address and Destination Address. If a Routing header is 826 present, the Destination Address of concern is that of the final 827 destination. 829 * "recently" means within the maximum likely lifetime of a packet, 830 including transit time from source to destination and time spent 831 awaiting reassembly with other fragments of the same packet. 832 However, it is not required that a source node know the maximum 833 packet lifetime. Rather, it is assumed that the requirement can 834 be met by maintaining the Identification value as a simple, 835 32-bit, "wrap-around" counter, incremented each time a packet 836 must be fragmented. It is an implementation choice whether to 837 maintain a single counter for the node or multiple counters, 838 e.g., one for each of the node's possible source addresses, or 839 one for each active (source address, destination address) 840 combination. 842 The initial, large, unfragmented packet is referred to as the 843 "original packet", and it is considered to consist of two parts, as 844 illustrated: 846 original packet: 848 +------------------+----------------------//-----------------------+ 849 | Unfragmentable | Fragmentable | 850 | Part | Part | 851 +------------------+----------------------//-----------------------+ 853 The Unfragmentable Part consists of the IPv6 header plus any 854 extension headers that must be processed by nodes en route to the 855 destination, that is, all headers up to and including the Routing 856 header if present, else the Hop-by-Hop Options header if present, 857 else no extension headers. 859 The Fragmentable Part consists of the rest of the packet, that is, 860 any extension headers that need be processed only by the final 861 destination node(s), plus the upper-layer header and data. 863 The Fragmentable Part of the original packet is divided into 864 fragments, each, except possibly the last ("rightmost") one, being an 865 integer multiple of 8 octets long. The fragments are transmitted in 866 separate "fragment packets" as illustrated: 868 original packet: 870 +------------------+--------------+--------------+--//--+----------+ 871 | Unfragmentable | first | second | | last | 872 | Part | fragment | fragment | .... | fragment | 873 +------------------+--------------+--------------+--//--+----------+ 874 fragment packets: 876 +------------------+--------+--------------+ 877 | Unfragmentable |Fragment| first | 878 | Part | Header | fragment | 879 +------------------+--------+--------------+ 881 +------------------+--------+--------------+ 882 | Unfragmentable |Fragment| second | 883 | Part | Header | fragment | 884 +------------------+--------+--------------+ 885 o 886 o 887 o 888 +------------------+--------+----------+ 889 | Unfragmentable |Fragment| last | 890 | Part | Header | fragment | 891 +------------------+--------+----------+ 893 Each fragment packet is composed of: 895 (1) The Unfragmentable Part of the original packet, with the 896 Payload Length of the original IPv6 header changed to contain 897 the length of this fragment packet only (excluding the length 898 of the IPv6 header itself), and the Next Header field of the 899 last header of the Unfragmentable Part changed to 44. 901 (2) A Fragment header containing: 903 The Next Header value that identifies the first header of 904 the Fragmentable Part of the original packet. 906 A Fragment Offset containing the offset of the fragment, 907 in 8-octet units, relative to the start of the 908 Fragmentable Part of the original packet. The Fragment 909 Offset of the first ("leftmost") fragment is 0. 911 An M flag value of 0 if the fragment is the last 912 ("rightmost") one, else an M flag value of 1. 914 The Identification value generated for the original 915 packet. 917 (3) The fragment itself. 919 The lengths of the fragments must be chosen such that the resulting 920 fragment packets fit within the MTU of the path to the packets' 921 destination(s). 923 At the destination, fragment packets are reassembled into their 924 original, unfragmented form, as illustrated: 926 reassembled original packet: 928 +------------------+----------------------//------------------------+ 929 | Unfragmentable | Fragmentable | 930 | Part | Part | 931 +------------------+----------------------//------------------------+ 933 The following rules govern reassembly: 935 An original packet is reassembled only from fragment packets that 936 have the same Source Address, Destination Address, and Fragment 937 Identification. 939 The Unfragmentable Part of the reassembled packet consists of all 940 headers up to, but not including, the Fragment header of the first 941 fragment packet (that is, the packet whose Fragment Offset is 942 zero), with the following two changes: 944 The Next Header field of the last header of the Unfragmentable 945 Part is obtained from the Next Header field of the first 946 fragment's Fragment header. 948 The Payload Length of the reassembled packet is computed from 949 the length of the Unfragmentable Part and the length and offset 950 of the last fragment. For example, a formula for computing the 951 Payload Length of the reassembled original packet is: 953 PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last 955 where 956 PL.orig = Payload Length field of reassembled packet. 957 PL.first = Payload Length field of first fragment packet. 958 FL.first = length of fragment following Fragment header of 959 first fragment packet. 960 FO.last = Fragment Offset field of Fragment header of 961 last fragment packet. 962 FL.last = length of fragment following Fragment header of 963 last fragment packet. 965 The Fragmentable Part of the reassembled packet is constructed 966 from the fragments following the Fragment headers in each of the 967 fragment packets. The length of each fragment is computed by 968 subtracting from the packet's Payload Length the length of the 969 headers between the IPv6 header and fragment itself; its relative 970 position in Fragmentable Part is computed from its Fragment Offset 971 value. 973 The Fragment header is not present in the final, reassembled 974 packet. 976 The following error conditions may arise when reassembling fragmented 977 packets: 979 If insufficient fragments are received to complete reassembly of a 980 packet within 60 seconds of the reception of the first-arriving 981 fragment of that packet, reassembly of that packet must be 982 abandoned and all the fragments that have been received for that 983 packet must be discarded. If the first fragment (i.e., the one 984 with a Fragment Offset of zero) has been received, an ICMP Time 985 Exceeded -- Fragment Reassembly Time Exceeded message should be 986 sent to the source of that fragment. 988 If the length of a fragment, as derived from the fragment packet's 989 Payload Length field, is not a multiple of 8 octets and the M flag 990 of that fragment is 1, then that fragment must be discarded and an 991 ICMP Parameter Problem, Code 0, message should be sent to the 992 source of the fragment, pointing to the Payload Length field of 993 the fragment packet. 995 If the length and offset of a fragment are such that the Payload 996 Length of the packet reassembled from that fragment would exceed 997 65,535 octets, then that fragment must be discarded and an ICMP 998 Parameter Problem, Code 0, message should be sent to the source of 999 the fragment, pointing to the Fragment Offset field of the 1000 fragment packet. 1002 The following conditions are not expected to occur, but are not 1003 considered errors if they do: 1005 The number and content of the headers preceding the Fragment 1006 header of different fragments of the same original packet may 1007 differ. Whatever headers are present, preceding the Fragment 1008 header in each fragment packet, are processed when the packets 1009 arrive, prior to queueing the fragments for reassembly. Only 1010 those headers in the Offset zero fragment packet are retained in 1011 the reassembled packet. 1013 The Next Header values in the Fragment headers of different 1014 fragments of the same original packet may differ. Only the value 1015 from the Offset zero fragment packet is used for reassembly. 1017 4.6 Destination Options Header 1019 The Destination Options header is used to carry optional information 1020 that need be examined only by a packet's destination node(s). The 1021 Destination Options header is identified by a Next Header value of 60 1022 in the immediately preceding header, and has the following format: 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Next Header | Hdr Ext Len | | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1027 | | 1028 . . 1029 . Options . 1030 . . 1031 | | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 Next Header 8-bit selector. Identifies the type of header 1035 immediately following the Destination Options 1036 header. Uses the same values as the IPv4 1037 Protocol field [RFC-1700 et seq.]. 1039 Hdr Ext Len 8-bit unsigned integer. Length of the 1040 Destination Options header in 8-octet units, 1041 not including the first 8 octets. 1043 Options Variable-length field, of length such that the 1044 complete Destination Options header is an 1045 integer multiple of 8 octets long. Contains 1046 one or more TLV-encoded options, as described 1047 in section 4.2. 1049 The only destination options defined in this document are the Pad1 1050 and PadN options specified in section 4.2. 1052 Note that there are two possible ways to encode optional destination 1053 information in an IPv6 packet: either as an option in the Destination 1054 Options header, or as a separate extension header. The Fragment 1055 header and the Authentication header are examples of the latter 1056 approach. Which approach can be used depends on what action is 1057 desired of a destination node that does not understand the optional 1058 information: 1060 o If the desired action is for the destination node to discard 1061 the packet and, only if the packet's Destination Address is not 1062 a multicast address, send an ICMP Unrecognized Type message to 1063 the packet's Source Address, then the information may be 1064 encoded either as a separate header or as an option in the 1065 Destination Options header whose Option Type has the value 11 1066 in its highest-order two bits. The choice may depend on such 1067 factors as which takes fewer octets, or which yields better 1068 alignment or more efficient parsing. 1070 o If any other action is desired, the information must be encoded 1071 as an option in the Destination Options header whose Option 1072 Type has the value 00, 01, or 10 in its highest-order two bits, 1073 specifying the desired action (see section 4.2). 1075 4.7 No Next Header 1077 The value 59 in the Next Header field of an IPv6 header or any 1078 extension header indicates that there is nothing following that 1079 header. If the Payload Length field of the IPv6 header indicates the 1080 presence of octets past the end of a header whose Next Header field 1081 contains 59, those octets must be ignored, and passed on unchanged if 1082 the packet is forwarded. 1084 5. Packet Size Issues 1086 IPv6 requires that every link in the internet have an MTU of 576 1087 octets or greater. On any link that cannot convey a 576-octet packet 1088 in one piece, link-specific fragmentation and reassembly must be 1089 provided at a layer below IPv6. 1091 From each link to which a node is directly attached, the node must 1092 be able to accept packets as large as that link's MTU. Links that 1093 have a configurable MTU (for example, PPP links [RFC-1661]) must be 1094 configured to have an MTU of at least 576 octets; it is recommended 1095 that a larger MTU be configured, to accommodate possible 1096 encapsulations (i.e., tunneling) without incurring fragmentation. 1098 It is strongly recommended that IPv6 nodes implement Path MTU 1099 Discovery [RFC-1191], in order to discover and take advantage of 1100 paths with MTU greater than 576 octets. However, a minimal IPv6 1101 implementation (e.g., in a boot ROM) may simply restrict itself to 1102 sending packets no larger than 576 octets, and omit implementation of 1103 Path MTU Discovery. 1105 In order to send a packet larger than a path's MTU, a node may use 1106 the IPv6 Fragment header to fragment the packet at the source and 1107 have it reassembled at the destination(s). However, the use of such 1108 fragmentation is discouraged in any application that is able to 1109 adjust its packets to fit the measured path MTU (i.e., down to 576 1110 octets). 1112 A node must be able to accept a fragmented packet that, after 1113 reassembly, is as large as 1500 octets, including the IPv6 header. A 1114 node is permitted to accept fragmented packets that reassemble to 1115 more than 1500 octets. However, a node must not send fragments that 1116 reassemble to a size greater than 1500 octets unless it has explicit 1117 knowledge that the destination(s) can reassemble a packet of that 1118 size. 1120 In response to an IPv6 packet that is sent to an IPv4 destination 1121 (i.e., a packet that undergoes translation from IPv6 to IPv4), the 1122 originating IPv6 node may receive an ICMP Packet Too Big message 1123 reporting a Next-Hop MTU less than 576. In that case, the IPv6 node 1124 is not required to reduce the size of subsequent packets to less than 1125 576, but must include a Fragment header in those packets so that the 1126 IPv6-to-IPv4 translating router can obtain a suitable Identification 1127 value to use in resulting IPv4 fragments. Note that this means the 1128 payload may have to be reduced to 528 octets (576 minus 40 for the 1129 IPv6 header and 8 for the Fragment header), and smaller still if 1130 additional extension headers are used. 1132 Note: Path MTU Discovery must be performed even in cases where a 1133 host "thinks" a destination is attached to the same link as 1134 itself. 1136 Note: Unlike IPv4, it is unnecessary in IPv6 to set a "Don't 1137 Fragment" flag in the packet header in order to perform Path MTU 1138 Discovery; that is an implicit attribute of every IPv6 packet. 1139 Also, those parts of the RFC-1191 procedures that involve use of 1140 a table of MTU "plateaus" do not apply to IPv6, because the IPv6 1141 version of the "Datagram Too Big" message always identifies the 1142 exact MTU to be used. 1144 6. Flow Labels 1146 The 24-bit Flow Label field in the IPv6 header may be used by a 1147 source to label those packets for which it requests special handling 1148 by the IPv6 routers, such as non-default quality of service or "real- 1149 time" service. This aspect of IPv6 is, at the time of writing, still 1150 experimental and subject to change as the requirements for flow 1151 support in the Internet become clearer. Hosts or routers that do not 1152 support the functions of the Flow Label field are required to set the 1153 field to zero when originating a packet, pass the field on unchanged 1154 when forwarding a packet, and ignore the field when receiving a 1155 packet. 1157 A flow is a sequence of packets sent from a particular source to a 1158 particular (unicast or multicast) destination for which the source 1159 desires special handling by the intervening routers. The nature of 1160 that special handling might be conveyed to the routers by a control 1161 protocol, such as a resource reservation protocol, or by information 1162 within the flow's packets themselves, e.g., in a hop-by-hop option. 1163 The details of such control protocols or options are beyond the scope 1164 of this document. 1166 There may be multiple active flows from a source to a destination, as 1167 well as traffic that is not associated with any flow. A flow is 1168 uniquely identified by the combination of a source address and a non- 1169 zero flow label. Packets that do not belong to a flow carry a flow 1170 label of zero. 1172 A flow label is assigned to a flow by the flow's source node. New 1173 flow labels must be chosen (pseudo-)randomly and uniformly from the 1174 range 1 to FFFFFF hex. The purpose of the random allocation is to 1175 make any set of bits within the Flow Label field suitable for use as 1176 a hash key by routers, for looking up the state associated with the 1177 flow. 1179 All packets belonging to the same flow must be sent with the same 1180 source address, destination address, and flow label. If any of those 1181 packets includes a Hop-by-Hop Options header, then they all must be 1182 originated with the same Hop-by-Hop Options header contents 1183 (excluding the Next Header field of the Hop-by-Hop Options header). 1184 If any of those packets includes a Routing header, then they all must 1185 be originated with the same contents in all extension headers up to 1186 and including the Routing header (excluding the Next Header field in 1187 the Routing header). The routers or destinations are permitted, but 1188 not required, to verify that these conditions are satisfied. If a 1189 violation is detected, it should be reported to the source by an ICMP 1190 Parameter Problem message, Code 0, pointing to the high-order octet 1191 of the Flow Label field (i.e., offset 1 within the IPv6 packet). 1193 Routers are free to "opportunistically" set up flow-handling state 1194 for any flow, even when no explicit flow establishment information 1195 has been provided to them via a control protocol, a hop-by-hop 1196 option, or other means. For example, upon receiving a packet from a 1197 particular source with an unknown, non-zero flow label, a router may 1198 process its IPv6 header and any necessary extension headers as if the 1199 flow label were zero. That processing would include determining the 1200 next-hop interface, and possibly other actions, such as updating a 1201 hop-by-hop option, advancing the pointer and addresses in a Routing 1202 header, or deciding on how to queue the packet based on its Class 1203 field. The router may then choose to "remember" the results of those 1204 processing steps and cache that information, using the source address 1205 plus the flow label as the cache key. Subsequent packets with the 1206 same source address and flow label may then be handled by referring 1207 to the cached information rather than examining all those fields 1208 that, according to the requirements of the previous paragraph, can be 1209 assumed unchanged from the first packet seen in the flow. 1211 Cached flow-handling state that is set up opportunistically, as 1212 discussed in the preceding paragraph, must be discarded no more than 1213 6 seconds after it is established, regardless of whether or not 1214 packets of the same flow continue to arrive. If another packet with 1215 the same source address and flow label arrives after the cached state 1216 has been discarded, the packet undergoes full, normal processing (as 1217 if its flow label were zero), which may result in the re-creation of 1218 cached flow state for that flow. 1220 The lifetime of flow-handling state that is set up explicitly, for 1221 example by a control protocol or a hop-by-hop option, must be 1222 specified as part of the specification of the explicit set-up 1223 mechanism; it may exceed 6 seconds. 1225 A source must not re-use a flow label for a new flow within the 1226 lifetime of any flow-handling state that might have been established 1227 for the prior use of that flow label. Since flow-handling state with 1228 a lifetime of 6 seconds may be established opportunistically for any 1229 flow, the minimum interval between the last packet of one flow and 1230 the first packet of a new flow using the same flow label is 6 1231 seconds. Flow labels used for explicitly set-up flows with longer 1232 flow-state lifetimes must remain unused for those longer lifetimes 1233 before being re-used for new flows. 1235 When a node stops and restarts (e.g., as a result of a "crash"), it 1236 must be careful not to use a flow label that it might have used for 1237 an earlier flow whose lifetime may not have expired yet. This may be 1238 accomplished by recording flow label usage on stable storage so that 1239 it can be remembered across crashes, or by refraining from using any 1240 flow labels until the maximum lifetime of any possible previously 1241 established flows has expired (at least 6 seconds; more if explicit 1242 flow set-up mechanisms with longer lifetimes might have been used). 1243 If the minimum time for rebooting the node is known (often more than 1244 6 seconds), that time can be deducted from the necessary waiting 1245 period before starting to allocate flow labels. 1247 There is no requirement that all, or even most, packets belong to 1248 flows, i.e., carry non-zero flow labels. This observation is placed 1249 here to remind protocol designers and implementors not to assume 1250 otherwise. For example, it would be unwise to design a router whose 1251 performance would be adequate only if most packets belonged to flows, 1252 or to design a header compression scheme that only worked on packets 1253 that belonged to flows. 1255 7. Traffic Classes 1257 The 4-bit Class field in the IPv6 header is available for use by 1258 originating nodes and/or forwarding routers to identify and 1259 distinguish between different classes or priorities of IPv6 packets. 1260 At the point in time at which this specification is being written, 1261 there are a number of experiments underway in the use of the IPv4 1262 Type of Service and Precedence bits to provide various forms of 1263 "differentiated service" for IP packets, other than through the use 1264 of explicit flow set-up. The Class field in the IPv6 header is 1265 intended to allow similar experiments to be conducted in IPv6. It is 1266 hoped that those experiments will eventually lead to agreement on 1267 what sorts of traffic classifications are most useful for IP packets. 1268 Until that time, any usage of the Class bits must be considered 1269 provisional and subject to possible change in the future. 1271 The following general requirements apply to the bits of the Class 1272 field: 1274 o The service interface to the IPv6 service within a node must 1275 provide a means for an upper-layer protocol to supply the value 1276 of the Class bits in packets originated by that upper-layer 1277 protocol. The default value must be zero for all 4 bits. 1279 o Routers, when forwarding a packet, are permitted to change the 1280 value of any of the Class bits in that packet. 1282 o Receivers must not assume that the value of the Class bits in a 1283 received packet are the same as the value sent by the packet's 1284 source. 1286 Until otherwise specified, the Class field should be treated as being 1287 internally subdivided into two subfields, a 1-bit delay sensitivity 1288 ("D") flag and a 3-bit Priority subfield, as follows: 1290 +-+-+-+-+ 1291 |D|Prio.| 1292 +-+-+-+-+ 1294 The D bit may set to one by packet originators to identify packets 1295 for which minimizing delivery delay is much more important than 1296 maximizing throughput. It is intended for interpretation by routers 1297 that forward packets onto very low-speed links (e.g., 14.4 or 28.8 1298 Kb/s modem links), where queueing small, interactive packets, such as 1299 those carrying keystrokes, keystroke echoes, and mouse clicks, in 1300 front of other traffic can greatly improve end-to-end interactive 1301 responsiveness. The D bit may also influence the choice of a 1302 packet's delivery path by routers that support multiple "type of 1303 service" routes, for example, for choosing between a low-speed, low- 1304 delay path or a higher speed but higher delay path. 1306 It is expected that routers that give preferential queueing or 1307 routing to packets with the D bit set will also limit the throughput 1308 of such packets to some fraction of the throughput available to 1309 packets that do not have the D bit set, to discourage applications 1310 from simply turning the bit on in all packets (and thereby defeating 1311 the purpose of the bit). Thus, an application that sends packets 1312 with the D bit set is indicating a willingness to give up throughput 1313 in order to achieve lower delivery delay for those packets. Since 1314 the primary intended use of the D bit is for giving preferential 1315 treatment to packets being forwarded over very low-speed links (on 1316 the order of 10s of kilobits per second), and since those packets are 1317 likely to be limited to a small fraction of the throughput of those 1318 links, it is recommended that the bit be set only on packets for 1319 which throughput of only a few kilobits per second is acceptable. 1321 It is strongly recommended, but not required, that routers leave the 1322 D bit unchanged in packets that they forward. Since the D bit may be 1323 used in route selection, care must be taken to prevent packet looping 1324 that might occur if the bit were to be alternatively set and cleared 1325 by different routers along a packet's delivery path. 1327 The 3-bit Priority subfield is expected to be used primarily by 1328 routers to indicate the relative priority of packets they originate 1329 and/or forward. For example, the border routers of an Internet 1330 Service Provider's routing domain might be configured to set the 1331 Priority bits of all packets arriving from customers according to the 1332 service levels being offered to those customers, and the routers 1333 within the domain might be configured to mark all routing protocol 1334 packets with a priority higher than any customer packets. There may 1335 also be uses of the Priority field in which originating applications 1336 are configured, or instructed via a protocol, to send certain packets 1337 with particular values in the Priority subfield, though that subfield 1338 may subsequently be overwritten by routers along the packets' 1339 delivery paths, for example, if the packets cross into different 1340 routing domains. 1342 By default, the Priority subfield should be treated as a 3-bit 1343 unsigned integer, with higher values meaning higher priority. 1344 However, a particular experimental use of the Priority subfield might 1345 entail a different interpretation of those 3 bits, for example, 1346 treating them as independent flag bits. 1348 8. Upper-Layer Protocol Issues 1350 8.1 Upper-Layer Checksums 1352 Any transport or other upper-layer protocol that includes the 1353 addresses from the IP header in its checksum computation must be 1354 modified for use over IPv6, to include the 128-bit IPv6 addresses 1355 instead of 32-bit IPv4 addresses. In particular, the following 1356 illustration shows the TCP and UDP "pseudo-header" for IPv6: 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | | 1360 + + 1361 | | 1362 + Source Address + 1363 | | 1364 + + 1365 | | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | | 1368 + + 1369 | | 1370 + Destination Address + 1371 | | 1372 + + 1373 | | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Upper-Layer Packet Length | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | zero | Next Header | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 o If the IPv6 packet contains a Routing header, the Destination 1381 Address used in the pseudo-header is that of the final 1382 destination. At the originating node, that address will be in 1383 the last element of the Routing header; at the recipient(s), 1384 that address will be in the Destination Address field of the 1385 IPv6 header. 1387 o The Next Header value in the pseudo-header identifies the 1388 upper-layer protocol (e.g., 6 for TCP, or 17 for UDP). It will 1389 differ from the Next Header value in the IPv6 header if there 1390 are extension headers between the IPv6 header and the upper- 1391 layer header. 1393 o The Upper-Layer Packet Length in the pseudo-header is the 1394 length of the upper-layer header and data (e.g., TCP header 1395 plus TCP data). Some upper-layer protocols carry their own 1396 length information (e.g., the Length field in the UDP header of 1397 non-jumbogram UDP packets); for such protocols, that is the 1398 length used in the pseudo-header. Other protocols (such as 1399 TCP) do not carry their own length information, in which case 1400 the length used in the pseudo-header is the Payload Length from 1401 the IPv6 header (or from the Jumbo Payload option), minus the 1402 length of any extension headers present between the IPv6 header 1403 and the upper-layer header. 1405 o Unlike IPv4, when UDP packets are originated by an IPv6 node, 1406 the UDP checksum is not optional. That is, whenever 1407 originating a UDP packet, an IPv6 node must compute a UDP 1408 checksum over the packet and the pseudo-header, and, if that 1409 computation yields a result of zero, it must be changed to hex 1410 FFFF for placement in the UDP header. IPv6 receivers must 1411 discard UDP packets containing a zero checksum, and should log 1412 the error. 1414 The IPv6 version of ICMP [RFC-1885] includes the above pseudo-header 1415 in its checksum computation; this is a change from the IPv4 version 1416 of ICMP, which does not include a pseudo-header in its checksum. The 1417 reason for the change is to protect ICMP from misdelivery or 1418 corruption of those fields of the IPv6 header on which it depends, 1419 which, unlike IPv4, are not covered by an internet-layer checksum. 1420 The Next Header field in the pseudo-header for ICMP contains the 1421 value 58, which identifies the IPv6 version of ICMP. 1423 8.2 Maximum Packet Lifetime 1425 Unlike IPv4, IPv6 nodes are not required to enforce maximum packet 1426 lifetime. That is the reason the IPv4 "Time to Live" field was 1427 renamed "Hop Limit" in IPv6. In practice, very few, if any, IPv4 1428 implementations conform to the requirement that they limit packet 1429 lifetime, so this is not a change in practice. Any upper-layer 1430 protocol that relies on the internet layer (whether IPv4 or IPv6) to 1431 limit packet lifetime ought to be upgraded to provide its own 1432 mechanisms for detecting and discarding obsolete packets. 1434 8.3 Maximum Upper-Layer Payload Size 1436 When computing the maximum payload size available for upper-layer 1437 data, an upper-layer protocol must take into account the larger size 1438 of the IPv6 header relative to the IPv4 header. For example, in 1439 IPv4, TCP's MSS option is computed as the maximum packet size (a 1440 default value or a value learned through Path MTU Discovery) minus 40 1441 octets (20 octets for the minimum-length IPv4 header and 20 octets 1442 for the minimum-length TCP header). When using TCP over IPv6, the 1443 MSS must be computed as the maximum packet size minus 60 octets, 1444 because the minimum-length IPv6 header (i.e., an IPv6 header with no 1445 extension headers) is 20 octets longer than a minimum-length IPv4 1446 header. 1448 8.4 Responding to Packets Carrying Routing Headers 1450 When an upper-layer protocol sends one or more packets in response to 1451 a received packet that included a Routing header, the response 1452 packet(s) must not include a Routing header that was automatically 1453 derived by "reversing" the received Routing header UNLESS the 1454 integrity and authenticity of the received Source Address and Routing 1455 header have been verified (e.g., via the use of an Authentication 1456 header in the received packet). In other words, only the following 1457 kinds of packets are permitted in response to a received packet 1458 bearing a Routing header: 1460 o Response packets that do not carry Routing headers. 1462 o Response packets that carry Routing headers that were NOT 1463 derived by reversing the Routing header of the received packet 1464 (for example, a Routing header supplied by local 1465 configuration). 1467 o Response packets that carry Routing headers that were derived 1468 by reversing the Routing header of the received packet IF AND 1469 ONLY IF the integrity and authenticity of the Source Address 1470 and Routing header from the received packet have been verified 1471 by the responder. 1473 Appendix A. Formatting Guidelines for Options 1475 This appendix gives some advice on how to lay out the fields when 1476 designing new options to be used in the Hop-by-Hop Options header or 1477 the Destination Options header, as described in section 4.2. These 1478 guidelines are based on the following assumptions: 1480 o One desirable feature is that any multi-octet fields within the 1481 Option Data area of an option be aligned on their natural 1482 boundaries, i.e., fields of width n octets should be placed at 1483 an integer multiple of n octets from the start of the Hop-by- 1484 Hop or Destination Options header, for n = 1, 2, 4, or 8. 1486 o Another desirable feature is that the Hop-by-Hop or Destination 1487 Options header take up as little space as possible, subject to 1488 the requirement that the header be an integer multiple of 8 1489 octets long. 1491 o It may be assumed that, when either of the option-bearing 1492 headers are present, they carry a very small number of options, 1493 usually only one. 1495 These assumptions suggest the following approach to laying out the 1496 fields of an option: order the fields from smallest to largest, with 1497 no interior padding, then derive the alignment requirement for the 1498 entire option based on the alignment requirement of the largest field 1499 (up to a maximum alignment of 8 octets). This approach is 1500 illustrated in the following examples: 1502 Example 1 1504 If an option X required two data fields, one of length 8 octets and 1505 one of length 4 octets, it would be laid out as follows: 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | Option Type=X |Opt Data Len=12| 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 | 4-octet field | 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 | | 1513 + 8-octet field + 1514 | | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 Its alignment requirement is 8n+2, to ensure that the 8-octet field 1518 starts at a multiple-of-8 offset from the start of the enclosing 1519 header. A complete Hop-by-Hop or Destination Options header 1520 containing this one option would look as follows: 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | Next Header | Hdr Ext Len=1 | Option Type=X |Opt Data Len=12| 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | 4-octet field | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | | 1528 + 8-octet field + 1529 | | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 Example 2 1534 If an option Y required three data fields, one of length 4 octets, 1535 one of length 2 octets, and one of length 1 octet, it would be laid 1536 out as follows: 1538 +-+-+-+-+-+-+-+-+ 1539 | Option Type=Y | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 |Opt Data Len=7 | 1-octet field | 2-octet field | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | 4-octet field | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 Its alignment requirement is 4n+3, to ensure that the 4-octet field 1547 starts at a multiple-of-4 offset from the start of the enclosing 1548 header. A complete Hop-by-Hop or Destination Options header 1549 containing this one option would look as follows: 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | Next Header | Hdr Ext Len=1 | Pad1 Option=0 | Option Type=Y | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 |Opt Data Len=7 | 1-octet field | 2-octet field | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | 4-octet field | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | PadN Option=1 |Opt Data Len=2 | 0 | 0 | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 Example 3 1562 A Hop-by-Hop or Destination Options header containing both options X 1563 and Y from Examples 1 and 2 would have one of the two following 1564 formats, depending on which option appeared first: 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | Next Header | Hdr Ext Len=3 | Option Type=X |Opt Data Len=12| 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 | 4-octet field | 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | | 1572 + 8-octet field + 1573 | | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | PadN Option=1 |Opt Data Len=1 | 0 | Option Type=Y | 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 |Opt Data Len=7 | 1-octet field | 2-octet field | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | 4-octet field | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | PadN Option=1 |Opt Data Len=2 | 0 | 0 | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | Next Header | Hdr Ext Len=3 | Pad1 Option=0 | Option Type=Y | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 |Opt Data Len=7 | 1-octet field | 2-octet field | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | 4-octet field | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | PadN Option=1 |Opt Data Len=4 | 0 | 0 | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | 0 | 0 | Option Type=X |Opt Data Len=12| 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | 4-octet field | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | | 1598 + 8-octet field + 1599 | | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 Security Considerations 1604 This document specifies that the IP Authentication Header [RFC-1826] 1605 and the IP Encapsulating Security Payload [RFC-1827] be used with 1606 IPv6, in conformance with the Security Architecture for the Internet 1607 Protocol [RFC-1825]. 1609 Acknowledgments 1611 The authors gratefully acknowledge the many helpful suggestions of 1612 the members of the IPng working group, the End-to-End Protocols 1613 research group, and the Internet Community At Large. 1615 Authors' Addresses 1617 Stephen E. Deering Robert M. Hinden 1618 Cisco Systems, Inc. Ipsilon Networks, Inc. 1619 170 West Tasman Drive 232 Java Drive 1620 San Jose, CA 95134-1706 Sunnyvale, CA 94089 1621 USA USA 1623 phone: +1 408 527 8213 phone: +1 408 990-2004 1624 fax: +1 408 527 8254 fax: +1 408 743-5677 1625 email: deering@cisco.com email: hinden@ipsilon.com 1627 References 1629 [RFC-1825] Atkinson, R., Security Architecture for the Internet 1630 Protocol, RFC-1825, August 1995. 1632 [RFC-1826] Atkinson, R., IP Authentication Header, RFC-1826, August 1633 1995. 1635 [RFC-1827] Atkinson, R., IP Encapsulating Security Protocol (ESP), 1636 RFC-1827, August 1995. 1638 [RFC-1885] Conta, A. and S. Deering, ICMP for the Internet Protocol 1639 Version 6 (IPv6), RFC-1885, December 1995. 1641 [ADDRARCH] Hinden, R., and S. Deering, IP Version 6 Addressing 1642 Architecture, Internet Draft, , July 1997. 1645 [RFC-1191] Mogul, J., and S. Deering, Path MTU Discovery, RFC-1191, 1646 November 1990. 1648 [RFC-791] Postel, J., Internet Protocol, RFC-791, September 1981. 1650 [RFC-1700] Reynolds, J., and J. Postel, Assigned Numbers, RFC-1700, 1651 October 1994. 1653 [RFC-1661] Simpson, W., The Point-to-Point Protocol (PPP), 1654 RFC-1548, April 1994. 1656 CHANGES SINCE RFC-1883 1658 This draft has the following changes from RFC-1883. Number indicates 1659 which version of internet draft the change was made. 1661 00) In section 4, corrected the Code value to indicate "unrecognized 1662 Next Header type encountered" in an ICMP Parameter Problem 1663 message (changed from 2 to 1). 1665 00) In the description of the Payload Length field in section 3, and 1666 of the Jumbo Payload Length field in section 4.3, made it 1667 clearer that extensions headers are included in the payload 1668 length count. 1670 00) In section 4.2, made it clearer that options are identified by 1671 the full 8-bit Option Type, not by the low-order 5 bits of an 1672 Option Type. Also specified that the same Option Type numbering 1673 space is used for both Hop-by-Hop Options and Destination 1674 Options headers. 1676 00) In section 4.4, added a sentence requiring that nodes processing 1677 a Routing header must send an ICMP Packet Too Big message in 1678 response to a packet that is too big to fit in the next hop link 1679 (rather than, say, performing fragmentation). 1681 00) Changed the name of the IPv6 Priority field to "Class", and 1682 replaced the previous description of Priority in section 7 with 1683 a description of the Class field. 1685 00) In the pseudo-header in section 8.1, changed the name of the 1686 "Payload Length" field to "Upper-Layer Packet Length". Also 1687 clarified that, in the case of protocols that carry their own 1688 length info (like non-jumbogram UDP), it is the upper-length- 1689 derived length, not the IP-layer-derived length, that is used in 1690 the pseudo-header. 1692 00) Added section 8.4, specifying that upper-layer protocols, when 1693 responding to a received packet that carried a Routing header, 1694 must not include the reverse of the Routing header in the 1695 response packet(s) unless the received Routing header was 1696 authenticated. 1698 00) Fixed some typos and grammatical errors. 1700 00) Authors' contact info updated.