idnits 2.17.1 draft-ietf-6man-node-req-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 838. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 851. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 7, 2008) is 5916 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1981 (ref. '5') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2401 (ref. '37') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2411 (ref. '36') (Obsoleted by RFC 6071) ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2671 (ref. '19') (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 3315 (ref. '11') (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3363 (ref. '17') ** Obsolete normative reference: RFC 3484 (ref. '10') (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3775 (ref. '20') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4835 (ref. '26') (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 4941 (ref. '9') (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '38') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '47') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '49') (Obsoleted by RFC 5996) Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Loughney 3 Internet-Draft Nokia 4 Intended status: Standards Track February 7, 2008 5 Expires: August 10, 2008 7 IPv6 Node Requirements RFC 4294-bis 8 draft-ietf-6man-node-req-bis-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 10, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document defines requirements for IPv6 nodes. It is expected 42 that IPv6 will be deployed in a wide range of devices and situations. 43 Specifying the requirements for IPv6 nodes allows IPv6 to function 44 well and interoperate in a large number of situations and 45 deployments. 47 Table of Contents 49 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.1. Scope of This Document . . . . . . . . . . . . . . . . . . 4 52 2.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 4 53 3. Abbreviations Used in This Document . . . . . . . . . . . . . 5 54 4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. Transmission of IPv6 Packets over Ethernet Networks - 56 RFC 2464 . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.2. IP version 6 over PPP - RFC 5072 . . . . . . . . . . . . . 6 58 4.3. IPv6 over ATM Networks - RFC 2492 . . . . . . . . . . . . 6 59 5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . . 6 61 5.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 7 62 5.3. Path MTU Discovery and Packet Size . . . . . . . . . . . . 8 63 5.3.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 8 64 5.4. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 8 65 5.5. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 66 4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.6.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 8 69 5.6.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 8 70 5.6.3. Privacy Extensions for Address Configuration in 71 IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 9 72 5.6.4. Default Address Selection for IPv6 - RFC 3484 . . . . 9 73 5.6.5. Stateful Address Autoconfiguration . . . . . . . . . . 9 74 5.7. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 . . 9 75 6. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 6.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 78 - RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.2.1. 5.2.1. Managed Address Configuration . . . . . . . . 10 80 6.2.2. Other Configuration Information . . . . . . . . . . . 10 81 6.2.3. Use of Router Advertisements in Managed 82 Environments . . . . . . . . . . . . . . . . . . . . . 11 83 7. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 11 84 7.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 11 85 7.1.1. Transition Mechanisms for IPv6 Hosts and Routers - 86 RFC 2893 . . . . . . . . . . . . . . . . . . . . . . . 11 87 8. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 9.1. Basic Architecture . . . . . . . . . . . . . . . . . . . . 12 90 9.2. Security Protocols . . . . . . . . . . . . . . . . . . . . 12 91 9.3. Transforms and Algorithms . . . . . . . . . . . . . . . . 12 92 9.4. Key Management Methods . . . . . . . . . . . . . . . . . . 13 93 10. Router-Specific Functionality . . . . . . . . . . . . . . . . 13 94 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 10.1.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . 13 96 10.1.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . 13 97 11. Network Management . . . . . . . . . . . . . . . . . . . . . . 13 98 11.1. Management Information Base Modules (MIBs) . . . . . . . . 14 99 11.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . . 14 100 11.1.2. Management Information Base for the Internet 101 Protocol (IP) . . . . . . . . . . . . . . . . . . . . 14 102 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 103 13. Authors and Acknowledgements . . . . . . . . . . . . . . . . . 14 104 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 105 14.1. Normative References . . . . . . . . . . . . . . . . . . . 15 106 14.2. Informative References . . . . . . . . . . . . . . . . . . 18 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 108 Intellectual Property and Copyright Statements . . . . . . . . . . 20 110 1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [1]. 116 2. Introduction 118 The goal of this document is to define the common functionality 119 required from both IPv6 hosts and routers. Many IPv6 nodes will 120 implement optional or additional features, but this document 121 summarizes requirements from other published Standards Track 122 documents in one place. 124 This document tries to avoid discussion of protocol details, and 125 references RFCs for this purpose. This document is informational in 126 nature and does not update Standards Track RFCs. 128 Although the document points to different specifications, it should 129 be noted that in most cases, the granularity of requirements are 130 smaller than a single specification, as many specifications define 131 multiple, independent pieces, some of which may not be mandatory. 133 As it is not always possible for an implementer to know the exact 134 usage of IPv6 in a node, an overriding requirement for IPv6 nodes is 135 that they should adhere to Jon Postel's Robustness Principle: 137 Be conservative in what you do, be liberal in what you accept from 138 others [38]. 140 2.1. Scope of This Document 142 IPv6 covers many specifications. It is intended that IPv6 will be 143 deployed in many different situations and environments. Therefore, 144 it is important to develop the requirements for IPv6 nodes to ensure 145 interoperability. 147 This document assumes that all IPv6 nodes meet the minimum 148 requirements specified here. 150 2.2. Description of IPv6 Nodes 152 From the Internet Protocol, Version 6 (IPv6) Specification [2], we 153 have the following definitions: 155 Description of an IPv6 Node 156 - a device that implements IPv6. 158 Description of an IPv6 router 160 - a node that forwards IPv6 packets not explicitly addressed to 161 itself. 163 Description of an IPv6 Host 165 - any node that is not a router. 167 3. Abbreviations Used in This Document 169 ATM Asynchronous Transfer Mode 170 AH Authentication Header 171 DAD Duplicate Address Detection 172 ESP Encapsulating Security Payload 173 ICMP Internet Control Message Protocol 174 IKE Internet Key Exchange 175 MIB Management Information Base 176 MLD Multicast Listener Discovery 177 MTU Maximum Transfer Unit 178 NA Neighbor Advertisement 179 NBMA Non-Broadcast Multiple Access 180 ND Neighbor Discovery 181 NS Neighbor Solicitation 182 NUD Neighbor Unreachability Detection 183 PPP Point-to-Point Protocol 184 PVC Permanent Virtual Circuit 185 SVC Switched Virtual Circuit 187 4. Sub-IP Layer 189 An IPv6 node must include support for one or more IPv6 link-layer 190 specifications. Which link-layer specifications are included will 191 depend upon what link-layers are supported by the hardware available 192 on the system. It is possible for a conformant IPv6 node to support 193 IPv6 on some of its interfaces and not on others. 195 As IPv6 is run over new layer 2 technologies, it is expected that new 196 specifications will be issued. This section highlights some major 197 layer 2 technologies and is not intended to be complete. 199 4.1. Transmission of IPv6 Packets over Ethernet Networks - RFC 2464 201 Nodes supporting IPv6 over Ethernet interfaces MUST implement 202 Transmission of IPv6 Packets over Ethernet Networks [39]. 204 4.2. IP version 6 over PPP - RFC 5072 206 Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [3]. 208 4.3. IPv6 over ATM Networks - RFC 2492 210 Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM 211 Networks [40]. Additionally, RFC 2492 states: 213 A minimally conforming IPv6/ATM driver SHALL support the PVC mode 214 of operation. An IPv6/ATM driver that supports the full SVC mode 215 SHALL also support PVC mode of operation. 217 5. IP Layer 219 5.1. Internet Protocol Version 6 - RFC 2460 221 The Internet Protocol Version 6 is specified in [2]. This 222 specification MUST be supported. 224 Unrecognized options in Hop-by-Hop Options or Destination Options 225 extensions MUST be processed as described in RFC 2460. 227 The node MUST follow the packet transmission rules in RFC 2460. 229 Nodes MUST always be able to send, receive, and process fragment 230 headers. All conformant IPv6 implementations MUST be capable of 231 sending and receiving IPv6 packets; the forwarding functionality MAY 232 be supported. 234 RFC 2460 specifies extension headers and the processing for these 235 headers. 237 A full implementation of IPv6 includes implementation of the 238 following extension headers: Hop-by-Hop Options, Routing (Type 0), 239 Fragment, Destination Options, Authentication and Encapsulating 240 Security Payload [2]. 242 An IPv6 node MUST be able to process these headers. It should be 243 noted that there is some discussion about the use of Routing Headers 244 and possible security threats 'IPv6-RH' that they cause. 246 5.2. Neighbor Discovery for IPv6 - RFC 4861 248 Neighbor Discovery SHOULD be supported. [4] states: 250 Unless specified otherwise (in a document that covers operating IP 251 over a particular link type) this document applies to all link 252 types. However, because ND uses link-layer multicast for some of 253 its services, it is possible that on some link types (e.g., NBMA 254 links) alternative protocols or mechanisms to implement those 255 services will be specified (in the appropriate document covering 256 the operation of IP over a particular link type). The services 257 described in this document that are not directly dependent on 258 multicast, such as Redirects, Next-hop determination, Neighbor 259 Unreachability Detection, etc., are expected to be provided as 260 specified in this document. The details of how one uses ND on 261 NBMA links is an area for further study. 263 Some detailed analysis of Neighbor Discovery follows: 265 Router Discovery is how hosts locate routers that reside on an 266 attached link. Router Discovery MUST be supported for 267 implementations. 269 Prefix Discovery is how hosts discover the set of address prefixes 270 that define which destinations are on-link for an attached link. 271 Prefix discovery MUST be supported for implementations. Neighbor 272 Unreachability Detection (NUD) MUST be supported for all paths 273 between hosts and neighboring nodes. It is not required for paths 274 between routers. However, when a node receives a unicast Neighbor 275 Solicitation (NS) message (that may be a NUD's NS), the node MUST 276 respond to it (i.e., send a unicast Neighbor Advertisement). 278 Duplicate Address Detection MUST be supported on all links supporting 279 link-layer multicast (RFC 4862, Section 5.4, specifies DAD MUST take 280 place on all unicast addresses). 282 A host implementation MUST support sending Router Solicitations. 284 Receiving and processing Router Advertisements MUST be supported for 285 host implementations. The ability to understand specific Router 286 Advertisement options is dependent on supporting the specification 287 where the RA is specified. 289 Sending and Receiving Neighbor Solicitation (NS) and Neighbor 290 Advertisement (NA) MUST be supported. NS and NA messages are 291 required for Duplicate Address Detection (DAD). 293 Redirect functionality SHOULD be supported. If the node is a router, 294 Redirect functionality MUST be supported. 296 5.3. Path MTU Discovery and Packet Size 298 5.3.1. Path MTU Discovery - RFC 1981 300 Path MTU Discovery [5] SHOULD be supported, though minimal 301 implementations MAY choose to not support it and avoid large packets. 302 The rules in RFC 2460 MUST be followed for packet fragmentation and 303 reassembly. 305 5.4. IPv6 Jumbograms - RFC 2675 307 IPv6 Jumbograms [41] MAY be supported. 309 5.5. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 311 ICMPv6 [6] MUST be supported. 313 5.6. Addressing 315 5.6.1. IP Version 6 Addressing Architecture - RFC 4291 317 The IPv6 Addressing Architecture [7] MUST be supported. 319 5.6.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 321 IPv6 Stateless Address Autoconfiguration is defined in [8]. This 322 specification MUST be supported for nodes that are hosts. Static 323 address can be supported as well. 325 Nodes that are routers MUST be able to generate link local addresses 326 as described in RFC 4862 [8]. 328 From 4862: 330 The autoconfiguration process specified in this document applies 331 only to hosts and not routers. Since host autoconfiguration uses 332 information advertised by routers, routers will need to be 333 configured by some other means. However, it is expected that 334 routers will generate link-local addresses using the mechanism 335 described in this document. In addition, routers are expected to 336 successfully pass the Duplicate Address Detection procedure 337 described in this document on all addresses prior to assigning 338 them to an interface. 340 Duplicate Address Detection (DAD) MUST be supported. 342 5.6.3. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 344 Privacy Extensions for Stateless Address Autoconfiguration [9] SHOULD 345 be supported. It is recommended that this behavior be configurable 346 on a connection basis within each application when available. It is 347 noted that a number of applications do not work with addresses 348 generated with this method, while other applications work quite well 349 with them. 351 5.6.4. Default Address Selection for IPv6 - RFC 3484 353 The rules specified in the Default Address Selection for IPv6 [10] 354 document MUST be implemented. It is expected that IPv6 nodes will 355 need to deal with multiple addresses. 357 5.6.5. Stateful Address Autoconfiguration 359 Stateful Address Autoconfiguration MAY be supported. DHCPv6 [11] is 360 the standard stateful address configuration protocol; see Section 5.3 361 for DHCPv6 support. 363 Nodes which do not support Stateful Address Autoconfiguration may be 364 unable to obtain any IPv6 addresses, aside from link-local addresses, 365 when it receives a router advertisement with the 'M' flag (Managed 366 address configuration) set and that contains no prefixes advertised 367 for Stateless Address Autoconfiguration (see Section 4.5.2). 368 Additionally, such nodes will be unable to obtain other configuration 369 information, such as the addresses of DNS servers when it is 370 connected to a link over which the node receives a router 371 advertisement in which the 'O' flag (Other stateful configuration) is 372 set. 374 5.7. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 376 Nodes that need to join multicast groups SHOULD implement MLDv2 [12]. 377 However, if the node has applications that only need support for Any- 378 Source Multicast [42], the node MAY implement MLDv1 [13] instead. If 379 the node has applications that need support for Source-Specific 380 Multicast [42], [14], the node MUST support MLDv2 [12]. 382 When MLD is used, the rules in the Source Address Selection for the 383 Multicast Listener Discovery (MLD) Protocol [15] MUST be followed. 385 6. DNS and DHCP 386 6.1. DNS 388 DNS is described in [43], [16], [17], and [18]. Not all nodes will 389 need to resolve names; those that will never need to resolve DNS 390 names do not need to implement resolver functionality. However, the 391 ability to resolve names is a basic infrastructure capability that 392 applications rely on and generally needs to be supported. All nodes 393 that need to resolve names SHOULD implement stub-resolver [43] 394 functionality, as in RFC 1034, Section 5.3.1, with support for: 396 - AAAA type Resource Records [18]; 397 - reverse addressing in ip6.arpa using PTR records [18]; 398 - EDNS0 [19] to allow for DNS packet sizes larger than 512 octets. 400 Those nodes are RECOMMENDED to support DNS security extensions [44], 401 [45], and [46]. 403 Those nodes are NOT RECOMMENDED to support the experimental A6 404 Resource Records [17]. 406 6.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315 408 6.2.1. 5.2.1. Managed Address Configuration 410 The method by which IPv6 nodes that use DHCP for address assignment 411 can obtain IPv6 addresses and other configuration information upon 412 receipt of a Router Advertisement with the \'M' flag set is described 413 in Section 5.5.3 of RFC 4862. 415 In addition, in the absence of a router, those IPv6 nodes that use 416 DHCP for address assignment MUST initiate DHCP to obtain IPv6 417 addresses and other configuration information, as described in 418 Section 5.5.2 of RFC 4862. Those IPv6 nodes that do not use DHCP for 419 address assignment can ignore the 'M' flag in Router Advertisements. 421 6.2.2. Other Configuration Information 423 The method by which IPv6 nodes that use DHCP to obtain other 424 configuration information can obtain other configuration information 425 upon receipt of a Router Advertisement with the \'O' flag set is 426 described in Section 5.5.3 of RFC 4862. 428 Those IPv6 nodes that use DHCP to obtain other configuration 429 information initiate DHCP for other configuration information upon 430 receipt of a Router Advertisement with the 'O' flag set, as described 431 in Section 5.5.3 of RFC 4862. Those IPv6 nodes that do not use DHCP 432 for other configuration information can ignore the 'O' flag in Router 433 Advertisements. 435 An IPv6 node can use the subset of DHCP (described in [47]) to obtain 436 other configuration information. 438 6.2.3. Use of Router Advertisements in Managed Environments 440 Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 441 are expected to determine their default router information and on- 442 link prefix information from received Router Advertisements. 444 7. IPv4 Support and Transition 446 IPv6 nodes MAY support IPv4. 448 7.1. Transition Mechanisms 450 7.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893 452 If an IPv6 node implements dual stack and tunneling, then [48] MUST 453 be supported. 455 8. Mobile IP 457 The Mobile IPv6 [20] specification defines requirements for the 458 following types of nodes: 460 - mobile nodes 461 - correspondent nodes with support for route optimization 462 - home agents 463 - all IPv6 routers 465 Hosts MAY support mobile node functionality described in Section 8.5 466 of [20], including support of generic packet tunneling [21] and 467 secure home agent communications [22]. 469 Hosts SHOULD support route optimization requirements for 470 correspondent nodes described in Section 8.2 of [20]. 472 Routers SHOULD support the generic mobility-related requirements for 473 all IPv6 routers described in Section 8.3 of [20]. Routers MAY 474 support the home agent functionality described in Section 8.4 of 475 [20], including support of [21] and [22]. 477 9. Security 479 This section describes the specification of IPsec for the IPv6 node. 481 9.1. Basic Architecture 483 Security Architecture for the Internet Protocol [23] MUST be 484 supported. 486 9.2. Security Protocols 488 ESP [24] MUST be supported. AH [25] MAY be supported. 490 9.3. Transforms and Algorithms 492 Current IPsec RFCs specify the support of transforms and algorithms 493 for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and 494 HMAC-MD5-96. However, 'Cryptographic Algorithm Implementation 495 Requirements For ESP and AH' [26] contains the current set of 496 mandatory to implement algorithms for ESP and AH. It also specifies 497 algorithms that should be implemented because they are likely to be 498 promoted to mandatory at some future time. IPv6 nodes SHOULD conform 499 to the requirements in [26], as well as the requirements specified 500 below. 502 Since ESP encryption and authentication are both optional, support 503 for the NULL encryption algorithm [27] and the NULL authentication 504 algorithm [24] MUST be provided to maintain consistency with the way 505 these services are negotiated. However, while authentication and 506 encryption can each be NULL, they MUST NOT both be NULL. The NULL 507 encryption algorithm is also useful for debugging. 509 The DES-CBC encryption algorithm [28] SHOULD NOT be supported within 510 ESP. Security issues related to the use of DES are discussed in 511 'DESDIFF', 'DESINT', and 'DESCRACK'. DES-CBC is still listed as 512 required by the existing IPsec RFCs, but updates to these RFCs will 513 be published in the near future. DES provides 56 bits of protection, 514 which is no longer considered sufficient. 516 The use of the HMAC-SHA-1-96 algorithm [29] within AH and ESP MUST be 517 supported. The use of the HMAC-MD5-96 algorithm [30] within AH and 518 ESP MAY also be supported. 520 The 3DES-CBC encryption algorithm [31] does not suffer from the same 521 security issues as DES-CBC, and the 3DES-CBC algorithm within ESP 522 MUST be supported to ensure interoperability. 524 The AES-128-CBC algorithm [32] MUST also be supported within ESP. 525 AES-128 is expected to be a widely available, secure, and efficient 526 algorithm. While AES-128-CBC is not required by the current IPsec 527 RFCs, it is expected to become required in the future. 529 9.4. Key Management Methods 531 An implementation MUST support the manual configuration of the 532 security key and SPI. The SPI configuration is needed in order to 533 delineate between multiple keys. 535 Key management SHOULD be supported. Examples of key management 536 systems include IKEv2 [49] and Kerberos; S/MIME and TLS include key 537 management functions. 539 Where key refresh, anti-replay features of AH and ESP, or on-demand 540 creation of Security Associations (SAs) is required, automated keying 541 MUST be supported. 543 Key management methods for multicast traffic are also being worked on 544 by the MSEC WG. 546 10. Router-Specific Functionality 548 This section defines general host considerations for IPv6 nodes that 549 act as routers. Currently, this section does not discuss routing- 550 specific requirements. 552 10.1. General 554 10.1.1. IPv6 Router Alert Option - RFC 2711 556 The IPv6 Router Alert Option [33] is an optional IPv6 Hop-by-Hop 557 Header that is used in conjunction with some protocols (e.g., RSVP 558 [50] or MLD [13]). The Router Alert option will need to be 559 implemented whenever protocols that mandate its usage are 560 implemented. See Section 4.6. 562 10.1.2. Neighbor Discovery for IPv6 - RFC 4861 564 Sending Router Advertisements and processing Router Solicitation MUST 565 be supported. 567 11. Network Management 569 Network Management MAY be supported by IPv6 nodes. However, for IPv6 570 nodes that are embedded devices, network management may be the only 571 possible way of controlling these nodes. 573 11.1. Management Information Base Modules (MIBs) 575 The following two MIBs SHOULD be supported by nodes that support an 576 SNMP agent. 578 11.1.1. IP Forwarding Table MIB 580 IP Forwarding Table MIB [34] SHOULD be supported by nodes that 581 support an SNMP agent. 583 11.1.2. Management Information Base for the Internet Protocol (IP) 585 IP MIB [35] SHOULD be supported by nodes that support an SNMP agent. 587 12. Security Considerations 589 This document does not affect the security of the Internet, but 590 implementations of IPv6 are expected to support a minimum set of 591 security features to ensure security on the Internet. 'IP Security 592 Document Roadmap' [36] is important for everyone to read. 594 The security considerations in RFC 2460 state the following: 596 The security features of IPv6 are described in the Security 597 Architecture for the Internet Protocol [37]. 599 RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for 600 the security features of IPv6. 602 13. Authors and Acknowledgements 604 This document was written by the IPv6 Node Requirements design team: 606 Jari Arkko 607 jari.arkko@ericsson.com 608 Marc Blanchet 609 marc.blanchet@viagenie.qc.ca 610 Samita Chakrabarti 611 samita.chakrabarti@eng.sun.com 612 Alain Durand 613 alain.durand@sun.com 614 Gerard Gastaud 615 gerard.gastaud@alcatel.fr 616 Jun-ichiro itojun Hagino 617 itojun@iijlab.net 618 Atsushi Inoue 619 inoue@isl.rdc.toshiba.co.jp 620 Masahiro Ishiyama 621 masahiro@isl.rdc.toshiba.co.jp 622 John Loughney 623 john.loughney@nokia.com 624 Rajiv Raghunarayan 625 raraghun@cisco.com 626 Shoichi Sakane 627 shouichi.sakane@jp.yokogawa.com 628 Dave Thaler 629 dthaler@windows.microsoft.com 630 Juha Wiljakka 631 juha.wiljakka@Nokia.com 633 The authors would like to thank Ran Atkinson, Jim Bound, Brian 634 Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas 635 Narten, Juha Ollila, and Pekka Savola for their comments. 637 14. References 639 14.1. Normative References 641 [16] Mockapetris, P., "Domain names - implementation and 642 specification", STD 13, RFC 1035, November 1987. 644 [5] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 645 IP version 6", RFC 1981, August 1996. 647 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 648 Levels", BCP 14, RFC 2119, March 1997. 650 [37] Kent, S. and R. Atkinson, "Security Architecture for the 651 Internet Protocol", RFC 2401, November 1998. 653 [30] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and 654 AH", RFC 2403, November 1998. 656 [29] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 657 and AH", RFC 2404, November 1998. 659 [28] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm 660 With Explicit IV", RFC 2405, November 1998. 662 [27] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its 663 Use With IPsec", RFC 2410, November 1998. 665 [36] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document 666 Roadmap", RFC 2411, November 1998. 668 [31] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", 669 RFC 2451, November 1998. 671 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 672 Specification", RFC 2460, December 1998. 674 [21] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 675 Specification", RFC 2473, December 1998. 677 [19] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 678 August 1999. 680 [13] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 681 Discovery (MLD) for IPv6", RFC 2710, October 1999. 683 [33] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 684 RFC 2711, October 1999. 686 [11] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 687 Carney, "Dynamic Host Configuration Protocol for IPv6 688 (DHCPv6)", RFC 3315, July 2003. 690 [17] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, 691 "Representing Internet Protocol version 6 (IPv6) Addresses in 692 the Domain Name System (DNS)", RFC 3363, August 2002. 694 [10] Draves, R., "Default Address Selection for Internet Protocol 695 version 6 (IPv6)", RFC 3484, February 2003. 697 [15] Haberman, B., "Source Address Selection for the Multicast 698 Listener Discovery (MLD) Protocol", RFC 3590, September 2003. 700 [18] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS 701 Extensions to Support IP Version 6", RFC 3596, October 2003. 703 [32] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 704 Algorithm and Its Use with IPsec", RFC 3602, September 2003. 706 [20] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 707 IPv6", RFC 3775, June 2004. 709 [22] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 710 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 711 Agents", RFC 3776, June 2004. 713 [12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 714 (MLDv2) for IPv6", RFC 3810, June 2004. 716 [7] Hinden, R. and S. Deering, "IP Version 6 Addressing 717 Architecture", RFC 4291, February 2006. 719 [34] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006. 721 [35] Routhier, S., "Management Information Base for the Internet 722 Protocol (IP)", RFC 4293, April 2006. 724 [23] Kent, S. and K. Seo, "Security Architecture for the Internet 725 Protocol", RFC 4301, December 2005. 727 [25] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 729 [24] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 730 December 2005. 732 [6] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 733 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 734 Specification", RFC 4443, March 2006. 736 [14] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 737 RFC 4607, August 2006. 739 [26] Manral, V., "Cryptographic Algorithm Implementation 740 Requirements for Encapsulating Security Payload (ESP) and 741 Authentication Header (AH)", RFC 4835, April 2007. 743 [4] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 744 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 745 September 2007. 747 [8] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address 748 Autoconfiguration", RFC 4862, September 2007. 750 [9] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions 751 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 752 September 2007. 754 [3] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", 755 RFC 5072, September 2007. 757 14.2. Informative References 759 [38] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 760 September 1981. 762 [43] Mockapetris, P., "Domain names - concepts and facilities", 763 STD 13, RFC 1034, November 1987. 765 [50] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 766 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 767 Specification", RFC 2205, September 1997. 769 [39] Crawford, M., "Transmission of IPv6 Packets over Ethernet 770 Networks", RFC 2464, December 1998. 772 [40] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 773 Networks", RFC 2492, January 1999. 775 [41] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 776 RFC 2675, August 1999. 778 [42] Bhattacharyya, S., "An Overview of Source-Specific Multicast 779 (SSM)", RFC 3569, July 2003. 781 [47] Droms, R., "Stateless Dynamic Host Configuration Protocol 782 (DHCP) Service for IPv6", RFC 3736, April 2004. 784 [44] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 785 "DNS Security Introduction and Requirements", RFC 4033, 786 March 2005. 788 [45] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 789 "Resource Records for the DNS Security Extensions", RFC 4034, 790 March 2005. 792 [46] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 793 "Protocol Modifications for the DNS Security Extensions", 794 RFC 4035, March 2005. 796 [48] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for 797 IPv6 Hosts and Routers", RFC 4213, October 2005. 799 [49] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 800 RFC 4306, December 2005. 802 Author's Address 804 John Loughney 805 Nokia 806 955 Page Mill Road 807 Palo Alto 94303 808 USA 810 Phone: +1 650 283 8068 811 Email: john.loughney@nokia.com 813 Full Copyright Statement 815 Copyright (C) The IETF Trust (2008). 817 This document is subject to the rights, licenses and restrictions 818 contained in BCP 78, and except as set forth therein, the authors 819 retain all their rights. 821 This document and the information contained herein are provided on an 822 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 823 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 824 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 825 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 826 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 827 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 829 Intellectual Property 831 The IETF takes no position regarding the validity or scope of any 832 Intellectual Property Rights or other rights that might be claimed to 833 pertain to the implementation or use of the technology described in 834 this document or the extent to which any license under such rights 835 might or might not be available; nor does it represent that it has 836 made any independent effort to identify any such rights. Information 837 on the procedures with respect to rights in RFC documents can be 838 found in BCP 78 and BCP 79. 840 Copies of IPR disclosures made to the IETF Secretariat and any 841 assurances of licenses to be made available, or the result of an 842 attempt made to obtain a general license or permission for the use of 843 such proprietary rights by implementers or users of this 844 specification can be obtained from the IETF on-line IPR repository at 845 http://www.ietf.org/ipr. 847 The IETF invites any interested party to bring to its attention any 848 copyrights, patents or patent applications, or other proprietary 849 rights that may cover technology that may be required to implement 850 this standard. Please address the information to the IETF at 851 ietf-ipr@ietf.org. 853 Acknowledgment 855 Funding for the RFC Editor function is provided by the IETF 856 Administrative Support Activity (IASA).