| < draft-thubert-v6ops-yada-yatt-03.txt | draft-thubert-v6ops-yada-yatt-04.txt > | |||
|---|---|---|---|---|
| v6ops P. Thubert, Ed. | v6ops P. Thubert, Ed. | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Updates: 1122, 4291 (if approved) 7 April 2022 | Updates: 1122, 4291 (if approved) 11 April 2022 | |||
| Intended status: Informational | Intended status: Informational | |||
| Expires: 9 October 2022 | Expires: 13 October 2022 | |||
| Yet Another Double Address and Translation Technique | Yet Another Double Address and Translation Technique | |||
| draft-thubert-v6ops-yada-yatt-03 | draft-thubert-v6ops-yada-yatt-04 | |||
| Abstract | Abstract | |||
| This document provides a stepwise migration between IPv4 and IPv6 | This document provides a stepwise migration between IPv4 and IPv6 | |||
| with baby steps from an IPv4-only stack/gateway/ISP to an IPv6-only | with baby steps from an IPv4-only stack/gateway/ISP to an IPv6-only | |||
| version, that allows portions of the nodes and of the networks to | version, that allows portions of the nodes and of the networks to | |||
| remain IPv4, and reduces the need for dual stack and CG NATs between | remain IPv4, and reduces the need for dual stack and CG NATs between | |||
| participating nodes. A first mechanism named YADA to augment the | participating nodes. A first mechanism named YADA to augment the | |||
| capacity of the current IPv4 Internet by interconnecting IPv4 realms | capacity of the current IPv4 Internet by interconnecting IPv4 realms | |||
| via a common footprint called the shaft. YADA extends RFC 1122 with | via a common footprint called the shaft. YADA extends RFC 1122 with | |||
| skipping to change at page 1, line 49 ¶ | skipping to change at page 1, line 49 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 9 October 2022. | This Internet-Draft will expire on 13 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 | 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. Extending RFC 1122 . . . . . . . . . . . . . . . . . . . . . 8 | 4. Extending RFC 1122 . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 5. Extending RFC 4291 . . . . . . . . . . . . . . . . . . . . . 8 | 5. Extending RFC 2131 . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 6. YADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 6. Extending RFC 4291 . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 7. YATT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 7. Extending RFC 8415 . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 8. The structure of the shaft . . . . . . . . . . . . . . . . . 15 | 8. YADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15 | 9. YADA Stateful NAT . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 10. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 16 | 10. YATT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 11. YATT Stateful PAT . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 12. The structure of the shaft . . . . . . . . . . . . . . . . . 17 | |||
| 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 | 13. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 14. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 19 | |||
| 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 | 15. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
| 14.2. Informative References . . . . . . . . . . . . . . . . . 17 | 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 | 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
| 18.1. Normative References . . . . . . . . . . . . . . . . . . 20 | ||||
| 18.2. Informative References . . . . . . . . . . . . . . . . . 20 | ||||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
| 1. Introduction and Motivation | 1. Introduction and Motivation | |||
| At the time of this writing, the transition to IPv6 started 20 years | At the time of this writing, the transition to IPv6 started 20 years | |||
| ago and large amounts of networks, hosts, and programs, are still | ago and large amounts of networks, hosts, and programs, are still | |||
| IPv4-only. The IPv4 and IPv6 camps are quite entrenched, and there's | IPv4-only. The IPv4 and IPv6 camps are quite entrenched, and there's | |||
| no indication that things will change any time soon. | no indication that things will change any time soon. | |||
| During that endless transition, stacks must implements both protocols | During that endless transition, stacks must implement both protocols | |||
| (aka dual stack) and a mechanism to use either based on the | (aka dual stack) and a mechanism to use either based on the | |||
| responsiveness (Happy Eyeballs). Service Providers must implement | responsiveness (Happy Eyeballs). Service Providers must implement | |||
| heavy weaponry called Carrier-Grade Network Address Translators (CG- | heavy weaponry called Carrier-Grade Network Address Translators (CG- | |||
| NATs) to translate between protocols between legacy IPv4-only and | NATs) to translate between protocols between legacy IPv4-only and | |||
| IPv6-only stacks, and tunneling techniques such as DS-Lite and | IPv6-only stacks, and tunneling techniques such as DS-Lite [RFC7333] | |||
| 464XLAT to traverse portions of the network that support only one of | and 464XLAT [RFC6877] to traverse portions of the network that | |||
| the IP versions. This means both CAPEX to install dual stack | support only one of the IP versions. This means both CAPEX to | |||
| infrastructures and NAT devices and OPEX to maintain them. The | install dual stack infrastructures and NAT devices and OPEX to | |||
| current situation is often qualified as the worst of both worlds and | maintain them. The current situation is often qualified as the worst | |||
| any indications is that it's here to stay, till each side suffered | of both worlds and any indications is that it's here to stay, till | |||
| enough and is ready for a compromise. | each side suffered enough and is ready for a compromise. | |||
| This document prepares for that time where the players will | This document prepares for that time where the players will | |||
| effectively be ready for a compromise. An acceptable compromise must | effectively be ready for a compromise. An acceptable compromise must | |||
| provide both sides with way to remain as long as desired, while | provide both sides with way to remain as long as desired, while | |||
| eliminating the need for dual stack and CG-NATs between participating | eliminating the need for dual stack and CG-NATs between participating | |||
| nodes. Certainly, an effort must be asked on each side to reduce the | nodes. Certainly, an effort must be asked on each side to reduce the | |||
| chasm, and that effort must come with enough benefits to effectively | chasm, and that effort must come with enough benefits to effectively | |||
| encourage a majority of interested parties to make the step. | encourage a majority of interested parties to make the step. | |||
| Yet Another Double Address (YADA) refers to effort that is asked from | Yet Another Double Address (YADA) refers to effort that is asked from | |||
| skipping to change at page 3, line 42 ¶ | skipping to change at page 4, line 6 ¶ | |||
| made by the IPv6 side to support a new IPv6 Prefix with special | made by the IPv6 side to support a new IPv6 Prefix with special | |||
| properties, which impacts in particular source address selection | properties, which impacts in particular source address selection | |||
| (SAS). YATT extends [IPv6-ADDRESSING] for the YATT format. The | (SAS). YATT extends [IPv6-ADDRESSING] for the YATT format. The | |||
| proposed benefit is a prefix (say /32) per realm and a prefix (say | proposed benefit is a prefix (say /32) per realm and a prefix (say | |||
| /64) per host in the realm. This address space may for instance | /64) per host in the realm. This address space may for instance | |||
| become handy for load balancing between physical servers / VMs / pods | become handy for load balancing between physical servers / VMs / pods | |||
| that operate a service associated with the virtual server that owns | that operate a service associated with the virtual server that owns | |||
| the host prefix. | the host prefix. | |||
| The YADA and YATT formats are interchangeable, which means that the | The YADA and YATT formats are interchangeable, which means that the | |||
| translation is stateless and can take place as a bump in the stack at | translation is stateless and can take place as a bump-in-the-stack at | |||
| either end or can be operated at line rate anywhere in the network by | either end or can be operated at line rate anywhere in the network by | |||
| an upgraded hardware. The routers that connect the shaft also | an upgraded hardware. The routers that connect the shaft also | |||
| perform a stateless operation that can be achieved at line rate by | perform a stateless operation that can be achieved at line rate by | |||
| upgraded hardware. This is how the chasm between IPv4 and IPv6 can | upgraded hardware. This is how the chasm between IPv4 and IPv6 can | |||
| be reduced, removing the need to deploy dual stack and CG-NATs | be reduced, removing the need to deploy dual stack and CG-NATs | |||
| between participating nodes. | between participating nodes. | |||
| This document provides a stepwise migration between IPv4 and IPv6 | This document provides a stepwise migration between IPv4 and IPv6 | |||
| with baby steps from an IPv4-only stack/gateway/ISP to YADA to YATT | with baby steps from an IPv4-only stack/gateway/ISP to YADA to YATT | |||
| to an IPv6-only version. The migration strategy allows portions of | to an IPv6-only version. The migration strategy allows portions of | |||
| the nodes and of the networks to remain IPv4. This enables an | the nodes and of the networks to remain IPv4. | |||
| IPv6-only stack to dialog with an IPv4-only stack across a network | ||||
| that can be IPv6, IPv4, or mixed. | ||||
| YATT requires that the IPv6 stack owns a prefix that derives from a | YATT requires that the IPv6 stack owns a prefix that derives from a | |||
| YADA address associated to a realm, even if there's absolutely no | YADA address associated to a realm, even if there's absolutely no | |||
| IPv4 operation taking place in that realm. The resulting | IPv4 operation taking place in that realm. The resulting | |||
| connectivity without dual stack and CG-NAT is as follows: | connectivity without dual stack and CG-NAT is as follows: | |||
| * A legacy IPv4-only node can only talk within its realm. It can | * A legacy IPv4-only node can only talk within its realm. It can | |||
| talk to a IPv4 legacy node, and YADA IPv4-only node and a YATT | talk to an IPv4 legacy node, a YADA IPv4-only node, and even a | |||
| IPv6-only node, e.g., leveraging a bump-in-the-stack in the YATT | YATT IPv6-only node, e.g., leveraging a bump-in-the-stack in the | |||
| node if the network is IPv4-only. | YATT node if the access network is IPv4-only. | |||
| * In addition, a YADA IPv4-only node can talk across realms to a | * In addition, a YADA IPv4-only node can talk across realms to a | |||
| YADA IPv4-only node and to any YATT IPv6-only node. | YADA IPv4-only node and to any YATT IPv6-only node, e.g., | |||
| leveraging a bump-in-the-stack in the YADA node if the network is | ||||
| IPv6-only. | ||||
| * In addition, a YATT IPv6-only node can talk to all the IPv6 | * In addition, a YATT IPv6-only node can talk to any other IPv6-only | |||
| addressable space to any IPv6-only node. | node. | |||
| Connectivity between an IPv4-only node and an IPv6-only node, or | Connectivity between an IPv4-only node and an IPv6-only node, or | |||
| between an IPv4-only node and a YADA node in different realm, still | between an IPv4-only node and a YADA node in different realm, still | |||
| requires a CG-NATs as of today, e.g., using the YATT format for the | requires a CG-NATs as of today, e.g., using the YATT format for the | |||
| IPv6 side in an unmodified CG-NAT. | IPv6 side in an unmodified CG-NAT. | |||
| 2. Terminology | 2. Terminology | |||
| 2.1. Glossary | 2.1. Glossary | |||
| skipping to change at page 5, line 28 ¶ | skipping to change at page 5, line 36 ¶ | |||
| the realm denoted by the realm address. | the realm denoted by the realm address. | |||
| YATT Space: An IPv6 range that is assigned for YATT operation. | YATT Space: An IPv6 range that is assigned for YATT operation. | |||
| YATT prefix: An IPv6 prefix that is derived from a YADA address by | YATT prefix: An IPv6 prefix that is derived from a YADA address by | |||
| appending the YATT space prefix, the (truncated) realm address and | appending the YATT space prefix, the (truncated) realm address and | |||
| the IPv4 address. | the IPv4 address. | |||
| YATT-IID: A 64-bit assigned constant that is used in YATT to | YATT-IID: A 64-bit assigned constant that is used in YATT to | |||
| statelessly form an IPv6 address from a YATT prefix. | statelessly form an IPv6 address from a YATT prefix. | |||
| Multinternet: A collection of IPv4 realms interconnected using a | Multinternet: A collection of IPv4 realms interconnected using a | |||
| common shaft. | common shaft. | |||
| 3. Operation | 3. Overview | |||
| This document provides a stepwise migration between IPv4 and IPv6 | This document provides a stepwise migration between IPv4 and IPv6 | |||
| with baby steps from an IPv4-only stack/gateway/ISP to an IPv6-only | with baby steps from an IPv4-only stack/gateway/ISP to an IPv6-only | |||
| version. The baby steps reduce the gap between the only versions and | version. The baby steps reduce the gap between the only versions and | |||
| teh associated need for dual stack and CG-NATs. | the associated need for dual stack and CG-NATs. | |||
| The first step called YADA uses IPv4-only signaling. The second step | ||||
| called Yet Another Translation Technique (YATT) offers an IPv6-only | ||||
| signaling that is interchangeable with YADA, so any router or stack | ||||
| may turn one into the other, allowing the stack or the link to be one | ||||
| version only. A YADA-enabled IPv4 stack can thus talk to a YATT- | ||||
| enabled IPv6 stack with neither CG-NATs nor dual stack network in | ||||
| between, but a stack that is not aware of this specification will | ||||
| still need a traditional NAT approach to communicate. | ||||
| The effort in this specification is to provide enough value / | ||||
| incentive for an IPv4-only stack/gateway/ISP to make the step towards | ||||
| YADA, as a push towards IPv6, and for an IPv6-only stack to support | ||||
| YATT on top to pull IPv4 space in IPv6, with a low barrier for making | ||||
| the baby step. For IPv4, going YADA expands the size/reach of the | ||||
| Internet, and allows multiple parties to build their own IPv4 realm, | ||||
| with control of interconnection with other realms. For an IPv6 node, | ||||
| supporting YATT provides connectivity to the YADA world, and | ||||
| automatically assigns a prefix in the node. | ||||
| This first mechanism called YADA allows to grow the Internet beyond | This first mechanism called YADA allows to grow the Internet beyond | |||
| the current IPv4 [IPv4] realm that limits its capacity to form public | the current IPv4 [IPv4] realm that limits its capacity to form public | |||
| addresses. Depending on the assignments to be made, the model allows | addresses. Depending on the assignments to be made, the model allows | |||
| to reuse all IP addresses and all Autonomous System Number (ASN) | to reuse all IP addresses and all Autonomous System Number (ASN) | |||
| currently available in the internet hundreds to millions of times. | currently available in the internet hundreds to millions of times. | |||
| This is achieved by interconnecting IPv4 realms via a common | This is achieved by interconnecting IPv4 realms via a common | |||
| footprint called the shaft. | footprint called the shaft. | |||
| In the analogy of a building, the ground floor would be the Internet, | In the analogy of a building, the ground floor would be the Internet, | |||
| skipping to change at page 7, line 44 ¶ | skipping to change at page 7, line 4 ¶ | |||
| / |------------| / | / |------------| / | |||
| / / | / / | |||
| ------------------------------------------------------/ | ------------------------------------------------------/ | |||
| Figure 1: The shaft | Figure 1: The shaft | |||
| By analogy, YADA assigns IPv4 prefixes to a multinternet shaft; those | By analogy, YADA assigns IPv4 prefixes to a multinternet shaft; those | |||
| prefixes are common across the realms that are interconnected by the | prefixes are common across the realms that are interconnected by the | |||
| shaft. A single /24 IPv4 prefix assigned allows for > 250 times the | shaft. A single /24 IPv4 prefix assigned allows for > 250 times the | |||
| capacity of the Internet as we know it at the time of this writing. | capacity of the Internet as we know it at the time of this writing. | |||
| Multiple prefixes can be assigned to the shaft for unicast and | Multiple prefixes can be assigned to the shaft for unicast and | |||
| multicast communications, and each realm needs at least one unicast | multicast communications, and each realm needs at least one unicast | |||
| address in the shaft called its realm address. A YADA address is | address in the shaft called its realm address. A YADA address is | |||
| formed by the tuple (realm address, IPv4 address) and is advertised | formed by the tuple (realm address, IPv4 address) and is advertised | |||
| in DNS as a new double-A record. | in DNS as a new double-A record. | |||
| YADA leverages IP-in-IP encapsulation to tunnel packets across the | YADA leverages IP-in-IP encapsulation to tunnel packets across the | |||
| shaft while normal IPv4 operations happen within a realm. YADA | shaft while normal IPv4 operations happen within a realm. YADA | |||
| requires a change in the stack in the YADA endpoints that communicate | requires a change in the stack in the YADA endpoints that communicate | |||
| with other realms to support the IP-in-IP YADA encapsulation. YADA | with other realms to support the IP-in-IP YADA encapsulation. YADA | |||
| also provides a bump in the stack method for legacy applications. | also provides a bump in the stack method for legacy applications. | |||
| More in Section 6. | More in Section 9. | |||
| A second mechanism called YATT translates the YADA format into flat | A second mechanism called YATT translates the YADA format into flat | |||
| IPv6 [IPv6]. While a YADA address pair can be seen as some foot | IPv6 [IPv6]. While a YADA address pair can be seen as some foot | |||
| print in one level, the YATT prefix encompasses that same foot print | print in one level, the YATT prefix encompasses that same foot print | |||
| plus all the air above it. For unicast addresses, YATT forms an IPv6 | plus all the air above it. For unicast addresses, YATT forms an IPv6 | |||
| prefix by collating an well-known assigned short prefix, the realm | prefix by collating an well-known assigned short prefix, the realm | |||
| address (in the shaft), and the host IPv4 address (locally | address (in the shaft), and the host IPv4 address (locally | |||
| significant within the realm). The resulting IPv6 prefix is | significant within the realm). The resulting IPv6 prefix is | |||
| automatically owned by the host that owns the IPv4 address in the | automatically owned by the host that owns the IPv4 address in the | |||
| realm. YATT then forms an IPv6 address for that host by collating a | realm. YATT then forms an IPv6 address for that host by collating a | |||
| well-known Interface ID, so there's a one-to-one relationship between | well-known Interface ID, so there's a one-to-one relationship between | |||
| the YADA and the IPv6 address derived from it. More in Section 7. | the YADA and the IPv6 address derived from it. More in Section 10. | |||
| A key concept for this specification is that YADA (the IPv4 | A key concept for this specification is that YADA (the IPv4 | |||
| formulation) and YATT (the IPv6 formulation) represent the same | formulation) and YATT (the IPv6 formulation) are alternative | |||
| thing. YADA uses IPv4 formats as plain IP-in-IP with no new | representations of the same abstract object (a double address), which | |||
| extension. YATT uses IPv6 format with the IPv4 addresses encoded on | can serve as an intermediate step across the IPv4-IPv6 chasm. The | |||
| the prefix. The formats are interchangeable, and a router can | IPv4 formulation (YADA) is a plain IP-in-IP with no new extension. | |||
| convert one to another as the packet flows over a next-hop link that | The IPv6 formulation (YATT) uses a standard IPv6 header with a | |||
| can only carry the other address family. | special encoding of the addresses. The formulations are | |||
| interchangeable; if a link supports both IP versions then the next | ||||
| hop is valid for both formulations, whichever of the 2 Address | ||||
| Families (AFs) was used to learn it; else any node can convert one | ||||
| formulation to the other to accomodate the IP version that is | ||||
| available on the next hop link. | ||||
| 4. Extending RFC 1122 | 4. Extending RFC 1122 | |||
| YADA extends [INT-ARCHI] to add the capability for an IPv4 host to | YADA extends [INT-ARCHI] to add the capability for an IPv4 host to | |||
| recognize an special IP-in-IP format as an inter-realm IPv4 packet | recognize an special IP-in-IP format as an inter-realm IPv4 packet | |||
| and process it accordingly. It also adds a new DNS double-A record | and process it accordingly. It also adds a new DNS double-A record | |||
| format that denotes a YADA address. | format that denotes a YADA address. | |||
| 5. Extending RFC 4291 | 5. Extending RFC 2131 | |||
| YATT extends [IPv6-ADDRESSING] to add the capability for an IPv4 host | The Dynamic Host Configuration Protocol [RFC2131] (DHCP) is extended | |||
| to recognize an special IPv6 format as an YATT address embedding a | to pass information to the host about its current realm. When this | |||
| YADA address and process it accordingly. It also automatically | information is present, the host is free to use YADA using that | |||
| derives the ownership of the YATT prefix associated to a owned YADA | realms as source realm. | |||
| address. | ||||
| 6. YADA | If a host obtains a public address from DHCP, and for the duration of | |||
| the lease, the host automatically owns the YATT prefix associated to | ||||
| a owned YADA address. In this manner, DHCPv4 becomes an alternate | ||||
| method for delegating an IPv6 prefix from which the host may | ||||
| provision an IPv6 stack. | ||||
| 6. Extending RFC 4291 | ||||
| YATT extends the IPv6 Addressing Architecture [IPv6-ADDRESSING] to | ||||
| add the capability for a host to recognize an special IPv6 format as | ||||
| an YATT address embedding a YADA address and process it accordingly. | ||||
| This is achieved in particular by the allocation of a YATT space that | ||||
| is a short prefix for all YATT prefixes, and a YATT-IID. | ||||
| 7. Extending RFC 8415 | ||||
| The DHCPv6 prefix delegation mechanism in Dynamic Host Configuration | ||||
| Protocol for IPv6 [RFC8415] is extended to delegate YATT prefixes to | ||||
| the hosts by enforcing that a delegated YATT prefix is provided in | ||||
| the form defined by Section 6. | ||||
| 8. YADA | ||||
| YADA assigns IPv4 prefixes to a multinternet shaft; those prefixes | YADA assigns IPv4 prefixes to a multinternet shaft; those prefixes | |||
| must be the same across all the realms that are interconnected by the | must be the same across all the realms that are interconnected by the | |||
| shaft. Multiple prefixes can be assigned to the shaft for unicast | shaft. Multiple prefixes can be assigned to the shaft for unicast | |||
| and multicast communications, and each realm needs at least one | and multicast communications, and each realm needs at least one | |||
| unicast address in the shaft called its realm address. A YADA | unicast address in the shaft called its realm address. A YADA | |||
| address is formed by the tuple (realm address, IPv4 address) and is | address is formed by the tuple (realm address, IPv4 address) and is | |||
| advertised in DNS as a new double-A record. Because the YADA | advertised in DNS as a new double-A record. Because the YADA | |||
| prefixes are assigned for YADA, a packet that has either source or | prefixes are assigned for YADA, a packet that has either source or | |||
| destination IPV4 address derived from a shaft prefix is a YADA | destination IPV4 address derived from a shaft prefix is a YADA | |||
| skipping to change at page 9, line 17 ¶ | skipping to change at page 9, line 6 ¶ | |||
| YADA leverages IP-in-IP encapsulation to tunnel packets across the | YADA leverages IP-in-IP encapsulation to tunnel packets across the | |||
| shaft for inter-realm communications, while the IPv4 operations | shaft for inter-realm communications, while the IPv4 operations | |||
| within a realm are unaffected. The YADA address is found by using | within a realm are unaffected. The YADA address is found by using | |||
| both inner and outer header and combining that information. The pair | both inner and outer header and combining that information. The pair | |||
| of IP headers is seen by a YADA stack as a single larger header | of IP headers is seen by a YADA stack as a single larger header | |||
| though a non-YADA forwarder only needs the outer header and plain | though a non-YADA forwarder only needs the outer header and plain | |||
| IPv4 operations on the outer IPv4 header to forward. | IPv4 operations on the outer IPv4 header to forward. | |||
| YADA requires a change in the stack in the YADA endpoints that | YADA requires a change in the stack in the YADA endpoints that | |||
| communicate with other realms to support the YADA encapsulation. | communicate with other realms to support the YADA encapsulation. A | |||
| YADA also provides a bump in the stack method for legacy | stack that resolve a DNS name with a double-A record indicating a | |||
| applications. A stack that resolve a DNS name with a double-A record | different realm generates an IP-in-IP packet to signal both the | |||
| indicating a different realm generates an IP-in-IP packet to signal | source and destination realms and the source and destination IPv4 | |||
| both the source and destination realms and the source and destination | addresses within the respective realms. | |||
| IPv4 addresses within the respective realms. | ||||
| Inside the source realm, the outer IPv4 header indicates the node's | Inside the source realm, the outer IPv4 header indicates the node's | |||
| IPv4 address as source, to remain topologically correct, and the | IPv4 address as source, to remain topologically correct, and the | |||
| local realm address as source in the inner header, as shown in | local realm address as source in the inner header, as shown in | |||
| Figure 2 | Figure 2 | |||
| <----------------------------- 20 bytes ----------------------------> | <----------------------------- 20 bytes ----------------------------> | |||
| +------------ ... ------------+-----------------+-------------------+ | +------------ ... ------------+-----------------+-------------------+ | |||
| | IPv4 header fields | Source node | destination realm | | | IPv4 header fields | Source node | destination realm | | |||
| | (outer) | IPv4 Address | IPv4 Address | | | (outer) | IPv4 Address | IPv4 Address | | |||
| skipping to change at page 10, line 29 ¶ | skipping to change at page 10, line 12 ¶ | |||
| does not defeat BCP 38 rules in the ISP network, as shown in | does not defeat BCP 38 rules in the ISP network, as shown in | |||
| Figure 3. | Figure 3. | |||
| | | | | | | |||
| /------|------------|--------------------------------- | /------|------------|--------------------------------- | |||
| / | | / | / | | / | |||
| / | | | | / | / | | | | / | |||
| / | |--------|---| Source Node / | / | |--------|---| Source Node / | |||
| / | / | / / | / | / | / / | |||
| / | /. <--|---- outer(src=src-addr / | / | /. <--|---- outer(src=src-addr / | |||
| / |/ . |/ . dst=dst-realm) / | / |/ . |/ . dst=dst-realm) / | |||
| / |------------| . inner(src=src-realm / | / |------------| . inner(src=src-realm / | |||
| / . . . . dst=dst-addr) / | / . . . . dst=dst-addr) / | |||
| / . . . . / | / . . . . / | |||
| / . . . . / | / . . . . / | |||
| -----------------------------------------------------/ | -----------------------------------------------------/ | |||
| | | | | | | | | |||
| | | | | | | |||
| | | | | | | |||
| Figure 3: Packets Entering the shaft | Figure 3: Packets Entering the shaft | |||
| When the packet reaches the shaft, the router that serves the shaft | When the packet reaches the shaft, the router that serves the shaft | |||
| swaps the inner and outer source IPv4 address, so the packet remains | in this realm checks that packet source in the inner header is an | |||
| topologically correct inside the shaft, as shown in Figure 4. | address of this realm, and if so, it swaps the inner and outer source | |||
| IPv4 address, and forwards the packet down the shaft. this way, the | ||||
| the packet remains topologically correct inside the shaft, as shown | ||||
| in Figure 4. | ||||
| <----------------------------- 20 bytes ----------------------------> | <----------------------------- 20 bytes ----------------------------> | |||
| +------------ ... ------------+-----------------+-------------------+ | +------------ ... ------------+-----------------+-------------------+ | |||
| | IPv4 header fields | Source realm | destination realm | | | IPv4 header fields | Source realm | destination realm | | |||
| | (outer) | IPv4 Address | IPv4 Address | | | (outer) | IPv4 Address | IPv4 Address | | |||
| +------------ ... ------------+-----------------+-------------------+ | +------------ ... ------------+-----------------+-------------------+ | |||
| | IPv4 header fields | Source node | destination node | | | IPv4 header fields | Source node | destination node | | |||
| | (inner) | IPv4 Address | IPv4 Address | | | (inner) | IPv4 Address | IPv4 Address | | |||
| +------------ ... ------------+-----------------+-------------------+ | +------------ ... ------------+-----------------+-------------------+ | |||
| . Options . | . Options . | |||
| skipping to change at page 11, line 31 ¶ | skipping to change at page 11, line 10 ¶ | |||
| Based on longest match, the router forwards the packet inside the | Based on longest match, the router forwards the packet inside the | |||
| shaft following the host route to a router that serves the | shaft following the host route to a router that serves the | |||
| destination realm, as shown in Figure 5. | destination realm, as shown in Figure 5. | |||
| | | | | | | |||
| /------|------------|--------------------------------- | /------|------------|--------------------------------- | |||
| / | | / | / | | / | |||
| / | | | | / | / | | | | / | |||
| / | |--------|---| Source Node / | / | |--------|---| Source Node / | |||
| / | / | / / | / | / | /. / | |||
| / | /. + | / outer(src=src-realm / | / | /. +- | / . outer(src=src-realm / | |||
| / |/ . | |/ . dst=dst-realm) / | / |/ . | |/ . dst=dst-realm) / | |||
| / |------------| . inner(src=src-addr / | / |------------| . inner(src=src-addr / | |||
| / . . | . . dst=dst-addr) / | / . . | . . dst=dst-addr) / | |||
| / . . | . . / | / . . | . . / | |||
| / . . | . . / | / . . | . . / | |||
| -----------------------------------------------------/ | -----------------------------------------------------/ | |||
| | | | | | | | | | | |||
| | | | forwarded unchanged | | | | | |||
| | | | down the shaft | | | | Sources swapped at shaft ingress | |||
| v | v | |||
| Figure 5: Packets Entering the shaft | Figure 5: Packets Entering the shaft | |||
| That router swaps the destination address in the inner and outer | That router swaps the destination address in the inner and outer | |||
| headers and forwards within its realm to the final destination, as | headers and forwards within its realm to the final destination, as | |||
| shown in Figure 6. | shown in Figure 6. | |||
| <----------------------------- 20 bytes ----------------------------> | <----------------------------- 20 bytes ----------------------------> | |||
| +------------ ... ------------+-----------------+-------------------+ | +------------ ... ------------+-----------------+-------------------+ | |||
| skipping to change at page 12, line 25 ¶ | skipping to change at page 12, line 5 ¶ | |||
| | | | | | | |||
| . Data . | . Data . | |||
| | | | | | | |||
| +-------------------------------------------------------------------+ | +-------------------------------------------------------------------+ | |||
| Figure 6: YADA format in the destination realm | Figure 6: YADA format in the destination realm | |||
| In normal conditions, the stack of the destination node recognizes | In normal conditions, the stack of the destination node recognizes | |||
| the YADA format and replies accordingly. | the YADA format and replies accordingly. | |||
| | | | | | |||
| | | | | | | | |||
| | | | | /------|------------|--------------------------------- | |||
| /------|----|-------|--------------------------------- | / | | | | / | |||
| / | | | | | / | ||||
| / | | | | | / | / | | | | | / | |||
| / | |----|---|---| Destination Node / | / | |----|---|---| Destination Node / | |||
| / | / | | / / | / | / | | /. / | |||
| / | /. +---|----> outer(src=src-realm / | / | /. +---|----> outer(src=src-realm / | |||
| / |/ . |/ . dst=dst-addr) / | / |/ . |/ . dst=dst-addr) / | |||
| / |------------| . inner(src=src-addr / | / |------------| . inner(src=src-addr / | |||
| / . . . . dst=realm-addr) / | / . . . . dst=realm-addr) / | |||
| / . . . . / | / . . . . / | |||
| / . . . . / | / . . . . / | |||
| -----------------------------------------------------/ | -----------------------------------------------------/ | |||
| destinations swapped at shaft egress | destinations swapped at shaft egress | |||
| Figure 7: Packets Outgoing the shaft | Figure 7: Packets Outgoing the shaft | |||
| In case of an error down the shaft or in the destination realm, if an | In case of an error down the shaft or in the destination realm, if an | |||
| ICMP message is generated by a node that is not YADA-aware, the | ICMP message is generated by a node that is not YADA-aware, the | |||
| message reaches the router that serves the shaft in the source realm. | message reaches the router that serves the shaft in the source realm. | |||
| If the inner header is present in the ICMP payload, then the Router | If the inner header is present in the ICMP payload, then the Router | |||
| extracts it and forwards to the packet source. If the destination | extracts it and forwards to the packet source. If the destination | |||
| stack does not support YADA and decapsulates, the message reaches the | stack does not support YADA and decapsulates, the message reaches the | |||
| router that serves the destination realm which logs and drops. based | router that serves the destination realm which logs and drops. based | |||
| on the log, the node may be updated, or the DNS records may be fixed | on the log, the node may be updated, or the DNS records may be fixed | |||
| to avoid pointing on a node that does not support YADA. | to avoid pointing on a node that does not support YADA. | |||
| YADA requires the assignment of a second IPv4 prefix, this time for a | ||||
| internal NATing operation. A bump-in-the-stack intercepts the DNS | ||||
| lookups, and when the response yields a double-A record with a | ||||
| foreign realm, the record is augmented with an IPv4 address taken | ||||
| from a local NAT pool. When the stack sends a packet to that | ||||
| particular address, the bump-in-the-stack translates to the YADA | ||||
| format, using the information in the double-A record for the | ||||
| destination, and the local realm as source realm. The other way | ||||
| around, if a packet arrives with a YADA format but the stack does not | ||||
| support it, the bump-in-the-stack allocates an address from the pool, | ||||
| and NATs to IPv4 using that address as source. | ||||
| YADA was initially published as USPTO 7,356,031, filed in February | YADA was initially published as USPTO 7,356,031, filed in February | |||
| 2002. | 2002. | |||
| 7. YATT | 9. YADA Stateful NAT | |||
| Inside a realm, a YADA stack falls back to classical IPv4 operations | ||||
| and will natively connects to any legacy IPv4 peers. To reach YADA | ||||
| nodes in alternate realms, YADA also provides a stateful NAT | ||||
| operation that performs an IPv4-to-YADA translation below the legacy | ||||
| stack. The translation reuses some prefix space allocated for either | ||||
| [RFC1918] or [RFC6598] for a local NAT pool that is used to present a | ||||
| single address to the legacy stack. | ||||
| The YADA formulation couples a realm address with a public IPv4 | ||||
| address. A host that owns a public address may perform the YADA | ||||
| stateful NAT operation as a bump-in-the-stack below the legacy stack. | ||||
| In a private network, the operation is preferably done in the private | ||||
| gateway, outside the existing private-public NAT so it operates on | ||||
| the resulting public address, to keep the classical NAT operation as | ||||
| is. | ||||
| +-------------+ | ||||
| | | | ||||
| | | +-------------+ | ||||
| +-------------+ | address | | ||||
| | IPv4 | | pool | | ||||
| | stack | +-------------+ | ||||
| +-------------+ +------------------------+ | ||||
| | | | bump in stack stateful | | ||||
| | | | IPv4 -> YADA NAT | | ||||
| +-----+-------+ +--------------------+---+ | ||||
| | ^ | | ||||
| v | v | ||||
| +---------------+------+--------+ +-------------------------------+ | ||||
| | src=this_node | dst=from_pool | | src=this_node | dst=dst-realm | | ||||
| +---------------+---------------+ +---------------+---------------+ | ||||
| | | |src=this_realm |dst=destination| | ||||
| | | +---------------+---------------+ | ||||
| | | | | | ||||
| | IP PAYLOAD | | | | ||||
| | | | | | ||||
| | | | IP PAYLOAD | | ||||
| | | | | | ||||
| +-------------------------------+ | | | ||||
| | | | ||||
| +----------------+--------------+ | ||||
| | | ||||
| V | ||||
| Figure 8: YADA Stateful NAT | ||||
| The stateful NAT intercepts the DNS lookups. If the response | ||||
| contains an A record, then the address is reachable in the local | ||||
| realm and the NAT ignores that destination, letting the legacy | ||||
| operations take place transparently. | ||||
| When the response yields a double-A record with a foreign realm, the | ||||
| stateful NAT allocates an IPv4 address from the local NAT pool and | ||||
| adds it in an A record to the DNS response. A local NAT state is | ||||
| built, indexed by the double-A outside and the allocated single-A | ||||
| inside. | ||||
| When the legacy stack pushes a packet to that particular address, the | ||||
| stateful NAT translates to the YADA format, using the information in | ||||
| the double-A record for the destination, and the local realm as | ||||
| source realm. | ||||
| The other way around, if a packet arrives in the YADA formulation | ||||
| from a different realm, the stateful NAT allocates an address from | ||||
| the pool, and NATs to classical IPv4 using that address as source. | ||||
| As an optimization, a NAT in a private gateway may learn which nodes | ||||
| inside support YADA and bypass the YADA stateful NAT operation | ||||
| completely for those nodes. | ||||
| As long at the bump-in-the-stack (or the gateway) generates YADA | ||||
| packets, the packets can be translated statelessly to YATT as a last | ||||
| bump-in-the-stack operation before transmission to be pushed on an | ||||
| IPv6-only link. | ||||
| The YATT and YADA formulations refer to the same object. A node that | ||||
| is configured with a YATT address is de facto owner of the embedded | ||||
| IPv4 address within the embedded IPv4 realm, and that address can be | ||||
| used to install a legacy IPv4 stack even if the attachement link is | ||||
| pure IPv6. As long at the stack generates YADA packets, the packets | ||||
| can be translated statelessly to YATT as a next bump-in-the-stack | ||||
| operation before transmission and placed on the IPv6-only network. | ||||
| 10. YATT | ||||
| A second mechanism called YATT translates the YADA format into flat | A second mechanism called YATT translates the YADA format into flat | |||
| IPv6. | IPv6. | |||
| +-----+---------------+--------------+-----------------------------+ | +-----+---------------+--------------+-----------------------------+ | |||
| |YATT | Realm | IPv4 | Well-Known | | |YATT | Realm | IPv4 | Well-Known | | |||
| |Space| Address | Address | IID | | |Space| Address | Address | IID | | |||
| +-----+- -------------+--------------+-----------------------------+ | +-----+- -------------+--------------+-----------------------------+ | |||
| <- YADA | <- YADA | |||
| prefix -> | prefix -> | |||
| <-------- YATT prefix ----------> | <-------- YATT prefix ----------> | |||
| Figure 8: YATT format | Figure 9: YATT format | |||
| For unicast addresses, YATT forms an IPv6 prefix by collating an | For unicast addresses, YATT forms an IPv6 prefix by collating an | |||
| well-known assigned short prefix called the YATT space, the realm | well-known assigned short prefix called the YATT space, the realm | |||
| address, and the host IPv4 address (locally significant within the | address, and the host IPv4 address (locally significant within the | |||
| realm). The resulting IPv6 prefix is automatically owned by the host | realm). The resulting IPv6 prefix is automatically owned by the host | |||
| that owns the IPv4 address in the realm. | that owns the IPv4 address in the realm. | |||
| Depending on assignment, the leftmost piece realm prefix may be | Depending on assignment, the leftmost piece realm prefix may be | |||
| truncated if it is well-known, to allow the YATT space and the realm | truncated if it is well-known, to allow the YATT space and the realm | |||
| address to fit in a 32-bit DWORD. This way, the YATT prefix can be a | address to fit in a 32-bit DWORD. This way, the YATT prefix can be a | |||
| skipping to change at page 14, line 26 ¶ | skipping to change at page 15, line 26 ¶ | |||
| YADA prefix is 240.0.0.0/6. In that case the values perfectly | YADA prefix is 240.0.0.0/6. In that case the values perfectly | |||
| overlap and the YATT format becomes as follows: | overlap and the YATT format becomes as follows: | |||
| +-----+----------+----------------+---------------------------------+ | +-----+----------+----------------+---------------------------------+ | |||
| | Realm Address | IPv4 Host | Well-Known | | | Realm Address | IPv4 Host | Well-Known | | |||
| | in 240.0.0.0/6 | Public Address | IID | | | in 240.0.0.0/6 | Public Address | IID | | |||
| +-----+- --------+----+-----------+---------------------------------+ | +-----+- --------+----+-----------+---------------------------------+ | |||
| <--- 32 bits ---><--- 32 bits ---><------------ 64 bits ------------> | <--- 32 bits ---><--- 32 bits ---><------------ 64 bits ------------> | |||
| <------ YATT IPv6 prefix -------> | <------ YATT IPv6 prefix -------> | |||
| Figure 9: YATT format using 240.0.0.0/6 | Figure 10: YATT format using 240.0.0.0/6 | |||
| In that case, the NAT operation is a plain insertion. Depending on | In that case, the NAT operation is a plain insertion. Depending on | |||
| the assignment, it might be that the Realm address must be placed in | the assignment, it might be that the Realm address must be placed in | |||
| full after YATT space. In that case, the length of the YATT prefix | full after YATT space. In that case, the length of the YATT prefix | |||
| will be more than 64 bits. | will be more than 64 bits. | |||
| Also, since 240.0.0.0/6 is currently unassigned, using it for the | Also, since 240.0.0.0/6 is currently unassigned, using it for the | |||
| shaft would allow literally to reuse every ASN and every IPv4 address | shaft would allow literally to reuse every ASN and every IPv4 address | |||
| currently available in the Internet in each and every other realm and | currently available in the Internet in each and every other realm and | |||
| reallocate them in any fashion desirable in that realm. | reallocate them in any fashion desirable in that realm. | |||
| skipping to change at page 15, line 5 ¶ | skipping to change at page 16, line 5 ¶ | |||
| YADA realm prefix in both IPv4 and YATT forms. | YADA realm prefix in both IPv4 and YATT forms. | |||
| If the network is IPv4 only, the packets are still generated using | If the network is IPv4 only, the packets are still generated using | |||
| IP-in-IP, and the YATT NAT operation may happen at the router that | IP-in-IP, and the YATT NAT operation may happen at the router that | |||
| delivers the packet in the destination realm, if it is v6-only, or in | delivers the packet in the destination realm, if it is v6-only, or in | |||
| the destination host, if its stack is v6-only. | the destination host, if its stack is v6-only. | |||
| YATT was initially published as USPTO 7,764,686, filed in December | YATT was initially published as USPTO 7,764,686, filed in December | |||
| 2002. | 2002. | |||
| 8. The structure of the shaft | 11. YATT Stateful PAT | |||
| The YATT and YADA formulations refer to the same object. A node that | ||||
| is the owner of a public address in a realm is de facto owner of the | ||||
| matching YATT prefix, and is de facto assigned the IPv6 address | ||||
| derived with the YATT-IID. The other way around, a node that is | ||||
| delegated a YATT prefix is de facto owner of the embedded IPv4 | ||||
| address within the embedded IPv4 realm. | ||||
| In an IPv4-only environment, a YATT stack may obtain a YADA address | ||||
| pair from DHCPv4 (see Section 5), derive a YATT prefix, and use it to | ||||
| configure the local IPv6 stack. As long at the stack generates YATT | ||||
| packets, the packets can be translated statelessly to YADA as a last | ||||
| bump-in-the-stack operation before transmission. In that model, | ||||
| lower-layer protocols such as ARP and DHCP must be supported, but the | ||||
| IP stack can be IPv6-only. | ||||
| In that case, the node shows as a YADA node, and may talk to a legacy | ||||
| IPv4 stack in a remote realm if the legacy that supports the YADA | ||||
| stateful translation. This combination of stateful PAT after the | ||||
| IPv6 stack and stateful NAT after the IPv4 stack allow the 2 stacks | ||||
| to communicate in the YADA/YATT formulations, and traverse IPv4-only | ||||
| and IPv6-only links using the appropriate formulation. | ||||
| The YATT node may use the YATT prefix to autoconfigure addresses, or | ||||
| it may offer it on an IPv6 stub (tethered) network for address | ||||
| autoconfiguration by attached nodes, protecting the addresses that it | ||||
| keeps for itself using in the DAD procedure. Addresses that are not | ||||
| derived from the YATT-IID will be reachable from IPv6 nodes over an | ||||
| IPv6 network, but not from YADA node, and not over IPv4-only links. | ||||
| To reach YADA nodes and traverse IPv4, the YATT node may leverage a | ||||
| stateful Port Address Translation (PAT) to transform the original IID | ||||
| in the YATT-IID outside. The stateful PAT operation can happen as a | ||||
| bump-in-the-stack before the YATT-to-YADA stateless translation. | ||||
| +-------------+ | ||||
| | | | ||||
| | | +----------+ | ||||
| +-------------+ | port | | ||||
| | IPv6 | | pool | | ||||
| | stack | +----------+ | ||||
| +-------------+ +------------------------+ | ||||
| | | | bump in stack stateful | | ||||
| | | | IPv6 -> YATT PAT | | ||||
| +-----+-------+ +--------------------+---+ | ||||
| | ^ | | ||||
| v | v | ||||
| +----------------------+--------+ +-------------------------------+ | ||||
| | src_prefix (YATT) ; IID = any | | src_prefix ; IID = YATT-IID | | ||||
| +-------------------------------+ +-------------------------------+ | ||||
| | dst (other YATT address) | | dst | | ||||
| +-------------------------------+ +-------------------------------+ | ||||
| +-------------------------------+ +-------------------------------+ | ||||
| | srcport = Selected ; dport | | srcport = Translated ; dport | | ||||
| +-------------------------------+ +-------------------------------+ | ||||
| | | | | | ||||
| | | | | | ||||
| | | | | | ||||
| | IP PAYLOAD | | IP PAYLOAD | | ||||
| | | | | | ||||
| | | | | | ||||
| | | | | | ||||
| +-------------------------------+ +---------------+---------------+ | ||||
| | | ||||
| V | ||||
| Figure 11: YATT Stateful PAT | ||||
| 12. The structure of the shaft | ||||
| A 10 miles view of the shaft could be as follows: it is implemented | A 10 miles view of the shaft could be as follows: it is implemented | |||
| in one IXP, spans all realms, and each realm has one address in the | in one IXP, spans all realms, and each realm has one address in the | |||
| shaft, with one router serving that realm. The address of the realm | shaft, with one router serving that realm. The address of the realm | |||
| is encoded in a loopback in the router, and advertised through an IGP | is encoded in a loopback in the router, and advertised through an IGP | |||
| inside the shaft, while BGP is used inside the realms but not inside | inside the shaft, while BGP is used inside the realms but not inside | |||
| the shaft. The shaft has a single large prefix that is advertised in | the shaft. The shaft has a single large prefix that is advertised in | |||
| each realm by the router that serves the shaft, and that is | each realm by the router that serves the shaft, and that is | |||
| disaggregated into host routes inside the shaft. | disaggregated into host routes inside the shaft. | |||
| None of the above is expected to remain true for long. As YADA and | None of the above is expected to remain true for long. As YADA and | |||
| YATT get deployed, the shaft will be implemented in different sites | YATT get deployed, the shaft will be implemented in different sites | |||
| over the world. A realm may be multihomed to be reached from a | over the world. A realm may be multihomed to be reached from a | |||
| different physical instance of the shaft, meaning that the shaft is | different physical instance of the shaft, meaning that the shaft is | |||
| composed of either more prefixes or the shaft prefix is | composed of either more prefixes or the shaft prefix is | |||
| disaggregated. Multiple routers will serve the same realm with high | disaggregated. Multiple routers will serve the same realm with high | |||
| availability and load balancing taking place inside the shaft to | availability and load balancing taking place inside the shaft to | |||
| maintain connectivity. Some shafts may be deployed to interconnect | maintain connectivity. A private shaft may be deployed to | |||
| only a subset of the realms, in which case those shafts would share a | interconnect a subset of the realms, in which case the shaft would | |||
| specific prefix that would not be advertised outside the concerned | use a specific prefix that would not be advertised outside the | |||
| realms. | concerned realms. | |||
| 9. Applicability | 13. Applicability | |||
| YADA And YATT enable communication between YADA-enabled IPv4 nodes | YADA And YATT enable communication between YADA-enabled IPv4 nodes | |||
| across realms, and with IPv6 nodes that own a YADA address from which | across realms, and with IPv6 nodes that own a YADA address from which | |||
| a YATT address can be derived. Communication from a legacy IPv4 | a YATT address can be derived. Communication from a legacy IPv4 | |||
| application/stack that is not YADA-enabled, or to an IPv6 address | application/stack that is not YADA-enabled, or to an IPv6 address | |||
| that is not a YATT address, is not provided. | that is not a YATT address, is not provided. | |||
| Since the YATT translation is stateless, the header translation can | Since the YATT translation is stateless, the header translation can | |||
| happen anywhere in the network, e.g., as a bump in the stack at | happen anywhere in the network, e.g., as a bump in the stack at | |||
| either end, or within the network, e.g., at the routers that serve | either end, or within the network, e.g., at the routers that serve | |||
| the realms on the shaft. The shaft itself is expected to be dual | the realms on the shaft. The shaft itself is expected to be dual | |||
| stack to forward packets in their native form, either v4 or v6. | stack to forward packets in their native form, either v4 or v6. | |||
| For a legacy IPv4 node to communicate with YADA-enabled IPv4 node in | For a legacy IPv4 node to communicate with YADA-enabled IPv4 node in | |||
| another realm, a NAT operation similar to NAT46 [NAT-DEPLOY], but | another realm, a NAT operation similar to NAT46 [NAT-DEPLOY], but | |||
| between IPv4 and YADA addresses, is required. The same would be | between IPv4 and YADA addresses, is required. The same would be | |||
| required to allow an IPv4-only YADA node to communicate with an IPv6 | required to allow an IPv4-only YADA node to communicate with an IPv6 | |||
| node a a non-YATT address. | node a non-YATT address. | |||
| In summary: | In summary: | |||
| * this specification does not allow any IPv4 legacy node to talk to | * this specification does not allow any IPv4 legacy node to talk to | |||
| any pure IPv6 node, and recognizes that this Graal may actually be | any pure IPv6 node, and recognizes that this Graal may actually be | |||
| a non-goal. | a non-goal. | |||
| * With YADA the current IPv4 Internet operations are not affected | * With YADA the current IPv4 Internet operations within a realm are | |||
| not mostly unaffected, though additional provisionning is needed | ||||
| for routing and security purposes | ||||
| * YADA extends the IPv4-reachable world by creating (millions of) | * YADA extends the IPv4-reachable world by creating (millions of) | |||
| parallel realms and changing (only) the stack on the hosts that | parallel realms | |||
| require inter-realm communication and specific routers at the | ||||
| ingress of the realms | * The stack on IPv4 hosts that require inter-realm communication | |||
| must be upgraded at least with a bump, though the function may be | ||||
| deported to the private gateway | ||||
| * A new functionality is needed in specific routers at the ingress | ||||
| of the realms and at the border to a single-version domain for NAT | ||||
| operation | ||||
| * A YADA node can talk (using IPv4) to a YATT node (using IPv6) with | * A YADA node can talk (using IPv4) to a YATT node (using IPv6) with | |||
| a stateless translation. The translation can happen anywhere in | a stateless translation. The translation can happen anywhere in | |||
| the network or in the stack. | the network or in the stack. | |||
| * a YATT node being an IPv6 can talk to any other IPv6 nodes. | 14. Backwards Compatibility | |||
| 10. Backwards Compatibility | ||||
| YADA operation does not affect the intra-realm communication. The | YADA operation does not affect the intra-realm communication. The | |||
| only affected stacks are the endpoints that communicate between | only affected stacks are the endpoints that communicate between | |||
| realms leveraging YADA. | realms leveraging YADA. | |||
| 11. Security Considerations | 15. Security Considerations | |||
| YADA introduces an IP-in-IP format that might be used to obfuscate an | YADA introduces an IP-in-IP format that might be used to obfuscate an | |||
| IP address impersonation performed in the inner header. A proper | IP address impersonation performed in the inner header. A proper | |||
| implemetation of BCP 38 should thus include the capability to | implemetation of BCP 38 should thus include the capability to | |||
| recognize a YADA format and look in the source IP field that | recognize a YADA format and allow the source IP address in the inner | |||
| expresses the source realm in the inner header. | header to be set to the local realm. | |||
| Upgrading the rules in his Broadband Network Gateways (BNGs) | Before the router that serves the realm swaps the source address to | |||
| represents additional work for an ISP, which should be done before | place a YADA packet in the shaft, it MUST ensure that the realm | |||
| the shaft addresses are routable within the ISP network, and whether | address in the inner header matches this realm. Otherwise it MUST | |||
| the ISP intends to provide improved NAT functions in the home | drop the packet and MAY generate and ICMP Error message back to the | |||
| gateways and CPEs. | source, indicating the offset of the source IP address of the inner | |||
| header. | ||||
| 12. IANA Considerations | 16. IANA Considerations | |||
| This document requires the creation of a registry for IPv4 YADA realm | This document requires the creation of a registry for IPv4 YADA realm | |||
| prefixes, and the assignment of at least one YADA realm prefix. | prefixes, and the assignment of at least one YADA realm prefix. | |||
| This document requires the creation of a registry for IPv4 YADA NAT | This document requires the creation of a registry for IPv4 YADA NAT | |||
| prefixes, and the assignment of at least one YADA NAT prefix. | prefixes, and the assignment of at least one YADA NAT prefix. | |||
| This document requires the creation of a new record in the Resource | This document requires the creation of a new record in the Resource | |||
| Record (RR) TYPEs subregistry of the Domain Name System (DNS) | Record (RR) TYPEs subregistry of the Domain Name System (DNS) | |||
| Parameters. The new record would be of type AA meaning a YADA | Parameters. The new record would be of type AA meaning a YADA | |||
| address. | address. | |||
| 13. Acknowledgments | 17. Acknowledgments | |||
| The author wishes to recognize the pioneer work done by Brian | The author wishes to recognize the pioneer work done by Brian | |||
| carpenter in the space of IPv4 augmentation with | carpenter in the space of IPv4 augmentation with | |||
| [I-D.carpenter-aeiou] | [I-D.carpenter-aeiou] | |||
| The author wishes to thank Greg Skinner as the first reviewer/ | The author wishes to thank Greg Skinner as the first reviewer/ | |||
| contributor to this work. Also Dave Bell, to remind that even if | contributor to this work. Also Dave Bell, to remind that even if | |||
| routing is not touched much inside an IPv4 realm vs. the current art, | routing is not touched much inside an IPv4 realm vs. the current art, | |||
| there is still work for the ISP, e.g., update the BCP 38 rules in the | there might still be work for the ISP, e.g., update the BCP 38 rules | |||
| BNGs. | in the BNGs. | |||
| 14. References | 18. References | |||
| 14.1. Normative References | 18.1. Normative References | |||
| [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, | [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
| DOI 10.17487/RFC0791, September 1981, | DOI 10.17487/RFC0791, September 1981, | |||
| <https://www.rfc-editor.org/info/rfc791>. | <https://www.rfc-editor.org/info/rfc791>. | |||
| [INT-ARCHI] | [INT-ARCHI] | |||
| Braden, R., Ed., "Requirements for Internet Hosts - | Braden, R., Ed., "Requirements for Internet Hosts - | |||
| Communication Layers", STD 3, RFC 1122, | Communication Layers", STD 3, RFC 1122, | |||
| DOI 10.17487/RFC1122, October 1989, | DOI 10.17487/RFC1122, October 1989, | |||
| <https://www.rfc-editor.org/info/rfc1122>. | <https://www.rfc-editor.org/info/rfc1122>. | |||
| [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", | ||||
| RFC 2131, DOI 10.17487/RFC2131, March 1997, | ||||
| <https://www.rfc-editor.org/info/rfc2131>. | ||||
| [IPv6-ADDRESSING] | [IPv6-ADDRESSING] | |||
| Hinden, R. and S. Deering, "IP Version 6 Addressing | Hinden, R. and S. Deering, "IP Version 6 Addressing | |||
| Architecture", RFC 4291, DOI 10.17487/RFC4291, February | Architecture", RFC 4291, DOI 10.17487/RFC4291, February | |||
| 2006, <https://www.rfc-editor.org/info/rfc4291>. | 2006, <https://www.rfc-editor.org/info/rfc4291>. | |||
| [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
| (IPv6) Specification", STD 86, RFC 8200, | (IPv6) Specification", STD 86, RFC 8200, | |||
| DOI 10.17487/RFC8200, July 2017, | DOI 10.17487/RFC8200, July 2017, | |||
| <https://www.rfc-editor.org/info/rfc8200>. | <https://www.rfc-editor.org/info/rfc8200>. | |||
| 14.2. Informative References | [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., | |||
| Richardson, M., Jiang, S., Lemon, T., and T. Winters, | ||||
| "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", | ||||
| RFC 8415, DOI 10.17487/RFC8415, November 2018, | ||||
| <https://www.rfc-editor.org/info/rfc8415>. | ||||
| 18.2. Informative References | ||||
| [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. | ||||
| J., and E. Lear, "Address Allocation for Private | ||||
| Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, | ||||
| February 1996, <https://www.rfc-editor.org/info/rfc1918>. | ||||
| [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and | ||||
| M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address | ||||
| Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April | ||||
| 2012, <https://www.rfc-editor.org/info/rfc6598>. | ||||
| [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: | ||||
| Combination of Stateful and Stateless Translation", | ||||
| RFC 6877, DOI 10.17487/RFC6877, April 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6877>. | ||||
| [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. | ||||
| Korhonen, "Requirements for Distributed Mobility | ||||
| Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, | ||||
| <https://www.rfc-editor.org/info/rfc7333>. | ||||
| [NAT-DEPLOY] | [NAT-DEPLOY] | |||
| Palet Martinez, J., "Additional Deployment Guidelines for | Palet Martinez, J., "Additional Deployment Guidelines for | |||
| NAT64/464XLAT in Operator and Enterprise Networks", | NAT64/464XLAT in Operator and Enterprise Networks", | |||
| RFC 8683, DOI 10.17487/RFC8683, November 2019, | RFC 8683, DOI 10.17487/RFC8683, November 2019, | |||
| <https://www.rfc-editor.org/info/rfc8683>. | <https://www.rfc-editor.org/info/rfc8683>. | |||
| [I-D.carpenter-aeiou] | [I-D.carpenter-aeiou] | |||
| Carpenter, B. E., "Address Extension by IP Option Usage | Carpenter, B. E., "Address Extension by IP Option Usage | |||
| (AEIOU)", Work in Progress, Internet-Draft, draft- | (AEIOU)", Work in Progress, Internet-Draft, draft- | |||
| End of changes. 52 change blocks. | ||||
| 154 lines changed or deleted | 344 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||