idnits 2.17.1 draft-clw-rfc6434-bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: [RFC6946] discusses IPv6 atomic fragments, and recommends that IPv6 atomic fragments are processed independently of any other fragments, to protect against fragmenttation-based attacks. [RFC8021] goes further and recommends the deprecation of atomic fragments. Nodes thus MUST not generate atomic fragments. -- The document date (March 13, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4307 (Obsoleted by RFC 8247) ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5006 (Obsoleted by RFC 6106) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Chown 3 Internet-Draft Jisc 4 Obsoletes: 6434 (if approved) J. Loughney 5 Intended status: Informational Nokia 6 Expires: September 14, 2017 T. Winters 7 University of New Hampshire 8 March 13, 2017 10 IPv6 Node Requirements 11 draft-clw-rfc6434-bis-01 13 Abstract 15 This document defines requirements for IPv6 nodes. It is expected 16 that IPv6 will be deployed in a wide range of devices and situations. 17 Specifying the requirements for IPv6 nodes allows IPv6 to function 18 well and interoperate in a large number of situations and 19 deployments. 21 This document obsoletes RFC 6434, and in turn RFC 4294. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 14, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Scope of This Document . . . . . . . . . . . . . . . . . 4 59 1.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 4 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 61 3. Abbreviations Used in This Document . . . . . . . . . . . . . 5 62 4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . 6 65 5.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 7 66 5.3. Default Router Preferences and More-Specific Routes - 67 RFC 4191 . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.4. SEcure Neighbor Discovery (SEND) - RFC 3971 . . . . . . . 9 69 5.5. IPv6 Router Advertisement Flags Option - RFC 5175 . 9 70 5.6. Path MTU Discovery and Packet Size . . . . . . . . . . . 10 71 5.6.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 10 72 5.7. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . 10 73 5.8. ICMP for the Internet Protocol Version 6 (IPv6) - 74 RFC 4443 . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.9. Addressing . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.9.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 11 77 5.9.2. Host Address Availability Recommendations . . . . . . 11 78 5.9.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 11 79 5.9.4. Privacy Extensions for Address Configuration in IPv6 80 - RFC 4941 . . . . . . . . . . . . . . . . . . . . . 12 81 5.9.5. Default Address Selection for IPv6 - RFC 6724 . . . . 13 82 5.9.6. Stateful Address Autoconfiguration (DHCPv6) - RFC 83 3315 . . . . . . . . . . . . . . . . . . . . . . . . 13 84 5.10. Multicast Listener Discovery (MLD) for IPv6 . . . . . . . 13 85 6. DHCP versus Router Advertisement Options for Host 86 Configuration . . . . . . . . . . . . . . . . . . . . . . . . 14 87 7. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . 15 88 7.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 7.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - 90 RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 15 91 7.2.1. Other Configuration Information . . . . . . . . . . . 15 92 7.2.2. Use of Router Advertisements in Managed Environments 16 93 7.3. IPv6 Router Advertisement Options for DNS 94 Configuration - RFC 6106 . . . . . . . . . . . . . . . . 16 95 8. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 16 96 8.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 16 97 8.1.1. Basic Transition Mechanisms for IPv6 Hosts and 98 Routers - RFC 4213 . . . . . . . . . . . . . . . . . 16 99 9. Application Support . . . . . . . . . . . . . . . . . . . . . 16 100 9.1. Textual Representation of IPv6 Addresses - RFC 5952 . 16 101 9.2. Application Programming Interfaces (APIs) . . . . . . . . 17 102 10. Cellular Host . . . . . . . . . . . . . . . . . . . . . . . . 17 103 11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 17 104 11.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 18 105 11.2. Transforms and Algorithms . . . . . . . . . . . . . . . 19 106 12. Router-Specific Functionality . . . . . . . . . . . . . . . . 19 107 12.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . 19 108 12.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 19 109 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 20 110 13. Network Management . . . . . . . . . . . . . . . . . . . . . 20 111 13.1. Management Information Base (MIB) Modules . . . . . . . 20 112 13.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 21 113 13.1.2. Management Information Base for the Internet 114 Protocol (IP) . . . . . . . . . . . . . . . . . . . 21 115 14. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 21 116 15. Security Considerations . . . . . . . . . . . . . . . . . . . 21 117 16. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 21 118 16.1. Authors and Acknowledgments (Current Document) . . . . . 21 119 16.2. Authors and Acknowledgments from RFC 6434 . . . . . . . 21 120 16.3. Authors and Acknowledgments from RFC 4294 . . . . . . . 21 121 17. Appendix: Changes from RFC 6434 . . . . . . . . . . . . . . . 23 122 18. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 23 123 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 124 19.1. Normative References . . . . . . . . . . . . . . . . . . 24 125 19.2. Informative References . . . . . . . . . . . . . . . . . 30 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 128 1. Introduction 130 This document defines common functionality required from both IPv6 131 hosts and routers. Many IPv6 nodes will implement optional or 132 additional features, but this document collects and summarizes 133 requirements from other published Standards Track documents in one 134 place. 136 This document tries to avoid discussion of protocol details and 137 references RFCs for this purpose. This document is intended to be an 138 applicability statement and to provide guidance as to which IPv6 139 specifications should be implemented in the general case and which 140 specifications may be of interest to specific deployment scenarios. 141 This document does not update any individual protocol document RFCs. 143 Although this document points to different specifications, it should 144 be noted that in many cases, the granularity of a particular 145 requirement will be smaller than a single specification, as many 146 specifications define multiple, independent pieces, some of which may 147 not be mandatory. In addition, most specifications define both 148 client and server behavior in the same specification, while many 149 implementations will be focused on only one of those roles. 151 This document defines a minimal level of requirement needed for a 152 device to provide useful internet service and considers a broad range 153 of device types and deployment scenarios. Because of the wide range 154 of deployment scenarios, the minimal requirements specified in this 155 document may not be sufficient for all deployment scenarios. It is 156 perfectly reasonable (and indeed expected) for other profiles to 157 define additional or stricter requirements appropriate for specific 158 usage and deployment environments. For example, this document does 159 not mandate that all clients support DHCP, but some deployment 160 scenarios may deem it appropriate to make such a requirement. For 161 example, government agencies in the USA have defined profiles for 162 specialized requirements for IPv6 in target environments (see 163 [USGv6]). 165 As it is not always possible for an implementer to know the exact 166 usage of IPv6 in a node, an overriding requirement for IPv6 nodes is 167 that they should adhere to Jon Postel's Robustness Principle: "Be 168 conservative in what you do, be liberal in what you accept from 169 others" [RFC0793]. 171 1.1. Scope of This Document 173 IPv6 covers many specifications. It is intended that IPv6 will be 174 deployed in many different situations and environments. Therefore, 175 it is important to develop requirements for IPv6 nodes to ensure 176 interoperability. 178 This document assumes that all IPv6 nodes meet the minimum 179 requirements specified here. 181 1.2. Description of IPv6 Nodes 183 From the Internet Protocol, Version 6 (IPv6) Specification [RFC2460], 184 we have the following definitions: 186 IPv6 node - a device that implements IPv6. 187 IPv6 router - a node that forwards IPv6 packets not explicitly 188 addressed to itself. 189 IPv6 host - any node that is not a router. 191 **BIS We will need to refer to 2460-bis, as well as 1981-bis and 192 4291-bis, throughout this document. These are still in flux, but we 193 will know the final versions of these documents before this -bis is 194 published, so can adapt text here once those updates are complete.** 196 2. Requirements Language 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in RFC 2119 [RFC2119]. 202 3. Abbreviations Used in This Document 204 ATM Asynchronous Transfer Mode 205 AH Authentication Header 206 DAD Duplicate Address Detection 207 ESP Encapsulating Security Payload 208 ICMP Internet Control Message Protocol 209 IKE Internet Key Exchange 210 MIB Management Information Base 211 MLD Multicast Listener Discovery 212 MTU Maximum Transmission Unit 213 NA Neighbor Advertisement 214 NBMA Non-Broadcast Multiple Access 215 ND Neighbor Discovery 216 NS Neighbor Solicitation 217 NUD Neighbor Unreachability Detection 218 PPP Point-to-Point Protocol 220 4. Sub-IP Layer 222 An IPv6 node must include support for one or more IPv6 link-layer 223 specifications. Which link-layer specifications an implementation 224 should include will depend upon what link-layers are supported by the 225 hardware available on the system. It is possible for a conformant 226 IPv6 node to support IPv6 on some of its interfaces and not on 227 others. 229 As IPv6 is run over new layer 2 technologies, it is expected that new 230 specifications will be issued. In the following, we list some of the 231 layer 2 technologies for which an IPv6 specification has been 232 developed. It is provided for informational purposes only and may 233 not be complete. 235 - Transmission of IPv6 Packets over Ethernet Networks [RFC2464] 237 - IPv6 over ATM Networks [RFC2492] 239 - Transmission of IPv6 Packets over Frame Relay Networks 240 Specification [RFC2590] 242 - Transmission of IPv6 Packets over IEEE 1394 Networks [RFC3146] 244 - Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) 245 Packets over Fibre Channel [RFC4338] 247 - Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944] 249 - Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 250 802.16 Networks [RFC5121] 252 - IP version 6 over PPP [RFC5072] 254 - IPv6 over IEEE 802.15.4 Networks [RFC4944] 256 In addition to traditional physical link-layers, it is also possible 257 to tunnel IPv6 over other protocols. Examples include: 259 - Teredo: Tunneling IPv6 over UDP through Network Address 260 Translations (NATs) [RFC4380] 262 - Section 3 of "Basic Transition Mechanisms for IPv6 Hosts and 263 Routers" [RFC4213] 265 **BIS Do we want a small section somewhere on UDP IPv6 tunneling, and 266 issues like RFC 6935, or 6936?** 268 5. IP Layer 270 5.1. Internet Protocol Version 6 - RFC 2460 272 The Internet Protocol Version 6 is specified in [RFC2460]. This 273 specification MUST be supported. 275 **BIS Again, update for RFC 2460 -bis ** 277 Any unrecognized extension headers or options MUST be processed as 278 described in RFC 2460. 280 The node MUST follow the packet transmission rules in RFC 2460. 282 Nodes MUST always be able to send, receive, and process fragment 283 headers. All conformant IPv6 implementations MUST be capable of 284 sending and receiving IPv6 packets; the forwarding functionality MAY 285 be supported. Overlapping fragments MUST be handled as described in 286 [RFC5722]. 288 [RFC6946] discusses IPv6 atomic fragments, and recommends that IPv6 289 atomic fragments are processed independently of any other fragments, 290 to protect against fragmenttation-based attacks. [RFC8021] goes 291 further and recommends the deprecation of atomic fragments. Nodes 292 thus MUST not generate atomic fragments. 294 To mitigate a variety of potential attacks, nodes SHOULD avoid using 295 predictable fragment Identification values in Fragment Headers, as 296 discussed in [RFC7739]. 298 RFC 2460 specifies extension headers and the processing for these 299 headers. 301 An IPv6 node MUST be able to process these headers. An exception is 302 Routing Header type 0 (RH0), which was deprecated by [RFC5095] due to 303 security concerns and which MUST be treated as an unrecognized 304 routing type. 306 Should a new type of Extension Header need to be defined, its format 307 MUST follow the consistent format described in Section 4 of 308 [RFC6564]. 310 Further, [RFC7045] adds specific requirements for processing of 311 Extension Headers, in particular that any forwarding node along an 312 IPv6 packet's path, which forwards the packet for any reason, SHOULD 313 do so regardless of any extension headers that are present. 315 [RFC7112] discusses issues with oversized IPv6 Extension Header 316 chains, and states that when a node fragments an IPv6 datagram, it 317 MUST include the entire IPv6 Header Chain in the First Fragment. 319 **BIS Wait to see outcome of insertion of EHs issue in 2460-bis, and 320 re-state here? ** 322 All nodes SHOULD support the setting and use of the IPv6 Flow Label 323 field as defined in the IPv6 Flow Label specification [RFC6437]. 324 Forwarding nodes such as routers and load distributors MUST NOT 325 depend only on Flow Label values being uniformly distributed. It is 326 RECOMMENDED that source hosts support the flow label by setting the 327 Flow Label field for all packets of a given flow to the same value 328 chosen from an approximation to a discrete uniform distribution. 330 5.2. Neighbor Discovery for IPv6 - RFC 4861 332 Neighbor Discovery is defined in [RFC4861]; the definition was 333 updated by [RFC5942]. Neighbor Discovery SHOULD be supported. RFC 334 4861 states: 336 Unless specified otherwise (in a document that covers operating IP 337 over a particular link type) this document applies to all link 338 types. However, because ND uses link-layer multicast for some of 339 its services, it is possible that on some link types (e.g., Non- 340 Broadcast Multi-Access (NBMA) links), alternative protocols or 341 mechanisms to implement those services will be specified (in the 342 appropriate document covering the operation of IP over a 343 particular link type). The services described in this document 344 that are not directly dependent on multicast, such as Redirects, 345 next-hop determination, Neighbor Unreachability Detection, etc., 346 are expected to be provided as specified in this document. The 347 details of how one uses ND on NBMA links are addressed in 348 [RFC2491]. 350 Some detailed analysis of Neighbor Discovery follows: 352 Router Discovery is how hosts locate routers that reside on an 353 attached link. Hosts MUST support Router Discovery functionality. 355 Prefix Discovery is how hosts discover the set of address prefixes 356 that define which destinations are on-link for an attached link. 357 Hosts MUST support Prefix Discovery. 359 Hosts MUST also implement Neighbor Unreachability Detection (NUD) for 360 all paths between hosts and neighboring nodes. NUD is not required 361 for paths between routers. However, all nodes MUST respond to 362 unicast Neighbor Solicitation (NS) messages. 364 [RFC7048] discusses NUD, in particular cases where it behaves too 365 impatiently. It states that if a node transmits more than a certain 366 number of packets, then it SHOULD use the exponential backoff of the 367 retransmit timer, up to a certain threshold point. 369 Hosts MUST support the sending of Router Solicitations and the 370 receiving of Router Advertisements. The ability to understand 371 individual Router Advertisement options is dependent on supporting 372 the functionality making use of the particular option. 374 [RFC7559] discusses packet loss resliency for Router Solicitations, 375 and requires that nodes MUST use a specific exponential backoff 376 algorithm for RS retransmissions. 378 All nodes MUST support the sending and receiving of Neighbor 379 Solicitation (NS) and Neighbor Advertisement (NA) messages. NS and 380 NA messages are required for Duplicate Address Detection (DAD). 382 Hosts SHOULD support the processing of Redirect functionality. 383 Routers MUST support the sending of Redirects, though not necessarily 384 for every individual packet (e.g., due to rate limiting). Redirects 385 are only useful on networks supporting hosts. In core networks 386 dominated by routers, Redirects are typically disabled. The sending 387 of Redirects SHOULD be disabled by default on backbone routers. They 388 MAY be enabled by default on routers intended to support hosts on 389 edge networks. 391 "IPv6 Host-to-Router Load Sharing" [RFC4311] includes additional 392 recommendations on how to select from a set of available routers. 393 [RFC4311] SHOULD be supported. 395 5.3. Default Router Preferences and More-Specific Routes - RFC 4191 397 "Default Router Preferences and More-Specific Routes" [RFC4191] 398 provides support for nodes attached to multiple (different) networks, 399 each providing routers that advertise themselves as default routers 400 via Router Advertisements. In some scenarios, one router may provide 401 connectivity to destinations the other router does not, and choosing 402 the "wrong" default router can result in reachability failures. In 403 such cases, RFC 4191 can help. 405 Small Office/Home Office (SOHO) deployments supported by routers 406 adhering to [RFC7084] use RFC 4191 to advertise routes to certain 407 local destinations. Consequently, nodes that will be deployed in 408 SOHO environments SHOULD implement RFC 4191. 410 5.4. SEcure Neighbor Discovery (SEND) - RFC 3971 412 SEND [RFC3971] and Cryptographically Generated Addresses (CGAs) 413 [RFC3972] provide a way to secure the message exchanges of Neighbor 414 Discovery. SEND has the potential to address certain classes of 415 spoofing attacks, but it does not provide specific protection for 416 threats from off-link attackers. It requires relatively heavyweight 417 provisioning, so is only likely to be used in scenarios where 418 security considerations are particularly important. 420 There have been relatively few implementations of SEND in common 421 operating systems and platforms, and thus deployment experience has 422 been limited to date. 424 At this time, SEND is considered optional. Due to the complexity in 425 deploying SEND, its deployment is only likely to be considered where 426 nodes are operating in a particularly strict security environment. 428 5.5. IPv6 Router Advertisement Flags Option - RFC 5175 430 Router Advertisements include an 8-bit field of single-bit Router 431 Advertisement flags. The Router Advertisement Flags Option extends 432 the number of available flag bits by 48 bits. At the time of this 433 writing, 6 of the original 8 single-bit flags have been assigned, 434 while 2 remain available for future assignment. No flags have been 435 defined that make use of the new option, and thus, strictly speaking, 436 there is no requirement to implement the option today. However, 437 implementations that are able to pass unrecognized options to a 438 higher-level entity that may be able to understand them (e.g., a 439 user-level process using a "raw socket" facility) MAY take steps to 440 handle the option in anticipation of a future usage. 442 5.6. Path MTU Discovery and Packet Size 444 5.6.1. Path MTU Discovery - RFC 1981 446 "Path MTU Discovery for IP version 6" [RFC1981] SHOULD be supported. 447 From [RFC2460]: 449 It is strongly recommended that IPv6 nodes implement Path MTU 450 Discovery [RFC1981], in order to discover and take advantage of 451 path MTUs greater than 1280 octets. However, a minimal IPv6 452 implementation (e.g., in a boot ROM) may simply restrict itself to 453 sending packets no larger than 1280 octets, and omit 454 implementation of Path MTU Discovery. 456 The rules in [RFC2460] and [RFC5722] MUST be followed for packet 457 fragmentation and reassembly. 459 One operational issue with Path MTU Discovery occurs when firewalls 460 block ICMP Packet Too Big messages. Path MTU Discovery relies on 461 such messages to determine what size messages can be successfully 462 sent. "Packetization Layer Path MTU Discovery" [RFC4821] avoids 463 having a dependency on Packet Too Big messages. 465 **BIS Add note about 1280 MTU and UDP, as per Mark Andrews' comments 466 in Berlin? ** 468 5.7. IPv6 Jumbograms - RFC 2675 470 IPv6 Jumbograms [RFC2675] are an optional extension that allow the 471 sending of IP datagrams larger than 65.535 bytes. IPv6 Jumbograms 472 make use of IPv6 hop-by-hop options and are only suitable on paths in 473 which every hop and link are capable of supporting Jumbograms (e.g., 474 within a campus or datacenter). To date, few implementations exist, 475 and there is essentially no reported experience from usage. 476 Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time. 478 **BIS Are these used? Do we need to modify the text for that? ** 480 5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 482 ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi- 483 Part Messages" [RFC4884] MAY be supported. 485 5.9. Addressing 487 5.9.1. IP Version 6 Addressing Architecture - RFC 4291 489 The IPv6 Addressing Architecture [RFC4291] MUST be supported. 491 **BIS Update to 4291-bis ** 493 **BIS Add note on Why /64? RFC 7421, after the conclusion of the 494 RFC4291-bis (lengthy!!!) discussions on the 64-bit IID topic. But no 495 need for /127 p2p text RFC 6164. And no need for note on IID 496 significance, as per RFC 7136. ** 498 5.9.2. Host Address Availability Recommendations 500 Hosts may be configured with addresses through a variety of methods, 501 including SLAAC, DHCPv6, or manual configuration. 503 [RFC7934] recommends that networks provide general-purpose end hosts 504 with multiple global IPv6 addresses when they attach, and it 505 describes the benefits of and the options for doing so. There are, 506 for example, benefits to multiple addresses for privacy reasons, or 507 to assigning hosts a whole /64 to avoid the need for host-based NAT. 509 5.9.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 511 Hosts MUST support IPv6 Stateless Address Autoconfiguration as 512 defined in either [RFC4862] or [RFC7217]. It is recommended that, 513 unless there is a specific requirement for MAC addresses to be 514 embedded in an IID, nodes follow the procedure in RFC7217 to generate 515 SLAAC-based addresses. Addresses generated through RFC7217 will be 516 the same whenever a given device (re)appears on the same subnet (with 517 a specific IPv6 prefix), but the IID will vary on each subnet 518 visited. 520 Nodes that are routers MUST be able to generate link-local addresses 521 as described in [RFC4862]. 523 From RFC 4862: 525 The autoconfiguration process specified in this document applies 526 only to hosts and not routers. Since host autoconfiguration uses 527 information advertised by routers, routers will need to be 528 configured by some other means. However, it is expected that 529 routers will generate link-local addresses using the mechanism 530 described in this document. In addition, routers are expected to 531 successfully pass the Duplicate Address Detection procedure 532 described in this document on all addresses prior to assigning 533 them to an interface. 535 All nodes MUST implement Duplicate Address Detection. Quoting from 536 Section 5.4 of RFC 4862: 538 Duplicate Address Detection MUST be performed on all unicast 539 addresses prior to assigning them to an interface, regardless of 540 whether they are obtained through stateless autoconfiguration, 541 DHCPv6, or manual configuration, with the following [exceptions 542 noted therein]. 544 "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429] 545 specifies a mechanism to reduce delays associated with generating 546 addresses via Stateless Address Autoconfiguration [RFC4862]. RFC 547 4429 was developed in conjunction with Mobile IPv6 in order to reduce 548 the time needed to acquire and configure addresses as devices quickly 549 move from one network to another, and it is desirable to minimize 550 transition delays. For general purpose devices, RFC 4429 remains 551 optional at this time. 553 [RFC7527] discusses enhanced DAD, and describes an algorithm to 554 automate the detection of looped back IPv6 ND messages used by DAD. 555 Nodes SHOULD implement this behaviour where such detection is 556 beneficial. 558 5.9.4. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 560 A node using Stateless Address Autoconfiguration [RFC4862] to form a 561 globally unique IPv6 address using its MAC address to generate the 562 IID will see that IID remain the same on any visited network, even 563 though the network prefix part changes. Thus it is possible for 3rd 564 party devices such nodes communicate with to track the activities of 565 the node as it moves around the network. Privacy Extensions for 566 Stateless Address Autoconfiguration [RFC4941] address this concern by 567 allowing nodes to configure an additional temporary address where the 568 IID is effectively randomly generated. Privacy addresses are then 569 used as source addresses for new communications initiated by the 570 node. 572 [RFC7721] discusses general privacy issues with IPv6 addressing. 574 RFC 4941 SHOULD be supported. In some scenarios, such as dedicated 575 servers in a data center, it provides limited or no benefit, or may 576 complicate network management. Thus devices implementing this 577 specification MUST provide a way for the end user to explicitly 578 enable or disable the use of such temporary addresses. 580 Note that RFC4941 can be used independently of traditional SLAAC, or 581 of RFC7217-based SLAAC. 583 Implementers of RFC 4941 should be aware that certain addresses are 584 reserved and should not be chosen for use as temporary addresses. 585 Consult "Reserved IPv6 Interface Identifiers" [RFC5453] for more 586 details. 588 5.9.5. Default Address Selection for IPv6 - RFC 6724 590 IPv6 nodes will invariably have multiple addresses configured 591 simultaneously, and thus will need to choose which addresses to use 592 for which communications. The rules specified in the Default Address 593 Selection for IPv6 [RFC6724] document MUST be implemented. 595 5.9.6. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 597 DHCPv6 [RFC3315] can be used to obtain and configure addresses. In 598 general, a network may provide for the configuration of addresses 599 through Router Advertisements, DHCPv6, or both. There will be a wide 600 range of IPv6 deployment models and differences in address assignment 601 requirements, some of which may require DHCPv6 for stateful address 602 assignment. Consequently, all hosts SHOULD implement address 603 configuration via DHCPv6. 605 In the absence of a router, IPv6 nodes using DHCP for address 606 assignment MAY initiate DHCP to obtain IPv6 addresses and other 607 configuration information, as described in Section 5.5.2 of 608 [RFC4862]. 610 5.10. Multicast Listener Discovery (MLD) for IPv6 612 **BIS MLDv2 only? 614 Nodes that need to join multicast groups MUST support MLDv1 615 [RFC2710]. MLDv1 is needed by any node that is expected to receive 616 and process multicast traffic. Note that Neighbor Discovery (as used 617 on most link types -- see Section 5.2) depends on multicast and 618 requires that nodes join Solicited Node multicast addresses. 620 MLDv2 [RFC3810] extends the functionality of MLDv1 by supporting 621 Source-Specific Multicast. The original MLDv2 protocol [RFC3810] 622 supporting Source-Specific Multicast [RFC4607] supports two types of 623 "filter modes". Using an INCLUDE filter, a node indicates a 624 multicast group along with a list of senders for the group from which 625 it wishes to receive traffic. Using an EXCLUDE filter, a node 626 indicates a multicast group along with a list of senders from which 627 it wishes to exclude receiving traffic. In practice, operations to 628 block source(s) using EXCLUDE mode are rarely used but add 629 considerable implementation complexity to MLDv2. Lightweight MLDv2 630 [RFC5790] is a simplified subset of the original MLDv2 specification 631 that omits EXCLUDE filter mode to specify undesired source(s). 633 Nodes SHOULD implement either MLDv2 [RFC3810] or Lightweight MLDv2 634 [RFC5790]. Specifically, nodes supporting applications using Source- 635 Specific Multicast that expect to take advantage of MLDv2's EXCLUDE 636 functionality [RFC3810] MUST support MLDv2 as defined in [RFC3810], 637 [RFC4604], and [RFC4607]. Nodes supporting applications that expect 638 to only take advantage of MLDv2's INCLUDE functionality as well as 639 Any-Source Multicast will find it sufficient to support Lightweight 640 MLDv2 as defined in [RFC5790]. 642 If a node only supports applications that use Any-Source Multicast 643 (i.e, they do not use Source-Specific Multicast), implementing MLDv1 644 [RFC2710] is sufficient. In all cases, however, nodes are strongly 645 encouraged to implement MLDv2 or Lightweight MLDv2 rather than MLDv1, 646 as the presence of a single MLDv1 participant on a link requires that 647 all other nodes on the link operate in version 1 compatibility mode. 649 When MLDv1 is used, the rules in the Source Address Selection for the 650 Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be 651 followed. 653 6. DHCP versus Router Advertisement Options for Host Configuration 655 **BIS this section probably needs rewriting ** 657 In IPv6, there are two main protocol mechanisms for propagating 658 configuration information to hosts: Router Advertisements (RAs) and 659 DHCP. Historically, RA options have been restricted to those deemed 660 essential for basic network functioning and for which all nodes are 661 configured with exactly the same information. Examples include the 662 Prefix Information Options, the MTU option, etc. On the other hand, 663 DHCP has generally been preferred for configuration of more general 664 parameters and for parameters that may be client-specific. That 665 said, identifying the exact line on whether a particular option 666 should be configured via DHCP versus an RA option has not always been 667 easy. Generally speaking, however, there has been a desire to define 668 only one mechanism for configuring a given option, rather than 669 defining multiple (different) ways of configuring the same 670 information. 672 One issue with having multiple ways of configuring the same 673 information is that interoperability suffers if a host chooses one 674 mechanism but the network operator chooses a different mechanism. 675 For "closed" environments, where the network operator has significant 676 influence over what devices connect to the network and thus what 677 configuration mechanisms they support, the operator may be able to 678 ensure that a particular mechanism is supported by all connected 679 hosts. In more open environments, however, where arbitrary devices 680 may connect (e.g., a WIFI hotspot), problems can arise. To maximize 681 interoperability in such environments, hosts would need to implement 682 multiple configuration mechanisms to ensure interoperability. 684 7. DNS and DHCP 686 7.1. DNS 688 DNS is described in [RFC1034], [RFC1035], [RFC3363], and [RFC3596]. 689 Not all nodes will need to resolve names; those that will never need 690 to resolve DNS names do not need to implement resolver functionality. 691 However, the ability to resolve names is a basic infrastructure 692 capability on which applications rely, and most nodes will need to 693 provide support. All nodes SHOULD implement stub-resolver [RFC1034] 694 functionality, as in [RFC1034], Section 5.3.1, with support for: 696 - AAAA type Resource Records [RFC3596]; 698 - reverse addressing in ip6.arpa using PTR records [RFC3596]; 700 - Extension Mechanisms for DNS (EDNS0) [RFC2671] to allow for DNS 701 packet sizes larger than 512 octets. 703 Those nodes are RECOMMENDED to support DNS security extensions 704 [RFC4033] [RFC4034] [RFC4035]. 706 A6 Resource Records, which were only ever defined with Experimental 707 status in [RFC3363], are now classified as Historic, as per 708 [RFC6563]. 710 **BIS Add DNS-SD? ** 712 7.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315 714 7.2.1. Other Configuration Information 716 IPv6 nodes use DHCP [RFC3315] to obtain address configuration 717 information (see Section 5.9.6) and to obtain additional (non- 718 address) configuration. If a host implementation supports 719 applications or other protocols that require configuration that is 720 only available via DHCP, hosts SHOULD implement DHCP. For 721 specialized devices on which no such configuration need is present, 722 DHCP may not be necessary. 724 An IPv6 node can use the subset of DHCP (described in [RFC3736]) to 725 obtain other configuration information. 727 7.2.2. Use of Router Advertisements in Managed Environments 729 Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 730 are expected to determine their default router information and on- 731 link prefix information from received Router Advertisements. There 732 is no defined DHCPv6 Gateway option. 734 7.3. IPv6 Router Advertisement Options for DNS Configuration - RFC 6106 736 Router Advertisements have historically limited options to those that 737 are critical to basic IPv6 functioning. Originally, DNS 738 configuration was not included as an RA option, and DHCP was the 739 recommended way to obtain DNS configuration information. Over time, 740 the thinking surrounding such an option has evolved. It is now 741 generally recognized that few nodes can function adequately without 742 having access to a working DNS resolver. [RFC5006] was published as 743 an Experimental document in 2007, and recently, a revised version was 744 placed on the Standards Track [RFC6106]. 746 Implementations SHOULD implement the DNS RA option [RFC6106]. 748 8. IPv4 Support and Transition 750 IPv6 nodes MAY support IPv4. 752 8.1. Transition Mechanisms 754 8.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC 755 4213 757 If an IPv6 node implements dual stack and tunneling, then [RFC4213] 758 MUST be supported. 760 9. Application Support 762 9.1. Textual Representation of IPv6 Addresses - RFC 5952 764 Software that allows users and operators to input IPv6 addresses in 765 text form SHOULD support "A Recommendation for IPv6 Address Text 766 Representation" [RFC5952]. 768 9.2. Application Programming Interfaces (APIs) 770 There are a number of IPv6-related APIs. This document does not 771 mandate the use of any, because the choice of API does not directly 772 relate to on-the-wire behavior of protocols. Implementers, however, 773 would be advised to consider providing a common API or reviewing 774 existing APIs for the type of functionality they provide to 775 applications. 777 "Basic Socket Interface Extensions for IPv6" [RFC3493] provides IPv6 778 functionality used by typical applications. Implementers should note 779 that RFC3493 has been picked up and further standardized by the 780 Portable Operating System Interface (POSIX) [POSIX]. 782 "Advanced Sockets Application Program Interface (API) for IPv6" 783 [RFC3542] provides access to advanced IPv6 features needed by 784 diagnostic and other more specialized applications. 786 "IPv6 Socket API for Source Address Selection" [RFC5014] provides 787 facilities that allow an application to override the default Source 788 Address Selection rules of [RFC6724]. 790 "Socket Interface Extensions for Multicast Source Filters" [RFC3678] 791 provides support for expressing source filters on multicast group 792 memberships. 794 "Extension to Sockets API for Mobile IPv6" [RFC4584] provides 795 application support for accessing and enabling Mobile IPv6 [RFC6275] 796 features. 798 10. Cellular Host 800 IPv6 for 3GPP [RFC7066] lists IPv6 Functionalities that need to be 801 implemented above and beyond the recommendations in this document. 802 Additionally a 3GPP IPv6 Host MAY implement [RFC7278] for delivering 803 IPv6 prefixes on the LAN link. 805 11. Security 807 This section describes the specification for security for IPv6 nodes. 809 Achieving security in practice is a complex undertaking. Operational 810 procedures, protocols, key distribution mechanisms, certificate 811 management approaches, etc., are all components that impact the level 812 of security actually achieved in practice. More importantly, 813 deficiencies or a poor fit in any one individual component can 814 significantly reduce the overall effectiveness of a particular 815 security approach. 817 IPsec provides channel security at the Internet layer, making it 818 possible to provide secure communication for all (or a subset of) 819 communication flows at the IP layer between pairs of internet nodes. 820 IPsec provides sufficient flexibility and granularity that individual 821 TCP connections can (selectively) be protected, etc. 823 Although IPsec can be used with manual keying in some cases, such 824 usage has limited applicability and is not recommended. 826 A range of security technologies and approaches proliferate today 827 (e.g., IPsec, Transport Layer Security (TLS), Secure SHell (SSH), 828 etc.) No one approach has emerged as an ideal technology for all 829 needs and environments. Moreover, IPsec is not viewed as the ideal 830 security technology in all cases and is unlikely to displace the 831 others. 833 Previously, IPv6 mandated implementation of IPsec and recommended the 834 key management approach of IKE. This document updates that 835 recommendation by making support of the IPsec Architecture [RFC4301] 836 a SHOULD for all IPv6 nodes. Note that the IPsec Architecture 837 requires (e.g., Section 4.5 of RFC 4301) the implementation of both 838 manual and automatic key management. Currently, the default 839 automated key management protocol to implement is IKEv2 [RFC5996]. 841 This document recognizes that there exists a range of device types 842 and environments where approaches to security other than IPsec can be 843 justified. For example, special-purpose devices may support only a 844 very limited number or type of applications, and an application- 845 specific security approach may be sufficient for limited management 846 or configuration capabilities. Alternatively, some devices may run 847 on extremely constrained hardware (e.g., sensors) where the full 848 IPsec Architecture is not justified. 850 **BIS Add note on security in IPv4-only networks? RFC 7123? 851 Relevant? ** 853 11.1. Requirements 855 "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be 856 supported by all IPv6 nodes. Note that the IPsec Architecture 857 requires (e.g., Section 4.5 of [RFC4301]) the implementation of both 858 manual and automatic key management. Currently, the default 859 automated key management protocol to implement is IKEv2. As required 860 in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST 861 implement ESP [RFC4303] and MAY implement AH [RFC4302]. 863 11.2. Transforms and Algorithms 865 The current set of mandatory-to-implement algorithms for the IPsec 866 Architecture are defined in "Cryptographic Algorithm Implementation 867 Requirements For ESP and AH" [RFC4835]. IPv6 nodes implementing the 868 IPsec Architecture MUST conform to the requirements in [RFC4835]. 869 Preferred cryptographic algorithms often change more frequently than 870 security protocols. Therefore, implementations MUST allow for 871 migration to new algorithms, as RFC 4835 is replaced or updated in 872 the future. 874 **BIS update to 7321bis** 876 The current set of mandatory-to-implement algorithms for IKEv2 are 877 defined in "Cryptographic Algorithms for Use in the Internet Key 878 Exchange Version 2 (IKEv2)" [RFC4307]. IPv6 nodes implementing IKEv2 879 MUST conform to the requirements in [RFC4307] and/or any future 880 updates or replacements to [RFC4307]. 882 **BIS update to 4307bis** 884 12. Router-Specific Functionality 886 This section defines general host considerations for IPv6 nodes that 887 act as routers. Currently, this section does not discuss routing- 888 specific requirements; for the case of typical home routers, 889 [RFC7084] defines basic requirements for customer edge routers. 891 **BIS Sync here with work by John Brzozowski et al. in draft-ali- 892 ipv6rtr-reqs-02** 894 12.1. IPv6 Router Alert Option - RFC 2711 896 The IPv6 Router Alert Option [RFC2711] is an optional IPv6 Hop-by-Hop 897 Header that is used in conjunction with some protocols (e.g., RSVP 898 [RFC2205] or Multicast Listener Discovery (MLD) [RFC2710]). The 899 Router Alert option will need to be implemented whenever protocols 900 that mandate its usage (e.g., MLD) are implemented. See 901 Section 5.10. 903 12.2. Neighbor Discovery for IPv6 - RFC 4861 905 Sending Router Advertisements and processing Router Solicitations 906 MUST be supported. 908 Section 7 of [RFC6275] includes some mobility-specific extensions to 909 Neighbor Discovery. Routers SHOULD implement Sections 7.3 and 7.5, 910 even if they do not implement Home Agent functionality. 912 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 914 A single DHCP server ([RFC3315] or [RFC4862]) can provide 915 configuration information to devices directly attached to a shared 916 link, as well as to devices located elsewhere within a site. 917 Communication between a client and a DHCP server located on different 918 links requires the use of DHCP relay agents on routers. 920 In simple deployments, consisting of a single router and either a 921 single LAN or multiple LANs attached to the single router, together 922 with a WAN connection, a DHCP server embedded within the router is 923 one common deployment scenario (e.g., [RFC7084]). However, there is 924 no need for relay agents in such scenarios. 926 In more complex deployment scenarios, such as within enterprise or 927 service provider networks, the use of DHCP requires some level of 928 configuration, in order to configure relay agents, DHCP servers, etc. 929 In such environments, the DHCP server might even be run on a 930 traditional server, rather than as part of a router. 932 Because of the wide range of deployment scenarios, support for DHCP 933 server functionality on routers is optional. However, routers 934 targeted for deployment within more complex scenarios (as described 935 above) SHOULD support relay agent functionality. Note that "Basic 936 Requirements for IPv6 Customer Edge Routers" [RFC7084] requires 937 implementation of a DHCPv6 server function in IPv6 Customer Edge (CE) 938 routers. 940 13. Network Management 942 Network management MAY be supported by IPv6 nodes. However, for IPv6 943 nodes that are embedded devices, network management may be the only 944 possible way of controlling these nodes. 946 **BIS This is a little thin. Add Netconf, restconf, yang models? ** 948 **BIS add the network polling/syslod nd for none DHCPv6 network 949 tracking.** 951 13.1. Management Information Base (MIB) Modules 953 **BIS Address MIB Obsolete draft 955 The following two MIB modules SHOULD be supported by nodes that 956 support a Simple Network Management Protocol (SNMP) agent. 958 13.1.1. IP Forwarding Table MIB 960 The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes 961 that support an SNMP agent. 963 13.1.2. Management Information Base for the Internet Protocol (IP) 965 The IP MIB [RFC4293] SHOULD be supported by nodes that support an 966 SNMP agent. 968 14. Constrained Devices 970 **BIS Should we add notes on constrained devices, and power 971 efficiency here in a new section? Talk about resource management in 972 nodes. Low power operation. 974 15. Security Considerations 976 This document does not directly affect the security of the Internet, 977 beyond the security considerations associated with the individual 978 protocols. 980 Security is also discussed in Section 11 above. 982 16. Authors and Acknowledgments 984 16.1. Authors and Acknowledgments (Current Document) 986 For this version of the IPv6 Node Requirements document, the authors 987 would like to thank **BIS Add new acknowledgements for significant 988 comments ** for their contributions. 990 16.2. Authors and Acknowledgments from RFC 6434 992 Ed Jankiewicz and Thomas Narten were named authors of the previous 993 iteration of this document, RFC6434. 995 For this version of the document, the authors thanked Hitoshi Asaeda, 996 Brian Carpenter, Tim Chown, Ralph Droms, Sheila Frankel, Sam Hartman, 997 Bob Hinden, Paul Hoffman, Pekka Savola, Yaron Sheffer, and Dave 998 Thaler. 1000 16.3. Authors and Acknowledgments from RFC 4294 1002 The original version of this document (RFC 4294) was written by the 1003 IPv6 Node Requirements design team: 1005 Jari Arkko 1006 jari.arkko@ericsson.com 1008 Marc Blanchet 1009 marc.blanchet@viagenie.qc.ca 1011 Samita Chakrabarti 1012 samita.chakrabarti@eng.sun.com 1014 Alain Durand 1015 alain.durand@sun.com 1017 Gerard Gastaud 1018 gerard.gastaud@alcatel.fr 1020 Jun-ichiro Itojun Hagino 1021 itojun@iijlab.net 1023 Atsushi Inoue 1024 inoue@isl.rdc.toshiba.co.jp 1026 Masahiro Ishiyama 1027 masahiro@isl.rdc.toshiba.co.jp 1029 John Loughney 1030 john.loughney@nokia.com 1032 Rajiv Raghunarayan 1033 raraghun@cisco.com 1034 Shoichi Sakane 1035 shouichi.sakane@jp.yokogawa.com 1037 Dave Thaler 1038 dthaler@windows.microsoft.com 1040 Juha Wiljakka 1041 juha.wiljakka@Nokia.com 1043 The authors would like to thank Ran Atkinson, Jim Bound, Brian 1044 Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas 1045 Narten, Juha Ollila, and Pekka Savola for their comments. Thanks to 1046 Mark Andrews for comments and corrections on DNS text. Thanks to 1047 Alfred Hoenes for tracking the updates to various RFCs. 1049 17. Appendix: Changes from RFC 6434 1051 There have been many editorial clarifications as well as significant 1052 additions and updates. While this section highlights some of the 1053 changes, readers should not rely on this section for a comprehensive 1054 list of all changes. 1056 1. Added 6LoWPAN to link layers 1058 2. Removed DOD IPv6 Profile updates 1060 3. Removed IPv6 Mobility RFC6275 1062 18. Appendix: Changes from RFC 4294 1064 There have been many editorial clarifications as well as significant 1065 additions and updates. While this section highlights some of the 1066 changes, readers should not rely on this section for a comprehensive 1067 list of all changes. 1069 1. Updated the Introduction to indicate that this document is an 1070 applicability statement and is aimed at general nodes. 1072 2. Significantly updated the section on Mobility protocols, adding 1073 references and downgrading previous SHOULDs to MAYs. 1075 3. Changed Sub-IP Layer section to just list relevant RFCs, and 1076 added some more RFCs. 1078 4. Added section on SEND (it is a MAY). 1080 5. Revised section on Privacy Extensions [RFC4941] to add more 1081 nuance to recommendation. 1083 6. Completely revised IPsec/IKEv2 section, downgrading overall 1084 recommendation to a SHOULD. 1086 7. Upgraded recommendation of DHCPv6 to SHOULD. 1088 8. Added background section on DHCP versus RA options, added SHOULD 1089 recommendation for DNS configuration via RAs [RFC6106], and 1090 cleaned up DHCP recommendations. 1092 9. Added recommendation that routers implement Sections 7.3 and 7.5 1093 of [RFC6275]. 1095 10. Added pointer to subnet clarification document [RFC5942]. 1097 11. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311] 1098 SHOULD be implemented. 1100 12. Added reference to [RFC5722] (Overlapping Fragments), and made 1101 it a MUST to implement. 1103 13. Made "A Recommendation for IPv6 Address Text Representation" 1104 [RFC5952] a SHOULD. 1106 14. Removed mention of "DNAME" from the discussion about [RFC3363]. 1108 15. Numerous updates to reflect newer versions of IPv6 documents, 1109 including [RFC4443], [RFC4291], [RFC3596], and [RFC4213]. 1111 16. Removed discussion of "Managed" and "Other" flags in RAs. There 1112 is no consensus at present on how to process these flags, and 1113 discussion of their semantics was removed in the most recent 1114 update of Stateless Address Autoconfiguration [RFC4862]. 1116 17. Added many more references to optional IPv6 documents. 1118 18. Made "A Recommendation for IPv6 Address Text Representation" 1119 [RFC5952] a SHOULD. 1121 19. Added reference to [RFC5722] (Overlapping Fragments), and made 1122 it a MUST to implement. 1124 20. Updated MLD section to include reference to Lightweight MLD 1125 [RFC5790]. 1127 21. Added SHOULD recommendation for "Default Router Preferences and 1128 More-Specific Routes" [RFC4191]. 1130 22. Made "IPv6 Flow Label Specification" [RFC6437] a SHOULD. 1132 19. References 1134 19.1. Normative References 1136 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1137 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1138 . 1140 [RFC1035] Mockapetris, P., "Domain names - implementation and 1141 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1142 November 1987, . 1144 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1145 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1146 1996, . 1148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1149 Requirement Levels", BCP 14, RFC 2119, 1150 DOI 10.17487/RFC2119, March 1997, 1151 . 1153 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1154 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1155 December 1998, . 1157 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1158 RFC 2671, DOI 10.17487/RFC2671, August 1999, 1159 . 1161 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1162 Listener Discovery (MLD) for IPv6", RFC 2710, 1163 DOI 10.17487/RFC2710, October 1999, 1164 . 1166 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1167 RFC 2711, DOI 10.17487/RFC2711, October 1999, 1168 . 1170 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1171 C., and M. Carney, "Dynamic Host Configuration Protocol 1172 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1173 2003, . 1175 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1176 Listener Discovery (MLD) Protocol", RFC 3590, 1177 DOI 10.17487/RFC3590, September 2003, 1178 . 1180 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1181 "DNS Extensions to Support IP Version 6", RFC 3596, 1182 DOI 10.17487/RFC3596, October 2003, 1183 . 1185 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1186 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 1187 April 2004, . 1189 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1190 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1191 DOI 10.17487/RFC3810, June 2004, 1192 . 1194 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1195 Rose, "DNS Security Introduction and Requirements", 1196 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1197 . 1199 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1200 Rose, "Resource Records for the DNS Security Extensions", 1201 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1202 . 1204 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1205 Rose, "Protocol Modifications for the DNS Security 1206 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1207 . 1209 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1210 for IPv6 Hosts and Routers", RFC 4213, 1211 DOI 10.17487/RFC4213, October 2005, 1212 . 1214 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1215 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1216 2006, . 1218 [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, 1219 DOI 10.17487/RFC4292, April 2006, 1220 . 1222 [RFC4293] Routhier, S., Ed., "Management Information Base for the 1223 Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, 1224 April 2006, . 1226 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1227 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1228 December 2005, . 1230 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1231 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1232 . 1234 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 1235 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 1236 DOI 10.17487/RFC4307, December 2005, 1237 . 1239 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load 1240 Sharing", RFC 4311, DOI 10.17487/RFC4311, November 2005, 1241 . 1243 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1244 Control Message Protocol (ICMPv6) for the Internet 1245 Protocol Version 6 (IPv6) Specification", RFC 4443, 1246 DOI 10.17487/RFC4443, March 2006, 1247 . 1249 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1250 Group Management Protocol Version 3 (IGMPv3) and Multicast 1251 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1252 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 1253 August 2006, . 1255 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1256 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 1257 . 1259 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1260 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1261 DOI 10.17487/RFC4861, September 2007, 1262 . 1264 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1265 Address Autoconfiguration", RFC 4862, 1266 DOI 10.17487/RFC4862, September 2007, 1267 . 1269 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 1270 Requirements for Encapsulating Security Payload (ESP) and 1271 Authentication Header (AH)", RFC 4835, 1272 DOI 10.17487/RFC4835, April 2007, 1273 . 1275 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1276 Extensions for Stateless Address Autoconfiguration in 1277 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1278 . 1280 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1281 of Type 0 Routing Headers in IPv6", RFC 5095, 1282 DOI 10.17487/RFC5095, December 2007, 1283 . 1285 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 1286 RFC 5453, DOI 10.17487/RFC5453, February 2009, 1287 . 1289 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 1290 RFC 5722, DOI 10.17487/RFC5722, December 2009, 1291 . 1293 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 1294 Group Management Protocol Version 3 (IGMPv3) and Multicast 1295 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 1296 DOI 10.17487/RFC5790, February 2010, 1297 . 1299 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 1300 Model: The Relationship between Links and Subnet 1301 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 1302 . 1304 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1305 Address Text Representation", RFC 5952, 1306 DOI 10.17487/RFC5952, August 2010, 1307 . 1309 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1310 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1311 RFC 5996, DOI 10.17487/RFC5996, September 2010, 1312 . 1314 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1315 "IPv6 Router Advertisement Options for DNS Configuration", 1316 RFC 6106, DOI 10.17487/RFC6106, November 2010, 1317 . 1319 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1320 "IPv6 Flow Label Specification", RFC 6437, 1321 DOI 10.17487/RFC6437, November 2011, 1322 . 1324 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 1325 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 1326 RFC 6564, DOI 10.17487/RFC6564, April 2012, 1327 . 1329 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1330 "Default Address Selection for Internet Protocol Version 6 1331 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1332 . 1334 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", 1335 RFC 6946, DOI 10.17487/RFC6946, May 2013, 1336 . 1338 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1339 of IPv6 Extension Headers", RFC 7045, 1340 DOI 10.17487/RFC7045, December 2013, 1341 . 1343 [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 1344 Detection Is Too Impatient", RFC 7048, 1345 DOI 10.17487/RFC7048, January 2014, 1346 . 1348 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 1349 Oversized IPv6 Header Chains", RFC 7112, 1350 DOI 10.17487/RFC7112, January 2014, 1351 . 1353 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1354 Interface Identifiers with IPv6 Stateless Address 1355 Autoconfiguration (SLAAC)", RFC 7217, 1356 DOI 10.17487/RFC7217, April 2014, 1357 . 1359 [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., 1360 and W. George, "Enhanced Duplicate Address Detection", 1361 RFC 7527, DOI 10.17487/RFC7527, April 2015, 1362 . 1364 [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss 1365 Resiliency for Router Solicitations", RFC 7559, 1366 DOI 10.17487/RFC7559, May 2015, 1367 . 1369 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1370 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1371 February 2016, . 1373 [RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6 1374 Atomic Fragments Considered Harmful", RFC 8021, 1375 DOI 10.17487/RFC8021, January 2017, 1376 . 1378 19.2. Informative References 1380 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1381 RFC 793, DOI 10.17487/RFC0793, September 1981, 1382 . 1384 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1385 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1386 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1387 September 1997, . 1389 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1390 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1391 . 1393 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1394 over Non-Broadcast Multiple Access (NBMA) networks", 1395 RFC 2491, DOI 10.17487/RFC2491, January 1999, 1396 . 1398 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 1399 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 1400 . 1402 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 1403 IPv6 Packets over Frame Relay Networks Specification", 1404 RFC 2590, DOI 10.17487/RFC2590, May 1999, 1405 . 1407 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1408 RFC 2675, DOI 10.17487/RFC2675, August 1999, 1409 . 1411 [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 1412 over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, 1413 October 2001, . 1415 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 1416 Hain, "Representing Internet Protocol version 6 (IPv6) 1417 Addresses in the Domain Name System (DNS)", RFC 3363, 1418 DOI 10.17487/RFC3363, August 2002, 1419 . 1421 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1422 Stevens, "Basic Socket Interface Extensions for IPv6", 1423 RFC 3493, DOI 10.17487/RFC3493, February 2003, 1424 . 1426 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1427 "Advanced Sockets Application Program Interface (API) for 1428 IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, 1429 . 1431 [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 1432 Extensions for Multicast Source Filters", RFC 3678, 1433 DOI 10.17487/RFC3678, January 2004, 1434 . 1436 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1437 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1438 2011, . 1440 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1441 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1442 DOI 10.17487/RFC3971, March 2005, 1443 . 1445 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1446 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1447 . 1449 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1450 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1451 November 2005, . 1453 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1454 DOI 10.17487/RFC4302, December 2005, 1455 . 1457 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 1458 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 1459 over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, 1460 January 2006, . 1462 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1463 Network Address Translations (NATs)", RFC 4380, 1464 DOI 10.17487/RFC4380, February 2006, 1465 . 1467 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1468 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 1469 . 1471 [RFC4584] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API 1472 for Mobile IPv6", RFC 4584, DOI 10.17487/RFC4584, July 1473 2006, . 1475 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1476 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1477 . 1479 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1480 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1481 DOI 10.17487/RFC4884, April 2007, 1482 . 1484 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1485 "Transmission of IPv6 Packets over IEEE 802.15.4 1486 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1487 . 1489 [RFC5006] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli, 1490 "IPv6 Router Advertisement Option for DNS Configuration", 1491 RFC 5006, DOI 10.17487/RFC5006, September 2007, 1492 . 1494 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 1495 Socket API for Source Address Selection", RFC 5014, 1496 DOI 10.17487/RFC5014, September 2007, 1497 . 1499 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 1500 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 1501 . 1503 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 1504 Madanapalli, "Transmission of IPv6 via the IPv6 1505 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 1506 DOI 10.17487/RFC5121, February 2008, 1507 . 1509 [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to 1510 Historic Status", RFC 6563, DOI 10.17487/RFC6563, March 1511 2012, . 1513 [RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S. 1514 Krishnan, "IPv6 for Third Generation Partnership Project 1515 (3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066, 1516 November 2013, . 1518 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1519 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1520 DOI 10.17487/RFC7084, November 2013, 1521 . 1523 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 1524 /64 Prefix from a Third Generation Partnership Project 1525 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 1526 DOI 10.17487/RFC7278, June 2014, 1527 . 1529 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1530 Considerations for IPv6 Address Generation Mechanisms", 1531 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1532 . 1534 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 1535 "Host Address Availability Recommendations", BCP 204, 1536 RFC 7934, DOI 10.17487/RFC7934, July 2016, 1537 . 1539 [POSIX] IEEE, "IEEE Std. 1003.1-2008 Standard for Information 1540 Technology -- Portable Operating System Interface (POSIX), 1541 ISO/IEC 9945:2009", . 1543 [USGv6] National Institute of Standards and Technology, "A Profile 1544 for IPv6 in the U.S. Government - Version 1.0", July 2008, 1545 . 1547 Authors' Addresses 1549 Tim Chown 1550 Jisc 1551 Lumen House, Library Avenue 1552 Harwell Oxford, Didcot OX11 0SG 1553 United Kingdom 1555 Email: tim.chown@jisc.ac.uk 1557 John Loughney 1558 Nokia 1559 200 South Mathilda Ave. 1560 Sunnyvale, CA 94086 1561 USA 1563 Phone: +1 650 283 8068 1564 Email: john.loughney@nokia.com 1565 Tim Winters 1566 University of New Hampshire 1567 InterOperability Laboratory 1568 Durham NH 1569 United States 1571 Email: twinters@iol.unh.edu