idnits 2.17.1 draft-ietf-ipv6-node-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 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 24 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.) ** There are 8 instances of too long lines in the document, the longest one being 223 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 163: '... none of the MUST NOTs....' RFC 2119 keyword, line 253: '... IPv6/ATM driver SHALL support the PVC...' RFC 2119 keyword, line 255: '... SHALL also support PVC mode of o...' RFC 2119 keyword, line 337: '...e implementation MAY support disabling...' RFC 2119 keyword, line 357: '...'s NS), the node MUST respond to it (i...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 1, 2002) is 7970 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: 'RFC793' is mentioned on line 116, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'RFC-2464' is mentioned on line 853, but not defined == Missing Reference: 'RFC-2467' is mentioned on line 863, but not defined == Missing Reference: 'RFC-2470' is mentioned on line 866, but not defined == Missing Reference: 'RFC2491' is mentioned on line 244, but not defined == Missing Reference: 'RFC2492' is mentioned on line 249, but not defined == Missing Reference: 'RFC2497' is mentioned on line 261, but not defined -- Looks like a reference, but probably isn't: '2529' on line 268 == Missing Reference: 'RFC2590' is mentioned on line 274, but not defined == Missing Reference: 'RFC2460' is mentioned on line 307, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Missing Reference: 'IPv6-RH' is mentioned on line 914, but not defined == Missing Reference: 'RFC2675' is mentioned on line 395, but not defined == Missing Reference: 'RFC-3041' is mentioned on line 910, but not defined ** Obsolete undefined reference: RFC 3041 (Obsoleted by RFC 4941) == Missing Reference: 'RFC2462' is mentioned on line 456, but not defined ** Obsolete undefined reference: RFC 2462 (Obsoleted by RFC 4862) == Missing Reference: 'DHCP' is mentioned on line 460, but not defined == Missing Reference: 'RFC-2675' is mentioned on line 888, but not defined == Missing Reference: 'RFC-1034' is mentioned on line 840, but not defined == Missing Reference: 'SOI' is mentioned on line 834, but not defined == Missing Reference: 'RFC-2411' is mentioned on line 712, but not defined ** Obsolete undefined reference: RFC 2411 (Obsoleted by RFC 6071) == Missing Reference: 'ANYCAST' is mentioned on line 831, but not defined == Missing Reference: 'RFC-793' is mentioned on line 837, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'RFC-2147' is mentioned on line 843, but not defined ** Obsolete undefined reference: RFC 2147 (Obsoleted by RFC 2675) == Missing Reference: 'RFC-2452' is mentioned on line 846, but not defined ** Obsolete undefined reference: RFC 2452 (Obsoleted by RFC 4022, RFC 8096) == Missing Reference: 'RFC-2454' is mentioned on line 850, but not defined ** Obsolete undefined reference: RFC 2454 (Obsoleted by RFC 4113, RFC 8096) == Missing Reference: 'RFC-2465' is mentioned on line 856, but not defined ** Obsolete undefined reference: RFC 2465 (Obsoleted by RFC 4293, RFC 8096) == Missing Reference: 'RFC-2466' is mentioned on line 860, but not defined ** Obsolete undefined reference: RFC 2466 (Obsoleted by RFC 4293, RFC 8096) == Missing Reference: 'RFC-2491' is mentioned on line 870, but not defined == Missing Reference: 'RFC-2492' is mentioned on line 874, but not defined == Missing Reference: 'RFC-2497' is mentioned on line 877, but not defined == Missing Reference: 'RFC-2529' is mentioned on line 880, but not defined == Missing Reference: 'RFC-2590' is mentioned on line 884, but not defined == Missing Reference: 'RFC-2732' is mentioned on line 891, but not defined ** Obsolete undefined reference: RFC 2732 (Obsoleted by RFC 3986) == Missing Reference: 'RFC-2851' is mentioned on line 895, but not defined ** Obsolete undefined reference: RFC 2851 (Obsoleted by RFC 3291) == Missing Reference: 'RFC-2874' is mentioned on line 899, but not defined == Missing Reference: 'RFC-2893' is mentioned on line 903, but not defined ** Obsolete undefined reference: RFC 2893 (Obsoleted by RFC 4213) == Missing Reference: 'RFC-3019' is mentioned on line 906, but not defined ** Obsolete undefined reference: RFC 3019 (Obsoleted by RFC 5519) == Unused Reference: 'RFC-2461' is defined on line 806, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDRARCHv3' -- Possible downref: Non-RFC (?) normative reference: ref. 'DEFADDR' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIPv6' ** Obsolete normative reference: RFC 1886 (Obsoleted by RFC 3596) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** 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) Summary: 34 errors (**), 0 flaws (~~), 41 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group John Loughney (ed) 3 Internet-Draft Nokia 4 July 1, 2002 6 Expires: December 29, 2002 8 IPv6 Node Requirements 9 draft-ietf-ipv6-node-requirements-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 1, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document defines requirements for IPv6 nodes. It is expected 41 that IPv6 will be deployed in a wide range of devices and situations. 42 Specifying the requirements for IPv6 nodes allows IPv6 to function 43 well and interoperate in a large number of situations and 44 deployments. 46 Table of Contents 48 1. Introduction 49 1.1 Scope of this Document 50 1.2 Description of IPv6 Nodes & Conformance Groups 51 2. Abbreviations Used in This Document 52 3. Sub-IP Layer 53 3.1 IPv6 over Foo 54 4. IP Layer 55 4.1 General 56 4.2 Neighbor Discovery 57 4.3 Path MTU Discovery & Packet Size 58 4.4 ICMPv6 59 4.5 Addressing 60 4.6 Other 61 5. Transport and DNS 62 5.1 Transport Layer 63 5.2 DNS 64 5.3 Other 65 6. Transition 66 6.1 Transition Mechanisms 67 7. Mobility 68 8. Security 69 8.1 Basic Architecture 70 8.2 Security Protocols 71 8.3 Transforms and Algorithms 72 8.4 Key Management Method 73 9. Router Functionality 74 9.1 General 75 10. Network Management 76 10.1 MIBs 77 11. Security Considerations 78 12. References 79 12.1 Normative 80 12.2 Non-Normative 81 13. Authors and Acknowledgements 82 14. Editor's Address 83 Appendix A: Change history 84 Appendix B: List of Specifications Included 85 Appendix C: Specifications Not Included 87 1. Introduction 89 The goal of this document is to define a minimal set of functionality 90 required for an IPv6 node. Many IPv6 nodes will implement optional 91 or additional features, but all IPv6 nodes can be expected to 92 implement the requirements listed in this document. 94 The document is written to minimize protocol discussion in this 95 document but instead make pointers to RFCs. In case of any 96 conflicting text, this document takes less precedence than the 97 normative RFCs, unless additional clarifying text is included in this 98 document. 100 During the process of writing this document, if any issue is raised 101 regarding the normative RFCs, the consensus is, whenever possible, to 102 fix the RFCs not to add text in this document. However, it may be 103 useful to include this information in an appendix for informative 104 purposes. 106 Although the document points to different specifications, it should 107 be noted that in most cases, the granularity of requirements are 108 smaller than a single specification, as many specifications define 109 multiple, independent pieces, some of which may not be mandatory. 111 As it is not always possible for an implementer to know the exact 112 usage of IPv6 in a node, an overriding requirement for IPv6 nodes is 113 that they should adhere to John Postel's Robustness Principle: 115 Be conservative in what you do, be liberal in what you accept from 116 others. [RFC793]. 118 1.1 Scope of this Document 120 IPv6 covers many specifications. It is intended that IPv6 will be 121 deployed in many different situations and environments. Therefore, 122 it is important to develop the requirements for IPv6 nodes, in order 123 to ensure interoperability. 125 This document assumes that all IPv6 nodes meet the minimum 126 requirements specified here. 128 1.2 Description of IPv6 Nodes & Conformance Groups 130 This document defines three classes of conformance for an IPv6 node: 131 Unconditionally Mandatory, Conditionally Mandatory and 132 Unconditionally Optional. The three classes of conformance are 133 defined in section 1.2. 135 From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we 136 have the following definitions: 138 Description of an IPv6 Node 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 Usage of IPv6 nodes 153 TBD 155 Conformance Group 157 A conformance group is a collection of related behavioral 158 specifications that appear in standards. A single RFC may contain 159 multiple independent pieces of functionality that belong to 160 separate conformance groups. If a node claims compliance to a 161 given conformance group, that means it implements all of the 162 mandatory behavior therein, including implementing all MUSTs, and 163 none of the MUST NOTs. 165 Unconditionally Mandatory 167 If a node claims compliance to this document, then it must support 168 the behavior specified within each conformance group listed of 169 type unconditionally mandatory. 171 Conditionally Mandatory 173 Conditionally mandatory groups include those which are mandatory 174 only if a particular condition is true, such as whether a specific 175 type of hardware is present, or whether another given group is 176 implemented. When a conditionally mandatory specification or 177 group is described, the condition will also be described. A given 178 RFC or portion thereof can sometimes appear in multiple 179 conformance groups, with different conditions. 181 Unconditionally Optional 182 Behavior that is neither unconditionally mandatory nor 183 conditionally mandatory is unconditionally optional for compliance 184 to this document. 186 2. Abbreviations Used in This Document 188 AH Authentication Header 190 DAD Duplicate Address Detection 192 ESP Encapsulating Security Payload 194 ICMP Internet Control Message Protocol 196 MIB Management Information Base 198 MTU Maximum Transfer Unit 200 NA Neighbor Advertisement 202 ND Neighbor Discovery 204 NS Neighbor Solicitation 206 NUD Neighbor Unreachability Detection 208 3. Sub-IP Layer 210 An IPv6 node must follow the RFC related to the link-layer that is 211 sending packet. By definition, these specifications are 212 conditionally mandatory, based upon what layer-2 is used. In 213 general, it is reasonable to be a conformant IPv6 node and NOT 214 support some legacy interfaces. 216 3.1 A.K.A - IPv6 over Foo 218 3.1.1 RFC2464 - Transmission of IPv6 Packets over Ethernet Networks 220 Transmission of IPv6 Packets over Ethernet Networks [RFC-2464] is 221 conditionally mandatory if the node supports Ethernet interfaces. 223 3.1.2 RFC2467 - A Method for the Transmission of IPv6 Packets over FDDI 224 Networks 226 A Method for the Transmission of IPv6 Packets over FDDI Networks 227 [RFC-2467] is conditionally mandatory if the node supports FDDI 228 interfaces. 230 3.1.3 RFC2470 - A Method for the Transmission of IPv6 Packets over Token 231 Ring Networks 233 A Method for the Transmission of IPv6 Packets over Token Ring 234 Networks [RFC-2470] is conditionally mandatory if the node supports 235 token ring interfaces. 237 3.1.4 RFC2472 - IP version 6 over PPP 239 IPv6 over PPP [RFC-2472] is conditionally mandatory if the node 240 supports PPP. 242 3.1.5 RFC2491 - IPv6 over Non-Broadcast Multiple Access (NBMA) Networks 244 IPv6 over Non-Broadcast Multiple Access (NBMA) Networks [RFC2491] is 245 conditionally mandatory if the node supports NBMA network interfaces. 247 3.1.6 RFC2492 - IPv6 over ATM Networks 249 IPv6 over ATM Networks [RFC2492] is conditionally mandatory if the 250 node supports ATM interfaces. Additionally, the specification 251 states: 253 A minimally conforming IPv6/ATM driver SHALL support the PVC mode 254 of operation. An IPv6/ATM driver that supports the full SVC mode 255 SHALL also support PVC mode of operation. 257 3.1.7 RFC2497 - A Method for the Transmission of IPv6 Packets over 258 ARCnet Networks 260 A Method for the Transmission of IPv6 Packets over ARCnet Networks 261 [RFC2497] is conditionally mandatory if the node supports ARCnet 262 network interfaces. 264 3.1.8 RFC2529 - Transmission of IPv6 Packets over IPv4 Domains without 265 Explicit Tunnels 267 Transmission of IPv6 Packets over IPv4 Domains without Explicit 268 Tunnels [2529] is unconditionally optional. 270 3.1.9 RFC2590 - Transmission of IPv6 Packets over Frame Relay Networks 271 Specification 273 Transmission of IPv6 Packets over Frame Relay Networks Specification 274 [RFC2590] is conditionally mandatory if the node supports Frame Relay 275 interfaces. 277 4. IP Layer 278 4.1 General 280 4.1.1 RFC2460 - Internet Protocol Version 6 282 The Internet Protocol Version 6 is specified in [RFC-2460]. This 283 specification is unconditionally mandatory. 285 Unrecognized options in Hop-by-Hop Options or Destination Options 286 extensions must be processed as described in RFC 2460. 288 The node must follow the packet transmission rules in RFC 2460. 290 Nodes must always be able to receive fragment headers. However, if it 291 does not implement path MTU discovery it may not need to send 292 fragment headers. However, nodes that do not implement transmission 293 of fragment headers need to impose limitation to payload size of 294 layer 4 protocols. 296 The capability of being a final destination is unconditionally 297 mandatory, whereas the capability of being an intermediate 298 destination is unconditionally optional (i.e. - host functionality 299 vs. router functionality). 301 RFC 2460 specifies extension headers and the processing for these 302 headers. 304 A full implementation of IPv6 includes implementation of the 305 following extension headers: Hop-by-Hop Options, Routing (Type 0), 306 Fragment, Destination Options, Authentication and Encapsulating 307 Security Payload. [RFC2460] 309 It is unconditionally mandatory for an IPv6 node to process these 310 headers. It should be noted that there is some discussion about the 311 use of Routing Headers and possible security threats [IPv6-RH] caused 312 by them. 314 4.2 Neighbor Discovery 316 4.2.1 RFC2461 - Neighbor Discovery for IPv6 318 Neighbor Discovery is conditionally mandatory. RFC 2461 states: 320 "Unless specified otherwise (in a document that covers operating 321 IP over a particular link type) this document applies to all link 322 types. However, because ND uses link-layer multicast for some of 323 its services, it is possible that on some link types (e.g., NBMA 324 links) alternative protocols or mechanisms to implement those 325 services will be specified (in the appropriate document covering 326 the operation of IP over a particular link type). The services 327 described in this document that are not directly dependent on 328 multicast, such as Redirects, Next-hop determination, Neighbor 329 Unreachability Detection, etc., are expected to be provided as 330 specified in this document. The details of how one uses ND on 331 NBMA links is an area for further study." 333 Some detailed analysis of Neighbor discovery follows: 335 Router Discovery is how hosts locate routers that reside on an 336 attached link. Router Discovery is unconditionally mandatory for 337 implementations. However, the implementation MAY support disabling 338 this feature. 340 Prefix Discovery is how hosts discover the set of address prefixes 341 that define which destinations are on-link for an attached link. 342 Prefix discovery is unconditionally mandatory for implementation with 343 option to disable this function. 345 Address resolution is how nodes determine the link-layer address of 346 an on-link destination (e.g., a neighbor) given only the 347 destination's IP address. It is conditionally mandatory 348 implementation depending on the link type support. Address Resolution 349 for point-to-point links may not be mandatory; working group 350 clarification is needed on this. 352 Neighbor Unreachability Detection (NUD) is conditionally mandatory. 353 It is unconditionally mandatory for all paths between hosts and 354 neighboring nodes. It is unconditionally optional for paths between 355 routers. It is unconditionally optional for multicast. However, when 356 a node receives a unicast Neighbor Solicitation (NS) message (that 357 may be a NUD's NS), the node MUST respond to it (i.e. send a unicast 358 Neighbor Advertisement). 360 Duplicate Address Detection is unconditionally mandatory (RFC2462 361 section 5.4 specifies DAD MUST take place on all unicast addresses). 363 Sending Router Solicitation is unconditionally mandatory for host 364 implementation, with a configuration option to disable this 365 functionality. 367 Receiving and processing Router Advertisements is unconditionally 368 mandatory for host implementation, with a configuration option to 369 disable this functionality. The ability to understand specific Router 370 Advertisements is dependent on supporting the specification where the 371 RA is specified. 373 Sending and Receiving Neighbor Solicitation (NS) and Neighbor 374 Advertisement (NA) are unconditionally mandatory. NS and NA messages 375 are required for Duplicate Address Detection (DAD). 377 Redirect Function is conditionally mandatory. If the node is a 378 router, Redirect Function is unconditionally mandatory. 380 4.3 Path MTU Discovery & Packet Size 382 4.3.1 RFC1981 - Path MTU Discovery 384 Path MTU Discovery [RFC-1981] is unconditionally optional. The IPv6 385 specification [RFC-2460] states in section 5 that "a minimal IPv6 386 implementation (e.g., in a boot ROM) may simply restrict itself to 387 sending packets no larger than 1280 octets, and omit implementation 388 of Path MTU Discovery." 390 If Path MTU Discovery is not implemented then the sending packet size 391 is limited to 1280 octets (standard limit in [RFC-2460]). 393 4.3.2 RFC2675 - IPv6 Jumbograms 395 IPv6 Jumbograms [RFC2675] is unconditionally optional. 397 4.4 ICMPv6 399 4.1.1 RFC2463 - ICMP for the Internet Protocol Version 6 (IPv6) 401 ICMPv6 [RFC-2463] is unconditionally mandatory. 403 4.5 Addressing 405 Currently, there is discussion on-going on support for site-local 406 addressing. 408 4.5.1 RFC2373 - IP Version 6 Addressing Architecture 410 The IPv6 Addressing Architecture [RFC-2373] is a mandatory part of 411 IPv6. Currently, this specification is being updated by [ADDRARCHv3]. 413 4.5.2 RFC2462 - IPv6 Stateless Address Autoconfiguration 415 IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. 416 This specification is unconditionally mandatory for nodes that are 417 hosts. 419 It is unconditionally mandatory for nodes that are routers to 420 generate link local addresses as described in this specification. 422 From 2462: 424 The autoconfiguration process specified in this document applies 425 only to hosts and not routers. Since host autoconfiguration uses 426 information advertised by routers, routers will need to be 427 configured by some other means. However, it is expected that 428 routers will generate link-local addresses using the mechanism 429 described in this document. In addition, routers are expected to 430 successfully pass the Duplicate Address Detection procedure 431 described in this document on all addresses prior to assigning 432 them to an interface. 434 Duplicate Address Detection (DAD) is unconditionally mandatory for 435 all interface addresses assigned to the node. 437 4.5.3 RFC3041 - Privacy Extensions for Address Configuration in IPv6 439 Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] 440 is unconditionally optional. Currently, there is discussion of the 441 applicability of temporary addresses. 443 4.5.4 Default Address Selection for IPv6 445 Default Address Selection for IPv6 [DEFADDR] is conditionally 446 mandatory, if a node has more than one IPv6 address per interface or 447 a node has more that one IPv6 interface (physical or logical) 448 configured. 450 The rules specified in the document are the only MUST to implement 451 portion of the architecture. There is no requirement that a node be 452 able to be part of more than one zone. 454 4.5.5 Stateful Address Autoconfiguration 456 IPv6 Stateless Address Autoconfiguration [RFC2462] defines stateless 457 address autoconfiguation. However, it does state that in the absence 458 of routers, hosts MUST attempt to use stateful autoconfiguration. 459 There is also reference to stateful address autoconfiguration being 460 defined elsewhere. Additionally, DHCP [DHCP] states that it is on 461 option for stateful address autoconfiguation. 463 From the current set of specification, it is not clear the level of 464 support that is needed for statefull Address Autoconfiguration. 466 4.6 Other 468 4.6.1 RFC2473 - Generic Packet Tunneling in IPv6 Specification 469 Generic Packet Tunneling [RFC-2473] conditionally mandatory, with the 470 condition being implementing the mobile node functionality or Home 471 Agent functionality of Mobile IP [MIPv6]. 473 4.6.2 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 475 Multicast Listener Discovery [RFC-2710] is Conditionally Mandatory, 476 where the condition is if the node joins any multicast groups other 477 than the all-nodes-on-link group (which will always be the case if it 478 runs ND or DAD on the link). 480 There has been some discussion that hosts may not be able to depend 481 on MLD if there is no connection to a router, therefore this may not 482 be Mandatory. Further discussion is needed on this. 484 5. Transport Layer and DNS 486 5.1 Transport Layer 488 5.1.1 RFC2147 - TCP and UDP over IPv6 Jumbograms 490 This specification is conditionally mandatory, if Jumbograms are 491 implemented [RFC-2675]. One open issue is if this document needs to 492 be updated, as it refers to an obsoleted document. 494 5.2 DNS 496 Support for DNS, as described in [RFC-1034], [RFC-1035] and [RFC- 497 1886], is unconditionally optional. Not all nodes will need to 498 resolve addresses. 500 5.2.1 RFC2874 - DNS Extensions to Support IPv6 Address Aggregation and 501 Renumbering 503 DNS Extensions to Support IPv6 Address Aggregation and Renumbering is 504 unconditionally optional 506 5.2.2 RFC2732 - Format for Literal IPv6 Addresses in URL's 508 RFC 2732 is conditionally mandatory if the node uses URL's. 510 5.3 Other 512 5.3.1 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 514 The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] is 515 unconditionally optional. 517 6. Transition 519 6.1 Transition Mechanisms 521 IPv6 nodes should use native address instead of transition-based 522 addressing. 524 6.1.1 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers 526 If an IPv6 node implement dual stack and/or tunneling, then RFC2893 527 is unconditionally mandatory. 529 This document is currently being updated. 531 7. Mobility 533 Currently, the MIPv6 specification [MIPv6] is nearing completion. 534 Mobile IPv6 places some requirements on IPv6 nodes. This document is 535 not meant to prescribe behaviors, but to capture the consensus of 536 what should be done for IPv6 nodes with respect to Mobile IPv6. 538 The Mobile IP specification [MIPv6] specifies the following classes 539 of functionality: Correspondent Node, Mobile Node, Route Optimization 540 functionality and Home Agent Functionality. 542 Correspondent Node functionality is Unconditionally Mandatory. 544 Mobile Node functionality is Conditionally Mandatory for nodes that 545 need to maintain sessions while changing their point of attachment to 546 the Internet. 548 Route Optimization functionality is conditionally mandatory for 549 hosts. Route Optimization is unconditionally optional for routers. 550 There is ongoing discussion about the role of Route Optimization. 551 This document should list some of the benefits of Route Optimization. 553 Home Agent functionality is Unconditionally Optional. 555 8. Security 557 This section describes the specification of IPsec for the IPv6 node. 558 Other issues that IPsec cannot resolve are described in the security 559 considerations. 561 8.1 Basic Architecture 563 Security Architecture for the Internet Protocol [RFC-2401] is 564 unconditionally mandatory except of the following description. 566 Requirements that this section describes explicitly MUST refer to 567 RFC-2401. 569 IPsec transport mode is unconditionally mandatory. 571 IPsec tunnel mode is unconditionally mandatory. 573 [DISCUSSION: Network administrators want to make separated 574 networks to be a single network by using a site-local address 575 space. The routers should be implemented both IPsec transport 576 mode and a generic tunnel in this case, but if there is no 577 statement what it should be, the administrators must use IPsec 578 tunnel mode because it is used now in IPv4 network.] 580 Applying single security association of ESP [RFC-2406] to a packet is 581 unconditionally mandatory, although RFC-2401 defines four types of 582 combination of security associations that must be supported by 583 compliant IPsec hosts. 585 Applying single security association of AH is conditionally mandatory 586 if AH [RFC-2402] is implemented. 588 The following packet type is conditionally mandatory if AH is 589 combined with ESP: IP|AH|ESP|ULP. 591 The summary of Basic Combinations of Security Associations in section 592 4.5 of RFC-2401 is: 594 case 1-2 is unconditionally mandatory. 595 case 1-1 and 1-3 is conditionally mandatory if AH is implemented. 596 case 1-4, 1-5, 2-5 and 4 is conditionally optional if IPsec tunnel 597 mode is implemented. 598 case 2-4 is conditionally optional if IPsec tunnel mode and AH is 599 implemented. 600 case 3 is not applicable to this document. 602 8.2 Security Protocols 604 ESP [RFC-2406] is unconditionally mandatory even when ESP is not 605 used. AH [RFC-2402] is unconditionally mandatory also. 607 AH is need if there is data in IP header to be protected, for 608 example, an extension header. 610 In practice, ESP can provide the same security services as AH and as 611 well as confidentiality, thus there is no real need for AH. 613 8.3 Transforms and Algorithms 614 The ESP DES-CBC Cipher Algorithm With Explicit IV [RFC-2405] is 615 conditionally mandatory if you need to have interoperability with old 616 implementation by using DES-CBC. Note the IPsec WG recommends not 617 using this algorithm. 3DES-CBC is conditionally mandatory so that the 618 part of ESP CBC-Mode Cipher Algorithms [RFC-2451] is unconditionally 619 mandatory. Note that the IPsec WG also recommends not using this 620 algorithm. AES-128-CBC [ipsec-ciph-aes-cbc] is unconditionally 621 mandatory but there is on-going work in the IPsec WG. NULL Encryption 622 algorithm [RFC-2410] is conditionally mandatory. It is only for 623 providing integrity service, and also for debugging use. 625 The use of HMAC-SHA-1-96 within ESP, described in [RFC-2404], is 626 unconditionally mandatory. This MUST be used if AH is implemented. 627 The Use of HMAC-MD5-96 within ESP, described in [RFC-2403], is 628 unconditionally mandatory. This MUST be used if AH is implemented. 629 The "HMAC-SHA-256-96 Algorithm and Its Use With IPsec" [ipsec-ciph- 630 sha-256] is unconditionally mandatory, but it is being discussed in 631 the IPsec WG. An implementer MUST refer to Keyed-Hashing for Message 632 Authentication [RFC-2104]. 634 8.4 Key Management Method 636 Manual keying is unconditionally mandatory. 638 Automated SA and Key Management is conditionally mandatory for the 639 use of the anti-replay features of AH and ESP, and to accommodate 640 on-demand creation of SAs, session-oriented keying. 642 IKE [RFC-2407, RFC-2408, RFC-2409] is unconditionally optional for 643 unicast traffic. Note that the IPsec WG is working on the successor 644 to IKE [SOI]. 646 9. Router Functionality 648 This section defines general considerations for IPv6 nodes that act 649 as routers. It is for future study if this document, or a separate 650 document is needed to fully define IPv6 router requirements. 651 Currently, this section does not discuss routing protocols. 653 9.1 General 655 9.1.1 RFC2711 - IPv6 Router Alert Option 657 The Router Alert Option [RFC-2711] is conditionally mandatory if the 658 node performs packet forwarding at the IP layer (i.e. - the node is a 659 router). 661 9.1.2 RFC2461 - Neighbor Discovery for IPv6 662 Sending Router Advertisements and processing Router Solicitation is 663 unconditionally mandatory. 665 10. Network Management 667 Network Management, is generally not a requirement for IPv6 nodes. 668 However, for IPv6 nodes that are embedded devices, network management 669 may be the only possibility to control these hosts. 671 10.1 MIBs 673 In a general sense, MIBs can be considered conditionally mandatory 674 when the node supports an SNMP agent. This section is for further 675 study. It should be also noted that these specifications are being 676 updated updated. 678 10.1.1 RFC2452 - IPv6 Management Information Base for the Transmission 679 Control Protocol 681 TBA 683 10.1.2 RFC2454 - IPv6 Management Information Base for the User Datagram 684 Protocol 686 TBA 688 10.1.3 RFC2465 - Management Information Base for IP Version 6: Textual 689 Conventions and General Group 691 TBA 693 10.1.4 RFC2466 - Management Information Base for IP Version 6: ICMPv6 694 Group 696 TBA 698 10.1.5 RFC2851 - Textual Conventions for Internet Network Addresses 700 TBA 702 10.1.6 RFC3019 - IP Version 6 Management Information Base for the 703 Multicast Listener Discovery Protocol 705 TBA 707 11. Security Considerations 709 This draft does not affect the security of the Internet, but 710 implementations of IPv6 are expected to support a minimum set of 711 security features to ensure security on the Internet. "IP Security 712 Document Roadmap" [RFC-2411] is important for everyone to read. 714 The security considerations in RFC2401 describes, 716 The security features of IPv6 are described in the Security 717 Architecture for the Internet Protocol [RFC-2401]. 719 IPsec cannot cover all of security requirement for IPv6 node. For 720 example, IPsec cannot protect the node from kind of DoS attack. The 721 node may need a mechanism of IPv6 packet filtering functionality, and 722 also may need a mechanism of rate limitation. 724 The use of ICMPv6 without IPsec can expose the nodes in question to 725 various kind of attacks including Denial-of-Service, Impersonation, 726 Man-in-the-Middle, and others. Note that only manually keyed IPsec 727 can protect some of the ICMPv6 messages that are related to 728 establishing communications. This is due to chick en-and-egg problems 729 on running automated key management protocols on top of IP. However, 730 manually keyed IPsec may require a large number of SAs in order to 731 run on a large network due to the use of many addresses during ICMPv6 732 Neighbor Discovery. 734 An implementer should also consider the analysis of anycast 735 [ANYCAST]. 737 12. References 739 12.1 Normative 741 [ADDRARCHv3] Hinden, R. and Deering, S. "IP Version 6 Addressing 742 Architecture", Work in progress. 744 [DEFADDR] Draves, R., "Default Address Selection for IPv6", Work 745 in progress. 747 [DHCPv6] Bound, J. et al., "Dynamic Host Configuration Protocol 748 for IPv6 (DHCPv6)", Work in progress. 750 [MIPv6] Johnson D. and Perkins, C., "Mobility Support in 751 IPv6", Work in progress. 753 [RFC-1035] Mockapetris, P., "Domain names - implementation and 754 specification", STD 13, RFC 1035, November 1987. 756 [RFC-1886] Thomson, S. and Huitema, C., "DNS Extensions to sup- 757 port IP version 6, RFC 1886, December 1995. 759 [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU 760 Discovery for IP version 6", RFC 1981, August 1996. 762 [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: 763 Keyed-Hashing for Message Authentication", RFC 2104, 764 February 1997. 766 [RFC-2373] Hinden, R. and Deering, S., "IP Version 6 Addressing 767 Architecture", RFC 2373, July 1998. 769 [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for 770 the Internet Protocol", RFC 2401, November 1998. 772 [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication 773 Header", RFC 2402, November 1998. 775 [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 within 776 ESP and AH", RFC 2403, November 1998. 778 [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 779 within ESP and AH", RFC 2404, November 1998. 781 [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher 782 Algorithm With Explicit IV", RFC 2405, November 1998. 784 [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security 785 Protocol (ESP)", RFC 2406, November 1998. 787 [RFC-2407] Piper, D., "The Internet IP Security Domain of 788 Interpretation for ISAKMP", RFC 2407, November 1998. 790 [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and Turner, 791 J., "Internet Security Association and Key Management 792 Protocol (ISAKMP)", RFC 2408, November 1998. 794 [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key 795 Exchange (IKE)", RFC 2409, November 1998. 797 [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm 798 and Its Use With IPsec", RFC 2410, November 1998 800 [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher 801 Algorithms", RFC 2451, November 1998 803 [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver- 804 sion 6 (IPv6) Specification", RFC 2460, December 1998. 806 [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor 807 Discovery for IP Version 6 (IPv6)", RFC 2461, December 808 1998. 810 [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address 811 Autoconfiguration", RFC 2462. 813 [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet Pro- 814 tocol Version 6 (IPv6)", RFC 2463, December 1998. 816 [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC 817 2472, December 1998. 819 [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling 820 in IPv6 Specification", RFC 2473, December 1998. 822 [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast 823 Listener Discovery (MLD) for IPv6", RFC 2710, October 824 1999. 826 [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert 827 Option", RFC 2711, October 1999. 829 12.2 Non-Normative 831 [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Any- 832 cast" Work in Progress. 834 [SOI] C. Madson, "Son-of-IKE Requirements", Work in Pro- 835 gress. 837 [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793, 838 August 1980. 840 [RFC-1034] Mockapetris, P., "Domain names - concepts and facili- 841 ties", RFC 1034, November 1987. 843 [RFC-2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 844 2147, May 1997. 846 [RFC-2452] M. Daniele, "IPv6 Management Information Base for the 847 Transmission Control Protocol", RFC2452, December 848 1998. 850 [RFC-2454] M. Daniele, "IPv6 Management Information Base for the 851 User Datagram Protocol, RFC2454", December 1998. 853 [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Eth- 854 ernet Networks", RFC 2462, December 1998. 856 [RFC-2465] D. Haskin, S. Onishi, "Management Information Base for 857 IP Version 6: Textual Conventions and General Group", 858 RFC2465, December 1998. 860 [RFC-2466] D. Haskin, S. Onishi, "Management Information Base for 861 IP Version 6: ICMPv6 Group", RFC2466, December 1998. 863 [RFC-2467] M. Crawford, "A Method for the Tranmission of IPv6 864 Packets over FDDI Networks", RFC2467, December 1998. 866 [RFC-2470] M. Crawford, T. Narten, S. Thomas, "A Method for the 867 Tranmission of IPv6 Packets over Token Ring Networks", 868 RFC2470, December 1998. 870 [RFC-2491] G. Armitage, P. Schulter, M. Jork, G. Harter, "IPv6 871 over Non-Broadcast Multiple Access (NBMA) networks", 872 RFC2491, January 1999. 874 [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 875 over ATM Networks", RFC2492, January 1999. 877 [RFC-2497] I. Souvatzis, "A Method for the Transmission of IPv6 878 Packets over ARCnet Networks", RFC2497, January 1999. 880 [RFC-2529] Carpenter, B. and Jung, C., "Transmission of IPv6 over 881 IPv4 Domains without Explicit Tunnels", RFC 2529, 882 March 1999. 884 [RFC-2590] A. Conta, A. Malis, M. Mueller, "Transmission of IPv6 885 Packets over Frame Relay Networks Specification", RFC 886 2590, May 1999. 888 [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6 Jumbo- 889 grams", RFC 2675, August 1999. 891 [RFC-2732] R. Hinden, B. Carpenter, L. Masinter, "Format for 892 Literal IPv6 Addresses in URL's", RFC 2732, December 893 1999. 895 [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. 896 Schoenwaelder, "Textual Conventions for Internet Net- 897 work Addresses", RFC2851, June 2000. 899 [RFC-2874] Crawford, M. and Huitema, C., "DNS Extensions to Sup- 900 port IPv6 Address Aggregation and Renumbering", RFC 901 2874, July 2000. 903 [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms 904 for IPv6 Hosts and Routers", RFC 2893, August 2000. 906 [RFC-3019] B. Haberman, R. Worzella, "IP Version 6 Management 907 Information Base for the Multicast Listener Discovery 908 Protocol", RFC3019, January 2001. 910 [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for 911 Stateless Address Autoconfiguration in IPv6", RFC 912 3041, January 2001. 914 [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home 915 Address Options", Work in Progress, March 2002. 917 13. Authors and Acknowledgements 919 This document was written by the IPv6 Node Requirements design team: 921 Jari Arkko 922 [jari.arkko@ericsson.com] 924 Marc Blanchet 925 [Marc.Blanchet@viagenie.qc.ca] 927 Samita Chakrabarti 928 [Samita.Chakrabarti@eng.sun.com] 930 Alain Durand 931 [Alain.Durand@Sun.com] 933 Gerard Gastaud 934 [Gerard.Gastaud@alcatel.fr] 936 Jun-ichiro itojun Hagino 937 [itojun@iijlab.net] 939 Atsushi Inoue 940 [inoue@isl.rdc.toshiba.co.jp] 942 Masahiro Ishiyama 944 [masahiro@isl.rdc.toshiba.co.jp] 946 John Loughney 947 [John.Loughney@Nokia.com] 949 Okabe Nobuo 950 [nov@tahi.org] 952 Rajiv Raghunarayan 953 [raraghun@cisco.com] 955 Shoichi Sakane 956 [shouichi.sakane@jp.yokogawa.com] 958 Dave Thaler 959 [dthaler@windows.microsoft.com] 961 Juha Wiljakka 962 [juha.wiljakka@Nokia.com] 964 The authors would like to thank Adam Machalek, Juha Ollila and Pekka Savola for their comments. 966 14. Editor's Contact Information 968 Comments or questions regarding this document should be sent to the IPv6 Working Group mailing list (ipng@sunroof.eng.sun.com) or to: 970 John Loughney 971 Nokia Research Center 972 It�merenkatu 11-13 973 00180 Helsinki 974 Finland 976 Phone: +358 50 483 6242 977 Email: John.Loughney@Nokia.com 979 Appendix A: Change history 981 The following is a list of changes since the previous version. 983 - Small updates based upon feedback from the IPv6 mailing list. 984 - Refomated chapters. 985 - Added Appendix B - List of RFCs. 987 TBD 989 Appendix B: List of RFCs 990 This is a list of RFC to look at during the editing process. They are classified by generic categories and by level of potential conformance. The * denotes some sections of the specification have lesser level of conformance required. 992 RFC Section Conformance 993 ======================================================== 994 RFC-1034 5.2.1 unconditionally optional 995 RFC-1035 5.2.1 unconditionally optional 996 RFC-1886 5.2.1 unconditionally optional 997 RFC-1981 4.3.1 unconditionally optional 998 RFC-2104 8.3 conditionally mandatory 999 RFC-2147 5.1.1 conditionally mandatory 1000 RFC-2373 4.5.1 unconditionally mandatory 1001 RFC-2401 8.1 unconditionally mandatory * 1002 RFC-2402 8.1 conditionally mandatory 1003 RFC-2403 8.3 unconditionally mandatory 1004 RFC-2404 8.3 unconditionally mandatory 1005 RFC-2405 8.3 conditionally mandatory 1006 RFC-2406 8.1 unconditionally mandatory 1007 RFC-2407 8.4 unconditionally mandatory 1008 RFC-2408 8.4 unconditionally mandatory 1009 RFC-2409 8.4 unconditionally mandatory 1010 RFC-2410 8.3 unconditionally mandatory 1011 RFC-2451 8.3 unconditionally mandatory 1012 RFC-2452 10.1.1 conditionally mandatory 1013 RFC-2454 10.1.2 conditionally mandatory 1014 RFC-2460 4.1.1 unconditionally mandatory * 1015 RFC-2461 4.2.1 unconditionally mandatory * 1016 RFC-2462 4.5.2 unconditionally mandatory * 1017 RFC-2463 4.5.1 unconditionally mandatory 1018 RFC-2464 3.1.1 conditionally mandatory 1019 RFC-2465 10.1.3 conditionally mandatory 1020 RFC-2466 10.1.4 conditionally mandatory 1021 RFC-2467 3.1.2 conditionally mandatory 1022 RFC-2470 3.1.3 conditionally mandatory 1023 RFC-2472 3.1.4 conditionally mandatory 1024 RFC-2473 4.6.1 conditionally mandatory 1025 RFC-2491 3.1.5 conditionally mandatory 1026 RFC-2492 3.1.6 conditionally mandatory 1027 RFC-2497 3.1.7 conditionally mandatory 1028 RFC-2529 3.1.8 unconditionally optional 1029 RFC-2590 3.1.9 conditionally mandatory 1030 RFC-2675 4.3.2 unconditionally optional 1031 RFC-2710 4.6.2 conditionally mandatory 1032 RFC-2711 9.1.1 conditionally mandatory 1033 RFC-2732 5.2.2 conditionally mandatory 1034 RFC-2851 10.1.5 conditionally mandatory 1035 RFC-2874 5.3.1 unconditionally optional 1036 RFC-2893 6.1.1 conditionally mandatory 1037 RFC-3019 10.1.6 conditionally mandatory 1038 RFC-3041 4.5.3 unconditionally optional 1040 Appendix C: Specifications Not Included 1042 Here is a list of documents considered, but not included in this document. In general, Information documents are not considered to place requirements on implementations. Experimental documents are just that, experimental, and cannot place requirements on the general behavior of IPv6 nodes. 1044 Upper Protocols 1045 2428 FTP Extensions For IPv6 And NATs 1047 Compression 1048 2507 IP Header Compression 1049 2508 Compressing IP/UDP/RTP Headers For Low-Speed Serial Links 1050 2509 IP Header Compression Over PPP 1052 Informational 1053 1752 The Recommendation For The IP Next Generation Protocol API RFCs 1054 1881 IPv6 Address Allocation Management. 1055 1887 An Architecture For Ipv6 Unicast Address Allocation 1056 2104 HMAC: Keyed-Hashing For Message Authentication 1057 2374 An IPv6 Aggregatable Global Unicast Address Format. 1058 2450 Proposed TLA And NLA Assignment Rules. 1060 Experimental 1061 2874 DNS Extensions To Support Ipv6 Address Aggregation 1062 2471 IPv6 Testing Address Allocation. 1064 Other 1065 2526 Reserved IPv6 Subnet Anycast 1066 2732 Format For Literal IPv6 Addr In URLs 1067 2894 Router Renumbering 1068 3122 Extensions To IPv6 ND For Inverse Discovery