idnits 2.17.1 draft-smith-v6ops-local-only-addressing-00.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 -- The document date (October 14, 2019) is 1655 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Smith 3 Internet-Draft October 14, 2019 4 Intended status: Informational 5 Expires: April 16, 2020 7 Default IPv6 Local Only Addressing for Non-Internet Devices 8 draft-smith-v6ops-local-only-addressing-00 10 Abstract 12 For certain types or models of devices it should be clear and obvious 13 that, by default, they should not be reachable from the global IPv6 14 Internet, or able to reach the global IPv6 Internet, even though the 15 network they are attached to provides global IPv6 Internet 16 connectivity. This memo proposes that these types of devices refuse 17 to configure and use global IPv6 Internet addresses by default. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 16, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Default Local Only Addresses . . . . . . . . . . . . . . . . 3 56 3. SLAAC Address Configuration . . . . . . . . . . . . . . . . . 3 57 4. DHCPv6 Address Configuration . . . . . . . . . . . . . . . . 4 58 5. Permitted Incoming and Outgoing Connections . . . . . . . . . 5 59 6. Example Device Types . . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 9. Change Log [RFC Editor please remove] . . . . . . . . . . . . 6 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 10.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 For some types of IPv6 devices, their access to the Internet, and 71 access from the Internet, should be prevented under normal 72 circumstances. Examples of these types of devices are network 73 attached paper printers, local network file and print servers, and 74 various types of "Internet of Things" devices. 76 As a basic and fundamental prevention measure, these types of devices 77 can have their ability to reach the Internet, or to be reachable from 78 the Internet, prevented by only attaching them to local network links 79 and routers that only support and provide Unique Local Unicast 80 Addresses (ULA) [RFC4193]. These nodes and devices would then only 81 have addresses from within the Link-Local [RFC4291] prefix and ULA 82 prefix(es) available on the link. 84 In some networks, it may not be possible or easy to use "ULA Only" 85 links to isolate these devices. For example, these devices may need 86 to be attached to the same link as other devices that do have global 87 IPv6 addresses and can reach the Internet. This may be because these 88 local network only devices may need to be discoverable by devices 89 with global Internet addresses via link-only discovery protocols such 90 as multicast DNS (mDNS) [RFC6762]. 92 This memo proposes that when it is clear to a device manufacturer 93 that a device should be isolated from the Internet by default, due 94 its functions and role, the device only configures Link-Local 95 Addresses and non-Internet usable addresses such as ULAs on its 96 interfaces, even though the link may support and provide global IPv6 97 Internet addresses. This memo also proposes that these devices 98 should have available an override configuration switch that causes 99 these devices to configure addresses from all prefixes available on 100 the link, including global IPv6 Internet address prefixes. 102 These types of devices are known as Local Only Address devices in 103 this memo. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. Default Local Only Addresses 113 By default, a Local Only Address device MUST only configure Link- 114 Local and non-global IPv6 addresses, currently Unique Local Addresses 115 [RFC4193], on its network interfaces. 117 The device SHOULD provide a default override configuration option, 118 known as Configure All IPv6 Addresses, allowing the device to 119 configure addresses from all available IPv6 address prefixes on the 120 link, including global IPv6 addresses. 122 This Configure All IPv6 Addresses configuration switch SHOULD be 123 available via a device's administrative interface. There may be some 124 devices where it is clear that attachment to the public IPv6 Internet 125 should never occur; for these devices, this configation switch SHOULD 126 be omitted. An example would be IoT devices such as Smart Grid 127 Advanced Metering Infrastructure (AMI) devices [RFC6272]. 129 (Further thought, there could probably be an RA PIO flag or similar 130 to override this default for all devices on a link, and a similar 131 DHCPv6 flag/option. Would mean this ID would be in 6man WG scope 132 rather than v6ops.) 134 3. SLAAC Address Configuration 136 By default, when the Local Only Addresses device is processing IPv6 137 Router Advertisement Prefix Information Options (PIOs) [RFC4861], to 138 configure IPv6 interface addresses via SLAAC [RFC4862], the device 139 MUST only configure addresses using PIOs that provide a prefix that 140 falls within the Unique Local Unicast Address [RFC4193] address range 141 of fc::/7, should the A or autonomous address-configuration flag be 142 set for the PIO. 144 By default, if there are no ULA prefix PIOs in the received RAs, or 145 no ULA prefix PIOs with the A flag set, the Local Only Addresses 146 device MUST only configure IPv6 Link-Local addresses on its network 147 interface. 149 By default, if there are ULA prefix PIOs that do not have the A flag 150 set, they MUST be processed per standard RA PIO processing for other 151 flags. For example, a PIO for a ULA prefix, with the A flag unset, 152 and the L or on-link flag set, is still processed, and is asserting 153 that the specified ULA prefix is on-link. 155 If the Configure All IPv6 Addresses configuration switch is enabled, 156 then the Local Only Addresses device MUST process all IPv6 RA PIOs 157 received for SLAAC address configuration, per [RFC4862], from that 158 point in time onwards. 160 If the Configure All IPv6 Addresses configuration switch is changed 161 from enabled to disabled, then the Local Only Addresses device MUST 162 immediately remove all global IPv6 addresses from the interface, 163 immediately terminating all upper layer application connections that 164 are using these global IPv6 addresses. This is regardless of any 165 remaining preferred and valid lifetimes for the addresses [RFC4862]. 166 This is immediately enforcing the intention that this Local Address 167 Only device should now be isolated from the global IPv6 Internet. 169 4. DHCPv6 Address Configuration 171 By default, if the Local Only Addresses device is using DHCPv6 172 [RFC8415] for address acquisition and configuration, the device MUST 173 ignore any received IPv6 addresses in either IA_TA or IA_NA options, 174 that not with the ULA prefix of fd00::/7. 176 Be default, if the Local Only Addresses device does not receive any 177 IA_TA or IA_NA options containing addresses from within the ULA 178 prefix of fd00::/7, then the device MUST only configure Link-Local 179 addresses on its interface. 181 Note that a device using DHCPv6 for address acquisition and 182 configuration could also be using SLAAC for address configuration in 183 parallel. All of the SLAAC Address Configuration procedures 184 described prevously will also apply. 186 If the Configure All IPv6 Addresses configuration switch is enabled, 187 then the Local Only Addresses device MUST then acquire and accept all 188 IPv6 addresses provided by the DHCPv6 server in either IA_NA or IA_TA 189 options. 191 If the Configure All IPv6 Addresses configuration switch is changed 192 from enabled to disabled, then the Local Only Addresses device MUST 193 immediately remove all global IPv6 addresses from the interface, 194 immediately terminating all upper layer application connections that 195 are using these global IPv6 addresses. This is regardless of any 196 remaining preferred and valid lifetimes for the addresses [RFC4862]. 197 This is immediately enforcing the intention that this Local Address 198 Only device should now be isolated from the global IPv6 Internet. 199 The Local Address Only device should gracefully close its DHCPv6 200 leases for these global IPv6 addresses, returning them to the DHCPv6 201 server's address pool. 203 5. Permitted Incoming and Outgoing Connections 205 By default, a Local Address Only device MUST NOT accept any upper 206 layer connections from any global IPv6 addresses. Any connection 207 attempts from global IPv6 addresses MUST be silently ignored, meaning 208 that no connection failure ICMPv6 or transport layer protocol error 209 messages are sent. Connection attempts from other address types, 210 such as Link-Local or ULA addresses are accepted, should other Local 211 Address Only device security policies permit them. 213 As a Local Address Only device, by default, MUST NOT have any valid 214 global IPv6 addresses, outgoing connections using global IPv6 215 addresses should not occur. 217 An application may attempt to overcome this global IPv6 address 218 constraint by constructing packets itself that contain a global IPv6 219 address source address. These types of packets MUST be dropped by 220 the Local Address Only device, and a system message alerting the 221 Local Only Address device operator to this possible security 222 violation SHOULD be logged with appropriate severity. 224 If the Configure All IPv6 Addresses configuration switch is changed 225 from disabled to enabled, all incoming and outgoing connections from 226 any type of IPv6 address are permitted, assuming any other Local 227 Address Only device security policies permit them. 229 6. Example Device Types 231 The following are some example types of devices for which this 232 default Local Only Address behaviour should be implemented. This is 233 is not exhaustive, and should be judged by a vendor on a device by 234 device type basis, by considering the device's purpose, and most 235 typical and common deployment scenarios. 237 o Network attached paper printers 238 o File Server and Network Attached Storage 240 o IoT devices such as Advanced Metering Infrastructure "smart" 241 electricity meters [RFC6272]. 243 o Networking device Operations, Administration and Maintenance (OAM) 244 and Out-of-Band (OOB) management interfaces, used for and by 245 device monitoring and management protocols such as SNMP [RFC1157]. 247 7. Security Considerations 249 This memo is specifically about increasing device security by 250 limiting their network accessibility and reachability by default, 251 when it suits the intended use of the device. It is imposing a 252 fundamental truth and constraint that if a device cannot be reached 253 by a packet, the device cannot be attacked by the contents of that 254 packet. By default, suitable devices are not reachable from the 255 Internet, and therefore cannot be attacked from devices on the 256 Internet. 258 However, this security mechanism is both baseline and coarse. It 259 does not protect against attacks from other devices that can reach 260 the Local Only Address device via ULA or Link-Local addresses. 262 This mechanism should be considered a minimum measure for suitable 263 devices to implement. It should be combined with other security 264 mechanisms, such as IPsec [RFC4301] for IPv6 layer authentication and 265 application layer authentication. 267 8. Acknowledgements 269 Review and comments were provided by YOUR NAME HERE! 271 This memo was prepared using the xml2rfc tool. 273 9. Change Log [RFC Editor please remove] 275 draft-smith-v6ops-local-only-addressing-00, initial version, 276 2019-09-15 278 10. References 280 10.1. Normative References 282 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 283 "Simple Network Management Protocol (SNMP)", RFC 1157, 284 DOI 10.17487/RFC1157, May 1990, 285 . 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, 289 DOI 10.17487/RFC2119, March 1997, 290 . 292 10.2. Informative References 294 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 295 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 296 . 298 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 299 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 300 2006, . 302 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 303 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 304 December 2005, . 306 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 307 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 308 DOI 10.17487/RFC4861, September 2007, 309 . 311 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 312 Address Autoconfiguration", RFC 4862, 313 DOI 10.17487/RFC4862, September 2007, 314 . 316 [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart 317 Grid", RFC 6272, DOI 10.17487/RFC6272, June 2011, 318 . 320 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 321 DOI 10.17487/RFC6762, February 2013, 322 . 324 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 325 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 326 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 327 RFC 8415, DOI 10.17487/RFC8415, November 2018, 328 . 330 Author's Address 331 Mark Smith 332 PO BOX 521 333 HEIDELBERG, VIC 3084 334 AU 336 Email: markzzzsmith@gmail.com