idnits 2.17.00 (12 Aug 2021) /tmp/idnits60519/draft-thubert-v6ops-yada-yatt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 3 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 (29 March 2022) is 53 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) 29 March 2022 5 Intended status: Informational 6 Expires: 30 September 2022 8 Yet Another Double Address and Translation Technique 9 draft-thubert-v6ops-yada-yatt-01 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. YATT can take place as a bump 22 in the stack at either end, or within the network and enables an 23 IPv6-only stack to dialog with an IPv4-only stack across a network 24 that can be IPv6, IPv4, or mixed. YATT requires that the IPv6 stack 25 owns a prefix that derives from a YADA address and the IPv4 stack is 26 capable of YADA, so it does not replace a generic 4 to 6 translation 27 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 30 September 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Extending RFC 1122 . . . . . . . . . . . . . . . . . . . . . 5 67 4. Extending RFC 4291 . . . . . . . . . . . . . . . . . . . . . 5 68 5. YADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 6. YATT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 12.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 This document provides a mechanism called Yet Another Double Address 83 (YADA) to grow the Internet beyond the current IPv4 [IPv4] realm that 84 limits its capacity to form public addresses. This is achieved by 85 interconnecting IPv4 realms via a common footprint called the shaft. 87 In the analogy of a building, the ground floor would be the Internet, 88 and each additional floor would be another IPv4 realm. The same 89 surface of floor is available in each level, analog to the full IPv4 90 addressing that is available in each realm. The same footprint is 91 dedicated across the building levels for the elevator shaft. The 92 elevator shaft enables a third dimension that spans across the levels 93 and allows to traverse from any level to any other level. The 94 elevator shaft cannot be used for living or office space. 96 /------------------------------------------------------ 97 / / 98 / |------------| realm 1 / 99 / /. /. / 100 / / . shaft / . (current IPv4 Internet) / 101 / |------------| . / 102 / . . . . / 103 ------------------------------------------------------/ 104 | . | | 105 /-----|------------|--|-------------------------------- 106 / | . | | / 107 / | |---------|--| realm 2 / 108 / | /. | /. / 109 / |/ . shaft |/ . / 110 / |------------| . / 111 / . . . . / 112 ------------------------------------------------------/ 113 | . | | 114 | . | | 115 | | . 116 | | . 117 . . | 118 . . | 119 | . | | 120 /-----|------------|--|-------------------------------- 121 / | . | | / 122 / | |---------|--| realm N / 123 / | / | / / 124 / |/ shaft |/ / 125 / |------------| / 126 / / 127 ------------------------------------------------------/ 129 Figure 1: The shaft 131 By analogy, YADA assigns IPv4 prefixes to a multinternet shaft; those 132 prefixes are common across the realms that are interconnected by the 133 shaft. A single /24 IPv4 prefix assigned allows for > 250 times the 134 capacity of the Internet as we know it at the time of this writing. 136 Multiple prefixes can be assigned to the shaft for unicast and 137 multicast communications, and each realm needs at least one unicast 138 address in the shaft called its realm address. A YADA address is 139 formed by the tuple (realm address, IPv4 address) and is advertised 140 in DNS as a new double-A record. 142 YADA leverages IP-in-IP encapsulation to tunnel packets across the 143 shaft while normal IPv4 operations happen within a realm. YADA 144 requires a change in the stack in the YADA endpoints that communicate 145 with other realms to support the IP-in-IP YADA encapsulation. YADA 146 also provides a bump in the stack method for legacy applications. 147 More in Section 5. 149 A second mechanism called Yet Another Translation Technique (YATT) 150 translates the YADA format into flat IPv6 [IPv6]. For unicast 151 addresses, YATT forms an IPv6 prefix by collating an well-known 152 assigned short prefix, the realm address (in the shaft), and the host 153 IPv4 address (locally significant within the realm). The resulting 154 IPv6 prefix is automatically owned by the host that owns the IPv4 155 address in the realm. YATT then forms an IPv6 address for that host 156 by collating a well-known Interface ID, so there's a one-to-one 157 relationship between the YADA and the IPv6 address derived from it. 158 More in Section 6. 160 2. Terminology 162 2.1. Glossary 164 This document often uses the following acronyms: 166 YADA: Yet Another Double Address 167 YATT: Yet Another Translation Technique 168 NAT: Network address Translation 169 IID: Interface ID 170 CG-NAT: Carrier Grade NAT 172 2.2. New Terms 174 This document often uses the following nex terms: 176 IPv4 realm A full IPv4 network like the current Internet. YADA does 177 not affect the traditional IPv4 operations within a realm. 178 The shaft The shaft refers to a collection of IPv4 unicast and 179 multicast prefixes that are assigned to Inter-realm communications 180 and cannot be assigned to hosts or multicast groups within a 181 realm. 182 realm address An IPv4 address that derives from a shaft prefix. 183 Uni-realm address A realm address that is unicast or anycast. A 184 realm may have more than one Uni-realm address. 185 Multi-realm address A realm address that is multicast and denotes a 186 collection of realms. 187 YADA realm Prefix A Prefix assigned to the shaft and from which 188 realm addresses can be derived. 189 YADA NAT Prefix A Prefix assigned to the YADA bump-in-the-stack NAT 190 operation. 191 Double-A or YADA address A YADA address is a tuple (realm address, 192 IPv4 address) where the IPv4 address is only significant within 193 the realm denoted by the realm address. 194 YATT Space An IPv6 range that is assigned for YATT operation. 195 YATT Prefix An IPv6 prefix that is derived from a YADA address by 196 appending the YATT space prefix, the (truncated) realm address and 197 the IPv4 address. 198 YATT-IID: A 64-bit assigned constant that is used in YATT to 199 statelessly form an IPv6 address from a YATT prefix. 200 Multinternet A collection of IPv4 realms interconnected using a 201 common shaft. 203 3. Extending RFC 1122 205 YADA extends [INT-ARCHI] to add the capability for an IPv4 host to 206 recognize an special IP-in-IP format as an inter-realm IPv4 packet 207 and process it accordingly. It also adds a new DNS double-A record 208 format that denotes a YADA address. 210 4. Extending RFC 4291 212 YATT extends [IPv6-ADDRESSING] to add the capability for an IPv4 host 213 to recognize an special IPv6 format as an YATT address embedding a 214 YADA address and process it accordingly. It also automatically 215 derives the ownership of the YATT prefix associated to a owned YADA 216 address. 218 5. YADA 220 YADA assigns IPv4 prefixes to a multinternet shaft; those prefixes 221 must be the same across all the realms that are interconnected by the 222 shaft. Multiple prefixes can be assigned to the shaft for unicast 223 and multicast communications, and each realm needs at least one 224 unicast address in the shaft called its realm address. A YADA 225 address is formed by the tuple (realm address, IPv4 address) and is 226 advertised in DNS as a new double-A record. Because the YADA 227 prefixes are assigned for YADA, a packet that has either source or 228 destination IPV4 address derived from a shaft prefix is a YADA 229 packet. 231 YADA leverages IP-in-IP encapsulation to tunnel packets across the 232 shaft for inter-realm communications, while the IPv4 operations 233 within a realm are unaffected. The YADA address is found by using 234 both inner and outer header and combining that information. The pair 235 of IP headers is seen by a YADA stack as a single larger header 236 though a non-YADA forwarder only needs the outer header and plain 237 IPv4 operations to forward. 239 YADA requires a change in the stack in the YADA endpoints that 240 communicate with other realms to support the YADA encapsulation. 241 YADA also provides a bump in the stack method for legacy 242 applications. YADA also requires a change for the routers that serve 243 the shaft. Those routers play a special role for packets that are 244 delivered from the shaft to the destination realm, and for ICMP 245 errors across realms. All other IPv4 nodes in the realm continue to 246 operate as before. 248 Routers serving the shaft advertise the shaft prefix(es) in their 249 respective realms, and their realm addresses within the shaft, as 250 host routes for unicast and anycast addresses. A stack that resolve 251 a DNS name with a double-A record indicating a different realm 252 generates an IP-in-IP packet, with the outer header indicating the 253 source and destination realms, and the inner header indicating the 254 source and destination IPv4 addresses within the respective realms, 255 as shown in Figure 2. The packet is forwarded down the shaft as is, 256 using the normal longest match or multicast operation. 258 | | 259 /------|------------|--------------------------------- 260 / | | / 261 / | | | | / 262 / | |--------|---| Source Node / 263 / | / | / / 264 / | /. +---|---- outer(src=src-realm / 265 / |/ . | |/ . dst=dst-realm) / 266 / |------------| . inner(src=src-addr / 267 / . . | . . dst=dst-addr) / 268 / . . | . . / 269 / . . | . . / 270 -----------------------------------------------------/ 271 | | | | 272 | | | 273 | | | 274 v 276 Figure 2: Packets Entering the shaft 278 The packet destination is an address is the shaft and it is attracted 279 by a router that serves the shaft and advertises its prefixes in the 280 source realm. Based on longest match, the router forwards the packet 281 inside the shaft following the host route to a router that serves the 282 destination realm. That router swaps the destination address in the 283 inner and outer headers and forwards within its realm to the final 284 destination, as shown in Figure 3. In normal conditions, the stack 285 of the destination node recognizes the YADA format and replies 286 accordingly. 288 | 289 | | | 290 | | | 291 /------|----|-------|--------------------------------- 292 / | | | | | / 293 / | | | | | / 294 / | |----|---|---| Destination Node / 295 / | / | | / / 296 / | /. +---|----> outer(src=src-realm / 297 / |/ . |/ . dst=dst-addr) / 298 / |------------| . inner(src=src-addr / 299 / . . . . dst=realm-addr) / 300 / . . . . / 301 / . . . . / 302 -----------------------------------------------------/ 304 Figure 3: Packets Outgoing the shaft 306 In case of an error down the path or at the destination, if an ICMP 307 message is generated by a node that is not YADA-aware, the message 308 reaches the router that serves the shaft in the source realm. If the 309 inner header is present in the ICMP payload, then the Router extracts 310 it and forwards to the packet source. If the destination stack does 311 not support YADA and decapsulates, the message reaches the router 312 that serves the destination realm which logs and drops. based on the 313 log, the node may be updated, or the DNS records may be fixed to 314 avoid pointing on a node that does not support YADA. 316 YADA requires the assignment of a second IPv4 prefix, this time for a 317 internal NATing operation. A bump-in-the-stack intercepts the DNS 318 lookups, and when the response yields a double-A record with a 319 foreign realm, the record is augmented with an IPv4 address taken 320 from a local NAT pool. When the stack sends a packet to that 321 particular address, the bump-in-the-stack translates to the YADA 322 format, using the information in the double-A record for the 323 destination, and the local realm as source realm. The other way 324 around, if a packet arrives with a YADA format but the stack does not 325 support it, the bump-in-the-stack allocates an address from the pool, 326 and NATs to IPv4 using that address as source. 328 YADA was initially published as USPTO 7,356,031, filed in February 329 2002. 331 6. YATT 333 A second mechanism called YATT translates the YADA format into flat 334 IPv6. 336 +-----+---------------+--------------+-----------------------------+ 337 |YATT | Realm | IPv4 | Well-Known | 338 |Space| Address | Address | IID | 339 +-----+- -------------+--------------+-----------------------------+ 340 <- YADA 341 Prefix -> 342 <-------- YATT Prefix ----------> 344 Figure 4: YATT format 346 For unicast addresses, YATT forms an IPv6 prefix by collating an 347 well-known assigned short prefix called the YATT space, the realm 348 address, and the host IPv4 address (locally significant within the 349 realm). The resulting IPv6 prefix is automatically owned by the host 350 that owns the IPv4 address in the realm. 352 Depending on assignment, the leftmost piece realm prefix may be 353 truncated if it is well-known, to allow the YATT space and the realm 354 address to fit in a 32-bit DWORD. This way, the YATT prefix can be a 355 full /64 prefix that is entirely owned by the host that owns the 356 associated YADA address. 358 YATT then forms an IPv6 address for that host by collating a well- 359 known Interface ID, so there's a one-to-one relationship. 361 The formats can not be strictly provided till the YATT space and YADA 362 prefix are assigned. But say that the YATT Space is F000::/6 and the 363 YADA prefix is 240.0.0.0/6. In that case the values perfectly 364 overlap and the YATT format becomes as follows: 366 +-----+----------+----------------+---------------------------------+ 367 | Realm Address | IPv4 Host | Well-Known | 368 | in 240.0.0.0/6 | Public Address | IID | 369 +-----+- --------+----+-----------+---------------------------------+ 370 <--- 32 bits ---><--- 32 bits ---><------------ 64 bits ------------> 371 <------ YATT IPv6 Prefix -------> 373 Figure 5: YATT format using 240.0.0.0/6 375 In that case, the NAT operation is a plain insertion. Depending on 376 the assignment, it might be that the Realm address must be placed in 377 full after YATT space. In that case, the length of the YATT prefix 378 will be more than 64 bits. 380 If the network supports IPv6 to the shaft, it makes sense for the 381 YADA host or the bump-in-the-stack to generate the packets in the 382 YATT form natively. The shaft router must then attract the shaft 383 YADA realm Prefix in both IPv4 and YATT forms. 385 If the network is IPv4 only, the packets are still generated using IP 386 in IP, and the YATT NAT operation may happen at the router that 387 delivers the packet in the destination realm, if it is v6-only, or in 388 the destination host, if its stack is v6-only. 390 YATT was initially published as USPTO 7,764,686, filed in December 391 2002. 393 7. Applicability 395 YADA And YATT enable communication between YADA-enabled IPv4 nodes 396 across realms, and with IPv6 nodes that own a YADA address from which 397 a YATT address can be derived. Communication from a legacy IPv4 398 application/stack that is not YADA-enabled, or to an IPv6 address 399 that is not a YATT address, is not provided. 401 Since the YATT translation is stateless, the header translation can 402 happen anywhere in the network, e.g., as a bump in the stack at 403 either end, or within the network, e.g., at the routers that serve 404 the realms on the shaft. The shaft itself is expected to be dual 405 stack to forward packets in their native form, either v4 or v6. 407 For a legacy IPv4 node to communicate with YADA-enabled IPv4 node in 408 another realm, a NAT operation similar to NAT46 [NAT-DEPLOY], but 409 between IPv4 and YADA addresses, is required. The same would be 410 required to allow an IPv4-only YADA node to communicate with 412 8. Backwards Compatibility 414 YADA operation does not affect the intra-realm communication. The 415 only affected stacks are the endpoints that communicate between 416 realms leveraging YADA. 418 9. Security Considerations 420 10. IANA Considerations 422 This document requires the creation of a registry for IPv4 YADA realm 423 prefixes, and the assignment of at least one YADA realm prefix. 425 This document requires the creation of a registry for IPv4 YADA NAT 426 prefixes, and the assignment of at least one YADA NAT prefix. 428 11. Acknowledgments 430 12. References 432 12.1. Normative References 434 [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, 435 DOI 10.17487/RFC0791, September 1981, 436 . 438 [INT-ARCHI] 439 Braden, R., Ed., "Requirements for Internet Hosts - 440 Communication Layers", STD 3, RFC 1122, 441 DOI 10.17487/RFC1122, October 1989, 442 . 444 [IPv6-ADDRESSING] 445 Hinden, R. and S. Deering, "IP Version 6 Addressing 446 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 447 2006, . 449 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 450 (IPv6) Specification", STD 86, RFC 8200, 451 DOI 10.17487/RFC8200, July 2017, 452 . 454 12.2. Informative References 456 [NAT-DEPLOY] 457 Palet Martinez, J., "Additional Deployment Guidelines for 458 NAT64/464XLAT in Operator and Enterprise Networks", 459 RFC 8683, DOI 10.17487/RFC8683, November 2019, 460 . 462 Author's Address 464 Pascal Thubert (editor) 465 Cisco Systems, Inc 466 Building D 467 45 Allee des Ormes - BP1200 468 06254 Mougins - Sophia Antipolis 469 France 470 Phone: +33 497 23 26 34 471 Email: pthubert@cisco.com