--- 1/draft-ietf-babel-v4viav6-01.txt 2021-04-13 09:14:55.990404589 -0700 +++ 2/draft-ietf-babel-v4viav6-02.txt 2021-04-13 09:14:56.014405188 -0700 @@ -1,19 +1,19 @@ Network Working Group J. Chroboczek Internet-Draft IRIF, University of Paris -Updates: 8966 (if approved) 9 April 2021 -Intended status: Experimental -Expires: 11 October 2021 +Updates: 8966 (if approved) 13 April 2021 +Intended status: Standards Track +Expires: 15 October 2021 IPv4 routes with an IPv6 next-hop in the Babel routing protocol - draft-ietf-babel-v4viav6-01 + draft-ietf-babel-v4viav6-02 Abstract This document defines an extension to the Babel routing protocol that allows annoncing routes to an IPv4 prefix with an IPv6 next-hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address. Status of This Memo @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 11 October 2021. + This Internet-Draft will expire on 15 October 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -185,52 +185,59 @@ 2.4. Other TLVs The only other TLVs defined by [RFC8966] that carry an AE field are Next-Hop and TLV. Next-Hop and IHU TLVs MUST NOT carry the AE TBD (v4-via-v6). 3. ICMPv4 and PMTU discovery The Internet Control Message Protocol (ICMPv4, or simply ICMP) - [RFC792] is a protocol related to IPv4 that carries diagnostic and - debugging information. ICMPv4 packets may be originated by end hosts - (e.g., the "destination unreachable, port unreachable" ICMPv4 - packet), but they may also be originated by intermediate routers - (e.g., most other kinds of "destination unreachable" packets). + [RFC792] is a protocol related to IPv4 that is primarily used to + carry diagnostic and debugging information. ICMPv4 packets may be + originated by end hosts (e.g., the "destination unreachable, port + unreachable" ICMPv4 packet), but they may also be originated by + intermediate routers (e.g., most other kinds of "destination + unreachable" packets). - Path MTU Discovery (PMTUd) [RFC1191] is an algorithm executed by end - hosts to discover the 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 most commonly deployed in the Internet has - a hard dependency on ICMPv4 packets originated by intermediate - routers: if intermediate routers are unable to send ICMPv4 packets, - PMTUd may lead to persistent blackholing of IPv4 traffic. + Some protocols deployed in the Internet rely on ICMPv4 packets sent + by intermediate routers. Most notably, path MTU Discovery (PMTUd) + [RFC1191] is an algorithm executed by end hosts to discover the + 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 + most commonly deployed in the Internet has a hard dependency on + ICMPv4 packets originated by intermediate routers: if intermediate + routers are unable to send ICMPv4 packets, PMTUd may lead to + persistent blackholing of IPv4 traffic. - For that reason, every Babel router that is able to forward IPv4 - traffic MUST be able originate ICMPv4 traffic. Since the extension - described in this document enables routers to forward IPv4 traffic - even when they have not been assigned an IPv4 address, a router - implementing this extension MUST be able to originate ICMPv4 packets - even when it has not been assigned an IPv4 address. + Due to this dependency, every Babel router that is able to forward + IPv4 traffic MUST be able originate ICMPv4 traffic. Since the + extension described in this document enables routers to forward IPv4 + traffic received over an interface that has not been assigned an IPv4 + address, a router implementing this extension MUST be able to + originate ICMPv4 packets, even when the outgoing interface has not + been assigned an IPv4 address. There are various ways to meet this requirement, and choosing between them is left to the implementation. For example, if a router has an - interface that has been assigned an IPv4 address, or if it has an - IPv4 address that has been assigned to the router itself (to the - "loopback interface"), then that IPv4 address may be "borrowed" to - serve as the source of originated ICMPv4 packets. If no IPv4 address - is available, a router may use a dummy IPv4 address as the source of + interface that has been assigned an IPv4 address, or if an IPv4 + address has been assigned to the router itself (to the "loopback + interface"), then that IPv4 address may be "borrowed" to serve as the + source of originated ICMPv4 packets. If no IPv4 address is + available, a router may use a dummy IPv4 address as the source of outgoing ICMPv4 packets, for example an address taken from a private address range [RFC1918] that is known to not be used in the local - routing domain. Note however that using the same address on multiple - routers may hamper debugging and fault isolation. + routing domain (either dynamically chosen, for example drawn randomly + or derived algorithmically from an IPv6 address, or statically + configured). Note however that using the same address on multiple + routers may hamper debugging and fault isolation, e.g., when using + 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, @@ -332,23 +339,24 @@ assumption is broken if the intermediary routers implement the extension described in this document, which might expose the IPv4-only hosts to traffic from the IPv4 Internet. If this is undesirable, the flow of IPv4 traffic must be restricted by the use of suitable filtering rules (Appendix C of [RFC8966]) together with matching packet filters in the data plane. 8. Acknowledgments This protocol extension was originally designed, described and - implemented in collaboration with Theophile Bastian. The author is - also indebted to Margaret Cullen, who pointed out the issues with - ICMP and helped coin the expression "V4-via-V6". + implemented in collaboration with Theophile Bastian. Margaret Cullen + pointed out the issues with ICMP and helped coin the phrase "v4-via- + v6". The author is also indebted to Donald Eastlake, Toke Hoiland- + Jorgensen, and David Schinazi. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, .