idnits 2.17.1 draft-pref64folks-6man-ra-pref64-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 -- The document date (July 19, 2018) is 2080 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) -- Looks like a reference, but probably isn't: '1' on line 231 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance L. Colitti 3 Internet-Draft E. Kline 4 Intended status: Standards Track J. Linkova 5 Expires: January 20, 2019 Google 6 July 19, 2018 8 Discovering PREF64 in Router Advertisements 9 draft-pref64folks-6man-ra-pref64-00 11 Abstract 13 This document specifies a Router Advertisement option to configure 14 the NAT64 prefix. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 20, 2019. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 52 2. Why include the NAT64 prefix in Router Advertisements . . . . 2 53 3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Option format . . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 7.2. Informative References . . . . . . . . . . . . . . . . . 4 60 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 NAT64 [RFC6146] with DNS64 [RFC6147] is a widely-deployed mechanism 66 to provide IPv4 access on IPv6-only networks. In order to support 67 functions such as local validation of DNSSEC [RFC4033] responses, 68 464xlat [RFC6877], and local IPv4 address synthesis [RFC8305], the 69 host must be aware of the NAT64 prefix in use by the network. This 70 document specifies a Router Advertisement [RFC4861] option to 71 communicate the NAT64 prefix to hosts. 73 1.1. Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 2. Why include the NAT64 prefix in Router Advertisements 81 Fate sharing. NAT64 requires a routing to be configured. IPv6 82 routing configuration requires receiving an IPv6 Router Advertisement 83 [RFC4861]. Compared to currently-deployed NAT64 prefix discovery 84 methods such as [RFC7050], including the NAT64 prefix in the Router 85 Advertisement minimizes the number of packets required to configure a 86 host. This speeds up the process of connecting to a network that 87 supports NAT64/DNS64, and simplifies host implementation by removing 88 the possibility that the a can have an incomplete layer 3 89 configuration (e.g., IPv6 addresses and prefixes, but no NAT64 90 prefix). 92 Deployability. All IPv6 hosts and networks are required to support 93 [RFC4861]. Other options such as [RFC7225]b require implementing 94 other protocols. 96 3. Semantics 98 This option specifies exactly one NAT64 prefix for all IPv4 99 addresses. Observation of current deployments suggest that they use 100 RFC7050, which also only supports one prefix. 102 This option only supports the NAT64 prefix length of 96 bits. In the 103 unlikely event of use cases for shorter prefixes ([RFC6052]) emerging 104 another option could be created. 106 4. Option format 108 0 1 2 3 109 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Type | Length | Lifetime | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | | 114 + Prefix + 115 | | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Figure 1: NAT64 Prefix Option Format 120 Fields: 122 Type 8-bit identifier of the RDNSS option type as assigned by 123 IANA: TBD 124 Length 8-bit unsigned integer. The length of the option (including 125 the Type and Length fields) is in units of 8 octets. The 126 only valid value for this filed is 2. A host MUST ignore the 127 NAT64 prefix option if the length field value is not set to 128 2. 129 Lifetime 16-bit unsigned integer. The maximum time in seconds over 130 which this NAT64 prefix MAY be used. The value of Lifetime 131 SHOULD by default be set to lesser of 3 x MaxRtrAdvInterval 132 or 65535 seconds. A value of zero means that the prefix 133 MUST no longer be used. 134 Prefix The highest 96-bits of the NAT64 prefix. 136 5. IANA Considerations 138 The IANA is requested to assign a new IPv6 Neighbor Discovery Option 139 type for the PREF64 option defined in this document. 141 +---------------+-------+ 142 | Option Name | Type | 143 +---------------+-------+ 144 | PREF64 option | (TBD) | 145 +---------------+-------+ 147 Table 1 149 The IANA registry for these options is: 151 https://www.iana.org/assignments/icmpv6-parameters [1] 153 6. Security Considerations 155 Because Router Advertisements are required in all IPv6 configuration 156 scenarios, on IPv6-only networks, Router Advertisements must already 157 be secured, e.g., by deploying RA guard [RFC6105]. Providing all 158 configuration in Router Advertisements increases security by ensuring 159 that no other protocols can be abused by malicious attackers to 160 provide hosts with invalid configuration. 162 The security measures that must already be in place to ensure that 163 Router Advertisements are only received from legitimate sources 164 eliminate the problem of PREF64 validation described in section 3.1 165 of [RFC7050]. 167 7. References 169 7.1. Normative References 171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 172 Requirement Levels", BCP 14, RFC 2119, 173 DOI 10.17487/RFC2119, March 1997, 174 . 176 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 177 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 178 DOI 10.17487/RFC6052, October 2010, 179 . 181 7.2. Informative References 183 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 184 Rose, "DNS Security Introduction and Requirements", 185 RFC 4033, DOI 10.17487/RFC4033, March 2005, 186 . 188 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 189 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 190 DOI 10.17487/RFC4861, September 2007, 191 . 193 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 194 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 195 DOI 10.17487/RFC6105, February 2011, 196 . 198 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 199 NAT64: Network Address and Protocol Translation from IPv6 200 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 201 April 2011, . 203 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 204 Beijnum, "DNS64: DNS Extensions for Network Address 205 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 206 DOI 10.17487/RFC6147, April 2011, 207 . 209 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 210 Combination of Stateful and Stateless Translation", 211 RFC 6877, DOI 10.17487/RFC6877, April 2013, 212 . 214 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 215 the IPv6 Prefix Used for IPv6 Address Synthesis", 216 RFC 7050, DOI 10.17487/RFC7050, November 2013, 217 . 219 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 220 Port Control Protocol (PCP)", RFC 7225, 221 DOI 10.17487/RFC7225, May 2014, 222 . 224 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 225 Better Connectivity Using Concurrency", RFC 8305, 226 DOI 10.17487/RFC8305, December 2017, 227 . 229 7.3. URIs 231 [1] https://www.iana.org/assignments/icmpv6-parameters 233 Authors' Addresses 235 Lorenzo Colitti 236 Google 237 Roppongi 6-10-1 238 Minato, Tokyo 106-6126 239 JP 241 Email: lorenzo@google.com 243 Erik Kline 244 Google 245 Roppongi 6-10-1 246 Minato, Tokyo 106-6126 247 JP 249 Email: ek@google.com 251 Jen Linkova 252 Google 253 1 Darling Island Rd 254 Pyrmont, NSW 2009 255 AU 257 Email: furry@google.com