idnits 2.17.1 draft-ietf-6man-node-req-bis-02.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 872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 896. 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 (November 3, 2008) is 5624 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC-4302' is mentioned on line 667, but not defined ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2411 (Obsoleted by RFC 6071) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 12 errors (**), 0 flaws (~~), 3 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: Informational November 3, 2008 5 Expires: May 7, 2009 7 IPv6 Node Requirements RFC 4294-bis 8 draft-ietf-6man-node-req-bis-02.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 May 7, 2009. 35 Abstract 37 This document defines requirements for IPv6 nodes. It is expected 38 that IPv6 will be deployed in a wide range of devices and situations. 39 Specifying the requirements for IPv6 nodes allows IPv6 to function 40 well and interoperate in a large number of situations and 41 deployments. 43 Table of Contents 45 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 46 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 2.1. Scope of This Document . . . . . . . . . . . . . . . . . . 4 48 2.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 4 49 3. Abbreviations Used in This Document . . . . . . . . . . . . . 5 50 4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 4.1. Transmission of IPv6 Packets over Ethernet Networks - 52 RFC 2464 . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4.2. IP version 6 over PPP - RFC 5072 . . . . . . . . . . . . . 6 54 4.3. IPv6 over ATM Networks - RFC 2492 . . . . . . . . . . . . 6 55 5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . . 6 57 5.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 7 58 5.3. Path MTU Discovery and Packet Size . . . . . . . . . . . . 8 59 5.3.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 8 60 5.4. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 8 61 5.5. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 62 4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5.6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.6.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 8 65 5.6.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 8 66 5.6.3. Privacy Extensions for Address Configuration in 67 IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 9 68 5.6.4. Default Address Selection for IPv6 - RFC 3484 . . . . 9 69 5.6.5. Stateful Address Autoconfiguration . . . . . . . . . . 9 70 5.7. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 . . 9 71 6. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 6.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 74 - RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.2.1. 5.2.1. Managed Address Configuration . . . . . . . . 10 76 6.2.2. Other Configuration Information . . . . . . . . . . . 11 77 6.2.3. Use of Router Advertisements in Managed 78 Environments . . . . . . . . . . . . . . . . . . . . . 11 79 7. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 11 80 7.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 11 81 7.1.1. Transition Mechanisms for IPv6 Hosts and Routers - 82 RFC 2893 . . . . . . . . . . . . . . . . . . . . . . . 11 83 8. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 9.1. Basic Architecture . . . . . . . . . . . . . . . . . . . . 12 86 9.2. Security Protocols . . . . . . . . . . . . . . . . . . . . 12 87 9.3. Transforms and Algorithms . . . . . . . . . . . . . . . . 12 88 9.4. Key Management Methods . . . . . . . . . . . . . . . . . . 13 89 10. Router-Specific Functionality . . . . . . . . . . . . . . . . 13 90 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 10.1.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . 14 92 10.1.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . 14 93 11. Network Management . . . . . . . . . . . . . . . . . . . . . . 14 94 11.1. Management Information Base Modules (MIBs) . . . . . . . . 14 95 11.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . . 14 96 11.1.2. Management Information Base for the Internet 97 Protocol (IP) . . . . . . . . . . . . . . . . . . . . 14 98 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 99 13. Authors and Acknowledgements . . . . . . . . . . . . . . . . . 15 100 14. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 15 101 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 15.1. Normative References . . . . . . . . . . . . . . . . . . . 16 103 15.2. Informative References . . . . . . . . . . . . . . . . . . 19 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 105 Intellectual Property and Copyright Statements . . . . . . . . . . 21 107 1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Introduction 115 The goal of this document is to define the common functionality 116 required from both IPv6 hosts and routers. Many IPv6 nodes will 117 implement optional or additional features, but this document 118 summarizes requirements from other published Standards Track 119 documents in one place. 121 This document tries to avoid discussion of protocol details, and 122 references RFCs for this purpose. This document is informational in 123 nature and does not update Standards Track RFCs. 125 Although the document points to different specifications, it should 126 be noted that in most cases, the granularity of requirements are 127 smaller than a single specification, as many specifications define 128 multiple, independent pieces, some of which may not be mandatory. 130 As it is not always possible for an implementer to know the exact 131 usage of IPv6 in a node, an overriding requirement for IPv6 nodes is 132 that they should adhere to Jon Postel's Robustness Principle: 134 Be conservative in what you do, be liberal in what you accept from 135 others [RFC0793]. 137 2.1. Scope of This Document 139 IPv6 covers many specifications. It is intended that IPv6 will be 140 deployed in many different situations and environments. Therefore, 141 it is important to develop the requirements for IPv6 nodes to ensure 142 interoperability. 144 This document assumes that all IPv6 nodes meet the minimum 145 requirements specified here. 147 2.2. Description of IPv6 Nodes 149 From the Internet Protocol, Version 6 (IPv6) Specification [RFC2460], 150 we have the following definitions: 152 Description of an IPv6 Node 153 - a device that implements IPv6. 155 Description of an IPv6 router 157 - a node that forwards IPv6 packets not explicitly addressed to 158 itself. 160 Description of an IPv6 Host 162 - any node that is not a router. 164 3. Abbreviations Used in This Document 166 ATM Asynchronous Transfer Mode 167 AH Authentication Header 168 DAD Duplicate Address Detection 169 ESP Encapsulating Security Payload 170 ICMP Internet Control Message Protocol 171 IKE Internet Key Exchange 172 MIB Management Information Base 173 MLD Multicast Listener Discovery 174 MTU Maximum Transfer Unit 175 NA Neighbor Advertisement 176 NBMA Non-Broadcast Multiple Access 177 ND Neighbor Discovery 178 NS Neighbor Solicitation 179 NUD Neighbor Unreachability Detection 180 PPP Point-to-Point Protocol 181 PVC Permanent Virtual Circuit 182 SVC Switched Virtual Circuit 184 4. Sub-IP Layer 186 An IPv6 node must include support for one or more IPv6 link-layer 187 specifications. Which link-layer specifications are included will 188 depend upon what link-layers are supported by the hardware available 189 on the system. It is possible for a conformant IPv6 node to support 190 IPv6 on some of its interfaces and not on others. 192 As IPv6 is run over new layer 2 technologies, it is expected that new 193 specifications will be issued. This section highlights some major 194 layer 2 technologies and is not intended to be complete. 196 4.1. Transmission of IPv6 Packets over Ethernet Networks - RFC 2464 198 Nodes supporting IPv6 over Ethernet interfaces MUST implement 199 Transmission of IPv6 Packets over Ethernet Networks [RFC2464]. 201 4.2. IP version 6 over PPP - RFC 5072 203 Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP 204 [RFC5072]. 206 4.3. IPv6 over ATM Networks - RFC 2492 208 Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM 209 Networks [RFC2492]. Additionally, RFC 2492 states: 211 A minimally conforming IPv6/ATM driver SHALL support the PVC mode 212 of operation. An IPv6/ATM driver that supports the full SVC mode 213 SHALL also support PVC mode of operation. 215 5. IP Layer 217 5.1. Internet Protocol Version 6 - RFC 2460 219 The Internet Protocol Version 6 is specified in [RFC2460]. This 220 specification MUST be supported. 222 Unrecognized options in Hop-by-Hop Options or Destination Options 223 extensions MUST be processed as described in RFC 2460. 225 The node MUST follow the packet transmission rules in RFC 2460. 227 Nodes MUST always be able to send, receive, and process fragment 228 headers. All conformant IPv6 implementations MUST be capable of 229 sending and receiving IPv6 packets; the forwarding functionality MAY 230 be supported. 232 RFC 2460 specifies extension headers and the processing for these 233 headers. 235 A full implementation of IPv6 includes implementation of the 236 following extension headers: Hop-by-Hop Options, Routing (Type 0), 237 Fragment, Destination Options, Authentication and Encapsulating 238 Security Payload [RFC2460]. 240 An IPv6 node MUST be able to process these headers. It should be 241 noted that there is some discussion about the use of Routing Headers 242 and possible security threats 'IPv6-RH' that they cause. 244 5.2. Neighbor Discovery for IPv6 - RFC 4861 246 Neighbor Discovery SHOULD be supported. [RFC4861] states: 248 Unless specified otherwise (in a document that covers operating IP 249 over a particular link type) this document applies to all link 250 types. However, because ND uses link-layer multicast for some of 251 its services, it is possible that on some link types (e.g., NBMA 252 links) alternative protocols or mechanisms to implement those 253 services will be specified (in the appropriate document covering 254 the operation of IP over a particular link type). The services 255 described in this document that are not directly dependent on 256 multicast, such as Redirects, Next-hop determination, Neighbor 257 Unreachability Detection, etc., are expected to be provided as 258 specified in this document. The details of how one uses ND on 259 NBMA links is an area for further study. 261 Some detailed analysis of Neighbor Discovery follows: 263 Router Discovery is how hosts locate routers that reside on an 264 attached link. Router Discovery MUST be supported for 265 implementations. 267 Prefix Discovery is how hosts discover the set of address prefixes 268 that define which destinations are on-link for an attached link. 269 Prefix discovery MUST be supported for implementations. Neighbor 270 Unreachability Detection (NUD) MUST be supported for all paths 271 between hosts and neighboring nodes. It is not required for paths 272 between routers. However, when a node receives a unicast Neighbor 273 Solicitation (NS) message (that may be a NUD's NS), the node MUST 274 respond to it (i.e., send a unicast Neighbor Advertisement). 276 Duplicate Address Detection MUST be supported on all links supporting 277 link-layer multicast (RFC 4862, Section 5.4, specifies DAD MUST take 278 place on all unicast addresses). 280 A host implementation MUST support sending Router Solicitations. 282 Receiving and processing Router Advertisements MUST be supported for 283 host implementations. The ability to understand specific Router 284 Advertisement options is dependent on supporting the specification 285 where the RA is specified. 287 Sending and Receiving Neighbor Solicitation (NS) and Neighbor 288 Advertisement (NA) MUST be supported. NS and NA messages are 289 required for Duplicate Address Detection (DAD). 291 Redirect functionality SHOULD be supported. If the node is a router, 292 Redirect functionality MUST be supported. 294 5.3. Path MTU Discovery and Packet Size 296 5.3.1. Path MTU Discovery - RFC 1981 298 Path MTU Discovery [RFC1981] SHOULD be supported, though minimal 299 implementations MAY choose to not support it and avoid large packets. 300 The rules in RFC 2460 MUST be followed for packet fragmentation and 301 reassembly. 303 5.4. IPv6 Jumbograms - RFC 2675 305 IPv6 Jumbograms [RFC2675] MAY be supported. 307 5.5. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 309 ICMPv6 [RFC4443] MUST be supported. 311 5.6. Addressing 313 5.6.1. IP Version 6 Addressing Architecture - RFC 4291 315 The IPv6 Addressing Architecture [RFC4291] MUST be supported. 317 5.6.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 319 IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. 320 This specification MUST be supported for nodes that are hosts. 321 Static address can be supported as well. 323 Nodes that are routers MUST be able to generate link local addresses 324 as described in RFC 4862 [RFC4862]. 326 From 4862: 328 The autoconfiguration process specified in this document applies 329 only to hosts and not routers. Since host autoconfiguration uses 330 information advertised by routers, routers will need to be 331 configured by some other means. However, it is expected that 332 routers will generate link-local addresses using the mechanism 333 described in this document. In addition, routers are expected to 334 successfully pass the Duplicate Address Detection procedure 335 described in this document on all addresses prior to assigning 336 them to an interface. 338 Duplicate Address Detection (DAD) MUST be supported. 340 5.6.3. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 342 Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] 343 SHOULD be supported. It is recommended that this behavior be 344 configurable on a connection basis within each application when 345 available. It is noted that a number of applications do not work 346 with addresses generated with this method, while other applications 347 work quite well with them. 349 5.6.4. Default Address Selection for IPv6 - RFC 3484 351 The rules specified in the Default Address Selection for IPv6 352 [RFC3484] document MUST be implemented. It is expected that IPv6 353 nodes will need to deal with multiple addresses. 355 5.6.5. Stateful Address Autoconfiguration 357 Stateful Address Autoconfiguration MAY be supported. DHCPv6 358 [RFC3315] is the standard stateful address configuration protocol; 359 see Section 5.3 for DHCPv6 support. 361 Nodes which do not support Stateful Address Autoconfiguration may be 362 unable to obtain any IPv6 addresses, aside from link-local addresses, 363 when it receives a router advertisement with the 'M' flag (Managed 364 address configuration) set and that contains no prefixes advertised 365 for Stateless Address Autoconfiguration (see Section 4.5.2). 366 Additionally, such nodes will be unable to obtain other configuration 367 information, such as the addresses of DNS servers when it is 368 connected to a link over which the node receives a router 369 advertisement in which the 'O' flag (Other stateful configuration) is 370 set. 372 5.7. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 374 Nodes that need to join multicast groups MUST support MLDv1 375 [RFC3590]. MLDv1 is needed by any node that is expected to receive 376 and process multicast traffic. Note that Neighbor Discovery (as used 377 on most link types -- see Section 5.2) depends on multicast and 378 requires that nodes join Solicited Node multicast addresses. 380 Nodes that need to join multicast groups SHOULD implement MLDv2 381 [RFC3810]. However, if the node has applications that only need 382 support for Any-Source Multicast [RFC3569], the node MAY implement 383 MLDv1 [RFC2710] instead. If the node has applications that need 384 support for Source-Specific Multicast [RFC3569], [RFC4607], the node 385 MUST support MLDv2 [RFC3810]. In all cases, nodes are strongly 386 encouraged to implement MLDv2 rather than MLDv1, as the presence of a 387 single MLDv1 participant on a link requires that all other nodes on 388 the link operate in version 1 compatability mode. 390 When MLDv1 is used, the rules in the Source Address Selection for the 391 Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be 392 followed. 394 6. DNS and DHCP 396 6.1. DNS 398 DNS is described in [RFC1034], [RFC1035], [RFC3363], and [RFC3596]. 399 Not all nodes will need to resolve names; those that will never need 400 to resolve DNS names do not need to implement resolver functionality. 401 However, the ability to resolve names is a basic infrastructure 402 capability that applications rely on and generally needs to be 403 supported. All nodes that need to resolve names SHOULD implement 404 stub-resolver [RFC1034] functionality, as in RFC 1034, Section 5.3.1, 405 with support for: 407 - AAAA type Resource Records [RFC3596]; 408 - reverse addressing in ip6.arpa using PTR records [RFC3596]; 409 - EDNS0 [RFC2671] to allow for DNS packet sizes larger than 512 410 octets. 412 Those nodes are RECOMMENDED to support DNS security extensions 413 [RFC4033], [RFC4034], and [RFC4035]. 415 Those nodes are NOT RECOMMENDED to support the experimental A6 416 Resource Records [RFC3363]. 418 6.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315 420 6.2.1. 5.2.1. Managed Address Configuration 422 The method by which IPv6 nodes that use DHCP for address assignment 423 can obtain IPv6 addresses and other configuration information upon 424 receipt of a Router Advertisement with the \'M' flag set is described 425 in Section 5.5.3 of RFC 4862. 427 In addition, in the absence of a router, those IPv6 nodes that use 428 DHCP for address assignment MAY initiate DHCP to obtain IPv6 429 addresses and other configuration information, as described in 430 Section 5.5.2 of RFC 4862. Those IPv6 nodes that do not use DHCP for 431 address assignment can ignore the 'M' flag in Router Advertisements. 433 6.2.2. Other Configuration Information 435 The method by which IPv6 nodes that use DHCP to obtain other 436 configuration information can obtain other configuration information 437 upon receipt of a Router Advertisement with the \'O' flag set is 438 described in Section 5.5.3 of RFC 4862. 440 Those IPv6 nodes that use DHCP to obtain other configuration 441 information initiate DHCP for other configuration information upon 442 receipt of a Router Advertisement with the 'O' flag set, as described 443 in Section 5.5.3 of RFC 4862. Those IPv6 nodes that do not use DHCP 444 for other configuration information can ignore the 'O' flag in Router 445 Advertisements. 447 An IPv6 node can use the subset of DHCP (described in [RFC3736]) to 448 obtain other configuration information. 450 6.2.3. Use of Router Advertisements in Managed Environments 452 Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 453 are expected to determine their default router information and on- 454 link prefix information from received Router Advertisements. 456 7. IPv4 Support and Transition 458 IPv6 nodes MAY support IPv4. 460 7.1. Transition Mechanisms 462 7.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893 464 If an IPv6 node implements dual stack and tunneling, then [RFC4213] 465 MUST be supported. 467 8. Mobile IP 469 The Mobile IPv6 [RFC3775] specification defines requirements for the 470 following types of nodes: 472 - mobile nodes 473 - correspondent nodes with support for route optimization 474 - home agents 475 - all IPv6 routers 477 Hosts MAY support mobile node functionality described in Section 8.5 478 of [RFC3775], including support of generic packet tunneling [RFC2473] 479 and secure home agent communications [RFC3776]. 481 Hosts SHOULD support route optimization requirements for 482 correspondent nodes described in Section 8.2 of [RFC3775]. 484 Routers SHOULD support the generic mobility-related requirements for 485 all IPv6 routers described in Section 8.3 of [RFC3775]. Routers MAY 486 support the home agent functionality described in Section 8.4 of 487 [RFC3775], including support of [RFC2473] and [RFC3776]. 489 9. Security 491 This section describes the specification of IPsec for the IPv6 node. 493 9.1. Basic Architecture 495 Security Architecture for the Internet Protocol [RFC4301] MUST be 496 supported. 498 9.2. Security Protocols 500 ESP [RFC4303] MUST be supported. AH [RFC4302] MAY be supported. 502 9.3. Transforms and Algorithms 504 Current IPsec RFCs specify the support of transforms and algorithms 505 for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and 506 HMAC-MD5-96. However, 'Cryptographic Algorithm Implementation 507 Requirements For ESP and AH' [RFC4835] contains the current set of 508 mandatory to implement algorithms for ESP and AH. It also specifies 509 algorithms that should be implemented because they are likely to be 510 promoted to mandatory at some future time. IPv6 nodes SHOULD conform 511 to the requirements in [RFC4835], as well as the requirements 512 specified below. 514 Since ESP encryption and authentication are both optional, support 515 for the NULL encryption algorithm [RFC2410] and the NULL 516 authentication algorithm [RFC4303] MUST be provided to maintain 517 consistency with the way these services are negotiated. However, 518 while authentication and encryption can each be NULL, they MUST NOT 519 both be NULL. The NULL encryption algorithm is also useful for 520 debugging. 522 The DES-CBC encryption algorithm [RFC2405] SHOULD NOT be supported 523 within ESP. Security issues related to the use of DES are discussed 524 in 'DESDIFF', 'DESINT', and 'DESCRACK'. DES-CBC is still listed as 525 required by the existing IPsec RFCs, but updates to these RFCs will 526 be published in the near future. DES provides 56 bits of protection, 527 which is no longer considered sufficient. 529 The use of the HMAC-SHA-1-96 algorithm [RFC2404] within AH and ESP 530 MUST be supported. The use of the HMAC-MD5-96 algorithm [RFC2403] 531 within AH and ESP MAY also be supported. 533 The 3DES-CBC encryption algorithm [RFC2451] does not suffer from the 534 same security issues as DES-CBC, and the 3DES-CBC algorithm within 535 ESP MUST be supported to ensure interoperability. 537 The AES-128-CBC algorithm [RFC3602] MUST also be supported within 538 ESP. AES-128 is expected to be a widely available, secure, and 539 efficient algorithm. While AES-128-CBC is not required by the 540 current IPsec RFCs, it is expected to become required in the future. 542 9.4. Key Management Methods 544 An implementation MUST support the manual configuration of the 545 security key and SPI. The SPI configuration is needed in order to 546 delineate between multiple keys. 548 Key management SHOULD be supported. Examples of key management 549 systems include IKEv2 [RFC4306] and Kerberos; S/MIME and TLS include 550 key management functions. 552 Where key refresh, anti-replay features of AH and ESP, or on-demand 553 creation of Security Associations (SAs) is required, automated keying 554 MUST be supported. 556 Key management methods for multicast traffic are also being worked on 557 by the MSEC WG. 559 10. Router-Specific Functionality 561 This section defines general host considerations for IPv6 nodes that 562 act as routers. Currently, this section does not discuss routing- 563 specific requirements. 565 10.1. General 566 10.1.1. IPv6 Router Alert Option - RFC 2711 568 The IPv6 Router Alert Option [RFC2711] is an optional IPv6 Hop-by-Hop 569 Header that is used in conjunction with some protocols (e.g., RSVP 570 [RFC2205] or MLD [RFC2710]). The Router Alert option will need to be 571 implemented whenever protocols that mandate its usage are 572 implemented. See Section 4.6. 574 10.1.2. Neighbor Discovery for IPv6 - RFC 4861 576 Sending Router Advertisements and processing Router Solicitation MUST 577 be supported. 579 11. Network Management 581 Network Management MAY be supported by IPv6 nodes. However, for IPv6 582 nodes that are embedded devices, network management may be the only 583 possible way of controlling these nodes. 585 11.1. Management Information Base Modules (MIBs) 587 The following two MIBs SHOULD be supported by nodes that support an 588 SNMP agent. 590 11.1.1. IP Forwarding Table MIB 592 IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes that 593 support an SNMP agent. 595 11.1.2. Management Information Base for the Internet Protocol (IP) 597 IP MIB [RFC4293] SHOULD be supported by nodes that support an SNMP 598 agent. 600 12. Security Considerations 602 This document does not affect the security of the Internet, but 603 implementations of IPv6 are expected to support a minimum set of 604 security features to ensure security on the Internet. 'IP Security 605 Document Roadmap' [RFC2411] is important for everyone to read. 607 The security considerations in RFC 2460 state the following: 609 The security features of IPv6 are described in the Security 610 Architecture for the Internet Protocol [RFC2401]. 612 RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for 613 the security features of IPv6. 615 13. Authors and Acknowledgements 617 This document was written by the IPv6 Node Requirements design team: 619 Jari Arkko 620 jari.arkko@ericsson.com 621 Marc Blanchet 622 marc.blanchet@viagenie.qc.ca 623 Samita Chakrabarti 624 samita.chakrabarti@eng.sun.com 625 Alain Durand 626 alain.durand@sun.com 627 Gerard Gastaud 628 gerard.gastaud@alcatel.fr 629 Jun-ichiro itojun Hagino 630 itojun@iijlab.net 631 Atsushi Inoue 632 inoue@isl.rdc.toshiba.co.jp 633 Masahiro Ishiyama 634 masahiro@isl.rdc.toshiba.co.jp 635 John Loughney 636 john.loughney@nokia.com 637 Rajiv Raghunarayan 638 raraghun@cisco.com 639 Shoichi Sakane 640 shouichi.sakane@jp.yokogawa.com 641 Dave Thaler 642 dthaler@windows.microsoft.com 643 Juha Wiljakka 644 juha.wiljakka@Nokia.com 646 The authors would like to thank Ran Atkinson, Jim Bound, Brian 647 Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas 648 Narten, Juha Ollila, and Pekka Savola for their comments. Thanks to 649 Mark Andrews for comments and corrections on DNS text. Thanks to 650 Alfred Hoenes for tracking the updates to various RFCs. 652 14. Appendix: Changes from RFC 4294 654 This appendix keeps track of the chances from RFC 4294 656 1. Section 5.1, removed "and DNAME" from the discussion about RFC- 657 3363. 659 2. RFC 2463 references updated to RFC 4443. 661 3. RFC 3513 references updated to RFC 4291. 663 4. RFC 3152 refrrences updated to RFC 3596. 665 5. RFC 2893 references updated to RFC 4213. 667 6. AH [RFC-4302] support chanced from MUST to MAY. 669 7. The reference for RFC 3152 has been deleted, as the RFC has been 670 obsoleted, and has been incorporated into RFC 3596. 672 8. The reference for RFC 3879 has been reomved as the material from 673 RFC 3879 has been incorporated into RFC 4291. 675 15. References 677 15.1. Normative References 679 [RFC1035] Mockapetris, P., "Domain names - implementation and 680 specification", STD 13, RFC 1035, November 1987. 682 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 683 for IP version 6", RFC 1981, August 1996. 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, March 1997. 688 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 689 Internet Protocol", RFC 2401, November 1998. 691 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 692 ESP and AH", RFC 2403, November 1998. 694 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 695 ESP and AH", RFC 2404, November 1998. 697 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 698 Algorithm With Explicit IV", RFC 2405, November 1998. 700 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 701 Its Use With IPsec", RFC 2410, November 1998. 703 [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security 704 Document Roadmap", RFC 2411, November 1998. 706 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 707 Algorithms", RFC 2451, November 1998. 709 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 710 (IPv6) Specification", RFC 2460, December 1998. 712 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 713 IPv6 Specification", RFC 2473, December 1998. 715 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 716 RFC 2671, August 1999. 718 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 719 Listener Discovery (MLD) for IPv6", RFC 2710, 720 October 1999. 722 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 723 RFC 2711, October 1999. 725 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 726 and M. Carney, "Dynamic Host Configuration Protocol for 727 IPv6 (DHCPv6)", RFC 3315, July 2003. 729 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 730 Hain, "Representing Internet Protocol version 6 (IPv6) 731 Addresses in the Domain Name System (DNS)", RFC 3363, 732 August 2002. 734 [RFC3484] Draves, R., "Default Address Selection for Internet 735 Protocol version 6 (IPv6)", RFC 3484, February 2003. 737 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 738 Listener Discovery (MLD) Protocol", RFC 3590, 739 September 2003. 741 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 742 "DNS Extensions to Support IP Version 6", RFC 3596, 743 October 2003. 745 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 746 Algorithm and Its Use with IPsec", RFC 3602, 747 September 2003. 749 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 750 in IPv6", RFC 3775, June 2004. 752 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 753 Protect Mobile IPv6 Signaling Between Mobile Nodes and 754 Home Agents", RFC 3776, June 2004. 756 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 757 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 759 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 760 Architecture", RFC 4291, February 2006. 762 [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, 763 April 2006. 765 [RFC4293] Routhier, S., "Management Information Base for the 766 Internet Protocol (IP)", RFC 4293, April 2006. 768 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 769 Internet Protocol", RFC 4301, December 2005. 771 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 772 December 2005. 774 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 775 RFC 4303, December 2005. 777 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 778 Message Protocol (ICMPv6) for the Internet Protocol 779 Version 6 (IPv6) Specification", RFC 4443, March 2006. 781 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 782 IP", RFC 4607, August 2006. 784 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 785 Requirements for Encapsulating Security Payload (ESP) and 786 Authentication Header (AH)", RFC 4835, April 2007. 788 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 789 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 790 September 2007. 792 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 793 Address Autoconfiguration", RFC 4862, September 2007. 795 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 796 Extensions for Stateless Address Autoconfiguration in 797 IPv6", RFC 4941, September 2007. 799 [RFC5072] S.Varada, Haskin, D., and E. Allen, "IP Version 6 over 800 PPP", RFC 5072, September 2007. 802 15.2. Informative References 804 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 805 RFC 793, September 1981. 807 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 808 STD 13, RFC 1034, November 1987. 810 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 811 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 812 Functional Specification", RFC 2205, September 1997. 814 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 815 Networks", RFC 2464, December 1998. 817 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 818 Networks", RFC 2492, January 1999. 820 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 821 RFC 2675, August 1999. 823 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 824 Multicast (SSM)", RFC 3569, July 2003. 826 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 827 (DHCP) Service for IPv6", RFC 3736, April 2004. 829 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 830 Rose, "DNS Security Introduction and Requirements", 831 RFC 4033, March 2005. 833 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 834 Rose, "Resource Records for the DNS Security Extensions", 835 RFC 4034, March 2005. 837 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 838 Rose, "Protocol Modifications for the DNS Security 839 Extensions", RFC 4035, March 2005. 841 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 842 for IPv6 Hosts and Routers", RFC 4213, October 2005. 844 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 845 RFC 4306, December 2005. 847 Author's Address 849 John Loughney 850 Nokia 851 955 Page Mill Road 852 Palo Alto 94303 853 USA 855 Phone: +1 650 283 8068 856 Email: john.loughney@nokia.com 858 Full Copyright Statement 860 Copyright (C) The IETF Trust (2008). 862 This document is subject to the rights, licenses and restrictions 863 contained in BCP 78, and except as set forth therein, the authors 864 retain all their rights. 866 This document and the information contained herein are provided on an 867 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 868 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 869 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 870 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 871 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 872 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 874 Intellectual Property 876 The IETF takes no position regarding the validity or scope of any 877 Intellectual Property Rights or other rights that might be claimed to 878 pertain to the implementation or use of the technology described in 879 this document or the extent to which any license under such rights 880 might or might not be available; nor does it represent that it has 881 made any independent effort to identify any such rights. Information 882 on the procedures with respect to rights in RFC documents can be 883 found in BCP 78 and BCP 79. 885 Copies of IPR disclosures made to the IETF Secretariat and any 886 assurances of licenses to be made available, or the result of an 887 attempt made to obtain a general license or permission for the use of 888 such proprietary rights by implementers or users of this 889 specification can be obtained from the IETF on-line IPR repository at 890 http://www.ietf.org/ipr. 892 The IETF invites any interested party to bring to its attention any 893 copyrights, patents or patent applications, or other proprietary 894 rights that may cover technology that may be required to implement 895 this standard. Please address the information to the IETF at 896 ietf-ipr@ietf.org.