--- 1/draft-ietf-6man-rfc2460bis-06.txt 2016-10-04 15:16:06.817859214 -0700 +++ 2/draft-ietf-6man-rfc2460bis-07.txt 2016-10-04 15:16:06.897861263 -0700 @@ -1,19 +1,19 @@ Network Working Group S. Deering Internet-Draft Retired Obsoletes: 2460 (if approved) R. Hinden Intended status: Standards Track Check Point Software -Expires: March 17, 2017 September 13, 2016 +Expires: April 7, 2017 October 4, 2016 Internet Protocol, Version 6 (IPv6) Specification - draft-ietf-6man-rfc2460bis-06 + draft-ietf-6man-rfc2460bis-07 Abstract This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC2460 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -21,21 +21,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 17, 2017. + This Internet-Draft will expire on April 7, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -67,34 +67,34 @@ 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 13 4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14 4.6. Destination Options Header . . . . . . . . . . . . . . . 21 4.7. No Next Header . . . . . . . . . . . . . . . . . . . . . 22 4.8. Defining New Extension Headers and Options . . . . . . . 22 5. Packet Size Issues . . . . . . . . . . . . . . . . . . . . . 23 6. Flow Labels . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Traffic Classes . . . . . . . . . . . . . . . . . . . . . . . 24 - 8. Upper-Layer Protocol Issues . . . . . . . . . . . . . . . . . 24 - 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 24 + 8. Upper-Layer Protocol Issues . . . . . . . . . . . . . . . . . 25 + 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 25 8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26 - 8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 26 + 8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 27 8.4. Responding to Packets Carrying Routing Headers . . . . . 27 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 29 - Appendix A. Formatting Guidelines for Options . . . . . . . . . 30 - Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 33 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 + Appendix A. Formatting Guidelines for Options . . . . . . . . . 31 + Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction IP version 6 (IPv6) is a new version of the Internet Protocol, designed as the successor to IP version 4 (IPv4) [RFC0791]. The changes from IPv4 to IPv6 fall primarily into the following categories: o Expanded Addressing Capabilities @@ -251,25 +251,33 @@ Destination Address 128-bit address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present). See [I-D.ietf-6man-rfc4291bis] and section 4.4. 4. IPv6 Extension Headers In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper- - layer header in a packet. There are a small number of such extension - headers, each identified by a distinct Next Header value. As - illustrated in these examples, an IPv6 packet may carry zero, one, or - more extension headers, each identified by the Next Header field of - the preceding header: + layer header in a packet. There is a small number of such extension + headers, each one identified by a distinct Next Header value. + + Extension Headers are numbered from IANA IP Protocol Numbers + [IANA-PN], the same values used for IPv4 and IPv6. When processing a + sequence of Next Header values in a packet, the first one that is not + an Extension Header [IANA-EH] indicates that the next item in the + packet is the corresponding upper-layer header. A special "No Next + Header" value is used if there is no upper-layer header. + + As illustrated in these examples, an IPv6 packet may carry zero, one, + or more extension headers, each identified by the Next Header field + of the preceding header: +---------------+------------------------ | IPv6 header | TCP header + data | | | Next Header = | | TCP | +---------------+------------------------ +---------------+----------------+------------------------ | IPv6 header | Routing header | TCP header + data @@ -317,29 +325,29 @@ the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by- Hop Options header if explicitly configured to do so. - If, as a result of processing a header, a node is required to proceed - to the next header but the Next Header value in the current header is - unrecognized by the node, it should discard the packet and send an - ICMP Parameter Problem message to the source of the packet, with an - ICMP Code value of 1 ("unrecognized Next Header type encountered") - and the ICMP Pointer field containing the offset of the unrecognized - value within the original packet. The same action should be taken if - a node encounters a Next Header value of zero in any header other - than an IPv6 header. + If, as a result of processing a header, the destination node is + required to proceed to the next header but the Next Header value in + the current header is unrecognized by the node, it should discard the + packet and send an ICMP Parameter Problem message to the source of + the packet, with an ICMP Code value of 1 ("unrecognized Next Header + type encountered") and the ICMP Pointer field containing the offset + of the unrecognized value within the original packet. The same + action should be taken if a node encounters a Next Header value of + zero in any header other than an IPv6 header. Each extension header is an integer multiple of 8 octets long, in order to retain 8-octet alignment for subsequent headers. Multi- octet fields within each extension header are aligned on their natural boundaries, i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8. A full implementation of IPv6 includes implementation of the following extension headers: @@ -830,70 +838,71 @@ from the fragments following the Fragment headers in each of the fragment packets. The length of each fragment is computed by subtracting from the packet's Payload Length the length of the headers between the IPv6 header and fragment itself; its relative position in Fragmentable Part is computed from its Fragment Offset value. The Fragment header is not present in the final, reassembled packet. - It should be noted that fragments may be duplicated in the - network. These exact duplicate fragments will be treated as - overlapping fragments and handled as described in the previous - paragraph. An implementation may choose to detect this case - and not drop the other fragments of the same packet. - If the fragment is a whole datagram (that is, both the Fragment Offset field and the M flag are zero), then it does not need any further reassembly and should be processed as a fully reassembled packet (i.e., updating Next Header, adjust Payload Length, removing the Fragmentation Header, etc.). Any other fragments that match this packet (i.e., the same IPv6 Source Address, IPv6 Destination Address, and Fragment Identification) should be processed independently. The following error conditions may arise when reassembling fragmented packets: - If insufficient fragments are received to complete reassembly of a - packet within 60 seconds of the reception of the first-arriving - fragment of that packet, reassembly of that packet must be - abandoned and all the fragments that have been received for that - packet must be discarded. If the first fragment (i.e., the one - with a Fragment Offset of zero) has been received, an ICMP Time - Exceeded -- Fragment Reassembly Time Exceeded message should be - sent to the source of that fragment. + o If insufficient fragments are received to complete reassembly + of a packet within 60 seconds of the reception of the first- + arriving fragment of that packet, reassembly of that packet + must be abandoned and all the fragments that have been received + for that packet must be discarded. If the first fragment + (i.e., the one with a Fragment Offset of zero) has been + received, an ICMP Time Exceeded -- Fragment Reassembly Time + Exceeded message should be sent to the source of that fragment. - If the length of a fragment, as derived from the fragment packet's - Payload Length field, is not a multiple of 8 octets and the M flag - of that fragment is 1, then that fragment must be discarded and an - ICMP Parameter Problem, Code 0, message should be sent to the - source of the fragment, pointing to the Payload Length field of - the fragment packet. + o If the length of a fragment, as derived from the fragment + packet's Payload Length field, is not a multiple of 8 octets + and the M flag of that fragment is 1, then that fragment must + be discarded and an ICMP Parameter Problem, Code 0, message + should be sent to the source of the fragment, pointing to the + Payload Length field of the fragment packet. - If the length and offset of a fragment are such that the Payload - Length of the packet reassembled from that fragment would exceed - 65,535 octets, then that fragment must be discarded and an ICMP - Parameter Problem, Code 0, message should be sent to the source of - the fragment, pointing to the Fragment Offset field of the - fragment packet. + o If the length and offset of a fragment are such that the + Payload Length of the packet reassembled from that fragment + would exceed 65,535 octets, then that fragment must be + discarded and an ICMP Parameter Problem, Code 0, message should + be sent to the source of the fragment, pointing to the Fragment + Offset field of the fragment packet. - If the first fragment does not include all headers through an - Upper-Layer header, then that fragment should be discarded and an - ICMP Parameter Problem, Code 3, message should be sent to the - source of the fragment, with the Pointer field set to zero. + o If the first fragment does not include all headers through an + Upper-Layer header, then that fragment should be discarded and + an ICMP Parameter Problem, Code 3, message should be sent to + the source of the fragment, with the Pointer field set to zero. - If any of the fragments being reassembled overlaps with any other - fragments being reassembled for the same packet, reassembly of - that packet must be abandoned and all the fragments that have been - received for that packet must be discarded. + o If any of the fragments being reassembled overlaps with any + other fragments being reassembled for the same packet, + reassembly of that packet must be abandoned and all the + fragments that have been received for that packet must be + discarded and no ICMP error messages should be sent. + + It should be noted that fragments may be duplicated in the + network. Instead of treating these exact duplicate fragments + as an overlapping fragments, an implementation may choose to + detect this case and drop exact duplicate fragments while + keeping the other fragments belonging to the same packet. The following conditions are not expected to occur, but are not considered errors if they do: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in @@ -965,34 +974,40 @@ The value 59 in the Next Header field of an IPv6 header or any extension header indicates that there is nothing following that header. If the Payload Length field of the IPv6 header indicates the presence of octets past the end of a header whose Next Header field contains 59, those octets must be ignored, and passed on unchanged if the packet is forwarded. 4.8. Defining New Extension Headers and Options - No new extension headers that require hop-by-hop behavior should be + New extension headers that require hop-by-hop behavior must not be defined because as specified in Section 4 of this document, the only Extension Header that has hop-by-hop behavior is the Hop-by-Hop Options header. - New hop-by-hop options are not recommended because it is expected - that nodes along a packet's delivery path will only examine and - process the hop-by-hop option header if explicitly configured to do - so. + New hop-by-hop options are not recommended because nodes may be + configured to ignore the Hop-by-Hop Option header, drop packets + containing a hop-by-hop header, or assign packets containing a hop- + by-hop header to a slow processing path. Designers considering + defining new hop-by-hop options need to be aware of this likely + behaviour. There has to a very clear justification why any new hop- + by-hop option is needed before it is standardized. - Defining new IPv6 extension headers is not recommended. Instead of - defining new Extension Headers, it is recommended that the - Destination Options header is used to carry optional information that - need be examined only by a packet's destination node(s). + Defining new IPv6 extension headers is not recommended. There has to + a very clear justification why any new extension header is needed + before it is standardized. Instead of defining new Extension + Headers, it is recommended that the Destination Options header is + used to carry optional information that need be examined only by a + packet's destination node(s), because they provide better handling + and backward compatibility. If new Extension Headers are defined, they need to use the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Header Specific Data . @@ -1203,26 +1218,42 @@ by the responder. 9. IANA Considerations RFC2460 is referenced in a number of IANA registries. These include: o Internet Protocol Version 6 (IPv6) Parameters [IANA-6P] o Assigned Internet Protocol Numbers [IANA-PN] + o ONC RPC Network Identifiers (netids) [IANA-NI] + + o Technical requirements for authoritative name servers [IANA-NS] + + o Network Layer Protocol Identifiers (NLPIDs) of Interest + [IANA-NL] + + o Protocol Registries [IANA-PR] + + o Structure of Management Information (SMI) Numbers (MIB Module + Registrations) [IANA-MI] + The IANA should update these references to point to this document. 10. Security Considerations - The security features of IPv6 are described in the Security - Architecture for the Internet Protocol [RFC4301]. + IPv6, from the viewpoint of the basic format and transmission of + packets, has security properties similar to IPv4. Risks of + corruption, forgery, and interception of packets, resulting in the + exposure of private information, may may be mitigated by use of the + Security Architecture for the Internet Protocol [RFC4301] or + encryption at higher layers of the protocol stack. 11. Acknowledgments The authors gratefully acknowledge the many helpful suggestions of the members of the IPng working group, the End-to-End Protocols research group, and the Internet Community At Large. The authors would also like to acknowledge the authors of the updating RFCs that were incorporated in this version of the document to move the IPv6 specification to Internet Standard. They are Joe @@ -1230,23 +1261,23 @@ Scott Bradner, Brian Carpenter, P.F. Chimento, Marshall Eubanks, Fernando Gont, James Hoagland, Sheng Jiang, Erik Kline, Suresh Krishnan, Vishwas Manral, George Neville-Neil, Jarno Rajahalme, Pekka Savola, Magnus Westerlund, and James Woodyatt. 12. References 12.1. Normative References [I-D.ietf-6man-rfc4291bis] - Hinden, R. and D. Deering, "IP Version 6 Addressing - Architecture", draft-ietf-6man-rfc4291bis-03 (work in - progress), June 2016. + Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", draft-ietf-6man-rfc4291bis-04 (work in + progress), September 2016. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . @@ -1270,24 +1301,40 @@ 12.2. Informative References [IANA-6P] "Internet Protocol Version 6 (IPv6) Parameters", . [IANA-EH] "IPv6 Extension Header Types", . + [IANA-MI] "Structure of Management Information (SMI) Numbers (MIB + Module Registrations)", < http://www.iana.org/assignments/ + smi-numbers/smi-numbers.xhtml>. + + [IANA-NI] "ONC RPC Network Identifiers (netids)", + . + + [IANA-NL] "Network Layer Protocol Identifiers (NLPIDs) of Interest", + . + + [IANA-NS] "Technical requirements for authoritative name servers", + . + [IANA-PN] "Assigned Internet Protocol Numbers", . + [IANA-PR] "Protocol Registries", . + [IANA-RH] "IANA Routing Types Parameter Registry", . [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, . [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August @@ -1461,20 +1508,42 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Appendix B. CHANGES SINCE RFC2460 This memo has the following changes from RFC2460. Numbers identify the Internet-Draft version in which the change was made. Working Group Internet Drafts + 07) Expanded Security Considerations section to include both + IPSEC and encryption at higher levels in the protocol stack + as ways to mitigate IP level security issues. + + 07) Added paragraph to Section 4 to clarify how Extension Headers + are numbered and which are upper-layer headers. + + 07) Moved the text regarding network duplicated fragments to the + received fragment error section. + + 07) Added clarification that no ICMP error message should be sent + if overlapping fragments are received. + + 07) Revised the text in Section 4.8 regarding new hop-by-hop + options and new Extension headers to be closer to the -05 + version. + + 07) Added additional registries to the IANA Considerations + section that IANA needs to update. + + 07) Editorial changes. + 06) Added the Routing Header to the list required extension headers that a full implementation includes. 06) Moved the text in Section 4.5 regarding the handling of received overlapping fragments to the list of error conditions 06) Rewrote the text in Section 4.8 "Defining New Extension Headers and Options" to be clearer and remove redundant text. @@ -1565,33 +1634,33 @@ recommendations for defining new Extension headers and options RFC7045: The changes were to add a reference to RFC7045, change the requirement for processing the hop-by-hop option to a should, and added a note that due to performance restrictions some nodes won't process the Hop- by-Hop Option header. RFC7112: The changes were to revise the Fragmentation - Section to require that all headers through the first - Upper-Layer Header are in the first fragment. This - changed the text describing how packets are fragmented and - reassembled and added a new error case. + Section (Section 4.5) to require that all headers through + the first Upper-Layer Header are in the first fragment. + This changed the text describing how packets are + fragmented and reassembled and added a new error case. 06) Editorial changes. 05) The purpose of this draft is to incorporate the updates dealing with fragmentation as defined in RFC5722 and RFC6946. Note: The issue relating to the handling of exact duplicate fragments identified on the mailing list is left open. - 05) Fix text in the end of Section 4.0 to correct the number of + 05) Fix text in the end of Section 4 to correct the number of extension headers defined in this document. 05) Editorial changes. 04) The purpose of this draft is to update the document to incorporate the update made by RFC6935 "UDP Checksums for Tunneled Packets". 04) Remove Routing (Type 0) header from the list of required extension headers. @@ -1607,23 +1676,23 @@ document to resolve the open Errata on RFC2460. Errata ID: 2541: This errata notes that RFC2460 didn't update RFC2205 when the length of the Flow Label was changed from 24 to 20 bits from RFC1883. This issue was resolved in RFC6437 where the Flow Label is defined. This draft now references RFC6437. No change is required. Errata ID: 4279: This errata noted that the specification doesn't handle the case of a forwarding node receiving a - packet with a zero Hop Limit. This is fixed in - Section 3.0 of this draft. Note: No change was made - regarding host behaviour. + packet with a zero Hop Limit. This is fixed in Section 3 + of this draft. Note: No change was made regarding host + behaviour. Errata ID: 2843: This errata is marked rejected. No change is required. 02) Editorial changes to the Flow Label and Traffic Class text. 01) The purpose of this version of the draft is to update the document to point to the current specifications of the IPv6 Flow Label field as defined in [RFC6437] and the Traffic Class as defined in [RFC2474] and [RFC3168].