idnits 2.17.1 draft-ietf-ipv6-node-requirements-10.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 3978, Section 5.5 on line 992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 976. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 982. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 998), 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. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** 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 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 20 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 21 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 12, 2004) is 7198 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 855, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'RFC-2464' is mentioned on line 865, but not defined == Missing Reference: 'RFC-2492' is mentioned on line 868, but not defined == Missing Reference: 'IPv6-RH' is mentioned on line 843, but not defined == Missing Reference: 'RFC-2675' is mentioned on line 871, but not defined == Missing Reference: 'RFC3569' is mentioned on line 392, but not defined == Missing Reference: 'MLDv1' is mentioned on line 391, but not defined == Missing Reference: 'SSMARCH' is mentioned on line 392, but not defined == Missing Reference: 'RFC-2474' is mentioned on line 405, but not defined == Missing Reference: 'RFC-3168' is mentioned on line 881, but not defined == Missing Reference: 'RFC-3697' is mentioned on line 888, but not defined ** Obsolete undefined reference: RFC 3697 (Obsoleted by RFC 6437) == Missing Reference: 'RFC-1034' is mentioned on line 858, but not defined == Missing Reference: 'DNSSEC-INTRO' is mentioned on line 826, but not defined == Missing Reference: 'DNSSEC-REC' is mentioned on line 830, but not defined == Missing Reference: 'DNSSEC-PROT' is mentioned on line 835, but not defined == Missing Reference: 'DHCPv6-SL' is mentioned on line 823, but not defined == Missing Reference: 'DESDIFF' is mentioned on line 812, but not defined == Missing Reference: 'DESINT' is mentioned on line 819, but not defined == Missing Reference: 'DESCRACK' is mentioned on line 816, but not defined == Missing Reference: 'IKEv2' is mentioned on line 584, but not defined == Missing Reference: 'RFC-2205' is mentioned on line 861, but not defined == Missing Reference: 'RFC-2411' is mentioned on line 643, but not defined ** Obsolete undefined reference: RFC 2411 (Obsoleted by RFC 6071) == Missing Reference: 'ANYCAST' is mentioned on line 808, but not defined == Missing Reference: 'IKE2' is mentioned on line 840, but not defined == Missing Reference: 'MC-THREAT' is mentioned on line 847, but not defined == Missing Reference: 'RFC-2851' is mentioned on line 874, but not defined ** Obsolete undefined reference: RFC 2851 (Obsoleted by RFC 3291) == Missing Reference: 'RFC-2893' is mentioned on line 878, but not defined ** Obsolete undefined reference: RFC 2893 (Obsoleted by RFC 4213) == Missing Reference: 'RFC-3569' is mentioned on line 885, but not defined == Missing Reference: 'SSM-ARCH' is mentioned on line 891, but not defined == Unused Reference: 'IKEv2ALGO' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC-2104' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'RFC-2461' is defined on line 740, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-ipsec-esp-ah-algorithms-01 ** 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: 33 errors (**), 0 flaws (~~), 39 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 12, 2004 5 Expires: February 12, 2005 7 IPv6 Node Requirements 8 draft-ietf-ipv6-node-requirements-10.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 all IPv6 nodes can be 95 expected to implement the mandatory requirements listed in this 96 document. 98 This document tries to avoid discussion of protocol details, and 99 references RFCs for this purpose. In case of any conflicting text, 100 this document takes less precedence than the normative RFCs, unless 101 additional clarifying text is included in this document. 103 Although the document points to different specifications, it should 104 be noted that in most cases, the granularity of requirements are 105 smaller than a single specification, as many specifications define 106 multiple, independent pieces, some of which may not be mandatory. 108 As it is not always possible for an implementer to know the exact 109 usage of IPv6 in a node, an overriding requirement for IPv6 nodes is 110 that they should adhere to Jon Postel's Robustness Principle: 112 Be conservative in what you do, be liberal in what you accept 113 from others [RFC-793]. 115 1.1 Requirement Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 119 this document are to be interpreted as described in RFC 2119 [RFC- 120 2119]. 122 1.2 Scope of this Document 124 IPv6 covers many specifications. It is intended that IPv6 will be 125 deployed in many different situations and environments. Therefore, 126 it is important to develop the requirements for IPv6 nodes, in order 127 to ensure interoperability. 129 This document assumes that all IPv6 nodes meet the minimum 130 requirements specified here. 132 1.3 Description of IPv6 Nodes 134 From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we 135 have the following definitions: 137 Description of an IPv6 Node 139 Internet-Draft 141 - a device that implements IPv6 143 Description of an IPv6 router 145 - a node that forwards IPv6 packets not explicitly addressed to 146 itself. 148 Description of an IPv6 Host 150 - any node that is not a router. 152 2. Abbreviations Used in This Document 154 ATM Asynchronous Transfer Mode 156 AH Authentication Header 158 DAD Duplicate Address Detection 160 ESP Encapsulating Security Payload 162 ICMP Internet Control Message Protocol 164 IKE Internet Key Exchange 166 MIB Management Information Base 168 MLD Multicast Listener Discovery 170 MTU Maximum Transfer Unit 172 NA Neighbor Advertisement 174 NBMA Non-Broadcast Multiple Access 176 ND Neighbor Discovery 178 NS Neighbor Solicitation 180 NUD Neighbor Unreachability Detection 182 PPP Point-to-Point Protocol 184 PVC Permanent Virtual Circuit 186 SVC Switched Virtual Circuit 188 3. Sub-IP Layer 190 Internet-Draft 192 An IPv6 node must include support for one or more IPv6 link-layer 193 specifications. Which link-layer specifications are included will 194 depend upon what link-layers are supported by the hardware available 195 on the system. It is possible for a conformant IPv6 node to support 196 IPv6 on some of its interfaces and not on others. 198 As IPv6 is run over new layer 2 technologies, it is expected that 199 new specifications will be issued. This section highlights some 200 major layer 2 technologies and is not intended to be complete. 202 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 204 Nodes supporting IPv6 over Ethernet interfaces MUST implement 205 Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. 207 3.2 IP version 6 over PPP - RFC2472 209 Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC- 210 2472]. 212 3.3 IPv6 over ATM Networks - RFC2492 214 Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM 215 Networks [RFC-2492]. Additionally, RFC 2492 states: 217 A minimally conforming IPv6/ATM driver SHALL support the PVC mode 218 of operation. An IPv6/ATM driver that supports the full SVC mode 219 SHALL also support PVC mode of operation. 221 4. IP Layer 223 4.1 Internet Protocol Version 6 - RFC2460 225 The Internet Protocol Version 6 is specified in [RFC-2460]. This 226 specification MUST be supported. 228 Unrecognized options in Hop-by-Hop Options or Destination Options 229 extensions MUST be processed as described in RFC 2460. 231 The node MUST follow the packet transmission rules in RFC 2460. 233 Nodes MUST always be able to send, receive and process fragment 234 headers. All conformant IPv6 implementations MUST be capable of 235 sending and receving IPv6 packets; forwarding functionality MAY be 236 supported 238 RFC 2460 specifies extension headers and the processing for these 239 headers. 241 Internet-Draft 243 A full implementation of IPv6 includes implementation of the 244 following extension headers: Hop-by-Hop Options, Routing (Type 245 0), Fragment, Destination Options, Authentication and 246 Encapsulating Security Payload. [RFC-2460] 248 An IPv6 node MUST be able to process these headers. It should be 249 noted that there is some discussion about the use of Routing Headers 250 and possible security threats [IPv6-RH] caused by them. 252 4.2 Neighbor Discovery for IPv6 - RFC2461 254 Neighbor Discovery SHOULD be supported. RFC 2461 states: 256 "Unless specified otherwise (in a document that covers operating 257 IP over a particular link type) this document applies to all link 258 types. However, because ND uses link-layer multicast for some of 259 its services, it is possible that on some link types (e.g., NBMA 260 links) alternative protocols or mechanisms to implement those 261 services will be specified (in the appropriate document covering 262 the operation of IP over a particular link type). The services 263 described in this document that are not directly dependent on 264 multicast, such as Redirects, Next-hop determination, Neighbor 265 Unreachability Detection, etc., are expected to be provided as 266 specified in this document. The details of how one uses ND on 267 NBMA links is an area for further study." 269 Some detailed analysis of Neighbor Discovery follows: 271 Router Discovery is how hosts locate routers that reside on an 272 attached link. Router Discovery MUST be supported for 273 implementations. 275 Prefix Discovery is how hosts discover the set of address prefixes 276 that define which destinations are on-link for an attached link. 277 Prefix discovery MUST be supported for implementations. Neighbor 278 Unreachability Detection (NUD) MUST be supported for all paths 279 between hosts and neighboring nodes. It is not required for paths 280 between routers. However, when a node receives a unicast Neighbor 281 Solicitation (NS) message (that may be a NUD's NS), the node MUST 282 respond to it (i.e. send a unicast Neighbor Advertisement). 284 Duplicate Address Detection MUST be supported on all links 285 supporting link-layer multicast (RFC2462 section 5.4 specifies DAD 286 MUST take place on all unicast addresses). 288 A host implementation MUST support sending Router Solicitations. 290 Receiving and processing Router Advertisements MUST be supported for 292 Internet-Draft 294 host implementations. The ability to understand specific Router 295 Advertisement options is dependent on supporting the specification 296 where the RA is specified. 298 Sending and Receiving Neighbor Solicitation (NS) and Neighbor 299 Advertisement (NA) MUST be supported. NS and NA messages are 300 required for Duplicate Address Detection (DAD). 302 Redirect functionality SHOULD be supported. If the node is a router, 303 Redirect functionality MUST be supported. 305 4.3 Path MTU Discovery & Packet Size 307 4.3.1 Path MTU Discovery - RFC1981 309 Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal 310 implementations MAY choose to not support it and avoid large 311 packets. The rules in RFC 2460 MUST be followed for packet 312 fragmentation and reassembly. 314 4.3.2 IPv6 Jumbograms - RFC2675 316 IPv6 Jumbograms [RFC-2675] MAY be supported. 318 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 320 ICMPv6 [RFC-2463] MUST be supported. 322 4.5 Addressing 324 4.5.1 IP Version 6 Addressing Architecture - RFC3513 326 The IPv6 Addressing Architecture [RFC-3513] MUST be supported as 327 updated by [DEP-SL]. 329 4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 331 IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. 332 This specification MUST be supported for nodes that are hosts. 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 341 information advertised by routers, routers will need to be 343 Internet-Draft 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 392 support for Source-Specific Multicast [RFC3569, SSMARCH], the node 394 Internet-Draft 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 4.7 Special header fields 404 If a node supports the Traffic Class field, it MUST do so in 405 accordance with [RFC-2474], [RFC-3168], or both. Hosts that do not 406 support this field MUST set it to zero when sending packets. Routers 407 that do not support this field MUST NOT change its value when 408 forwarding packets. 410 If a node supports the Flow Label field, it MUST do so in accordance 411 with [RFC-3697]. Hosts that do not support this field MUST set it to 412 zero when sending packets. Routers that do not support this field 413 MUST NOT change its value when forwarding packets. 415 5. DNS and DHCP 417 5.1 DNS 419 DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] 420 and [RFC-3596]. Not all nodes will need to resolve names, and those 421 that will never need to resolve DNS names do not need to implement 422 resolver functionality. However, the ability to resolve names is a 423 basic infrastructure capability that applications rely on and 424 generally needs to be supported. All nodes that need to resolve 425 names SHOULD implement stub-resolver [RFC-1034] functionality, in 426 RFC 1034 section 5.3.1 with support for: 428 - AAAA type Resource Records [RFC-3596]; 429 - reverse addressing in ip6.arpa using PTR records [RFC-3152]; 430 - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 431 octets. 433 Those nodes are RECOMMENDED to support DNS security extentions 434 [DNSSEC-INTRO], [DNSSEC-REC] and [DNSSEC-PROT]. 436 Those nodes are NOT RECOMMENDED to support the experimental A6 and 437 DNAME Resource Records [RFC-3363]. 439 5.2 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 441 5.2.1 Managed Address Configuration 443 The method by which IPv6 Nodes that use DHCP for address assignment 445 Internet-Draft 447 can obtain IPv6 addresses and other configuration information upon 448 receipt of a Router Advertisement with the 'M' flag set is described 449 in section 5.5.3 of RFC 2462. 451 In addition, in the absence of a router, those IPv6 Nodes that use 452 DHCP for address assignment MUST initiate DHCP to obtain IPv6 453 addresses and other configuration information, as described in 454 section 5.5.2 of RFC 2462. Those IPv6 nodes that do not use DHCP 455 for address assignment can ignore the 'M' flag in Router 456 Advertisements. 458 5.2.2 Other Configuration Information 460 The method by which IPv6 Nodes that use DHCP to obtain other 461 configuration information can obtain other configuration information 462 upon receipt of a Router Advertisement with the 'O' flag set is 463 described in section 5.5.3 of RFC 2462. 465 Those IPv6 Nodes that use DHCP to obtain other configuration 466 information initiate DHCP for other configuration information upon 467 receipt of a Router Advertisement with the 'O' flag set, as 468 described in section 5.5.3 of RFC 2462. Those IPv6 nodes that do 469 not use DHCP for other configuration information can ignore the 'O' 470 flag in Router Advertisements. 472 An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to 473 obtain other configuration information. 475 5.3.3 Use of Router Advertisements in Managed Environments 477 Nodes using the Dynamic Host Configuration Protocol for IPv6 478 (DHCPv6) are expected to determine their default router information 479 and on-link prefix information from received Router Advertisements. 481 6. IPv4 Support and Transition 483 IPv6 nodes MAY support IPv4. 485 6.1 Transition Mechanisms 487 6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 489 If an IPv6 node implements dual stack and tunneling, then RFC2893 490 MUST be supported. 492 RFC 2893 is currently being updated. 494 7. Mobile IP 496 Internet-Draft 498 The Mobile IPv6 [MIPv6] specification defines requirements for the 499 following types of nodes: 501 - mobile nodes 502 - correspondent nodes with support for route optimization 503 - home agents 504 - all IPv6 routers 506 Hosts MAY support mobile node functionality described in Section 8.5 507 of [MIPv6], including support of generic packet tunneling [RFC-2473] 508 and secure home agent communications [MIPv6-HASEC]. 510 Hosts SHOULD support route optimization requirements for 511 correspondent nodes described in Section 8.2 of [MIPv6]. 513 Routers SHOULD support the generic mobility-related requirements for 514 all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY 515 support the home agent functionality described in Section 8.4 of 516 [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC]. 518 8. Security 520 This section describes the specification of IPsec for the IPv6 node. 522 8.1 Basic Architecture 524 Security Architecture for the Internet Protocol [RFC-2401] MUST be 525 supported. RFC-2401 is being updated by the IPsec Working Group. 527 8.2 Security Protocols 529 ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. 530 RFC-2406 and RFC 2402 are being updated by the IPsec Working Group. 532 8.3 Transforms and Algorithms 534 Current IPsec RFCs specify the support of transforms and algorithms 535 for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, 536 and HMAC-MD5-96. However, "Cryptographic Algorithm Implementation 537 Requirements For ESP And AH" [CRYPTREQ] contains the current set of 538 mandatory to implement algorithms for ESP and AH. It also specifies 539 algorithms that should be implemented because they are likely to be 540 promoted to mandatory at some future time. IPv6 nodes SHOULD 541 conform to the requirements in [CRYPTREQ] as well as the 542 requirements specified below. 544 Since ESP encryption and authentication are both optional, support 546 Internet-Draft 548 for the NULL encryption algorithm [RFC-2410] and the NULL 549 authentication algorithm [RFC-2406] MUST be provided to maintain 550 consistency with the way these services are negotiated. However, 551 while authentication and encryption can each be NULL, they MUST NOT 552 both be NULL. The NULL encryption algorithm is also useful for 553 debugging. 555 The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported 556 within ESP. Security issues related to the use of DES are discussed 557 in [DESDIFF], [DESINT], [DESCRACK]. DES-CBC is still listed as 558 required by the existing IPsec RFCs, but updates to these RFCs will 559 be published soon. DES provides 56 bits of protection, which is no 560 longer considered sufficient. 562 The use of HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP MUST 563 be supported. The use of HMAC-MD5-96 algorithm [RFC-2403] within AH 564 and ESP MAY also be supported. 566 The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from 567 the same security issues as DES-CBC, and the 3DES-CBC algorithm 568 within ESP MUST be supported to ensure interoperability. 570 The AES-128-CBC algorithm [RFC-3602] MUST also be supported 571 within 572 ESP. AES-128 is expected to be a widely available, secure, and 573 efficient algorithm. While AES-128-CBC is not required by the 574 current IPsec RFCs, it is expected to become required in the 575 future. 576 8.4 Key Management Methods 578 An implementation MUST support the manual configuration of the 579 security key and SPI. The SPI configuration is needed in order to 580 delineate between multiple keys. 582 Key management SHOULD be supported. Examples of key management 583 systems include IKEv1 [RFC-2407] [RFC-2408] [RFC-2409], IKEv2 584 [IKEv2] and Kerberos; S/MIME and TLS include key management 585 functions. 587 Where key refresh, anti-replay features of AH and ESP, or on-demand 588 creation of Security Associations (SAs) is required, 589 automated keying MUST be supported. 591 Key management methods for multicast traffic are also being worked 592 on by the MSEC WG. 594 9. Router-Specific Functionality 596 Internet-Draft 598 This section defines general host considerations for IPv6 nodes that 599 act as routers. Currently, this section does not discuss routing- 600 specific requirements. 602 9.1 General 604 9.1.1 IPv6 Router Alert Option - RFC2711 606 The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- 607 Hop Header that is used in conjunction with some protocols (e.g., 608 RSVP [RFC-2205], or MLD [RFC-2710]). The Router Alert option will 609 need to be implemented whenever protocols that mandate its usage are 610 implemented. See Section 4.6. 612 9.1.2 Neighbor Discovery for IPv6 - RFC2461 614 Sending Router Advertisements and processing Router Solicitation 615 MUST be supported. 617 10. Network Management 619 Network Management MAY be supported by IPv6 nodes. However, for 620 IPv6 nodes that are embedded devices, network management may be the 621 only possibility to control these nodes. 623 10.1 Management Information Base Modules (MIBs) 625 The following two MIBs SHOULD be supported by nodes that support an 626 SNMP agent. 628 10.1.1 IP Forwarding Table MIB 630 IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes 631 that support an SNMP agent. 633 10.1.2 Management Information Base for the Internet Protocol (IP) 635 IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an 636 SNMP agent. 638 11. Security Considerations 640 This draft does not affect the security of the Internet, but 641 implementations of IPv6 are expected to support a minimum set of 642 security features to ensure security on the Internet. "IP Security 643 Document Roadmap" [RFC-2411] is important for everyone to read. 645 The security considerations in RFC2460 describe the following: 647 Internet-Draft 649 The security features of IPv6 are described in the Security 650 Architecture for the Internet Protocol [RFC-2401]. 652 12. References 654 12.1 Normative 656 [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa- 657 tion Requirements For ESP And AH", draft-ietf-ipsec- 658 esp-ah-algorithms-01.txt, January 2004. 660 [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the 661 Internet Key Exchange Version 2", draft-ietf-ipsec- 662 ikev2-algorithms-05.txt, Work in Progress. 664 [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Sup- 665 port in IPv6", draft-ietf-mobileip-ipv6-24.txt, Work 666 in progress. 668 [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec 669 to Protect Mobile IPv6 Signaling between Mobile Nodes 670 and Home Agents", draft-ietf-mobileip-mipv6-ha- 671 ipsec-06.txt, Work in Progress. 673 [MLDv2] Vida, R. et al., "Multicast Listener Discovery Ver- 674 sion 2 (MLDv2) for IPv6", draft-vida-mld-v2-08.txt, 675 Work in Progress. 677 [RFC-1035] Mockapetris, P., "Domain names - implementation and 678 specification", STD 13, RFC 1035, November 1987. 680 [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU 681 Discovery for IP version 6", RFC 1981, August 1996. 683 [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table 684 MIB", draft-ietf-ipv6-rfc2096-update-07.txt, Work in 685 Progress. 687 [RFC-2011BIS] Routhier, S (ed), "Management Information Base for 688 the Internet Protocol (IP)", draft-ietf-ipv6- 689 rfc2011-update-09.txt, Work in progress. 691 [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: 692 Keyed-Hashing for Message Authentication", RFC 2104, 693 February 1997. 695 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, March 1997. 698 Internet-Draft 700 [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for 701 the Internet Protocol", RFC 2401, November 1998. 703 [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication 704 Header", RFC 2402, November 1998. 706 [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 707 within ESP and AH", RFC 2403, November 1998. 709 [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 710 within ESP and AH", RFC 2404, November 1998. 712 [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher 713 Algorithm With Explicit IV", RFC 2405, November 1998. 715 [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security 716 Protocol (ESP)", RFC 2406, November 1998. 718 [RFC-2407] Piper, D., "The Internet IP Security Domain of 719 Interpretation for ISAKMP", RFC 2407, November 1998. 721 [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and 722 Turner, J., "Internet Security Association and Key 723 Management Protocol (ISAKMP)", RFC 2408, November 724 1998. 726 [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key 727 Exchange (IKE)", RFC 2409, November 1998. 729 [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algo- 730 rithm and Its Use With IPsec", RFC 2410, November 731 1998. 733 [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher 734 Algorithms", RFC 2451, November 1998. 736 [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver- 737 sion 6 (IPv6) Specification", RFC 2460, December 738 1998. 740 [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor 741 Discovery for IP Version 6 (IPv6)", RFC 2461, 742 December 1998. 744 [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address 745 Autoconfiguration", RFC 2462. 747 [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet 749 Internet-Draft 751 Protocol Version 6 (IPv6)", RFC 2463, December 1998. 753 [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", 754 RFC 2472, December 1998. 756 [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling 757 in IPv6 Specification", RFC 2473, December 1998. Xxx 758 add 760 [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 761 RFC 2671, August 1999. 763 [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast 764 Listener Discovery (MLD) for IPv6", RFC 2710, October 765 1999. 767 [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert 768 Option", RFC 2711, October 1999. 770 [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for 771 Stateless Address Autoconfiguration in IPv6", RFC 772 3041, January 2001. 774 [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August 775 2001. 777 [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Proto- 778 col for IPv6 (DHCPv6)", RFC 3315, July 2003. 780 [RFC-3363] Bush, R., et al., "Representing Internet Protocol 781 version 6 (IPv6) Addresses in the Domain Name System 782 (DNS)", RFC 3363, August 2002. 784 [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC 785 3484, February 2003. 787 [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing 788 Architecture", RFC 3513, April 2003. 790 [RFC-3590] Haberman, B., "Source Address Selection for the Mul- 791 ticast Listener Discovery (MLD) Protocol", RFC 3590, 792 September 2003. 794 [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP 795 version 6", RFC 3596, October 2003. 797 [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use 798 with IPsec", RFC 3602, September 2003. 800 Internet-Draft 802 [DEP-SL] C. Huitema, B. Carpenter, "Deprecating Site Local 803 Addresses", draft-ietf-ipv6-deprecate-site-local- 804 03.txt, Work in Progress. 806 12.2 Non-Normative 808 [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast", 809 draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt, Work in 810 Progress. 812 [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of 813 DES-like cryptosystems", Journal of Cryptology Vol 4, 814 Jan 1991. 816 [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 817 2000. 819 [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without 820 Strong Integrity", Proceedings of the 32nd IETF, 821 Danvers, MA, April 1995. 823 [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6 Ser- 824 vice", RFC 3736, April 2004. 826 [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and 827 Rose, S., "DNS Security Introduction and Requirements" 828 draft-ietf-dnsext-dnssec-intro-10.txt, Work in Progress. 830 [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and 831 Rose, S., "Resource Records for the DNS Security Exten- 832 sions", draft-ietf-dnsext-dnssec-records-08.txt, Work in 833 Progress. 835 [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and 836 Rose, S., "Protocol Modifications for the DNS Security 837 Extensions", draft-ietf-dnsext-dnssec-protocol-06.txt, 838 Work in Progress. 840 [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto- 841 col", draft-ietf-ipsec-ikev2-13.txt, Work in Progress. 843 [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home 844 Address Options", draft-savola-ipv6-rh-ha-security- 845 03.txt, Work in Progress. 847 [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu- 848 rity Threats and Counter-Measures; In Proceedings "Sym- 849 posium on Network and Distributed System Security", 851 Internet-Draft 853 February 1995, pp.2-16. 855 [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793, 856 August 1980. 858 [RFC-1034] Mockapetris, P., "Domain names - concepts and facili- 859 ties", RFC 1034, November 1987. 861 [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and 862 S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC 863 2205, September 1997. 865 [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ether- 866 net Networks", RFC 2462, December 1998. 868 [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over 869 ATM Networks", RFC 2492, January 1999. 871 [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6 Jumbo- 872 grams", RFC 2675, August 1999. 874 [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder, 875 "Textual Conventions for Internet Network Addresses", 876 RFC 2851, June 2000. 878 [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms 879 for IPv6 Hosts and Routers", RFC 2893, August 2000. 881 [RFC-3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 882 of Explicit Congestion Notification (ECN) to IP", RFC 883 3168, September 2001. 885 [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific 886 Multicast (SSM)", RFC 3569, July 2003. 888 [RFC-3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 889 "IPv6 Flow Label Specification", RFC 3697, March 2004. 891 [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for 892 IP", draft-ietf-ssm-arch-04.txt, Work in Progress. 894 13. Authors and Acknowledgements 896 This document was written by the IPv6 Node Requirements design team: 898 Jari Arkko 899 [jari.arkko@ericsson.com] 901 Internet-Draft 903 Marc Blanchet 904 [marc.blanchet@viagenie.qc.ca] 906 Samita Chakrabarti 907 [samita.chakrabarti@eng.sun.com] 909 Alain Durand 910 [alain.durand@sun.com] 912 Gerard Gastaud 913 [gerard.gastaud@alcatel.fr] 915 Jun-ichiro itojun Hagino 916 [itojun@iijlab.net] 918 Atsushi Inoue 919 [inoue@isl.rdc.toshiba.co.jp] 921 Masahiro Ishiyama 922 [masahiro@isl.rdc.toshiba.co.jp] 924 John Loughney 925 [john.loughney@nokia.com] 927 Rajiv Raghunarayan 928 [raraghun@cisco.com] 930 Shoichi Sakane 931 [shouichi.sakane@jp.yokogawa.com] 933 Dave Thaler 934 [dthaler@windows.microsoft.com] 936 Juha Wiljakka 937 [juha.wiljakka@Nokia.com] 939 The authors would like to thank Ran Atkinson, Jim Bound, Brian Car- 940 penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Nar- 941 ten, Juha Ollila and Pekka Savola for their comments. 943 14. Editor's Contact Information 945 Comments or questions regarding this document should be sent to the 946 IPv6 Working Group mailing list (ipv6@ietf.org) or to: 948 John Loughney 949 Nokia Research Center 950 Itamerenkatu 11-13 952 Internet-Draft 954 00180 Helsinki 955 Finland 957 Phone: +358 50 483 6242 958 Email: John.Loughney@Nokia.com 960 Intellectual Property Statement 962 The IETF takes no position regarding the validity or scope of any 963 Intellectual Property Rights or other rights that might be claimed to 964 pertain to the implementation or use of the technology described in 965 this document or the extent to which any license under such rights 966 might or might not be available; nor does it represent that it has 967 made any independent effort to identify any such rights. Information 968 on the IETF's procedures with respect to rights in IETF Documents can 969 be found in BCP 78 and BCP 79. 971 Copies of IPR disclosures made to the IETF Secretariat and any 972 assurances of licenses to be made available, or the result of an 973 attempt made to obtain a general license or permission for the use of 974 such proprietary rights by implementers or users of this 975 specification can be obtained from the IETF on-line IPR repository at 976 http://www.ietf.org/ipr. 978 The IETF invites any interested party to bring to its attention any 979 copyrights, patents or patent applications, or other proprietary 980 rights that may cover technology that may be required to implement 981 this standard. Please address the information to the IETF at 982 ietf-ipr@ietf.org. 984 Disclaimer of Validity 986 This document and the information contained herein are provided on an 987 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 988 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 989 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 990 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 991 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 992 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 994 Copyright Statement 996 Copyright (C) The Internet Society (2004). This document is subject 997 to the rights, licenses and restrictions contained in BCP 78, and 998 except as set forth therein, the authors retain all their rights. 1000 Internet-Draft 1002 Acknowledgment 1004 Funding for the RFC Editor function is currently provided by the 1005 Internet Society.