idnits 2.17.1 draft-hunek-v6ops-nat64-srv-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2021) is 886 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations M. Hunek 3 Internet-Draft Technical University of Liberec 4 Intended status: Standards Track November 2021 5 Expires: 21 May 2022 7 NAT64/DNS64 detection via SRV Records 8 draft-hunek-v6ops-nat64-srv-00 10 Abstract 12 This document specifies how to discover the NAT64 pools in use and 13 DNS servers providing DNS64 service to the local clients. The 14 discovery made via SRV records allows the assignment of priorities to 15 the NAT64 pools and DNS64 servers. It also allows clients to have 16 different DNS providers than NAT64 providers while providing a secure 17 way via DNSSEC validation of provided SRV records. This way, it 18 provides DNS64 service regardless of DNS operator and DNS transport 19 protocol. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 5 May 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Problems with Current Solutions . . . . . . . . . . . . . . . 3 58 3.1. DNS-based method . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Methods based on other protocols . . . . . . . . . . . . 5 60 4. Local domain detection . . . . . . . . . . . . . . . . . . . 6 61 5. NAT64 service SRV record . . . . . . . . . . . . . . . . . . 6 62 6. DNS64 service SRV record . . . . . . . . . . . . . . . . . . 7 63 7. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1. Interaction with other methods . . . . . . . . . . . . . 8 65 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 12.2. Informative References . . . . . . . . . . . . . . . . . 14 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 The slower than expected adoption of the IPv6 resulted in the need 77 for reliable transition mechanisms that shut down legacy protocols in 78 the early adopters' network without waiting for latecomers. The 79 transition mechanisms like NAT64/DNS64 or 464XLAT [RFC6877] are 80 essential in the transition between dual-stack networks and IPv6-only 81 networks while not sacrificing the accessibility of the IPv4-only 82 services. It is essential for these transition mechanisms to 83 reliably and securely detect prefixes used for translation. Failing 84 to do so, the IPv4-only services would not be accessible, or the 85 traffic for these services could be kidnapped. 87 There are multiple solutions for detecting NAT64 prefixes, but none 88 of those are without problems and can fit different applications' 89 needs. This document describes a new DNS-based method that could 90 replace the method standardized by [RFC7050] and lately updated by 91 [RFC8880], as this method is incompatible with DNSSEC and does have 92 unrealistic prerequisites. 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 2. Terminology 104 CLAT: Customer-side translator as defined in [RFC6877]. 106 Node: Either physical device or an application capable of performing 107 DNS queries. 109 NAT64 FQDN: a fully qualified domain name (FQDN) for a NAT64 protocol 110 translator. 112 Pref64::/n: a IPv6 prefix used for IPv6 address synthesis [RFC6146]. 114 Pref64::WKA: an IPv6 address consisting of Pref64::/n and WKA at any 115 of the locations allowed by RFC 6052 [RFC6052]. 117 Secure Channel: a communication channel a Node has between itself and 118 a DNS64 server protecting DNS protocol-related messages from 119 interception and tampering. The Channel can be, for example, IPsec- 120 based virtual private network (VPN) tunnel or a link-layer utilizing 121 data encryption technologies. 123 Well-Known IPv4 Address (WKA): an IPv4 address that is well-known and 124 present in an A record for the well-known name as defined in 125 [RFC7050]. 127 3. Problems with Current Solutions 129 For means of comparison, current solutions are split into two groups. 130 The first one is the DNS-based solutions and the second one are 131 solutions based on other protocols. 133 3.1. DNS-based method 135 The DNS based method is represented by the current method of 136 [RFC7050] updated by the [RFC8880]. This method uses the Well-Known 137 Name 'ipv4only.arpa.' with only an A record to detect DNS64 service. 138 As this method depends on a specific DNS64 capable resolver with a 139 specific NAT64 prefix, a client has to use the resolver provided by 140 the NAT64 service provider. Furthermore, information about the NAT64 141 prefix in use is distributed only locally, so the third-party 142 resolvers have no information about it, so they cannot provide DNS64 143 service for them. 145 With the introduction of the DNS-over-HTTPS (DoH) [RFC8484], the 146 introduction of the third-party resolver made the [RFC7050] unusable 147 for clients using DoH. There is a quick fix provided by the 148 [RFC8880] that the Well-Known name should be treated differently - 149 resolved by autoconfigured resolver on a specific outbound interface 150 only. However, this would mean that the application/system stub 151 resolver has to keep track of the source of configured DNS resolvers, 152 which may be an unrealistic expectation. 154 Another design property of the [RFC7050] is its incompatibility with 155 the DNSSEC. In order for [RFC7050] to work, the DNSSEC has to be 156 turned off, and even the detection phase of this method could not use 157 it to verify the provided information. As the network operator does 158 not own the 'arpa.' domain, it cannot properly sign the AAAA record 159 for the Well-Known Name. Because of it, the first step of the NAT64 160 prefix detection is always insecure. 162 In order for [RFC7050] method to be secure, this method requires 163 these prerequisites: 165 * DNSSEC signed NAT64 FQDN 167 * Corresponding PTR 169 * Secure Channel between Node and resolver 171 * Trusted domain list 173 * No user input 175 The [RFC8880] adds another set of prerequisites: 177 * Stub resolver must distinguish between configuration sources of 178 recursive DNS 180 * Only autoconfiguration sources can provide recursive DNS to 181 resolve Well-Known Name 183 * Recursive DNS resolver is interface specific 185 Some of these listed prerequisites cannot be achieved in certain 186 networks without prior provisioning of the Node. This includes 187 recommended secure channel between a Node and DNS64 recursive 188 resolver on shared network segments and the Trusted Domain List 189 mandatory requirement that implicitly cannot be entered by a user. 190 As not every Node is provisioned by a network operator, especially in 191 smaller networks, and the generation process of the Trusted Domain 192 List is not defined. The implementations of the [RFC7050] seems to 193 ignore this requirement. However, without it, these implementations 194 are insecure. This is due to the fact that the path between a Node 195 and a resolver cannot be secured by the DNSSEC, and without Trusted 196 Domain List, any arbitrary data can be injected into a Node 197 configuration. 199 Requirements of the [RFC8880] are also hard to implement strictly 200 according to standard. The user-space application vendor that 201 implements its own stub resolver would like to implement [RFC8880] it 202 would require access to the information about network configuration 203 to keep track of which recursive DNS server has been received from 204 which interface and from which protocol. Presenting such information 205 to the user-space is not typical and requires system-level changes. 206 Furthermore, when strictly following the [RFC8880], the network 207 cannot use static configuration to have NAT64 functionality 208 autoconfigured from the DNS. 210 3.2. Methods based on other protocols 212 There are other solutions for detecting NAT64 prefixes based on 213 various protocols. Namely [RFC7225], [RFC8115] and [RFC8781]. 214 Regardless of the protocol used, these solutions have some common 215 properties that limit their user-space use. If an application vendor 216 would like to implement any of these methods, it would need to 217 include a client implementation of an underlying protocol, or the 218 system would need to provide an interface to obtain NAT64 prefix 219 detected by these methods to the user-space application. This is 220 much harder than making a DNS query inside an application. 222 Another common property of these methods is an expectation of local 223 DNS64 synthesis or CLAT presence on a Node. This may be the case for 224 some Nodes, but others may depend on this functionality from the 225 DNS64 resolver. For such Nodes, the DNS-based detection mechanism 226 could be the preferred solution. 228 It is fair to say that these methods are viable solutions for system- 229 level NAT64 prefix detection - implementations of a system DNS stub 230 resolver or CLAT daemon. These methods are not so easy to implement 231 for user-space applications and daemons that are not so tightly 232 integrated into an operating system. 234 4. Local domain detection 236 The Node should perform detection of the domain used by the network 237 operator. A Node MAY use any source of such information, but a Node 238 implementing the method described in this document MUST be able to 239 use the PTR record for Node's unicast address as one of such source. 241 A network operator that uses the method described in this document to 242 distribute NAT64 configuration to Nodes connected to its network MUST 243 provide a PTR record for every IPv6 address handed to the Node. The 244 PTR record MUST have valid DNSSEC signature and MUST point to 245 securely delegated zone with DNSSEC signed NAT64 SRV record. The SRV 246 record itself MUST point to DNSSEC signed AAAA record and MAY also 247 point to DNSSEC signed A record. 249 Both Node and a network operator MAY use other sources of information 250 about a local domain. If they decide to do so, the channel to 251 provide such information MUST be secured against undetected data 252 manipulation, as these sources may not provide the same level of 253 security as the DNSSEC signed PTR record. 255 Other sources of information about local domain MAY include (but are 256 not limited to): 258 * Node's FQDN 260 * Router Advertisement DNSSL option [RFC8106] 262 * DHCPv6 options: 57, 24, 39, 74 or 118 264 5. NAT64 service SRV record 266 This document specifies two new well-known SRV records. The one for 267 NAT64 prefix which Node MUST implement: 269 _nat64._ipv6.Name TTL Class SRV Priority Weight Port Target 271 The TTL, Class, Priority, and Weight follow the same scheme as 272 defined in [RFC2782] and have their standard meaning. 274 Port: IPv6 as L3 protocol does not use port numbers. Because of 275 that, this field SHOULD be either set to zero or SHOULD be used to 276 indicate the length of network prefix length in both IPv6 and IPv4 277 protocol, used for NAT64. In such a case, the port 16b integer MUST 278 be constructed by directly appending IPv4 pool prefix length after 279 the IPv6 prefix length decimally. Usually, this would mean 9632, 280 stating that the IPv6 prefix with a length of /96 is translated into 281 a single IPv4 address (/32). 283 Target: MUST point to AAAA record formed from Pref64::/n prefix and 284 WKA same way as in [RFC7050] (Pref64::WKA). The target MAY also 285 point to A record, in which case it SHOULD point to the IPv4 address 286 used for NAT64 (or base address of the NAT64 IPv4 prefix). A network 287 operator MAY indicate to Node that NAT64 service is not provided by 288 putting root domain target (".") into the SRV record. The Port field 289 value should be set to zero for such a record, and Node MUST stop 290 further NAT64 prefix detection for a given domain. 292 Note: The target MAY also point to AAAA record of Any-Source 293 Multicast prefix or Source-Specific Multicast prefix, similarly to 294 [RFC8115] this MAY be used to indicate a Node prefix used for 295 multicast translation. For this reason, a Node MUST check address 296 type before its use. One SRV record MUST NOT combine unicast and 297 multicast targets, and in the case of a multicast target, the Port 298 field value MUST be set to a value of 9600, and A record target MUST 299 be ignored by a Node. 301 6. DNS64 service SRV record 303 The second SRV record is for the discovery of the DNS64 service. 304 Support of this record is OPTIONAL, but Node SHOULD implement it. 306 _dns64.Protocol.Name TTL Class SRV Priority Weight Port Target 308 Record informs about location of DNS64 service. This record might be 309 used if the network operator does not want to deploy DNS64 in their 310 main DNS infrastructure. A DNS64 SRV record follows the rules 311 specified by [RFC2782] and does not modify the meaning of any field. 313 Server provided by this record SHOULD only be used for domain names 314 which have returned NODATA for AAAA record and for A record queries 315 when a Node is not performing DNS64 function and is not using CLAT. 317 7. Node Behavior 319 In the initial stage of the Node connected to the network - after the 320 Node is configured with an IP address; the Node MUST get local 321 domains used in the network. The method of obtaining such 322 information is described in the section Local domain detection. When 323 no local domain can be discovered, the Node SHOULD continue NAT64/ 324 DNS64 detection by other means. 326 After the list of local domains has been established, the Node MUST 327 query for a NAT64 SRV record for every domain in the list. The 328 result of such queries SHOULD be ordered by following the rules of 329 [RFC2782]. When multiple records have equal values of both priority 330 and weight, the records SHOULD maintain the same order as its domain 331 in the discovered domain list. 333 If a Node is not configured to perform DNS64 address synthesis and is 334 not using CLAT, it SHOULD perform a query for DNS64 SRV record for 335 every discovered domain with NAT64 SRV record. If such a record is 336 obtained, the Node SHOULD use preferred target of DNS64 SRV record to 337 query for FQDNs without AAAA record - when Node received NODATA 338 response for its query. Similarly, such Node SHOULD prefer target of 339 DNS64 SRV record for any A record query (like caused by Happy Eye- 340 Balls). 342 If the Node can validate DNS records via DNSSEC, the Node MUST 343 perform validation of NAT64/DNS64 SRV record. The default behavior 344 of Node SHOULD be to ignore any NAT64/DNS64 SRV records which cannot 345 be validated or did not pass the validation. 347 Any information received from DNS MUST respect TTL of received 348 records. The Node MUST perform a new detection before currently used 349 information expires. This also applies to information received from 350 other sources that include expiration. 352 7.1. Interaction with other methods 354 Proposed method does not aim to replace all other NAT64 prefix 355 detection methods. In fact, it should be the network operator who 356 should decide which detection method should be used in the network 357 and which should have a preference. One advantage of using SRV 358 records for NAT64 detection is their Priority and Weight fields that 359 allows to communicate such preference to a Node. 361 In accordance with the latest detection method the [RFC8781], other 362 detection method should be treated equally to SRV method with 363 following Priority and Weight fields: 365 +=========+==========+========+ 366 | Method | Priority | Weight | 367 +=========+==========+========+ 368 | RFC8115 | 100 | 0 | 369 +---------+----------+--------+ 370 | RFC7225 | 150 | 0 | 371 +---------+----------+--------+ 372 | RFC8781 | 200 | 0 | 373 +---------+----------+--------+ 374 | RFC7050 | 250 | 0 | 375 +---------+----------+--------+ 377 Table 1: Default priorities 378 of other methods 380 If a network operator prefers another method than the SRV method and 381 wants to provide the SRV method as a fallback, it should set the 382 priority field of the NAT64 SRV record to a higher value than 383 specified for a method that should be used as a primary. For 384 example, when a network operator uses Router Advertisement to 385 distribute NAT64 prefix information to its network and also wants to 386 use the SRV method as a fallback; it should set Priority field to 387 number higher than 200. 389 It is RECOMMENDED that network operators SHOULD NOT use values higher 390 than 249 in the Priority field of the NAT64 SRV record unless they 391 want to use [RFC7050] as a primary source of NAT64 prefix 392 configuration, and they have all Nodes connected in their network 393 properly configured for this. In order for this configuration to be 394 safe, the Nodes MUST follow all the mandatory and optional 395 requirements of both [RFC7050] and [RFC8880]. Otherwise, the 396 [RFC7050] SHOULD NOT be used as a primary configuration source. 398 Default priority values on Node SHOULD be user-configurable. 400 A Node SHOULD start the NAT64 detection process by performing the SRV 401 method. If it is successful and the SRV record Priority field value 402 is lower than configured values for other methods, the Node MUST NOT 403 use other detection methods. If the Priority value is higher than 404 configured Priority value of any other methods, the Node SHOULD also 405 perform detection methods with the lower priority values. Detection 406 SHOULD be done starting from the lowest configured Priority value to 407 the highest. The successful completion of any detection method MUST 408 stop further detection. 410 Similarly, the DNS64 function of the recursive resolver in use SHOULD 411 be treated equally to the DNS64 SRV record with the Priority field 412 value of 250. If the Node supports the DNS64 SRV record, Node is not 413 performing DNS64 function, it is not using CLAT and the DNS64 SRV 414 record has a lower Priority field value; the A record queries MUST be 415 sent to the target of such SRV record instead of Node's default 416 recursive resolver. 418 Regardless of the detection method used for DNS64 discovery, the Node 419 MUST NOT accept any DNS64 synthesized AAAA record outside detected 420 NAT64 prefixes. 422 8. Example 424 The Node is a home router connected to the ISP network in which the 425 NAT64/DNS64 is used, and the ISP has the following SRV records in 426 their zones: 428 * nat64.ipv6.example.com. IN SRV 5 10 9632 nat64-pool- 429 1.example.com. 431 * nat64-pool-1.example.com. IN AAAA 2001:db8:64:ff9b:1::c000:aa 433 * nat64-pool-1.example.com. IN A 192.0.2.64 435 * nat64.ipv6.example.com. IN SRV 10 10 9632 nat64-pool- 436 2.example.com. 438 * nat64-pool-2.example.com. IN AAAA 2001:db8:64:ff9b:2::c000:aa 440 * nat64-pool-2.example.com. IN A 192.0.2.164 442 * nat64.ipv6.example.net. IN SRV 10 10 9624 nat64-pool.example.net. 444 * nat64-pool.example.net. IN AAAA 2001:db8:64:ff9b:abc::c000:aa 446 * nat64-pool.example.net. IN A 198.51.100.0 448 * nat64.ipv6.example.invalid. IN SRV 10 10 9624 449 nat64-pool.example.org. 451 * nat64-pool.example.org. IN AAAA 2001:db8:64:ff9b:def::c000:aa 453 * nat64-pool.example.org. IN A 203.0.113.0 455 In addition, the zones "example.net" and "example.invalid" has got 456 DNS64 SRV records: 458 * dns64.tcp.example.net. IN SRV 5 10 53 dns64.example.net. 460 * dns64.udp.example.net. IN SRV 10 10 53 dns64.example.net. 462 * dns64.example.net. IN AAAA 2001:db8::53 464 * dns64.udp.example.invalid. IN SRV 10 10 53 dns64.example.org. 466 * dns64.example.org. IN AAAA 2001:db8:123::53 468 The Node has detected the following list of domains: 470 1. example.net 472 2. example.invalid 474 3. example.com 476 4. example.org 478 The Node would fetch all available SRV records and their A and AAAA 479 counterparts and sort them in the following order: 481 +===========================+========+==========+================+ 482 | Pool | DNSSEC | Priority | Reason | 483 +===========================+========+==========+================+ 484 | nat64-pool-1.example.com. | yes | 5 | lowest | 485 | | | | priority field | 486 +---------------------------+--------+----------+----------------+ 487 | nat64-pool.example.net. | yes | 10 | discovered | 488 | | | | first | 489 +---------------------------+--------+----------+----------------+ 490 | nat64-pool-2.example.net. | yes | 10 | higher | 491 | | | | priority field | 492 +---------------------------+--------+----------+----------------+ 493 | nat64-pool.example.org. | no | 10 | no valid | 494 | | | | DNSSEC chain | 495 +---------------------------+--------+----------+----------------+ 497 Table 2: Detectected Prefixes 499 After sorting, the DNSSEC validating Node SHOULD graylist any record 500 which cannot be validated by the DNSSEC. This example would be 501 "nat64-pool.example.org." because it has been obtained from insecure 502 domain "example.invalid". Such pool SHOULD NOT be used if it is not 503 confirmed by other DNSSEC secured record. 505 If the Node can act as a recursive or caching DNS server and it is 506 configured to provide the DNS64 service, it MUST provide this service 507 using a sorted list of NAT64 pools. For such Node, the process of 508 the NAT64/DNS64 ends here. 510 However, when the Node is not capable of performing AAAA record 511 synthesis or it is not configured to provide DNS64 service, and it is 512 not using CLAT, it MUST perform detection of DNS64. 514 When the Node supports the DNS64 SRV record, it MUST make a sorted 515 list of DNS64 servers from the DNS64 SRV records. If the Priority 516 field of the corresponding DNS64 record is higher than 250, and when 517 the Node does not support the DNS64 SRV record; the Node MUST perform 518 DNS64 detection for specified NAT64 pool by the [RFC7050] method. 520 The detection, according to [RFC7050], should be done by querying for 521 "ipv4only.arpa". If the reply contains a pool listed in the NAT64 522 pool list, the corresponding entry is marked as having DNS64 provided 523 by recursive DNS. 525 The DNS64 sorted list would look like this: 527 +====================+=======+========+==========+================+ 528 | Server | Proto | DNSSEC | Priority | Reason | 529 +====================+=======+========+==========+================+ 530 | dns64.example.net. | tcp | yes | 5 | lowest | 531 | | | | | priority field | 532 +--------------------+-------+--------+----------+----------------+ 533 | dns64.example.net. | udp | yes | 10 | higher | 534 | | | | | priority field | 535 +--------------------+-------+--------+----------+----------------+ 536 | dns64.example.org. | udp | no | 10 | no valid | 537 | | | | | DNSSEC chain | 538 +--------------------+-------+--------+----------+----------------+ 540 Table 3: Detectected DNS64 Servers 542 Sorting is done in the same fashion as any other SRV record with the 543 same exception of graylisting records without a valid DNSSEC chain. 544 Those SHOULD NOT be used when not confirmed by DNSSEC validated 545 record and SHOULD be kept at the end of the list. 547 For example, when ISP is providing DNS64 service in their main DNS 548 infrastructure only for pools in the domains "example.com" and 549 "example.org" and the pool "nat64-pool.example.net" is used only with 550 corresponding DNS64 server. The final sorted list of NAT64 prefixes 551 used by the Node in the ISP network would be: 553 +===========================+==========+==========+================+ 554 | Pool | State | Priority | Reason | 555 +===========================+==========+==========+================+ 556 | nat64-pool-1.example.com. | active | 5 | lowest | 557 | | | | priority field | 558 +---------------------------+----------+----------+----------------+ 559 | nat64-pool-2.example.net. | backup | 10 | higher | 560 | | | | priority field | 561 +---------------------------+----------+----------+----------------+ 562 | nat64-pool.example.net. | active* | 10 | only DNS64 SRV | 563 | | | | capable Node | 564 +---------------------------+----------+----------+----------------+ 565 | nat64-pool.example.org. | inactive | 10 | no valid | 566 | | | | DNSSEC chain | 567 +---------------------------+----------+----------+----------------+ 569 Table 4: Used Prefixes 571 As the pool "nat64-pool.example.net" is used only with the server 572 "dns64.example.net", this would effectively make it usable only for 573 Nodes supporting DNS64 SRV and not running DNS64 locally or not using 574 CLAT. For such Nodes, this pool would have priority over others 575 because lower Priority field value of the DNS64 SRV record. 577 Now, the Node has successfully identified NAT64 pools and the DNS64 578 servers in the ISP infrastructure. The discovered prefixes SHOULD be 579 considered safe, and DNSSEC validation of answers in these prefixes, 580 when a remote recursive resolver does the DNS64 synthesis, it MUST be 581 either disabled or performed by validating only the suffix. 583 9. Acknowledgements 585 The author of this document would like to thank Lee Howard, Gert 586 Doering, Fred Baker, Philip Homburg, Mikael Abrahamsson, Jordi Palet 587 Martinez, Gabor Lencse, Dan Wing for their valuable comments. 589 10. IANA Considerations 591 This document proposes two services, "_nat64" and "_dns64" in Service 592 field of SRV RR ([RFC2782]). 594 11. Security Considerations 596 The method proposed by this document relies on security principles 597 based on DNSSEC and secure discovery of local domain. In order to be 598 secure, the network operator MUST deploy DNSSEC on at least one 599 domain (advertised to the Node), establish a secure channel to this 600 advertisement, or provide every IPv6 address given to a Node with 601 DNSSEC secured PTR record. 603 12. References 605 12.1. Normative References 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, 609 DOI 10.17487/RFC2119, March 1997, 610 . 612 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 613 specifying the location of services (DNS SRV)", RFC 2782, 614 DOI 10.17487/RFC2782, February 2000, 615 . 617 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 618 NAT64: Network Address and Protocol Translation from IPv6 619 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 620 April 2011, . 622 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 623 the IPv6 Prefix Used for IPv6 Address Synthesis", 624 RFC 7050, DOI 10.17487/RFC7050, November 2013, 625 . 627 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 628 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 629 May 2017, . 631 12.2. Informative References 633 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 634 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 635 DOI 10.17487/RFC6052, October 2010, 636 . 638 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 639 Combination of Stateful and Stateless Translation", 640 RFC 6877, DOI 10.17487/RFC6877, April 2013, 641 . 643 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 644 Port Control Protocol (PCP)", RFC 7225, 645 DOI 10.17487/RFC7225, May 2014, 646 . 648 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 649 "IPv6 Router Advertisement Options for DNS Configuration", 650 RFC 8106, DOI 10.17487/RFC8106, March 2017, 651 . 653 [RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 654 Option for IPv4-Embedded Multicast and Unicast IPv6 655 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, 656 . 658 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 659 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 660 . 662 [RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router 663 Advertisements", RFC 8781, DOI 10.17487/RFC8781, April 664 2020, . 666 [RFC8880] Cheshire, S. and D. Schinazi, "Special Use Domain Name 667 'ipv4only.arpa'", RFC 8880, DOI 10.17487/RFC8880, August 668 2020, . 670 Author's Address 672 Martin Hunek 673 Technical University of Liberec 674 Studentska 1402/2 675 46017 Liberec 676 Czechia 678 Email: martin.hunek@tul.cz