draft-ietf-6man-rfc2460bis-09.txt   draft-ietf-6man-rfc2460bis-10.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: October 1, 2017 March 30, 2017 Expires: October 23, 2017 April 21, 2017
Internet Protocol, Version 6 (IPv6) Specification Internet Protocol, Version 6 (IPv6) Specification
draft-ietf-6man-rfc2460bis-09 draft-ietf-6man-rfc2460bis-10
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 October 1, 2017. This Internet-Draft will expire on October 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 2, line 41 skipping to change at page 2, line 41
5. Packet Size Issues . . . . . . . . . . . . . . . . . . . . . 23 5. Packet Size Issues . . . . . . . . . . . . . . . . . . . . . 23
6. Flow Labels . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Flow Labels . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Traffic Classes . . . . . . . . . . . . . . . . . . . . . . . 24 7. Traffic Classes . . . . . . . . . . . . . . . . . . . . . . . 24
8. Upper-Layer Protocol Issues . . . . . . . . . . . . . . . . . 24 8. Upper-Layer Protocol Issues . . . . . . . . . . . . . . . . . 24
8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 24 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 24
8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26 8.2. Maximum Packet Lifetime . . . . . . . . . . . . . . . . . 26
8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 26 8.3. Maximum Upper-Layer Payload Size . . . . . . . . . . . . 26
8.4. Responding to Packets Carrying Routing Headers . . . . . 27 8.4. Responding to Packets Carrying Routing Headers . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Formatting Guidelines for Options . . . . . . . . . 30 Appendix A. Formatting Guidelines for Options . . . . . . . . . 33
Appendix B. Changes Since RFC2460 . . . . . . . . . . . . . . . 33 Appendix B. Changes Since RFC2460 . . . . . . . . . . . . . . . 36
B.1. Change History Since RFC2460 . . . . . . . . . . . . . . 36 B.1. Change History Since RFC2460 . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
IP version 6 (IPv6) is a new version of the Internet Protocol (IP), IP version 6 (IPv6) is a new version of the Internet Protocol (IP),
designed as the successor to IP version 4 (IPv4) [RFC0791]. The designed as the successor to IP version 4 (IPv4) [RFC0791]. The
changes from IPv4 to IPv6 fall primarily into the following changes from IPv4 to IPv6 fall primarily into the following
categories: categories:
o Expanded Addressing Capabilities o Expanded Addressing Capabilities
skipping to change at page 15, line 40 skipping to change at page 15, line 40
"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 |
+------------------+-------------------------+---//----------------+ +------------------+-------------------------+---//----------------+
The Per-Fragment Headers consists of the IPv6 header plus any The Per-Fragment Headers must consist of the IPv6 header plus any
extension headers that must be processed by nodes en route to the extension headers that must be processed by nodes en route to the
destination, that is, all headers up to and including the Routing destination, that is, all headers up to and including the Routing
header if present, else the Hop-by-Hop Options header if present, header if present, else the Hop-by-Hop Options header if present,
else no extension headers. else no extension headers.
The Extension Headers are all other extension headers that are not The Extension Headers are all other extension headers that are not
included in the Per-Fragment headers part of the packet. For this included in the Per-Fragment headers part of the packet. For this
purpose, the Encapsulating Security Payload (ESP) is not purpose, the Encapsulating Security Payload (ESP) is not
considered an extension header. The Upper-Layer Header is the considered an extension header. The Upper-Layer Header is the
first upper-layer header that is not an IPv6 extension header. first upper-layer header that is not an IPv6 extension header.
skipping to change at page 20, line 29 skipping to change at page 20, line 29
reassembly of that packet must be abandoned and all the reassembly of that packet must be abandoned and all the
fragments that have been received for that packet must be fragments that have been received for that packet must be
discarded and no ICMP error messages should be sent. discarded and no ICMP error messages should be sent.
It should be noted that fragments may be duplicated in the It should be noted that fragments may be duplicated in the
network. Instead of treating these exact duplicate fragments network. Instead of treating these exact duplicate fragments
as overlapping fragments, an implementation may choose to as overlapping fragments, an implementation may choose to
detect this case and drop exact duplicate fragments while detect this case and drop exact duplicate fragments while
keeping the other fragments belonging to the same packet. keeping the other fragments belonging to the same packet.
The following conditions are not expected to occur, but are not The following conditions are not expected to occur frequently, but
considered errors if they do: are not considered errors if they do:
The number and content of the headers preceding the Fragment The number and content of the headers preceding the Fragment
header of different fragments of the same original packet may header of different fragments of the same original packet may
differ. Whatever headers are present, preceding the Fragment differ. Whatever headers are present, preceding the Fragment
header in each fragment packet, are processed when the packets header in each fragment packet, are processed when the packets
arrive, prior to queueing the fragments for reassembly. Only arrive, prior to queueing the fragments for reassembly. Only
those headers in the Offset zero fragment packet are retained in those headers in the Offset zero fragment packet are retained in
the reassembled packet. the reassembled packet.
The Next Header values in the Fragment headers of different The Next Header values in the Fragment headers of different
skipping to change at page 24, line 34 skipping to change at page 24, line 34
label sequences of packets to be treated in the network as a single label sequences of packets to be treated in the network as a single
flow. flow.
The current definition of the IPv6 Flow Label can be found in The current definition of the IPv6 Flow Label can be found in
[RFC6437]. [RFC6437].
7. Traffic Classes 7. Traffic Classes
The 8-bit Traffic Class field in the IPv6 header is used by the The 8-bit Traffic Class field in the IPv6 header is used by the
network for traffic management. The value of the Traffic Class bits network for traffic management. The value of the Traffic Class bits
in a received packet might be different from the value sent by the in a received packet or fragment might be different from the value
packet's source. sent by the packet's source.
The current use of the Traffic Class field for Differentiated The current use of the Traffic Class field for Differentiated
Services and Explicit Congestion Notification is specified in Services and Explicit Congestion Notification is specified in
[RFC2474] and [RFC3168]. [RFC2474] and [RFC3168].
8. Upper-Layer Protocol Issues 8. Upper-Layer Protocol Issues
8.1. Upper-Layer Checksums 8.1. Upper-Layer Checksums
Any transport or other upper-layer protocol that includes the Any transport or other upper-layer protocol that includes the
skipping to change at page 28, line 12 skipping to change at page 28, line 12
o Protocol Registries [IANA-PR] o Protocol Registries [IANA-PR]
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 that are similar to IPv4. These
corruption, forgery, and interception of packets, resulting in the security issues include:
exposure of private information, may be mitigated by use of the
Security Architecture for the Internet Protocol [RFC4301] or o Eavesdropping, On-path elements can observe the whole packet
encryption at higher layers of the protocol stack. (including both contents and metadata) of each IPv6 datagram.
o Replay, where attacker records a sequence of packets off of the
wire and plays them back to the party which originally received
them.
o Packet insertion, where the attacker forges a packet with some
chosen set of properties and injects it into the network.
o Packet deletion, where the attacker remove a packet from the
wire.
o Packet modification, where the attacker removes a packet from
the wire, modifies it, and re-injects it into the network.
o Man in the Middle attacks, where the attacker subverts the
communication stream in order to pose as the sender to receiver
and the receiver to the sender.
o Denial of Service Attacks, where the attacker sends large
amounts of legitimate traffic to a destination to overwhelm it.
IPv6 packets can be protected from eavesdropping, replay, packet
insertion, packet modification, and man in the middle attacks by use
of the "Security Architecture for the Internet Protocol" [RFC4301].
In addition, upper-layer protocols such as TLS or SSH can be used to
protect the application layer traffic running on top of IPv6.
There is not any mechanism to protect against "denial of service
attacks". Defending against these type of attacks is outside the
scope of this specification.
IPv6 addresses are significantly larger than IPv4 address making it
much harder to scan the address space across the Internet and even on
a single network link (e.g., Local Area Network). See [RFC7707] for
more information.
IPv6 addresses of nodes are expected to be more visible on the
Internet as compared with IPv4 since the use of address translation
technology is reduced. This creates some additional privacy issues
such as making it easier to distinguish endpoints. See [RFC7721] for
more information.
The design of IPv6 extension headers architecture, while adding a lot
of flexibility, also creates new security challenges. As noted
below, issues relating the fragment extension header have been
resolved, but it's clear that for any new extension header designed
in the future, the security implications need to be examined
throughly, and this needs to include how the new extension header
works with existing extension headers. See [RFC7045] for more
information.
This version of the IPv6 specification resolves a number of security
issues that were found with the previous version [RFC2460] of the
IPv6 specification. These include:
o Revised the text to handle the case of fragments that are whole
datagrams (i.e., both the Fragment Offset field and the M flag
are zero). If received they should be processed as a
reassembled packet. Any other fragments that match should be
processed independently. The Fragment creation process was
modified to not create whole datagram fragments (Fragment
Offset field and the M flag are zero). See [RFC6946] for more
information.
o Changed the text to require that IPv6 nodes must not create
overlapping fragments. Also, when reassembling an IPv6
datagram, if one or more its constituent fragments is
determined to be an overlapping fragment, the entire datagram
(and any constituent fragments) must be silently discarded.
Includes clarification that no ICMP error message should be
sent if overlapping fragments are received. See [RFC5722] for
more information.
0 Revised the text to require that all headers through the first
Upper-Layer Header are in the first fragment. See [RFC6946]
for more information.
o Removed the paragraph in Section 5 that required including a
fragment header to outgoing packets if a ICMP Packet Too Big
message reporting a Next-Hop MTU less than 1280. See [RFC7112]
for more information.
o Incorporated the updates from [RFC5095] and [RFC5871] to remove
the description of the RH0 Routing Header, that the allocations
guidelines for routing headers are specified in RFC5871, and
removed RH0 Routing Header from the list of required extension
headers.
Security issues relating to other parts of IPv6 including addressing,
ICMPv6, Path MTU Discovery, etc., are discussed in the appropriate
specifications.
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
updating RFCs that were incorporated in this version of the document updating RFCs that were incorporated in this version of the document
to move the IPv6 specification to Internet Standard. They are Joe to move the IPv6 specification to Internet Standard. They are Joe
skipping to change at page 30, line 29 skipping to change at page 32, line 25
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI
10.17487/RFC4302, December 2005, 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>. <http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, DOI 10.17487/RFC4303, December 2005, 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>. <http://www.rfc-editor.org/info/rfc4303>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, DOI
10.17487/RFC5095, December 2007,
<http://www.rfc-editor.org/info/rfc5095>.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, DOI 10.17487/RFC5722, December 2009,
<http://www.rfc-editor.org/info/rfc5722>.
[RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for [RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871, the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871,
May 2010, <http://www.rfc-editor.org/info/rfc5871>. May 2010, <http://www.rfc-editor.org/info/rfc5871>.
[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>.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
6946, DOI 10.17487/RFC6946, May 2013,
<http://www.rfc-editor.org/info/rfc6946>.
[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>.
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/
RFC7112, January 2014,
<http://www.rfc-editor.org/info/rfc7112>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<http://www.rfc-editor.org/info/rfc7707>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment [RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739, Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <http://www.rfc-editor.org/info/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:
skipping to change at page 33, line 48 skipping to change at page 36, line 48
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B. Changes Since RFC2460 Appendix B. Changes Since RFC2460
This memo has the following changes from RFC2460. This memo has the following changes from RFC2460.
o Clarification that extension headers are not examined, processed, o Clarification that extension headers are not examined, processed,
inserted, or deleted by any node along a packet's delivery path. inserted, or deleted by any node along a packet's delivery path.
o 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.
o Added paragraph to Section 4 to clarify how Extension Headers are o Added paragraph to Section 4 to clarify how Extension Headers are
numbered and which are upper-layer headers. numbered and which are upper-layer headers.
o Revision Section 4.5 on IPv6 Fragmentation based on updates from o Revision Section 4.5 on IPv6 Fragmentation based on updates from
RFC5722, RFC6946 RFC7112, and RFC8021. This includes: RFC5722, RFC6946 RFC7112, and RFC8021. This include:
- Revised the text to handle the case of fragments that are whole - Revised the text to handle the case of fragments that are whole
datagrams (i.e., both the Fragment Offset field and the M flag datagrams (i.e., both the Fragment Offset field and the M flag
are zero). If received they should be processed as a are zero). If received they should be processed as a
reassembled packet. Any other fragments that match should be reassembled packet. Any other fragments that match should be
processed independently. The revised Fragment creation process processed independently. The revised Fragment creation process
was modified to not create whole datagram fragments (Fragment was modified to not create whole datagram fragments (Fragment
Offset field and the M flag are zero). Offset field and the M flag are zero).
- Changed the text to require that IPv6 nodes must not create - Changed the text to require that IPv6 nodes must not create
overlapping fragments. Also, when reassembling an IPv6 overlapping fragments. Also, when reassembling an IPv6
datagram, if one or more its constituent fragments is datagram, if one or more its constituent fragments is
determined to be an overlapping fragment, the entire datagram determined to be an overlapping fragment, the entire datagram
(and any constituent fragments, including those not yet (and any constituent fragments) must be silently discarded.
received) MUST be silently discarded. Includes clarification Includes a clarification that no ICMP error message should be
that no ICMP error message should be sent if overlapping sent if overlapping fragments are received.
fragments are received.
- Revised the text to require that all headers through the first - Revised the text to require that all headers through the first
Upper-Layer Header are in the first fragment. This changed the Upper-Layer Header are in the first fragment. This changed the
text describing how packets are fragmented and reassembled, and text describing how packets are fragmented and reassembled, and
added a new error case. added a new error case.
- Added text to Fragment Header process on handling exact - Added text to Fragment Header process on handling exact
duplicate fragments. duplicate fragments.
- Updated the Fragmentation header text to correct the inclusion - Updated the Fragmentation header text to correct the inclusion
of AH and note no next header case. of AH and note no next header case.
- Change terminology in Fragment header section from - Change terminology in Fragment header section from
"Unfragmentable Headers" to "Per-Fragment Headers". "Unfragmentable Headers" to "Per-Fragment Headers".
- Removed paragraph in Section 5 that required including a - Removed the paragraph in Section 5 that required including a
fragment header to outgoing packets if a ICMP Packet Too Big fragment header to outgoing packets if a ICMP Packet Too Big
message reporting a Next-Hop MTU less than 1280. message reporting a Next-Hop MTU less than 1280.
- Changed the text to clarify MTU restriction and 8-byte - Changed the text to clarify MTU restriction and 8-byte
restrictions, and noting the restriction on headers in first restrictions, and noting the restriction on headers in first
fragment. fragment.
o Changed requirement for HBH header to a may, and added a note to o Changed requirement for HBH header to a may, and added a note to
indicate what is expected regarding HBH headers. indicate what is expected regarding HBH headers.
skipping to change at page 35, line 27 skipping to change at page 38, line 17
o Add instruction to the IANA Considerations section to change o Add instruction to the IANA Considerations section to change
references to RFC2460 to this document references to RFC2460 to this document
o Add a paragraph to the acknowledgement section acknowledging the o Add a paragraph to the acknowledgement section acknowledging the
authors of the updating documents authors of the updating documents
o Update references to current versions and assign references to o Update references to current versions and assign references to
normative and informative. normative and informative.
o Incorporate the update from RFC6564 to add a new Section 4.8 that o Incorporated the update from RFC6564 to add a new Section 4.8 that
describes recommendations for defining new Extension headers and describes recommendations for defining new Extension headers and
options options
o Incorporate the update in made by RFC6935 "UDP Checksums for o Incorporate the update in made by RFC6935 "UDP Checksums for
Tunneled Packets" in Section 8. Added an exception to the default Tunneled Packets" in Section 8. Added an exception to the default
behaviour for the handling of handling UDP packets with zero behaviour for the handling of handling UDP packets with zero
checksums for tunnels. checksums for tunnels.
o Incorporate the updates from RFC5095 and RFC5871 to remove the o Incorporate the updates from RFC5095 and RFC5871 to remove the
description of the RH0 Routing Header, that the allocations description of the RH0 Routing Header, that the allocations
skipping to change at page 36, line 18 skipping to change at page 39, line 7
draft. draft.
Errata ID: 2843: This errata is marked rejected. No change was Errata ID: 2843: This errata is marked rejected. No change was
made. made.
o Simplify the text in Section 6 about Flow Labels and remove o Simplify the text in Section 6 about Flow Labels and remove
Appendix A, and instead point to the current specifications of the Appendix A, and instead point to the current specifications of the
IPv6 Flow Label field as defined in [RFC6437] and the Traffic IPv6 Flow Label field as defined in [RFC6437] and the Traffic
Class as defined in [RFC2474] and [RFC3168]. Class as defined in [RFC2474] and [RFC3168].
o Revised and expanded the Security Consideration section.
B.1. Change History Since RFC2460 B.1. Change History Since RFC2460
NOTE TO RFC EDITOR: Please remove this subsection prior to RFC NOTE TO RFC EDITOR: Please remove this subsection prior to RFC
Publication Publication
This section describes change history made in each Internet Draft This section describes change history made in each Internet Draft
that went into producing this version. The numbers identify the that went into producing this version. The numbers identify the
Internet-Draft version in which the change was made. Internet-Draft version in which the change was made.
Working Group Internet Drafts Working Group Internet Drafts
10) Revised and expanded Security Consideration Section based on
IESG Discuss comments.
10) Editorial changes.
09) Based on results of IETF last call, changed text in Section 4 09) Based on results of IETF last call, changed text in Section 4
to add clarification that extension headers are not examined, to add clarification that extension headers are not examined,
processed, inserted, or deleted by any node along a packet's processed, inserted, or deleted by any node along a packet's
delivery path. delivery path.
09) Changed reference from draft-ietf-6man-rfc4291bis to RFC4291 09) Changed reference from draft-ietf-6man-rfc4291bis to RFC4291
because the bis draft won't be advanced as the same time. because the bis draft won't be advanced as the same time.
09) Revised "Changes since RFC2460" Section to have a summary of 09) Revised "Changes since RFC2460" Section to have a summary of
changes since RFC2460 and a separate subsection with a change changes since RFC2460 and a separate subsection with a change
 End of changes. 18 change blocks. 
32 lines changed or deleted 146 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/