--- 1/draft-ietf-6man-rfc2460bis-03.txt 2016-03-21 10:21:09.474216651 -0700 +++ 2/draft-ietf-6man-rfc2460bis-04.txt 2016-03-21 10:21:09.622220345 -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: July 25, 2016 January 22, 2016 +Expires: September 22, 2016 March 21, 2016 Internet Protocol, Version 6 (IPv6) Specification - draft-ietf-6man-rfc2460bis-03 + draft-ietf-6man-rfc2460bis-04 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 July 25, 2016. + This Internet-Draft will expire on September 22, 2016. 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 @@ -648,27 +648,24 @@ that of any other fragmented packet sent recently* with the same Source Address and Destination Address. If a Routing header is present, the Destination Address of concern is that of the final destination. * "recently" means within the maximum likely lifetime of a packet, including transit time from source to destination and time spent awaiting reassembly with other fragments of the same packet. However, it is not required that a source node know the maximum packet lifetime. Rather, it is assumed that the - requirement can be met by maintaining the Identification value - as a simple, 32-bit, "wrap-around" counter, incremented each - time a packet must be fragmented. It is an implementation - choice whether to maintain a single counter for the node or - multiple counters, e.g., one for each of the node's possible - source addresses, or one for each active (source address, - destination address) combination. + requirement can be met by implementing an algorithm that + results in a low identification reuse frequency. Examples of + algorithms that can meet this requirement are described in + [RFC7739]. The initial, large, unfragmented packet is referred to as the "original packet", and it is considered to consist of three parts, as illustrated: original packet: +------------------+-------------------------+---//----------------+ | Per-Fragment | Extension & Upper-Layer | Fragmentable | | Headers | Headers | Part | @@ -1327,20 +1325,24 @@ [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/ RFC7045, December 2013, . + [RFC7739] Gont, F., "Security Implications of Predictable Fragment + Identification Values", RFC 7739, DOI 10.17487/RFC7739, + February 2016, . + Appendix A. Formatting Guidelines for Options This appendix gives some advice on how to lay out the fields when designing new options to be used in the Hop-by-Hop Options header or the Destination Options header, as described in section 4.2. These guidelines are based on the following assumptions: o One desirable feature is that any multi-octet fields within the Option Data area of an option be aligned on their natural boundaries, i.e., fields of width n octets should be placed at @@ -1463,20 +1466,25 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 + 04) Changed text discussing Fragment ID selection to refer to + RFC7739 for example algorithms. + + 04) Editorial changes. + 03) Clarified the text about decrementing the hop limit. 03) Removed IP Next Generation from the Abstract. 03) Add reference to the end of Section 4 to IPv6 Extension Header IANA registry. 03) Editorial changes. 02) Added text to Section 4.8 "Defining New Extension Headers and