diff options
Diffstat (limited to 'doc/draft/draft-ietf-ipv6-node-requirements-08.txt')
| -rw-r--r-- | doc/draft/draft-ietf-ipv6-node-requirements-08.txt | 1200 |
1 files changed, 1200 insertions, 0 deletions
diff --git a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt new file mode 100644 index 0000000..2d5c87e --- /dev/null +++ b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt @@ -0,0 +1,1200 @@ + + + + + + +IPv6 Working Group John Loughney (ed) +Internet-Draft Nokia + January 14, 2004 + +Expires: July 14, 2004 + + + + IPv6 Node Requirements + draft-ietf-ipv6-node-requirements-08.txt + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines requirements for IPv6 nodes. It is expected + that IPv6 will be deployed in a wide range of devices and situations. + Specifying the requirements for IPv6 nodes allows IPv6 to function + well and interoperate in a large number of situations and + deployments. + + + + + +Loughney (editor) February 16, 2004 [Page 1] + + + + + +Internet-Draft + + +Table of Contents + + 1. Introduction + 1.1 Requirement Language + 1.2 Scope of this Document + 1.3 Description of IPv6 Nodes + 2. Abbreviations Used in This Document + 3. Sub-IP Layer + 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 + 3.2 IP version 6 over PPP - RFC2472 + 3.3 IPv6 over ATM Networks - RFC2492 + 4. IP Layer + 4.1 Internet Protocol Version 6 - RFC2460 + 4.2 Neighbor Discovery for IPv6 - RFC2461 + 4.3 Path MTU Discovery & Packet Size + 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 + 4.5 Addressing + 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 + 5. Transport and DNS + 5.1 Transport Layer + 5.2 DNS + 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + 6. IPv4 Support and Transition + 6.1 Transition Mechanisms + 7. Mobility + 8. Security + 8.1 Basic Architecture + 8.2 Security Protocols + 8.3 Transforms and Algorithms + 8.4 Key Management Methods + 9. Router Functionality + 9.1 General + 10. Network Management + 10.1 MIBs + 11. Security Considerations + 12. References + 12.1 Normative + 12.2 Non-Normative + 13. Authors and Acknowledgements + 14. Editor's Address + Notices + + + + + + + + + + +Loughney (editor) February 16, 2004 [Page 2] + + + + + +Internet-Draft + + +1. Introduction + + The goal of this document is to define the common functionality + required from both IPv6 hosts and routers. Many IPv6 nodes will + implement optional or additional features, but all IPv6 nodes can be + expected to implement the mandatory requirements listed in this + document. + + This document tries to avoid discussion of protocol details, and + references RFCs for this purpose. In case of any conflicting text, + this document takes less precedence than the normative RFCs, unless + additional clarifying text is included in this document. + + Although the document points to different specifications, it should + be noted that in most cases, the granularity of requirements are + smaller than a single specification, as many specifications define + multiple, independent pieces, some of which may not be mandatory. + + As it is not always possible for an implementer to know the exact + usage of IPv6 in a node, an overriding requirement for IPv6 nodes is + that they should adhere to Jon Postel's Robustness Principle: + + Be conservative in what you do, be liberal in what you accept from + others [RFC-793]. + +1.1 Requirement Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC-2119]. + +1.2 Scope of this Document + + IPv6 covers many specifications. It is intended that IPv6 will be + deployed in many different situations and environments. Therefore, + it is important to develop the requirements for IPv6 nodes, in order + to ensure interoperability. + + This document assumes that all IPv6 nodes meet the minimum + requirements specified here. + +1.3 Description of IPv6 Nodes + + From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we + have the following definitions: + + Description of an IPv6 Node + + + + +Loughney (editor) February 16, 2004 [Page 3] + + + + + +Internet-Draft + + + - a device that implements IPv6 + + Description of an IPv6 router + + - a node that forwards IPv6 packets not explicitly addressed to + itself. + + Description of an IPv6 Host + + - any node that is not a router. + +2. Abbreviations Used in This Document + + ATM Asynchronous Transfer Mode + + AH Authentication Header + + DAD Duplicate Address Detection + + ESP Encapsulating Security Payload + + ICMP Internet Control Message Protocol + + IKE Internet Key Exchange + + MIB Management Information Base + + MLD Multicast Listener Discovery + + MTU Maximum Transfer Unit + + NA Neighbor Advertisement + + NBMA Non-Broadcast Multiple Access + + ND Neighbor Discovery + + NS Neighbor Solicitation + + NUD Neighbor Unreachability Detection + + PPP Point-to-Point Protocol + + PVC Permanent Virtual Circuit + + SVC Switched Virtual Circuit + +3. Sub-IP Layer + + + +Loughney (editor) February 16, 2004 [Page 4] + + + + + +Internet-Draft + + + An IPv6 node must include support for one or more IPv6 link-layer + specifications. Which link-layer specifications are included will + depend upon what link-layers are supported by the hardware available + on the system. It is possible for a conformant IPv6 node to support + IPv6 on some of its interfaces and not on others. + + As IPv6 is run over new layer 2 technologies, it is expected that new + specifications will be issued. This section highlights some major + layer 2 technologies and is not intended to be complete. + +3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 + + Nodes supporting IPv6 over Ethernet interfaces MUST implement + Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. + +3.2 IP version 6 over PPP - RFC2472 + + Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC- + 2472]. + +3.3 IPv6 over ATM Networks - RFC2492 + + Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM + Networks [RFC-2492]. Additionally, RFC 2492 states: + + A minimally conforming IPv6/ATM driver SHALL support the PVC mode + of operation. An IPv6/ATM driver that supports the full SVC mode + SHALL also support PVC mode of operation. + +4. IP Layer + +4.1 Internet Protocol Version 6 - RFC2460 + + The Internet Protocol Version 6 is specified in [RFC-2460]. This + specification MUST be supported. + + Unrecognized options in Hop-by-Hop Options or Destination Options + extensions MUST be processed as described in RFC 2460. + + The node MUST follow the packet transmission rules in RFC 2460. + + Nodes MUST always be able to send, receive and process fragment + headers. All conformant IPv6 implementations MUST be capable of + sending and receving IPv6 packets; forwarding functionality MAY be + supported + + RFC 2460 specifies extension headers and the processing for these + headers. + + + +Loughney (editor) February 16, 2004 [Page 5] + + + + + +Internet-Draft + + + A full implementation of IPv6 includes implementation of the + following extension headers: Hop-by-Hop Options, Routing (Type 0), + Fragment, Destination Options, Authentication and Encapsulating + Security Payload. [RFC-2460] + + An IPv6 node MUST be able to process these headers. It should be + noted that there is some discussion about the use of Routing Headers + and possible security threats [IPv6-RH] caused by them. + +4.2 Neighbor Discovery for IPv6 - RFC2461 + + Neighbor Discovery SHOULD be supported. RFC 2461 states: + + "Unless specified otherwise (in a document that covers operating + IP over a particular link type) this document applies to all link + types. However, because ND uses link-layer multicast for some of + its services, it is possible that on some link types (e.g., NBMA + links) alternative protocols or mechanisms to implement those + services will be specified (in the appropriate document covering + the operation of IP over a particular link type). The services + described in this document that are not directly dependent on + multicast, such as Redirects, Next-hop determination, Neighbor + Unreachability Detection, etc., are expected to be provided as + specified in this document. The details of how one uses ND on + NBMA links is an area for further study." + + Some detailed analysis of Neighbor Discovery follows: + + Router Discovery is how hosts locate routers that reside on an + attached link. Router Discovery MUST be supported for + implementations. + + Prefix Discovery is how hosts discover the set of address prefixes + that define which destinations are on-link for an attached link. + Prefix discovery MUST be supported for implementations. Neighbor + Unreachability Detection (NUD) MUST be supported for all paths + between hosts and neighboring nodes. It is not required for paths + between routers. However, when a node receives a unicast Neighbor + Solicitation (NS) message (that may be a NUD's NS), the node MUST + respond to it (i.e. send a unicast Neighbor Advertisement). + + Duplicate Address Detection MUST be supported on all links supporting + link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take + place on all unicast addresses). + + A host implementation MUST support sending Router Solicitations. + + Receiving and processing Router Advertisements MUST be supported for + + + +Loughney (editor) February 16, 2004 [Page 6] + + + + + +Internet-Draft + + + host implementations. The ability to understand specific Router + Advertisement options is dependent on supporting the specification + where the RA is specified. + + Sending and Receiving Neighbor Solicitation (NS) and Neighbor + Advertisement (NA) MUST be supported. NS and NA messages are required + for Duplicate Address Detection (DAD). + + Redirect functionality SHOULD be supported. If the node is a router, + Redirect functionality MUST be supported. + +4.3 Path MTU Discovery & Packet Size + +4.3.1 Path MTU Discovery - RFC1981 + + Path MTU Discovery [RFC-1981] 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 + reassembly. + +4.3.2 IPv6 Jumbograms - RFC2675 + + IPv6 Jumbograms [RFC-2675] MAY be supported. + +4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 + + ICMPv6 [RFC-2463] MUST be supported. + +4.5 Addressing + +4.5.1 IP Version 6 Addressing Architecture - RFC3513 + + The IPv6 Addressing Architecture [RFC-3513] MUST be supported. + +4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 + + IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. + This specification MUST be supported for nodes that are hosts. + + Nodes that are routers MUST be able to generate link local addresses + as described in RFC 2462 [RFC-2462]. + + From 2462: + + The autoconfiguration process specified in this document applies + only to hosts and not routers. Since host autoconfiguration uses + information advertised by routers, routers will need to be + configured by some other means. However, it is expected that + + + +Loughney (editor) February 16, 2004 [Page 7] + + + + + +Internet-Draft + + + routers will generate link-local addresses using the mechanism + described in this document. In addition, routers are expected to + successfully pass the Duplicate Address Detection procedure + described in this document on all addresses prior to assigning + them to an interface. + + Duplicate Address Detection (DAD) MUST be supported. + +4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 + + Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] + SHOULD be supported. It is recommended that this behavior be + configurable on a connection basis within each application when + available. It is noted that a number of applications do not work + with addresses generated with this method, while other applications + work quite well with them. + +4.5.4 Default Address Selection for IPv6 - RFC3484 + + The rules specified in the Default Address Selection for IPv6 [RFC- + 3484] document MUST be implemented. It is expected that IPv6 nodes + will need to deal with multiple addresses. + +4.5.5 Stateful Address Autoconfiguration + + Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- + 3315] is the standard stateful address configuration protocol; see + section 5.3 for DHCPv6 support. + + Nodes which do not support Stateful Address Autoconfiguration may be + unable to obtain any IPv6 addresses aside from link-local addresses + when it receives a router advertisement with the 'M' flag (Managed + address configuration) set and which contains no prefixes advertised + for Stateless Address Autoconfiguration (see section 4.5.2). + Additionally, such nodes will be unable to obtain other configuration + information such as the addresses of DNS servers when it is connected + to a link over which the node receives a router advertisement in + which the 'O' flag ("Other stateful configuration") is set. + +4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 + + Nodes that need to join multicast groups SHOULD implement MLDv2 + [MLDv2]. However, if the node has applications, which only need + support for Any- Source Multicast [RFC3569], the node MAY implement + MLDv1 [MLDv1] instead. If the node has applications, which need + support for Source- Specific Multicast [RFC3569, SSMARCH], the node + MUST support MLDv2 [MLDv2]. + + + + +Loughney (editor) February 16, 2004 [Page 8] + + + + + +Internet-Draft + + + When MLD is used, the rules in "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be + followed. + +5. Transport Layer and DNS + +5.1 Transport Layer + +5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 + + This specification MUST be supported if jumbograms are implemented + [RFC- 2675]. + +5.2 DNS + + DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] + and [RFC-3596] MAY be supported. Not all nodes will need to resolve + names. All nodes that need to resolve names SHOULD implement stub- + resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with + support for: + + - AAAA type Resource Records [RFC-3596]; + - reverse addressing in ip6.arpa using PTR records [RFC-3152]; + - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 + octets. + + Those nodes are RECOMMENDED to support DNS security extentions + [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT]. + + Those nodes are NOT RECOMMENDED to support the experimental A6 and + DNAME Resource Records [RFC-3363]. + +5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 + + RFC 2732 MUST be supported if applications on the node use URL's. + +5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 + +5.3.1 Managed Address Configuration + + Those IPv6 Nodes that use DHCP for address assignment initiate DHCP + to obtain IPv6 addresses and other configuration information upon + receipt of a Router Advertisement with the 'M' flag set, as described + in section 5.5.3 of RFC 2462. In addition, in the absence of a + router, those IPv6 Nodes that use DHCP for address assignment MUST + initiate DHCP to obtain IPv6 addresses and other configuration + information, as described in section 5.5.2 of RFC 2462. Those IPv6 + nodes that do not use DHCP for address assignment can ignore the 'M' + + + +Loughney (editor) February 16, 2004 [Page 9] + + + + + +Internet-Draft + + + flag in Router Advertisements. + +5.3.2 Other Configuration Information + + Those IPv6 Nodes that use DHCP to obtain other configuration + information initiate DHCP for other configuration information upon + receipt of a Router Advertisement with the 'O' flag set, as described + in section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP + for other configuration information can ignore the 'O' flag in Router + Advertisements. + + An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to + obtain other configuration information. + +6. IPv4 Support and Transition + + IPv6 nodes MAY support IPv4. + +6.1 Transition Mechanisms + +6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 + + If an IPv6 node implements dual stack and tunneling, then RFC2893 + MUST be supported. + + RFC 2893 is currently being updated. + +7. Mobile IP + + The Mobile IPv6 [MIPv6] specification defines requirements for the + following types of nodes: + + - mobile nodes + - correspondent nodes with support for route optimization + - home agents + - all IPv6 routers + + Hosts MAY support mobile node functionality described in Section 8.5 + of [MIPv6], including support of generic packet tunneling [RFC-2473] + and secure home agent communications [MIPv6-HASEC]. + + Hosts SHOULD support route optimization requirements for + correspondent nodes described in Section 8.2 of [MIPv6]. + + Routers SHOULD support the generic mobility-related requirements for + all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY + support the home agent functionality described in Section 8.4 of + [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC]. + + + +Loughney (editor) February 16, 2004 [Page 10] + + + + + +Internet-Draft + + +8. Security + + This section describes the specification of IPsec for the IPv6 node. + +8.1 Basic Architecture + + Security Architecture for the Internet Protocol [RFC-2401] MUST be + supported. RFC-2401 is being updated by the IPsec Working Group. + +8.2 Security Protocols + + ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. + RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group. + + +8.3 Transforms and Algorithms + + Current IPsec RFCs specify the support of certain transforms and + algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. + The requirements for these are discussed first, and then additional + algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed. + + NULL encryption algorithm [RFC-2410] MUST be supported for providing + integrity service and also for debugging use. + + The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD + NOT be supported. Security issues related to the use of DES are + discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as + required by the existing IPsec RFCs, but as it is currently viewed as + an inherently weak algorithm, and no longer fulfills its intended + role. + + The NULL authentication algorithm [RFC-2406] MUST be supported within + ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC- + 2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP, + described in [RFC-2403] MUST be supported. An implementer MUST refer + to Keyed- Hashing for Message Authentication [RFC-2104]. + + 3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC + and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES- + CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected + to be a widely available, secure algorithm that is required for + interoperability. It is not required by the current IPsec RFCs, but + is expected to become required in the future. + + In addition to the above requirements, "Cryptographic Algorithm + Implementation Requirements For ESP And AH" [CRYPTREQ] contains the + current set of mandatory to implement algorithms for ESP and AH as + + + +Loughney (editor) February 16, 2004 [Page 11] + + + + + +Internet-Draft + + + well as specifying algorithms that should be implemented because they + may be promoted to mandatory at some future time. It is RECOMMENDED + that IPv6 nodes conform to the requirements in this document. + +8.4 Key Management Methods + + Manual keying MUST be supported. + + IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast + traffic. Where key refresh, anti-replay features of AH and ESP, or + on- demand creation of Security Associations (SAs) is required, + automated keying MUST be supported. Note that the IPsec WG is working + on the successor to IKE [IKE2]. Key management methods for multicast + traffic are also being worked on by the MSEC WG. + + "Cryptographic Algorithms for use in the Internet Key Exchange + Version 2" [IKEv2ALGO] defines the current set of mandatory to + implement algorithms for use of IKEv2 as well as specifying + algorithms that should be implemented because they made be promoted + to mandatory at some future time. It is RECOMMENDED that IPv6 nodes + implementing IKEv2 conform to the requirements in this + document. + +9. Router-Specific Functionality + + This section defines general host considerations for IPv6 nodes that + act as routers. Currently, this section does not discuss routing- + specific requirements. + +9.1 General + +9.1.1 IPv6 Router Alert Option - RFC2711 + + + The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- + Hop Header that is used in conjunction with some protocols (e.g., + RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will + need to be implemented whenever protocols that mandate its usage are + implemented. See Section 4.6. + +9.1.2 Neighbor Discovery for IPv6 - RFC2461 + + Sending Router Advertisements and processing Router Solicitation MUST + be supported. + +10. Network Management + + Network Management MAY be supported by IPv6 nodes. However, for IPv6 + + + +Loughney (editor) February 16, 2004 [Page 12] + + + + + +Internet-Draft + + + nodes that are embedded devices, network management may be the only + possibility to control these nodes. + +10.1 Management Information Base Modules (MIBs) + + The following two MIBs SHOULD be supported by nodes that support an + SNMP agent. + +10.1.1 IP Forwarding Table MIB + + IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes + that support an SNMP agent. + +10.1.2 Management Information Base for the Internet Protocol (IP) + + IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an + SNMP agent. + +11. Security Considerations + + This draft does not affect the security of the Internet, but + implementations of IPv6 are expected to support a minimum set of + security features to ensure security on the Internet. "IP Security + Document Roadmap" [RFC-2411] is important for everyone to read. + + The security considerations in RFC2460 describe the following: + + The security features of IPv6 are described in the Security + Architecture for the Internet Protocol [RFC-2401]. + +12. References + +12.1 Normative + + [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa- + tion Requirements For ESP And AH", draft-ietf-ipsec- + esp-ah-algorithms-01.txt, January 2004. + + [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the + Internet Key Exchange Version 2", draft-ietf-ipsec- + ikev2-algorithms-04.txt, Work in Progress. + + [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6 + Service", draft- ietf-dhc-dhcpv6-stateless-00.txt, + Work in Progress. + + [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Support + in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in + + + +Loughney (editor) February 16, 2004 [Page 13] + + + + + +Internet-Draft + + + progress. + + [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec + to Protect Mobile IPv6 Signaling between Mobile Nodes + and Home Agents", draft-ietf- mobileip-mipv6-ha- + ipsec-06.txt, Work in Progress. + + [MLDv2] Vida, R. et al., "Multicast Listener Discovery Version + 2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in + Progress. + + [RFC-1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU + Discovery for IP version 6", RFC 1981, August 1996. + + [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table + MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in + Progress. + + [RFC-2011BIS] Routhier, S (ed), "Management Information Base for the + Internet Protocol (IP)", draft-ietf-ipv6-rfc2011- + update-07.txt, Work in progress. + + [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for + the Internet Protocol", RFC 2401, November 1998. + + [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication + Header", RFC 2402, November 1998. + + [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 within + ESP and AH", RFC 2403, November 1998. + + [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 + within ESP and AH", RFC 2404, November 1998. + + [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher + Algorithm With Explicit IV", RFC 2405, November 1998. + + [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security + + + +Loughney (editor) February 16, 2004 [Page 14] + + + + + +Internet-Draft + + + Protocol (ESP)", RFC 2406, November 1998. + + [RFC-2407] Piper, D., "The Internet IP Security Domain of + Interpretation for ISAKMP", RFC 2407, November 1998. + + [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and Turner, + J., "Internet Security Association and Key Management + Protocol (ISAKMP)", RFC 2408, November 1998. + + [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key + Exchange (IKE)", RFC 2409, November 1998. + + [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm + and Its Use With IPsec", RFC 2410, November 1998. + + [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher + Algorithms", RFC 2451, November 1998. + + [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver- + sion 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address + Autoconfiguration", RFC 2462. + + [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet Pro- + tocol Version 6 (IPv6)", RFC 2463, December 1998. + + [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC + 2472, December 1998. + + [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling + in IPv6 Specification", RFC 2473, December 1998. Xxx + add + + [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + + [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert + Option", RFC 2711, October 1999. + + + + +Loughney (editor) February 16, 2004 [Page 15] + + + + + +Internet-Draft + + + [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC + 3041, January 2001. + + [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August + 2001. + + [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC-3363] Bush, R., et al., "Representing Internet Protocol ver- + sion 6 (IPv6) Addresses in the Domain Name System + (DNS)", RFC 3363, August 2002. + + [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC + 3484, February 2003. + + [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing + Architecture", RFC 3513, April 2003. + + [RFC-3590] Haberman, B., "Source Address Selection for the Multi- + cast Listener Discovery (MLD) Protocol", RFC 3590, + September 2003. + + [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP + version 6", RFC 3596, October 2003. + + [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use + with IPsec", RFC 3602, September 2003. + +12.2 Non-Normative + + [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast", + draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in + Progress. + + [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of + DES-like cryptosystems", Journal of Cryptology Vol 4, Jan + 1991. + + [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000. + + [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without + Strong Integrity", Proceedings of the 32nd IETF, Danvers, + MA, April 1995. + + [DHCPv6-SL] Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser- + vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in + + + +Loughney (editor) February 16, 2004 [Page 16] + + + + + +Internet-Draft + + + Progress. + + [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "DNS Security Introduction and Requirements" draft- + ietf-dnsext-dnssec-intro- 06.txt, Work in Progress. + + [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro- + gress. + + [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "Protocol Modifications for the DNS Security Exten- + sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work + in Progress. + + [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto- + col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress. + + [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home + Address Options", draft-savola-ipv6-rh-ha-security- + 03.txt, Work in Progress, March 2002. + + [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu- + rity Threats and Counter-Measures; In Proceedings "Sympo- + sium on Network and Distributed System Security", Febru- + ary 1995, pp.2-16. + + [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793, + August 1980. + + [RFC-1034] Mockapetris, P., "Domain names - concepts and facili- + ties", RFC 1034, November 1987. + + [RFC-2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, + May 1997. + + [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and + S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC + 2205, September 1997. + + [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet + Networks", RFC 2462, December 1998. + + [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over + ATM Networks", RFC 2492, January 1999. + + [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6 + + + +Loughney (editor) February 16, 2004 [Page 17] + + + + + +Internet-Draft + + + Jumbograms", RFC 2675, August 1999. + + [RFC-2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal + IPv6 Addresses in URL's", RFC 2732, December 1999. + + [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder, + "Textual Conventions for Internet Network Addresses", RFC + 2851, June 2000. + + [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms for + IPv6 Hosts and Routers", RFC 2893, August 2000. + + [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, July 2003. + + [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", + draft-ietf- ssm-arch-03.txt, Work in Progress. + +13. Authors and Acknowledgements + + This document was written by the IPv6 Node Requirements design team: + + Jari Arkko + [jari.arkko@ericsson.com] + + Marc Blanchet + [marc.blanchet@viagenie.qc.ca] + + Samita Chakrabarti + [samita.chakrabarti@eng.sun.com] + + Alain Durand + [alain.durand@sun.com] + + Gerard Gastaud + [gerard.gastaud@alcatel.fr] + + Jun-ichiro itojun Hagino + [itojun@iijlab.net] + + Atsushi Inoue + [inoue@isl.rdc.toshiba.co.jp] + + Masahiro Ishiyama + [masahiro@isl.rdc.toshiba.co.jp] + + John Loughney + [john.loughney@nokia.com] + + + +Loughney (editor) February 16, 2004 [Page 18] + + + + + +Internet-Draft + + + Rajiv Raghunarayan + [raraghun@cisco.com] + + Shoichi Sakane + [shouichi.sakane@jp.yokogawa.com] + + Dave Thaler + [dthaler@windows.microsoft.com] + + Juha Wiljakka + [juha.wiljakka@Nokia.com] + + The authors would like to thank Ran Atkinson, Jim Bound, Brian Car- + penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, + Juha Ollila and Pekka Savola for their comments. + +14. Editor's Contact Information + + Comments or questions regarding this document should be sent to the + IPv6 Working Group mailing list (ipv6@ietf.org) or to: + + John Loughney + Nokia Research Center + Itamerenkatu 11-13 + 00180 Helsinki + Finland + + Phone: +358 50 483 6242 + Email: John.Loughney@Nokia.com + +Notices + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to per- + tain 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; neither does it represent that it has made + any effort to identify any such rights. Information on the IETF's + procedures with respect to rights in standards-track and standards- + related documentation can be found in BCP-11. Copies of claims of + rights made available for publication 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 implementors or users of this specification can be obtained from + the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + + + +Loughney (editor) February 16, 2004 [Page 19] + + + + + +Internet-Draft + + + rights, which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Loughney (editor) February 16, 2004 [Page 20] + + |
