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