idnits 2.17.1 draft-ietf-6man-ipv6only-flag-05.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 RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- 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 (March 7, 2019) is 1875 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 233, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'RFC4389' is mentioned on line 235, 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: 4861, 5175 (if approved) B. Carpenter 5 Intended status: Standards Track Univ. of Auckland 6 Expires: September 8, 2019 B. Zeeb 7 March 7, 2019 9 IPv6 Router Advertisement IPv6-Only Flag 10 draft-ietf-6man-ipv6only-flag-05 12 Abstract 14 This document specifies a Router Advertisement Flag to indicate to 15 hosts that the administrator has configured the router to advertise 16 that the link is IPv6-Only. This document updates RFC4861 and 17 RFC5175. 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 http://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 September 8, 2019. 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 (http://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 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 55 3. Applicability Statements . . . . . . . . . . . . . . . . . . 4 56 4. IPv6-Only Definition . . . . . . . . . . . . . . . . . . . . 5 57 5. IPv6-Only Flag . . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Router and Operational Considerations . . . . . . . . . . . . 6 59 7. Host Behavior Considerations . . . . . . . . . . . . . . . . 7 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 63 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 66 12.2. Informative References . . . . . . . . . . . . . . . . . 13 67 Appendix A. Implementaton Status [RFC Editor: Please remove] . . 14 68 A.1. FreeBSD Implementation . . . . . . . . . . . . . . . . . 14 69 A.2. Test using Scapy . . . . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 This document specifies a Router Advertisement Flag to indicate to 75 hosts that the administrator has configured the router to advertise 76 that the link is IPv6-Only. The flag only applies to IPv6 default 77 routers. 79 Hosts that support IPv4 and IPv6, usually called dual stack hosts, 80 need to also work efficiently on IPv6-Only links, i.e, links where 81 there are no IPv4 routers and/or IPv4 services. Dual stack is the 82 default configuration for most current host operating systems such as 83 Windows 10, iOS, Android, Linux, and BSD, as well as devices such as 84 some printers. Monitoring of an IPv6-Only link, for example at the 85 IETF 100 meeting in Singapore, shows that current dual stack hosts 86 will create local auto-configured IPv4 addresses and attempt to reach 87 IPv4 services, even though they cannot configure a normal address 88 using DHCP. This may be a problem for several reasons, depending on 89 the equipment in use and its configuration, especially on large 90 wireless networks: 92 o It may result in an undesirable level of wasted Layer 2 broadcast 93 traffic. 95 o Switches in multi-segment wireless networks may create IPv4 state 96 for dual stack hosts (in particular, ARP cache entries to support 97 ARP proxying). 99 o Such traffic may drain battery power on wireless hosts that have 100 no interest in link-local IPv4, ARP, and DHCPv4 relay traffic, but 101 receive unwanted IPv4 packets. [RFC7772] indicates how this risk 102 might be quantified. 104 o Similarly, hosts may waste battery power on futile attempts to 105 access services by sending IPv4 packets. 107 o On an IPv6-Only link, IPv4 might be used for malicious purposes 108 and pass unnoticed by IPv6-Only monitoring mechanisms. 110 In networks with managed infrastructure whose equipment allows it, 111 these problems could be mitigated by configuring the Layer 2 112 infrastructure to drop IPv4 and ARP traffic by filtering Ethertypes 113 0x0800 and 0x0806 [IANA-Ethertype]. IPv6 uses a different Ethertype, 114 0x86DD, so this filtering will not interfere with IPv6 traffic. 115 Depending on the equipment details, this would limit the traffic to 116 the link from an IPv4 sender to the switch, and would drop all IPv4 117 and ARP broadcast packets at the switch. This document recommends 118 using such mechanisms when available. 120 However, hosts transmitting IPv4 packets would still do so, consuming 121 their own battery power and some radio bandwidth. The intent of this 122 specification is to provide a mechanism that prevents such traffic, 123 and also works on networks without the ability to filter L2 traffic, 124 or where there are portions of a network without the ability to 125 filter L2 traffic. It may also be valuable on unmanaged networks 126 using routers pre-configured for IPv6-Only operations and where Layer 127 2 filtering is unavailable. 129 An assumption of this document is that because it is an IPv6-Only 130 link there is no IPv4 DHCP server or relay active on the link. This 131 further means that the DHCP option to disable IPv4 stateless auto- 132 configuration [RFC2563] can not be used. 134 The remainder of this document therefore assumes that neither 135 effective Layer 2 filtering nor the RFC 2563 DHCP option is 136 applicable to the link concerned. 138 Because there is no IPv4 support on an IPv6-Only link, the only way 139 to notify the dual stack hosts that this link is IPv6-Only is to use 140 an IPv6 mechanism. An active notification will be much more precise 141 than attempting to deduce this fact by the lack of IPv4 responses or 142 traffic. 144 This document therefore defines a mechanism that a router 145 administrator can use to inform hosts that this is an IPv6-Only link 146 on their default routers such that they can disable IPv4 on this 147 link, mitigating all of the above problems. The mechanism is based 148 on the IPv6 Router Advertisement message because this is a type of 149 message that is certain to be received by every dual stack host, 150 regardless of what network management protocols may or may not be in 151 use. 153 IPv4-only hosts, and dual-stack hosts that do not recognize the new 154 flag, may continue to attempt IPv4 operations, in particular IPv4 155 discovery protocols typically sent as link-layer broadcasts. This 156 legacy traffic cannot be prevented by any IPv6 mechanism. The value 157 of the new flag is limited to hosts that recognize it. 159 A possible subsidiary use of the IPv6-Only flag is using it to 160 trigger IPv6-Only testing and validation on a link. 162 This document specifies a new flag for Router Advertisement Flag 163 [RFC5175]. It updates [RFC5175] to add this flag. It also updates 164 [RFC4861] to add an additional item to check and report. 166 2. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 3. Applicability Statements 176 This OPTIONAL mechanism is designed to allow administrators to notify 177 hosts that the link is IPv6-Only. It SHOULD be only used in 178 IPv6-Only links (see Section 4 for definition of IPv6-Only). For a 179 VLAN, the IPv6-Only flag only applies to the specific VLAN on which 180 it was received. 182 Dual stack hosts that have IPv4 active configuration obtained from 183 the network (e.g., via DHCP), can ignore the flag and continue to use 184 IPv4. 186 Administrators MUST only use this mechanism if they are certain that 187 the link is IPv6-Only. For example, in cases where there is a need 188 to continue to use IPv4, when there are intended to be IPv4-only 189 hosts or IPv4 routers on the link, setting this flag to 1 is a 190 configuration error. 192 This mechanism is intended to be compatible with link-layer solutions 193 that filter out IPv4 traffic. 195 4. IPv6-Only Definition 197 IPv6-Only is defined to mean that no other versions of Internet 198 Protocol than IPv6 are intentionally in use directly on the link. 199 Today this effectively simply means that IPv4 is not intentionally in 200 use on the link, and it includes: 202 * No IPv4 traffic on the link. 203 * No IPv4 routers on the link. 204 * No DHCPv4 servers on the link. 205 * No IPv4 accessible services on the link. 206 * All IPv4 and ARP traffic may be blocked at Layer 2 by the 207 administrator. 209 It is expected that on IPv6-Only networks it will be common to access 210 to IPv4 external services by techniques such as NAT64 [RFC6146] and 211 DNS64 [RFC6147] at the edge of the network. This is beyond the 212 scope of this document. 214 Note that IPv6-Only provides no information about other network 215 protocols than IP (and ARP) in use directly over the link layer. It 216 is out of scope of this specification whether any such protocol is in 217 use on the link or whether any protocol is tunneled over IPv6. 219 5. IPv6-Only Flag 221 RFC5175 currently defines the flags in the NDP Router Advertisement 222 message and these flags are registered in the IANA IPv6 ND Router 223 Advertisement flags Registry [IANA-RF]. This currently contains the 224 following one-bit flags defined in published RFCs: 226 0 1 2 3 4 5 6 7 227 +-+-+-+-+-+-+-+-+ 228 |M|O|H|Prf|P|R|R| 229 +-+-+-+-+-+-+-+-+ 231 M Managed Address Configuration Flag [RFC4861] 232 O Other Configuration Flag [RFC4861] 233 H Mobile IPv6 Home Agent Flag [RFC3775] 234 Prf Router Selection Preferences [RFC4191] 235 P Neighbor Discovery Proxy Flag [RFC4389] 236 R Reserved 238 This document defines bit 6 to be the IPv6-Only Flag: 240 S IPv6-Only Flag 242 This flag has two values. These are: 244 0 This is not an IPv6-Only link 245 1 This is an IPv6-Only link 247 RFC 5175 requires that unused flag bits be set to zero. Therefore, a 248 router that does not support the new flag will not appear to assert 249 that this is an IPv6-Only link. 251 Hosts receiving the Router Advertisement SHOULD only process this 252 flag if the advertising router is a Default Router. Specifically, if 253 the Lifetime field in the Router Advertisement is not zero, otherwise 254 it SHOULD be ignored. This is done to allow some IPv6 routers to 255 advertise information without being a Default Router and providing 256 IPv6 connectivity. 258 Note that although this mechanism uses one of only two reserved flag 259 bits in the RA, an extension mechanism is defined in Section 4 of 260 [RFC5175] in case additional flags are ever required for future 261 extensions. It should be noted that since RFC5175 was published in 262 2008, no new RA flags have been assigned in the IANA registry. 264 6. Router and Operational Considerations 266 Default IPv6 routers that are on an IPv6-Only link SHOULD be 267 configured by the administrator to set the IPv6-Only flag to 1 on 268 interfaces on this link. In all other cases the flag SHOULD NOT be 269 set to 1. 271 The intent is that the administrator of the router configures the 272 router to set the IPv6-Only flag if and only if she/he wants to tell 273 the hosts on the link that the link is IPv6-Only. This is a 274 configuration flag, it is not something that the router decides on 275 its own. Routers MAY log a configuration error if the flag is set 276 and IPv4 is still active on the router's interface to the link. 278 Routers implementing this document SHOULD log to system or network 279 management inconsistent setting of the IPv6-Only flag. This extends 280 the behaviour specified in Section 6.2.7 of [RFC4861]. 282 Operators of large IPv6-Only wireless links are advised to also use 283 Layer 2 techniques to drop IPv4 and ARP packets (Ethertypes 0x0800 284 and 0x0806) at all switches, and to ensure that IPv4 and ARP features 285 are disabled in all switches. 287 7. Host Behavior Considerations 289 Hosts that support the IPv6-Only RA flag MUST have a configuration 290 option to ignore or process the flag. The motivation for this 291 configuration option is for hosts that are capable of processing the 292 IPv6-Only flag to only act on the flag if they are configured to do 293 so. 295 If there are multiple IPv6 default routers on a link, they might send 296 different values of the flag. If at least one IPv6 default router 297 sends the flag with value 0, a dual stack host MUST NOT assume that 298 the link is IPv6-Only. If all IPv6 default routers send the flag 299 with value 1, a dual stack host SHOULD assume that this is an 300 IPv6-Only link. 302 A host that receives only RAs with the flag set to 1 SHOULD NOT 303 attempt any IPv4 operations, unless it subsequently receives at least 304 one RA with the flag set to zero. As soon as such an RA is received, 305 IPv4 operations MAY be started. 307 If the host has active IPv4 configuration information obtained from 308 the network (e.g., via DHCP), the flag can be ignored and IPv4 309 operations can continue. The host MAY implement a policy overriding 310 these default behaviors. 312 In the event that the host subsequently receives at least one RA with 313 the flag set to zero IPv4 operations MAY be started. 315 A host MAY delay all IPv4 operations at start-up or reconnection 316 until a reasonable time has elapsed for RA messages to arrive. If 317 all RAs received have the flag set to 1, a host SHOULD NOT attempt 318 IPv4 operations. 320 In all of the above, the flag's value is considered valid for the 321 lifetime of the default router concerned, unless a subsequent RA 322 delivers a different flag value. If a default router expires (i.e., 323 no RA is received that refreshes its lifetime), the host must remove 324 this router's flag value from consideration. If the result is that 325 all surviving default routers have the flag set to 1, the host SHOULD 326 assume that the link is IPv6-Only. In other words, at any given 327 time, the state of the flag as seen by the host is the logical AND of 328 the flags sent by all unexpired default IPv6 routers on the link. 330 This also means that if all default routers on the link have set the 331 flag, the resulting host state for the link is IPv6-Only. If the 332 lifetimes of all the routers on the link subsequently expire, then 333 the host state for the link is not IPv6-Only. 335 8. IANA Considerations 337 IANA is requested to assign the new Router Advertisement flag defined 338 in Section 5 of this document. Bit 6 is the next available bit in 339 this registry, IANA is requested to use this bit unless there is a 340 reason to use another bit in this registry. 342 IANA is also requested to register this new flag bit in the IANA IPv6 343 ND Router Advertisement flags Registry [IANA-RF]. 345 9. Security Considerations 347 This document shares the security issues with other parts of IPv6 348 Neighbor Discovery. [RFC6104] discusses certain attacks and 349 mitigations. General techniques to protect Router Advertisement 350 traffic such as Router Guard [RFC6105] are useful in protecting 351 against these vulnerabilities. 353 A bad actor could use this mechanism to attempt turn off IPv4 service 354 on a link that is intentionally using IPv4, by sending Router 355 Advertisements with the IPv6-Only flag set to 1. There are several 356 protections to reduce this attack. These are: 358 o There is configuration setting that controls if the host should 359 process the IPv6-Only flag. This gives local control over using 360 the flag and reduces the ability of a bad actor to turn off IPv4 361 for hosts that support the flag. 363 o As long as there are one or more routers sending Router 364 Advertisements with this flag set to 0, they would override this 365 attack given the mechanism in Section 5. Specifically a host 366 would only turn off IPv4 service if it wasn't hearing any Router 367 Advertisement with the flag set to 0. If the advice in Section 6 368 is followed, this attack will fail. 370 o An attack would not succeed if the dual stack hosts had active 371 IPv4 configuration. As specified in Section 7, a dual stack host 372 will ignore the flag if it has active IPv4 configuration. 374 In a situation where the bad actor has control of all routers on the 375 link and sends Router Advertisements with the IPv6-Only flag set to 1 376 from all of them and if the hosts don't have assigned IPv4 addresses, 377 the attack will succeed, but so will many other forms of router-based 378 attack. 380 Conversely, a bad actor could use this mechanism to turn on, or 381 pretend to turn on, IPv4 service on an IPv6-Only link, by sending 382 Router Advertisements with the flag set to 0. However, this is 383 really no different than what such a bad actor can do anyway, if they 384 have the ability to configure a bogus router in the first place. The 385 advice in Section 6 will minimize such an attack by limiting it to a 386 single link. 388 Note that manipulating the Router Preference [RFC4191] will not 389 affect either of these attacks: any IPv6-Only flag of 0 will always 390 override all flags set to 1. 392 The new flag is neutral from an IPv6 privacy viewpoint, since it does 393 not affect IPv6 operations in any way. From an IPv4 privacy 394 viewpoint, it has the potential benefit of suppressing unnecessary 395 traffic that might reveal the existence of a host and the correlation 396 between its hardware and IPv4 addresses. It should be noted that 397 hosts that don't support this flag are not protected from IPv4-based 398 attacks. 400 10. Acknowledgments 402 A closely related proposal was published earlier as 403 [I-D.ietf-sunset4-noipv4]. 405 Helpful comments were received from Lorenzo Colitti, David Farmer, 406 Fernando Gont, Nick Hilliard, Lee Howard, Erik Kline, Jen Linkova, 407 Veronika McKillop, George Michaelson, Alexandre Petrescu, Michael 408 Richardson, Mark Smith, Barbara Stark, Tatuya Jinmei, Ole Troan, 409 James Woodyatt, and other members of the 6MAN working group. 411 Bjoern Zeeb has also produced a variant of this proposal and proposed 412 an IPv6 transition plan in [I-D.bz-v4goawayflag]. 414 11. Change log [RFC Editor: Please remove] 416 draft-ietf-6man-ipv6only-flag-05, 2019-March-7: 418 * Added a host configuration option to Section 7 that controls if 419 the host should process the IPv6-Only flag. This provides 420 local control over using the use of flag and reduces the 421 ability of a bad actor to turn off IPv4 for hosts that support 422 the flag. 423 * Changed Section 7 to specify that the host can ignore flag set 424 to 1 if it has active IPv4 configuration obtained from the 425 network (e.g., via DHCP). Similar changes to Section 3 and 426 Section 9 427 * Clarification in Section 6 to strengthen the text about the 428 administrators intent. 429 * Added Bjoern Zeeb as an author. 430 * Updated information on FreeBSD implementation in Appendix A.1 431 * Editorial changes. 433 draft-ietf-6man-ipv6only-flag-04, 2018-November-4: 435 * Added text to Section 1 explaining why the mechanism is based 436 on Router Advertisements. 437 * Added text to Section 3 that for a VLAN, the IPv6-Only flag 438 only applies to the specific VLAN on which it was received. 439 * Changed Section 3 that administrators MUST only use this 440 mechanism if they are certain that the link is IPv6-Only, 441 instead of SHOULD. 442 * Added ARP to Section 4 protocols that the IPv6-Only flag 443 applies to. 444 * Renamed the IPv6-Only flag label from "6" to "S". 445 * Added pointers to Section 7.2.7 of RFC4861 in Section 6. 446 * Added that RFC4861 is also updated by Section 6 for routers 447 implementing this flag. 448 * Changed Section 7 from SHOULD NOT to MUST NOT. 449 * Added Appendix A on implementations and testing. 450 * Many small clarifications based on IPv6 list discussion and 451 editorial changes. 453 draft-ietf-6man-ipv6only-flag-03, 2018-October-16: 455 * Reorganized text about problem statement and applicability 456 * Added note about shortage of flag bits 457 * Clarified text about logging configuration error in Section 6 458 * Editorial changes. 460 draft-ietf-6man-ipv6only-flag-02, 2018-August-14: 462 * Added text to Section 9 to clarify that hosts not supporting 463 this flag are not protected from IPv4-based attacks. 464 * Editorial changes. 466 draft-ietf-6man-ipv6only-flag-01, 2018-June-29: 468 * Added text to section that defines what IPv6-Only includes to 469 clarify that only other version of the Internet Protocol are in 470 scope. 471 * Added clarification if the lifetime of all routers expire. 472 * Editorial changes. 474 draft-ietf-6man-ipv6only-flag-00, 2018-May-21: 476 * Changed the file name to draft-ietf-6man-ipv6only-flag to match 477 the current tile and that it is a w.g. draft. 478 * Added new section that defines what IPv6-Only includes. 479 * Expanded description of using Layer 2 filter to block IPv4 and 480 ARP traffic. 481 * Editorial changes. 483 draft-hinden-ipv4flag-04, 2018-April-16: 485 * Changed the name of the document and flag to be the IPv6-Only 486 flag. 487 * Rewrote text to make it affirmative that this is used by an 488 administrator to tell the hosts that the link is IPv6-Only. 489 * Added an Applicability Statements section to scope the intend 490 use. 491 * Changed requirement language to upper case, added Requirements 492 Language section with references to [RFC2119] and [RFC8174]. 493 * Editorial changes. 495 draft-hinden-ipv4flag-03, 2018-Feb-15: 497 * Changed terminology to use "link" instead of "network". 498 * Improved text in Section 4. "Host Behavior Considerations" and 499 added suggestion to only perform IPv4 if an application 500 requests it. 501 * Added clarification that the bit is set because an 502 administrator configured the router to send it. 503 * Editorial changes. 505 draft-hinden-ipv4flag-02, 2018-Feb-15: 507 * Improved text in introduction. 508 * Added reference to current IANA registry in Section 2. 510 * Editorial changes. 512 draft-hinden-ipv4flag-01, 2017-Dec-12 514 * Inverted name of flag from "Available" to "Unavailable". 515 * Added problem description and clarified scope. 516 * Added router and operational considerations. 517 * Added host behavior considerations. 518 * Extended security considerations. 519 * Added Acknowledgment section, including reference to prior 520 sunset4 draft. 522 draft-hinden-ipv4flag-00, 2017-Nov-17: 524 * Original version. 526 12. References 528 12.1. Normative References 530 [IANA-Ethertype] 531 "Ether Types", . 534 [IANA-RF] "IPv6 ND Router Advertisement flags", 535 . 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 540 RFC2119, March 1997, . 543 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 544 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 545 November 2005, . 547 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 548 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 549 DOI 10.17487/RFC4861, September 2007, . 552 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 553 Advertisement Flags Option", RFC 5175, DOI 10.17487/ 554 RFC5175, March 2008, . 557 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 558 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 559 May 2017, . 561 12.2. Informative References 563 [I-D.bz-v4goawayflag] 564 Zeeb, B., "IPv6 Router Advertisement IPv4 GoAway Flag", 565 draft-bz-v4goawayflag-00 (work in progress), March 2018. 567 [I-D.ietf-sunset4-noipv4] 568 Perreault, S., George, W., Tsou, T., Yang, T., and J. 569 Tremblay, "Turning off IPv4 Using DHCPv6 or Router 570 Advertisements", draft-ietf-sunset4-noipv4-01 (work in 571 progress), December 2014. 573 [RFC2563] Troll, R., "DHCP Option to Disable Stateless Auto- 574 Configuration in IPv4 Clients", RFC 2563, DOI 10.17487/ 575 RFC2563, May 1999, . 578 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 579 Problem Statement", RFC 6104, DOI 10.17487/RFC6104, 580 February 2011, . 582 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 583 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 584 10.17487/RFC6105, February 2011, . 587 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 588 NAT64: Network Address and Protocol Translation from IPv6 589 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 590 April 2011, . 592 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 593 Beijnum, "DNS64: DNS Extensions for Network Address 594 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 595 DOI 10.17487/RFC6147, April 2011, . 598 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 599 Consumption of Router Advertisements", BCP 202, RFC 7772, 600 DOI 10.17487/RFC7772, February 2016, . 603 [Scapy_RA] 604 "Router Advertisements with scapy (NETLAB)", 605 . 607 Appendix A. Implementaton Status [RFC Editor: Please remove] 609 At the time this document was written there is one implementation and 610 a few comparability tests. 612 A.1. FreeBSD Implementation 614 A FreeBSD implementation was written by Bjoern A. Zeeb. 616 Summary: 618 Changes for the IPv6-Only flag include updates of user space 619 utilities to announce the "S" (IPv6-Only) flag to the network and 620 to show it in management utilities. 622 The kernel logic includes a global flag to disable processing of 623 the IPv6-Only flag even if the logic to act upon the IPv6-Only 624 flag is compiled in. There are checks for IPv4 configuration on a 625 receiving interface, which if found, will also force the IPv6-Only 626 flag to be ignored. 628 Further there are input and output filters for IPv4, ARP, and 629 REVARP in place for when the flag passes the aforementioned checks 630 and is enabled. 632 In addition to the draft there is a manual option to enable the 633 IPv6-Only filtering logic manually to observe the system behaviour 634 on links without router(s) advertising the IPv6-Only flag. 636 The code was tested with 2 FreeBSD IPv6 routers, a FreeBSD laptop 637 on ethernet as well as wifi, and with Win10 and OSX clients (which 638 did not fall over with the "S" flag set but not understood). 640 More information and updates can be found at: 642 https://wiki.freebsd.org/IPv6/IPv6OnlyRAFlag 644 A.2. Test using Scapy 646 Independent tests have been done using [Scapy_RA] by Alexandre 647 Petrescu and Brian Carpenter to verify that setting the IPv6-Only 648 Flag did not break legacy hosts. Both verified that setting this 649 flag did not cause any adverse effects on Windows 10 and Android. 651 Authors' Addresses 653 Robert M. Hinden 654 Check Point Software 655 959 Skyway Road 656 San Carlos, CA 94070 657 USA 659 Email: bob.hinden@gmail.com 661 Brian Carpenter 662 Department of Computer Science 663 University of Auckland 664 PB 92019 665 Auckland 1142 666 New Zealand 668 Email: brian.e.carpenter@gmail.com 670 Bjoern A. Zeeb 671 Bruehlstr. 19 672 Bondorf 71149 673 Germany 675 Email: bzeeb+ietf@zabbadoz.net