idnits 2.17.1 draft-ietf-6man-ipv6only-flag-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5175, updated by this document, for RFC5378 checks: 2008-03-07) -- 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 (May 24, 2018) is 2158 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: 'RFC3775' is mentioned on line 189, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'RFC4389' is mentioned on line 191, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-Ethertype' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-RF' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Hinden 3 Internet-Draft Check Point Software 4 Updates: 5175 (if approved) B. Carpenter 5 Intended status: Standards Track Univ. of Auckland 6 Expires: November 25, 2018 May 24, 2018 8 IPv6 Router Advertisement IPv6-Only Flag 9 draft-ietf-6man-ipv6only-flag-00 11 Abstract 13 This document specifies a Router Advertisement Flag to indicate to 14 hosts that the administrator has configured the router to advertise 15 that the link is IPv6-Only. This document updates RFC5175. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 25, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 53 3. Applicability Statements . . . . . . . . . . . . . . . . . . 4 54 4. IPv6-Only Definition . . . . . . . . . . . . . . . . . . . . 4 55 5. IPv6-Only Flag . . . . . . . . . . . . . . . . . . . . . . . 4 56 6. Router and Operational Considerations . . . . . . . . . . . . 5 57 7. Host Behavior Considerations . . . . . . . . . . . . . . . . 6 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 61 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 62 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 64 12.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 This document specifies a Router Advertisement Flag to indicate to 70 hosts that the administrator has configured the router to advertise 71 that the link is IPv6-Only. The flag does not apply to non-default 72 IPv6 routers. 74 Hosts that support IPv4 and IPv6, usually called dual stack hosts, 75 need to also work efficiently on IPv6 only links. That is, a link 76 where there are no IPv4 routers and/or IPv4 services. Dual stack is 77 the default configuration for most current host operating systems 78 such as Windows 10, IOS, Android, Linux, and BSD, as well as devices 79 such as printers. Monitoring of IPv6-only link, for example at the 80 IETF 100 meeting in Singapore, shows that current dual stack hosts 81 will create local auto-configured IPv4 addresses and attempt to reach 82 IPv4 services. This may be a problem for several reasons: 84 o It may result in an undesirable level of Layer 2 broadcast 85 traffic, especially on large wireless networks. 87 o In particular, this may overload switches in multi-segment 88 wireless networks because it will create IPv4 state for every dual 89 stack host. 91 o Such traffic may drain battery power on wireless hosts that have 92 no interest in link-local IPv4 traffic. [RFC7772] indicates how 93 this risk might be quantified. 95 o Similarly, hosts may waste battery power on futile attempts to 96 access IPv4 services. 98 o On an IPv6-only link, IPv4 might be used for malicious purposes 99 and pass unnoticed by IPv6-only monitoring mechanisms. 101 This document defines a mechanism that a router administrator can use 102 to inform hosts that this is an IPv6-Only link on their default 103 routers such that they can disable IPv4 on this link, mitigating all 104 of the above problems. 106 In managed networks whose equipment allows it, these problems could 107 be mitigated by configuring the Layer 2 infrastructure to drop IPv4 108 and ARP traffic by filtering Ethertypes 0x0800 and 0x806 109 [IANA-Ethertype]. IPv6 uses a different Ethertype 0x86DD so this 110 filtering will not interfere with IPv6 traffic. Depending on the 111 equipment details, this would limit the traffic to the link to the 112 switch, and would drop all IPv4 and ARP broadcast packets. However, 113 hosts transmitting IPv4 packets would still do so, consuming their 114 own battery power and some radio bandwidth. The intent of this 115 specification is to provide a mechanism that works on networks 116 without the ability to filter L2 traffic, or where there are portions 117 of a network without the ability to filter L2 traffic. It may also 118 be valuable on unmanaged networks using routers pre-configured for 119 IPv6-only operations and where Layer 2 filtering is unavailable. 121 Because there is no IPv4 support on IPv6-only routers, the only way 122 to notify the dual stack hosts that this link is IPv6-Only is to use 123 an IPv6 mechanism. An active notification will be much more precise 124 than attempting to deduce this fact by the lack of IPv4 responses or 125 traffic. 127 IPv4-only hosts, and dual-stack hosts that do not recognize the new 128 flag, will continue to attempt IPv4 operations, in particular IPv4 129 discovery protocols typically sent as link-layer broadcasts. This 130 legacy traffic cannot be prevented by any IPv6 mechanism. The value 131 of the new flag is limited to hosts that recognize it. 133 This document specifies a new flag for Router Advertisement Flag 134 [RFC5175]. It updates [RFC5175] to add this flag. 136 2. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 3. Applicability Statements 146 The mechanism is designed to allow administrators to notify hosts 147 that the link is IPv6-Only. It SHOULD be only used in IPv6-Only 148 links. 150 Dual stack hosts that have a good reason to use IPv4, for example for 151 a specific IPv4 link-local service, can continue to do so. This is 152 consistent with the SHOULD language in this document. 154 Administrators SHOULD only use this mechanism if they are certain 155 that the link is IPv6-Only. For example, in cases where there is a 156 need to continue to use IPv4 or there are IPv4 only routers, setting 157 this flag to 1 is a configuration error. 159 4. IPv6-Only Definition 161 IPv6-Only is defined to mean that only IPv6 is running on the link. 162 This includes: 164 * No IPv4 traffic on the Link 165 * No IPv4 routers on the Link 166 * No DHCPv4 servers on the Link 167 * No IPv4 accessible services on the Link 168 * All IPv4 and ARP traffic may be blocked at Layer 2 by the 169 administrator 171 It is expected that on IPv6-Only networks it will be common for 172 access to IPv4 external services to be reached by techniques such as 173 NAT64 [RFC6146] and DNS64 [RFC6147] at the edge of the network. This 174 is beyond the scope of this document. 176 5. IPv6-Only Flag 178 RFC5175 currently defines the flags in the NDP Router Advertisement 179 message and these flags are registered in the IANA IPv6 ND Router 180 Advertisement flags Registry [IANA-RF]. This currently contains the 181 following one-bit flags defined in published RFCs: 183 0 1 2 3 4 5 6 7 184 +-+-+-+-+-+-+-+-+ 185 |M|O|H|Prf|P|R|R| 186 +-+-+-+-+-+-+-+-+ 187 M Managed Address Configuration Flag [RFC4861] 188 O Other Configuration Flag [RFC4861] 189 H Mobile IPv6 Home Agent Flag [RFC3775] 190 Prf Router Selection Preferences [RFC4191] 191 P Neighbor Discovery Proxy Flag [RFC4389] 192 R Reserved 194 This document defines bit 6 to be the IPv6-Only Flag: 196 6 IPv6-Only Flag 198 This flag has two values. These are: 200 0 This is not an IPv6-Only link 201 1 This is an IPv6-Only link 203 RFC 5175 requires that unused flag bits be set to zero. Therefore, a 204 router that does not support the new flag will not appear to assert 205 that this is an IPv6-Only link. 207 Hosts receiving the Router Advertisement SHOULD only process this 208 flag if the advertising router is a Default Router. Specifically, if 209 the Lifetime field in the Router Advertisement is not zero, otherwise 210 it SHOUD be ignored. This is done to allow some IPv6 routers to 211 advertise information without being a Default Router and providing 212 IPv6 connectivity. 214 6. Router and Operational Considerations 216 Default IPv6 routers that are on an IPv6-Only link SHOULD be 217 configured to set the IPv6-Only flag to 1 on interfaces on this link. 218 In all other cases the flag SHOULD NOT be set to 1. 220 The intent is that the administrator of the router configures the 221 router to set the IPv6-Only flag if she/he wants to tell the hosts on 222 the link that the link is IPv6-Only. This is a configuration flag, 223 it is not something that the router decides on it's own. 225 Operators of large IPv6-only wireless links are advised to also use 226 Layer 2 techniques to drop IPv4 and ARP packets (Ethertypes 0x0800 227 and 0x806) at all switches, and to ensure that IPv4 and ARP features 228 are disabled in all switches. 230 7. Host Behavior Considerations 232 If there are multiple IPv6 default routers on a link, they might send 233 different values of the flag. If at least one IPv6 default router 234 sends the flag with value 0, a dual stack host SHOULD NOT assume that 235 the link is IPv6-Only. If all IPv6 default routers send the flag 236 with value 1, a dual stack host SHOULD assume that this is an 237 IPv6-Only link. 239 A host that receives only RAs with the flag set to 1 SHOULD NOT 240 attempt any IPv4 operations, unless it subsequently receives at least 241 one RA with the flag set to zero. As soon as such an RA is received, 242 IPv4 operations SHOULD be started. 244 A host MAY choose to delay all IPv4 operations at start-up until a 245 reasonable time has elapsed for RA messages to arrive. If all RAs 246 received have the flag set, a host SHOULD also choose to not attempt 247 IPv4 operations until an application asks it to, specifically delay 248 performing DHCPV4 until it gets a request from an application to use 249 IPv4. This would avoid attempting to obtain IPv4 addresses if there 250 are no applications trying to use IPv4. 252 In all of the above, the flag's value is considered valid for the 253 lifetime of the default router concerned, unless a subsequent RA 254 delivers a different flag value. If a default router expires (i.e., 255 no RA is received that refreshes its lifetime), the host must remove 256 this router's flag value from consideration. If the result is that 257 all surviving default routers have the flag set to 1, the host SHOULD 258 assume that the link is IPv6-Only. In other words, at any given 259 time, the state of the flag as seen by the host is the logical AND of 260 the flags sent by all unexpired default IPv6 routers. 262 8. IANA Considerations 264 IANA is requested to assign the new Router Advertisement flag defined 265 in Section 5 of this document. Bit 6 is the next available bit in 266 this registry, IANA is requested to use this bit unless there is a 267 reason to use another bit in this registry. 269 IANA is also requested to register this new flag bit in the IANA IPv6 270 ND Router Advertisement flags Registry [IANA-RF]. 272 9. Security Considerations 274 This document shares the security issues with other parts of IPv6 275 Neighbor Discovery. General techniques to protect Router 276 Advertisement traffic such as Router Guard [RFC6105] are useful in 277 protecting these vulnerabilities. 279 A bad actor could use this mechanism to attempt turn off IPv4 service 280 on a link that is using IPv4, by sending Router Advertisements with 281 the IPv6-Only Flag set to 1. In that case, as long as there are 282 routers sending Router Advertisements with this Flag set to 0, they 283 would override this attack given the mechanism in Section 5. 284 Specifically a host would only turn off IPv4 service if it wasn't 285 hearing any Router Advertisement with the Flag set to 0. If the 286 advice in Section 6 is followed, this attack will fail. 288 Conversely, a bad actor could use this mechanism to turn on, or 289 pretend to turn on, IPv4 service on an IPv6-only link, by sending 290 Router Advertisements with the Flag set to 0. However, this is 291 really no different than what such a bad actor can do anyway, if they 292 have the ability to configure a bogus router in the first place. The 293 advice in Section 6 will minimize such an attack by limiting it to a 294 single link. 296 Note that manipulating the Router Preference [RFC4191] will not 297 affect either of these attacks: any IPv6-Only Flag of 0 will always 298 override all Flags set to 1. 300 The new flag is neutral from an IPv6 privacy viewpoint, since it does 301 not affect IPv6 operations in any way. From an IPv4 privacy 302 viewpoint, it has the potential benefit of suppressing unnecessary 303 traffic that might reveal the existence of a host and the correlation 304 between its hardware and IPv4 addresses. 306 10. Acknowledgments 308 A closely related proposal was published earlier as 309 [I-D.ietf-sunset4-noipv4]. 311 Helpful comments were received from Lorenzo Colitti, David Farmer, 312 Fernando Gont, Nick Hilliard, Erik Kline, Jen Linkova, Veronika 313 McKillop, Michael Richardson, Mark Smith, Barbara Stark, Ole Troan, 314 James Woodyatt, and other members of the 6MAN working group. 316 Bjoern Zeeb has also produced a variant of this proposal and proposed 317 an IPv6 transition plan in [I-D.bz-v4goawayflag]. 319 11. Change log [RFC Editor: Please remove] 321 draft-ietf-6man-ipv6only-flag-00, 2018-May-21: 323 * Changed the file name to draft-ietf-6man-ipv6only-flag to match 324 the current tile and that it is a w.g. draft. 325 * Added new section that defines what IPv6-Only includes. 327 * Expanded description of using Layer 2 filter to block IPv4 and 328 ARP traffic. 329 * Editorial changes. 331 draft-hinden-ipv4flag-04, 2018-April-16: 333 * Changed the name of the document and flag to be the IPv6-Only 334 flag. 335 * Rewrote text to make it affirmative that this is used by an 336 administrator to tell the hosts that the link is IPv6-Only. 337 * Added an Applicability Statements section to scope the intend 338 use. 339 * Changed requirement language to upper case, added Requirements 340 Language section with references to [RFC2119] and [RFC8174]. 341 * Editorial changes. 343 draft-hinden-ipv4flag-03, 2018-Feb-15: 345 * Changed terminology to use "link" instead of "network". 346 * Improved text in Section 4. "Host Behavior Considerations" and 347 added suggestion to only perform IPv4 if an application 348 requests it. 349 * Added clarification that the bit is set because an 350 administrator configured the router to send it. 351 * Editorial changes. 353 draft-hinden-ipv4flag-02, 2018-Feb-15: 355 * Improved text in introduction. 356 * Added reference to current IANA registry in Section 2. 357 * Editorial changes. 359 draft-hinden-ipv4flag-01, 2017-Dec-12 361 * Inverted name of flag from "Available" to "Unavailable". 362 * Added problem description and clarified scope. 363 * Added router and operational considerations. 364 * Added host behavior considerations. 365 * Extended security considerations. 366 * Added Acknowledgment section, including reference to prior 367 sunset4 draft. 369 draft-hinden-ipv4flag-00, 2017-Nov-17: 371 * Original version. 373 12. References 375 12.1. Normative References 377 [IANA-Ethertype] 378 "Ether Types", . 381 [IANA-RF] "IPv6 ND Router Advertisement flags", 382 . 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 387 RFC2119, March 1997, . 390 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 391 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 392 November 2005, . 394 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 395 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 396 DOI 10.17487/RFC4861, September 2007, . 399 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 400 Advertisement Flags Option", RFC 5175, DOI 10.17487/ 401 RFC5175, March 2008, . 404 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 405 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 406 May 2017, . 408 12.2. Informative References 410 [I-D.bz-v4goawayflag] 411 Zeeb, B., "IPv6 Router Advertisement IPv4 GoAway Flag", 412 draft-bz-v4goawayflag-00 (work in progress), March 2018. 414 [I-D.ietf-sunset4-noipv4] 415 Perreault, S., George, W., Tsou, T., Yang, T., and J. 416 Tremblay, "Turning off IPv4 Using DHCPv6 or Router 417 Advertisements", draft-ietf-sunset4-noipv4-01 (work in 418 progress), December 2014. 420 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 421 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 422 10.17487/RFC6105, February 2011, . 425 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 426 NAT64: Network Address and Protocol Translation from IPv6 427 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 428 April 2011, . 430 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 431 Beijnum, "DNS64: DNS Extensions for Network Address 432 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 433 DOI 10.17487/RFC6147, April 2011, . 436 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 437 Consumption of Router Advertisements", BCP 202, RFC 7772, 438 DOI 10.17487/RFC7772, February 2016, . 441 Authors' Addresses 443 Robert M. Hinden 444 Check Point Software 445 959 Skyway Road 446 San Carlos, CA 94070 447 USA 449 Email: bob.hinden@gmail.com 451 Brian Carpenter 452 Department of Computer Science 453 University of Auckland 454 PB 92019 455 Auckland 1142 456 New Zealand 458 Email: brian.e.carpenter@gmail.com