draft-ietf-babel-v4viav6-02.txt		draft-ietf-babel-v4viav6-03.txt
	Network Working Group J. Chroboczek		Network Working Group J. Chroboczek
	Internet-Draft IRIF, University of Paris		Internet-Draft IRIF, University of Paris
	Updates: 8966 (if approved) 13 April 2021		Updates: 8966 (if approved) 21 April 2021
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 15 October 2021		Expires: 23 October 2021
	IPv4 routes with an IPv6 next-hop in the Babel routing protocol		IPv4 routes with an IPv6 next-hop in the Babel routing protocol
	draft-ietf-babel-v4viav6-02		draft-ietf-babel-v4viav6-03
	Abstract		Abstract
	This document defines an extension to the Babel routing protocol that		This document defines an extension to the Babel routing protocol that
	allows annoncing routes to an IPv4 prefix with an IPv6 next-hop,		allows annoncing routes to an IPv4 prefix with an IPv6 next-hop,
	which makes it possible for IPv4 traffic to flow through interfaces		which makes it possible for IPv4 traffic to flow through interfaces
	that have not been assigned an IPv4 address.		that have not been assigned an IPv4 address.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 15 October 2021.		This Internet-Draft will expire on 23 October 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Specification of Requirements . . . . . . . . . . . . . . 3		1.1. Specification of Requirements . . . . . . . . . . . . . . 3
	2. Protocol operation . . . . . . . . . . . . . . . . . . . . . 3		2. Protocol operation . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Announcing v4-via-v6 routes . . . . . . . . . . . . . . . 3		2.1. Announcing v4-via-v6 routes . . . . . . . . . . . . . . . 3
	2.2. Receiving v4-via-v6 routes . . . . . . . . . . . . . . . 4		2.2. Receiving v4-via-v6 routes . . . . . . . . . . . . . . . 4
	2.3. Prefix and seqno requests . . . . . . . . . . . . . . . . 4		2.3. Prefix and seqno requests . . . . . . . . . . . . . . . . 4
	2.4. Other TLVs . . . . . . . . . . . . . . . . . . . . . . . 5		2.4. Other TLVs . . . . . . . . . . . . . . . . . . . . . . . 5
	3. ICMPv4 and PMTU discovery . . . . . . . . . . . . . . . . . . 5		3. ICMPv4 and PMTU discovery . . . . . . . . . . . . . . . . . . 5
	4. Backwards compatibility . . . . . . . . . . . . . . . . . . . 6		4. Protocol encoding . . . . . . . . . . . . . . . . . . . . . . 6
	5. Protocol encoding . . . . . . . . . . . . . . . . . . . . . . 6		4.1. Prefix encoding . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Prefix encoding . . . . . . . . . . . . . . . . . . . . . 6		4.2. Changes to existing TLVs . . . . . . . . . . . . . . . . 6
	5.2. Changes for existing TLVs . . . . . . . . . . . . . . . . 7		5. Backwards compatibility . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 36 ¶
	Some protocols deployed in the Internet rely on ICMPv4 packets sent		Some protocols deployed in the Internet rely on ICMPv4 packets sent
	by intermediate routers. Most notably, path MTU Discovery (PMTUd)		by intermediate routers. Most notably, path MTU Discovery (PMTUd)
	[RFC1191] is an algorithm executed by end hosts to discover the		[RFC1191] is an algorithm executed by end hosts to discover the
	maximum packet size that a route is able to carry. While there exist		maximum packet size that a route is able to carry. While there exist
	variants of PMTUd that are purely end-to-end [RFC4821], the variant		variants of PMTUd that are purely end-to-end [RFC4821], the variant
	most commonly deployed in the Internet has a hard dependency on		most commonly deployed in the Internet has a hard dependency on
	ICMPv4 packets originated by intermediate routers: if intermediate		ICMPv4 packets originated by intermediate routers: if intermediate
	routers are unable to send ICMPv4 packets, PMTUd may lead to		routers are unable to send ICMPv4 packets, PMTUd may lead to
	persistent blackholing of IPv4 traffic.		persistent blackholing of IPv4 traffic.
	Due to this dependency, every Babel router that is able to forward		Due to this kind of dependency, every Babel router that is able to
	IPv4 traffic MUST be able originate ICMPv4 traffic. Since the		forward IPv4 traffic MUST be able originate ICMPv4 traffic. Since
	extension described in this document enables routers to forward IPv4		the extension described in this document enables routers to forward
	traffic received over an interface that has not been assigned an IPv4		IPv4 traffic received over an interface that has not been assigned an
	address, a router implementing this extension MUST be able to		IPv4 address, a router implementing this extension MUST be able to
	originate ICMPv4 packets, even when the outgoing interface has not		originate ICMPv4 packets even when the outgoing interface has not
	been assigned an IPv4 address.		been assigned an IPv4 address.
	There are various ways to meet this requirement, and choosing between		There are various ways to meet this requirement, and choosing between
	them is left to the implementation. For example, if a router has an		them is left to the implementation. For example, if a router has an
	interface that has been assigned an IPv4 address, or if an IPv4		interface that has been assigned an IPv4 address, or if an IPv4
	address has been assigned to the router itself (to the "loopback		address has been assigned to the router itself (to the "loopback
	interface"), then that IPv4 address may be "borrowed" to serve as the		interface"), then that IPv4 address may be "borrowed" to serve as the
	source of originated ICMPv4 packets. If no IPv4 address is		source of originated ICMPv4 packets. If no IPv4 address is
	available, a router may use a dummy IPv4 address as the source of		available, a router may choose a source address from a prefix known
	outgoing ICMPv4 packets, for example an address taken from a private		to be unused, for example from a suitably chosen private address
	address range [RFC1918] that is known to not be used in the local		range [RFC1918]. If no more suitable address is available, then a
	routing domain (either dynamically chosen, for example drawn randomly		router MAY use the IPv4 dummy address 192.0.0.8 as the source address
	or derived algorithmically from an IPv6 address, or statically		of the IMCPv4 packets that it sends. Note however that using the
	configured). Note however that using the same address on multiple		same address on multiple routers may hamper debugging and fault
	routers may hamper debugging and fault isolation, e.g., when using		isolation, e.g., when using the "traceroute" utility.
	the "traceroute" utility.
	4. Backwards compatibility
	This protocol extension adds no new TLVs or sub-TLVs.
	This protocol extension uses a new AE. As discussed in Appendix D of
	[RFC8966] and specified in the same document, implementations that do
	not understand the present extension will silently ignore the various
	TLVs that use this new AE. As a result, incompatible versions will
	ignore v4-via-v6 routes. They will also ignore requests with AE TBD,
	which, as stated in Section 2.3, are NOT RECOMMENDED.
	Using a new AE introduces a new compression state, used to parse the
	network prefixes. As this compression state is separate from other
	AEs' states, it will not interfere with the compression state of
	unextended nodes.
	This extension reuses the next-hop state from AEs 2 and 3 (IPv6), but
	makes no changes to the way it is updated, and therefore causes no
	compatibility issues.
	As mentioned in Section 2.1, ordinary IPv4 announcements are
	preferred to v4-via-v6 announcements when the outgoing interface has
	an assigned IPv4 address; doing otherwise would prevent routers that
	do not implement this extension from learning the route being
	announced.
	5. Protocol encoding		4. Protocol encoding
	This extension defines the v4-via-v6 AE, whose value is TBD. This AE		This extension defines the v4-via-v6 AE, whose value is TBD. This AE
	is solely used to tag network prefixes, and MUST NOT be used to tag		is solely used to tag network prefixes, and MUST NOT be used to tag
	peers' addresses, eg. in Next-Hop or IHU TLVs.		peers' addresses, eg. in Next-Hop or IHU TLVs.
	This extension defines no new TLVs or sub-TLVs.		This extension defines no new TLVs or sub-TLVs.
	5.1. Prefix encoding		4.1. Prefix encoding
	Network prefixes tagged with AE TBD MUST be encoded and decoded as		Network prefixes tagged with AE TBD MUST be encoded and decoded just
	prefixes tagged with AE 1 (IPv4), as described in Section 4.3.1 of		like prefixes tagged with AE 1 (IPv4), as described in Section 4.3.1
	[RFC8966].		of [RFC8966].
	A new compression state for AE TBD (v4-via-v6) distinct from that of		A new compression state for AE TBD (v4-via-v6) distinct from that of
	AE 1 (IPv4) is introduced, and MUST be used for address compression		AE 1 (IPv4) is introduced, and MUST be used for address compression
	of prefixes tagged with AE TBD, as described in Section 4.6.9 of		of prefixes tagged with AE TBD, as described in Section 4.6.9 of
	[RFC8966]		[RFC8966]
	5.2. Changes for existing TLVs		4.2. Changes to existing TLVs
	The following TLVs MAY be tagged with AE TBD:		The following TLVs MAY be tagged with AE TBD:
	* Update (Type = 8)		* Update (Type = 8)
	* Route Request (Type = 9)		* Route Request (Type = 9)
	* Seqno Request (Type = 10)		* Seqno Request (Type = 10)
	As AE TBD is suitable only to tag network prefixes, IHU (Type = 5)		As AE TBD is suitable only for network prefixes, IHU (Type = 5) and
	and Next-Hop (Type = 7) TLVs MUST NOT be tagged with AE TBD. Such		Next-Hop (Type = 7) TLVs MUST NOT be tagged with AE TBD. Such
	(incorrect) TLVs MUST be silently ignored upon reception.		(incorrect) TLVs MUST be ignored upon reception.
	5.2.1. Update		4.2.1. Update
	An Update (Type = 8) TLV with AE = TBD is constructed as described in		An Update (Type = 8) TLV with AE = TBD is constructed as described in
	Section 4.6.9 of [RFC8966] for AE 1 (IPv4), with the following		Section 4.6.9 of [RFC8966] for AE 1 (IPv4), with the following
	specificities:		specificities:
	* Prefix. The Prefix field is constructed according to the		* Prefix. The Prefix field is constructed according to Section 4.1
	Section 5.1 above.		above.
	* Next hop. The next hop is determined as described in Section 2.2		* Next hop. The next hop is determined as described in Section 2.2
	above.		above.
	5.2.2. Other valid TLVs tagged with AE = TBD		4.2.2. Other TLVs
	Any other valid TLV tagged with AE = TBD MUST be constructed and		When tagged with the AE TBD, Route Request and Seqno Request updates
	decoded as described in Section 4.6 of [RFC8966]. Network prefixes		MUST be constructed and decoded as described in Section 4.6 of
	within MUST be constructed and decoded as described in Section 5.1		[RFC8966], and the network prefixes contained within them decoded as
	above.		described in Section 4.1 above.
			5. Backwards compatibility
			This protocol extension adds no new TLVs or sub-TLVs.
			This protocol extension uses a new AE. As discussed in Appendix D of
			[RFC8966] and specified in the same document, implementations that do
			not understand the present extension will silently ignore the various
			TLVs that use this new AE. As a result, incompatible versions will
			ignore v4-via-v6 routes. They will also ignore requests with AE TBD,
			which, as stated in Section 2.3, are NOT RECOMMENDED.
			Using a new AE introduces a new compression state, used to parse the
			network prefixes. As this compression state is separate from other
			AEs' states, it will not interfere with the compression state of
			unextended nodes.
			This extension reuses the next-hop state from AEs 2 and 3 (IPv6), but
			makes no changes to the way it is updated, and therefore causes no
			compatibility issues.
			As mentioned in Section 2.1, ordinary IPv4 announcements are
			preferred to v4-via-v6 announcements when the outgoing interface has
			an assigned IPv4 address; doing otherwise would prevent routers that
			do not implement this extension from learning the route being
			announced.
	6. IANA Considerations		6. IANA Considerations
	IANA is requested to allocate a value (4 suggested) in the "Babel		IANA is requested to allocate a value (4 suggested) in the "Babel
	Address Encodings" registry as follows:		Address Encodings" registry as follows:
	+=====+===========+=================+		+=====+===========+=================+
	| AE | Name | Reference |		| AE | Name | Reference |
	+=====+===========+=================+		+=====+===========+=================+
	| TBD | v4-via-v6 | (this document) |		| TBD | v4-via-v6 | (this document) |
End of changes. 16 change blocks.
	65 lines changed or deleted		64 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/