idnits 2.17.00 (12 Aug 2021) /tmp/idnits60099/draft-thubert-v6ops-yada-yatt-03.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 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 directly say this. It does mention RFC4291 though, so this could be OK. -- The draft header indicates that this document updates RFC1122, but the abstract doesn't seem to directly say this. It does mention RFC1122 though, so this could be OK. 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 (7 April 2022) is 44 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 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) 7 April 2022 5 Intended status: Informational 6 Expires: 9 October 2022 8 Yet Another Double Address and Translation Technique 9 draft-thubert-v6ops-yada-yatt-03 11 Abstract 13 This document provides a stepwise migration between IPv4 and IPv6 14 with baby steps from an IPv4-only stack/gateway/ISP to an IPv6-only 15 version, that allows portions of the nodes and of the networks to 16 remain IPv4, and reduces the need for dual stack and CG NATs between 17 participating nodes. A first mechanism named YADA to augment the 18 capacity of the current IPv4 Internet by interconnecting IPv4 realms 19 via a common footprint called the shaft. YADA extends RFC 1122 with 20 the support of an IP-in-IP format used to forward the packet between 21 parallel IPv4 realms. This document also provides a stateless 22 address and IP header translation between YADA and IPv6 called YATT 23 and extends RFC 4291 for the YATT format. The YADA and YATT formats 24 are interchangeable, and the stateless translation can take place as 25 a bump in the stack at either end, or within the network at any 26 router. This enables an IPv6-only stack to dialog with an IPv4-only 27 stack across a network that can be IPv6, IPv4, or mixed. YATT 28 requires that the IPv6 stack owns a prefix that derives from a YADA 29 address and that the IPv4 stack in a different realm is capable of 30 YADA, so it does not replace a generic 4 to 6 translation mechanism 31 for any v6 to any v4. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 9 October 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Extending RFC 1122 . . . . . . . . . . . . . . . . . . . . . 8 72 5. Extending RFC 4291 . . . . . . . . . . . . . . . . . . . . . 8 73 6. YADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7. YATT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 8. The structure of the shaft . . . . . . . . . . . . . . . . . 15 76 9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15 77 10. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 16 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 81 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 83 14.2. Informative References . . . . . . . . . . . . . . . . . 17 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction and Motivation 88 At the time of this writing, the transition to IPv6 started 20 years 89 ago and large amounts of networks, hosts, and programs, are still 90 IPv4-only. The IPv4 and IPv6 camps are quite entrenched, and there's 91 no indication that things will change any time soon. 93 During that endless transition, stacks must implements both protocols 94 (aka dual stack) and a mechanism to use either based on the 95 responsiveness (Happy Eyeballs). Service Providers must implement 96 heavy weaponry called Carrier-Grade Network Address Translators (CG- 97 NATs) to translate between protocols between legacy IPv4-only and 98 IPv6-only stacks, and tunneling techniques such as DS-Lite and 99 464XLAT to traverse portions of the network that support only one of 100 the IP versions. This means both CAPEX to install dual stack 101 infrastructures and NAT devices and OPEX to maintain them. The 102 current situation is often qualified as the worst of both worlds and 103 any indications is that it's here to stay, till each side suffered 104 enough and is ready for a compromise. 106 This document prepares for that time where the players will 107 effectively be ready for a compromise. An acceptable compromise must 108 provide both sides with way to remain as long as desired, while 109 eliminating the need for dual stack and CG-NATs between participating 110 nodes. Certainly, an effort must be asked on each side to reduce the 111 chasm, and that effort must come with enough benefits to effectively 112 encourage a majority of interested parties to make the step. 114 Yet Another Double Address (YADA) refers to effort that is asked from 115 the IPv4 side to support a new IP-in-IP model. YADA extends 116 [INT-ARCHI] with the support of an IP-in-IP format used to forward 117 the packet between parallel IPv4 realms. The proposed benefit is a 118 thousandfold increase of the IPv4-addressable domain by building 119 parallel realms each potentially the size of the current Internet. 120 Only the stacks that need to talk to a parallel realm need to evolve. 121 Routing and forwarding can remain IPv4-only with the same operations 122 as today, though new routers with YADA capabilities must be deployed 123 to route between realms. 125 Yet Another Translation Technique (YATT) refers to an effort to be 126 made by the IPv6 side to support a new IPv6 Prefix with special 127 properties, which impacts in particular source address selection 128 (SAS). YATT extends [IPv6-ADDRESSING] for the YATT format. The 129 proposed benefit is a prefix (say /32) per realm and a prefix (say 130 /64) per host in the realm. This address space may for instance 131 become handy for load balancing between physical servers / VMs / pods 132 that operate a service associated with the virtual server that owns 133 the host prefix. 135 The YADA and YATT formats are interchangeable, which means that the 136 translation is stateless and can take place as a bump in the stack at 137 either end or can be operated at line rate anywhere in the network by 138 an upgraded hardware. The routers that connect the shaft also 139 perform a stateless operation that can be achieved at line rate by 140 upgraded hardware. This is how the chasm between IPv4 and IPv6 can 141 be reduced, removing the need to deploy dual stack and CG-NATs 142 between participating nodes. 144 This document provides a stepwise migration between IPv4 and IPv6 145 with baby steps from an IPv4-only stack/gateway/ISP to YADA to YATT 146 to an IPv6-only version. The migration strategy allows portions of 147 the nodes and of the networks to remain IPv4. This enables an 148 IPv6-only stack to dialog with an IPv4-only stack across a network 149 that can be IPv6, IPv4, or mixed. 151 YATT requires that the IPv6 stack owns a prefix that derives from a 152 YADA address associated to a realm, even if there's absolutely no 153 IPv4 operation taking place in that realm. The resulting 154 connectivity without dual stack and CG-NAT is as follows: 156 * A legacy IPv4-only node can only talk within its realm. It can 157 talk to a IPv4 legacy node, and YADA IPv4-only node and a YATT 158 IPv6-only node, e.g., leveraging a bump-in-the-stack in the YATT 159 node if the network is IPv4-only. 161 * In addition, a YADA IPv4-only node can talk across realms to a 162 YADA IPv4-only node and to any YATT IPv6-only node. 164 * In addition, a YATT IPv6-only node can talk to all the IPv6 165 addressable space to any IPv6-only node. 167 Connectivity between an IPv4-only node and an IPv6-only node, or 168 between an IPv4-only node and a YADA node in different realm, still 169 requires a CG-NATs as of today, e.g., using the YATT format for the 170 IPv6 side in an unmodified CG-NAT. 172 2. Terminology 174 2.1. Glossary 176 This document often uses the following acronyms: 178 YADA: Yet Another Double Address 179 YATT: Yet Another Translation Technique 180 NAT: Network address Translation 181 IID: Interface ID 182 CG-NAT: Carrier Grade NAT 184 2.2. New Terms 186 This document often uses the following new terms: 188 IPv4 realm: A full IPv4 network like the current Internet. YADA 189 does not affect the traditional IPv4 operations within a realm. 190 The shaft: The shaft refers to a collection of IPv4 unicast and 191 multicast prefixes that are assigned to Inter-realm communications 192 and cannot be assigned to hosts or multicast groups within a 193 realm. 194 Realm address: An IPv4 address that derives from a shaft prefix. 195 Uni-realm address: A realm address that is unicast or anycast. A 196 realm may have more than one Uni-realm add ress. 197 Multi-realm address: A realm address that is multicast and denotes a 198 collection of realms. 199 YADA realm prefix: A prefix assigned to the shaft and from which 200 realm addresses can be derived. 201 YADA NAT prefix: A prefix assigned to the YADA bump-in-the-stack NAT 202 operation. 203 Double-A or YADA address: A YADA address is a tuple (realm address, 204 IPv4 address) where the IPv4 address is only significant within 205 the realm denoted by the realm address. 206 YATT Space: An IPv6 range that is assigned for YATT operation. 207 YATT prefix: An IPv6 prefix that is derived from a YADA address by 208 appending the YATT space prefix, the (truncated) realm address and 209 the IPv4 address. 210 YATT-IID: A 64-bit assigned constant that is used in YATT to 211 statelessly form an IPv6 address from a YATT prefix. 212 Multinternet: A collection of IPv4 realms interconnected using a 213 common shaft. 215 3. Operation 217 This document provides a stepwise migration between IPv4 and IPv6 218 with baby steps from an IPv4-only stack/gateway/ISP to an IPv6-only 219 version. The baby steps reduce the gap between the only versions and 220 teh associated need for dual stack and CG-NATs. 222 The first step called YADA uses IPv4-only signaling. The second step 223 called Yet Another Translation Technique (YATT) offers an IPv6-only 224 signaling that is interchangeable with YADA, so any router or stack 225 may turn one into the other, allowing the stack or the link to be one 226 version only. A YADA-enabled IPv4 stack can thus talk to a YATT- 227 enabled IPv6 stack with neither CG-NATs nor dual stack network in 228 between, but a stack that is not aware of this specification will 229 still need a traditional NAT approach to communicate. 231 The effort in this specification is to provide enough value / 232 incentive for an IPv4-only stack/gateway/ISP to make the step towards 233 YADA, as a push towards IPv6, and for an IPv6-only stack to support 234 YATT on top to pull IPv4 space in IPv6, with a low barrier for making 235 the baby step. For IPv4, going YADA expands the size/reach of the 236 Internet, and allows multiple parties to build their own IPv4 realm, 237 with control of interconnection with other realms. For an IPv6 node, 238 supporting YATT provides connectivity to the YADA world, and 239 automatically assigns a prefix in the node. 241 This first mechanism called YADA allows to grow the Internet beyond 242 the current IPv4 [IPv4] realm that limits its capacity to form public 243 addresses. Depending on the assignments to be made, the model allows 244 to reuse all IP addresses and all Autonomous System Number (ASN) 245 currently available in the internet hundreds to millions of times. 246 This is achieved by interconnecting IPv4 realms via a common 247 footprint called the shaft. 249 In the analogy of a building, the ground floor would be the Internet, 250 and each additional floor would be another IPv4 realm. The same 251 surface of floor is available in each level, analog to the full IPv4 252 addressing that is available in each realm. The same footprint is 253 dedicated across the building levels for the elevator shaft. The 254 elevator shaft enables a third dimension that spans across the levels 255 and allows to traverse from any level to any other level. The 256 elevator shaft cannot be used for living or office space. 258 /------------------------------------------------------ 259 / / 260 / |------------| realm 1 / 261 / /. /. / 262 / / . shaft / . (current IPv4 Internet) / 263 / |------------| . / 264 / . . . . / 265 ------------------------------------------------------/ 266 | . | | 267 /-----|------------|--|-------------------------------- 268 / | . | | / 269 / | |---------|--| realm 2 / 270 / | /. | /. / 271 / |/ . shaft |/ . / 272 / |------------| . / 273 / . . . . / 274 ------------------------------------------------------/ 275 | . | | 276 | . | | 277 | | . 278 | | . 279 . . | 280 . . | 281 | . | | 282 /-----|------------|--|-------------------------------- 283 / | . | | / 284 / | |---------|--| realm N / 285 / | / | / / 286 / |/ shaft |/ / 287 / |------------| / 288 / / 289 ------------------------------------------------------/ 291 Figure 1: The shaft 293 By analogy, YADA assigns IPv4 prefixes to a multinternet shaft; those 294 prefixes are common across the realms that are interconnected by the 295 shaft. A single /24 IPv4 prefix assigned allows for > 250 times the 296 capacity of the Internet as we know it at the time of this writing. 297 Multiple prefixes can be assigned to the shaft for unicast and 298 multicast communications, and each realm needs at least one unicast 299 address in the shaft called its realm address. A YADA address is 300 formed by the tuple (realm address, IPv4 address) and is advertised 301 in DNS as a new double-A record. 303 YADA leverages IP-in-IP encapsulation to tunnel packets across the 304 shaft while normal IPv4 operations happen within a realm. YADA 305 requires a change in the stack in the YADA endpoints that communicate 306 with other realms to support the IP-in-IP YADA encapsulation. YADA 307 also provides a bump in the stack method for legacy applications. 308 More in Section 6. 310 A second mechanism called YATT translates the YADA format into flat 311 IPv6 [IPv6]. While a YADA address pair can be seen as some foot 312 print in one level, the YATT prefix encompasses that same foot print 313 plus all the air above it. For unicast addresses, YATT forms an IPv6 314 prefix by collating an well-known assigned short prefix, the realm 315 address (in the shaft), and the host IPv4 address (locally 316 significant within the realm). The resulting IPv6 prefix is 317 automatically owned by the host that owns the IPv4 address in the 318 realm. YATT then forms an IPv6 address for that host by collating a 319 well-known Interface ID, so there's a one-to-one relationship between 320 the YADA and the IPv6 address derived from it. More in Section 7. 322 A key concept for this specification is that YADA (the IPv4 323 formulation) and YATT (the IPv6 formulation) represent the same 324 thing. YADA uses IPv4 formats as plain IP-in-IP with no new 325 extension. YATT uses IPv6 format with the IPv4 addresses encoded on 326 the prefix. The formats are interchangeable, and a router can 327 convert one to another as the packet flows over a next-hop link that 328 can only carry the other address family. 330 4. Extending RFC 1122 332 YADA extends [INT-ARCHI] to add the capability for an IPv4 host to 333 recognize an special IP-in-IP format as an inter-realm IPv4 packet 334 and process it accordingly. It also adds a new DNS double-A record 335 format that denotes a YADA address. 337 5. Extending RFC 4291 339 YATT extends [IPv6-ADDRESSING] to add the capability for an IPv4 host 340 to recognize an special IPv6 format as an YATT address embedding a 341 YADA address and process it accordingly. It also automatically 342 derives the ownership of the YATT prefix associated to a owned YADA 343 address. 345 6. YADA 347 YADA assigns IPv4 prefixes to a multinternet shaft; those prefixes 348 must be the same across all the realms that are interconnected by the 349 shaft. Multiple prefixes can be assigned to the shaft for unicast 350 and multicast communications, and each realm needs at least one 351 unicast address in the shaft called its realm address. A YADA 352 address is formed by the tuple (realm address, IPv4 address) and is 353 advertised in DNS as a new double-A record. Because the YADA 354 prefixes are assigned for YADA, a packet that has either source or 355 destination IPV4 address derived from a shaft prefix is a YADA 356 packet. 358 YADA leverages IP-in-IP encapsulation to tunnel packets across the 359 shaft for inter-realm communications, while the IPv4 operations 360 within a realm are unaffected. The YADA address is found by using 361 both inner and outer header and combining that information. The pair 362 of IP headers is seen by a YADA stack as a single larger header 363 though a non-YADA forwarder only needs the outer header and plain 364 IPv4 operations on the outer IPv4 header to forward. 366 YADA requires a change in the stack in the YADA endpoints that 367 communicate with other realms to support the YADA encapsulation. 368 YADA also provides a bump in the stack method for legacy 369 applications. A stack that resolve a DNS name with a double-A record 370 indicating a different realm generates an IP-in-IP packet to signal 371 both the source and destination realms and the source and destination 372 IPv4 addresses within the respective realms. 374 Inside the source realm, the outer IPv4 header indicates the node's 375 IPv4 address as source, to remain topologically correct, and the 376 local realm address as source in the inner header, as shown in 377 Figure 2 379 <----------------------------- 20 bytes ----------------------------> 380 +------------ ... ------------+-----------------+-------------------+ 381 | IPv4 header fields | Source node | destination realm | 382 | (outer) | IPv4 Address | IPv4 Address | 383 +------------ ... ------------+-----------------+-------------------+ 384 | IPv4 header fields | Source realm | destination node | 385 | (inner) | IPv4 Address | IPv4 Address | 386 +------------ ... ------------+-----------------+-------------------+ 387 . Options . 388 +------------ ... --------------------------------------------------+ 389 | | 390 . Data . 391 | | 392 +-------------------------------------------------------------------+ 394 Figure 2: YADA format in the source realm 396 YADA also requires a change for the routers that serve the shaft. 397 Those routers play a special role for packets that are delivered from 398 the shaft to the destination realm, and for ICMP errors across 399 realms. All other IPv4 nodes in the realm continue to operate 400 routing and forwarding as before. 402 Routers serving the shaft advertise the shaft prefix(es) in their 403 respective realms, and their realm addresses within the shaft, as 404 host routes for unicast and anycast addresses. 406 Inside the source realm, the IPv4 destination in the outer header is 407 an address is the shaft and it is attracted by a router that serves 408 the shaft in the source realm. The packet source in the outer header 409 is the address of the source node in the local realm, so the packet 410 does not defeat BCP 38 rules in the ISP network, as shown in 411 Figure 3. 413 | | 414 /------|------------|--------------------------------- 415 / | | / 416 / | | | | / 417 / | |--------|---| Source Node / 418 / | / | / / 419 / | /. <--|---- outer(src=src-addr / 420 / |/ . |/ . dst=dst-realm) / 421 / |------------| . inner(src=src-realm / 422 / . . . . dst=dst-addr) / 423 / . . . . / 424 / . . . . / 425 -----------------------------------------------------/ 426 | | | 427 | | 428 | | 430 Figure 3: Packets Entering the shaft 432 When the packet reaches the shaft, the router that serves the shaft 433 swaps the inner and outer source IPv4 address, so the packet remains 434 topologically correct inside the shaft, as shown in Figure 4. 436 <----------------------------- 20 bytes ----------------------------> 437 +------------ ... ------------+-----------------+-------------------+ 438 | IPv4 header fields | Source realm | destination realm | 439 | (outer) | IPv4 Address | IPv4 Address | 440 +------------ ... ------------+-----------------+-------------------+ 441 | IPv4 header fields | Source node | destination node | 442 | (inner) | IPv4 Address | IPv4 Address | 443 +------------ ... ------------+-----------------+-------------------+ 444 . Options . 445 +------------ ... --------------------------------------------------+ 446 | | 447 . Data . 448 | | 449 +-------------------------------------------------------------------+ 451 Figure 4: YADA format inside the shaft 453 Based on longest match, the router forwards the packet inside the 454 shaft following the host route to a router that serves the 455 destination realm, as shown in Figure 5. 457 | | 458 /------|------------|--------------------------------- 459 / | | / 460 / | | | | / 461 / | |--------|---| Source Node / 462 / | / | / / 463 / | /. + | / outer(src=src-realm / 464 / |/ . | |/ . dst=dst-realm) / 465 / |------------| . inner(src=src-addr / 466 / . . | . . dst=dst-addr) / 467 / . . | . . / 468 / . . | . . / 469 -----------------------------------------------------/ 470 | | | | 471 | | | forwarded unchanged 472 | | | down the shaft 473 v 475 Figure 5: Packets Entering the shaft 477 That router swaps the destination address in the inner and outer 478 headers and forwards within its realm to the final destination, as 479 shown in Figure 6. 481 <----------------------------- 20 bytes ----------------------------> 482 +------------ ... ------------+-----------------+-------------------+ 483 | IPv4 header fields | Source realm | destination node | 484 | (outer) | IPv4 Address | IPv4 Address | 485 +------------ ... ------------+-----------------+-------------------+ 486 | IPv4 header fields | Source node | destination realm | 487 | (inner) | IPv4 Address | IPv4 Address | 488 +------------ ... ------------+-----------------+-------------------+ 489 . Options . 490 +------------ ... --------------------------------------------------+ 491 | | 492 . Data . 493 | | 494 +-------------------------------------------------------------------+ 496 Figure 6: YADA format in the destination realm 498 In normal conditions, the stack of the destination node recognizes 499 the YADA format and replies accordingly. 501 | 502 | | | 503 | | | 504 /------|----|-------|--------------------------------- 505 / | | | | | / 506 / | | | | | / 507 / | |----|---|---| Destination Node / 508 / | / | | / / 509 / | /. +---|----> outer(src=src-realm / 510 / |/ . |/ . dst=dst-addr) / 511 / |------------| . inner(src=src-addr / 512 / . . . . dst=realm-addr) / 513 / . . . . / 514 / . . . . / 515 -----------------------------------------------------/ 517 destinations swapped at shaft egress 519 Figure 7: Packets Outgoing the shaft 521 In case of an error down the shaft or in the destination realm, if an 522 ICMP message is generated by a node that is not YADA-aware, the 523 message reaches the router that serves the shaft in the source realm. 524 If the inner header is present in the ICMP payload, then the Router 525 extracts it and forwards to the packet source. If the destination 526 stack does not support YADA and decapsulates, the message reaches the 527 router that serves the destination realm which logs and drops. based 528 on the log, the node may be updated, or the DNS records may be fixed 529 to avoid pointing on a node that does not support YADA. 531 YADA requires the assignment of a second IPv4 prefix, this time for a 532 internal NATing operation. A bump-in-the-stack intercepts the DNS 533 lookups, and when the response yields a double-A record with a 534 foreign realm, the record is augmented with an IPv4 address taken 535 from a local NAT pool. When the stack sends a packet to that 536 particular address, the bump-in-the-stack translates to the YADA 537 format, using the information in the double-A record for the 538 destination, and the local realm as source realm. The other way 539 around, if a packet arrives with a YADA format but the stack does not 540 support it, the bump-in-the-stack allocates an address from the pool, 541 and NATs to IPv4 using that address as source. 543 YADA was initially published as USPTO 7,356,031, filed in February 544 2002. 546 7. YATT 548 A second mechanism called YATT translates the YADA format into flat 549 IPv6. 551 +-----+---------------+--------------+-----------------------------+ 552 |YATT | Realm | IPv4 | Well-Known | 553 |Space| Address | Address | IID | 554 +-----+- -------------+--------------+-----------------------------+ 555 <- YADA 556 prefix -> 557 <-------- YATT prefix ----------> 559 Figure 8: YATT format 561 For unicast addresses, YATT forms an IPv6 prefix by collating an 562 well-known assigned short prefix called the YATT space, the realm 563 address, and the host IPv4 address (locally significant within the 564 realm). The resulting IPv6 prefix is automatically owned by the host 565 that owns the IPv4 address in the realm. 567 Depending on assignment, the leftmost piece realm prefix may be 568 truncated if it is well-known, to allow the YATT space and the realm 569 address to fit in a 32-bit DWORD. This way, the YATT prefix can be a 570 full /64 prefix that is entirely owned by the host that owns the 571 associated YADA address. 573 YATT then forms an IPv6 address for that host by collating a well- 574 known Interface ID, so there's a one-to-one relationship. 576 The formats can not be strictly provided till the YATT space and YADA 577 prefix are assigned. But say that the YATT Space is F000::/6 and the 578 YADA prefix is 240.0.0.0/6. In that case the values perfectly 579 overlap and the YATT format becomes as follows: 581 +-----+----------+----------------+---------------------------------+ 582 | Realm Address | IPv4 Host | Well-Known | 583 | in 240.0.0.0/6 | Public Address | IID | 584 +-----+- --------+----+-----------+---------------------------------+ 585 <--- 32 bits ---><--- 32 bits ---><------------ 64 bits ------------> 586 <------ YATT IPv6 prefix -------> 588 Figure 9: YATT format using 240.0.0.0/6 590 In that case, the NAT operation is a plain insertion. Depending on 591 the assignment, it might be that the Realm address must be placed in 592 full after YATT space. In that case, the length of the YATT prefix 593 will be more than 64 bits. 595 Also, since 240.0.0.0/6 is currently unassigned, using it for the 596 shaft would allow literally to reuse every ASN and every IPv4 address 597 currently available in the Internet in each and every other realm and 598 reallocate them in any fashion desirable in that realm. 600 If the network supports IPv6 to the shaft, it makes sense for the 601 YADA host or the bump-in-the-stack to generate the packets in the 602 YATT form natively. The shaft router must then attract the shaft 603 YADA realm prefix in both IPv4 and YATT forms. 605 If the network is IPv4 only, the packets are still generated using 606 IP-in-IP, and the YATT NAT operation may happen at the router that 607 delivers the packet in the destination realm, if it is v6-only, or in 608 the destination host, if its stack is v6-only. 610 YATT was initially published as USPTO 7,764,686, filed in December 611 2002. 613 8. The structure of the shaft 615 A 10 miles view of the shaft could be as follows: it is implemented 616 in one IXP, spans all realms, and each realm has one address in the 617 shaft, with one router serving that realm. The address of the realm 618 is encoded in a loopback in the router, and advertised through an IGP 619 inside the shaft, while BGP is used inside the realms but not inside 620 the shaft. The shaft has a single large prefix that is advertised in 621 each realm by the router that serves the shaft, and that is 622 disaggregated into host routes inside the shaft. 624 None of the above is expected to remain true for long. As YADA and 625 YATT get deployed, the shaft will be implemented in different sites 626 over the world. A realm may be multihomed to be reached from a 627 different physical instance of the shaft, meaning that the shaft is 628 composed of either more prefixes or the shaft prefix is 629 disaggregated. Multiple routers will serve the same realm with high 630 availability and load balancing taking place inside the shaft to 631 maintain connectivity. Some shafts may be deployed to interconnect 632 only a subset of the realms, in which case those shafts would share a 633 specific prefix that would not be advertised outside the concerned 634 realms. 636 9. Applicability 638 YADA And YATT enable communication between YADA-enabled IPv4 nodes 639 across realms, and with IPv6 nodes that own a YADA address from which 640 a YATT address can be derived. Communication from a legacy IPv4 641 application/stack that is not YADA-enabled, or to an IPv6 address 642 that is not a YATT address, is not provided. 644 Since the YATT translation is stateless, the header translation can 645 happen anywhere in the network, e.g., as a bump in the stack at 646 either end, or within the network, e.g., at the routers that serve 647 the realms on the shaft. The shaft itself is expected to be dual 648 stack to forward packets in their native form, either v4 or v6. 650 For a legacy IPv4 node to communicate with YADA-enabled IPv4 node in 651 another realm, a NAT operation similar to NAT46 [NAT-DEPLOY], but 652 between IPv4 and YADA addresses, is required. The same would be 653 required to allow an IPv4-only YADA node to communicate with an IPv6 654 node a a non-YATT address. 656 In summary: 658 * this specification does not allow any IPv4 legacy node to talk to 659 any pure IPv6 node, and recognizes that this Graal may actually be 660 a non-goal. 662 * With YADA the current IPv4 Internet operations are not affected 664 * YADA extends the IPv4-reachable world by creating (millions of) 665 parallel realms and changing (only) the stack on the hosts that 666 require inter-realm communication and specific routers at the 667 ingress of the realms 669 * A YADA node can talk (using IPv4) to a YATT node (using IPv6) with 670 a stateless translation. The translation can happen anywhere in 671 the network or in the stack. 673 * a YATT node being an IPv6 can talk to any other IPv6 nodes. 675 10. Backwards Compatibility 677 YADA operation does not affect the intra-realm communication. The 678 only affected stacks are the endpoints that communicate between 679 realms leveraging YADA. 681 11. Security Considerations 683 YADA introduces an IP-in-IP format that might be used to obfuscate an 684 IP address impersonation performed in the inner header. A proper 685 implemetation of BCP 38 should thus include the capability to 686 recognize a YADA format and look in the source IP field that 687 expresses the source realm in the inner header. 689 Upgrading the rules in his Broadband Network Gateways (BNGs) 690 represents additional work for an ISP, which should be done before 691 the shaft addresses are routable within the ISP network, and whether 692 the ISP intends to provide improved NAT functions in the home 693 gateways and CPEs. 695 12. IANA Considerations 697 This document requires the creation of a registry for IPv4 YADA realm 698 prefixes, and the assignment of at least one YADA realm prefix. 700 This document requires the creation of a registry for IPv4 YADA NAT 701 prefixes, and the assignment of at least one YADA NAT prefix. 703 This document requires the creation of a new record in the Resource 704 Record (RR) TYPEs subregistry of the Domain Name System (DNS) 705 Parameters. The new record would be of type AA meaning a YADA 706 address. 708 13. Acknowledgments 710 The author wishes to recognize the pioneer work done by Brian 711 carpenter in the space of IPv4 augmentation with 712 [I-D.carpenter-aeiou] 714 The author wishes to thank Greg Skinner as the first reviewer/ 715 contributor to this work. Also Dave Bell, to remind that even if 716 routing is not touched much inside an IPv4 realm vs. the current art, 717 there is still work for the ISP, e.g., update the BCP 38 rules in the 718 BNGs. 720 14. References 722 14.1. Normative References 724 [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, 725 DOI 10.17487/RFC0791, September 1981, 726 . 728 [INT-ARCHI] 729 Braden, R., Ed., "Requirements for Internet Hosts - 730 Communication Layers", STD 3, RFC 1122, 731 DOI 10.17487/RFC1122, October 1989, 732 . 734 [IPv6-ADDRESSING] 735 Hinden, R. and S. Deering, "IP Version 6 Addressing 736 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 737 2006, . 739 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 740 (IPv6) Specification", STD 86, RFC 8200, 741 DOI 10.17487/RFC8200, July 2017, 742 . 744 14.2. Informative References 746 [NAT-DEPLOY] 747 Palet Martinez, J., "Additional Deployment Guidelines for 748 NAT64/464XLAT in Operator and Enterprise Networks", 749 RFC 8683, DOI 10.17487/RFC8683, November 2019, 750 . 752 [I-D.carpenter-aeiou] 753 Carpenter, B. E., "Address Extension by IP Option Usage 754 (AEIOU)", Work in Progress, Internet-Draft, draft- 755 carpenter-aeiou-00, 21 March 1994, 756 . 759 Author's Address 761 Pascal Thubert (editor) 762 Cisco Systems, Inc 763 Building D 764 45 Allee des Ormes - BP1200 765 06254 Mougins - Sophia Antipolis 766 France 767 Phone: +33 497 23 26 34 768 Email: pthubert@cisco.com