draft-ietf-6man-rfc2460bis-06.txt | draft-ietf-6man-rfc2460bis-07.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: March 17, 2017 September 13, 2016 | Expires: April 7, 2017 October 4, 2016 | |||
Internet Protocol, Version 6 (IPv6) Specification | Internet Protocol, Version 6 (IPv6) Specification | |||
draft-ietf-6man-rfc2460bis-06 | draft-ietf-6man-rfc2460bis-07 | |||
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 March 17, 2017. | This Internet-Draft will expire on April 7, 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 2, line 34 ¶ | skipping to change at page 2, line 34 ¶ | |||
4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 4.2. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 | 4.3. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 12 | |||
4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 13 | 4.4. Routing Header . . . . . . . . . . . . . . . . . . . . . 13 | |||
4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14 | 4.5. Fragment Header . . . . . . . . . . . . . . . . . . . . . 14 | |||
4.6. Destination Options Header . . . . . . . . . . . . . . . 21 | 4.6. Destination Options Header . . . . . . . . . . . . . . . 21 | |||
4.7. No Next Header . . . . . . . . . . . . . . . . . . . . . 22 | 4.7. No Next Header . . . . . . . . . . . . . . . . . . . . . 22 | |||
4.8. Defining New Extension Headers and Options . . . . . . . 22 | 4.8. Defining New Extension Headers and Options . . . . . . . 22 | |||
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 . . . . . . . . . . . . . . . . . 25 | |||
8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 24 | 8.1. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 25 | |||
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 . . . . . . . . . . . . 27 | |||
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 . . . . . . . . . . . . . . . . . . . . . 28 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | |||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 29 | 12.2. Informative References . . . . . . . . . . . . . . . . . 29 | |||
Appendix A. Formatting Guidelines for Options . . . . . . . . . 30 | Appendix A. Formatting Guidelines for Options . . . . . . . . . 31 | |||
Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 33 | Appendix B. CHANGES SINCE RFC2460 . . . . . . . . . . . . . . . 34 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
1. Introduction | 1. Introduction | |||
IP version 6 (IPv6) is a new version of the Internet Protocol, | IP version 6 (IPv6) is a new version of the Internet Protocol, | |||
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 6, line 32 ¶ | skipping to change at page 6, line 32 ¶ | |||
Destination Address 128-bit address of the intended recipient of | Destination Address 128-bit address of the intended recipient of | |||
the packet (possibly not the ultimate | the packet (possibly not the ultimate | |||
recipient, if a Routing header is present). | recipient, if a Routing header is present). | |||
See [I-D.ietf-6man-rfc4291bis] and section | See [I-D.ietf-6man-rfc4291bis] and section | |||
4.4. | 4.4. | |||
4. IPv6 Extension Headers | 4. IPv6 Extension Headers | |||
In IPv6, optional internet-layer information is encoded in separate | In IPv6, optional internet-layer information is encoded in separate | |||
headers that may be placed between the IPv6 header and the upper- | 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 | layer header in a packet. There is a small number of such extension | |||
headers, each identified by a distinct Next Header value. As | headers, each one identified by a distinct Next Header value. | |||
illustrated in these examples, an IPv6 packet may carry zero, one, or | ||||
more extension headers, each identified by the Next Header field of | Extension Headers are numbered from IANA IP Protocol Numbers | |||
the preceding header: | [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 | | IPv6 header | TCP header + data | |||
| | | | | | |||
| Next Header = | | | Next Header = | | |||
| TCP | | | TCP | | |||
+---------------+------------------------ | +---------------+------------------------ | |||
+---------------+----------------+------------------------ | +---------------+----------------+------------------------ | |||
| IPv6 header | Routing header | TCP header + data | | IPv6 header | Routing header | TCP header + data | |||
skipping to change at page 8, line 18 ¶ | skipping to change at page 8, line 18 ¶ | |||
the source and destination nodes. The Hop-by-Hop Options header, | the source and destination nodes. The Hop-by-Hop Options header, | |||
when present, must immediately follow the IPv6 header. Its presence | when present, must immediately follow the IPv6 header. Its presence | |||
is indicated by the value zero in the Next Header field of the IPv6 | is indicated by the value zero in the Next Header field of the IPv6 | |||
header. | header. | |||
NOTE: While [RFC2460] required that all nodes must examine and | NOTE: While [RFC2460] required that all nodes must examine and | |||
process the Hop-by-Hop Options header, it is now expected that nodes | 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- | along a packet's delivery path only examine and process the Hop-by- | |||
Hop Options header if explicitly configured to do so. | Hop Options header if explicitly configured to do so. | |||
If, as a result of processing a header, a node is required to proceed | If, as a result of processing a header, the destination node is | |||
to the next header but the Next Header value in the current header is | required to proceed to the next header but the Next Header value in | |||
unrecognized by the node, it should discard the packet and send an | the current header is unrecognized by the node, it should discard the | |||
ICMP Parameter Problem message to the source of the packet, with an | packet and send an ICMP Parameter Problem message to the source of | |||
ICMP Code value of 1 ("unrecognized Next Header type encountered") | the packet, with an ICMP Code value of 1 ("unrecognized Next Header | |||
and the ICMP Pointer field containing the offset of the unrecognized | type encountered") and the ICMP Pointer field containing the offset | |||
value within the original packet. The same action should be taken if | of the unrecognized value within the original packet. The same | |||
a node encounters a Next Header value of zero in any header other | action should be taken if a node encounters a Next Header value of | |||
than an IPv6 header. | zero in any header other than an IPv6 header. | |||
Each extension header is an integer multiple of 8 octets long, in | Each extension header is an integer multiple of 8 octets long, in | |||
order to retain 8-octet alignment for subsequent headers. Multi- | order to retain 8-octet alignment for subsequent headers. Multi- | |||
octet fields within each extension header are aligned on their | octet fields within each extension header are aligned on their | |||
natural boundaries, i.e., fields of width n octets are placed at an | 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, | integer multiple of n octets from the start of the header, for n = 1, | |||
2, 4, or 8. | 2, 4, or 8. | |||
A full implementation of IPv6 includes implementation of the | A full implementation of IPv6 includes implementation of the | |||
following extension headers: | following extension headers: | |||
skipping to change at page 19, line 40 ¶ | skipping to change at page 19, line 40 ¶ | |||
from the fragments following the Fragment headers in each of | from the fragments following the Fragment headers in each of | |||
the fragment packets. The length of each fragment is computed | the fragment packets. The length of each fragment is computed | |||
by subtracting from the packet's Payload Length the length of | by subtracting from the packet's Payload Length the length of | |||
the headers between the IPv6 header and fragment itself; its | the headers between the IPv6 header and fragment itself; its | |||
relative position in Fragmentable Part is computed from its | relative position in Fragmentable Part is computed from its | |||
Fragment Offset value. | Fragment Offset value. | |||
The Fragment header is not present in the final, reassembled | The Fragment header is not present in the final, reassembled | |||
packet. | 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 | 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 | Offset field and the M flag are zero), then it does not need | |||
any further reassembly and should be processed as a fully | any further reassembly and should be processed as a fully | |||
reassembled packet (i.e., updating Next Header, adjust Payload | reassembled packet (i.e., updating Next Header, adjust Payload | |||
Length, removing the Fragmentation Header, etc.). Any other | Length, removing the Fragmentation Header, etc.). Any other | |||
fragments that match this packet (i.e., the same IPv6 Source | fragments that match this packet (i.e., the same IPv6 Source | |||
Address, IPv6 Destination Address, and Fragment Identification) | Address, IPv6 Destination Address, and Fragment Identification) | |||
should be processed independently. | should be processed independently. | |||
The following error conditions may arise when reassembling fragmented | The following error conditions may arise when reassembling fragmented | |||
packets: | packets: | |||
If insufficient fragments are received to complete reassembly of a | o If insufficient fragments are received to complete reassembly | |||
packet within 60 seconds of the reception of the first-arriving | of a packet within 60 seconds of the reception of the first- | |||
fragment of that packet, reassembly of that packet must be | arriving fragment of that packet, reassembly of that packet | |||
abandoned and all the fragments that have been received for that | must be abandoned and all the fragments that have been received | |||
packet must be discarded. If the first fragment (i.e., the one | for that packet must be discarded. If the first fragment | |||
with a Fragment Offset of zero) has been received, an ICMP Time | (i.e., the one with a Fragment Offset of zero) has been | |||
Exceeded -- Fragment Reassembly Time Exceeded message should be | received, an ICMP Time Exceeded -- Fragment Reassembly Time | |||
sent to the source of that fragment. | Exceeded message should be sent to the source of that fragment. | |||
If the length of a fragment, as derived from the fragment packet's | o If the length of a fragment, as derived from the fragment | |||
Payload Length field, is not a multiple of 8 octets and the M flag | packet's Payload Length field, is not a multiple of 8 octets | |||
of that fragment is 1, then that fragment must be discarded and an | and the M flag of that fragment is 1, then that fragment must | |||
ICMP Parameter Problem, Code 0, message should be sent to the | be discarded and an ICMP Parameter Problem, Code 0, message | |||
source of the fragment, pointing to the Payload Length field of | should be sent to the source of the fragment, pointing to the | |||
the fragment packet. | Payload Length field of the fragment packet. | |||
If the length and offset of a fragment are such that the Payload | o If the length and offset of a fragment are such that the | |||
Length of the packet reassembled from that fragment would exceed | Payload Length of the packet reassembled from that fragment | |||
65,535 octets, then that fragment must be discarded and an ICMP | would exceed 65,535 octets, then that fragment must be | |||
Parameter Problem, Code 0, message should be sent to the source of | discarded and an ICMP Parameter Problem, Code 0, message should | |||
the fragment, pointing to the Fragment Offset field of the | be sent to the source of the fragment, pointing to the Fragment | |||
fragment packet. | Offset field of the fragment packet. | |||
If the first fragment does not include all headers through an | o If the first fragment does not include all headers through an | |||
Upper-Layer header, then that fragment should be discarded and an | Upper-Layer header, then that fragment should be discarded and | |||
ICMP Parameter Problem, Code 3, message should be sent to the | an ICMP Parameter Problem, Code 3, message should be sent to | |||
source of the fragment, with the Pointer field set to zero. | the source of the fragment, with the Pointer field set to zero. | |||
If any of the fragments being reassembled overlaps with any other | o If any of the fragments being reassembled overlaps with any | |||
fragments being reassembled for the same packet, reassembly of | other fragments being reassembled for the same packet, | |||
that packet must be abandoned and all the fragments that have been | reassembly of that packet must be abandoned and all the | |||
received for that packet must be discarded. | 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 | The following conditions are not expected to occur, but are not | |||
considered errors if they do: | 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 | |||
skipping to change at page 22, line 39 ¶ | skipping to change at page 22, line 42 ¶ | |||
The value 59 in the Next Header field of an IPv6 header or any | The value 59 in the Next Header field of an IPv6 header or any | |||
extension header indicates that there is nothing following that | extension header indicates that there is nothing following that | |||
header. If the Payload Length field of the IPv6 header indicates the | 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 | 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 | contains 59, those octets must be ignored, and passed on unchanged if | |||
the packet is forwarded. | the packet is forwarded. | |||
4.8. Defining New Extension Headers and Options | 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 | 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 | Extension Header that has hop-by-hop behavior is the Hop-by-Hop | |||
Options header. | Options header. | |||
New hop-by-hop options are not recommended because it is expected | New hop-by-hop options are not recommended because nodes may be | |||
that nodes along a packet's delivery path will only examine and | configured to ignore the Hop-by-Hop Option header, drop packets | |||
process the hop-by-hop option header if explicitly configured to do | containing a hop-by-hop header, or assign packets containing a hop- | |||
so. | 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 IPv6 extension headers is not recommended. There has to | |||
defining new Extension Headers, it is recommended that the | a very clear justification why any new extension header is needed | |||
Destination Options header is used to carry optional information that | before it is standardized. Instead of defining new Extension | |||
need be examined only by a packet's destination node(s). | 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 | If new Extension Headers are defined, they need to use the following | |||
format: | format: | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Next Header | Hdr Ext Len | | | | Next Header | Hdr Ext Len | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |||
| | | | | | |||
. . | . . | |||
. Header Specific Data . | . Header Specific Data . | |||
skipping to change at page 27, line 42 ¶ | skipping to change at page 28, line 13 ¶ | |||
by the responder. | by the responder. | |||
9. IANA Considerations | 9. IANA Considerations | |||
RFC2460 is referenced in a number of IANA registries. These include: | RFC2460 is referenced in a number of IANA registries. These include: | |||
o Internet Protocol Version 6 (IPv6) Parameters [IANA-6P] | o Internet Protocol Version 6 (IPv6) Parameters [IANA-6P] | |||
o Assigned Internet Protocol Numbers [IANA-PN] | 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. | The IANA should update these references to point to this document. | |||
10. Security Considerations | 10. Security Considerations | |||
The security features of IPv6 are described in the Security | IPv6, from the viewpoint of the basic format and transmission of | |||
Architecture for the Internet Protocol [RFC4301]. | 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 | 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 28, line 30 ¶ | 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 D. Deering, "IP Version 6 Addressing | Hinden, R. and S. Deering, "IP Version 6 Addressing | |||
Architecture", draft-ietf-6man-rfc4291bis-03 (work in | Architecture", draft-ietf-6man-rfc4291bis-04 (work in | |||
progress), June 2016. | progress), September 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 29, line 26 ¶ | skipping to change at page 29, line 50 ¶ | |||
12.2. Informative References | 12.2. Informative References | |||
[IANA-6P] "Internet Protocol Version 6 (IPv6) Parameters", | [IANA-6P] "Internet Protocol Version 6 (IPv6) Parameters", | |||
<https://www.iana.org/assignments/ipv6-parameters/ | <https://www.iana.org/assignments/ipv6-parameters/ | |||
ipv6-parameters.xhtml>. | ipv6-parameters.xhtml>. | |||
[IANA-EH] "IPv6 Extension Header Types", | [IANA-EH] "IPv6 Extension Header Types", | |||
<https://www.iana.org/assignments/ipv6-parameters/ipv6- | <https://www.iana.org/assignments/ipv6-parameters/ipv6- | |||
parameters.xhtml#extension-header>. | parameters.xhtml#extension-header>. | |||
[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)", | ||||
<http://www.iana.org/assignments/rpc-netids/ | ||||
rpc-netids.xhtml>. | ||||
[IANA-NL] "Network Layer Protocol Identifiers (NLPIDs) of Interest", | ||||
<http://www.iana.org/assignments/nlpids/nlpids.xhtml>. | ||||
[IANA-NS] "Technical requirements for authoritative name servers", | ||||
<https://www.iana.org/help/nameserver-requirements>. | ||||
[IANA-PN] "Assigned Internet Protocol Numbers", | [IANA-PN] "Assigned Internet Protocol Numbers", | |||
<https://www.iana.org/assignments/protocol-numbers/ | <https://www.iana.org/assignments/protocol-numbers/ | |||
protocol-numbers.xhtml>. | protocol-numbers.xhtml>. | |||
[IANA-PR] "Protocol Registries", <https://www.iana.org/protocols>. | ||||
[IANA-RH] "IANA Routing Types Parameter Registry", | [IANA-RH] "IANA Routing Types Parameter Registry", | |||
<https://www.iana.org/assignments/ipv6-parameters/ | <https://www.iana.org/assignments/ipv6-parameters/ | |||
ipv6-parameters.xhtml#ipv6-parameters-3>. | ipv6-parameters.xhtml#ipv6-parameters-3>. | |||
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD | [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD | |||
51, RFC 1661, DOI 10.17487/RFC1661, July 1994, | 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, | |||
<http://www.rfc-editor.org/info/rfc1661>. | <http://www.rfc-editor.org/info/rfc1661>. | |||
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery | [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery | |||
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August | for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August | |||
skipping to change at page 33, 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 | |||
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 | 06) Added the Routing Header to the list required extension | |||
headers that a full implementation includes. | headers that a full implementation includes. | |||
06) Moved the text in Section 4.5 regarding the handling of | 06) Moved the text in Section 4.5 regarding the handling of | |||
received overlapping fragments to the list of error | received overlapping fragments to the list of error | |||
conditions | conditions | |||
06) Rewrote the text in Section 4.8 "Defining New Extension | 06) Rewrote the text in Section 4.8 "Defining New Extension | |||
Headers and Options" to be clearer and remove redundant text. | Headers and Options" to be clearer and remove redundant text. | |||
skipping to change at page 36, line 16 ¶ | skipping to change at page 37, line 32 ¶ | |||
recommendations for defining new Extension headers and | recommendations for defining new Extension headers and | |||
options | options | |||
RFC7045: The changes were to add a reference to RFC7045, | RFC7045: The changes were to add a reference to RFC7045, | |||
change the requirement for processing the hop-by-hop | change the requirement for processing the hop-by-hop | |||
option to a should, and added a note that due to | option to a should, and added a note that due to | |||
performance restrictions some nodes won't process the Hop- | performance restrictions some nodes won't process the Hop- | |||
by-Hop Option header. | by-Hop Option header. | |||
RFC7112: The changes were to revise the Fragmentation | RFC7112: The changes were to revise the Fragmentation | |||
Section to require that all headers through the first | Section (Section 4.5) to require that all headers through | |||
Upper-Layer Header are in the first fragment. This | the first Upper-Layer Header are in the first fragment. | |||
changed the text describing how packets are fragmented and | This changed the text describing how packets are | |||
reassembled and added a new error case. | fragmented and reassembled and added a new error case. | |||
06) Editorial changes. | 06) Editorial changes. | |||
05) The purpose of this draft is to incorporate the updates | 05) The purpose of this draft is to incorporate the updates | |||
dealing with fragmentation as defined in RFC5722 and RFC6946. | dealing with fragmentation as defined in RFC5722 and RFC6946. | |||
Note: The issue relating to the handling of exact duplicate | Note: The issue relating to the handling of exact duplicate | |||
fragments identified on the mailing list is left open. | 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. | extension headers defined in this document. | |||
05) Editorial changes. | 05) Editorial changes. | |||
04) The purpose of this draft is to update the document to | 04) The purpose of this draft is to update the document to | |||
incorporate the update made by RFC6935 "UDP Checksums for | incorporate the update made by RFC6935 "UDP Checksums for | |||
Tunneled Packets". | Tunneled Packets". | |||
04) Remove Routing (Type 0) header from the list of required | 04) Remove Routing (Type 0) header from the list of required | |||
extension headers. | extension headers. | |||
skipping to change at page 37, line 16 ¶ | skipping to change at page 38, line 35 ¶ | |||
document to resolve the open Errata on RFC2460. | document to resolve the open Errata on RFC2460. | |||
Errata ID: 2541: This errata notes that RFC2460 didn't | Errata ID: 2541: This errata notes that RFC2460 didn't | |||
update RFC2205 when the length of the Flow Label was | update RFC2205 when the length of the Flow Label was | |||
changed from 24 to 20 bits from RFC1883. This issue was | changed from 24 to 20 bits from RFC1883. This issue was | |||
resolved in RFC6437 where the Flow Label is defined. This | resolved in RFC6437 where the Flow Label is defined. This | |||
draft now references RFC6437. No change is required. | draft now references RFC6437. No change is required. | |||
Errata ID: 4279: This errata noted that the specification | Errata ID: 4279: This errata noted that the specification | |||
doesn't handle the case of a forwarding node receiving a | doesn't handle the case of a forwarding node receiving a | |||
packet with a zero Hop Limit. This is fixed in | packet with a zero Hop Limit. This is fixed in Section 3 | |||
Section 3.0 of this draft. Note: No change was made | of this draft. Note: No change was made regarding host | |||
regarding host behaviour. | behaviour. | |||
Errata ID: 2843: This errata is marked rejected. No | Errata ID: 2843: This errata is marked rejected. No | |||
change is required. | change is required. | |||
02) Editorial changes to the Flow Label and Traffic Class text. | 02) Editorial changes to the Flow Label and Traffic Class text. | |||
01) The purpose of this version of the draft is to update the | 01) The purpose of this version of the draft is to update the | |||
document to point to the current specifications of the IPv6 | document to point to the current specifications of the IPv6 | |||
Flow Label field as defined in [RFC6437] and the Traffic | Flow Label field as defined in [RFC6437] and the Traffic | |||
Class as defined in [RFC2474] and [RFC3168]. | Class as defined in [RFC2474] and [RFC3168]. | |||
End of changes. 28 change blocks. | ||||
82 lines changed or deleted | 151 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/ |