< 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/