idnits 2.17.1 draft-hinden-ipv4flag-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 (November 17, 2017) is 2345 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 102, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'RFC4191' is mentioned on line 103, but not defined == Missing Reference: 'RFC4389' is mentioned on line 104, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-RF' Summary: 1 error (**), 0 flaws (~~), 4 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: May 21, 2018 November 17, 2017 8 IPv6 Router Advertisement IPv4 Availability Flag 9 draft-hinden-ipv4flag-00 11 Abstract 13 This document specifies a Router Advertisement Flag to indicate that 14 there is no IPv4 service on the advertising router. This document 15 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 May 21, 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 Availability Flag . . . . . . . . . . . . . . . . . . . 2 53 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 58 6.2. Informative References . . . . . . . . . . . . . . . . . 4 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 61 1. Introduction 63 This document specifies a Router Advertisement Flag to indicate that 64 there is no IPv4 service on the advertising router. 66 Hosts that support IPv4 and IPv6, usually called dual stack hosts, 67 need to work on IPv6 only networks. That is, a link where there are 68 no IPv4 routers and/or IPv4 services. Monitoring of IPv6-only 69 networks, for example at the IETF 100 meeting in Singapore, shows 70 that current dual stack hosts will create local auto-configured IPv4 71 addresses and attempt to reach IPv4 services. A mechanism is needed 72 to inform hosts that there is no IPv4 support and that they should 73 turn off IPv4. 75 Because there is no IPv4 support on these links, the only way to 76 notify the dual stack hosts on the link is to use an IPv6 mechanism. 77 An active notification will be much more robust than attempting to 78 deduce this state by the lack of IPv4 responses or traffic. 80 IPv4-only hosts, and dual-stack hosts that do not recognize the new 81 flag, will continue to attempt IPv4 operations, in particular IPv4 82 discovery protocols typically sent as link-layer broadcasts. This 83 legacy traffic cannot be prevented by any IPv6 mechanism. The value 84 of the new flag is limited to dual-stack hosts that recognize it. 86 This document specifies an new flag for IPv6 Neighbor Discovery 87 [RFC4861] Router Advertisement Flag [RFC5175]. It updates [RFC5175]. 89 2. IPv4 Availability Flag 91 RFC5175 currently defines the flags in the NDP Router Advertisement 92 message. This currently contains the following one-bit flags defined 93 in published RFCs: 95 0 1 2 3 4 5 6 7 96 +-+-+-+-+-+-+-+-+ 97 |M|O|H|Prf|P|R|R| 98 +-+-+-+-+-+-+-+-+ 100 M Managed Address Configuration Flag [RFC4861] 101 O Other Configuration Flag [RFC4861] 102 H Mobile IPv6 Home Agent Flag [RFC3775] 103 Prf Router Selection Preferences [RFC4191] 104 P Neighbor Discovery Proxy Flag [RFC4389] 105 R Reserved 107 This document defines bit 6 to be the IPv4 Available Flag: 109 4 IPv4 Available Flag [RFC4861] 111 This flag has two values. These are: 113 0 IPv4 is Available on this Router 114 1 IPv4 is Not Available on this Router 116 RFC 5175 requires that unused flag bits be set to zero. Therefore, a 117 router that does not support the new flag will not appear to assert 118 that IPv4 is unsupported. 120 If there are multiple IPv6 routers on a network, they might send 121 different values of the flag. A host that receives only RAs with the 122 flag set to 1 should not attempt IPv4 operations, unless it 123 subsequently receives at least one RA with the flag set to zero. 125 3. IANA Considerations 127 IANA is requested to assign the new Router Advertisement flag defined 128 in Section 2 of this document. Bit 6 is the next available bit in 129 this registry, IANA is requested to use this bit unless there is a 130 reason not to use this bit. 132 IANA should also register this new flag bit in IANA IPv6 ND Router 133 Advertisement flags Registry [IANA-RF]. 135 4. Security Considerations 137 This document shares the security issues with other parts of IPv6 138 Neighbor Discovery. General techniques to protect Router 139 Advertisement traffic such as Router Guard [RFC6105] are useful in 140 protecting these vulnerabilities. 142 A bad actor could use this mechanism to attempt turn off IPv4 service 143 on a network that is using IPv4. In that case, as long as there are 144 routers sending Router Advertisements with this Flag set to 0, this 145 would override this attack given the mechanism in Section 2. 146 Specifically a host would only turn off IPv4 service if it wasn't 147 hearing any Router Advertisement with the Flag set to 0. 149 5. Acknowledgments 151 [Your name here] 153 6. References 155 6.1. Normative References 157 [IANA-RF] "IPv6 ND Router Advertisement flags", 158 . 161 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 162 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 163 DOI 10.17487/RFC4861, September 2007, . 166 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 167 Advertisement Flags Option", RFC 5175, DOI 10.17487/ 168 RFC5175, March 2008, . 171 6.2. Informative References 173 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 174 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 175 10.17487/RFC6105, February 2011, . 178 Authors' Addresses 179 Robert M. Hinden 180 Check Point Software 181 959 Skyway Road 182 San Carlos, CA 94070 183 USA 185 Email: bob.hinden@gmail.com 187 Brian Carpenter 188 Department of Computer Science 189 University of Auckland 190 PB 92019 191 Auckland 1142 192 New Zealand 194 Email: brian.e.carpenter@gmail.com