1 2 3 4 5 6 7Network Working Group S. Deering 8Request for Comments: 2460 Cisco 9Obsoletes: 1883 R. Hinden 10Category: Standards Track Nokia 11 December 1998 12 13 14 Internet Protocol, Version 6 (IPv6) 15 Specification 16 17Status of this Memo 18 19 This document specifies an Internet standards track protocol for the 20 Internet community, and requests discussion and suggestions for 21 improvements. Please refer to the current edition of the "Internet 22 Official Protocol Standards" (STD 1) for the standardization state 23 and status of this protocol. Distribution of this memo is unlimited. 24 25Copyright Notice 26 27 Copyright (C) The Internet Society (1998). All Rights Reserved. 28 29Abstract 30 31 This document specifies version 6 of the Internet Protocol (IPv6), 32 also sometimes referred to as IP Next Generation or IPng. 33 34Table of Contents 35 36 1. Introduction..................................................2 37 2. Terminology...................................................3 38 3. IPv6 Header Format............................................4 39 4. IPv6 Extension Headers........................................6 40 4.1 Extension Header Order...................................7 41 4.2 Options..................................................9 42 4.3 Hop-by-Hop Options Header...............................11 43 4.4 Routing Header..........................................12 44 4.5 Fragment Header.........................................18 45 4.6 Destination Options Header..............................23 46 4.7 No Next Header..........................................24 47 5. Packet Size Issues...........................................24 48 6. Flow Labels..................................................25 49 7. Traffic Classes..............................................25 50 8. Upper-Layer Protocol Issues..................................27 51 8.1 Upper-Layer Checksums...................................27 52 8.2 Maximum Packet Lifetime.................................28 53 8.3 Maximum Upper-Layer Payload Size........................28 54 8.4 Responding to Packets Carrying Routing Headers..........29 55 56 57 58Deering & Hinden Standards Track [Page 1] 59 60RFC 2460 IPv6 Specification December 1998 61 62 63 Appendix A. Semantics and Usage of the Flow Label Field.........30 64 Appendix B. Formatting Guidelines for Options...................32 65 Security Considerations.........................................35 66 Acknowledgments.................................................35 67 Authors' Addresses..............................................35 68 References......................................................35 69 Changes Since RFC-1883..........................................36 70 Full Copyright Statement........................................39 71 721. Introduction 73 74 IP version 6 (IPv6) is a new version of the Internet Protocol, 75 designed as the successor to IP version 4 (IPv4) [RFC-791]. The 76 changes from IPv4 to IPv6 fall primarily into the following 77 categories: 78 79 o Expanded Addressing Capabilities 80 81 IPv6 increases the IP address size from 32 bits to 128 bits, to 82 support more levels of addressing hierarchy, a much greater 83 number of addressable nodes, and simpler auto-configuration of 84 addresses. The scalability of multicast routing is improved by 85 adding a "scope" field to multicast addresses. And a new type 86 of address called an "anycast address" is defined, used to send 87 a packet to any one of a group of nodes. 88 89 o Header Format Simplification 90 91 Some IPv4 header fields have been dropped or made optional, to 92 reduce the common-case processing cost of packet handling and 93 to limit the bandwidth cost of the IPv6 header. 94 95 o Improved Support for Extensions and Options 96 97 Changes in the way IP header options are encoded allows for 98 more efficient forwarding, less stringent limits on the length 99 of options, and greater flexibility for introducing new options 100 in the future. 101 102 o Flow Labeling Capability 103 104 A new capability is added to enable the labeling of packets 105 belonging to particular traffic "flows" for which the sender 106 requests special handling, such as non-default quality of 107 service or "real-time" service. 108 109 110 111 112 113 114Deering & Hinden Standards Track [Page 2] 115 116RFC 2460 IPv6 Specification December 1998 117 118 119 o Authentication and Privacy Capabilities 120 121 Extensions to support authentication, data integrity, and 122 (optional) data confidentiality are specified for IPv6. 123 124 This document specifies the basic IPv6 header and the initially- 125 defined IPv6 extension headers and options. It also discusses packet 126 size issues, the semantics of flow labels and traffic classes, and 127 the effects of IPv6 on upper-layer protocols. The format and 128 semantics of IPv6 addresses are specified separately in [ADDRARCH]. 129 The IPv6 version of ICMP, which all IPv6 implementations are required 130 to include, is specified in [ICMPv6]. 131 1322. Terminology 133 134 node - a device that implements IPv6. 135 136 router - a node that forwards IPv6 packets not explicitly 137 addressed to itself. [See Note below]. 138 139 host - any node that is not a router. [See Note below]. 140 141 upper layer - a protocol layer immediately above IPv6. Examples are 142 transport protocols such as TCP and UDP, control 143 protocols such as ICMP, routing protocols such as OSPF, 144 and internet or lower-layer protocols being "tunneled" 145 over (i.e., encapsulated in) IPv6 such as IPX, 146 AppleTalk, or IPv6 itself. 147 148 link - a communication facility or medium over which nodes can 149 communicate at the link layer, i.e., the layer 150 immediately below IPv6. Examples are Ethernets (simple 151 or bridged); PPP links; X.25, Frame Relay, or ATM 152 networks; and internet (or higher) layer "tunnels", 153 such as tunnels over IPv4 or IPv6 itself. 154 155 neighbors - nodes attached to the same link. 156 157 interface - a node's attachment to a link. 158 159 address - an IPv6-layer identifier for an interface or a set of 160 interfaces. 161 162 packet - an IPv6 header plus payload. 163 164 link MTU - the maximum transmission unit, i.e., maximum packet 165 size in octets, that can be conveyed over a link. 166 167 168 169 170Deering & Hinden Standards Track [Page 3] 171 172RFC 2460 IPv6 Specification December 1998 173 174 175 path MTU - the minimum link MTU of all the links in a path between 176 a source node and a destination node. 177 178 Note: it is possible, though unusual, for a device with multiple 179 interfaces to be configured to forward non-self-destined packets 180 arriving from some set (fewer than all) of its interfaces, and to 181 discard non-self-destined packets arriving from its other interfaces. 182 Such a device must obey the protocol requirements for routers when 183 receiving packets from, and interacting with neighbors over, the 184 former (forwarding) interfaces. It must obey the protocol 185 requirements for hosts when receiving packets from, and interacting 186 with neighbors over, the latter (non-forwarding) interfaces. 187 1883. IPv6 Header Format 189 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |Version| Traffic Class | Flow Label | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Payload Length | Next Header | Hop Limit | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | | 196 + + 197 | | 198 + Source Address + 199 | | 200 + + 201 | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | 204 + + 205 | | 206 + Destination Address + 207 | | 208 + + 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 212 Version 4-bit Internet Protocol version number = 6. 213 214 Traffic Class 8-bit traffic class field. See section 7. 215 216 Flow Label 20-bit flow label. See section 6. 217 218 Payload Length 16-bit unsigned integer. Length of the IPv6 219 payload, i.e., the rest of the packet following 220 this IPv6 header, in octets. (Note that any 221 222 223 224 225 226Deering & Hinden Standards Track [Page 4] 227 228RFC 2460 IPv6 Specification December 1998 229 230 231 extension headers [section 4] present are 232 considered part of the payload, i.e., included 233 in the length count.) 234 235 Next Header 8-bit selector. Identifies the type of header 236 immediately following the IPv6 header. Uses the 237 same values as the IPv4 Protocol field [RFC-1700 238 et seq.]. 239 240 Hop Limit 8-bit unsigned integer. Decremented by 1 by 241 each node that forwards the packet. The packet 242 is discarded if Hop Limit is decremented to 243 zero. 244 245 Source Address 128-bit address of the originator of the packet. 246 See [ADDRARCH]. 247 248 Destination Address 128-bit address of the intended recipient of the 249 packet (possibly not the ultimate recipient, if 250 a Routing header is present). See [ADDRARCH] 251 and section 4.4. 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282Deering & Hinden Standards Track [Page 5] 283 284RFC 2460 IPv6 Specification December 1998 285 286 2874. IPv6 Extension Headers 288 289 In IPv6, optional internet-layer information is encoded in separate 290 headers that may be placed between the IPv6 header and the upper- 291 layer header in a packet. There are a small number of such extension 292 headers, each identified by a distinct Next Header value. As 293 illustrated in these examples, an IPv6 packet may carry zero, one, or 294 more extension headers, each identified by the Next Header field of 295 the preceding header: 296 297 +---------------+------------------------ 298 | IPv6 header | TCP header + data 299 | | 300 | Next Header = | 301 | TCP | 302 +---------------+------------------------ 303 304 305 +---------------+----------------+------------------------ 306 | IPv6 header | Routing header | TCP header + data 307 | | | 308 | Next Header = | Next Header = | 309 | Routing | TCP | 310 +---------------+----------------+------------------------ 311 312 313 +---------------+----------------+-----------------+----------------- 314 | IPv6 header | Routing header | Fragment header | fragment of TCP 315 | | | | header + data 316 | Next Header = | Next Header = | Next Header = | 317 | Routing | Fragment | TCP | 318 +---------------+----------------+-----------------+----------------- 319 320 With one exception, extension headers are not examined or processed 321 by any node along a packet's delivery path, until the packet reaches 322 the node (or each of the set of nodes, in the case of multicast) 323 identified in the Destination Address field of the IPv6 header. 324 There, normal demultiplexing on the Next Header field of the IPv6 325 header invokes the module to process the first extension header, or 326 the upper-layer header if no extension header is present. The 327 contents and semantics of each extension header determine whether or 328 not to proceed to the next header. Therefore, extension headers must 329 be processed strictly in the order they appear in the packet; a 330 receiver must not, for example, scan through a packet looking for a 331 particular kind of extension header and process that header prior to 332 processing all preceding ones. 333 334 335 336 337 338Deering & Hinden Standards Track [Page 6] 339 340RFC 2460 IPv6 Specification December 1998 341 342 343 The exception referred to in the preceding paragraph is the Hop-by- 344 Hop Options header, which carries information that must be examined 345 and processed by every node along a packet's delivery path, including 346 the source and destination nodes. The Hop-by-Hop Options header, 347 when present, must immediately follow the IPv6 header. Its presence 348 is indicated by the value zero in the Next Header field of the IPv6 349 header. 350 351 If, as a result of processing a header, a node is required to proceed 352 to the next header but the Next Header value in the current header is 353 unrecognized by the node, it should discard the packet and send an 354 ICMP Parameter Problem message to the source of the packet, with an 355 ICMP Code value of 1 ("unrecognized Next Header type encountered") 356 and the ICMP Pointer field containing the offset of the unrecognized 357 value within the original packet. The same action should be taken if 358 a node encounters a Next Header value of zero in any header other 359 than an IPv6 header. 360 361 Each extension header is an integer multiple of 8 octets long, in 362 order to retain 8-octet alignment for subsequent headers. Multi- 363 octet fields within each extension header are aligned on their 364 natural boundaries, i.e., fields of width n octets are placed at an 365 integer multiple of n octets from the start of the header, for n = 1, 366 2, 4, or 8. 367 368 A full implementation of IPv6 includes implementation of the 369 following extension headers: 370 371 Hop-by-Hop Options 372 Routing (Type 0) 373 Fragment 374 Destination Options 375 Authentication 376 Encapsulating Security Payload 377 378 The first four are specified in this document; the last two are 379 specified in [RFC-2402] and [RFC-2406], respectively. 380 3814.1 Extension Header Order 382 383 When more than one extension header is used in the same packet, it is 384 recommended that those headers appear in the following order: 385 386 IPv6 header 387 Hop-by-Hop Options header 388 Destination Options header (note 1) 389 Routing header 390 Fragment header 391 392 393 394Deering & Hinden Standards Track [Page 7] 395 396RFC 2460 IPv6 Specification December 1998 397 398 399 Authentication header (note 2) 400 Encapsulating Security Payload header (note 2) 401 Destination Options header (note 3) 402 upper-layer header 403 404 note 1: for options to be processed by the first destination 405 that appears in the IPv6 Destination Address field 406 plus subsequent destinations listed in the Routing 407 header. 408 409 note 2: additional recommendations regarding the relative 410 order of the Authentication and Encapsulating 411 Security Payload headers are given in [RFC-2406]. 412 413 note 3: for options to be processed only by the final 414 destination of the packet. 415 416 Each extension header should occur at most once, except for the 417 Destination Options header which should occur at most twice (once 418 before a Routing header and once before the upper-layer header). 419 420 If the upper-layer header is another IPv6 header (in the case of IPv6 421 being tunneled over or encapsulated in IPv6), it may be followed by 422 its own extension headers, which are separately subject to the same 423 ordering recommendations. 424 425 If and when other extension headers are defined, their ordering 426 constraints relative to the above listed headers must be specified. 427 428 IPv6 nodes must accept and attempt to process extension headers in 429 any order and occurring any number of times in the same packet, 430 except for the Hop-by-Hop Options header which is restricted to 431 appear immediately after an IPv6 header only. Nonetheless, it is 432 strongly advised that sources of IPv6 packets adhere to the above 433 recommended order until and unless subsequent specifications revise 434 that recommendation. 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450Deering & Hinden Standards Track [Page 8] 451 452RFC 2460 IPv6 Specification December 1998 453 454 4554.2 Options 456 457 Two of the currently-defined extension headers -- the Hop-by-Hop 458 Options header and the Destination Options header -- carry a variable 459 number of type-length-value (TLV) encoded "options", of the following 460 format: 461 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 463 | Option Type | Opt Data Len | Option Data 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 465 466 Option Type 8-bit identifier of the type of option. 467 468 Opt Data Len 8-bit unsigned integer. Length of the Option 469 Data field of this option, in octets. 470 471 Option Data Variable-length field. Option-Type-specific 472 data. 473 474 The sequence of options within a header must be processed strictly in 475 the order they appear in the header; a receiver must not, for 476 example, scan through the header looking for a particular kind of 477 option and process that option prior to processing all preceding 478 ones. 479 480 The Option Type identifiers are internally encoded such that their 481 highest-order two bits specify the action that must be taken if the 482 processing IPv6 node does not recognize the Option Type: 483 484 00 - skip over this option and continue processing the header. 485 486 01 - discard the packet. 487 488 10 - discard the packet and, regardless of whether or not the 489 packet's Destination Address was a multicast address, send an 490 ICMP Parameter Problem, Code 2, message to the packet's 491 Source Address, pointing to the unrecognized Option Type. 492 493 11 - discard the packet and, only if the packet's Destination 494 Address was not a multicast address, send an ICMP Parameter 495 Problem, Code 2, message to the packet's Source Address, 496 pointing to the unrecognized Option Type. 497 498 The third-highest-order bit of the Option Type specifies whether or 499 not the Option Data of that option can change en-route to the 500 packet's final destination. When an Authentication header is present 501 502 503 504 505 506Deering & Hinden Standards Track [Page 9] 507 508RFC 2460 IPv6 Specification December 1998 509 510 511 in the packet, for any option whose data may change en-route, its 512 entire Option Data field must be treated as zero-valued octets when 513 computing or verifying the packet's authenticating value. 514 515 0 - Option Data does not change en-route 516 517 1 - Option Data may change en-route 518 519 The three high-order bits described above are to be treated as part 520 of the Option Type, not independent of the Option Type. That is, a 521 particular option is identified by a full 8-bit Option Type, not just 522 the low-order 5 bits of an Option Type. 523 524 The same Option Type numbering space is used for both the Hop-by-Hop 525 Options header and the Destination Options header. However, the 526 specification of a particular option may restrict its use to only one 527 of those two headers. 528 529 Individual options may have specific alignment requirements, to 530 ensure that multi-octet values within Option Data fields fall on 531 natural boundaries. The alignment requirement of an option is 532 specified using the notation xn+y, meaning the Option Type must 533 appear at an integer multiple of x octets from the start of the 534 header, plus y octets. For example: 535 536 2n means any 2-octet offset from the start of the header. 537 8n+2 means any 8-octet offset from the start of the header, 538 plus 2 octets. 539 540 There are two padding options which are used when necessary to align 541 subsequent options and to pad out the containing header to a multiple 542 of 8 octets in length. These padding options must be recognized by 543 all IPv6 implementations: 544 545 Pad1 option (alignment requirement: none) 546 547 +-+-+-+-+-+-+-+-+ 548 | 0 | 549 +-+-+-+-+-+-+-+-+ 550 551 NOTE! the format of the Pad1 option is a special case -- it does 552 not have length and value fields. 553 554 The Pad1 option is used to insert one octet of padding into the 555 Options area of a header. If more than one octet of padding is 556 required, the PadN option, described next, should be used, rather 557 than multiple Pad1 options. 558 559 560 561 562Deering & Hinden Standards Track [Page 10] 563 564RFC 2460 IPv6 Specification December 1998 565 566 567 PadN option (alignment requirement: none) 568 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 570 | 1 | Opt Data Len | Option Data 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 572 573 The PadN option is used to insert two or more octets of padding 574 into the Options area of a header. For N octets of padding, the 575 Opt Data Len field contains the value N-2, and the Option Data 576 consists of N-2 zero-valued octets. 577 578 Appendix B contains formatting guidelines for designing new options. 579 5804.3 Hop-by-Hop Options Header 581 582 The Hop-by-Hop Options header is used to carry optional information 583 that must be examined by every node along a packet's delivery path. 584 The Hop-by-Hop Options header is identified by a Next Header value of 585 0 in the IPv6 header, and has the following format: 586 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Next Header | Hdr Ext Len | | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 590 | | 591 . . 592 . Options . 593 . . 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 597 Next Header 8-bit selector. Identifies the type of header 598 immediately following the Hop-by-Hop Options 599 header. Uses the same values as the IPv4 600 Protocol field [RFC-1700 et seq.]. 601 602 Hdr Ext Len 8-bit unsigned integer. Length of the Hop-by- 603 Hop Options header in 8-octet units, not 604 including the first 8 octets. 605 606 Options Variable-length field, of length such that the 607 complete Hop-by-Hop Options header is an integer 608 multiple of 8 octets long. Contains one or more 609 TLV-encoded options, as described in section 610 4.2. 611 612 The only hop-by-hop options defined in this document are the Pad1 and 613 PadN options specified in section 4.2. 614 615 616 617 618Deering & Hinden Standards Track [Page 11] 619 620RFC 2460 IPv6 Specification December 1998 621 622 6234.4 Routing Header 624 625 The Routing header is used by an IPv6 source to list one or more 626 intermediate nodes to be "visited" on the way to a packet's 627 destination. This function is very similar to IPv4's Loose Source 628 and Record Route option. The Routing header is identified by a Next 629 Header value of 43 in the immediately preceding header, and has the 630 following format: 631 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | | 636 . . 637 . type-specific data . 638 . . 639 | | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 642 Next Header 8-bit selector. Identifies the type of header 643 immediately following the Routing header. Uses 644 the same values as the IPv4 Protocol field 645 [RFC-1700 et seq.]. 646 647 Hdr Ext Len 8-bit unsigned integer. Length of the Routing 648 header in 8-octet units, not including the first 649 8 octets. 650 651 Routing Type 8-bit identifier of a particular Routing header 652 variant. 653 654 Segments Left 8-bit unsigned integer. Number of route 655 segments remaining, i.e., number of explicitly 656 listed intermediate nodes still to be visited 657 before reaching the final destination. 658 659 type-specific data Variable-length field, of format determined by 660 the Routing Type, and of length such that the 661 complete Routing header is an integer multiple 662 of 8 octets long. 663 664 If, while processing a received packet, a node encounters a Routing 665 header with an unrecognized Routing Type value, the required behavior 666 of the node depends on the value of the Segments Left field, as 667 follows: 668 669 670 671 672 673 674Deering & Hinden Standards Track [Page 12] 675 676RFC 2460 IPv6 Specification December 1998 677 678 679 If Segments Left is zero, the node must ignore the Routing header 680 and proceed to process the next header in the packet, whose type 681 is identified by the Next Header field in the Routing header. 682 683 If Segments Left is non-zero, the node must discard the packet and 684 send an ICMP Parameter Problem, Code 0, message to the packet's 685 Source Address, pointing to the unrecognized Routing Type. 686 687 If, after processing a Routing header of a received packet, an 688 intermediate node determines that the packet is to be forwarded onto 689 a link whose link MTU is less than the size of the packet, the node 690 must discard the packet and send an ICMP Packet Too Big message to 691 the packet's Source Address. 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730Deering & Hinden Standards Track [Page 13] 731 732RFC 2460 IPv6 Specification December 1998 733 734 735 The Type 0 Routing header has the following format: 736 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Next Header | Hdr Ext Len | Routing Type=0| Segments Left | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Reserved | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | | 743 + + 744 | | 745 + Address[1] + 746 | | 747 + + 748 | | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | | 751 + + 752 | | 753 + Address[2] + 754 | | 755 + + 756 | | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 . . . 759 . . . 760 . . . 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | | 763 + + 764 | | 765 + Address[n] + 766 | | 767 + + 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 771 Next Header 8-bit selector. Identifies the type of header 772 immediately following the Routing header. Uses 773 the same values as the IPv4 Protocol field 774 [RFC-1700 et seq.]. 775 776 Hdr Ext Len 8-bit unsigned integer. Length of the Routing 777 header in 8-octet units, not including the first 778 8 octets. For the Type 0 Routing header, Hdr 779 Ext Len is equal to two times the number of 780 addresses in the header. 781 782 Routing Type 0. 783 784 785 786Deering & Hinden Standards Track [Page 14] 787 788RFC 2460 IPv6 Specification December 1998 789 790 791 Segments Left 8-bit unsigned integer. Number of route 792 segments remaining, i.e., number of explicitly 793 listed intermediate nodes still to be visited 794 before reaching the final destination. 795 796 Reserved 32-bit reserved field. Initialized to zero for 797 transmission; ignored on reception. 798 799 Address[1..n] Vector of 128-bit addresses, numbered 1 to n. 800 801 Multicast addresses must not appear in a Routing header of Type 0, or 802 in the IPv6 Destination Address field of a packet carrying a Routing 803 header of Type 0. 804 805 A Routing header is not examined or processed until it reaches the 806 node identified in the Destination Address field of the IPv6 header. 807 In that node, dispatching on the Next Header field of the immediately 808 preceding header causes the Routing header module to be invoked, 809 which, in the case of Routing Type 0, performs the following 810 algorithm: 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842Deering & Hinden Standards Track [Page 15] 843 844RFC 2460 IPv6 Specification December 1998 845 846 847 if Segments Left = 0 { 848 proceed to process the next header in the packet, whose type is 849 identified by the Next Header field in the Routing header 850 } 851 else if Hdr Ext Len is odd { 852 send an ICMP Parameter Problem, Code 0, message to the Source 853 Address, pointing to the Hdr Ext Len field, and discard the 854 packet 855 } 856 else { 857 compute n, the number of addresses in the Routing header, by 858 dividing Hdr Ext Len by 2 859 860 if Segments Left is greater than n { 861 send an ICMP Parameter Problem, Code 0, message to the Source 862 Address, pointing to the Segments Left field, and discard the 863 packet 864 } 865 else { 866 decrement Segments Left by 1; 867 compute i, the index of the next address to be visited in 868 the address vector, by subtracting Segments Left from n 869 870 if Address [i] or the IPv6 Destination Address is multicast { 871 discard the packet 872 } 873 else { 874 swap the IPv6 Destination Address and Address[i] 875 876 if the IPv6 Hop Limit is less than or equal to 1 { 877 send an ICMP Time Exceeded -- Hop Limit Exceeded in 878 Transit message to the Source Address and discard the 879 packet 880 } 881 else { 882 decrement the Hop Limit by 1 883 884 resubmit the packet to the IPv6 module for transmission 885 to the new destination 886 } 887 } 888 } 889 } 890 891 892 893 894 895 896 897 898Deering & Hinden Standards Track [Page 16] 899 900RFC 2460 IPv6 Specification December 1998 901 902 903 As an example of the effects of the above algorithm, consider the 904 case of a source node S sending a packet to destination node D, using 905 a Routing header to cause the packet to be routed via intermediate 906 nodes I1, I2, and I3. The values of the relevant IPv6 header and 907 Routing header fields on each segment of the delivery path would be 908 as follows: 909 910 As the packet travels from S to I1: 911 912 Source Address = S Hdr Ext Len = 6 913 Destination Address = I1 Segments Left = 3 914 Address[1] = I2 915 Address[2] = I3 916 Address[3] = D 917 918 As the packet travels from I1 to I2: 919 920 Source Address = S Hdr Ext Len = 6 921 Destination Address = I2 Segments Left = 2 922 Address[1] = I1 923 Address[2] = I3 924 Address[3] = D 925 926 As the packet travels from I2 to I3: 927 928 Source Address = S Hdr Ext Len = 6 929 Destination Address = I3 Segments Left = 1 930 Address[1] = I1 931 Address[2] = I2 932 Address[3] = D 933 934 As the packet travels from I3 to D: 935 936 Source Address = S Hdr Ext Len = 6 937 Destination Address = D Segments Left = 0 938 Address[1] = I1 939 Address[2] = I2 940 Address[3] = I3 941 942 943 944 945 946 947 948 949 950 951 952 953 954Deering & Hinden Standards Track [Page 17] 955 956RFC 2460 IPv6 Specification December 1998 957 958 9594.5 Fragment Header 960 961 The Fragment header is used by an IPv6 source to send a packet larger 962 than would fit in the path MTU to its destination. (Note: unlike 963 IPv4, fragmentation in IPv6 is performed only by source nodes, not by 964 routers along a packet's delivery path -- see section 5.) The 965 Fragment header is identified by a Next Header value of 44 in the 966 immediately preceding header, and has the following format: 967 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Next Header | Reserved | Fragment Offset |Res|M| 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Identification | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 974 Next Header 8-bit selector. Identifies the initial header 975 type of the Fragmentable Part of the original 976 packet (defined below). Uses the same values as 977 the IPv4 Protocol field [RFC-1700 et seq.]. 978 979 Reserved 8-bit reserved field. Initialized to zero for 980 transmission; ignored on reception. 981 982 Fragment Offset 13-bit unsigned integer. The offset, in 8-octet 983 units, of the data following this header, 984 relative to the start of the Fragmentable Part 985 of the original packet. 986 987 Res 2-bit reserved field. Initialized to zero for 988 transmission; ignored on reception. 989 990 M flag 1 = more fragments; 0 = last fragment. 991 992 Identification 32 bits. See description below. 993 994 In order to send a packet that is too large to fit in the MTU of the 995 path to its destination, a source node may divide the packet into 996 fragments and send each fragment as a separate packet, to be 997 reassembled at the receiver. 998 999 For every packet that is to be fragmented, the source node generates 1000 an Identification value. The Identification must be different than 1001 that of any other fragmented packet sent recently* with the same 1002 Source Address and Destination Address. If a Routing header is 1003 present, the Destination Address of concern is that of the final 1004 destination. 1005 1006 1007 1008 1009 1010Deering & Hinden Standards Track [Page 18] 1011 1012RFC 2460 IPv6 Specification December 1998 1013 1014 1015 * "recently" means within the maximum likely lifetime of a packet, 1016 including transit time from source to destination and time spent 1017 awaiting reassembly with other fragments of the same packet. 1018 However, it is not required that a source node know the maximum 1019 packet lifetime. Rather, it is assumed that the requirement can 1020 be met by maintaining the Identification value as a simple, 32- 1021 bit, "wrap-around" counter, incremented each time a packet must 1022 be fragmented. It is an implementation choice whether to 1023 maintain a single counter for the node or multiple counters, 1024 e.g., one for each of the node's possible source addresses, or 1025 one for each active (source address, destination address) 1026 combination. 1027 1028 The initial, large, unfragmented packet is referred to as the 1029 "original packet", and it is considered to consist of two parts, as 1030 illustrated: 1031 1032 original packet: 1033 1034 +------------------+----------------------//-----------------------+ 1035 | Unfragmentable | Fragmentable | 1036 | Part | Part | 1037 +------------------+----------------------//-----------------------+ 1038 1039 The Unfragmentable Part consists of the IPv6 header plus any 1040 extension headers that must be processed by nodes en route to the 1041 destination, that is, all headers up to and including the Routing 1042 header if present, else the Hop-by-Hop Options header if present, 1043 else no extension headers. 1044 1045 The Fragmentable Part consists of the rest of the packet, that is, 1046 any extension headers that need be processed only by the final 1047 destination node(s), plus the upper-layer header and data. 1048 1049 The Fragmentable Part of the original packet is divided into 1050 fragments, each, except possibly the last ("rightmost") one, being an 1051 integer multiple of 8 octets long. The fragments are transmitted in 1052 separate "fragment packets" as illustrated: 1053 1054 original packet: 1055 1056 +------------------+--------------+--------------+--//--+----------+ 1057 | Unfragmentable | first | second | | last | 1058 | Part | fragment | fragment | .... | fragment | 1059 +------------------+--------------+--------------+--//--+----------+ 1060 1061 1062 1063 1064 1065 1066Deering & Hinden Standards Track [Page 19] 1067 1068RFC 2460 IPv6 Specification December 1998 1069 1070 1071 fragment packets: 1072 1073 +------------------+--------+--------------+ 1074 | Unfragmentable |Fragment| first | 1075 | Part | Header | fragment | 1076 +------------------+--------+--------------+ 1077 1078 +------------------+--------+--------------+ 1079 | Unfragmentable |Fragment| second | 1080 | Part | Header | fragment | 1081 +------------------+--------+--------------+ 1082 o 1083 o 1084 o 1085 +------------------+--------+----------+ 1086 | Unfragmentable |Fragment| last | 1087 | Part | Header | fragment | 1088 +------------------+--------+----------+ 1089 1090 Each fragment packet is composed of: 1091 1092 (1) The Unfragmentable Part of the original packet, with the 1093 Payload Length of the original IPv6 header changed to contain 1094 the length of this fragment packet only (excluding the length 1095 of the IPv6 header itself), and the Next Header field of the 1096 last header of the Unfragmentable Part changed to 44. 1097 1098 (2) A Fragment header containing: 1099 1100 The Next Header value that identifies the first header of 1101 the Fragmentable Part of the original packet. 1102 1103 A Fragment Offset containing the offset of the fragment, 1104 in 8-octet units, relative to the start of the 1105 Fragmentable Part of the original packet. The Fragment 1106 Offset of the first ("leftmost") fragment is 0. 1107 1108 An M flag value of 0 if the fragment is the last 1109 ("rightmost") one, else an M flag value of 1. 1110 1111 The Identification value generated for the original 1112 packet. 1113 1114 (3) The fragment itself. 1115 1116 The lengths of the fragments must be chosen such that the resulting 1117 fragment packets fit within the MTU of the path to the packets' 1118 destination(s). 1119 1120 1121 1122Deering & Hinden Standards Track [Page 20] 1123 1124RFC 2460 IPv6 Specification December 1998 1125 1126 1127 At the destination, fragment packets are reassembled into their 1128 original, unfragmented form, as illustrated: 1129 1130 reassembled original packet: 1131 1132 +------------------+----------------------//------------------------+ 1133 | Unfragmentable | Fragmentable | 1134 | Part | Part | 1135 +------------------+----------------------//------------------------+ 1136 1137 The following rules govern reassembly: 1138 1139 An original packet is reassembled only from fragment packets that 1140 have the same Source Address, Destination Address, and Fragment 1141 Identification. 1142 1143 The Unfragmentable Part of the reassembled packet consists of all 1144 headers up to, but not including, the Fragment header of the first 1145 fragment packet (that is, the packet whose Fragment Offset is 1146 zero), with the following two changes: 1147 1148 The Next Header field of the last header of the Unfragmentable 1149 Part is obtained from the Next Header field of the first 1150 fragment's Fragment header. 1151 1152 The Payload Length of the reassembled packet is computed from 1153 the length of the Unfragmentable Part and the length and offset 1154 of the last fragment. For example, a formula for computing the 1155 Payload Length of the reassembled original packet is: 1156 1157 PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last 1158 1159 where 1160 PL.orig = Payload Length field of reassembled packet. 1161 PL.first = Payload Length field of first fragment packet. 1162 FL.first = length of fragment following Fragment header of 1163 first fragment packet. 1164 FO.last = Fragment Offset field of Fragment header of 1165 last fragment packet. 1166 FL.last = length of fragment following Fragment header of 1167 last fragment packet. 1168 1169 The Fragmentable Part of the reassembled packet is constructed 1170 from the fragments following the Fragment headers in each of the 1171 fragment packets. The length of each fragment is computed by 1172 subtracting from the packet's Payload Length the length of the 1173 1174 1175 1176 1177 1178Deering & Hinden Standards Track [Page 21] 1179 1180RFC 2460 IPv6 Specification December 1998 1181 1182 1183 headers between the IPv6 header and fragment itself; its relative 1184 position in Fragmentable Part is computed from its Fragment Offset 1185 value. 1186 1187 The Fragment header is not present in the final, reassembled 1188 packet. 1189 1190 The following error conditions may arise when reassembling fragmented 1191 packets: 1192 1193 If insufficient fragments are received to complete reassembly of a 1194 packet within 60 seconds of the reception of the first-arriving 1195 fragment of that packet, reassembly of that packet must be 1196 abandoned and all the fragments that have been received for that 1197 packet must be discarded. If the first fragment (i.e., the one 1198 with a Fragment Offset of zero) has been received, an ICMP Time 1199 Exceeded -- Fragment Reassembly Time Exceeded message should be 1200 sent to the source of that fragment. 1201 1202 If the length of a fragment, as derived from the fragment packet's 1203 Payload Length field, is not a multiple of 8 octets and the M flag 1204 of that fragment is 1, then that fragment must be discarded and an 1205 ICMP Parameter Problem, Code 0, message should be sent to the 1206 source of the fragment, pointing to the Payload Length field of 1207 the fragment packet. 1208 1209 If the length and offset of a fragment are such that the Payload 1210 Length of the packet reassembled from that fragment would exceed 1211 65,535 octets, then that fragment must be discarded and an ICMP 1212 Parameter Problem, Code 0, message should be sent to the source of 1213 the fragment, pointing to the Fragment Offset field of the 1214 fragment packet. 1215 1216 The following conditions are not expected to occur, but are not 1217 considered errors if they do: 1218 1219 The number and content of the headers preceding the Fragment 1220 header of different fragments of the same original packet may 1221 differ. Whatever headers are present, preceding the Fragment 1222 header in each fragment packet, are processed when the packets 1223 arrive, prior to queueing the fragments for reassembly. Only 1224 those headers in the Offset zero fragment packet are retained in 1225 the reassembled packet. 1226 1227 The Next Header values in the Fragment headers of different 1228 fragments of the same original packet may differ. Only the value 1229 from the Offset zero fragment packet is used for reassembly. 1230 1231 1232 1233 1234Deering & Hinden Standards Track [Page 22] 1235 1236RFC 2460 IPv6 Specification December 1998 1237 1238 12394.6 Destination Options Header 1240 1241 The Destination Options header is used to carry optional information 1242 that need be examined only by a packet's destination node(s). The 1243 Destination Options header is identified by a Next Header value of 60 1244 in the immediately preceding header, and has the following format: 1245 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Next Header | Hdr Ext Len | | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1249 | | 1250 . . 1251 . Options . 1252 . . 1253 | | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 1256 Next Header 8-bit selector. Identifies the type of header 1257 immediately following the Destination Options 1258 header. Uses the same values as the IPv4 1259 Protocol field [RFC-1700 et seq.]. 1260 1261 Hdr Ext Len 8-bit unsigned integer. Length of the 1262 Destination Options header in 8-octet units, not 1263 including the first 8 octets. 1264 1265 Options Variable-length field, of length such that the 1266 complete Destination Options header is an 1267 integer multiple of 8 octets long. Contains one 1268 or more TLV-encoded options, as described in 1269 section 4.2. 1270 1271 The only destination options defined in this document are the Pad1 1272 and PadN options specified in section 4.2. 1273 1274 Note that there are two possible ways to encode optional destination 1275 information in an IPv6 packet: either as an option in the Destination 1276 Options header, or as a separate extension header. The Fragment 1277 header and the Authentication header are examples of the latter 1278 approach. Which approach can be used depends on what action is 1279 desired of a destination node that does not understand the optional 1280 information: 1281 1282 o If the desired action is for the destination node to discard 1283 the packet and, only if the packet's Destination Address is not 1284 a multicast address, send an ICMP Unrecognized Type message to 1285 the packet's Source Address, then the information may be 1286 encoded either as a separate header or as an option in the 1287 1288 1289 1290Deering & Hinden Standards Track [Page 23] 1291 1292RFC 2460 IPv6 Specification December 1998 1293 1294 1295 Destination Options header whose Option Type has the value 11 1296 in its highest-order two bits. The choice may depend on such 1297 factors as which takes fewer octets, or which yields better 1298 alignment or more efficient parsing. 1299 1300 o If any other action is desired, the information must be encoded 1301 as an option in the Destination Options header whose Option 1302 Type has the value 00, 01, or 10 in its highest-order two bits, 1303 specifying the desired action (see section 4.2). 1304 13054.7 No Next Header 1306 1307 The value 59 in the Next Header field of an IPv6 header or any 1308 extension header indicates that there is nothing following that 1309 header. If the Payload Length field of the IPv6 header indicates the 1310 presence of octets past the end of a header whose Next Header field 1311 contains 59, those octets must be ignored, and passed on unchanged if 1312 the packet is forwarded. 1313 13145. Packet Size Issues 1315 1316 IPv6 requires that every link in the internet have an MTU of 1280 1317 octets or greater. On any link that cannot convey a 1280-octet 1318 packet in one piece, link-specific fragmentation and reassembly must 1319 be provided at a layer below IPv6. 1320 1321 Links that have a configurable MTU (for example, PPP links [RFC- 1322 1661]) must be configured to have an MTU of at least 1280 octets; it 1323 is recommended that they be configured with an MTU of 1500 octets or 1324 greater, to accommodate possible encapsulations (i.e., tunneling) 1325 without incurring IPv6-layer fragmentation. 1326 1327 From each link to which a node is directly attached, the node must be 1328 able to accept packets as large as that link's MTU. 1329 1330 It is strongly recommended that IPv6 nodes implement Path MTU 1331 Discovery [RFC-1981], in order to discover and take advantage of path 1332 MTUs greater than 1280 octets. However, a minimal IPv6 1333 implementation (e.g., in a boot ROM) may simply restrict itself to 1334 sending packets no larger than 1280 octets, and omit implementation 1335 of Path MTU Discovery. 1336 1337 In order to send a packet larger than a path's MTU, a node may use 1338 the IPv6 Fragment header to fragment the packet at the source and 1339 have it reassembled at the destination(s). However, the use of such 1340 fragmentation is discouraged in any application that is able to 1341 adjust its packets to fit the measured path MTU (i.e., down to 1280 1342 octets). 1343 1344 1345 1346Deering & Hinden Standards Track [Page 24] 1347 1348RFC 2460 IPv6 Specification December 1998 1349 1350 1351 A node must be able to accept a fragmented packet that, after 1352 reassembly, is as large as 1500 octets. A node is permitted to 1353 accept fragmented packets that reassemble to more than 1500 octets. 1354 An upper-layer protocol or application that depends on IPv6 1355 fragmentation to send packets larger than the MTU of a path should 1356 not send packets larger than 1500 octets unless it has assurance that 1357 the destination is capable of reassembling packets of that larger 1358 size. 1359 1360 In response to an IPv6 packet that is sent to an IPv4 destination 1361 (i.e., a packet that undergoes translation from IPv6 to IPv4), the 1362 originating IPv6 node may receive an ICMP Packet Too Big message 1363 reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node 1364 is not required to reduce the size of subsequent packets to less than 1365 1280, but must include a Fragment header in those packets so that the 1366 IPv6-to-IPv4 translating router can obtain a suitable Identification 1367 value to use in resulting IPv4 fragments. Note that this means the 1368 payload may have to be reduced to 1232 octets (1280 minus 40 for the 1369 IPv6 header and 8 for the Fragment header), and smaller still if 1370 additional extension headers are used. 1371 13726. Flow Labels 1373 1374 The 20-bit Flow Label field in the IPv6 header may be used by a 1375 source to label sequences of packets for which it requests special 1376 handling by the IPv6 routers, such as non-default quality of service 1377 or "real-time" service. This aspect of IPv6 is, at the time of 1378 writing, still experimental and subject to change as the requirements 1379 for flow support in the Internet become clearer. Hosts or routers 1380 that do not support the functions of the Flow Label field are 1381 required to set the field to zero when originating a packet, pass the 1382 field on unchanged when forwarding a packet, and ignore the field 1383 when receiving a packet. 1384 1385 Appendix A describes the current intended semantics and usage of the 1386 Flow Label field. 1387 13887. Traffic Classes 1389 1390 The 8-bit Traffic Class field in the IPv6 header is available for use 1391 by originating nodes and/or forwarding routers to identify and 1392 distinguish between different classes or priorities of IPv6 packets. 1393 At the point in time at which this specification is being written, 1394 there are a number of experiments underway in the use of the IPv4 1395 Type of Service and/or Precedence bits to provide various forms of 1396 "differentiated service" for IP packets, other than through the use 1397 of explicit flow set-up. The Traffic Class field in the IPv6 header 1398 is intended to allow similar functionality to be supported in IPv6. 1399 1400 1401 1402Deering & Hinden Standards Track [Page 25] 1403 1404RFC 2460 IPv6 Specification December 1998 1405 1406 1407 It is hoped that those experiments will eventually lead to agreement 1408 on what sorts of traffic classifications are most useful for IP 1409 packets. Detailed definitions of the syntax and semantics of all or 1410 some of the IPv6 Traffic Class bits, whether experimental or intended 1411 for eventual standardization, are to be provided in separate 1412 documents. 1413 1414 The following general requirements apply to the Traffic Class field: 1415 1416 o The service interface to the IPv6 service within a node must 1417 provide a means for an upper-layer protocol to supply the value 1418 of the Traffic Class bits in packets originated by that upper- 1419 layer protocol. The default value must be zero for all 8 bits. 1420 1421 o Nodes that support a specific (experimental or eventual 1422 standard) use of some or all of the Traffic Class bits are 1423 permitted to change the value of those bits in packets that 1424 they originate, forward, or receive, as required for that 1425 specific use. Nodes should ignore and leave unchanged any bits 1426 of the Traffic Class field for which they do not support a 1427 specific use. 1428 1429 o An upper-layer protocol must not assume that the value of the 1430 Traffic Class bits in a received packet are the same as the 1431 value sent by the packet's source. 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458Deering & Hinden Standards Track [Page 26] 1459 1460RFC 2460 IPv6 Specification December 1998 1461 1462 14638. Upper-Layer Protocol Issues 1464 14658.1 Upper-Layer Checksums 1466 1467 Any transport or other upper-layer protocol that includes the 1468 addresses from the IP header in its checksum computation must be 1469 modified for use over IPv6, to include the 128-bit IPv6 addresses 1470 instead of 32-bit IPv4 addresses. In particular, the following 1471 illustration shows the TCP and UDP "pseudo-header" for IPv6: 1472 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | | 1475 + + 1476 | | 1477 + Source Address + 1478 | | 1479 + + 1480 | | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | | 1483 + + 1484 | | 1485 + Destination Address + 1486 | | 1487 + + 1488 | | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | Upper-Layer Packet Length | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | zero | Next Header | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 1495 o If the IPv6 packet contains a Routing header, the Destination 1496 Address used in the pseudo-header is that of the final 1497 destination. At the originating node, that address will be in 1498 the last element of the Routing header; at the recipient(s), 1499 that address will be in the Destination Address field of the 1500 IPv6 header. 1501 1502 o The Next Header value in the pseudo-header identifies the 1503 upper-layer protocol (e.g., 6 for TCP, or 17 for UDP). It will 1504 differ from the Next Header value in the IPv6 header if there 1505 are extension headers between the IPv6 header and the upper- 1506 layer header. 1507 1508 o The Upper-Layer Packet Length in the pseudo-header is the 1509 length of the upper-layer header and data (e.g., TCP header 1510 plus TCP data). Some upper-layer protocols carry their own 1511 1512 1513 1514Deering & Hinden Standards Track [Page 27] 1515 1516RFC 2460 IPv6 Specification December 1998 1517 1518 1519 length information (e.g., the Length field in the UDP header); 1520 for such protocols, that is the length used in the pseudo- 1521 header. Other protocols (such as TCP) do not carry their own 1522 length information, in which case the length used in the 1523 pseudo-header is the Payload Length from the IPv6 header, minus 1524 the length of any extension headers present between the IPv6 1525 header and the upper-layer header. 1526 1527 o Unlike IPv4, when UDP packets are originated by an IPv6 node, 1528 the UDP checksum is not optional. That is, whenever 1529 originating a UDP packet, an IPv6 node must compute a UDP 1530 checksum over the packet and the pseudo-header, and, if that 1531 computation yields a result of zero, it must be changed to hex 1532 FFFF for placement in the UDP header. IPv6 receivers must 1533 discard UDP packets containing a zero checksum, and should log 1534 the error. 1535 1536 The IPv6 version of ICMP [ICMPv6] includes the above pseudo-header in 1537 its checksum computation; this is a change from the IPv4 version of 1538 ICMP, which does not include a pseudo-header in its checksum. The 1539 reason for the change is to protect ICMP from misdelivery or 1540 corruption of those fields of the IPv6 header on which it depends, 1541 which, unlike IPv4, are not covered by an internet-layer checksum. 1542 The Next Header field in the pseudo-header for ICMP contains the 1543 value 58, which identifies the IPv6 version of ICMP. 1544 15458.2 Maximum Packet Lifetime 1546 1547 Unlike IPv4, IPv6 nodes are not required to enforce maximum packet 1548 lifetime. That is the reason the IPv4 "Time to Live" field was 1549 renamed "Hop Limit" in IPv6. In practice, very few, if any, IPv4 1550 implementations conform to the requirement that they limit packet 1551 lifetime, so this is not a change in practice. Any upper-layer 1552 protocol that relies on the internet layer (whether IPv4 or IPv6) to 1553 limit packet lifetime ought to be upgraded to provide its own 1554 mechanisms for detecting and discarding obsolete packets. 1555 15568.3 Maximum Upper-Layer Payload Size 1557 1558 When computing the maximum payload size available for upper-layer 1559 data, an upper-layer protocol must take into account the larger size 1560 of the IPv6 header relative to the IPv4 header. For example, in 1561 IPv4, TCP's MSS option is computed as the maximum packet size (a 1562 default value or a value learned through Path MTU Discovery) minus 40 1563 octets (20 octets for the minimum-length IPv4 header and 20 octets 1564 for the minimum-length TCP header). When using TCP over IPv6, the 1565 MSS must be computed as the maximum packet size minus 60 octets, 1566 1567 1568 1569 1570Deering & Hinden Standards Track [Page 28] 1571 1572RFC 2460 IPv6 Specification December 1998 1573 1574 1575 because the minimum-length IPv6 header (i.e., an IPv6 header with no 1576 extension headers) is 20 octets longer than a minimum-length IPv4 1577 header. 1578 15798.4 Responding to Packets Carrying Routing Headers 1580 1581 When an upper-layer protocol sends one or more packets in response to 1582 a received packet that included a Routing header, the response 1583 packet(s) must not include a Routing header that was automatically 1584 derived by "reversing" the received Routing header UNLESS the 1585 integrity and authenticity of the received Source Address and Routing 1586 header have been verified (e.g., via the use of an Authentication 1587 header in the received packet). In other words, only the following 1588 kinds of packets are permitted in response to a received packet 1589 bearing a Routing header: 1590 1591 o Response packets that do not carry Routing headers. 1592 1593 o Response packets that carry Routing headers that were NOT 1594 derived by reversing the Routing header of the received packet 1595 (for example, a Routing header supplied by local 1596 configuration). 1597 1598 o Response packets that carry Routing headers that were derived 1599 by reversing the Routing header of the received packet IF AND 1600 ONLY IF the integrity and authenticity of the Source Address 1601 and Routing header from the received packet have been verified 1602 by the responder. 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626Deering & Hinden Standards Track [Page 29] 1627 1628RFC 2460 IPv6 Specification December 1998 1629 1630 1631Appendix A. Semantics and Usage of the Flow Label Field 1632 1633 A flow is a sequence of packets sent from a particular source to a 1634 particular (unicast or multicast) destination for which the source 1635 desires special handling by the intervening routers. The nature of 1636 that special handling might be conveyed to the routers by a control 1637 protocol, such as a resource reservation protocol, or by information 1638 within the flow's packets themselves, e.g., in a hop-by-hop option. 1639 The details of such control protocols or options are beyond the scope 1640 of this document. 1641 1642 There may be multiple active flows from a source to a destination, as 1643 well as traffic that is not associated with any flow. A flow is 1644 uniquely identified by the combination of a source address and a 1645 non-zero flow label. Packets that do not belong to a flow carry a 1646 flow label of zero. 1647 1648 A flow label is assigned to a flow by the flow's source node. New 1649 flow labels must be chosen (pseudo-)randomly and uniformly from the 1650 range 1 to FFFFF hex. The purpose of the random allocation is to 1651 make any set of bits within the Flow Label field suitable for use as 1652 a hash key by routers, for looking up the state associated with the 1653 flow. 1654 1655 All packets belonging to the same flow must be sent with the same 1656 source address, destination address, and flow label. If any of those 1657 packets includes a Hop-by-Hop Options header, then they all must be 1658 originated with the same Hop-by-Hop Options header contents 1659 (excluding the Next Header field of the Hop-by-Hop Options header). 1660 If any of those packets includes a Routing header, then they all must 1661 be originated with the same contents in all extension headers up to 1662 and including the Routing header (excluding the Next Header field in 1663 the Routing header). The routers or destinations are permitted, but 1664 not required, to verify that these conditions are satisfied. If a 1665 violation is detected, it should be reported to the source by an ICMP 1666 Parameter Problem message, Code 0, pointing to the high-order octet 1667 of the Flow Label field (i.e., offset 1 within the IPv6 packet). 1668 1669 The maximum lifetime of any flow-handling state established along a 1670 flow's path must be specified as part of the description of the 1671 state-establishment mechanism, e.g., the resource reservation 1672 protocol or the flow-setup hop-by-hop option. A source must not re- 1673 use a flow label for a new flow within the maximum lifetime of any 1674 flow-handling state that might have been established for the prior 1675 use of that flow label. 1676 1677 1678 1679 1680 1681 1682Deering & Hinden Standards Track [Page 30] 1683 1684RFC 2460 IPv6 Specification December 1998 1685 1686 1687 When a node stops and restarts (e.g., as a result of a "crash"), it 1688 must be careful not to use a flow label that it might have used for 1689 an earlier flow whose lifetime may not have expired yet. This may be 1690 accomplished by recording flow label usage on stable storage so that 1691 it can be remembered across crashes, or by refraining from using any 1692 flow labels until the maximum lifetime of any possible previously 1693 established flows has expired. If the minimum time for rebooting the 1694 node is known, that time can be deducted from the necessary waiting 1695 period before starting to allocate flow labels. 1696 1697 There is no requirement that all, or even most, packets belong to 1698 flows, i.e., carry non-zero flow labels. This observation is placed 1699 here to remind protocol designers and implementors not to assume 1700 otherwise. For example, it would be unwise to design a router whose 1701 performance would be adequate only if most packets belonged to flows, 1702 or to design a header compression scheme that only worked on packets 1703 that belonged to flows. 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738Deering & Hinden Standards Track [Page 31] 1739 1740RFC 2460 IPv6 Specification December 1998 1741 1742 1743Appendix B. Formatting Guidelines for Options 1744 1745 This appendix gives some advice on how to lay out the fields when 1746 designing new options to be used in the Hop-by-Hop Options header or 1747 the Destination Options header, as described in section 4.2. These 1748 guidelines are based on the following assumptions: 1749 1750 o One desirable feature is that any multi-octet fields within the 1751 Option Data area of an option be aligned on their natural 1752 boundaries, i.e., fields of width n octets should be placed at 1753 an integer multiple of n octets from the start of the Hop-by- 1754 Hop or Destination Options header, for n = 1, 2, 4, or 8. 1755 1756 o Another desirable feature is that the Hop-by-Hop or Destination 1757 Options header take up as little space as possible, subject to 1758 the requirement that the header be an integer multiple of 8 1759 octets long. 1760 1761 o It may be assumed that, when either of the option-bearing 1762 headers are present, they carry a very small number of options, 1763 usually only one. 1764 1765 These assumptions suggest the following approach to laying out the 1766 fields of an option: order the fields from smallest to largest, with 1767 no interior padding, then derive the alignment requirement for the 1768 entire option based on the alignment requirement of the largest field 1769 (up to a maximum alignment of 8 octets). This approach is 1770 illustrated in the following examples: 1771 1772 Example 1 1773 1774 If an option X required two data fields, one of length 8 octets and 1775 one of length 4 octets, it would be laid out as follows: 1776 1777 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | Option Type=X |Opt Data Len=12| 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | 4-octet field | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | | 1784 + 8-octet field + 1785 | | 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 1788 1789 1790 1791 1792 1793 1794Deering & Hinden Standards Track [Page 32] 1795 1796RFC 2460 IPv6 Specification December 1998 1797 1798 1799 Its alignment requirement is 8n+2, to ensure that the 8-octet field 1800 starts at a multiple-of-8 offset from the start of the enclosing 1801 header. A complete Hop-by-Hop or Destination Options header 1802 containing this one option would look as follows: 1803 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 | Next Header | Hdr Ext Len=1 | Option Type=X |Opt Data Len=12| 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | 4-octet field | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | | 1810 + 8-octet field + 1811 | | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 1814 Example 2 1815 1816 If an option Y required three data fields, one of length 4 octets, 1817 one of length 2 octets, and one of length 1 octet, it would be laid 1818 out as follows: 1819 1820 +-+-+-+-+-+-+-+-+ 1821 | Option Type=Y | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 |Opt Data Len=7 | 1-octet field | 2-octet field | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | 4-octet field | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 1828 Its alignment requirement is 4n+3, to ensure that the 4-octet field 1829 starts at a multiple-of-4 offset from the start of the enclosing 1830 header. A complete Hop-by-Hop or Destination Options header 1831 containing this one option would look as follows: 1832 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | Next Header | Hdr Ext Len=1 | Pad1 Option=0 | Option Type=Y | 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 |Opt Data Len=7 | 1-octet field | 2-octet field | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | 4-octet field | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 | PadN Option=1 |Opt Data Len=2 | 0 | 0 | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 1843 1844 1845 1846 1847 1848 1849 1850Deering & Hinden Standards Track [Page 33] 1851 1852RFC 2460 IPv6 Specification December 1998 1853 1854 1855 Example 3 1856 1857 A Hop-by-Hop or Destination Options header containing both options X 1858 and Y from Examples 1 and 2 would have one of the two following 1859 formats, depending on which option appeared first: 1860 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Next Header | Hdr Ext Len=3 | Option Type=X |Opt Data Len=12| 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | 4-octet field | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | | 1867 + 8-octet field + 1868 | | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | PadN Option=1 |Opt Data Len=1 | 0 | Option Type=Y | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 |Opt Data Len=7 | 1-octet field | 2-octet field | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | 4-octet field | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 | PadN Option=1 |Opt Data Len=2 | 0 | 0 | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 1879 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | Next Header | Hdr Ext Len=3 | Pad1 Option=0 | Option Type=Y | 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 |Opt Data Len=7 | 1-octet field | 2-octet field | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | 4-octet field | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 | PadN Option=1 |Opt Data Len=4 | 0 | 0 | 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 | 0 | 0 | Option Type=X |Opt Data Len=12| 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 | 4-octet field | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | | 1894 + 8-octet field + 1895 | | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906Deering & Hinden Standards Track [Page 34] 1907 1908RFC 2460 IPv6 Specification December 1998 1909 1910 1911Security Considerations 1912 1913 The security features of IPv6 are described in the Security 1914 Architecture for the Internet Protocol [RFC-2401]. 1915 1916Acknowledgments 1917 1918 The authors gratefully acknowledge the many helpful suggestions of 1919 the members of the IPng working group, the End-to-End Protocols 1920 research group, and the Internet Community At Large. 1921 1922Authors' Addresses 1923 1924 Stephen E. Deering 1925 Cisco Systems, Inc. 1926 170 West Tasman Drive 1927 San Jose, CA 95134-1706 1928 USA 1929 1930 Phone: +1 408 527 8213 1931 Fax: +1 408 527 8254 1932 EMail: deering@cisco.com 1933 1934 1935 Robert M. Hinden 1936 Nokia 1937 232 Java Drive 1938 Sunnyvale, CA 94089 1939 USA 1940 1941 Phone: +1 408 990-2004 1942 Fax: +1 408 743-5677 1943 EMail: hinden@iprg.nokia.com 1944 1945References 1946 1947 [RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the 1948 Internet Protocol", RFC 2401, November 1998. 1949 1950 [RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", 1951 RFC 2402, November 1998. 1952 1953 [RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 1954 Protocol (ESP)", RFC 2406, November 1998. 1955 1956 [ICMPv6] Conta, A. and S. Deering, "ICMP for the Internet 1957 Protocol Version 6 (IPv6)", RFC 2463, December 1998. 1958 1959 1960 1961 1962Deering & Hinden Standards Track [Page 35] 1963 1964RFC 2460 IPv6 Specification December 1998 1965 1966 1967 [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing 1968 Architecture", RFC 2373, July 1998. 1969 1970 [RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU 1971 Discovery for IP version 6", RFC 1981, August 1996. 1972 1973 [RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1974 September 1981. 1975 1976 [RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, 1977 RFC 1700, October 1994. See also: 1978 http://www.iana.org/numbers.html 1979 1980 [RFC-1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 1981 51, RFC 1661, July 1994. 1982 1983CHANGES SINCE RFC-1883 1984 1985 This memo has the following changes from RFC-1883. Numbers identify 1986 the Internet-Draft version in which the change was made. 1987 1988 02) Removed all references to jumbograms and the Jumbo Payload 1989 option (moved to a separate document). 1990 1991 02) Moved most of Flow Label description from section 6 to (new) 1992 Appendix A. 1993 1994 02) In Flow Label description, now in Appendix A, corrected maximum 1995 Flow Label value from FFFFFF to FFFFF (i.e., one less "F") due 1996 to reduction of size of Flow Label field from 24 bits to 20 1997 bits. 1998 1999 02) Renumbered (relettered?) the previous Appendix A to be Appendix 2000 B. 2001 2002 02) Changed the wording of the Security Considerations section to 2003 avoid dependency loop between this spec and the IPsec specs. 2004 2005 02) Updated R. Hinden's email address and company affiliation. 2006 2007 2008 -------------------------------------------------------- 2009 2010 01) In section 3, changed field name "Class" to "Traffic Class" and 2011 increased its size from 4 to 8 bits. Decreased size of Flow 2012 Label field from 24 to 20 bits to compensate for increase in 2013 Traffic Class field. 2014 2015 2016 2017 2018Deering & Hinden Standards Track [Page 36] 2019 2020RFC 2460 IPv6 Specification December 1998 2021 2022 2023 01) In section 4.1, restored the order of the Authentication Header 2024 and the ESP header, which were mistakenly swapped in the 00 2025 version of this memo. 2026 2027 01) In section 4.4, deleted the Strict/Loose Bit Map field and the 2028 strict routing functionality from the Type 0 Routing header, and 2029 removed the restriction on number of addresses that may be 2030 carried in the Type 0 Routing header (was limited to 23 2031 addresses, because of the size of the strict/loose bit map). 2032 2033 01) In section 5, changed the minimum IPv6 MTU from 576 to 1280 2034 octets, and added a recommendation that links with configurable 2035 MTU (e.g., PPP links) be configured to have an MTU of at least 2036 1500 octets. 2037 2038 01) In section 5, deleted the requirement that a node must not send 2039 fragmented packets that reassemble to more than 1500 octets 2040 without knowledge of the destination reassembly buffer size, and 2041 replaced it with a recommendation that upper-layer protocols or 2042 applications should not do that. 2043 2044 01) Replaced reference to the IPv4 Path MTU Discovery spec (RFC- 2045 1191) with reference to the IPv6 Path MTU Discovery spec (RFC- 2046 1981), and deleted the Notes at the end of section 5 regarding 2047 Path MTU Discovery, since those details are now covered by RFC- 2048 1981. 2049 2050 01) In section 6, deleted specification of "opportunistic" flow 2051 set-up, and removed all references to the 6-second maximum 2052 lifetime for opportunistically established flow state. 2053 2054 01) In section 7, deleted the provisional description of the 2055 internal structure and semantics of the Traffic Class field, and 2056 specified that such descriptions be provided in separate 2057 documents. 2058 2059 -------------------------------------------------------- 2060 2061 00) In section 4, corrected the Code value to indicate "unrecognized 2062 Next Header type encountered" in an ICMP Parameter Problem 2063 message (changed from 2 to 1). 2064 2065 00) In the description of the Payload Length field in section 3, and 2066 of the Jumbo Payload Length field in section 4.3, made it 2067 clearer that extension headers are included in the payload 2068 length count. 2069 2070 2071 2072 2073 2074Deering & Hinden Standards Track [Page 37] 2075 2076RFC 2460 IPv6 Specification December 1998 2077 2078 2079 00) In section 4.1, swapped the order of the Authentication header 2080 and the ESP header. (NOTE: this was a mistake, and the change 2081 was undone in version 01.) 2082 2083 00) In section 4.2, made it clearer that options are identified by 2084 the full 8-bit Option Type, not by the low-order 5 bits of an 2085 Option Type. Also specified that the same Option Type numbering 2086 space is used for both Hop-by-Hop Options and Destination 2087 Options headers. 2088 2089 00) In section 4.4, added a sentence requiring that nodes processing 2090 a Routing header must send an ICMP Packet Too Big message in 2091 response to a packet that is too big to fit in the next hop link 2092 (rather than, say, performing fragmentation). 2093 2094 00) Changed the name of the IPv6 Priority field to "Class", and 2095 replaced the previous description of Priority in section 7 with 2096 a description of the Class field. Also, excluded this field 2097 from the set of fields that must remain the same for all packets 2098 in the same flow, as specified in section 6. 2099 2100 00) In the pseudo-header in section 8.1, changed the name of the 2101 "Payload Length" field to "Upper-Layer Packet Length". Also 2102 clarified that, in the case of protocols that carry their own 2103 length info (like non-jumbogram UDP), it is the upper-layer- 2104 derived length, not the IP-layer-derived length, that is used in 2105 the pseudo-header. 2106 2107 00) Added section 8.4, specifying that upper-layer protocols, when 2108 responding to a received packet that carried a Routing header, 2109 must not include the reverse of the Routing header in the 2110 response packet(s) unless the received Routing header was 2111 authenticated. 2112 2113 00) Fixed some typos and grammatical errors. 2114 2115 00) Authors' contact info updated. 2116 2117 -------------------------------------------------------- 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130Deering & Hinden Standards Track [Page 38] 2131 2132RFC 2460 IPv6 Specification December 1998 2133 2134 2135Full Copyright Statement 2136 2137 Copyright (C) The Internet Society (1998). All Rights Reserved. 2138 2139 This document and translations of it may be copied and furnished to 2140 others, and derivative works that comment on or otherwise explain it 2141 or assist in its implementation may be prepared, copied, published 2142 and distributed, in whole or in part, without restriction of any 2143 kind, provided that the above copyright notice and this paragraph are 2144 included on all such copies and derivative works. However, this 2145 document itself may not be modified in any way, such as by removing 2146 the copyright notice or references to the Internet Society or other 2147 Internet organizations, except as needed for the purpose of 2148 developing Internet standards in which case the procedures for 2149 copyrights defined in the Internet Standards process must be 2150 followed, or as required to translate it into languages other than 2151 English. 2152 2153 The limited permissions granted above are perpetual and will not be 2154 revoked by the Internet Society or its successors or assigns. 2155 2156 This document and the information contained herein is provided on an 2157 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2158 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2159 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2160 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2161 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186Deering & Hinden Standards Track [Page 39] 2187 2188