idnits 2.17.1 draft-ietf-6man-node-req-bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC-4302' is mentioned on line 742, 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 (==), 5 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 T. Narten 5 Expires: January 14, 2010 IBM Corporation 6 July 13, 2009 8 IPv6 Node Requirements RFC 4294-bis 9 draft-ietf-6man-node-req-bis-03.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 14, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document defines requirements for IPv6 nodes. It is expected 58 that IPv6 will be deployed in a wide range of devices and situations. 59 Specifying the requirements for IPv6 nodes allows IPv6 to function 60 well and interoperate in a large number of situations and 61 deployments. 63 Table of Contents 65 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Scope of This Document . . . . . . . . . . . . . . . . . . 4 68 2.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 4 69 3. Abbreviations Used in This Document . . . . . . . . . . . . . 5 70 4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. Transmission of IPv6 Packets over Ethernet Networks - 72 RFC 2464 . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.2. IP version 6 over PPP - RFC 5072 . . . . . . . . . . . . . 6 74 4.3. IPv6 over ATM Networks - RFC 2492 . . . . . . . . . . . . 6 75 5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . . 6 77 5.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 7 78 5.3. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 8 79 5.4. Path MTU Discovery and Packet Size . . . . . . . . . . . . 8 80 5.4.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 8 81 5.5. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 8 82 5.6. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 83 4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 5.7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 8 85 5.7.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 8 86 5.7.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 9 87 5.7.3. Privacy Extensions for Address Configuration in 88 IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 9 89 5.7.4. Default Address Selection for IPv6 - RFC 3484 . . . . 9 90 5.7.5. Stateful Address Autoconfiguration . . . . . . . . . . 9 91 5.8. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 . . 10 92 6. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 10 93 6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 94 6.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 95 - RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 11 97 6.2.1. 5.2.1. Managed Address Configuration . . . . . . . . 11 98 6.2.2. Other Configuration Information . . . . . . . . . . . 11 99 6.2.3. Use of Router Advertisements in Managed 100 Environments . . . . . . . . . . . . . . . . . . . . . 11 101 7. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 12 102 7.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 12 103 7.1.1. Basic Transition Mechanisms for IPv6 Hosts and 104 Routers - RFC 4213 . . . . . . . . . . . . . . . . . . 12 105 8. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 106 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 107 9.1. Basic Architecture . . . . . . . . . . . . . . . . . . . . 12 108 9.2. Security Protocols . . . . . . . . . . . . . . . . . . . . 13 109 9.3. Transforms and Algorithms . . . . . . . . . . . . . . . . 13 110 9.4. Key Management Methods . . . . . . . . . . . . . . . . . . 13 111 10. Router-Specific Functionality . . . . . . . . . . . . . . . . 14 112 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 113 10.1.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . 14 114 10.1.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . 14 115 11. Network Management . . . . . . . . . . . . . . . . . . . . . . 14 116 11.1. Management Information Base Modules (MIBs) . . . . . . . . 14 117 11.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . . 15 118 11.1.2. Management Information Base for the Internet 119 Protocol (IP) . . . . . . . . . . . . . . . . . . . . 15 120 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15 121 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 122 14. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 16 123 15. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 17 124 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 125 16.1. Normative References . . . . . . . . . . . . . . . . . . . 17 126 16.2. Informative References . . . . . . . . . . . . . . . . . . 20 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 129 1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 2. Introduction 137 The goal of this document is to define the common functionality 138 required from both IPv6 hosts and routers. Many IPv6 nodes will 139 implement optional or additional features, but this document 140 summarizes requirements from other published Standards Track 141 documents in one place. 143 This document tries to avoid discussion of protocol details, and 144 references RFCs for this purpose. This document is informational in 145 nature and does not update Standards Track RFCs. 147 Although the document points to different specifications, it should 148 be noted that in most cases, the granularity of requirements are 149 smaller than a single specification, as many specifications define 150 multiple, independent pieces, some of which may not be mandatory. 152 As it is not always possible for an implementer to know the exact 153 usage of IPv6 in a node, an overriding requirement for IPv6 nodes is 154 that they should adhere to Jon Postel's Robustness Principle: 156 Be conservative in what you do, be liberal in what you accept from 157 others [RFC0793]. 159 2.1. Scope of This Document 161 IPv6 covers many specifications. It is intended that IPv6 will be 162 deployed in many different situations and environments. Therefore, 163 it is important to develop the requirements for IPv6 nodes to ensure 164 interoperability. 166 This document assumes that all IPv6 nodes meet the minimum 167 requirements specified here. 169 2.2. Description of IPv6 Nodes 171 From the Internet Protocol, Version 6 (IPv6) Specification [RFC2460], 172 we have the following definitions: 174 Description of an IPv6 Node 175 - a device that implements IPv6. 177 Description of an IPv6 router 179 - a node that forwards IPv6 packets not explicitly addressed to 180 itself. 182 Description of an IPv6 Host 184 - any node that is not a router. 186 3. Abbreviations Used in This Document 188 ATM Asynchronous Transfer Mode 189 AH Authentication Header 190 DAD Duplicate Address Detection 191 ESP Encapsulating Security Payload 192 ICMP Internet Control Message Protocol 193 IKE Internet Key Exchange 194 MIB Management Information Base 195 MLD Multicast Listener Discovery 196 MTU Maximum Transfer Unit 197 NA Neighbor Advertisement 198 NBMA Non-Broadcast Multiple Access 199 ND Neighbor Discovery 200 NS Neighbor Solicitation 201 NUD Neighbor Unreachability Detection 202 PPP Point-to-Point Protocol 203 PVC Permanent Virtual Circuit 204 SVC Switched Virtual Circuit 206 4. Sub-IP Layer 208 An IPv6 node must include support for one or more IPv6 link-layer 209 specifications. Which link-layer specifications are included will 210 depend upon what link-layers are supported by the hardware available 211 on the system. It is possible for a conformant IPv6 node to support 212 IPv6 on some of its interfaces and not on others. 214 As IPv6 is run over new layer 2 technologies, it is expected that new 215 specifications will be issued. This section highlights some major 216 layer 2 technologies and is not intended to be complete. 218 4.1. Transmission of IPv6 Packets over Ethernet Networks - RFC 2464 220 Nodes supporting IPv6 over Ethernet interfaces MUST implement 221 Transmission of IPv6 Packets over Ethernet Networks [RFC2464]. 223 4.2. IP version 6 over PPP - RFC 5072 225 Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP 226 [RFC5072]. 228 4.3. IPv6 over ATM Networks - RFC 2492 230 Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM 231 Networks [RFC2492]. Additionally, RFC 2492 states: 233 A minimally conforming IPv6/ATM driver SHALL support the PVC mode 234 of operation. An IPv6/ATM driver that supports the full SVC mode 235 SHALL also support PVC mode of operation. 237 5. IP Layer 239 5.1. Internet Protocol Version 6 - RFC 2460 241 The Internet Protocol Version 6 is specified in [RFC2460]. This 242 specification MUST be supported. 244 Unrecognized options in Hop-by-Hop Options or Destination Options 245 extensions MUST be processed as described in RFC 2460. 247 The node MUST follow the packet transmission rules in RFC 2460. 249 Nodes MUST always be able to send, receive, and process fragment 250 headers. All conformant IPv6 implementations MUST be capable of 251 sending and receiving IPv6 packets; the forwarding functionality MAY 252 be supported. 254 RFC 2460 specifies extension headers and the processing for these 255 headers. 257 A full implementation of IPv6 includes implementation of the 258 following extension headers: Hop-by-Hop Options, Routing (Type 0), 259 Fragment, Destination Options, Authentication and Encapsulating 260 Security Payload [RFC2460]. 262 An IPv6 node MUST be able to process these headers. An exception is 263 Routing Header type 0 (RH0) which was deprecated by [RFC5095] due to 264 security concerns, and which MUST be treated as an unrecognized 265 routing type. 267 5.2. Neighbor Discovery for IPv6 - RFC 4861 269 Neighbor Discovery SHOULD be supported. [RFC4861] states: 271 Unless specified otherwise (in a document that covers operating IP 272 over a particular link type) this document applies to all link 273 types. However, because ND uses link-layer multicast for some of 274 its services, it is possible that on some link types (e.g., NBMA 275 links) alternative protocols or mechanisms to implement those 276 services will be specified (in the appropriate document covering 277 the operation of IP over a particular link type). The services 278 described in this document that are not directly dependent on 279 multicast, such as Redirects, Next-hop determination, Neighbor 280 Unreachability Detection, etc., are expected to be provided as 281 specified in this document. The details of how one uses ND on 282 NBMA links is an area for further study. 284 Some detailed analysis of Neighbor Discovery follows: 286 Router Discovery is how hosts locate routers that reside on an 287 attached link. Router Discovery MUST be supported for 288 implementations. 290 Prefix Discovery is how hosts discover the set of address prefixes 291 that define which destinations are on-link for an attached link. 292 Prefix discovery MUST be supported for implementations. Neighbor 293 Unreachability Detection (NUD) MUST be supported for all paths 294 between hosts and neighboring nodes. It is not required for paths 295 between routers. However, when a node receives a unicast Neighbor 296 Solicitation (NS) message (that may be a NUD's NS), the node MUST 297 respond to it (i.e., send a unicast Neighbor Advertisement). 299 Duplicate Address Detection MUST be supported on all links supporting 300 link-layer multicast (RFC 4862, Section 5.4, specifies DAD MUST take 301 place on all unicast addresses). 303 A host implementation MUST support sending Router Solicitations. 305 Receiving and processing Router Advertisements MUST be supported for 306 host implementations. The ability to understand specific Router 307 Advertisement options is dependent on supporting the specification 308 where the RA is specified. 310 Sending and Receiving Neighbor Solicitation (NS) and Neighbor 311 Advertisement (NA) MUST be supported. NS and NA messages are 312 required for Duplicate Address Detection (DAD). 314 Redirect functionality SHOULD be supported. If the node is a router, 315 Redirect functionality MUST be supported. 317 5.3. IPv6 Router Advertisement Flags Option - RFC 5175 319 Router Advertisements include an 8-bit field of single-bit Router 320 Advertisement flags. The Router Advertisement Flags Option extends 321 the number of available flag bits by 48 bits. At the time of this 322 writing, 6 of the original 8 bit flags have been assigned, while 2 323 are available for future assignment. No flags have been defined that 324 make use of the new option, and thus strictly speaking, there is no 325 requirement to implement the option today. However, implementations 326 that are able to pass unrecognized options to a higher level entity 327 that may be able to understand them (e.g., a user-level process using 328 a "raw socket" facility), MAY take steps to handle the option in 329 anticipation of a future usage. 331 5.4. Path MTU Discovery and Packet Size 333 5.4.1. Path MTU Discovery - RFC 1981 335 From [RFC2460]: 337 It is strongly recommended that IPv6 nodes implement Path MTU 338 Discovery [RFC1981], in order to discover and take advantage of 339 path MTUs greater than 1280 octets. However, a minimal IPv6 340 implementation (e.g., in a boot ROM) may simply restrict itself to 341 sending packets no larger than 1280 octets, and omit 342 implementation of Path MTU Discovery. 344 The rules in RFC 2460 MUST be followed for packet fragmentation and 345 reassembly. 347 5.5. IPv6 Jumbograms - RFC 2675 349 IPv6 Jumbograms [RFC2675] MAY be supported. 351 5.6. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 353 ICMPv6 [RFC4443] MUST be supported. 355 5.7. Addressing 357 5.7.1. IP Version 6 Addressing Architecture - RFC 4291 359 The IPv6 Addressing Architecture [RFC4291] MUST be supported. 361 5.7.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 363 IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. 364 This specification MUST be supported for nodes that are hosts. 365 Static address can be supported as well. 367 Nodes that are routers MUST be able to generate link local addresses 368 as described in RFC 4862 [RFC4862]. 370 From 4862: 372 The autoconfiguration process specified in this document applies 373 only to hosts and not routers. Since host autoconfiguration uses 374 information advertised by routers, routers will need to be 375 configured by some other means. However, it is expected that 376 routers will generate link-local addresses using the mechanism 377 described in this document. In addition, routers are expected to 378 successfully pass the Duplicate Address Detection procedure 379 described in this document on all addresses prior to assigning 380 them to an interface. 382 Duplicate Address Detection (DAD) MUST be supported. 384 5.7.3. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 386 Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] 387 SHOULD be supported. It is recommended that this behavior be 388 configurable on a connection basis within each application when 389 available. It is noted that a number of applications do not work 390 with addresses generated with this method, while other applications 391 work quite well with them. 393 5.7.4. Default Address Selection for IPv6 - RFC 3484 395 The rules specified in the Default Address Selection for IPv6 396 [RFC3484] document MUST be implemented. It is expected that IPv6 397 nodes will need to deal with multiple addresses. 399 5.7.5. Stateful Address Autoconfiguration 401 Stateful Address Autoconfiguration MAY be supported. DHCPv6 402 [RFC3315] is the standard stateful address configuration protocol; 403 see Section 6.2 for DHCPv6 support. 405 Nodes which do not support Stateful Address Autoconfiguration may be 406 unable to obtain any IPv6 addresses, aside from link-local addresses, 407 when it receives a router advertisement with the 'M' flag (Managed 408 address configuration) set and that contains no prefixes advertised 409 for Stateless Address Autoconfiguration (see Section 4.5.2). 410 Additionally, such nodes will be unable to obtain other configuration 411 information, such as the addresses of DNS servers when it is 412 connected to a link over which the node receives a router 413 advertisement in which the 'O' flag (Other stateful configuration) is 414 set. 416 5.8. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 418 Nodes that need to join multicast groups MUST support MLDv1 419 [RFC3590]. MLDv1 is needed by any node that is expected to receive 420 and process multicast traffic. Note that Neighbor Discovery (as used 421 on most link types -- see Section 5.2) depends on multicast and 422 requires that nodes join Solicited Node multicast addresses. 424 Nodes that need to join multicast groups SHOULD implement MLDv2 425 [RFC3810]. However, if the node has applications that only need 426 support for Any-Source Multicast [RFC3569], the node MAY implement 427 MLDv1 [RFC2710] instead. If the node has applications that need 428 support for Source-Specific Multicast [RFC3569], [RFC4607], the node 429 MUST support MLDv2 [RFC3810]. In all cases, nodes are strongly 430 encouraged to implement MLDv2 rather than MLDv1, as the presence of a 431 single MLDv1 participant on a link requires that all other nodes on 432 the link operate in version 1 compatability mode. 434 When MLDv1 is used, the rules in the Source Address Selection for the 435 Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be 436 followed. 438 6. DNS and DHCP 440 6.1. DNS 442 DNS is described in [RFC1034], [RFC1035], [RFC3363], and [RFC3596]. 443 Not all nodes will need to resolve names; those that will never need 444 to resolve DNS names do not need to implement resolver functionality. 445 However, the ability to resolve names is a basic infrastructure 446 capability that applications rely on and generally needs to be 447 supported. All nodes that need to resolve names SHOULD implement 448 stub-resolver [RFC1034] functionality, as in RFC 1034, Section 5.3.1, 449 with support for: 451 - AAAA type Resource Records [RFC3596]; 452 - reverse addressing in ip6.arpa using PTR records [RFC3596]; 453 - EDNS0 [RFC2671] to allow for DNS packet sizes larger than 512 454 octets. 456 Those nodes are RECOMMENDED to support DNS security extensions 457 [RFC4033], [RFC4034], and [RFC4035]. 459 Those nodes are NOT RECOMMENDED to support the experimental A6 460 Resource Records [RFC3363]. 462 6.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315 464 6.2.1. 5.2.1. Managed Address Configuration 466 The method by which IPv6 nodes that use DHCP for address assignment 467 can obtain IPv6 addresses and other configuration information upon 468 receipt of a Router Advertisement with the \'M' flag set is described 469 in Section 5.5.3 of RFC 4862. 471 In addition, in the absence of a router, those IPv6 nodes that use 472 DHCP for address assignment MAY initiate DHCP to obtain IPv6 473 addresses and other configuration information, as described in 474 Section 5.5.2 of RFC 4862. Those IPv6 nodes that do not use DHCP for 475 address assignment can ignore the 'M' flag in Router Advertisements. 477 6.2.2. Other Configuration Information 479 The method by which IPv6 nodes that use DHCP to obtain other 480 configuration information can obtain other configuration information 481 upon receipt of a Router Advertisement with the \'O' flag set is 482 described in Section 5.5.3 of RFC 4862. 484 Those IPv6 nodes that use DHCP to obtain other configuration 485 information initiate DHCP for other configuration information upon 486 receipt of a Router Advertisement with the 'O' flag set, as described 487 in Section 5.5.3 of RFC 4862. Those IPv6 nodes that do not use DHCP 488 for other configuration information can ignore the 'O' flag in Router 489 Advertisements. 491 An IPv6 node can use the subset of DHCP (described in [RFC3736]) to 492 obtain other configuration information. 494 6.2.3. Use of Router Advertisements in Managed Environments 496 Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 497 are expected to determine their default router information and on- 498 link prefix information from received Router Advertisements. 500 7. IPv4 Support and Transition 502 IPv6 nodes MAY support IPv4. 504 7.1. Transition Mechanisms 506 7.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC 507 4213 509 If an IPv6 node implements dual stack and tunneling, then [RFC4213] 510 MUST be supported. 512 8. Mobile IP 514 The Mobile IPv6 [RFC3775] specification defines requirements for the 515 following types of nodes: 517 - mobile nodes 518 - correspondent nodes with support for route optimization 519 - home agents 520 - all IPv6 routers 522 Hosts MAY support mobile node functionality described in Section 8.5 523 of [RFC3775], including support of generic packet tunneling [RFC2473] 524 and secure home agent communications [RFC4877]. 526 Hosts SHOULD support route optimization requirements for 527 correspondent nodes described in Section 8.2 of [RFC3775]. 529 Routers SHOULD support the generic mobility-related requirements for 530 all IPv6 routers described in Section 8.3 of [RFC3775]. Routers MAY 531 support the home agent functionality described in Section 8.4 of 532 [RFC3775], including support of [RFC2473] and [RFC4877]. 534 9. Security 536 This section describes the specification of IPsec for the IPv6 node. 538 9.1. Basic Architecture 540 Security Architecture for the Internet Protocol [RFC4301] MUST be 541 supported. 543 9.2. Security Protocols 545 ESP [RFC4303] MUST be supported. AH [RFC4302] MAY be supported. 547 9.3. Transforms and Algorithms 549 Current IPsec RFCs specify the support of transforms and algorithms 550 for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and 551 HMAC-MD5-96. However, 'Cryptographic Algorithm Implementation 552 Requirements For ESP and AH' [RFC4835] contains the current set of 553 mandatory to implement algorithms for ESP and AH. It also specifies 554 algorithms that should be implemented because they are likely to be 555 promoted to mandatory at some future time. IPv6 nodes SHOULD conform 556 to the requirements in [RFC4835], as well as the requirements 557 specified below. 559 Since ESP encryption and authentication are both optional, support 560 for the NULL encryption algorithm [RFC2410] and the NULL 561 authentication algorithm [RFC4303] MUST be provided to maintain 562 consistency with the way these services are negotiated. However, 563 while authentication and encryption can each be NULL, they MUST NOT 564 both be NULL. The NULL encryption algorithm is also useful for 565 debugging. 567 The DES-CBC encryption algorithm [RFC2405] SHOULD NOT be supported 568 within ESP. Security issues related to the use of DES are discussed 569 in 'DESDIFF', 'DESINT', and 'DESCRACK'. DES-CBC is still listed as 570 required by the existing IPsec RFCs, but updates to these RFCs will 571 be published in the near future. DES provides 56 bits of protection, 572 which is no longer considered sufficient. 574 The use of the HMAC-SHA-1-96 algorithm [RFC2404] within AH and ESP 575 MUST be supported. The use of the HMAC-MD5-96 algorithm [RFC2403] 576 within AH and ESP MAY also be supported. 578 The 3DES-CBC encryption algorithm [RFC2451] does not suffer from the 579 same security issues as DES-CBC, and the 3DES-CBC algorithm within 580 ESP MUST be supported to ensure interoperability. 582 The AES-128-CBC algorithm [RFC3602] MUST also be supported within 583 ESP. AES-128 is expected to be a widely available, secure, and 584 efficient algorithm. While AES-128-CBC is not required by the 585 current IPsec RFCs, it is expected to become required in the future. 587 9.4. Key Management Methods 589 An implementation MUST support the manual configuration of the 590 security key and SPI. The SPI configuration is needed in order to 591 delineate between multiple keys. 593 Key management SHOULD be supported. Examples of key management 594 systems include IKEv2 [RFC4306] and Kerberos; S/MIME and TLS include 595 key management functions. 597 Where key refresh, anti-replay features of AH and ESP, or on-demand 598 creation of Security Associations (SAs) is required, automated keying 599 MUST be supported. 601 Key management methods for multicast traffic are also being worked on 602 by the MSEC WG. 604 10. Router-Specific Functionality 606 This section defines general host considerations for IPv6 nodes that 607 act as routers. Currently, this section does not discuss routing- 608 specific requirements. 610 10.1. General 612 10.1.1. IPv6 Router Alert Option - RFC 2711 614 The IPv6 Router Alert Option [RFC2711] is an optional IPv6 Hop-by-Hop 615 Header that is used in conjunction with some protocols (e.g., RSVP 616 [RFC2205] or MLD [RFC2710]). The Router Alert option will need to be 617 implemented whenever protocols that mandate its usage are 618 implemented. See Section 4.6. 620 10.1.2. Neighbor Discovery for IPv6 - RFC 4861 622 Sending Router Advertisements and processing Router Solicitation MUST 623 be supported. 625 11. Network Management 627 Network Management MAY be supported by IPv6 nodes. However, for IPv6 628 nodes that are embedded devices, network management may be the only 629 possible way of controlling these nodes. 631 11.1. Management Information Base Modules (MIBs) 633 The following two MIBs SHOULD be supported by nodes that support an 634 SNMP agent. 636 11.1.1. IP Forwarding Table MIB 638 IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes that 639 support an SNMP agent. 641 11.1.2. Management Information Base for the Internet Protocol (IP) 643 IP MIB [RFC4293] SHOULD be supported by nodes that support an SNMP 644 agent. 646 12. Open Issues 648 1. General: should this document be more of an applicability 649 statement providing context for when a technology may be useful, 650 but without just saying SHOULD or MUST? 651 2. Need to address contradiction that this document is 652 Informational, yet tries to make recommendations that go beyond 653 what is stated in current RFCs in some cases. (see previous 654 point) 655 3. Should we try and tackle the confusion related to the M&O bits in 656 Router Advertisements? (probably not in this document -- see 657 previous point.) 658 4. Need to provide more context for MIPv6 recommendations. Blanket 659 SHOULD for RO in nodes does not reflect current state of MIPv6 660 deployment. 661 5. Security Considerations Section needs updating. 662 6. For things like link-layer types, may be better to just list all 663 the IPv6-over-Foo documents as a summary table, making no 664 recommendations at all. 665 7. Privacy Extensions recommendation needs more context. It makes 666 no sense for a server to implement this. It is only applicable 667 to mobile devices. 668 8. Security Recommendations may need updating. Are they still 669 correct? And what is value of mandating IPsec if there is no key 670 management? Also, what is the sense of mandating IPsec for 671 limited-functionality devices that have a limited number of 672 applications, each using their own security? Relax current 673 requirement or leave as is? 675 13. Security Considerations 677 This document does not affect the security of the Internet, but 678 implementations of IPv6 are expected to support a minimum set of 679 security features to ensure security on the Internet. 'IP Security 680 Document Roadmap' [RFC2411] is important for everyone to read. 682 The security considerations in RFC 2460 state the following: 684 The security features of IPv6 are described in the Security 685 Architecture for the Internet Protocol [RFC2401]. 687 RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for 688 the security features of IPv6. 690 14. Authors and Acknowledgments 692 This document was written by the IPv6 Node Requirements design team: 694 Jari Arkko 695 jari.arkko@ericsson.com 696 Marc Blanchet 697 marc.blanchet@viagenie.qc.ca 698 Samita Chakrabarti 699 samita.chakrabarti@eng.sun.com 700 Alain Durand 701 alain.durand@sun.com 702 Gerard Gastaud 703 gerard.gastaud@alcatel.fr 704 Jun-ichiro itojun Hagino 705 itojun@iijlab.net 706 Atsushi Inoue 707 inoue@isl.rdc.toshiba.co.jp 708 Masahiro Ishiyama 709 masahiro@isl.rdc.toshiba.co.jp 710 John Loughney 711 john.loughney@nokia.com 712 Rajiv Raghunarayan 713 raraghun@cisco.com 714 Shoichi Sakane 715 shouichi.sakane@jp.yokogawa.com 716 Dave Thaler 717 dthaler@windows.microsoft.com 718 Juha Wiljakka 719 juha.wiljakka@Nokia.com 721 The authors would like to thank Ran Atkinson, Jim Bound, Brian 722 Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas 723 Narten, Juha Ollila, and Pekka Savola for their comments. Thanks to 724 Mark Andrews for comments and corrections on DNS text. Thanks to 725 Alfred Hoenes for tracking the updates to various RFCs. 727 15. Appendix: Changes from RFC 4294 729 This appendix keeps track of the chances from RFC 4294 731 1. Section 5.1, removed "and DNAME" from the discussion about RFC- 732 3363. 734 2. RFC 2463 references updated to RFC 4443. 736 3. RFC 3513 references updated to RFC 4291. 738 4. RFC 3152 references updated to RFC 3596. 740 5. RFC 2893 references updated to RFC 4213. 742 6. AH [RFC-4302] support chanced from MUST to MAY. 744 7. The reference for RFC 3152 has been deleted, as the RFC has been 745 obsoleted, and has been incorporated into RFC 3596. 747 8. The reference for RFC 3879 has been removed as the material from 748 RFC 3879 has been incorporated into RFC 4291. 750 16. References 752 16.1. Normative References 754 [RFC1035] Mockapetris, P., "Domain names - implementation and 755 specification", STD 13, RFC 1035, November 1987. 757 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 758 for IP version 6", RFC 1981, August 1996. 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, March 1997. 763 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 764 Internet Protocol", RFC 2401, November 1998. 766 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 767 ESP and AH", RFC 2403, November 1998. 769 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 770 ESP and AH", RFC 2404, November 1998. 772 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 773 Algorithm With Explicit IV", RFC 2405, November 1998. 775 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 776 Its Use With IPsec", RFC 2410, November 1998. 778 [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security 779 Document Roadmap", RFC 2411, November 1998. 781 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 782 Algorithms", RFC 2451, November 1998. 784 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 785 (IPv6) Specification", RFC 2460, December 1998. 787 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 788 IPv6 Specification", RFC 2473, December 1998. 790 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 791 RFC 2671, August 1999. 793 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 794 Listener Discovery (MLD) for IPv6", RFC 2710, 795 October 1999. 797 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 798 RFC 2711, October 1999. 800 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 801 and M. Carney, "Dynamic Host Configuration Protocol for 802 IPv6 (DHCPv6)", RFC 3315, July 2003. 804 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 805 Hain, "Representing Internet Protocol version 6 (IPv6) 806 Addresses in the Domain Name System (DNS)", RFC 3363, 807 August 2002. 809 [RFC3484] Draves, R., "Default Address Selection for Internet 810 Protocol version 6 (IPv6)", RFC 3484, February 2003. 812 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 813 Listener Discovery (MLD) Protocol", RFC 3590, 814 September 2003. 816 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 817 "DNS Extensions to Support IP Version 6", RFC 3596, 818 October 2003. 820 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 821 Algorithm and Its Use with IPsec", RFC 3602, 822 September 2003. 824 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 825 in IPv6", RFC 3775, June 2004. 827 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 828 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 830 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 831 Architecture", RFC 4291, February 2006. 833 [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, 834 April 2006. 836 [RFC4293] Routhier, S., "Management Information Base for the 837 Internet Protocol (IP)", RFC 4293, April 2006. 839 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 840 Internet Protocol", RFC 4301, December 2005. 842 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 843 December 2005. 845 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 846 RFC 4303, December 2005. 848 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 849 Message Protocol (ICMPv6) for the Internet Protocol 850 Version 6 (IPv6) Specification", RFC 4443, March 2006. 852 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 853 IP", RFC 4607, August 2006. 855 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 856 Requirements for Encapsulating Security Payload (ESP) and 857 Authentication Header (AH)", RFC 4835, April 2007. 859 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 860 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 861 September 2007. 863 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 864 Address Autoconfiguration", RFC 4862, September 2007. 866 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 867 IKEv2 and the Revised IPsec Architecture", RFC 4877, 868 April 2007. 870 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 871 Extensions for Stateless Address Autoconfiguration in 872 IPv6", RFC 4941, September 2007. 874 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 875 PPP", RFC 5072, September 2007. 877 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 878 of Type 0 Routing Headers in IPv6", RFC 5095, 879 December 2007. 881 16.2. Informative References 883 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 884 RFC 793, September 1981. 886 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 887 STD 13, RFC 1034, November 1987. 889 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 890 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 891 Functional Specification", RFC 2205, September 1997. 893 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 894 Networks", RFC 2464, December 1998. 896 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 897 Networks", RFC 2492, January 1999. 899 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 900 RFC 2675, August 1999. 902 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 903 Multicast (SSM)", RFC 3569, July 2003. 905 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 906 (DHCP) Service for IPv6", RFC 3736, April 2004. 908 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 909 Rose, "DNS Security Introduction and Requirements", 910 RFC 4033, March 2005. 912 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 913 Rose, "Resource Records for the DNS Security Extensions", 914 RFC 4034, March 2005. 916 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 917 Rose, "Protocol Modifications for the DNS Security 918 Extensions", RFC 4035, March 2005. 920 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 921 for IPv6 Hosts and Routers", RFC 4213, October 2005. 923 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 924 RFC 4306, December 2005. 926 Authors' Addresses 928 John Loughney 929 Nokia 930 955 Page Mill Road 931 Palo Alto 94303 932 USA 934 Phone: +1 650 283 8068 935 Email: john.loughney@nokia.com 937 Thomas Narten 938 IBM Corporation 939 3039 Cornwallis Ave. 940 PO Box 12195 941 Research Triangle Park, NC 27709-2195 942 USA 944 Phone: +1 919 254 7798 945 Email: narten@us.ibm.com