idnits 2.17.1 draft-ietf-6man-ipv6only-flag-03.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 (October 16, 2018) is 2019 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 222, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'RFC4389' is mentioned on line 224, 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: April 19, 2019 October 16, 2018 8 IPv6 Router Advertisement IPv6-Only Flag 9 draft-ietf-6man-ipv6only-flag-03 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 April 19, 2019. 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 . . . . . . . . . . . . . . . . . . . . 4 53 3. Applicability Statements . . . . . . . . . . . . . . . . . . 4 54 4. IPv6-Only Definition . . . . . . . . . . . . . . . . . . . . 4 55 5. IPv6-Only Flag . . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Router and Operational Considerations . . . . . . . . . . . . 6 57 7. Host Behavior Considerations . . . . . . . . . . . . . . . . 6 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 61 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 62 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 64 12.2. Informative References . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 an IPv6-only link, for example at 80 the IETF 100 meeting in Singapore, shows that current dual stack 81 hosts will create local auto-configured IPv4 addresses and attempt to 82 reach IPv4 services, even though they cannot configure a normal 83 address using DHCP. This may be a problem for several reasons, 84 depending on the equipment in use and its configuration, especially 85 on large wireless networks: 87 o It may result in an undesirable level of wasted Layer 2 broadcast 88 traffic. 90 o In particular, this may overload switches in multi-segment 91 wireless networks if the switches create IPv4 state for every dual 92 stack host. 94 o Such traffic may drain battery power on wireless hosts that have 95 no interest in link-local IPv4, ARP, and DHCPv4 relay traffic, but 96 receive unwanted IPv4 packets. [RFC7772] indicates how this risk 97 might be quantified. 99 o Similarly, hosts may waste battery power on futile attempts to 100 access services by sending IPv4 packets. 102 o On an IPv6-only link, IPv4 might be used for malicious purposes 103 and pass unnoticed by IPv6-only monitoring mechanisms. 105 In managed networks whose equipment allows it, these problems could 106 be mitigated by configuring the Layer 2 infrastructure to drop IPv4 107 and ARP traffic by filtering Ethertypes 0x0800 and 0x806 108 [IANA-Ethertype]. IPv6 uses a different Ethertype, 0x86DD, so this 109 filtering will not interfere with IPv6 traffic. Depending on the 110 equipment details, this would limit the traffic to the link from an 111 IPv4 sender to the switch, and would drop all IPv4 and ARP broadcast 112 packets at the switch. This document recommends using such 113 mechanisms when available. 115 However, hosts transmitting IPv4 packets would still do so, consuming 116 their own battery power and some radio bandwidth. The intent of this 117 specification is to provide a mechanism that prevents such traffic, 118 and also works on networks without the ability to filter L2 traffic, 119 or where there are portions of a network without the ability to 120 filter L2 traffic. It may also be valuable on unmanaged networks 121 using routers pre-configured for IPv6-only operations and where Layer 122 2 filtering is unavailable. 124 An assumption of this document is that no IPv4 DHCP server or relay 125 is active on the link, because it is an IPv6-only link. If this 126 assumption is false, the DHCP option to disable IPv4 stateless auto- 127 configuration [RFC2563] could be used. 129 The remainder of this document therefore assumes that neither 130 effective Layer 2 filtering nor the RFC 2563 DHCP option is 131 applicable to the link concerned. 133 Because there is no IPv4 support on IPv6-only routers, the only way 134 to notify the dual stack hosts that this link is IPv6-Only is to use 135 an IPv6 mechanism. An active notification will be much more precise 136 than attempting to deduce this fact by the lack of IPv4 responses or 137 traffic. 139 This document therefore defines a mechanism that a router 140 administrator can use to inform hosts that this is an IPv6-Only link 141 on their default routers such that they can disable IPv4 on this 142 link, mitigating all of the above problems. 144 IPv4-only hosts, and dual-stack hosts that do not recognize the new 145 flag, may continue to attempt IPv4 operations, in particular IPv4 146 discovery protocols typically sent as link-layer broadcasts. This 147 legacy traffic cannot be prevented by any IPv6 mechanism. The value 148 of the new flag is limited to hosts that recognize it. 150 A possible subsidiary use of the IPv6-Only flag is using it to 151 trigger IPv6-Only testing and validation on a link. 153 This document specifies a new flag for Router Advertisement Flag 154 [RFC5175]. It updates [RFC5175] to add this flag. 156 2. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in BCP 161 14 [RFC2119] [RFC8174] when, and only when, they appear in all 162 capitals, as shown here. 164 3. Applicability Statements 166 This OPTIONAL mechanism is designed to allow administrators to notify 167 hosts that the link is IPv6-Only. It SHOULD be only used in 168 IPv6-Only links (see below for definition). 170 Dual stack hosts that have a good reason to use IPv4, for example for 171 a specific IPv4 link-local service, can attempt to do so. Therefore 172 respect of the IPv6-Only flag is recommended, not mandatory, for 173 hosts. 175 Administrators SHOULD only use this mechanism if they are certain 176 that the link is IPv6-Only. For example, in cases where there is a 177 need to continue to use IPv4, when there are intended to be IPv4-only 178 hosts or IPv4 routers on the link, setting this flag to 1 is a 179 configuration error. 181 This mechanism is intended to be compatible with link-layer solutions 182 that filter out IPv4 traffic. 184 4. IPv6-Only Definition 186 IPv6-Only is defined to mean that no other versions of internet 187 protocol than IPv6 are intentionally running directly on the link. 188 Today this effectively simply means that IPv4 is not running on the 189 link, and it includes: 191 * No IPv4 traffic on the Link 192 * No IPv4 routers on the Link 193 * No DHCPv4 servers on the Link 194 * No IPv4 accessible services on the Link 195 * All IPv4 and ARP traffic may be blocked at Layer 2 by the 196 administrator 198 It is expected that on IPv6-Only networks it will be common for 199 access to IPv4 external services to be reached by techniques such as 200 NAT64 [RFC6146] and DNS64 [RFC6147] at the edge of the network. This 201 is beyond the scope of this document. 203 Note that IPv6-Only provides no information about other network 204 protocols than IP running directly over the link layer. It is out of 205 scope of this specification whether any such protocol is running on 206 the link or whether any protocol is tunneled over IPv6. 208 5. IPv6-Only Flag 210 RFC5175 currently defines the flags in the NDP Router Advertisement 211 message and these flags are registered in the IANA IPv6 ND Router 212 Advertisement flags Registry [IANA-RF]. This currently contains the 213 following one-bit flags defined in published RFCs: 215 0 1 2 3 4 5 6 7 216 +-+-+-+-+-+-+-+-+ 217 |M|O|H|Prf|P|R|R| 218 +-+-+-+-+-+-+-+-+ 220 M Managed Address Configuration Flag [RFC4861] 221 O Other Configuration Flag [RFC4861] 222 H Mobile IPv6 Home Agent Flag [RFC3775] 223 Prf Router Selection Preferences [RFC4191] 224 P Neighbor Discovery Proxy Flag [RFC4389] 225 R Reserved 227 This document defines bit 6 to be the IPv6-Only Flag: 229 6 IPv6-Only Flag 231 This flag has two values. These are: 233 0 This is not an IPv6-Only link 234 1 This is an IPv6-Only link 236 RFC 5175 requires that unused flag bits be set to zero. Therefore, a 237 router that does not support the new flag will not appear to assert 238 that this is an IPv6-Only link. 240 Hosts receiving the Router Advertisement SHOULD only process this 241 flag if the advertising router is a Default Router. Specifically, if 242 the Lifetime field in the Router Advertisement is not zero, otherwise 243 it SHOUD be ignored. This is done to allow some IPv6 routers to 244 advertise information without being a Default Router and providing 245 IPv6 connectivity. 247 Note that although this mechanism uses one of only two reserved flag 248 bits in the RA, an extension mechanism is defined in Section 4 of 249 [RFC5175] in case additional flags are ever required for future 250 extensions. 252 6. Router and Operational Considerations 254 Default IPv6 routers that are on an IPv6-Only link SHOULD be 255 configured to set the IPv6-Only flag to 1 on interfaces on this link. 256 In all other cases the flag SHOULD NOT be set to 1. 258 The intent is that the administrator of the router configures the 259 router to set the IPv6-Only flag if she/he wants to tell the hosts on 260 the link that the link is IPv6-Only. This is a configuration flag, 261 it is not something that the router decides on it's own. Routers MAY 262 log a configuration error if the flag is set and IPv4 is still active 263 on the routers interface to the link. 265 Operators of large IPv6-only wireless links are advised to also use 266 Layer 2 techniques to drop IPv4 and ARP packets (Ethertypes 0x0800 267 and 0x806) at all switches, and to ensure that IPv4 and ARP features 268 are disabled in all switches. 270 7. Host Behavior Considerations 272 If there are multiple IPv6 default routers on a link, they might send 273 different values of the flag. If at least one IPv6 default router 274 sends the flag with value 0, a dual stack host SHOULD NOT assume that 275 the link is IPv6-Only. If all IPv6 default routers send the flag 276 with value 1, a dual stack host SHOULD assume that this is an 277 IPv6-Only link. 279 A host that receives only RAs with the flag set to 1 SHOULD NOT 280 attempt any IPv4 operations, unless it subsequently receives at least 281 one RA with the flag set to zero. As soon as such an RA is received, 282 IPv4 operations SHOULD be started. 284 A host MAY choose to delay all IPv4 operations at start-up until a 285 reasonable time has elapsed for RA messages to arrive. If all RAs 286 received have the flag set, a host SHOULD also choose to not attempt 287 IPv4 operations until an application asks it to, specifically delay 288 performing DHCPV4 until it gets a request from an application to use 289 IPv4. This would avoid attempting to obtain IPv4 addresses if there 290 are no applications trying to use IPv4. 292 In all of the above, the flag's value is considered valid for the 293 lifetime of the default router concerned, unless a subsequent RA 294 delivers a different flag value. If a default router expires (i.e., 295 no RA is received that refreshes its lifetime), the host must remove 296 this router's flag value from consideration. If the result is that 297 all surviving default routers have the flag set to 1, the host SHOULD 298 assume that the link is IPv6-Only. In other words, at any given 299 time, the state of the flag as seen by the host is the logical AND of 300 the flags sent by all unexpired default IPv6 routers. 302 This also means that if all default routers have set the flag, the 303 flag for the host is thereby set. If the lifetimes of all the 304 routers subsequently expire, then the state of the flag for the host 305 becomes cleared. 307 8. IANA Considerations 309 IANA is requested to assign the new Router Advertisement flag defined 310 in Section 5 of this document. Bit 6 is the next available bit in 311 this registry, IANA is requested to use this bit unless there is a 312 reason to use another bit in this registry. 314 IANA is also requested to register this new flag bit in the IANA IPv6 315 ND Router Advertisement flags Registry [IANA-RF]. 317 9. Security Considerations 319 This document shares the security issues with other parts of IPv6 320 Neighbor Discovery. [RFC6104] discusses certain attacks and 321 mitigations. General techniques to protect Router Advertisement 322 traffic such as Router Guard [RFC6105] are useful in protecting 323 against these vulnerabilities. 325 A bad actor could use this mechanism to attempt turn off IPv4 service 326 on a link that is intentionally using IPv4, by sending Router 327 Advertisements with the IPv6-Only Flag set to 1. In that case, as 328 long as there are one or more routers sending Router Advertisements 329 with this Flag set to 0, they would override this attack given the 330 mechanism in Section 5. Specifically a host would only turn off IPv4 331 service if it wasn't hearing any Router Advertisement with the Flag 332 set to 0. If the advice in Section 6 is followed, this attack will 333 fail. In a situation where the bad actor has control of all routers 334 on the link and sends Router Advertisements with the IPv6-Only Flag 335 set to 1 from all of them, the attack will succeed, but so will many 336 other forms of router-based attack. 338 Conversely, a bad actor could use this mechanism to turn on, or 339 pretend to turn on, IPv4 service on an IPv6-only link, by sending 340 Router Advertisements with the Flag set to 0. However, this is 341 really no different than what such a bad actor can do anyway, if they 342 have the ability to configure a bogus router in the first place. The 343 advice in Section 6 will minimize such an attack by limiting it to a 344 single link. 346 Note that manipulating the Router Preference [RFC4191] will not 347 affect either of these attacks: any IPv6-Only Flag of 0 will always 348 override all Flags set to 1. 350 The new flag is neutral from an IPv6 privacy viewpoint, since it does 351 not affect IPv6 operations in any way. From an IPv4 privacy 352 viewpoint, it has the potential benefit of suppressing unnecessary 353 traffic that might reveal the existence of a host and the correlation 354 between its hardware and IPv4 addresses. It should be noted that 355 hosts that don't support this flag are not protected from IPv4-based 356 attacks. 358 10. Acknowledgments 360 A closely related proposal was published earlier as 361 [I-D.ietf-sunset4-noipv4]. 363 Helpful comments were received from Lorenzo Colitti, David Farmer, 364 Fernando Gont, Nick Hilliard, Erik Kline, Jen Linkova, Veronika 365 McKillop, George Michaelson, Michael Richardson, Mark Smith, Barbara 366 Stark, Tatuya Jinmei, Ole Troan, James Woodyatt, and other members of 367 the 6MAN working group. 369 Bjoern Zeeb has also produced a variant of this proposal and proposed 370 an IPv6 transition plan in [I-D.bz-v4goawayflag]. 372 11. Change log [RFC Editor: Please remove] 374 draft-ietf-6man-ipv6only-flag-03, 2018-October-16: 376 * Reorganized text about problem statement and applicability 377 * Added note about shortage of flag bits 378 * Clarified text about logging configuration error in Section 6 379 * Editorial changes. 381 draft-ietf-6man-ipv6only-flag-02, 2018-August-14: 383 * Added text to Section 9 to clarify that hosts not supporting 384 this flag are not protected from IPv4-based attacks. 385 * Editorial changes. 387 draft-ietf-6man-ipv6only-flag-01, 2018-June-29: 389 * Added text to section that defines what IPv6-Only includes to 390 clarify that only other version of the Internet protocol are in 391 scope. 392 * Added clarification if the lifetime of all routers expire. 393 * Editorial changes. 395 draft-ietf-6man-ipv6only-flag-00, 2018-May-21: 397 * Changed the file name to draft-ietf-6man-ipv6only-flag to match 398 the current tile and that it is a w.g. draft. 399 * Added new section that defines what IPv6-Only includes. 400 * Expanded description of using Layer 2 filter to block IPv4 and 401 ARP traffic. 402 * Editorial changes. 404 draft-hinden-ipv4flag-04, 2018-April-16: 406 * Changed the name of the document and flag to be the IPv6-Only 407 flag. 408 * Rewrote text to make it affirmative that this is used by an 409 administrator to tell the hosts that the link is IPv6-Only. 410 * Added an Applicability Statements section to scope the intend 411 use. 412 * Changed requirement language to upper case, added Requirements 413 Language section with references to [RFC2119] and [RFC8174]. 414 * Editorial changes. 416 draft-hinden-ipv4flag-03, 2018-Feb-15: 418 * Changed terminology to use "link" instead of "network". 420 * Improved text in Section 4. "Host Behavior Considerations" and 421 added suggestion to only perform IPv4 if an application 422 requests it. 423 * Added clarification that the bit is set because an 424 administrator configured the router to send it. 425 * Editorial changes. 427 draft-hinden-ipv4flag-02, 2018-Feb-15: 429 * Improved text in introduction. 430 * Added reference to current IANA registry in Section 2. 431 * Editorial changes. 433 draft-hinden-ipv4flag-01, 2017-Dec-12 435 * Inverted name of flag from "Available" to "Unavailable". 436 * Added problem description and clarified scope. 437 * Added router and operational considerations. 438 * Added host behavior considerations. 439 * Extended security considerations. 440 * Added Acknowledgment section, including reference to prior 441 sunset4 draft. 443 draft-hinden-ipv4flag-00, 2017-Nov-17: 445 * Original version. 447 12. References 449 12.1. Normative References 451 [IANA-Ethertype] 452 "Ether Types", . 455 [IANA-RF] "IPv6 ND Router Advertisement flags", 456 . 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 461 RFC2119, March 1997, . 464 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 465 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 466 November 2005, . 468 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 469 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 470 DOI 10.17487/RFC4861, September 2007, . 473 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 474 Advertisement Flags Option", RFC 5175, DOI 10.17487/ 475 RFC5175, March 2008, . 478 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 479 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 480 May 2017, . 482 12.2. Informative References 484 [I-D.bz-v4goawayflag] 485 Zeeb, B., "IPv6 Router Advertisement IPv4 GoAway Flag", 486 draft-bz-v4goawayflag-00 (work in progress), March 2018. 488 [I-D.ietf-sunset4-noipv4] 489 Perreault, S., George, W., Tsou, T., Yang, T., and J. 490 Tremblay, "Turning off IPv4 Using DHCPv6 or Router 491 Advertisements", draft-ietf-sunset4-noipv4-01 (work in 492 progress), December 2014. 494 [RFC2563] Troll, R., "DHCP Option to Disable Stateless Auto- 495 Configuration in IPv4 Clients", RFC 2563, DOI 10.17487/ 496 RFC2563, May 1999, . 499 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 500 Problem Statement", RFC 6104, DOI 10.17487/RFC6104, 501 February 2011, . 503 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 504 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 505 10.17487/RFC6105, February 2011, . 508 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 509 NAT64: Network Address and Protocol Translation from IPv6 510 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 511 April 2011, . 513 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 514 Beijnum, "DNS64: DNS Extensions for Network Address 515 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 516 DOI 10.17487/RFC6147, April 2011, . 519 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 520 Consumption of Router Advertisements", BCP 202, RFC 7772, 521 DOI 10.17487/RFC7772, February 2016, . 524 Authors' Addresses 526 Robert M. Hinden 527 Check Point Software 528 959 Skyway Road 529 San Carlos, CA 94070 530 USA 532 Email: bob.hinden@gmail.com 534 Brian Carpenter 535 Department of Computer Science 536 University of Auckland 537 PB 92019 538 Auckland 1142 539 New Zealand 541 Email: brian.e.carpenter@gmail.com