draft-ietf-babel-v4viav6-06.txt		draft-ietf-babel-v4viav6-07.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) 18 June 2021		Updates: 8966 (if approved) 16 January 2022
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 20 December 2021		Expires: 20 July 2022
	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-06		draft-ietf-babel-v4viav6-07
	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. This document updates		that have not been assigned an IPv4 address. This document updates
	RFC 8966.		RFC 8966.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 20 December 2021.		This Internet-Draft will expire on 20 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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 Simplified BSD License text		extracted from this document must include Revised BSD License text as
	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 Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	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 . . . . . . . . . . . . . . . 4		2.1. Announcing v4-via-v6 routes . . . . . . . . . . . . . . . 4
	2.2. Receiving v4-via-v6 routes . . . . . . . . . . . . . . . 4		2.2. Receiving v4-via-v6 routes . . . . . . . . . . . . . . . 4
	2.3. Prefix and seqno requests . . . . . . . . . . . . . . . . 5		2.3. Prefix and seqno requests . . . . . . . . . . . . . . . . 5
	2.4. Other TLVs . . . . . . . . . . . . . . . . . . . . . . . 5		2.4. Other TLVs . . . . . . . . . . . . . . . . . . . . . . . 5
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	Address Encoding (AE), a small integer that identifies the address		Address Encoding (AE), a small integer that identifies the address
	family (IPv4 or IPv6) of the address of prefix, and describes how it		family (IPv4 or IPv6) of the address of prefix, and describes how it
	is encoded. This extension defines a new AE, called v4-via-v6, which		is encoded. This extension defines a new AE, called v4-via-v6, which
	has the same format as the existing AE for IPv4 addresses. This new		has the same format as the existing AE for IPv4 addresses. This new
	AE is only allowed in TLVs that carry network prefixes: TLVs that		AE is only allowed in TLVs that carry network prefixes: TLVs that
	carry a neighbour address use one of the normal encodings for IPv6		carry a neighbour address use one of the normal encodings for IPv6
	addresses.		addresses.
	2.1. Announcing v4-via-v6 routes		2.1. Announcing v4-via-v6 routes
	A Babel node that needs to announce an IPv4 route over an interface		A Babel node can use a v4-via-v6 announcement to announce an IPv4
	that has no assigned IPv4 address MAY make a v4-via-v6 announcement.		route over an interface that has no assigned IPv4 address. In order
	In order to do so, it first establishes an IPv6 next-hop address in		to do so, it first establishes an IPv6 next-hop address in the usual
	the usual manner (either by sending the Babel packet over IPv6, or by		manner (either by sending the Babel packet over IPv6, or by including
	including a Next Hop TLV containing an IPv6 address and using AE 2 or		a Next Hop TLV containing an IPv6 address and using AE 2 or 3); it
	3); it then sends an Update, with AE equal to 4 (v4-via-v6)		then sends an Update, with AE equal to 4 (v4-via-v6) containing the
	containing the IPv4 prefix being announced.		IPv4 prefix being announced.
	If the outgoing interface has been assigned an IPv4 address, then, in		If the outgoing interface has been assigned an IPv4 address, then, in
	the interest of maximising compatibility with existing routers, the		the interest of maximising compatibility with existing routers, the
	sender SHOULD prefer an ordinary IPv4 announcement; even in that		sender SHOULD prefer an ordinary IPv4 announcement; even in that
	case, however, it MAY send a v4-via-v6 announcement. A node SHOULD		case, however, it MAY send a v4-via-v6 announcement. A node SHOULD
	NOT send both ordinary IPv4 and v4-via-v6 announcements for the same		NOT send both ordinary IPv4 and v4-via-v6 announcements for the same
	prefix over a single interface (if the update is sent to a multicast		prefix over a single interface (if the update is sent to a multicast
	address) or to a single neighbour (if sent to a unicast address),		address) or to a single neighbour (if sent to a unicast address),
	since doing that provides no benefit while doubling the amount of		since doing that provides no benefit while doubling the amount of
	routing traffic.		routing traffic.
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 23 ¶
	persistent blackholing of IPv4 traffic.		persistent blackholing of IPv4 traffic.
	Due to this kind of dependency, every Babel router that is able to		Due to this kind of dependency, every Babel router that is able to
	forward IPv4 traffic MUST be able originate ICMPv4 traffic. Since		forward IPv4 traffic MUST be able originate ICMPv4 traffic. Since
	the extension described in this document enables routers to forward		the extension described in this document enables routers to forward
	IPv4 traffic received over an interface that has not been assigned an		IPv4 traffic received over an interface that has not been assigned an
	IPv4 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		In such a situation, if a Babel router has an interface that has been
	them is left to the implementation. For example, if a router has an		assigned an IPv4 address, or if an IPv4 address has been assigned to
	interface that has been assigned an IPv4 address, or if an IPv4		the router itself (to the "loopback interface"), then that IPv4
	address has been assigned to the router itself (to the "loopback		address may be used as the source of originated ICMPv4 packets. If
	interface"), then that IPv4 address may be "borrowed" to serve as the		no IPv4 address is available, a Babel router could use the
	source of originated ICMPv4 packets. If no IPv4 address is		experimental mechanism described in Section 22 of [RFC7600], which
	available, a router may choose a source address from a prefix known		consists of using the dummy address 192.0.0.8 as the source address
	to be unused, for example from a suitably chosen private address		of originated ICMPv4 packets. Note however that using the same
	range [RFC1918]. If no more suitable address is available, then a		address on multiple routers may hamper debugging and fault isolation,
	router MAY use the IPv4 dummy address 192.0.0.8 as the source address		e.g., when using the "traceroute" utility.
	of the IMCPv4 packets that it sends. Note however that using the
	same address on multiple routers may hamper debugging and fault
	isolation, e.g., when using the "traceroute" utility.
	4. Protocol encoding		4. Protocol encoding
	This extension defines the v4-via-v6 AE, whose value is 4. This AE		This extension defines the v4-via-v6 AE, whose value is 4. 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
	neighbour addresses, e.g. in Next Hop or IHU TLVs.		neighbour addresses, e.g. in Next Hop or IHU TLVs.
	This extension defines no new TLVs or sub-TLVs.		This extension defines no new TLVs or sub-TLVs.
	4.1. Prefix encoding		4.1. Prefix encoding
	skipping to change at page 9, line 11 ¶		skipping to change at page 9, line 11 ¶
	traffic must be restricted by the use of suitable filtering rules		traffic must be restricted by the use of suitable filtering rules
	(Appendix C of [RFC8966]) together with matching packet filters in		(Appendix C of [RFC8966]) together with matching packet filters in
	the data plane.		the data plane.
	8. Acknowledgments		8. Acknowledgments
	This protocol extension was originally designed, described and		This protocol extension was originally designed, described and
	implemented in collaboration with Theophile Bastian. Margaret Cullen		implemented in collaboration with Theophile Bastian. Margaret Cullen
	pointed out the issues with ICMP and helped coin the phrase "v4-via-		pointed out the issues with ICMP and helped coin the phrase "v4-via-
	v6". The author is also indebted to Donald Eastlake, Toke Hoiland-		v6". The author is also indebted to Donald Eastlake, Toke Hoiland-
	Jorgensen, and David Schinazi.		Jorgensen, David Schinazi, and Donald Sharp.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, DOI 10.17487/RFC0792, September 1981,		RFC 792, DOI 10.17487/RFC0792, September 1981,
	<https://www.rfc-editor.org/info/rfc792>.		<https://www.rfc-editor.org/info/rfc792>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 9, line 46 ¶		skipping to change at page 9, line 46 ¶
	[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or		[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
	Converting Network Protocol Addresses to 48.bit Ethernet		Converting Network Protocol Addresses to 48.bit Ethernet
	Address for Transmission on Ethernet Hardware", STD 37,		Address for Transmission on Ethernet Hardware", STD 37,
	RFC 826, DOI 10.17487/RFC0826, November 1982,		RFC 826, DOI 10.17487/RFC0826, November 1982,
	<https://www.rfc-editor.org/rfc/rfc826>.		<https://www.rfc-editor.org/rfc/rfc826>.
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	DOI 10.17487/RFC1191, November 1990,		DOI 10.17487/RFC1191, November 1990,
	<https://www.rfc-editor.org/info/rfc1191>.		<https://www.rfc-editor.org/info/rfc1191>.
	[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>.
	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,		Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
	<https://www.rfc-editor.org/info/rfc4821>.		<https://www.rfc-editor.org/info/rfc4821>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<https://www.rfc-editor.org/rfc/rfc4861>.		<https://www.rfc-editor.org/rfc/rfc4861>.
	[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network		[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
	Layer Reachability Information with an IPv6 Next Hop",		Layer Reachability Information with an IPv6 Next Hop",
	RFC 5549, DOI 10.17487/RFC5549, May 2009,		RFC 5549, DOI 10.17487/RFC5549, May 2009,
	<https://www.rfc-editor.org/rfc/rfc5549>.		<https://www.rfc-editor.org/rfc/rfc5549>.
			[RFC7600] Despres, R., Jiang, S., Ed., Penno, R., Lee, Y., Chen, G.,
			and M. Chen, "IPv4 Residual Deployment via IPv6 - A
			Stateless Solution (4rd)", RFC 7600, DOI 10.17487/RFC7600,
			July 2015, <https://www.rfc-editor.org/info/rfc7600>.
	Author's Address		Author's Address
	Juliusz Chroboczek		Juliusz Chroboczek
	IRIF, University of Paris		IRIF, University of Paris
	Case 7014		Case 7014
	75205 Paris Cedex 13		75205 Paris Cedex 13
	France		France
	Email: jch@irif.fr		Email: jch@irif.fr
End of changes. 11 change blocks.
	34 lines changed or deleted		31 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/