idnits 2.17.1 draft-pref64folks-6man-ra-pref64-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2018) is 2100 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 255 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 21, 2019 Google 6 July 20, 2018 8 Discovering PREF64 in Router Advertisements 9 draft-pref64folks-6man-ra-pref64-01 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 21, 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 . . . . . . . . . . . . . . . . . . . . . 4 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 59 7.2. Informative References . . . . . . . . . . . . . . . . . 5 60 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 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] require implementing 94 other protocols. 96 3. Semantics 98 This option specifies exactly one NAT64 prefix for all IPv4 99 destinations. If the network operator desires to route different 100 parts of the IPv4 address space to different NAT64 devices, this can 101 be accomplished by routing more specifics of the NAT64 prefix to 102 those devices. For example, if the operator would like to route 103 10.0.0.0/8 through NAT64 device A and the rest of the IPv4 space 104 through NAT64 device B, and the operator's NAT64 prefix is 105 2001:db8:a:b::/96, then the operator can route 106 2001:db8:a:b::a00:0/104 to NAT64 A and 2001:db8:a:b::/64 to NAT64 B. 108 This option may appear more than once in a Router Advertisement. 109 Host behaviour with regards to synthesizing IPv6 addresses from IPv4 110 addresses SHOULD follow the recommendations given in Section 5.1 of 111 [RFC7050], limited to the NAT64 prefixes that have non-zero lifetime. 113 In a network that provides both IPv4 and NAT64, it may be desirable 114 for certain IPv4 addresses not to be translated. An example might be 115 private address ranges that are local to the network and should not 116 be reached through the NAT64. This type of configuration cannot be 117 conveyed to hosts using this option, or through other NAT64 prefix 118 provisioning mechanisms such as [RFC7050] or [RFC7225]. This problem 119 does not apply in IPv6-only networks, because in such networks, the 120 host does not have an IPv4 address and cannot reach any IPv4 121 destinations without the NAT64. 123 For simplicity, this option only supports a NAT64 prefix length of 96 124 bits, as this is by the most common configuration used by hosts. 125 Networks using one of the other prefix lengths supported in 126 ([RFC6052]) can use other mechanisms such as [RFC7050] or [RFC7225]. 127 If different prefix lengths become common, another RA option could be 128 created to configure them. 130 4. Option format 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Type | Length | Lifetime | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | | 137 + Prefix + 138 | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 Figure 1: NAT64 Prefix Option Format 143 Fields: 145 Type 8-bit identifier of the RDNSS option type as assigned by 146 IANA: TBD 147 Length 8-bit unsigned integer. The length of the option (including 148 the Type and Length fields) is in units of 8 octets. The 149 sender MUST set the Length to 2. A host MUST ignore the 150 NAT64 prefix option if the length field value is 1. If the 151 Length field value exceeds 2, the host MUST utilize the 152 first 16 octets and ignore the rest of the option. 153 Lifetime 16-bit unsigned integer. The maximum time in seconds over 154 which this NAT64 prefix MAY be used. The value of Lifetime 155 SHOULD by default be set to lesser of 3 x MaxRtrAdvInterval 156 or 65535 seconds. A value of zero means that the prefix 157 MUST no longer be used. 158 Prefix The highest 96-bits of the NAT64 prefix. 160 5. IANA Considerations 162 The IANA is requested to assign a new IPv6 Neighbor Discovery Option 163 type for the PREF64 option defined in this document. 165 +---------------+-------+ 166 | Option Name | Type | 167 +---------------+-------+ 168 | PREF64 option | (TBD) | 169 +---------------+-------+ 171 Table 1 173 The IANA registry for these options is: 175 https://www.iana.org/assignments/icmpv6-parameters [1] 177 6. Security Considerations 179 Because Router Advertisements are required in all IPv6 configuration 180 scenarios, on IPv6-only networks, Router Advertisements must already 181 be secured, e.g., by deploying RA guard [RFC6105]. Providing all 182 configuration in Router Advertisements increases security by ensuring 183 that no other protocols can be abused by malicious attackers to 184 provide hosts with invalid configuration. 186 The security measures that must already be in place to ensure that 187 Router Advertisements are only received from legitimate sources 188 eliminate the problem of NAT64 prefix validation described in section 189 3.1 of [RFC7050]. 191 7. References 193 7.1. Normative References 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, 197 DOI 10.17487/RFC2119, March 1997, 198 . 200 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 201 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 202 DOI 10.17487/RFC6052, October 2010, 203 . 205 7.2. Informative References 207 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 208 Rose, "DNS Security Introduction and Requirements", 209 RFC 4033, DOI 10.17487/RFC4033, March 2005, 210 . 212 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 213 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 214 DOI 10.17487/RFC4861, September 2007, 215 . 217 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 218 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 219 DOI 10.17487/RFC6105, February 2011, 220 . 222 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 223 NAT64: Network Address and Protocol Translation from IPv6 224 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 225 April 2011, . 227 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 228 Beijnum, "DNS64: DNS Extensions for Network Address 229 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 230 DOI 10.17487/RFC6147, April 2011, 231 . 233 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 234 Combination of Stateful and Stateless Translation", 235 RFC 6877, DOI 10.17487/RFC6877, April 2013, 236 . 238 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 239 the IPv6 Prefix Used for IPv6 Address Synthesis", 240 RFC 7050, DOI 10.17487/RFC7050, November 2013, 241 . 243 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 244 Port Control Protocol (PCP)", RFC 7225, 245 DOI 10.17487/RFC7225, May 2014, 246 . 248 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 249 Better Connectivity Using Concurrency", RFC 8305, 250 DOI 10.17487/RFC8305, December 2017, 251 . 253 7.3. URIs 255 [1] https://www.iana.org/assignments/icmpv6-parameters 257 Authors' Addresses 259 Lorenzo Colitti 260 Google 261 Roppongi 6-10-1 262 Minato, Tokyo 106-6126 263 JP 265 Email: lorenzo@google.com 266 Erik Kline 267 Google 268 Roppongi 6-10-1 269 Minato, Tokyo 106-6126 270 JP 272 Email: ek@google.com 274 Jen Linkova 275 Google 276 1 Darling Island Rd 277 Pyrmont, NSW 2009 278 AU 280 Email: furry@google.com