idnits 2.17.1 draft-hinden-ipv4flag-02.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 (February 15, 2018) is 2259 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 145, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'RFC4389' is mentioned on line 147, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-RF' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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: August 19, 2018 February 15, 2018 8 IPv6 Router Advertisement IPv4 Unavailable Flag 9 draft-hinden-ipv4flag-02 11 Abstract 13 This document specifies a Router Advertisement Flag to indicate to 14 hosts that there is no IPv4 service on the advertising default IPv6 15 router. 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 August 19, 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. IPv4 Unavailable Flag . . . . . . . . . . . . . . . . . . . . 3 53 3. Router and Operational Considerations . . . . . . . . . . . . 4 54 4. Host Behavior Considerations . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 58 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 6 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 61 9.2. Informative References . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 This document specifies a Router Advertisement Flag to indicate to 67 hosts that there is no IPv4 service on the advertising default IPv6 68 router. The flag does not apply to non-default IPv6 routers. 70 Hosts that support IPv4 and IPv6, usually called dual stack hosts, 71 need to work on IPv6 only networks. That is, a link where there are 72 no IPv4 routers and/or IPv4 services. Dual stack is the default 73 configuration for most current host operating systems such as Windows 74 10, IOS, Android, Linux, and BSD, as well as devices such as 75 printers. Monitoring of IPv6-only networks, for example at the IETF 76 100 meeting in Singapore, shows that current dual stack hosts will 77 create local auto-configured IPv4 addresses and attempt to reach IPv4 78 services. This may be a problem for several reasons: 80 o It may result in an undesirable level of Layer 2 broadcast 81 traffic, especially on large wireless networks. 83 o In particular, this may overload switches in multi-segment 84 wireless networks because it will create IPv4 state for every dual 85 stack host. 87 o Such traffic may drain battery power on wireless hosts that have 88 no interest in link-local IPv4 traffic. [RFC7772] indicates how 89 this risk might be quantified. 91 o Similarly, hosts may waste battery power on futile attempts to 92 access IPv4 services. 94 o On an IPv6-only network, IPv4 might be used for malicious purposes 95 and pass unnoticed by IPv6-only monitoring mechanisms. 97 Some of these problems could be mitigated by configuring the Layer 2 98 infrastructure to drop IPv4 and DHCPv4 traffic by filtering 99 Ethertypes 0x0800 and 0x806. However although this would limit the 100 traffic to a single segment, it would not eliminate it. 102 This document defines a mechanism to inform hosts that there is no 103 IPv4 support on their default routers so that they may choose to turn 104 off IPv4, mitigating all of the above problems. Each TCP/IP host 105 implementation will differ in the way it handles the absence of IPv4 106 support, so the usefulness of this mechanism will vary. In any case 107 it is only a hint. 109 Because there is no IPv4 support on IPv6-only routers, the only way 110 to notify the dual stack hosts on the link is to use an IPv6 111 mechanism. An active notification will be much more precise than 112 attempting to deduce this fact by the lack of IPv4 responses or 113 traffic. 115 IPv4-only hosts, and dual-stack hosts that do not recognize the new 116 flag, will continue to attempt IPv4 operations, in particular IPv4 117 discovery protocols typically sent as link-layer broadcasts. This 118 legacy traffic cannot be prevented by any IPv6 mechanism. The value 119 of the new flag is limited to dual-stack hosts that recognize it. 121 Additionally, dual-stack hosts that support any form of link-local 122 service may choose to support such a service over IPv4 regardless of 123 the new mechanism. Similarly, it is possible that a network could be 124 configured with both IPv6-only routers and IPv4-only routers. For 125 that reason, the new mechanism is advisory in nature. Host behaviors 126 are discussed in more detail in Section 4. 128 This document specifies a new flag for IPv6 Neighbor Discovery 129 [RFC4861] Router Advertisement Flag [RFC5175]. It updates [RFC5175] 130 to add this flag. 132 2. IPv4 Unavailable Flag 134 RFC5175 currently defines the flags in the NDP Router Advertisement 135 message and these flags are registered in the IANA IPv6 ND Router 136 Advertisement flags Registry [IANA-RF]. This currently contains the 137 following one-bit flags defined in published RFCs: 139 0 1 2 3 4 5 6 7 140 +-+-+-+-+-+-+-+-+ 141 |M|O|H|Prf|P|R|R| 142 +-+-+-+-+-+-+-+-+ 143 M Managed Address Configuration Flag [RFC4861] 144 O Other Configuration Flag [RFC4861] 145 H Mobile IPv6 Home Agent Flag [RFC3775] 146 Prf Router Selection Preferences [RFC4191] 147 P Neighbor Discovery Proxy Flag [RFC4389] 148 R Reserved 150 This document defines bit 6 to be the IPv4 Unavailable Flag: 152 4 IPv4 Unavailable Flag [RFC4861] 154 This flag has two values. These are: 156 0 IPv4 is Available on this default Router 157 1 IPv4 is Not Available on this default Router 159 RFC 5175 requires that unused flag bits be set to zero. Therefore, a 160 router that does not support the new flag will not appear to assert 161 that IPv4 is unsupported. 163 Hosts receiving the Router Advertisement should only process this 164 flag if the advertising router is a Default Router. Specifically, if 165 the Lifetime field in the Router Advertisement is not zero, otherwise 166 it should be ignored. This is done to allow some IPv6 routers to 167 advertise information without being a Default Router and providing 168 IPv6 connectivity. 170 3. Router and Operational Considerations 172 Default IPv6 routers that do not support IPv4 should be configured to 173 set the IPv4 Unavailable flag to 1, unless the operator is aware that 174 IPv4 support is available from another router. Default IPv6 routers 175 that also support IPv4 must set the IPv4 Unavailable flag to 0. 177 Operators of large IPv6-only wireless networks are advised to use 178 Layer 2 techniques to drop IPv4 and DHCPv4 packets (Ethertypes 0x0800 179 and 0x806) at all switches, and to ensure that IPv4 and DHCPv4 Layer 180 3 features are disabled in all switches. 182 4. Host Behavior Considerations 184 As noted above, the IPv4 Unavailable flag is advisory. Hosts may 185 vary in their treatment of it. 187 A host may choose to delay all IPv4 operations at start-up until a 188 reasonable time has elapsed for RA messages to arrive. 190 If there are multiple IPv6 default routers on a network, they might 191 send different values of the flag. If at least one IPv6 default 192 router sends the flag with value 0, a dual stack host should assume 193 that IPv4 is available. If all IPv6 default routers send the flag 194 with value 1, a dual stack host may assume that IPv4 is not 195 available. 197 A host that receives only RAs with the flag set to 1 may choose not 198 to attempt any IPv4 operations, unless it subsequently receives at 199 least one RA with the flag set to zero. As soon as such an RA is 200 received, IPv4 operations should be started. 202 Alternatively, a host that receives only RAs with the flag set to 1 203 may choose to attempt IPv4 operations but at significantly lower 204 frequency than normal. For example, it may choose to lengthen the 205 interval between DHCPv4 discovery messages to much longer than the 64 206 seconds defined by [RFC2131]. 208 A host that receives only RAs with the flag set to 1 may choose not 209 to form an IPv4 link-local address. However, as noted above, if it 210 contains link-local applications that can use IPv4, it may instead 211 choose to form an IPv4 link-local address in the normal way 212 [RFC3927], and then send the discovery traffic for such applications. 214 In all of the above, the flag's value is considered valid for the 215 lifetime of the default router concerned, unless a subsequent RA 216 delivers a different flag value. If a default router expires (i.e., 217 no RA is received that refreshes its lifetime), the host must remove 218 this router's flag value from consideration. If the result is that 219 all surviving default routers have the flag set to 1, the host may 220 now assume that IPv4 is not available. In other words, at any given 221 time, the state of the flag as seen by the host is the logical AND of 222 the flags sent by all unexpired default IPv6 routers. 224 5. IANA Considerations 226 IANA is requested to assign the new Router Advertisement flag defined 227 in Section 2 of this document. Bit 6 is the next available bit in 228 this registry, IANA is requested to use this bit unless there is a 229 reason to use another bit in this registry. 231 IANA should also register this new flag bit in the IANA IPv6 ND 232 Router Advertisement flags Registry [IANA-RF]. 234 6. Security Considerations 236 This document shares the security issues with other parts of IPv6 237 Neighbor Discovery. General techniques to protect Router 238 Advertisement traffic such as Router Guard [RFC6105] are useful in 239 protecting these vulnerabilities. 241 A bad actor could use this mechanism to attempt turn off IPv4 service 242 on a network that is using IPv4, by sending Router Advertisements 243 with the IPv4 Unavailable Flag set to 1. In that case, as long as 244 there are routers sending Router Advertisements with this Flag set to 245 0, they would override this attack given the mechanism in Section 2. 246 Specifically a host would only turn off IPv4 service if it wasn't 247 hearing any Router Advertisement with the Flag set to 0. If the 248 advice in Section 3 is followed, this attack will fail. 250 Conversely, a bad actor could use this mechanism to turn on, or 251 pretend to turn on, IPv4 service on an IPv6-only network, by sending 252 Router Advertisements with the Flag set to 0. However, this is 253 really no different than what such a bad actor can do anyway, if they 254 have the ability to configure a bogus router in the first place. The 255 advice in Section 3 will minimize such an attack by limiting it to a 256 single network segment. 258 Note that manipulating the Router Preference [RFC4191] will not 259 affect either of these attacks: any IPv4 Unavailable Flag of 0 will 260 always override all Flags set to 1. 262 The new flag is neutral from an IPv6 privacy viewpoint, since it does 263 not affect IPv6 operations in any way. From an IPv4 privacy 264 viewpoint, it has the potential benefit of suppressing unnecessary 265 traffic that might reveal the existence of a host and the correlation 266 between its hardware and IPv4 addresses. 268 7. Acknowledgments 270 A closely related proposal was published earlier as 271 [I-D.ietf-sunset4-noipv4]. 273 Helpful comments were received from Lorenzo Colitti, David Farmer, 274 Fernando Gont, Erik Kline, Jen Linkova, Michael Richardson, James 275 Woodyatt, and other members of the 6MAN working group. 277 8. Change log [RFC Editor: Please remove] 279 draft-hinden-ipv4flag-01, 2018-Feb-15: 281 Improved text in introduction. 283 Added reference to current IANA registry in Section 2. 285 Editorial changes. 287 draft-hinden-ipv4flag-01, 2017-Dec-12 289 Inverted name of flag from "Available" to "Unavailable". 291 Added problem description and clarified scope. 293 Added router and operational considerations. 295 Added host behavior considerations. 297 Extended security considerations. 299 Added Acknowledgment section, including reference to prior sunset4 300 draft. 302 draft-hinden-ipv4flag-00, 2017-Nov-17: 304 Original version. 306 9. References 308 9.1. Normative References 310 [IANA-RF] "IPv6 ND Router Advertisement flags", 311 . 314 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 315 2131, DOI 10.17487/RFC2131, March 1997, . 318 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 319 Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 320 10.17487/RFC3927, May 2005, . 323 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 324 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 325 November 2005, . 327 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 328 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 329 DOI 10.17487/RFC4861, September 2007, . 332 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 333 Advertisement Flags Option", RFC 5175, DOI 10.17487/ 334 RFC5175, March 2008, . 337 9.2. Informative References 339 [I-D.ietf-sunset4-noipv4] 340 Perreault, S., George, W., Tsou, T., Yang, T., and J. 341 Tremblay, "Turning off IPv4 Using DHCPv6 or Router 342 Advertisements", draft-ietf-sunset4-noipv4-01 (work in 343 progress), December 2014. 345 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 346 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 347 10.17487/RFC6105, February 2011, . 350 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 351 Consumption of Router Advertisements", BCP 202, RFC 7772, 352 DOI 10.17487/RFC7772, February 2016, . 355 Authors' Addresses 357 Robert M. Hinden 358 Check Point Software 359 959 Skyway Road 360 San Carlos, CA 94070 361 USA 363 Email: bob.hinden@gmail.com 365 Brian Carpenter 366 Department of Computer Science 367 University of Auckland 368 PB 92019 369 Auckland 1142 370 New Zealand 372 Email: brian.e.carpenter@gmail.com