idnits 2.17.1 draft-ietf-ipv6-node-requirements-11.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 961. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 35), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages 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 RFC 3978 Section 5.4 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 (August 23, 2004) is 7179 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) == Missing Reference: 'RFC-793' is mentioned on line 838, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'RFC-2464' is mentioned on line 850, but not defined == Missing Reference: 'RFC-2492' is mentioned on line 853, but not defined == Missing Reference: 'IPv6-RH' is mentioned on line 829, but not defined == Missing Reference: 'RFC-2675' is mentioned on line 856, but not defined == Missing Reference: 'RFC3569' is mentioned on line 395, but not defined == Missing Reference: 'MLDv1' is mentioned on line 391, but not defined == Missing Reference: 'SSMARCH' is mentioned on line 395, but not defined == Missing Reference: 'RFC-1034' is mentioned on line 841, but not defined == Missing Reference: 'DNSSEC-INTRO' is mentioned on line 812, but not defined == Missing Reference: 'DNSSEC-REC' is mentioned on line 816, but not defined == Missing Reference: 'DNSSEC-PROT' is mentioned on line 821, but not defined == Missing Reference: 'DHCPv6-SL' is mentioned on line 809, but not defined == Missing Reference: 'DESDIFF' is mentioned on line 795, but not defined == Missing Reference: 'DESINT' is mentioned on line 805, but not defined == Missing Reference: 'DESCRACK' is mentioned on line 802, but not defined == Missing Reference: 'IKEv2' is mentioned on line 569, but not defined == Missing Reference: 'RFC-2205' is mentioned on line 844, but not defined == Missing Reference: 'RFC-2411' is mentioned on line 628, but not defined ** Obsolete undefined reference: RFC 2411 (Obsoleted by RFC 6071) == Missing Reference: 'ANYCAST' is mentioned on line 791, but not defined == Missing Reference: 'IKE2' is mentioned on line 826, but not defined == Missing Reference: 'MC-THREAT' is mentioned on line 833, but not defined == Missing Reference: 'RFC-2851' is mentioned on line 859, but not defined ** Obsolete undefined reference: RFC 2851 (Obsoleted by RFC 3291) == Missing Reference: 'RFC-2893' is mentioned on line 863, but not defined ** Obsolete undefined reference: RFC 2893 (Obsoleted by RFC 4213) == Missing Reference: 'RFC-3569' is mentioned on line 866, but not defined == Missing Reference: 'SSM-ARCH' is mentioned on line 869, but not defined == Unused Reference: 'IKEv2ALGO' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC-2104' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC-2461' is defined on line 726, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-ipsec-esp-ah-algorithms-01 -- No information found for draft-ietf-ipsec- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IKEv2ALGO' ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) == Outdated reference: A later version (-10) exists of draft-ietf-ipv6-rfc2011-update-09 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2472 (Obsoleted by RFC 5072, RFC 5172) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3152 (Obsoleted by RFC 3596) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3363 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) Summary: 34 errors (**), 0 flaws (~~), 36 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Working Group John Loughney (ed) 2 Internet-Draft Nokia 3 August 23, 2004 5 Expires: February 22, 2005 7 IPv6 Node Requirements 8 draft-ietf-ipv6-node-requirements-11.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance 15 with RFC 3668. 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 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference 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 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document defines requirements for IPv6 nodes. It is expected 40 that IPv6 will be deployed in a wide range of devices and 41 situations. Specifying the requirements for IPv6 nodes allows IPv6 42 to function well and interoperate in a large number of situations 43 and deployments. 45 Internet-Draft 47 Table of Contents 49 1. Introduction 50 1.1 Requirement Language 51 1.2 Scope of this Document 52 1.3 Description of IPv6 Nodes 53 2. Abbreviations Used in This Document 54 3. Sub-IP Layer 55 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 56 3.2 IP version 6 over PPP - RFC2472 57 3.3 IPv6 over ATM Networks - RFC2492 58 4. IP Layer 59 4.1 Internet Protocol Version 6 - RFC2460 60 4.2 Neighbor Discovery for IPv6 - RFC2461 61 4.3 Path MTU Discovery & Packet Size 62 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 63 4.5 Addressing 64 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 65 5. DNS and DHCP 66 5.1 DNS 67 5.2 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 68 6. IPv4 Support and Transition 69 6.1 Transition Mechanisms 70 7. Mobility 71 8. Security 72 8.1 Basic Architecture 73 8.2 Security Protocols 74 8.3 Transforms and Algorithms 75 8.4 Key Management Methods 76 9. Router Functionality 77 9.1 General 78 10. Network Management 79 10.1 MIBs 80 11. Security Considerations 81 12. References 82 12.1 Normative 83 12.2 Non-Normative 84 13. Authors and Acknowledgements 85 14. Editor's Address 86 Notices 88 Internet-Draft 90 1. Introduction 92 The goal of this document is to define the common functionality 93 required from both IPv6 hosts and routers. Many IPv6 nodes will 94 implement optional or additional features, but this document 95 summarizes requirements from other published Standards Track 96 documents in one place. 98 This document tries to avoid discussion of protocol details, and 99 references RFCs for this purpose. This document is informational in 100 nature and does not update Standards Track RFCs. 102 Although the document points to different specifications, it should 103 be noted that in most cases, the granularity of requirements are 104 smaller than a single specification, as many specifications define 105 multiple, independent pieces, some of which may not be mandatory. 107 As it is not always possible for an implementer to know the exact 108 usage of IPv6 in a node, an overriding requirement for IPv6 nodes is 109 that they should adhere to Jon Postel's Robustness Principle: 111 Be conservative in what you do, be liberal in what you accept 112 from others [RFC-793]. 114 1.1 Requirement Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 118 this document are to be interpreted as described in RFC 2119 [RFC- 119 2119]. 121 1.2 Scope of this Document 123 IPv6 covers many specifications. It is intended that IPv6 will be 124 deployed in many different situations and environments. Therefore, 125 it is important to develop the requirements for IPv6 nodes, in order 126 to ensure interoperability. 128 This document assumes that all IPv6 nodes meet the minimum 129 requirements specified here. 131 1.3 Description of IPv6 Nodes 133 From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we 134 have the following definitions: 136 Description of an IPv6 Node 138 Internet-Draft 140 - a device that implements IPv6 142 Description of an IPv6 router 144 - a node that forwards IPv6 packets not explicitly addressed to 145 itself. 147 Description of an IPv6 Host 149 - any node that is not a router. 151 2. Abbreviations Used in This Document 153 ATM Asynchronous Transfer Mode 155 AH Authentication Header 157 DAD Duplicate Address Detection 159 ESP Encapsulating Security Payload 161 ICMP Internet Control Message Protocol 163 IKE Internet Key Exchange 165 MIB Management Information Base 167 MLD Multicast Listener Discovery 169 MTU Maximum Transfer Unit 171 NA Neighbor Advertisement 173 NBMA Non-Broadcast Multiple Access 175 ND Neighbor Discovery 177 NS Neighbor Solicitation 179 NUD Neighbor Unreachability Detection 181 PPP Point-to-Point Protocol 183 PVC Permanent Virtual Circuit 185 SVC Switched Virtual Circuit 187 3. Sub-IP Layer 189 Internet-Draft 191 An IPv6 node must include support for one or more IPv6 link-layer 192 specifications. Which link-layer specifications are included will 193 depend upon what link-layers are supported by the hardware available 194 on the system. It is possible for a conformant IPv6 node to support 195 IPv6 on some of its interfaces and not on others. 197 As IPv6 is run over new layer 2 technologies, it is expected that 198 new specifications will be issued. This section highlights some 199 major layer 2 technologies and is not intended to be complete. 201 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 203 Nodes supporting IPv6 over Ethernet interfaces MUST implement 204 Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. 206 3.2 IP version 6 over PPP - RFC2472 208 Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC- 209 2472]. 211 3.3 IPv6 over ATM Networks - RFC2492 213 Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM 214 Networks [RFC-2492]. Additionally, RFC 2492 states: 216 A minimally conforming IPv6/ATM driver SHALL support the PVC mode 217 of operation. An IPv6/ATM driver that supports the full SVC mode 218 SHALL also support PVC mode of operation. 220 4. IP Layer 222 4.1 Internet Protocol Version 6 - RFC2460 224 The Internet Protocol Version 6 is specified in [RFC-2460]. This 225 specification MUST be supported. 227 Unrecognized options in Hop-by-Hop Options or Destination Options 228 extensions MUST be processed as described in RFC 2460. 230 The node MUST follow the packet transmission rules in RFC 2460. 232 Nodes MUST always be able to send, receive and process fragment 233 headers. All conformant IPv6 implementations MUST be capable of 234 sending and receving IPv6 packets; forwarding functionality MAY be 235 supported 237 RFC 2460 specifies extension headers and the processing for these 238 headers. 240 Internet-Draft 242 A full implementation of IPv6 includes implementation of the 243 following extension headers: Hop-by-Hop Options, Routing (Type 244 0), Fragment, Destination Options, Authentication and 245 Encapsulating Security Payload. [RFC-2460] 247 An IPv6 node MUST be able to process these headers. It should be 248 noted that there is some discussion about the use of Routing Headers 249 and possible security threats [IPv6-RH] caused by them. 251 4.2 Neighbor Discovery for IPv6 - RFC2461 253 Neighbor Discovery SHOULD be supported. RFC 2461 states: 255 "Unless specified otherwise (in a document that covers operating 256 IP over a particular link type) this document applies to all link 257 types. However, because ND uses link-layer multicast for some of 258 its services, it is possible that on some link types (e.g., NBMA 259 links) alternative protocols or mechanisms to implement those 260 services will be specified (in the appropriate document covering 261 the operation of IP over a particular link type). The services 262 described in this document that are not directly dependent on 263 multicast, such as Redirects, Next-hop determination, Neighbor 264 Unreachability Detection, etc., are expected to be provided as 265 specified in this document. The details of how one uses ND on 266 NBMA links is an area for further study." 268 Some detailed analysis of Neighbor Discovery follows: 270 Router Discovery is how hosts locate routers that reside on an 271 attached link. Router Discovery MUST be supported for 272 implementations. 274 Prefix Discovery is how hosts discover the set of address prefixes 275 that define which destinations are on-link for an attached link. 276 Prefix discovery MUST be supported for implementations. Neighbor 277 Unreachability Detection (NUD) MUST be supported for all paths 278 between hosts and neighboring nodes. It is not required for paths 279 between routers. However, when a node receives a unicast Neighbor 280 Solicitation (NS) message (that may be a NUD's NS), the node MUST 281 respond to it (i.e. send a unicast Neighbor Advertisement). 283 Duplicate Address Detection MUST be supported on all links 284 supporting link-layer multicast (RFC2462 section 5.4 specifies DAD 285 MUST take place on all unicast addresses). 287 A host implementation MUST support sending Router Solicitations. 289 Receiving and processing Router Advertisements MUST be supported for 291 Internet-Draft 293 host implementations. The ability to understand specific Router 294 Advertisement options is dependent on supporting the specification 295 where the RA is specified. 297 Sending and Receiving Neighbor Solicitation (NS) and Neighbor 298 Advertisement (NA) MUST be supported. NS and NA messages are 299 required for Duplicate Address Detection (DAD). 301 Redirect functionality SHOULD be supported. If the node is a router, 302 Redirect functionality MUST be supported. 304 4.3 Path MTU Discovery & Packet Size 306 4.3.1 Path MTU Discovery - RFC1981 308 Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal 309 implementations MAY choose to not support it and avoid large 310 packets. The rules in RFC 2460 MUST be followed for packet 311 fragmentation and reassembly. 313 4.3.2 IPv6 Jumbograms - RFC2675 315 IPv6 Jumbograms [RFC-2675] MAY be supported. 317 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 319 ICMPv6 [RFC-2463] MUST be supported. 321 Addressing 323 4.5.1 IP Version 6 Addressing Architecture - RFC3513 325 The IPv6 Addressing Architecture [RFC-3513] MUST be supported as 326 updated by [DEP-SL]. 328 4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 330 IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. 331 This specification MUST be supported for nodes that are hosts. 332 Static address can be supported as well. 334 Nodes that are routers MUST be able to generate link local addresses 335 as described in RFC 2462 [RFC-2462]. 337 From 2462: 339 The autoconfiguration process specified in this document applies 340 only to hosts and not routers. Since host autoconfiguration uses 342 Internet-Draft 344 information advertised by routers, routers will need to be 345 configured by some other means. However, it is expected that 346 routers will generate link-local addresses using the mechanism 347 described in this document. In addition, routers are expected to 348 successfully pass the Duplicate Address Detection procedure 349 described in this document on all addresses prior to assigning 350 them to an interface. 352 Duplicate Address Detection (DAD) MUST be supported. 354 4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 356 Privacy Extensions for Stateless Address Autoconfiguration [RFC- 357 3041] SHOULD be supported. It is recommended that this behavior be 358 configurable on a connection basis within each application when 359 available. It is noted that a number of applications do not work 360 with addresses generated with this method, while other applications 361 work quite well with them. 363 4.5.4 Default Address Selection for IPv6 - RFC3484 365 The rules specified in the Default Address Selection for IPv6 [RFC- 366 3484] document MUST be implemented. It is expected that IPv6 nodes 367 will need to deal with multiple addresses. 369 4.5.5 Stateful Address Autoconfiguration 371 Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- 372 3315] is the standard stateful address configuration protocol; see 373 section 5.3 for DHCPv6 support. 375 Nodes which do not support Stateful Address Autoconfiguration may be 376 unable to obtain any IPv6 addresses aside from link-local addresses 377 when it receives a router advertisement with the 'M' flag (Managed 378 address configuration) set and which contains no prefixes advertised 379 for Stateless Address Autoconfiguration (see section 4.5.2). 380 Additionally, such nodes will be unable to obtain other 381 configuration information such as the addresses of DNS servers when 382 it is connected to a link over which the node receives a router 383 advertisement in which the 'O' flag ("Other stateful configuration") 384 is set. 386 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 388 Nodes that need to join multicast groups SHOULD implement MLDv2 389 [MLDv2]. However, if the node has applications, which only need 390 support for Any-Source Multicast [RFC3569], the node MAY implement 391 MLDv1 [MLDv1] instead. If the node has applications, which need 393 Internet-Draft 395 support for Source-Specific Multicast [RFC3569, SSMARCH], the node 396 MUST support MLDv2 [MLDv2]. 398 When MLD is used, the rules in "Source Address Selection for the 399 Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be 400 followed. 402 5. DNS and DHCP 404 5.1 DNS 406 DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] 407 and [RFC-3596]. Not all nodes will need to resolve names, and those 408 that will never need to resolve DNS names do not need to implement 409 resolver functionality. However, the ability to resolve names is a 410 basic infrastructure capability that applications rely on and 411 generally needs to be supported. All nodes that need to resolve 412 names SHOULD implement stub-resolver [RFC-1034] functionality, in 413 RFC 1034 section 5.3.1 with support for: 415 - AAAA type Resource Records [RFC-3596]; 416 - reverse addressing in ip6.arpa using PTR records [RFC-3152]; 417 - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 418 octets. 420 Those nodes are RECOMMENDED to support DNS security extentions 421 [DNSSEC-INTRO], [DNSSEC-REC] and [DNSSEC-PROT]. 423 Those nodes are NOT RECOMMENDED to support the experimental A6 and 424 DNAME Resource Records [RFC-3363]. 426 5.2 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 428 5.2.1 Managed Address Configuration 430 The method by which IPv6 Nodes that use DHCP for address assignment 431 can obtain IPv6 addresses and other configuration information upon 432 receipt of a Router Advertisement with the 'M' flag set is described 433 in section 5.5.3 of RFC 2462. 435 In addition, in the absence of a router, those IPv6 Nodes that use 436 DHCP for address assignment MUST initiate DHCP to obtain IPv6 437 addresses and other configuration information, as described in 438 section 5.5.2 of RFC 2462. Those IPv6 nodes that do not use DHCP 439 for address assignment can ignore the 'M' flag in Router 440 Advertisements. 442 5.2.2 Other Configuration Information 444 Internet-Draft 446 The method by which IPv6 Nodes that use DHCP to obtain other 447 configuration information can obtain other configuration information 448 upon receipt of a Router Advertisement with the 'O' flag set is 449 described in section 5.5.3 of RFC 2462. 451 Those IPv6 Nodes that use DHCP to obtain other configuration 452 information initiate DHCP for other configuration information upon 453 receipt of a Router Advertisement with the 'O' flag set, as 454 described in section 5.5.3 of RFC 2462. Those IPv6 nodes that do 455 not use DHCP for other configuration information can ignore the 'O' 456 flag in Router Advertisements. 458 An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to 459 obtain other configuration information. 461 5.3.3 Use of Router Advertisements in Managed Environments 463 Nodes using the Dynamic Host Configuration Protocol for IPv6 464 (DHCPv6) are expected to determine their default router information 465 and on-link prefix information from received Router Advertisements. 467 6. IPv4 Support and Transition 469 IPv6 nodes MAY support IPv4. 471 6.1 Transition Mechanisms 473 6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 475 If an IPv6 node implements dual stack and tunneling, then RFC2893 476 MUST be supported. 478 RFC 2893 is currently being updated. 480 7. Mobile IP 482 The Mobile IPv6 [MIPv6] specification defines requirements for the 483 following types of nodes: 485 - mobile nodes 486 - correspondent nodes with support for route optimization 487 - home agents 488 - all IPv6 routers 490 Hosts MAY support mobile node functionality described in Section 8.5 491 of [MIPv6], including support of generic packet tunneling [RFC-2473] 492 and secure home agent communications [MIPv6-HASEC]. 494 Internet-Draft 496 Hosts SHOULD support route optimization requirements for 497 correspondent nodes described in Section 8.2 of [MIPv6]. 499 Routers SHOULD support the generic mobility-related requirements for 500 all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY 501 support the home agent functionality described in Section 8.4 of 502 [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC]. 504 8. Security 506 This section describes the specification of IPsec for the IPv6 node. 508 8.1 Basic Architecture 510 Security Architecture for the Internet Protocol [RFC-2401] MUST be 511 supported. RFC-2401 is being updated by the IPsec Working Group. 513 8.2 Security Protocols 515 ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. 516 RFC-2406 and RFC 2402 are being updated by the IPsec Working Group. 518 8.3 Transforms and Algorithms 520 Current IPsec RFCs specify the support of transforms and algorithms 521 for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, 522 and HMAC-MD5-96. However, "Cryptographic Algorithm Implementation 523 Requirements For ESP And AH" [CRYPTREQ] contains the current set of 524 mandatory to implement algorithms for ESP and AH. It also specifies 525 algorithms that should be implemented because they are likely to be 526 promoted to mandatory at some future time. IPv6 nodes SHOULD 527 conform to the requirements in [CRYPTREQ] as well as the 528 requirements specified below. 530 Since ESP encryption and authentication are both optional, support 531 for the NULL encryption algorithm [RFC-2410] and the NULL 532 authentication algorithm [RFC-2406] MUST be provided to maintain 533 consistency with the way these services are negotiated. However, 534 while authentication and encryption can each be NULL, they MUST NOT 535 both be NULL. The NULL encryption algorithm is also useful for 536 debugging. 538 The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported 539 within ESP. Security issues related to the use of DES are discussed 540 in [DESDIFF], [DESINT], [DESCRACK]. DES-CBC is still listed as 541 required by the existing IPsec RFCs, but updates to these RFCs will 542 be published soon. DES provides 56 bits of protection, which is no 544 Internet-Draft 546 longer considered sufficient. 548 The use of HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP MUST 549 be supported. The use of HMAC-MD5-96 algorithm [RFC-2403] within AH 550 and ESP MAY also be supported. 552 The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from 553 the same security issues as DES-CBC, and the 3DES-CBC algorithm 554 within ESP MUST be supported to ensure interoperability. 556 The AES-128-CBC algorithm [RFC-3602] MUST also be supported within 557 ESP. AES-128 is expected to be a widely available, secure, and 558 efficient algorithm. While AES-128-CBC is not required by the 559 current IPsec RFCs, it is expected to become required in the future. 561 8.4 Key Management Methods 563 An implementation MUST support the manual configuration of the 564 security key and SPI. The SPI configuration is needed in order to 565 delineate between multiple keys. 567 Key management SHOULD be supported. Examples of key management 568 systems include IKEv1 [RFC-2407] [RFC-2408] [RFC-2409], IKEv2 569 [IKEv2] and Kerberos; S/MIME and TLS include key management 570 functions. 572 Where key refresh, anti-replay features of AH and ESP, or on-demand 573 creation of Security Associations (SAs) is required, automated 574 keying MUST be supported. 576 Key management methods for multicast traffic are also being worked 577 on by the MSEC WG. 579 9. Router-Specific Functionality 581 This section defines general host considerations for IPv6 nodes that 582 act as routers. Currently, this section does not discuss routing- 583 specific requirements. 585 9.1 General 587 9.1.1 IPv6 Router Alert Option - RFC2711 589 The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- 590 Hop Header that is used in conjunction with some protocols (e.g., 591 RSVP [RFC-2205], or MLD [RFC-2710]). The Router Alert option will 592 need to be implemented whenever protocols that mandate its usage are 593 implemented. See Section 4.6. 595 Internet-Draft 597 9.1.2 Neighbor Discovery for IPv6 - RFC2461 599 Sending Router Advertisements and processing Router Solicitation 600 MUST be supported. 602 10. Network Management 604 Network Management MAY be supported by IPv6 nodes. However, for 605 IPv6 nodes that are embedded devices, network management may be the 606 only possibility to control these nodes. 608 10.1 Management Information Base Modules (MIBs) 610 The following two MIBs SHOULD be supported by nodes that support an 611 SNMP agent. 613 10.1.1 IP Forwarding Table MIB 615 IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes 616 that support an SNMP agent. 618 10.1.2 Management Information Base for the Internet Protocol (IP) 620 IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an 621 SNMP agent. 623 11. Security Considerations 625 This draft does not affect the security of the Internet, but 626 implementations of IPv6 are expected to support a minimum set of 627 security features to ensure security on the Internet. "IP Security 628 Document Roadmap" [RFC-2411] is important for everyone to read. 630 The security considerations in RFC2460 describe the following: 632 The security features of IPv6 are described in the Security 633 Architecture for the Internet Protocol [RFC-2401]. 635 12. References 637 12.1 Normative 639 [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa- 640 tion Requirements For ESP And AH", draft-ietf-ipsec- 641 esp-ah-algorithms-01.txt, January 2004. 643 [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the 644 Internet Key Exchange Version 2", draft-ietf-ipsec- 646 Internet-Draft 648 ikev2-algorithms-05.txt, Work in Progress. 650 [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Sup- 651 port in IPv6", draft-ietf-mobileip-ipv6-24.txt, Work 652 in progress. 654 [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec 655 to Protect Mobile IPv6 Signaling between Mobile Nodes 656 and Home Agents", draft-ietf-mobileip-mipv6-ha- 657 ipsec-06.txt, Work in Progress. 659 [MLDv2] Vida, R. et al., "Multicast Listener Discovery Ver- 660 sion 2 (MLDv2) for IPv6", draft-vida-mld-v2-08.txt, 661 Work in Progress. 663 [RFC-1035] Mockapetris, P., "Domain names - implementation and 664 specification", STD 13, RFC 1035, November 1987. 666 [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU 667 Discovery for IP version 6", RFC 1981, August 1996. 669 [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table 670 MIB", draft-ietf-ipv6-rfc2096-update-07.txt, Work in 671 Progress. 673 [RFC-2011BIS] Routhier, S (ed), "Management Information Base for 674 the Internet Protocol (IP)", draft-ietf-ipv6- 675 rfc2011-update-09.txt, Work in progress. 677 [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: 678 Keyed-Hashing for Message Authentication", RFC 2104, 679 February 1997. 681 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, March 1997. 684 [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for 685 the Internet Protocol", RFC 2401, November 1998. 687 [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication 688 Header", RFC 2402, November 1998. 690 [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 691 within ESP and AH", RFC 2403, November 1998. 693 [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 694 within ESP and AH", RFC 2404, November 1998. 696 Internet-Draft 698 [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher 699 Algorithm With Explicit IV", RFC 2405, November 1998. 701 [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security 702 Protocol (ESP)", RFC 2406, November 1998. 704 [RFC-2407] Piper, D., "The Internet IP Security Domain of 705 Interpretation for ISAKMP", RFC 2407, November 1998. 707 [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and 708 Turner, J., "Internet Security Association and Key 709 Management Protocol (ISAKMP)", RFC 2408, November 710 1998. 712 [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key 713 Exchange (IKE)", RFC 2409, November 1998. 715 [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algo- 716 rithm and Its Use With IPsec", RFC 2410, November 717 1998. 719 [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher 720 Algorithms", RFC 2451, November 1998. 722 [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver- 723 sion 6 (IPv6) Specification", RFC 2460, December 724 1998. 726 [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor 727 Discovery for IP Version 6 (IPv6)", RFC 2461, 728 December 1998. 730 [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address 731 Autoconfiguration", RFC 2462. 733 [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet 734 Protocol Version 6 (IPv6)", RFC 2463, December 1998. 736 [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", 737 RFC 2472, December 1998. 739 [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling 740 in IPv6 Specification", RFC 2473, December 1998. Xxx 741 add 743 [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 744 RFC 2671, August 1999. 746 Internet-Draft 748 [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast 749 Listener Discovery (MLD) for IPv6", RFC 2710, October 750 1999. 752 [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert 753 Option", RFC 2711, October 1999. 755 [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for 756 Stateless Address Autoconfiguration in IPv6", RFC 757 3041, January 2001. 759 [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August 760 2001. 762 [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Proto- 763 col for IPv6 (DHCPv6)", RFC 3315, July 2003. 765 [RFC-3363] Bush, R., et al., "Representing Internet Protocol 766 version 6 (IPv6) Addresses in the Domain Name System 767 (DNS)", RFC 3363, August 2002. 769 [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC 770 3484, February 2003. 772 [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing 773 Architecture", RFC 3513, April 2003. 775 [RFC-3590] Haberman, B., "Source Address Selection for the Mul- 776 ticast Listener Discovery (MLD) Protocol", RFC 3590, 777 September 2003. 779 [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP 780 version 6", RFC 3596, October 2003. 782 [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use 783 with IPsec", RFC 3602, September 2003. 785 [DEP-SL] C. Huitema, B. Carpenter, "Deprecating Site Local 786 Addresses", draft-ietf-ipv6-deprecate-site-local- 787 03.txt, Work in Progress. 789 12.2 Non-Normative 791 [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast", 792 draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt, Work in 793 Progress. 795 [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of 797 Internet-Draft 799 DES-like cryptosystems", Journal of Cryptology Vol 4, 800 Jan 1991. 802 [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 803 2000. 805 [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without 806 Strong Integrity", Proceedings of the 32nd IETF, 807 Danvers, MA, April 1995. 809 [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6 Ser- 810 vice", RFC 3736, April 2004. 812 [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and 813 Rose, S., "DNS Security Introduction and Requirements" 814 draft-ietf-dnsext-dnssec-intro-10.txt, Work in Progress. 816 [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and 817 Rose, S., "Resource Records for the DNS Security Exten- 818 sions", draft-ietf-dnsext-dnssec-records-08.txt, Work in 819 Progress. 821 [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and 822 Rose, S., "Protocol Modifications for the DNS Security 823 Extensions", draft-ietf-dnsext-dnssec-protocol-06.txt, 824 Work in Progress. 826 [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto- 827 col", draft-ietf-ipsec-ikev2-13.txt, Work in Progress. 829 [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home 830 Address Options", draft-savola-ipv6-rh-ha-security- 831 03.txt, Work in Progress. 833 [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu- 834 rity Threats and Counter-Measures; In Proceedings "Sym- 835 posium on Network and Distributed System Security", 836 February 1995, pp.2-16. 838 [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793, 839 August 1980. 841 [RFC-1034] Mockapetris, P., "Domain names - concepts and facili- 842 ties", RFC 1034, November 1987. 844 [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and 845 S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC 846 2205, September 1997. 848 Internet-Draft 850 [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ether- 851 net Networks", RFC 2462, December 1998. 853 [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over 854 ATM Networks", RFC 2492, January 1999. 856 [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6 Jumbo- 857 grams", RFC 2675, August 1999. 859 [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder, 860 "Textual Conventions for Internet Network Addresses", 861 RFC 2851, June 2000. 863 [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms 864 for IPv6 Hosts and Routers", RFC 2893, August 2000. 866 [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific 867 Multicast (SSM)", RFC 3569, July 2003. 869 [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for 870 IP", draft-ietf-ssm-arch-04.txt, Work in Progress. 872 13. Authors and Acknowledgements 874 This document was written by the IPv6 Node Requirements design team: 876 Jari Arkko 877 [jari.arkko@ericsson.com] 879 Marc Blanchet 880 [marc.blanchet@viagenie.qc.ca] 882 Samita Chakrabarti 883 [samita.chakrabarti@eng.sun.com] 885 Alain Durand 886 [alain.durand@sun.com] 888 Gerard Gastaud 889 [gerard.gastaud@alcatel.fr] 891 Jun-ichiro itojun Hagino 892 [itojun@iijlab.net] 894 Atsushi Inoue 895 [inoue@isl.rdc.toshiba.co.jp] 897 Masahiro Ishiyama 899 Internet-Draft 901 [masahiro@isl.rdc.toshiba.co.jp] 903 John Loughney 904 [john.loughney@nokia.com] 906 Rajiv Raghunarayan 907 [raraghun@cisco.com] 909 Shoichi Sakane 910 [shouichi.sakane@jp.yokogawa.com] 912 Dave Thaler 913 [dthaler@windows.microsoft.com] 915 Juha Wiljakka 916 [juha.wiljakka@Nokia.com] 918 The authors would like to thank Ran Atkinson, Jim Bound, Brian Car- 919 penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Nar- 920 ten, Juha Ollila and Pekka Savola for their comments. 922 14. Editor's Contact Information 924 Comments or questions regarding this document should be sent to the 925 IPv6 Working Group mailing list (ipv6@ietf.org) or to: 927 John Loughney 928 Nokia Research Center 929 Itamerenkatu 11-13 930 00180 Helsinki 931 Finland 933 Phone: +358 50 483 6242 934 Email: John.Loughney@Nokia.com 936 Notices 938 The IETF takes no position regarding the validity or scope of any 939 Intellectual Property Rights or other rights that might be claimed 940 to pertain to the implementation or use of the technology described 941 in this document or the extent to which any license under such 942 rights might or might not be available; nor does it represent that 943 it has made any independent effort to identify any such rights. 944 Information on the procedures with respect to rights in RFC docu- 945 ments can be found in BCP 78 and BCP 79. 947 Copies of IPR disclosures made to the IETF Secretariat and any 948 assurances of licenses to be made available, or the result of an 950 Internet-Draft 952 attempt made to obtain a general license or permission for the use 953 of such proprietary rights by implementers or users of this specifi- 954 cation can be obtained from the IETF on-line IPR repository at 955 http://www.ietf.org/ipr. 957 The IETF invites any interested party to bring to its attention any 958 copyrights, patents or patent applications, or other proprietary 959 rights that may cover technology that may be required to implement 960 this standard. Please address the information to the IETF at ietf- 961 ipr@ietf.org. 963 Acknowledgement 965 Funding for the RFC Editor function is currently provided by the 966 Internet Society.