< draft-thubert-v6ops-yada-yatt-00.txt		draft-thubert-v6ops-yada-yatt-01.txt >
	v6ops P. Thubert, Ed.		v6ops P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Updates: 1122, 4291 (if approved) 28 March 2022		Updates: 1122, 4291 (if approved) 29 March 2022
	Intended status: Informational		Intended status: Informational
	Expires: 29 September 2022		Expires: 30 September 2022
	Yet Another Double address and Translation Technique		Yet Another Double Address and Translation Technique
	draft-thubert-v6ops-yada-yatt-00		draft-thubert-v6ops-yada-yatt-01
	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. YATT can take place as a bump
	in the stack at either end, or within the network and enables an		in the stack at either end, or within the network and enables an
	IPv6-only stack to dialog with an IPv4-only stack across a network		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		that can be IPv6, IPv4, or mixed. YATT requires that the IPv6 stack
	owns a prefix that derives from a YADA address and the IPv4 stack is		owns a prefix that derives from a YADA address and the IPv4 stack is
	capable of YADA, so it does not replace a generic 4 to 6 translation		capable of YADA, so it does not replace a generic 4 to 6 translation
	mechanism for any v6 to any v4.		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
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 29 September 2022.		This Internet-Draft will expire on 30 September 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
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 10		9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	12.1. Normative References . . . . . . . . . . . . . . . . . . 10		12.1. Normative References . . . . . . . . . . . . . . . . . . 10
	12.2. Informative References . . . . . . . . . . . . . . . . . 10		12.2. Informative References . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	This document provides a mechanism called Yet Another Double address		This document provides a mechanism called Yet Another Double Address
	(YADA) to grow the Internet beyond the current IPv4 [IPv4] realm that		(YADA) to grow the Internet beyond the current IPv4 [IPv4] realm that
	limits its capacity to form public addresses. This is achieved by		limits its capacity to form public addresses. This is achieved by
	interconnecting IPv4 realms via a common footprint called the shaft.		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
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 35 ¶
	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.
	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 nex terms:
	IPv4 realm A full IPv4 network like the current Internet. YADA does		IPv4 realm A full IPv4 network like the current Internet. YADA does
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 32 ¶
	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
	YATT extends [IPv6-addressING] to add the capability for an IPv4 host		YATT extends [IPv6-ADDRESSING] to add the capability for an IPv4 host
	to recognize an special IPv6 format as an YATT address embedding a		to recognize an special IPv6 format as an YATT address embedding a
	YADA address and process it accordingly. It also automatically		YADA address and process it accordingly. It also automatically
	derives the ownership of the YATT prefix associated to a owned YADA		derives the ownership of the YATT prefix associated to a owned YADA
	address.		address.
	5. YADA		5. 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
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	-----------------------------------------------------/		-----------------------------------------------------/
	| | | |		| | | |
	| | |		| | |
	| | |		| | |
	v		v
	Figure 2: Packets Entering the shaft		Figure 2: 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 ion longest match, the router forwards the		source realm. Based on longest match, the router forwards the packet
	packet inside the shaft following the host route to a router that		inside the shaft following the host route to a router that serves the
	serves the destination realm. That router swaps the destination		destination realm. That router swaps the destination address in the
	address in the inner and outer headers and forwards within its realm		inner and outer headers and forwards within its realm to the final
	to the final destination, as shown in Figure 3. In normal		destination, as shown in Figure 3. In normal conditions, the stack
	conditions, the stack of the destination node recognizes the YADA		of the destination node recognizes the YADA format and replies
	format and replies accordingly.		accordingly.
	|		|
	| | |		| | |
	| | |		| | |
	/------|----|-------|---------------------------------		/------|----|-------|---------------------------------
	/ | | | | | /		/ | | | | | /
	/ | | | | | /		/ | | | | | /
	/ | |----|---|---| Destination Node /		/ | |----|---|---| Destination Node /
	/ | / | | / /		/ | / | | / /
	/ | /. +---|----> outer(src=src-realm /		/ | /. +---|----> outer(src=src-realm /
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 13 ¶
	avoid pointing on a node that does not support YADA.		avoid pointing on a node that does not support YADA.
	YADA requires the assignment of a second IPv4 prefix, this time for a		YADA requires the assignment of a second IPv4 prefix, this time for a
	internal NATing operation. A bump-in-the-stack intercepts the DNS		internal NATing operation. A bump-in-the-stack intercepts the DNS
	lookups, and when the response yields a double-A record with a		lookups, and when the response yields a double-A record with a
	foreign realm, the record is augmented with an IPv4 address taken		foreign realm, the record is augmented with an IPv4 address taken
	from a local NAT pool. When the stack sends a packet to that		from a local NAT pool. When the stack sends a packet to that
	particular address, the bump-in-the-stack translates to the YADA		particular address, the bump-in-the-stack translates to the YADA
	format, using the information in the double-A record for the		format, using the information in the double-A record for the
	destination, and the local realm as source realm. The other way		destination, and the local realm as source realm. The other way
	around, id a packet arrives with a YADA format but the stack does not		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,		support it, the bump-in-the-stack allocates an address from the pool,
	and NATs to IPv4 using that address as source.		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.
	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.
	skipping to change at page 9, line 6 ¶		skipping to change at page 9, line 6 ¶
	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
	full /64 prefix that is entirely owned by the host that owns the		full /64 prefix that is entirely owned by the host that owns the
	associated YADA address.		associated YADA address.
	YATT then forms an IPv6 address for that host by collating a well-		YATT then forms an IPv6 address for that host by collating a well-
	known Interface ID, so there's a one-to-one relationship.		known Interface ID, so there's a one-to-one relationship.
	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 F00::/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 ------->
	skipping to change at page 10, line 6 ¶		skipping to change at page 10, line 6 ¶
	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 DS-Lite [DS-LIGHT], but		another realm, a NAT operation similar to NAT46 [NAT-DEPLOY], but
	between IPv4 and YADA addresses, is required.		between IPv4 and YADA addresses, is required. The same would be
			required to allow an IPv4-only YADA node to communicate with
	8. Backwards Compatibility		8. 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		9. Security Considerations
	10. IANA Considerations		10. IANA Considerations
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 42 ¶
	[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>.
	[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		12.2. Informative References
	[DS-LIGHT] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.		[NAT-DEPLOY]
	Korhonen, "Requirements for Distributed Mobility		Palet Martinez, J., "Additional Deployment Guidelines for
	Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,		NAT64/464XLAT in Operator and Enterprise Networks",
	<https://www.rfc-editor.org/info/rfc7333>.		RFC 8683, DOI 10.17487/RFC8683, November 2019,
			<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
End of changes. 14 change blocks.
	25 lines changed or deleted		27 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/