draft-ietf-6man-rfc2460bis-03.txt   draft-ietf-6man-rfc2460bis-04.txt 
Network Working Group S. Deering Network Working Group S. Deering
Internet-Draft Retired Internet-Draft Retired
Obsoletes: 2460 (if approved) R. Hinden Obsoletes: 2460 (if approved) R. Hinden
Intended status: Standards Track Check Point Software 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 Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-03 draft-ietf-6man-rfc2460bis-04
Abstract Abstract
This document specifies version 6 of the Internet Protocol (IPv6). This document specifies version 6 of the Internet Protocol (IPv6).
It obsoletes RFC2460 It obsoletes RFC2460
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 15, line 31 skipping to change at page 15, line 31
that of any other fragmented packet sent recently* with the same that of any other fragmented packet sent recently* with the same
Source Address and Destination Address. If a Routing header is Source Address and Destination Address. If a Routing header is
present, the Destination Address of concern is that of the final present, the Destination Address of concern is that of the final
destination. destination.
* "recently" means within the maximum likely lifetime of a * "recently" means within the maximum likely lifetime of a
packet, including transit time from source to destination and packet, including transit time from source to destination and
time spent awaiting reassembly with other fragments of the same time spent awaiting reassembly with other fragments of the same
packet. However, it is not required that a source node know packet. However, it is not required that a source node know
the maximum packet lifetime. Rather, it is assumed that the the maximum packet lifetime. Rather, it is assumed that the
requirement can be met by maintaining the Identification value requirement can be met by implementing an algorithm that
as a simple, 32-bit, "wrap-around" counter, incremented each results in a low identification reuse frequency. Examples of
time a packet must be fragmented. It is an implementation algorithms that can meet this requirement are described in
choice whether to maintain a single counter for the node or [RFC7739].
multiple counters, e.g., one for each of the node's possible
source addresses, or one for each active (source address,
destination address) combination.
The initial, large, unfragmented packet is referred to as the The initial, large, unfragmented packet is referred to as the
"original packet", and it is considered to consist of three parts, as "original packet", and it is considered to consist of three parts, as
illustrated: illustrated:
original packet: original packet:
+------------------+-------------------------+---//----------------+ +------------------+-------------------------+---//----------------+
| Per-Fragment | Extension & Upper-Layer | Fragmentable | | Per-Fragment | Extension & Upper-Layer | Fragmentable |
| Headers | Headers | Part | | Headers | Headers | Part |
skipping to change at page 30, line 27 skipping to change at page 30, line 27
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013, RFC 6936, DOI 10.17487/RFC6936, April 2013,
<http://www.rfc-editor.org/info/rfc6936>. <http://www.rfc-editor.org/info/rfc6936>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, DOI 10.17487/ of IPv6 Extension Headers", RFC 7045, DOI 10.17487/
RFC7045, December 2013, RFC7045, December 2013,
<http://www.rfc-editor.org/info/rfc7045>. <http://www.rfc-editor.org/info/rfc7045>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <http://www.rfc-editor.org/info/rfc7739>.
Appendix A. Formatting Guidelines for Options Appendix A. Formatting Guidelines for Options
This appendix gives some advice on how to lay out the fields when 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 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 the Destination Options header, as described in section 4.2. These
guidelines are based on the following assumptions: guidelines are based on the following assumptions:
o One desirable feature is that any multi-octet fields within the o One desirable feature is that any multi-octet fields within the
Option Data area of an option be aligned on their natural Option Data area of an option be aligned on their natural
boundaries, i.e., fields of width n octets should be placed at boundaries, i.e., fields of width n octets should be placed at
skipping to change at page 33, line 48 skipping to change at page 33, line 48
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B. CHANGES SINCE RFC2460 Appendix B. CHANGES SINCE RFC2460
This memo has the following changes from RFC2460. Numbers identify This memo has the following changes from RFC2460. Numbers identify
the Internet-Draft version in which the change was made. the Internet-Draft version in which the change was made.
Working Group Internet Drafts 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) Clarified the text about decrementing the hop limit.
03) Removed IP Next Generation from the Abstract. 03) Removed IP Next Generation from the Abstract.
03) Add reference to the end of Section 4 to IPv6 Extension 03) Add reference to the end of Section 4 to IPv6 Extension
Header IANA registry. Header IANA registry.
03) Editorial changes. 03) Editorial changes.
02) Added text to Section 4.8 "Defining New Extension Headers and 02) Added text to Section 4.8 "Defining New Extension Headers and
 End of changes. 6 change blocks. 
10 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/