draft-ietf-6man-rfc2460bis-07.txt   draft-ietf-6man-rfc2460bis-08.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: April 7, 2017 October 4, 2016 Expires: May 19, 2017 November 15, 2016
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-07 draft-ietf-6man-rfc2460bis-08
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 April 7, 2017. This Internet-Draft will expire on May 19, 2017.
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 7, line 27 skipping to change at page 7, line 27
+---------------+----------------+------------------------ +---------------+----------------+------------------------
+---------------+----------------+-----------------+----------------- +---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP | IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data | | | | header + data
| Next Header = | Next Header = | Next Header = | | Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP | | Routing | Fragment | TCP |
+---------------+----------------+-----------------+----------------- +---------------+----------------+-----------------+-----------------
The insertion of Extension Headers by any node other than the source The insertion of Extension Headers by any node other than the source
of the packet breaks PMTU-discovery and can result in ICMP error of the packet causes serious problems. Two examples include breaking
messages being sent to the source of the packet that did not insert the integrity checks provided by the Authentication Header Integrity
the header. [RFC4302], and breaking Path MTU Discovery which can result in ICMP
error messages being sent to the source of the packet that did not
insert the header, rather than the node that inserted the header.
The current approach to allowing a header to be inserted is to One approach to avoid these problems is to encapsulate the packet
encapsulate the packet using another IPv6 header and including the using another IPv6 header and including the additional extension
additional extension header after the first IPv6 header, for example, header after the first IPv6 header, for example, as defined in
as defined in [RFC2473]. [RFC2473]
With one exception, extension headers are not processed by any node With one exception, extension headers are not processed by any node
along a packet's delivery path, until the packet reaches the node (or along a packet's delivery path, until the packet reaches the node (or
each of the set of nodes, in the case of multicast) identified in the each of the set of nodes, in the case of multicast) identified in the
Destination Address field of the IPv6 header. Note: If an Destination Address field of the IPv6 header. Note: If an
intermediate forwarding node examines an extension header for any intermediate forwarding node examines an extension header for any
reason, it must do so in accordance with the provisions of [RFC7045]. reason, it must do so in accordance with the provisions of [RFC7045].
At the Destination node, normal demultiplexing on the Next Header At the Destination node, normal demultiplexing on the Next Header
field of the IPv6 header invokes the module to process the first field of the IPv6 header invokes the module to process the first
extension header, or the upper-layer header if no extension header is extension header, or the upper-layer header if no extension header is
skipping to change at page 28, line 32 skipping to change at page 28, line 32
o Structure of Management Information (SMI) Numbers (MIB Module o Structure of Management Information (SMI) Numbers (MIB Module
Registrations) [IANA-MI] Registrations) [IANA-MI]
The IANA should update these references to point to this document. The IANA should update these references to point to this document.
10. Security Considerations 10. Security Considerations
IPv6, from the viewpoint of the basic format and transmission of IPv6, from the viewpoint of the basic format and transmission of
packets, has security properties similar to IPv4. Risks of packets, has security properties similar to IPv4. Risks of
corruption, forgery, and interception of packets, resulting in the corruption, forgery, and interception of packets, resulting in the
exposure of private information, may may be mitigated by use of the exposure of private information, may be mitigated by use of the
Security Architecture for the Internet Protocol [RFC4301] or Security Architecture for the Internet Protocol [RFC4301] or
encryption at higher layers of the protocol stack. encryption at higher layers of the protocol stack.
11. Acknowledgments 11. Acknowledgments
The authors gratefully acknowledge the many helpful suggestions of The authors gratefully acknowledge the many helpful suggestions of
the members of the IPng working group, the End-to-End Protocols the members of the IPng working group, the End-to-End Protocols
research group, and the Internet Community At Large. research group, and the Internet Community At Large.
The authors would also like to acknowledge the authors of the The authors would also like to acknowledge the authors of the
skipping to change at page 29, line 10 skipping to change at page 29, line 10
Scott Bradner, Brian Carpenter, P.F. Chimento, Marshall Eubanks, Scott Bradner, Brian Carpenter, P.F. Chimento, Marshall Eubanks,
Fernando Gont, James Hoagland, Sheng Jiang, Erik Kline, Suresh Fernando Gont, James Hoagland, Sheng Jiang, Erik Kline, Suresh
Krishnan, Vishwas Manral, George Neville-Neil, Jarno Rajahalme, Pekka Krishnan, Vishwas Manral, George Neville-Neil, Jarno Rajahalme, Pekka
Savola, Magnus Westerlund, and James Woodyatt. Savola, Magnus Westerlund, and James Woodyatt.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-6man-rfc4291bis] [I-D.ietf-6man-rfc4291bis]
Hinden, R. and S. Deering, "IP Version 6 Addressing Hinden, R. and S. <>, "IP Version 6 Addressing
Architecture", draft-ietf-6man-rfc4291bis-04 (work in Architecture", draft-ietf-6man-rfc4291bis-06 (work in
progress), September 2016. progress), November 2016.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI
10.17487/RFC0791, September 1981, 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI
10.17487/RFC2474, December 1998, 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
skipping to change at page 34, line 48 skipping to change at page 34, 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
08) Revised header insertion text in Section 4 based on the
results of w.g. survey that concluded to describe the
problems with header insertion.
08) Editorial changes.
07) Expanded Security Considerations section to include both 07) Expanded Security Considerations section to include both
IPSEC and encryption at higher levels in the protocol stack IPSEC and encryption at higher levels in the protocol stack
as ways to mitigate IP level security issues. as ways to mitigate IP level security issues.
07) Added paragraph to Section 4 to clarify how Extension Headers 07) Added paragraph to Section 4 to clarify how Extension Headers
are numbered and which are upper-layer headers. are numbered and which are upper-layer headers.
07) Moved the text regarding network duplicated fragments to the 07) Moved the text regarding network duplicated fragments to the
received fragment error section. received fragment error section.
 End of changes. 8 change blocks. 
14 lines changed or deleted 22 lines changed or added

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