draft-ietf-6man-node-req-bis-02.txt   draft-ietf-6man-node-req-bis-03.txt 
Internet Engineering Task Force J. Loughney Internet Engineering Task Force J. Loughney
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Informational November 3, 2008 Intended status: Informational T. Narten
Expires: May 7, 2009 Expires: January 14, 2010 IBM Corporation
July 13, 2009
IPv6 Node Requirements RFC 4294-bis IPv6 Node Requirements RFC 4294-bis
draft-ietf-6man-node-req-bis-02.txt draft-ietf-6man-node-req-bis-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document defines requirements for IPv6 nodes. It is expected This document defines requirements for IPv6 nodes. It is expected
that IPv6 will be deployed in a wide range of devices and situations. that IPv6 will be deployed in a wide range of devices and situations.
Specifying the requirements for IPv6 nodes allows IPv6 to function Specifying the requirements for IPv6 nodes allows IPv6 to function
well and interoperate in a large number of situations and well and interoperate in a large number of situations and
deployments. deployments.
Table of Contents Table of Contents
skipping to change at page 2, line 20 skipping to change at page 2, line 34
2.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 4 2.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 4
3. Abbreviations Used in This Document . . . . . . . . . . . . . 5 3. Abbreviations Used in This Document . . . . . . . . . . . . . 5
4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Transmission of IPv6 Packets over Ethernet Networks - 4.1. Transmission of IPv6 Packets over Ethernet Networks -
RFC 2464 . . . . . . . . . . . . . . . . . . . . . . . . . 6 RFC 2464 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. IP version 6 over PPP - RFC 5072 . . . . . . . . . . . . . 6 4.2. IP version 6 over PPP - RFC 5072 . . . . . . . . . . . . . 6
4.3. IPv6 over ATM Networks - RFC 2492 . . . . . . . . . . . . 6 4.3. IPv6 over ATM Networks - RFC 2492 . . . . . . . . . . . . 6
5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . . 6 5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . . 6
5.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 7 5.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 7
5.3. Path MTU Discovery and Packet Size . . . . . . . . . . . . 8 5.3. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 8
5.3.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 8 5.4. Path MTU Discovery and Packet Size . . . . . . . . . . . . 8
5.4. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 8 5.4.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 8
5.5. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 5.5. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 8
5.6. ICMP for the Internet Protocol Version 6 (IPv6) - RFC
4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 8 5.7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 8
5.6.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 8 5.7.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 8
5.6.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 8 5.7.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 9
5.6.3. Privacy Extensions for Address Configuration in 5.7.3. Privacy Extensions for Address Configuration in
IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 9 IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 9
5.6.4. Default Address Selection for IPv6 - RFC 3484 . . . . 9 5.7.4. Default Address Selection for IPv6 - RFC 3484 . . . . 9
5.6.5. Stateful Address Autoconfiguration . . . . . . . . . . 9 5.7.5. Stateful Address Autoconfiguration . . . . . . . . . . 9
5.7. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 . . 9 5.8. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 . . 10
6. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 6.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
- RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 10 - RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1. 5.2.1. Managed Address Configuration . . . . . . . . 10 6.2.1. 5.2.1. Managed Address Configuration . . . . . . . . 11
6.2.2. Other Configuration Information . . . . . . . . . . . 11 6.2.2. Other Configuration Information . . . . . . . . . . . 11
6.2.3. Use of Router Advertisements in Managed 6.2.3. Use of Router Advertisements in Managed
Environments . . . . . . . . . . . . . . . . . . . . . 11 Environments . . . . . . . . . . . . . . . . . . . . . 11
7. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 11 7. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 12
7.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 11 7.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 12
7.1.1. Transition Mechanisms for IPv6 Hosts and Routers - 7.1.1. Basic Transition Mechanisms for IPv6 Hosts and
RFC 2893 . . . . . . . . . . . . . . . . . . . . . . . 11 Routers - RFC 4213 . . . . . . . . . . . . . . . . . . 12
8. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Basic Architecture . . . . . . . . . . . . . . . . . . . . 12 9.1. Basic Architecture . . . . . . . . . . . . . . . . . . . . 12
9.2. Security Protocols . . . . . . . . . . . . . . . . . . . . 12 9.2. Security Protocols . . . . . . . . . . . . . . . . . . . . 13
9.3. Transforms and Algorithms . . . . . . . . . . . . . . . . 12 9.3. Transforms and Algorithms . . . . . . . . . . . . . . . . 13
9.4. Key Management Methods . . . . . . . . . . . . . . . . . . 13 9.4. Key Management Methods . . . . . . . . . . . . . . . . . . 13
10. Router-Specific Functionality . . . . . . . . . . . . . . . . 13 10. Router-Specific Functionality . . . . . . . . . . . . . . . . 14
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . 14 10.1.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . 14
10.1.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . 14 10.1.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . 14
11. Network Management . . . . . . . . . . . . . . . . . . . . . . 14 11. Network Management . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Management Information Base Modules (MIBs) . . . . . . . . 14 11.1. Management Information Base Modules (MIBs) . . . . . . . . 14
11.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . . 14 11.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . . 15
11.1.2. Management Information Base for the Internet 11.1.2. Management Information Base for the Internet
Protocol (IP) . . . . . . . . . . . . . . . . . . . . 14 Protocol (IP) . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15
13. Authors and Acknowledgements . . . . . . . . . . . . . . . . . 15 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 15 14. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 16
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 15. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 17
15.1. Normative References . . . . . . . . . . . . . . . . . . . 16 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
15.2. Informative References . . . . . . . . . . . . . . . . . . 19 16.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 16.2. Informative References . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Requirements Language 1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 2. Introduction
The goal of this document is to define the common functionality The goal of this document is to define the common functionality
skipping to change at page 6, line 49 skipping to change at page 6, line 49
be supported. be supported.
RFC 2460 specifies extension headers and the processing for these RFC 2460 specifies extension headers and the processing for these
headers. headers.
A full implementation of IPv6 includes implementation of the A full implementation of IPv6 includes implementation of the
following extension headers: Hop-by-Hop Options, Routing (Type 0), following extension headers: Hop-by-Hop Options, Routing (Type 0),
Fragment, Destination Options, Authentication and Encapsulating Fragment, Destination Options, Authentication and Encapsulating
Security Payload [RFC2460]. Security Payload [RFC2460].
An IPv6 node MUST be able to process these headers. It should be An IPv6 node MUST be able to process these headers. An exception is
noted that there is some discussion about the use of Routing Headers Routing Header type 0 (RH0) which was deprecated by [RFC5095] due to
and possible security threats 'IPv6-RH' that they cause. security concerns, and which MUST be treated as an unrecognized
routing type.
5.2. Neighbor Discovery for IPv6 - RFC 4861 5.2. Neighbor Discovery for IPv6 - RFC 4861
Neighbor Discovery SHOULD be supported. [RFC4861] states: Neighbor Discovery SHOULD be supported. [RFC4861] states:
Unless specified otherwise (in a document that covers operating IP Unless specified otherwise (in a document that covers operating IP
over a particular link type) this document applies to all link over a particular link type) this document applies to all link
types. However, because ND uses link-layer multicast for some of types. However, because ND uses link-layer multicast for some of
its services, it is possible that on some link types (e.g., NBMA its services, it is possible that on some link types (e.g., NBMA
links) alternative protocols or mechanisms to implement those links) alternative protocols or mechanisms to implement those
skipping to change at page 8, line 6 skipping to change at page 8, line 8
Advertisement options is dependent on supporting the specification Advertisement options is dependent on supporting the specification
where the RA is specified. where the RA is specified.
Sending and Receiving Neighbor Solicitation (NS) and Neighbor Sending and Receiving Neighbor Solicitation (NS) and Neighbor
Advertisement (NA) MUST be supported. NS and NA messages are Advertisement (NA) MUST be supported. NS and NA messages are
required for Duplicate Address Detection (DAD). required for Duplicate Address Detection (DAD).
Redirect functionality SHOULD be supported. If the node is a router, Redirect functionality SHOULD be supported. If the node is a router,
Redirect functionality MUST be supported. Redirect functionality MUST be supported.
5.3. Path MTU Discovery and Packet Size 5.3. IPv6 Router Advertisement Flags Option - RFC 5175
5.3.1. Path MTU Discovery - RFC 1981 Router Advertisements include an 8-bit field of single-bit Router
Advertisement flags. The Router Advertisement Flags Option extends
the number of available flag bits by 48 bits. At the time of this
writing, 6 of the original 8 bit flags have been assigned, while 2
are available for future assignment. No flags have been defined that
make use of the new option, and thus strictly speaking, there is no
requirement to implement the option today. However, implementations
that are able to pass unrecognized options to a higher level entity
that may be able to understand them (e.g., a user-level process using
a "raw socket" facility), MAY take steps to handle the option in
anticipation of a future usage.
5.4. Path MTU Discovery and Packet Size
5.4.1. Path MTU Discovery - RFC 1981
From [RFC2460]:
It is strongly recommended that IPv6 nodes implement Path MTU
Discovery [RFC1981], in order to discover and take advantage of
path MTUs greater than 1280 octets. However, a minimal IPv6
implementation (e.g., in a boot ROM) may simply restrict itself to
sending packets no larger than 1280 octets, and omit
implementation of Path MTU Discovery.
Path MTU Discovery [RFC1981] SHOULD be supported, though minimal
implementations MAY choose to not support it and avoid large packets.
The rules in RFC 2460 MUST be followed for packet fragmentation and The rules in RFC 2460 MUST be followed for packet fragmentation and
reassembly. reassembly.
5.4. IPv6 Jumbograms - RFC 2675 5.5. IPv6 Jumbograms - RFC 2675
IPv6 Jumbograms [RFC2675] MAY be supported. IPv6 Jumbograms [RFC2675] MAY be supported.
5.5. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 5.6. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443
ICMPv6 [RFC4443] MUST be supported. ICMPv6 [RFC4443] MUST be supported.
5.6. Addressing 5.7. Addressing
5.6.1. IP Version 6 Addressing Architecture - RFC 4291 5.7.1. IP Version 6 Addressing Architecture - RFC 4291
The IPv6 Addressing Architecture [RFC4291] MUST be supported. The IPv6 Addressing Architecture [RFC4291] MUST be supported.
5.6.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 5.7.2. IPv6 Stateless Address Autoconfiguration - RFC 4862
IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. IPv6 Stateless Address Autoconfiguration is defined in [RFC4862].
This specification MUST be supported for nodes that are hosts. This specification MUST be supported for nodes that are hosts.
Static address can be supported as well. Static address can be supported as well.
Nodes that are routers MUST be able to generate link local addresses Nodes that are routers MUST be able to generate link local addresses
as described in RFC 4862 [RFC4862]. as described in RFC 4862 [RFC4862].
From 4862: From 4862:
skipping to change at page 9, line 5 skipping to change at page 9, line 28
information advertised by routers, routers will need to be information advertised by routers, routers will need to be
configured by some other means. However, it is expected that configured by some other means. However, it is expected that
routers will generate link-local addresses using the mechanism routers will generate link-local addresses using the mechanism
described in this document. In addition, routers are expected to described in this document. In addition, routers are expected to
successfully pass the Duplicate Address Detection procedure successfully pass the Duplicate Address Detection procedure
described in this document on all addresses prior to assigning described in this document on all addresses prior to assigning
them to an interface. them to an interface.
Duplicate Address Detection (DAD) MUST be supported. Duplicate Address Detection (DAD) MUST be supported.
5.6.3. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 5.7.3. Privacy Extensions for Address Configuration in IPv6 - RFC 4941
Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] Privacy Extensions for Stateless Address Autoconfiguration [RFC4941]
SHOULD be supported. It is recommended that this behavior be SHOULD be supported. It is recommended that this behavior be
configurable on a connection basis within each application when configurable on a connection basis within each application when
available. It is noted that a number of applications do not work available. It is noted that a number of applications do not work
with addresses generated with this method, while other applications with addresses generated with this method, while other applications
work quite well with them. work quite well with them.
5.6.4. Default Address Selection for IPv6 - RFC 3484 5.7.4. Default Address Selection for IPv6 - RFC 3484
The rules specified in the Default Address Selection for IPv6 The rules specified in the Default Address Selection for IPv6
[RFC3484] document MUST be implemented. It is expected that IPv6 [RFC3484] document MUST be implemented. It is expected that IPv6
nodes will need to deal with multiple addresses. nodes will need to deal with multiple addresses.
5.6.5. Stateful Address Autoconfiguration 5.7.5. Stateful Address Autoconfiguration
Stateful Address Autoconfiguration MAY be supported. DHCPv6 Stateful Address Autoconfiguration MAY be supported. DHCPv6
[RFC3315] is the standard stateful address configuration protocol; [RFC3315] is the standard stateful address configuration protocol;
see Section 5.3 for DHCPv6 support. see Section 6.2 for DHCPv6 support.
Nodes which do not support Stateful Address Autoconfiguration may be Nodes which do not support Stateful Address Autoconfiguration may be
unable to obtain any IPv6 addresses, aside from link-local addresses, unable to obtain any IPv6 addresses, aside from link-local addresses,
when it receives a router advertisement with the 'M' flag (Managed when it receives a router advertisement with the 'M' flag (Managed
address configuration) set and that contains no prefixes advertised address configuration) set and that contains no prefixes advertised
for Stateless Address Autoconfiguration (see Section 4.5.2). for Stateless Address Autoconfiguration (see Section 4.5.2).
Additionally, such nodes will be unable to obtain other configuration Additionally, such nodes will be unable to obtain other configuration
information, such as the addresses of DNS servers when it is information, such as the addresses of DNS servers when it is
connected to a link over which the node receives a router connected to a link over which the node receives a router
advertisement in which the 'O' flag (Other stateful configuration) is advertisement in which the 'O' flag (Other stateful configuration) is
set. set.
5.7. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 5.8. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710
Nodes that need to join multicast groups MUST support MLDv1 Nodes that need to join multicast groups MUST support MLDv1
[RFC3590]. MLDv1 is needed by any node that is expected to receive [RFC3590]. MLDv1 is needed by any node that is expected to receive
and process multicast traffic. Note that Neighbor Discovery (as used and process multicast traffic. Note that Neighbor Discovery (as used
on most link types -- see Section 5.2) depends on multicast and on most link types -- see Section 5.2) depends on multicast and
requires that nodes join Solicited Node multicast addresses. requires that nodes join Solicited Node multicast addresses.
Nodes that need to join multicast groups SHOULD implement MLDv2 Nodes that need to join multicast groups SHOULD implement MLDv2
[RFC3810]. However, if the node has applications that only need [RFC3810]. However, if the node has applications that only need
support for Any-Source Multicast [RFC3569], the node MAY implement support for Any-Source Multicast [RFC3569], the node MAY implement
skipping to change at page 11, line 34 skipping to change at page 12, line 11
Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
are expected to determine their default router information and on- are expected to determine their default router information and on-
link prefix information from received Router Advertisements. link prefix information from received Router Advertisements.
7. IPv4 Support and Transition 7. IPv4 Support and Transition
IPv6 nodes MAY support IPv4. IPv6 nodes MAY support IPv4.
7.1. Transition Mechanisms 7.1. Transition Mechanisms
7.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893 7.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC
4213
If an IPv6 node implements dual stack and tunneling, then [RFC4213] If an IPv6 node implements dual stack and tunneling, then [RFC4213]
MUST be supported. MUST be supported.
8. Mobile IP 8. Mobile IP
The Mobile IPv6 [RFC3775] specification defines requirements for the The Mobile IPv6 [RFC3775] specification defines requirements for the
following types of nodes: following types of nodes:
- mobile nodes - mobile nodes
- correspondent nodes with support for route optimization - correspondent nodes with support for route optimization
- home agents - home agents
- all IPv6 routers - all IPv6 routers
Hosts MAY support mobile node functionality described in Section 8.5 Hosts MAY support mobile node functionality described in Section 8.5
of [RFC3775], including support of generic packet tunneling [RFC2473] of [RFC3775], including support of generic packet tunneling [RFC2473]
and secure home agent communications [RFC3776]. and secure home agent communications [RFC4877].
Hosts SHOULD support route optimization requirements for Hosts SHOULD support route optimization requirements for
correspondent nodes described in Section 8.2 of [RFC3775]. correspondent nodes described in Section 8.2 of [RFC3775].
Routers SHOULD support the generic mobility-related requirements for Routers SHOULD support the generic mobility-related requirements for
all IPv6 routers described in Section 8.3 of [RFC3775]. Routers MAY all IPv6 routers described in Section 8.3 of [RFC3775]. Routers MAY
support the home agent functionality described in Section 8.4 of support the home agent functionality described in Section 8.4 of
[RFC3775], including support of [RFC2473] and [RFC3776]. [RFC3775], including support of [RFC2473] and [RFC4877].
9. Security 9. Security
This section describes the specification of IPsec for the IPv6 node. This section describes the specification of IPsec for the IPv6 node.
9.1. Basic Architecture 9.1. Basic Architecture
Security Architecture for the Internet Protocol [RFC4301] MUST be Security Architecture for the Internet Protocol [RFC4301] MUST be
supported. supported.
skipping to change at page 14, line 39 skipping to change at page 15, line 15
11.1.1. IP Forwarding Table MIB 11.1.1. IP Forwarding Table MIB
IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes that IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes that
support an SNMP agent. support an SNMP agent.
11.1.2. Management Information Base for the Internet Protocol (IP) 11.1.2. Management Information Base for the Internet Protocol (IP)
IP MIB [RFC4293] SHOULD be supported by nodes that support an SNMP IP MIB [RFC4293] SHOULD be supported by nodes that support an SNMP
agent. agent.
12. Security Considerations 12. Open Issues
1. General: should this document be more of an applicability
statement providing context for when a technology may be useful,
but without just saying SHOULD or MUST?
2. Need to address contradiction that this document is
Informational, yet tries to make recommendations that go beyond
what is stated in current RFCs in some cases. (see previous
point)
3. Should we try and tackle the confusion related to the M&O bits in
Router Advertisements? (probably not in this document -- see
previous point.)
4. Need to provide more context for MIPv6 recommendations. Blanket
SHOULD for RO in nodes does not reflect current state of MIPv6
deployment.
5. Security Considerations Section needs updating.
6. For things like link-layer types, may be better to just list all
the IPv6-over-Foo documents as a summary table, making no
recommendations at all.
7. Privacy Extensions recommendation needs more context. It makes
no sense for a server to implement this. It is only applicable
to mobile devices.
8. Security Recommendations may need updating. Are they still
correct? And what is value of mandating IPsec if there is no key
management? Also, what is the sense of mandating IPsec for
limited-functionality devices that have a limited number of
applications, each using their own security? Relax current
requirement or leave as is?
13. Security Considerations
This document does not affect the security of the Internet, but This document does not affect the security of the Internet, but
implementations of IPv6 are expected to support a minimum set of implementations of IPv6 are expected to support a minimum set of
security features to ensure security on the Internet. 'IP Security security features to ensure security on the Internet. 'IP Security
Document Roadmap' [RFC2411] is important for everyone to read. Document Roadmap' [RFC2411] is important for everyone to read.
The security considerations in RFC 2460 state the following: The security considerations in RFC 2460 state the following:
The security features of IPv6 are described in the Security The security features of IPv6 are described in the Security
Architecture for the Internet Protocol [RFC2401]. Architecture for the Internet Protocol [RFC2401].
RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for
the security features of IPv6. the security features of IPv6.
13. Authors and Acknowledgements 14. Authors and Acknowledgments
This document was written by the IPv6 Node Requirements design team: This document was written by the IPv6 Node Requirements design team:
Jari Arkko Jari Arkko
jari.arkko@ericsson.com jari.arkko@ericsson.com
Marc Blanchet Marc Blanchet
marc.blanchet@viagenie.qc.ca marc.blanchet@viagenie.qc.ca
Samita Chakrabarti Samita Chakrabarti
samita.chakrabarti@eng.sun.com samita.chakrabarti@eng.sun.com
Alain Durand Alain Durand
skipping to change at page 15, line 45 skipping to change at page 17, line 5
dthaler@windows.microsoft.com dthaler@windows.microsoft.com
Juha Wiljakka Juha Wiljakka
juha.wiljakka@Nokia.com juha.wiljakka@Nokia.com
The authors would like to thank Ran Atkinson, Jim Bound, Brian The authors would like to thank Ran Atkinson, Jim Bound, Brian
Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas
Narten, Juha Ollila, and Pekka Savola for their comments. Thanks to Narten, Juha Ollila, and Pekka Savola for their comments. Thanks to
Mark Andrews for comments and corrections on DNS text. Thanks to Mark Andrews for comments and corrections on DNS text. Thanks to
Alfred Hoenes for tracking the updates to various RFCs. Alfred Hoenes for tracking the updates to various RFCs.
14. Appendix: Changes from RFC 4294 15. Appendix: Changes from RFC 4294
This appendix keeps track of the chances from RFC 4294 This appendix keeps track of the chances from RFC 4294
1. Section 5.1, removed "and DNAME" from the discussion about RFC- 1. Section 5.1, removed "and DNAME" from the discussion about RFC-
3363. 3363.
2. RFC 2463 references updated to RFC 4443. 2. RFC 2463 references updated to RFC 4443.
3. RFC 3513 references updated to RFC 4291. 3. RFC 3513 references updated to RFC 4291.
4. RFC 3152 refrrences updated to RFC 3596. 4. RFC 3152 references updated to RFC 3596.
5. RFC 2893 references updated to RFC 4213. 5. RFC 2893 references updated to RFC 4213.
6. AH [RFC-4302] support chanced from MUST to MAY. 6. AH [RFC-4302] support chanced from MUST to MAY.
7. The reference for RFC 3152 has been deleted, as the RFC has been 7. The reference for RFC 3152 has been deleted, as the RFC has been
obsoleted, and has been incorporated into RFC 3596. obsoleted, and has been incorporated into RFC 3596.
8. The reference for RFC 3879 has been reomved as the material from 8. The reference for RFC 3879 has been removed as the material from
RFC 3879 has been incorporated into RFC 4291. RFC 3879 has been incorporated into RFC 4291.
15. References 16. References
15.1. Normative References 16.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[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, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 17, line 51 skipping to change at page 19, line 8
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
October 2003. October 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, Algorithm and Its Use with IPsec", RFC 3602,
September 2003. September 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292,
April 2006. April 2006.
[RFC4293] Routhier, S., "Management Information Base for the [RFC4293] Routhier, S., "Management Information Base for the
skipping to change at page 18, line 45 skipping to change at page 19, line 47
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007. Authentication Header (AH)", RFC 4835, April 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5072] S.Varada, Haskin, D., and E. Allen, "IP Version 6 over [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007. PPP", RFC 5072, September 2007.
15.2. Informative References [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007.
16.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
skipping to change at page 20, line 5 skipping to change at page 21, line 11
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
Author's Address Authors' Addresses
John Loughney John Loughney
Nokia Nokia
955 Page Mill Road 955 Page Mill Road
Palo Alto 94303 Palo Alto 94303
USA USA
Phone: +1 650 283 8068 Phone: +1 650 283 8068
Email: john.loughney@nokia.com Email: john.loughney@nokia.com
Full Copyright Statement Thomas Narten
IBM Corporation
Copyright (C) The IETF Trust (2008). 3039 Cornwallis Ave.
PO Box 12195
This document is subject to the rights, licenses and restrictions Research Triangle Park, NC 27709-2195
contained in BCP 78, and except as set forth therein, the authors USA
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Phone: +1 919 254 7798
copyrights, patents or patent applications, or other proprietary Email: narten@us.ibm.com
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 44 change blocks. 
107 lines changed or deleted 157 lines changed or added

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