< draft-thubert-v6ops-yada-yatt-01.txt   draft-thubert-v6ops-yada-yatt-02.txt >
v6ops P. Thubert, Ed. v6ops P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 1122, 4291 (if approved) 29 March 2022 Updates: 1122, 4291 (if approved) 5 April 2022
Intended status: Informational Intended status: Informational
Expires: 30 September 2022 Expires: 7 October 2022
Yet Another Double Address and Translation Technique Yet Another Double Address and Translation Technique
draft-thubert-v6ops-yada-yatt-01 draft-thubert-v6ops-yada-yatt-02
Abstract Abstract
This document provides a mechanism named YADA to extend the current This document provides a mechanism named YADA to extend the current
IPv4 Internet by interconnecting IPv4 realms via a common footprint IPv4 Internet by interconnecting IPv4 realms via a common footprint
called the shaft. YADA extends [INT-ARCHI] with the support of an called the shaft. YADA extends [INT-ARCHI] with the support of an
IP-in-IP format used to tunnel packets across the shaft. This IP-in-IP format used to tunnel packets across the shaft. This
document also provides a bump-in-the-stack method to enable YADA on a document also provides a bump-in-the-stack method to enable YADA on a
legacy stack, e.g., to enable virtual machines without changing them. legacy stack, e.g., to enable virtual machines without changing them.
This document also provides a stateless address and IP header This document also provides a stateless address and IP header
translation between YADA and IPv6 [IPv6] called YATT and extends translation between YADA and IPv6 [IPv6] called YATT and extends
[IPv6-ADDRESSING] for the YATT format. YATT can take place as a bump [IPv6-ADDRESSING] for the YATT format. YADA and YATT can take place
in the stack at either end, or within the network and enables an as a bump in the stack at either end, or within the network and
IPv6-only stack to dialog with an IPv4-only stack across a network enables an IPv6-only stack to dialog with an IPv4-only stack across a
that can be IPv6, IPv4, or mixed. YATT requires that the IPv6 stack network that can be IPv6, IPv4, or mixed. YATT requires that the
owns a prefix that derives from a YADA address and the IPv4 stack is IPv6 stack owns a prefix that derives from a YADA address and the
capable of YADA, so it does not replace a generic 4 to 6 translation IPv4 stack is capable of YADA, so it does not replace a generic 4 to
mechanism for any v6 to any v4. 6 translation mechanism for any v6 to any v4.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 30 September 2022. This Internet-Draft will expire on 7 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Extending RFC 1122 . . . . . . . . . . . . . . . . . . . . . 5 3. Extending RFC 1122 . . . . . . . . . . . . . . . . . . . . . 6
4. Extending RFC 4291 . . . . . . . . . . . . . . . . . . . . . 5 4. Extending RFC 4291 . . . . . . . . . . . . . . . . . . . . . 6
5. YADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. YADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. YATT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. YATT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 7. The structure of the shaft . . . . . . . . . . . . . . . . . 11
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document provides a mechanism called Yet Another Double Address This document defines baby steps from an IPv4-only stack/gateway/ISP
(YADA) to grow the Internet beyond the current IPv4 [IPv4] realm that to an IPv6-only version. The goal is to end with dual stack and
limits its capacity to form public addresses. This is achieved by Carrier-Grade Network Address Translators (CG-NATs). The first step
interconnecting IPv4 realms via a common footprint called the shaft. called Yet Another Double Address (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
the current IPv4 [IPv4] realm that limits its capacity to form public
addresses. Depending on the assignments to be made, the model allows
to reuse all IP addresses and all Autonomous System Number (ASN)
currently available in the internet hundreds to millions of times.
This is achieved by interconnecting IPv4 realms via a common
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,
and each additional floor would be another IPv4 realm. The same and each additional floor would be another IPv4 realm. The same
surface of floor is available in each level, analog to the full IPv4 surface of floor is available in each level, analog to the full IPv4
addressing that is available in each realm. The same footprint is addressing that is available in each realm. The same footprint is
dedicated across the building levels for the elevator shaft. The dedicated across the building levels for the elevator shaft. The
elevator shaft enables a third dimension that spans across the levels elevator shaft enables a third dimension that spans across the levels
and allows to traverse from any level to any other level. The and allows to traverse from any level to any other level. The
elevator shaft cannot be used for living or office space. elevator shaft cannot be used for living or office space.
skipping to change at page 4, line 29 skipping to change at page 5, line 19
translates the YADA format into flat IPv6 [IPv6]. For unicast translates the YADA format into flat IPv6 [IPv6]. For unicast
addresses, YATT forms an IPv6 prefix by collating an well-known addresses, YATT forms an IPv6 prefix by collating an well-known
assigned short prefix, the realm address (in the shaft), and the host assigned short prefix, the realm address (in the shaft), and the host
IPv4 address (locally significant within the realm). The resulting IPv4 address (locally significant within the realm). The resulting
IPv6 prefix is automatically owned by the host that owns the IPv4 IPv6 prefix is automatically owned by the host that owns the IPv4
address in the realm. YATT then forms an IPv6 address for that host address in the realm. YATT then forms an IPv6 address for that host
by collating a well-known Interface ID, so there's a one-to-one by collating a well-known Interface ID, so there's a one-to-one
relationship between the YADA and the IPv6 address derived from it. relationship between the YADA and the IPv6 address derived from it.
More in Section 6. More in Section 6.
A key concept for this specification is that YADA (the IPv4
formulation) and YATT (the IPv6 formulation) represent the same
thing. YADA uses IPv4 formats as plain IP-in-IP with no new
extension. YATT uses IPv6 format with the IPv4 addresses encoded on
the prefix. The formats are interchangeable, and a router can
convert one to another as the packet flows over a next-hop link that
can only carry the other address family.
2. Terminology 2. Terminology
2.1. Glossary 2.1. Glossary
This document often uses the following acronyms: This document often uses the following acronyms:
YADA: Yet Another Double Address YADA: Yet Another Double Address
YATT: Yet Another Translation Technique YATT: Yet Another Translation Technique
NAT: Network address Translation NAT: Network address Translation
IID: Interface ID IID: Interface ID
CG-NAT: Carrier Grade NAT CG-NAT: Carrier Grade NAT
2.2. New Terms 2.2. New Terms
This document often uses the following nex terms: This document often uses the following new terms:
IPv4 realm A full IPv4 network like the current Internet. YADA does IPv4 realm: A full IPv4 network like the current Internet. YADA
not affect the traditional IPv4 operations within a realm. does not affect the traditional IPv4 operations within a realm.
The shaft The shaft refers to a collection of IPv4 unicast and The shaft: The shaft refers to a collection of IPv4 unicast and
multicast prefixes that are assigned to Inter-realm communications multicast prefixes that are assigned to Inter-realm communications
and cannot be assigned to hosts or multicast groups within a and cannot be assigned to hosts or multicast groups within a
realm. realm.
realm address An IPv4 address that derives from a shaft prefix. Realm address: An IPv4 address that derives from a shaft prefix.
Uni-realm address A realm address that is unicast or anycast. A Uni-realm address: A realm address that is unicast or anycast. A
realm may have more than one Uni-realm address. realm may have more than one Uni-realm add ress.
Multi-realm address A realm address that is multicast and denotes a
Multi-realm address: A realm address that is multicast and denotes a
collection of realms. collection of realms.
YADA realm Prefix A Prefix assigned to the shaft and from which YADA realm prefix: A prefix assigned to the shaft and from which
realm addresses can be derived. realm addresses can be derived.
YADA NAT Prefix A Prefix assigned to the YADA bump-in-the-stack NAT YADA NAT prefix: A prefix assigned to the YADA bump-in-the-stack NAT
operation. operation.
Double-A or YADA address A YADA address is a tuple (realm address, Double-A or YADA address: A YADA address is a tuple (realm address,
IPv4 address) where the IPv4 address is only significant within IPv4 address) where the IPv4 address is only significant within
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. Extending RFC 1122 3. 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.
4. Extending RFC 4291 4. Extending RFC 4291
skipping to change at page 6, line 13 skipping to change at page 7, line 13
packet. packet.
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 to forward. IPv4 operations to forward.
<----------------------------- 20 bytes ---------------------------->
+------------ ... ------------+-----------------+-------------------+
| IPv4 header fields | Source realm | destination realm |
| | IPv4 Address | IPv4 Address |
+------------ ... ------------+-----------------+-------------------+
| IPv4 header fields | Source node | destination node |
| | IPv4 Address | IPv4 Address |
+------------ ... ------------+-----------------+-------------------+
. Options .
+------------ ... --------------------------------------------------+
| |
. Data .
| |
+-------------------------------------------------------------------+
Figure 2: YADA format in the source realm
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.
YADA also provides a bump in the stack method for legacy YADA also provides a bump in the stack method for legacy
applications. YADA also requires a change for the routers that serve applications. YADA also requires a change for the routers that serve
the shaft. Those routers play a special role for packets that are the shaft. Those routers play a special role for packets that are
delivered from the shaft to the destination realm, and for ICMP delivered from the shaft to the destination realm, and for ICMP
errors across realms. All other IPv4 nodes in the realm continue to errors across realms. All other IPv4 nodes in the realm continue to
operate as before. operate as before.
Routers serving the shaft advertise the shaft prefix(es) in their Routers serving the shaft advertise the shaft prefix(es) in their
respective realms, and their realm addresses within the shaft, as respective realms, and their realm addresses within the shaft, as
host routes for unicast and anycast addresses. A stack that resolve host routes for unicast and anycast addresses. A stack that resolve
a DNS name with a double-A record indicating a different realm a DNS name with a double-A record indicating a different realm
generates an IP-in-IP packet, with the outer header indicating the generates an IP-in-IP packet, with the outer header indicating the
source and destination realms, and the inner header indicating the source and destination realms, and the inner header indicating the
source and destination IPv4 addresses within the respective realms, source and destination IPv4 addresses within the respective realms,
as shown in Figure 2. The packet is forwarded down the shaft as is, as shown in Figure 3. The packet is forwarded down the shaft as is,
using the normal longest match or multicast operation. using the normal longest match or multicast operation.
| | | |
/------|------------|--------------------------------- /------|------------|---------------------------------
/ | | / / | | /
/ | | | | / / | | | | /
/ | |--------|---| 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
v v
Figure 2: Packets Entering the shaft Figure 3: Packets Entering the shaft
The packet destination is an address is the shaft and it is attracted The packet destination is an address is the shaft and it is attracted
by a router that serves the shaft and advertises its prefixes in the by a router that serves the shaft and advertises its prefixes in the
source realm. Based on longest match, the router forwards the packet source realm. Based on longest match, the router forwards the packet
inside the shaft following the host route to a router that serves the inside the shaft following the host route to a router that serves the
destination realm. That router swaps the destination address in the destination realm. That router swaps the destination address in the
inner and outer headers and forwards within its realm to the final inner and outer headers and forwards within its realm to the final
destination, as shown in Figure 3. In normal conditions, the stack destination, as shown in Figure 4.
of the destination node recognizes the YADA format and replies
accordingly. <----------------------------- 20 bytes ---------------------------->
+------------ ... ------------+-----------------+-------------------+
| IPv4 header fields | Source realm | destination node |
| | IPv4 Address | IPv4 Address |
+------------ ... ------------+-----------------+-------------------+
| IPv4 header fields | Source node | destination realm |
| | IPv4 Address | IPv4 Address |
+------------ ... ------------+-----------------+-------------------+
. Options .
+------------ ... --------------------------------------------------+
| |
. Data .
| |
+-------------------------------------------------------------------+
Figure 4: YADA format in the destination realm
In normal conditions, the stack of the destination node recognizes
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) /
/ . . . . / / . . . . /
/ . . . . / / . . . . /
-----------------------------------------------------/ -----------------------------------------------------/
Figure 3: Packets Outgoing the shaft destinations swapped at shaft egress
Figure 5: Packets Outgoing the shaft
In case of an error down the path or at the destination, if an ICMP In case of an error down the path or at the destination, if an ICMP
message is generated by a node that is not YADA-aware, the message message is generated by a node that is not YADA-aware, the message
reaches the router that serves the shaft in the source realm. If the reaches the router that serves the shaft in the source realm. If the
inner header is present in the ICMP payload, then the Router extracts inner header is present in the ICMP payload, then the Router extracts
it and forwards to the packet source. If the destination stack does it and forwards to the packet source. If the destination stack does
not support YADA and decapsulates, the message reaches the router not support YADA and decapsulates, the message reaches the router
that serves the destination realm which logs and drops. based on the 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 to log, the node may be updated, or the DNS records may be fixed to
avoid pointing on a node that does not support YADA. avoid pointing on a node that does not support YADA.
skipping to change at page 8, line 30 skipping to change at page 10, line 15
6. YATT 6. 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 4: YATT format Figure 6: 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 9, line 15 skipping to change at page 10, line 45
The formats can not be strictly provided till the YATT space and YADA The formats can not be strictly provided till the YATT space and YADA
prefix are assigned. But say that the YATT Space is F000::/6 and the prefix are assigned. But say that the YATT Space is F000::/6 and the
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 5: YATT format using 240.0.0.0/6 Figure 7: 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
shaft would allow literally to reuse every ASN and every IPv4 address
currently available in the Internet in each and every other realm and
reallocate them in any fashion desirable in that realm.
If the network supports IPv6 to the shaft, it makes sense for the If the network supports IPv6 to the shaft, it makes sense for the
YADA host or the bump-in-the-stack to generate the packets in the YADA host or the bump-in-the-stack to generate the packets in the
YATT form natively. The shaft router must then attract the shaft YATT form natively. The shaft router must then attract the shaft
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 IP If the network is IPv4 only, the packets are still generated using
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.
7. Applicability 7. The structure of the shaft
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
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
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
each realm by the router that serves the shaft, and that is
disaggregated into host routes inside the shaft.
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
over the world. A realm may be multihomed to be reached from a
different physical instance of the shaft, meaning that the shaft is
composed of either more prefixes or the shaft prefix is
disaggregated. Multiple routers will serve the same realm with high
availability and load balancing taking place inside the shaft to
maintain connectivity. Some shafts may be deployed to interconnect
only a subset of the realms, in which case those shafts would share a
specific prefix that would not be advertised outside the concerned
realms.
8. 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 required to allow an IPv4-only YADA node to communicate with an IPv6
node a a non-YATT address.
8. Backwards Compatibility In summary:
* this specification does not allow any IPv4 legacy node to talk to
any pure IPv6 node, and recognizes that this Graal may actually be
a non-goal.
* With YADA the current IPv4 Internet operations are not affected
* YADA extends the IPv4-reachable world by creating (millions of)
parallel realms and changing (only) the stack on the hosts that
require inter-realm communication and specific routers at the
ingress of the realms
* A YADA node can talk (using IPv4) to a YATT node (using IPv6) with
a stateless translation. The translation can happen anywhere in
the network or in the stack.
* a YATT node being an IPv6 can talk to any other IPv6 nodes.
9. 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.
9. Security Considerations 10. Security Considerations
10. IANA Considerations 11. 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.
11. Acknowledgments This document requires the creation of a new record in the Resource
Record (RR) TYPEs subregistry of the Domain Name System (DNS)
Parameters. The new record would be of type AA meaning a YADA
address.
12. References 12. Acknowledgments
12.1. Normative References The author wishes to thank Greg Skinner as the first reviewer/
contributor to this work.
13. References
13.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>.
skipping to change at page 10, line 52 skipping to change at page 13, line 39
[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>.
12.2. Informative References 13.2. Informative References
[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>.
Author's Address Author's Address
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
06254 Mougins - Sophia Antipolis 06254 Mougins - Sophia Antipolis
France France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
 End of changes. 39 change blocks. 
71 lines changed or deleted 199 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/