idnits 2.17.00 (12 Aug 2021) /tmp/idnits61252/draft-thubert-v6ops-yada-yatt-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([INT-ARCHI], [IPv6], [IPv6-ADDRESSING]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC4291, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1122, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC4291, updated by this document, for RFC5378 checks: 2003-10-10) -- 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 (5 April 2022) is 46 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 1122, 4291 (if approved) 5 April 2022 5 Intended status: Informational 6 Expires: 7 October 2022 8 Yet Another Double Address and Translation Technique 9 draft-thubert-v6ops-yada-yatt-02 11 Abstract 13 This document provides a mechanism named YADA to extend the current 14 IPv4 Internet by interconnecting IPv4 realms via a common footprint 15 called the shaft. YADA extends [INT-ARCHI] with the support of an 16 IP-in-IP format used to tunnel packets across the shaft. This 17 document also provides a bump-in-the-stack method to enable YADA on a 18 legacy stack, e.g., to enable virtual machines without changing them. 19 This document also provides a stateless address and IP header 20 translation between YADA and IPv6 [IPv6] called YATT and extends 21 [IPv6-ADDRESSING] for the YATT format. YADA and YATT can take place 22 as a bump in the stack at either end, or within the network and 23 enables an IPv6-only stack to dialog with an IPv4-only stack across a 24 network that can be IPv6, IPv4, or mixed. YATT requires that the 25 IPv6 stack owns a prefix that derives from a YADA address and the 26 IPv4 stack is capable of YADA, so it does not replace a generic 4 to 27 6 translation mechanism for any v6 to any v4. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 7 October 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Extending RFC 1122 . . . . . . . . . . . . . . . . . . . . . 6 67 4. Extending RFC 4291 . . . . . . . . . . . . . . . . . . . . . 6 68 5. YADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. YATT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7. The structure of the shaft . . . . . . . . . . . . . . . . . 11 71 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 13.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 This document defines baby steps from an IPv4-only stack/gateway/ISP 84 to an IPv6-only version. The goal is to end with dual stack and 85 Carrier-Grade Network Address Translators (CG-NATs). The first step 86 called Yet Another Double Address (YADA) uses IPv4-only signaling. 87 The second step called Yet Another Translation Technique (YATT) 88 offers an IPv6-only signaling that is interchangeable with YADA, so 89 any router or stack may turn one into the other, allowing the stack 90 or the link to be one version only. A YADA-enabled IPv4 stack can 91 thus talk to a YATT-enabled IPv6 stack with neither CG-NATs nor dual 92 stack network in between, but a stack that is not aware of this 93 specification will still need a traditional NAT approach to 94 communicate. 96 The effort in this specification is to provide enough value / 97 incentive for an IPv4-only stack/gateway/ISP to make the step towards 98 YADA, as a push towards IPv6, and for an IPv6-only stack to support 99 YATT on top to pull IPv4 space in IPv6, with a low barrier for making 100 the baby step. For IPv4, going YADA expands the size/reach of the 101 Internet, and allows multiple parties to build their own IPv4 realm, 102 with control of interconnection with other realms. For an IPv6 node, 103 supporting YATT provides connectivity to the YADA world, and 104 automatically assigns a prefix in the node. 106 This first mechanism called YADA allows to grow the Internet beyond 107 the current IPv4 [IPv4] realm that limits its capacity to form public 108 addresses. Depending on the assignments to be made, the model allows 109 to reuse all IP addresses and all Autonomous System Number (ASN) 110 currently available in the internet hundreds to millions of times. 111 This is achieved by interconnecting IPv4 realms via a common 112 footprint called the shaft. 114 In the analogy of a building, the ground floor would be the Internet, 115 and each additional floor would be another IPv4 realm. The same 116 surface of floor is available in each level, analog to the full IPv4 117 addressing that is available in each realm. The same footprint is 118 dedicated across the building levels for the elevator shaft. The 119 elevator shaft enables a third dimension that spans across the levels 120 and allows to traverse from any level to any other level. The 121 elevator shaft cannot be used for living or office space. 123 /------------------------------------------------------ 124 / / 125 / |------------| realm 1 / 126 / /. /. / 127 / / . shaft / . (current IPv4 Internet) / 128 / |------------| . / 129 / . . . . / 130 ------------------------------------------------------/ 131 | . | | 132 /-----|------------|--|-------------------------------- 133 / | . | | / 134 / | |---------|--| realm 2 / 135 / | /. | /. / 136 / |/ . shaft |/ . / 137 / |------------| . / 138 / . . . . / 139 ------------------------------------------------------/ 140 | . | | 141 | . | | 142 | | . 143 | | . 144 . . | 145 . . | 146 | . | | 147 /-----|------------|--|-------------------------------- 148 / | . | | / 149 / | |---------|--| realm N / 150 / | / | / / 151 / |/ shaft |/ / 152 / |------------| / 153 / / 154 ------------------------------------------------------/ 156 Figure 1: The shaft 158 By analogy, YADA assigns IPv4 prefixes to a multinternet shaft; those 159 prefixes are common across the realms that are interconnected by the 160 shaft. A single /24 IPv4 prefix assigned allows for > 250 times the 161 capacity of the Internet as we know it at the time of this writing. 162 Multiple prefixes can be assigned to the shaft for unicast and 163 multicast communications, and each realm needs at least one unicast 164 address in the shaft called its realm address. A YADA address is 165 formed by the tuple (realm address, IPv4 address) and is advertised 166 in DNS as a new double-A record. 168 YADA leverages IP-in-IP encapsulation to tunnel packets across the 169 shaft while normal IPv4 operations happen within a realm. YADA 170 requires a change in the stack in the YADA endpoints that communicate 171 with other realms to support the IP-in-IP YADA encapsulation. YADA 172 also provides a bump in the stack method for legacy applications. 173 More in Section 5. 175 A second mechanism called Yet Another Translation Technique (YATT) 176 translates the YADA format into flat IPv6 [IPv6]. For unicast 177 addresses, YATT forms an IPv6 prefix by collating an well-known 178 assigned short prefix, the realm address (in the shaft), and the host 179 IPv4 address (locally significant within the realm). The resulting 180 IPv6 prefix is automatically owned by the host that owns the IPv4 181 address in the realm. YATT then forms an IPv6 address for that host 182 by collating a well-known Interface ID, so there's a one-to-one 183 relationship between the YADA and the IPv6 address derived from it. 184 More in Section 6. 186 A key concept for this specification is that YADA (the IPv4 187 formulation) and YATT (the IPv6 formulation) represent the same 188 thing. YADA uses IPv4 formats as plain IP-in-IP with no new 189 extension. YATT uses IPv6 format with the IPv4 addresses encoded on 190 the prefix. The formats are interchangeable, and a router can 191 convert one to another as the packet flows over a next-hop link that 192 can only carry the other address family. 194 2. Terminology 196 2.1. Glossary 198 This document often uses the following acronyms: 200 YADA: Yet Another Double Address 201 YATT: Yet Another Translation Technique 202 NAT: Network address Translation 203 IID: Interface ID 204 CG-NAT: Carrier Grade NAT 206 2.2. New Terms 208 This document often uses the following new terms: 210 IPv4 realm: A full IPv4 network like the current Internet. YADA 211 does not affect the traditional IPv4 operations within a realm. 212 The shaft: The shaft refers to a collection of IPv4 unicast and 213 multicast prefixes that are assigned to Inter-realm communications 214 and cannot be assigned to hosts or multicast groups within a 215 realm. 216 Realm address: An IPv4 address that derives from a shaft prefix. 217 Uni-realm address: A realm address that is unicast or anycast. A 218 realm may have more than one Uni-realm add ress. 220 Multi-realm address: A realm address that is multicast and denotes a 221 collection of realms. 222 YADA realm prefix: A prefix assigned to the shaft and from which 223 realm addresses can be derived. 224 YADA NAT prefix: A prefix assigned to the YADA bump-in-the-stack NAT 225 operation. 226 Double-A or YADA address: A YADA address is a tuple (realm address, 227 IPv4 address) where the IPv4 address is only significant within 228 the realm denoted by the realm address. 229 YATT Space: An IPv6 range that is assigned for YATT operation. 230 YATT prefix: An IPv6 prefix that is derived from a YADA address by 231 appending the YATT space prefix, the (truncated) realm address and 232 the IPv4 address. 233 YATT-IID: A 64-bit assigned constant that is used in YATT to 234 statelessly form an IPv6 address from a YATT prefix. 235 Multinternet: A collection of IPv4 realms interconnected using a 236 common shaft. 238 3. Extending RFC 1122 240 YADA extends [INT-ARCHI] to add the capability for an IPv4 host to 241 recognize an special IP-in-IP format as an inter-realm IPv4 packet 242 and process it accordingly. It also adds a new DNS double-A record 243 format that denotes a YADA address. 245 4. Extending RFC 4291 247 YATT extends [IPv6-ADDRESSING] to add the capability for an IPv4 host 248 to recognize an special IPv6 format as an YATT address embedding a 249 YADA address and process it accordingly. It also automatically 250 derives the ownership of the YATT prefix associated to a owned YADA 251 address. 253 5. YADA 255 YADA assigns IPv4 prefixes to a multinternet shaft; those prefixes 256 must be the same across all the realms that are interconnected by the 257 shaft. Multiple prefixes can be assigned to the shaft for unicast 258 and multicast communications, and each realm needs at least one 259 unicast address in the shaft called its realm address. A YADA 260 address is formed by the tuple (realm address, IPv4 address) and is 261 advertised in DNS as a new double-A record. Because the YADA 262 prefixes are assigned for YADA, a packet that has either source or 263 destination IPV4 address derived from a shaft prefix is a YADA 264 packet. 266 YADA leverages IP-in-IP encapsulation to tunnel packets across the 267 shaft for inter-realm communications, while the IPv4 operations 268 within a realm are unaffected. The YADA address is found by using 269 both inner and outer header and combining that information. The pair 270 of IP headers is seen by a YADA stack as a single larger header 271 though a non-YADA forwarder only needs the outer header and plain 272 IPv4 operations to forward. 274 <----------------------------- 20 bytes ----------------------------> 275 +------------ ... ------------+-----------------+-------------------+ 276 | IPv4 header fields | Source realm | destination realm | 277 | | IPv4 Address | IPv4 Address | 278 +------------ ... ------------+-----------------+-------------------+ 279 | IPv4 header fields | Source node | destination node | 280 | | IPv4 Address | IPv4 Address | 281 +------------ ... ------------+-----------------+-------------------+ 282 . Options . 283 +------------ ... --------------------------------------------------+ 284 | | 285 . Data . 286 | | 287 +-------------------------------------------------------------------+ 289 Figure 2: YADA format in the source realm 291 YADA requires a change in the stack in the YADA endpoints that 292 communicate with other realms to support the YADA encapsulation. 293 YADA also provides a bump in the stack method for legacy 294 applications. YADA also requires a change for the routers that serve 295 the shaft. Those routers play a special role for packets that are 296 delivered from the shaft to the destination realm, and for ICMP 297 errors across realms. All other IPv4 nodes in the realm continue to 298 operate as before. 300 Routers serving the shaft advertise the shaft prefix(es) in their 301 respective realms, and their realm addresses within the shaft, as 302 host routes for unicast and anycast addresses. A stack that resolve 303 a DNS name with a double-A record indicating a different realm 304 generates an IP-in-IP packet, with the outer header indicating the 305 source and destination realms, and the inner header indicating the 306 source and destination IPv4 addresses within the respective realms, 307 as shown in Figure 3. The packet is forwarded down the shaft as is, 308 using the normal longest match or multicast operation. 310 | | 311 /------|------------|--------------------------------- 312 / | | / 313 / | | | | / 314 / | |--------|---| Source Node / 315 / | / | / / 316 / | /. +---|---- outer(src=src-realm / 317 / |/ . | |/ . dst=dst-realm) / 318 / |------------| . inner(src=src-addr / 319 / . . | . . dst=dst-addr) / 320 / . . | . . / 321 / . . | . . / 322 -----------------------------------------------------/ 323 | | | | 324 | | | forwarded unchanged 325 | | | down the shaft 326 v 328 Figure 3: Packets Entering the shaft 330 The packet destination is an address is the shaft and it is attracted 331 by a router that serves the shaft and advertises its prefixes in the 332 source realm. Based on longest match, the router forwards the packet 333 inside the shaft following the host route to a router that serves the 334 destination realm. That router swaps the destination address in the 335 inner and outer headers and forwards within its realm to the final 336 destination, as shown in Figure 4. 338 <----------------------------- 20 bytes ----------------------------> 339 +------------ ... ------------+-----------------+-------------------+ 340 | IPv4 header fields | Source realm | destination node | 341 | | IPv4 Address | IPv4 Address | 342 +------------ ... ------------+-----------------+-------------------+ 343 | IPv4 header fields | Source node | destination realm | 344 | | IPv4 Address | IPv4 Address | 345 +------------ ... ------------+-----------------+-------------------+ 346 . Options . 347 +------------ ... --------------------------------------------------+ 348 | | 349 . Data . 350 | | 351 +-------------------------------------------------------------------+ 353 Figure 4: YADA format in the destination realm 355 In normal conditions, the stack of the destination node recognizes 356 the YADA format and replies accordingly. 358 | 359 | | | 360 | | | 361 /------|----|-------|--------------------------------- 362 / | | | | | / 363 / | | | | | / 364 / | |----|---|---| Destination Node / 365 / | / | | / / 366 / | /. +---|----> outer(src=src-realm / 367 / |/ . |/ . dst=dst-addr) / 368 / |------------| . inner(src=src-addr / 369 / . . . . dst=realm-addr) / 370 / . . . . / 371 / . . . . / 372 -----------------------------------------------------/ 374 destinations swapped at shaft egress 376 Figure 5: Packets Outgoing the shaft 378 In case of an error down the path or at the destination, if an ICMP 379 message is generated by a node that is not YADA-aware, the message 380 reaches the router that serves the shaft in the source realm. If the 381 inner header is present in the ICMP payload, then the Router extracts 382 it and forwards to the packet source. If the destination stack does 383 not support YADA and decapsulates, the message reaches the router 384 that serves the destination realm which logs and drops. based on the 385 log, the node may be updated, or the DNS records may be fixed to 386 avoid pointing on a node that does not support YADA. 388 YADA requires the assignment of a second IPv4 prefix, this time for a 389 internal NATing operation. A bump-in-the-stack intercepts the DNS 390 lookups, and when the response yields a double-A record with a 391 foreign realm, the record is augmented with an IPv4 address taken 392 from a local NAT pool. When the stack sends a packet to that 393 particular address, the bump-in-the-stack translates to the YADA 394 format, using the information in the double-A record for the 395 destination, and the local realm as source realm. The other way 396 around, if a packet arrives with a YADA format but the stack does not 397 support it, the bump-in-the-stack allocates an address from the pool, 398 and NATs to IPv4 using that address as source. 400 YADA was initially published as USPTO 7,356,031, filed in February 401 2002. 403 6. YATT 405 A second mechanism called YATT translates the YADA format into flat 406 IPv6. 408 +-----+---------------+--------------+-----------------------------+ 409 |YATT | Realm | IPv4 | Well-Known | 410 |Space| Address | Address | IID | 411 +-----+- -------------+--------------+-----------------------------+ 412 <- YADA 413 prefix -> 414 <-------- YATT prefix ----------> 416 Figure 6: YATT format 418 For unicast addresses, YATT forms an IPv6 prefix by collating an 419 well-known assigned short prefix called the YATT space, the realm 420 address, and the host IPv4 address (locally significant within the 421 realm). The resulting IPv6 prefix is automatically owned by the host 422 that owns the IPv4 address in the realm. 424 Depending on assignment, the leftmost piece realm prefix may be 425 truncated if it is well-known, to allow the YATT space and the realm 426 address to fit in a 32-bit DWORD. This way, the YATT prefix can be a 427 full /64 prefix that is entirely owned by the host that owns the 428 associated YADA address. 430 YATT then forms an IPv6 address for that host by collating a well- 431 known Interface ID, so there's a one-to-one relationship. 433 The formats can not be strictly provided till the YATT space and YADA 434 prefix are assigned. But say that the YATT Space is F000::/6 and the 435 YADA prefix is 240.0.0.0/6. In that case the values perfectly 436 overlap and the YATT format becomes as follows: 438 +-----+----------+----------------+---------------------------------+ 439 | Realm Address | IPv4 Host | Well-Known | 440 | in 240.0.0.0/6 | Public Address | IID | 441 +-----+- --------+----+-----------+---------------------------------+ 442 <--- 32 bits ---><--- 32 bits ---><------------ 64 bits ------------> 443 <------ YATT IPv6 prefix -------> 445 Figure 7: YATT format using 240.0.0.0/6 447 In that case, the NAT operation is a plain insertion. Depending on 448 the assignment, it might be that the Realm address must be placed in 449 full after YATT space. In that case, the length of the YATT prefix 450 will be more than 64 bits. 452 Also, since 240.0.0.0/6 is currently unassigned, using it for the 453 shaft would allow literally to reuse every ASN and every IPv4 address 454 currently available in the Internet in each and every other realm and 455 reallocate them in any fashion desirable in that realm. 457 If the network supports IPv6 to the shaft, it makes sense for the 458 YADA host or the bump-in-the-stack to generate the packets in the 459 YATT form natively. The shaft router must then attract the shaft 460 YADA realm prefix in both IPv4 and YATT forms. 462 If the network is IPv4 only, the packets are still generated using 463 IP-in-IP, and the YATT NAT operation may happen at the router that 464 delivers the packet in the destination realm, if it is v6-only, or in 465 the destination host, if its stack is v6-only. 467 YATT was initially published as USPTO 7,764,686, filed in December 468 2002. 470 7. The structure of the shaft 472 A 10 miles view of the shaft could be as follows: it is implemented 473 in one IXP, spans all realms, and each realm has one address in the 474 shaft, with one router serving that realm. The address of the realm 475 is encoded in a loopback in the router, and advertised through an IGP 476 inside the shaft, while BGP is used inside the realms but not inside 477 the shaft. The shaft has a single large prefix that is advertised in 478 each realm by the router that serves the shaft, and that is 479 disaggregated into host routes inside the shaft. 481 None of the above is expected to remain true for long. As YADA and 482 YATT get deployed, the shaft will be implemented in different sites 483 over the world. A realm may be multihomed to be reached from a 484 different physical instance of the shaft, meaning that the shaft is 485 composed of either more prefixes or the shaft prefix is 486 disaggregated. Multiple routers will serve the same realm with high 487 availability and load balancing taking place inside the shaft to 488 maintain connectivity. Some shafts may be deployed to interconnect 489 only a subset of the realms, in which case those shafts would share a 490 specific prefix that would not be advertised outside the concerned 491 realms. 493 8. Applicability 495 YADA And YATT enable communication between YADA-enabled IPv4 nodes 496 across realms, and with IPv6 nodes that own a YADA address from which 497 a YATT address can be derived. Communication from a legacy IPv4 498 application/stack that is not YADA-enabled, or to an IPv6 address 499 that is not a YATT address, is not provided. 501 Since the YATT translation is stateless, the header translation can 502 happen anywhere in the network, e.g., as a bump in the stack at 503 either end, or within the network, e.g., at the routers that serve 504 the realms on the shaft. The shaft itself is expected to be dual 505 stack to forward packets in their native form, either v4 or v6. 507 For a legacy IPv4 node to communicate with YADA-enabled IPv4 node in 508 another realm, a NAT operation similar to NAT46 [NAT-DEPLOY], but 509 between IPv4 and YADA addresses, is required. The same would be 510 required to allow an IPv4-only YADA node to communicate with an IPv6 511 node a a non-YATT address. 513 In summary: 515 * this specification does not allow any IPv4 legacy node to talk to 516 any pure IPv6 node, and recognizes that this Graal may actually be 517 a non-goal. 519 * With YADA the current IPv4 Internet operations are not affected 521 * YADA extends the IPv4-reachable world by creating (millions of) 522 parallel realms and changing (only) the stack on the hosts that 523 require inter-realm communication and specific routers at the 524 ingress of the realms 526 * A YADA node can talk (using IPv4) to a YATT node (using IPv6) with 527 a stateless translation. The translation can happen anywhere in 528 the network or in the stack. 530 * a YATT node being an IPv6 can talk to any other IPv6 nodes. 532 9. Backwards Compatibility 534 YADA operation does not affect the intra-realm communication. The 535 only affected stacks are the endpoints that communicate between 536 realms leveraging YADA. 538 10. Security Considerations 540 11. IANA Considerations 542 This document requires the creation of a registry for IPv4 YADA realm 543 prefixes, and the assignment of at least one YADA realm prefix. 545 This document requires the creation of a registry for IPv4 YADA NAT 546 prefixes, and the assignment of at least one YADA NAT prefix. 548 This document requires the creation of a new record in the Resource 549 Record (RR) TYPEs subregistry of the Domain Name System (DNS) 550 Parameters. The new record would be of type AA meaning a YADA 551 address. 553 12. Acknowledgments 555 The author wishes to thank Greg Skinner as the first reviewer/ 556 contributor to this work. 558 13. References 560 13.1. Normative References 562 [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, 563 DOI 10.17487/RFC0791, September 1981, 564 . 566 [INT-ARCHI] 567 Braden, R., Ed., "Requirements for Internet Hosts - 568 Communication Layers", STD 3, RFC 1122, 569 DOI 10.17487/RFC1122, October 1989, 570 . 572 [IPv6-ADDRESSING] 573 Hinden, R. and S. Deering, "IP Version 6 Addressing 574 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 575 2006, . 577 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 578 (IPv6) Specification", STD 86, RFC 8200, 579 DOI 10.17487/RFC8200, July 2017, 580 . 582 13.2. Informative References 584 [NAT-DEPLOY] 585 Palet Martinez, J., "Additional Deployment Guidelines for 586 NAT64/464XLAT in Operator and Enterprise Networks", 587 RFC 8683, DOI 10.17487/RFC8683, November 2019, 588 . 590 Author's Address 591 Pascal Thubert (editor) 592 Cisco Systems, Inc 593 Building D 594 45 Allee des Ormes - BP1200 595 06254 Mougins - Sophia Antipolis 596 France 597 Phone: +33 497 23 26 34 598 Email: pthubert@cisco.com