idnits 2.17.1 draft-thubert-v6ops-yada-yatt-04.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 850: '...in the shaft, it MUST ensure that the ...' RFC 2119 keyword, line 851: '...matches this realm. Otherwise it MUST...' RFC 2119 keyword, line 852: '...p the packet and MAY generate and ICMP...' -- 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: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1122, updated by this document, for RFC5378 checks: 1989-10-01) -- 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 (11 April 2022) is 746 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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) 11 April 2022 5 Intended status: Informational 6 Expires: 13 October 2022 8 Yet Another Double Address and Translation Technique 9 draft-thubert-v6ops-yada-yatt-04 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 13 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Extending RFC 1122 . . . . . . . . . . . . . . . . . . . . . 7 72 5. Extending RFC 2131 . . . . . . . . . . . . . . . . . . . . . 8 73 6. Extending RFC 4291 . . . . . . . . . . . . . . . . . . . . . 8 74 7. Extending RFC 8415 . . . . . . . . . . . . . . . . . . . . . 8 75 8. YADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 9. YADA Stateful NAT . . . . . . . . . . . . . . . . . . . . . . 12 77 10. YATT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 11. YATT Stateful PAT . . . . . . . . . . . . . . . . . . . . . . 16 79 12. The structure of the shaft . . . . . . . . . . . . . . . . . 17 80 13. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 18 81 14. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 19 82 15. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 85 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 18.1. Normative References . . . . . . . . . . . . . . . . . . 20 87 18.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction and Motivation 92 At the time of this writing, the transition to IPv6 started 20 years 93 ago and large amounts of networks, hosts, and programs, are still 94 IPv4-only. The IPv4 and IPv6 camps are quite entrenched, and there's 95 no indication that things will change any time soon. 97 During that endless transition, stacks must implement both protocols 98 (aka dual stack) and a mechanism to use either based on the 99 responsiveness (Happy Eyeballs). Service Providers must implement 100 heavy weaponry called Carrier-Grade Network Address Translators (CG- 101 NATs) to translate between protocols between legacy IPv4-only and 102 IPv6-only stacks, and tunneling techniques such as DS-Lite [RFC7333] 103 and 464XLAT [RFC6877] to traverse portions of the network that 104 support only one of the IP versions. This means both CAPEX to 105 install dual stack infrastructures and NAT devices and OPEX to 106 maintain them. The current situation is often qualified as the worst 107 of both worlds and any indications is that it's here to stay, till 108 each side suffered enough and is ready for a compromise. 110 This document prepares for that time where the players will 111 effectively be ready for a compromise. An acceptable compromise must 112 provide both sides with way to remain as long as desired, while 113 eliminating the need for dual stack and CG-NATs between participating 114 nodes. Certainly, an effort must be asked on each side to reduce the 115 chasm, and that effort must come with enough benefits to effectively 116 encourage a majority of interested parties to make the step. 118 Yet Another Double Address (YADA) refers to effort that is asked from 119 the IPv4 side to support a new IP-in-IP model. YADA extends 120 [INT-ARCHI] with the support of an IP-in-IP format used to forward 121 the packet between parallel IPv4 realms. The proposed benefit is a 122 thousandfold increase of the IPv4-addressable domain by building 123 parallel realms each potentially the size of the current Internet. 124 Only the stacks that need to talk to a parallel realm need to evolve. 125 Routing and forwarding can remain IPv4-only with the same operations 126 as today, though new routers with YADA capabilities must be deployed 127 to route between realms. 129 Yet Another Translation Technique (YATT) refers to an effort to be 130 made by the IPv6 side to support a new IPv6 Prefix with special 131 properties, which impacts in particular source address selection 132 (SAS). YATT extends [IPv6-ADDRESSING] for the YATT format. The 133 proposed benefit is a prefix (say /32) per realm and a prefix (say 134 /64) per host in the realm. This address space may for instance 135 become handy for load balancing between physical servers / VMs / pods 136 that operate a service associated with the virtual server that owns 137 the host prefix. 139 The YADA and YATT formats are interchangeable, which means that the 140 translation is stateless and can take place as a bump-in-the-stack at 141 either end or can be operated at line rate anywhere in the network by 142 an upgraded hardware. The routers that connect the shaft also 143 perform a stateless operation that can be achieved at line rate by 144 upgraded hardware. This is how the chasm between IPv4 and IPv6 can 145 be reduced, removing the need to deploy dual stack and CG-NATs 146 between participating nodes. 148 This document provides a stepwise migration between IPv4 and IPv6 149 with baby steps from an IPv4-only stack/gateway/ISP to YADA to YATT 150 to an IPv6-only version. The migration strategy allows portions of 151 the nodes and of the networks to remain IPv4. 153 YATT requires that the IPv6 stack owns a prefix that derives from a 154 YADA address associated to a realm, even if there's absolutely no 155 IPv4 operation taking place in that realm. The resulting 156 connectivity without dual stack and CG-NAT is as follows: 158 * A legacy IPv4-only node can only talk within its realm. It can 159 talk to an IPv4 legacy node, a YADA IPv4-only node, and even a 160 YATT IPv6-only node, e.g., leveraging a bump-in-the-stack in the 161 YATT node if the access network is IPv4-only. 163 * In addition, a YADA IPv4-only node can talk across realms to a 164 YADA IPv4-only node and to any YATT IPv6-only node, e.g., 165 leveraging a bump-in-the-stack in the YADA node if the network is 166 IPv6-only. 168 * In addition, a YATT IPv6-only node can talk to any other IPv6-only 169 node. 171 Connectivity between an IPv4-only node and an IPv6-only node, or 172 between an IPv4-only node and a YADA node in different realm, still 173 requires a CG-NATs as of today, e.g., using the YATT format for the 174 IPv6 side in an unmodified CG-NAT. 176 2. Terminology 178 2.1. Glossary 180 This document often uses the following acronyms: 182 YADA: Yet Another Double Address 183 YATT: Yet Another Translation Technique 184 NAT: Network address Translation 185 IID: Interface ID 186 CG-NAT: Carrier Grade NAT 188 2.2. New Terms 190 This document often uses the following new terms: 192 IPv4 realm: A full IPv4 network like the current Internet. YADA 193 does not affect the traditional IPv4 operations within a realm. 194 The shaft: The shaft refers to a collection of IPv4 unicast and 195 multicast prefixes that are assigned to Inter-realm communications 196 and cannot be assigned to hosts or multicast groups within a 197 realm. 198 Realm address: An IPv4 address that derives from a shaft prefix. 199 Uni-realm address: A realm address that is unicast or anycast. A 200 realm may have more than one Uni-realm add ress. 201 Multi-realm address: A realm address that is multicast and denotes a 202 collection of realms. 203 YADA realm prefix: A prefix assigned to the shaft and from which 204 realm addresses can be derived. 205 YADA NAT prefix: A prefix assigned to the YADA bump-in-the-stack NAT 206 operation. 207 Double-A or YADA address: A YADA address is a tuple (realm address, 208 IPv4 address) where the IPv4 address is only significant within 209 the realm denoted by the realm address. 210 YATT Space: An IPv6 range that is assigned for YATT operation. 211 YATT prefix: An IPv6 prefix that is derived from a YADA address by 212 appending the YATT space prefix, the (truncated) realm address and 213 the IPv4 address. 214 YATT-IID: A 64-bit assigned constant that is used in YATT to 215 statelessly form an IPv6 address from a YATT prefix. 216 Multinternet: A collection of IPv4 realms interconnected using a 217 common shaft. 219 3. Overview 221 This document provides a stepwise migration between IPv4 and IPv6 222 with baby steps from an IPv4-only stack/gateway/ISP to an IPv6-only 223 version. The baby steps reduce the gap between the only versions and 224 the associated need for dual stack and CG-NATs. 226 This first mechanism called YADA allows to grow the Internet beyond 227 the current IPv4 [IPv4] realm that limits its capacity to form public 228 addresses. Depending on the assignments to be made, the model allows 229 to reuse all IP addresses and all Autonomous System Number (ASN) 230 currently available in the internet hundreds to millions of times. 231 This is achieved by interconnecting IPv4 realms via a common 232 footprint called the shaft. 234 In the analogy of a building, the ground floor would be the Internet, 235 and each additional floor would be another IPv4 realm. The same 236 surface of floor is available in each level, analog to the full IPv4 237 addressing that is available in each realm. The same footprint is 238 dedicated across the building levels for the elevator shaft. The 239 elevator shaft enables a third dimension that spans across the levels 240 and allows to traverse from any level to any other level. The 241 elevator shaft cannot be used for living or office space. 243 /------------------------------------------------------ 244 / / 245 / |------------| realm 1 / 246 / /. /. / 247 / / . shaft / . (current IPv4 Internet) / 248 / |------------| . / 249 / . . . . / 250 ------------------------------------------------------/ 251 | . | | 252 /-----|------------|--|-------------------------------- 253 / | . | | / 254 / | |---------|--| realm 2 / 255 / | /. | /. / 256 / |/ . shaft |/ . / 257 / |------------| . / 258 / . . . . / 259 ------------------------------------------------------/ 260 | . | | 261 | . | | 262 | | . 263 | | . 264 . . | 265 . . | 266 | . | | 267 /-----|------------|--|-------------------------------- 268 / | . | | / 269 / | |---------|--| realm N / 270 / | / | / / 271 / |/ shaft |/ / 272 / |------------| / 273 / / 274 ------------------------------------------------------/ 276 Figure 1: The shaft 278 By analogy, YADA assigns IPv4 prefixes to a multinternet shaft; those 279 prefixes are common across the realms that are interconnected by the 280 shaft. A single /24 IPv4 prefix assigned allows for > 250 times the 281 capacity of the Internet as we know it at the time of this writing. 283 Multiple prefixes can be assigned to the shaft for unicast and 284 multicast communications, and each realm needs at least one unicast 285 address in the shaft called its realm address. A YADA address is 286 formed by the tuple (realm address, IPv4 address) and is advertised 287 in DNS as a new double-A record. 289 YADA leverages IP-in-IP encapsulation to tunnel packets across the 290 shaft while normal IPv4 operations happen within a realm. YADA 291 requires a change in the stack in the YADA endpoints that communicate 292 with other realms to support the IP-in-IP YADA encapsulation. YADA 293 also provides a bump in the stack method for legacy applications. 294 More in Section 9. 296 A second mechanism called YATT translates the YADA format into flat 297 IPv6 [IPv6]. While a YADA address pair can be seen as some foot 298 print in one level, the YATT prefix encompasses that same foot print 299 plus all the air above it. For unicast addresses, YATT forms an IPv6 300 prefix by collating an well-known assigned short prefix, the realm 301 address (in the shaft), and the host IPv4 address (locally 302 significant within the realm). The resulting IPv6 prefix is 303 automatically owned by the host that owns the IPv4 address in the 304 realm. YATT then forms an IPv6 address for that host by collating a 305 well-known Interface ID, so there's a one-to-one relationship between 306 the YADA and the IPv6 address derived from it. More in Section 10. 308 A key concept for this specification is that YADA (the IPv4 309 formulation) and YATT (the IPv6 formulation) are alternative 310 representations of the same abstract object (a double address), which 311 can serve as an intermediate step across the IPv4-IPv6 chasm. The 312 IPv4 formulation (YADA) is a plain IP-in-IP with no new extension. 313 The IPv6 formulation (YATT) uses a standard IPv6 header with a 314 special encoding of the addresses. The formulations are 315 interchangeable; if a link supports both IP versions then the next 316 hop is valid for both formulations, whichever of the 2 Address 317 Families (AFs) was used to learn it; else any node can convert one 318 formulation to the other to accomodate the IP version that is 319 available on the next hop link. 321 4. Extending RFC 1122 323 YADA extends [INT-ARCHI] to add the capability for an IPv4 host to 324 recognize an special IP-in-IP format as an inter-realm IPv4 packet 325 and process it accordingly. It also adds a new DNS double-A record 326 format that denotes a YADA address. 328 5. Extending RFC 2131 330 The Dynamic Host Configuration Protocol [RFC2131] (DHCP) is extended 331 to pass information to the host about its current realm. When this 332 information is present, the host is free to use YADA using that 333 realms as source realm. 335 If a host obtains a public address from DHCP, and for the duration of 336 the lease, the host automatically owns the YATT prefix associated to 337 a owned YADA address. In this manner, DHCPv4 becomes an alternate 338 method for delegating an IPv6 prefix from which the host may 339 provision an IPv6 stack. 341 6. Extending RFC 4291 343 YATT extends the IPv6 Addressing Architecture [IPv6-ADDRESSING] to 344 add the capability for a host to recognize an special IPv6 format as 345 an YATT address embedding a YADA address and process it accordingly. 346 This is achieved in particular by the allocation of a YATT space that 347 is a short prefix for all YATT prefixes, and a YATT-IID. 349 7. Extending RFC 8415 351 The DHCPv6 prefix delegation mechanism in Dynamic Host Configuration 352 Protocol for IPv6 [RFC8415] is extended to delegate YATT prefixes to 353 the hosts by enforcing that a delegated YATT prefix is provided in 354 the form defined by Section 6. 356 8. YADA 358 YADA assigns IPv4 prefixes to a multinternet shaft; those prefixes 359 must be the same across all the realms that are interconnected by the 360 shaft. Multiple prefixes can be assigned to the shaft for unicast 361 and multicast communications, and each realm needs at least one 362 unicast address in the shaft called its realm address. A YADA 363 address is formed by the tuple (realm address, IPv4 address) and is 364 advertised in DNS as a new double-A record. Because the YADA 365 prefixes are assigned for YADA, a packet that has either source or 366 destination IPV4 address derived from a shaft prefix is a YADA 367 packet. 369 YADA leverages IP-in-IP encapsulation to tunnel packets across the 370 shaft for inter-realm communications, while the IPv4 operations 371 within a realm are unaffected. The YADA address is found by using 372 both inner and outer header and combining that information. The pair 373 of IP headers is seen by a YADA stack as a single larger header 374 though a non-YADA forwarder only needs the outer header and plain 375 IPv4 operations on the outer IPv4 header to forward. 377 YADA requires a change in the stack in the YADA endpoints that 378 communicate with other realms to support the YADA encapsulation. A 379 stack that resolve a DNS name with a double-A record indicating a 380 different realm generates an IP-in-IP packet to signal both the 381 source and destination realms and the source and destination IPv4 382 addresses within the respective realms. 384 Inside the source realm, the outer IPv4 header indicates the node's 385 IPv4 address as source, to remain topologically correct, and the 386 local realm address as source in the inner header, as shown in 387 Figure 2 389 <----------------------------- 20 bytes ----------------------------> 390 +------------ ... ------------+-----------------+-------------------+ 391 | IPv4 header fields | Source node | destination realm | 392 | (outer) | IPv4 Address | IPv4 Address | 393 +------------ ... ------------+-----------------+-------------------+ 394 | IPv4 header fields | Source realm | destination node | 395 | (inner) | IPv4 Address | IPv4 Address | 396 +------------ ... ------------+-----------------+-------------------+ 397 . Options . 398 +------------ ... --------------------------------------------------+ 399 | | 400 . Data . 401 | | 402 +-------------------------------------------------------------------+ 404 Figure 2: YADA format in the source realm 406 YADA also requires a change for the routers that serve the shaft. 407 Those routers play a special role for packets that are delivered from 408 the shaft to the destination realm, and for ICMP errors across 409 realms. All other IPv4 nodes in the realm continue to operate 410 routing and forwarding as before. 412 Routers serving the shaft advertise the shaft prefix(es) in their 413 respective realms, and their realm addresses within the shaft, as 414 host routes for unicast and anycast addresses. 416 Inside the source realm, the IPv4 destination in the outer header is 417 an address is the shaft and it is attracted by a router that serves 418 the shaft in the source realm. The packet source in the outer header 419 is the address of the source node in the local realm, so the packet 420 does not defeat BCP 38 rules in the ISP network, as shown in 421 Figure 3. 423 | | 424 /------|------------|--------------------------------- 425 / | | / 426 / | | | | / 427 / | |--------|---| Source Node / 428 / | / | / / 429 / | /. <--|---- outer(src=src-addr / 430 / |/ . |/ . dst=dst-realm) / 431 / |------------| . inner(src=src-realm / 432 / . . . . dst=dst-addr) / 433 / . . . . / 434 / . . . . / 435 -----------------------------------------------------/ 436 | | | 437 | | 438 | | 440 Figure 3: Packets Entering the shaft 442 When the packet reaches the shaft, the router that serves the shaft 443 in this realm checks that packet source in the inner header is an 444 address of this realm, and if so, it swaps the inner and outer source 445 IPv4 address, and forwards the packet down the shaft. this way, the 446 the packet remains topologically correct inside the shaft, as shown 447 in Figure 4. 449 <----------------------------- 20 bytes ----------------------------> 450 +------------ ... ------------+-----------------+-------------------+ 451 | IPv4 header fields | Source realm | destination realm | 452 | (outer) | IPv4 Address | IPv4 Address | 453 +------------ ... ------------+-----------------+-------------------+ 454 | IPv4 header fields | Source node | destination node | 455 | (inner) | IPv4 Address | IPv4 Address | 456 +------------ ... ------------+-----------------+-------------------+ 457 . Options . 458 +------------ ... --------------------------------------------------+ 459 | | 460 . Data . 461 | | 462 +-------------------------------------------------------------------+ 464 Figure 4: YADA format inside the shaft 466 Based on longest match, the router forwards the packet inside the 467 shaft following the host route to a router that serves the 468 destination realm, as shown in Figure 5. 470 | | 471 /------|------------|--------------------------------- 472 / | | / 473 / | | | | / 474 / | |--------|---| Source Node / 475 / | / | /. / 476 / | /. +- | / . outer(src=src-realm / 477 / |/ . | |/ . dst=dst-realm) / 478 / |------------| . inner(src=src-addr / 479 / . . | . . dst=dst-addr) / 480 / . . | . . / 481 / . . | . . / 482 -----------------------------------------------------/ 483 | | | | 484 | | | 485 | | | Sources swapped at shaft ingress 486 v 488 Figure 5: Packets Entering the shaft 490 That router swaps the destination address in the inner and outer 491 headers and forwards within its realm to the final destination, as 492 shown in Figure 6. 494 <----------------------------- 20 bytes ----------------------------> 495 +------------ ... ------------+-----------------+-------------------+ 496 | IPv4 header fields | Source realm | destination node | 497 | (outer) | IPv4 Address | IPv4 Address | 498 +------------ ... ------------+-----------------+-------------------+ 499 | IPv4 header fields | Source node | destination realm | 500 | (inner) | IPv4 Address | IPv4 Address | 501 +------------ ... ------------+-----------------+-------------------+ 502 . Options . 503 +------------ ... --------------------------------------------------+ 504 | | 505 . Data . 506 | | 507 +-------------------------------------------------------------------+ 509 Figure 6: YADA format in the destination realm 511 In normal conditions, the stack of the destination node recognizes 512 the YADA format and replies accordingly. 514 | | 515 | | 516 /------|------------|--------------------------------- 517 / | | | | / 518 / | | | | | / 519 / | |----|---|---| Destination Node / 520 / | / | | /. / 521 / | /. +---|----> outer(src=src-realm / 522 / |/ . |/ . dst=dst-addr) / 523 / |------------| . inner(src=src-addr / 524 / . . . . dst=realm-addr) / 525 / . . . . / 526 / . . . . / 527 -----------------------------------------------------/ 529 destinations swapped at shaft egress 531 Figure 7: Packets Outgoing the shaft 533 In case of an error down the shaft or in the destination realm, if an 534 ICMP message is generated by a node that is not YADA-aware, the 535 message reaches the router that serves the shaft in the source realm. 536 If the inner header is present in the ICMP payload, then the Router 537 extracts it and forwards to the packet source. If the destination 538 stack does not support YADA and decapsulates, the message reaches the 539 router that serves the destination realm which logs and drops. based 540 on the log, the node may be updated, or the DNS records may be fixed 541 to avoid pointing on a node that does not support YADA. 543 YADA was initially published as USPTO 7,356,031, filed in February 544 2002. 546 9. YADA Stateful NAT 548 Inside a realm, a YADA stack falls back to classical IPv4 operations 549 and will natively connects to any legacy IPv4 peers. To reach YADA 550 nodes in alternate realms, YADA also provides a stateful NAT 551 operation that performs an IPv4-to-YADA translation below the legacy 552 stack. The translation reuses some prefix space allocated for either 553 [RFC1918] or [RFC6598] for a local NAT pool that is used to present a 554 single address to the legacy stack. 556 The YADA formulation couples a realm address with a public IPv4 557 address. A host that owns a public address may perform the YADA 558 stateful NAT operation as a bump-in-the-stack below the legacy stack. 559 In a private network, the operation is preferably done in the private 560 gateway, outside the existing private-public NAT so it operates on 561 the resulting public address, to keep the classical NAT operation as 562 is. 564 +-------------+ 565 | | 566 | | +-------------+ 567 +-------------+ | address | 568 | IPv4 | | pool | 569 | stack | +-------------+ 570 +-------------+ +------------------------+ 571 | | | bump in stack stateful | 572 | | | IPv4 -> YADA NAT | 573 +-----+-------+ +--------------------+---+ 574 | ^ | 575 v | v 576 +---------------+------+--------+ +-------------------------------+ 577 | src=this_node | dst=from_pool | | src=this_node | dst=dst-realm | 578 +---------------+---------------+ +---------------+---------------+ 579 | | |src=this_realm |dst=destination| 580 | | +---------------+---------------+ 581 | | | | 582 | IP PAYLOAD | | | 583 | | | | 584 | | | IP PAYLOAD | 585 | | | | 586 +-------------------------------+ | | 587 | | 588 +----------------+--------------+ 589 | 590 V 592 Figure 8: YADA Stateful NAT 594 The stateful NAT intercepts the DNS lookups. If the response 595 contains an A record, then the address is reachable in the local 596 realm and the NAT ignores that destination, letting the legacy 597 operations take place transparently. 599 When the response yields a double-A record with a foreign realm, the 600 stateful NAT allocates an IPv4 address from the local NAT pool and 601 adds it in an A record to the DNS response. A local NAT state is 602 built, indexed by the double-A outside and the allocated single-A 603 inside. 605 When the legacy stack pushes a packet to that particular address, the 606 stateful NAT translates to the YADA format, using the information in 607 the double-A record for the destination, and the local realm as 608 source realm. 610 The other way around, if a packet arrives in the YADA formulation 611 from a different realm, the stateful NAT allocates an address from 612 the pool, and NATs to classical IPv4 using that address as source. 614 As an optimization, a NAT in a private gateway may learn which nodes 615 inside support YADA and bypass the YADA stateful NAT operation 616 completely for those nodes. 618 As long at the bump-in-the-stack (or the gateway) generates YADA 619 packets, the packets can be translated statelessly to YATT as a last 620 bump-in-the-stack operation before transmission to be pushed on an 621 IPv6-only link. 623 The YATT and YADA formulations refer to the same object. A node that 624 is configured with a YATT address is de facto owner of the embedded 625 IPv4 address within the embedded IPv4 realm, and that address can be 626 used to install a legacy IPv4 stack even if the attachement link is 627 pure IPv6. As long at the stack generates YADA packets, the packets 628 can be translated statelessly to YATT as a next bump-in-the-stack 629 operation before transmission and placed on the IPv6-only network. 631 10. YATT 633 A second mechanism called YATT translates the YADA format into flat 634 IPv6. 636 +-----+---------------+--------------+-----------------------------+ 637 |YATT | Realm | IPv4 | Well-Known | 638 |Space| Address | Address | IID | 639 +-----+- -------------+--------------+-----------------------------+ 640 <- YADA 641 prefix -> 642 <-------- YATT prefix ----------> 644 Figure 9: YATT format 646 For unicast addresses, YATT forms an IPv6 prefix by collating an 647 well-known assigned short prefix called the YATT space, the realm 648 address, and the host IPv4 address (locally significant within the 649 realm). The resulting IPv6 prefix is automatically owned by the host 650 that owns the IPv4 address in the realm. 652 Depending on assignment, the leftmost piece realm prefix may be 653 truncated if it is well-known, to allow the YATT space and the realm 654 address to fit in a 32-bit DWORD. This way, the YATT prefix can be a 655 full /64 prefix that is entirely owned by the host that owns the 656 associated YADA address. 658 YATT then forms an IPv6 address for that host by collating a well- 659 known Interface ID, so there's a one-to-one relationship. 661 The formats can not be strictly provided till the YATT space and YADA 662 prefix are assigned. But say that the YATT Space is F000::/6 and the 663 YADA prefix is 240.0.0.0/6. In that case the values perfectly 664 overlap and the YATT format becomes as follows: 666 +-----+----------+----------------+---------------------------------+ 667 | Realm Address | IPv4 Host | Well-Known | 668 | in 240.0.0.0/6 | Public Address | IID | 669 +-----+- --------+----+-----------+---------------------------------+ 670 <--- 32 bits ---><--- 32 bits ---><------------ 64 bits ------------> 671 <------ YATT IPv6 prefix -------> 673 Figure 10: YATT format using 240.0.0.0/6 675 In that case, the NAT operation is a plain insertion. Depending on 676 the assignment, it might be that the Realm address must be placed in 677 full after YATT space. In that case, the length of the YATT prefix 678 will be more than 64 bits. 680 Also, since 240.0.0.0/6 is currently unassigned, using it for the 681 shaft would allow literally to reuse every ASN and every IPv4 address 682 currently available in the Internet in each and every other realm and 683 reallocate them in any fashion desirable in that realm. 685 If the network supports IPv6 to the shaft, it makes sense for the 686 YADA host or the bump-in-the-stack to generate the packets in the 687 YATT form natively. The shaft router must then attract the shaft 688 YADA realm prefix in both IPv4 and YATT forms. 690 If the network is IPv4 only, the packets are still generated using 691 IP-in-IP, and the YATT NAT operation may happen at the router that 692 delivers the packet in the destination realm, if it is v6-only, or in 693 the destination host, if its stack is v6-only. 695 YATT was initially published as USPTO 7,764,686, filed in December 696 2002. 698 11. YATT Stateful PAT 700 The YATT and YADA formulations refer to the same object. A node that 701 is the owner of a public address in a realm is de facto owner of the 702 matching YATT prefix, and is de facto assigned the IPv6 address 703 derived with the YATT-IID. The other way around, a node that is 704 delegated a YATT prefix is de facto owner of the embedded IPv4 705 address within the embedded IPv4 realm. 707 In an IPv4-only environment, a YATT stack may obtain a YADA address 708 pair from DHCPv4 (see Section 5), derive a YATT prefix, and use it to 709 configure the local IPv6 stack. As long at the stack generates YATT 710 packets, the packets can be translated statelessly to YADA as a last 711 bump-in-the-stack operation before transmission. In that model, 712 lower-layer protocols such as ARP and DHCP must be supported, but the 713 IP stack can be IPv6-only. 715 In that case, the node shows as a YADA node, and may talk to a legacy 716 IPv4 stack in a remote realm if the legacy that supports the YADA 717 stateful translation. This combination of stateful PAT after the 718 IPv6 stack and stateful NAT after the IPv4 stack allow the 2 stacks 719 to communicate in the YADA/YATT formulations, and traverse IPv4-only 720 and IPv6-only links using the appropriate formulation. 722 The YATT node may use the YATT prefix to autoconfigure addresses, or 723 it may offer it on an IPv6 stub (tethered) network for address 724 autoconfiguration by attached nodes, protecting the addresses that it 725 keeps for itself using in the DAD procedure. Addresses that are not 726 derived from the YATT-IID will be reachable from IPv6 nodes over an 727 IPv6 network, but not from YADA node, and not over IPv4-only links. 729 To reach YADA nodes and traverse IPv4, the YATT node may leverage a 730 stateful Port Address Translation (PAT) to transform the original IID 731 in the YATT-IID outside. The stateful PAT operation can happen as a 732 bump-in-the-stack before the YATT-to-YADA stateless translation. 734 +-------------+ 735 | | 736 | | +----------+ 737 +-------------+ | port | 738 | IPv6 | | pool | 739 | stack | +----------+ 740 +-------------+ +------------------------+ 741 | | | bump in stack stateful | 742 | | | IPv6 -> YATT PAT | 743 +-----+-------+ +--------------------+---+ 744 | ^ | 745 v | v 746 +----------------------+--------+ +-------------------------------+ 747 | src_prefix (YATT) ; IID = any | | src_prefix ; IID = YATT-IID | 748 +-------------------------------+ +-------------------------------+ 749 | dst (other YATT address) | | dst | 750 +-------------------------------+ +-------------------------------+ 751 +-------------------------------+ +-------------------------------+ 752 | srcport = Selected ; dport | | srcport = Translated ; dport | 753 +-------------------------------+ +-------------------------------+ 754 | | | | 755 | | | | 756 | | | | 757 | IP PAYLOAD | | IP PAYLOAD | 758 | | | | 759 | | | | 760 | | | | 761 +-------------------------------+ +---------------+---------------+ 762 | 763 V 765 Figure 11: YATT Stateful PAT 767 12. The structure of the shaft 769 A 10 miles view of the shaft could be as follows: it is implemented 770 in one IXP, spans all realms, and each realm has one address in the 771 shaft, with one router serving that realm. The address of the realm 772 is encoded in a loopback in the router, and advertised through an IGP 773 inside the shaft, while BGP is used inside the realms but not inside 774 the shaft. The shaft has a single large prefix that is advertised in 775 each realm by the router that serves the shaft, and that is 776 disaggregated into host routes inside the shaft. 778 None of the above is expected to remain true for long. As YADA and 779 YATT get deployed, the shaft will be implemented in different sites 780 over the world. A realm may be multihomed to be reached from a 781 different physical instance of the shaft, meaning that the shaft is 782 composed of either more prefixes or the shaft prefix is 783 disaggregated. Multiple routers will serve the same realm with high 784 availability and load balancing taking place inside the shaft to 785 maintain connectivity. A private shaft may be deployed to 786 interconnect a subset of the realms, in which case the shaft would 787 use a specific prefix that would not be advertised outside the 788 concerned realms. 790 13. Applicability 792 YADA And YATT enable communication between YADA-enabled IPv4 nodes 793 across realms, and with IPv6 nodes that own a YADA address from which 794 a YATT address can be derived. Communication from a legacy IPv4 795 application/stack that is not YADA-enabled, or to an IPv6 address 796 that is not a YATT address, is not provided. 798 Since the YATT translation is stateless, the header translation can 799 happen anywhere in the network, e.g., as a bump in the stack at 800 either end, or within the network, e.g., at the routers that serve 801 the realms on the shaft. The shaft itself is expected to be dual 802 stack to forward packets in their native form, either v4 or v6. 804 For a legacy IPv4 node to communicate with YADA-enabled IPv4 node in 805 another realm, a NAT operation similar to NAT46 [NAT-DEPLOY], but 806 between IPv4 and YADA addresses, is required. The same would be 807 required to allow an IPv4-only YADA node to communicate with an IPv6 808 node a non-YATT address. 810 In summary: 812 * this specification does not allow any IPv4 legacy node to talk to 813 any pure IPv6 node, and recognizes that this Graal may actually be 814 a non-goal. 816 * With YADA the current IPv4 Internet operations within a realm are 817 not mostly unaffected, though additional provisionning is needed 818 for routing and security purposes 820 * YADA extends the IPv4-reachable world by creating (millions of) 821 parallel realms 823 * The stack on IPv4 hosts that require inter-realm communication 824 must be upgraded at least with a bump, though the function may be 825 deported to the private gateway 827 * A new functionality is needed in specific routers at the ingress 828 of the realms and at the border to a single-version domain for NAT 829 operation 831 * A YADA node can talk (using IPv4) to a YATT node (using IPv6) with 832 a stateless translation. The translation can happen anywhere in 833 the network or in the stack. 835 14. Backwards Compatibility 837 YADA operation does not affect the intra-realm communication. The 838 only affected stacks are the endpoints that communicate between 839 realms leveraging YADA. 841 15. Security Considerations 843 YADA introduces an IP-in-IP format that might be used to obfuscate an 844 IP address impersonation performed in the inner header. A proper 845 implemetation of BCP 38 should thus include the capability to 846 recognize a YADA format and allow the source IP address in the inner 847 header to be set to the local realm. 849 Before the router that serves the realm swaps the source address to 850 place a YADA packet in the shaft, it MUST ensure that the realm 851 address in the inner header matches this realm. Otherwise it MUST 852 drop the packet and MAY generate and ICMP Error message back to the 853 source, indicating the offset of the source IP address of the inner 854 header. 856 16. IANA Considerations 858 This document requires the creation of a registry for IPv4 YADA realm 859 prefixes, and the assignment of at least one YADA realm prefix. 861 This document requires the creation of a registry for IPv4 YADA NAT 862 prefixes, and the assignment of at least one YADA NAT prefix. 864 This document requires the creation of a new record in the Resource 865 Record (RR) TYPEs subregistry of the Domain Name System (DNS) 866 Parameters. The new record would be of type AA meaning a YADA 867 address. 869 17. Acknowledgments 871 The author wishes to recognize the pioneer work done by Brian 872 carpenter in the space of IPv4 augmentation with 873 [I-D.carpenter-aeiou] 874 The author wishes to thank Greg Skinner as the first reviewer/ 875 contributor to this work. Also Dave Bell, to remind that even if 876 routing is not touched much inside an IPv4 realm vs. the current art, 877 there might still be work for the ISP, e.g., update the BCP 38 rules 878 in the BNGs. 880 18. References 882 18.1. Normative References 884 [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, 885 DOI 10.17487/RFC0791, September 1981, 886 . 888 [INT-ARCHI] 889 Braden, R., Ed., "Requirements for Internet Hosts - 890 Communication Layers", STD 3, RFC 1122, 891 DOI 10.17487/RFC1122, October 1989, 892 . 894 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 895 RFC 2131, DOI 10.17487/RFC2131, March 1997, 896 . 898 [IPv6-ADDRESSING] 899 Hinden, R. and S. Deering, "IP Version 6 Addressing 900 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 901 2006, . 903 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 904 (IPv6) Specification", STD 86, RFC 8200, 905 DOI 10.17487/RFC8200, July 2017, 906 . 908 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 909 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 910 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 911 RFC 8415, DOI 10.17487/RFC8415, November 2018, 912 . 914 18.2. Informative References 916 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 917 J., and E. Lear, "Address Allocation for Private 918 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 919 February 1996, . 921 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 922 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 923 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 924 2012, . 926 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 927 Combination of Stateful and Stateless Translation", 928 RFC 6877, DOI 10.17487/RFC6877, April 2013, 929 . 931 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 932 Korhonen, "Requirements for Distributed Mobility 933 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 934 . 936 [NAT-DEPLOY] 937 Palet Martinez, J., "Additional Deployment Guidelines for 938 NAT64/464XLAT in Operator and Enterprise Networks", 939 RFC 8683, DOI 10.17487/RFC8683, November 2019, 940 . 942 [I-D.carpenter-aeiou] 943 Carpenter, B. E., "Address Extension by IP Option Usage 944 (AEIOU)", Work in Progress, Internet-Draft, draft- 945 carpenter-aeiou-00, 21 March 1994, 946 . 949 Author's Address 951 Pascal Thubert (editor) 952 Cisco Systems, Inc 953 Building D 954 45 Allee des Ormes - BP1200 955 06254 Mougins - Sophia Antipolis 956 France 957 Phone: +33 497 23 26 34 958 Email: pthubert@cisco.com