| RFC 9229 | IPv4 Routes with an IPv6 Next Hop | May 2022 |
| Chroboczek | Experimental | [Page] |
This document defines an extension to the Babel routing protocol thatallows announcing routes to an IPv4 prefix with an IPv6 next hop, whichmakes it possible for IPv4 traffic to flow through interfaces that havenot been assigned an IPv4 address.¶
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.¶
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9229.¶
Copyright (c) 2022 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 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The role of a routing protocol is to build a routing table, a datastructure that maps network prefixes in a given family (IPv4 or IPv6)to next hops, which are (at least conceptually) pairs of an outgoinginterface and a neighbour's network address. For example:¶
destination next hop 2001:db8:0:1::/64 eth0, fe80::1234:5678 203.0.113.0/24 eth0, 192.0.2.1¶
When a packet is routed according to a given routing table entry, theforwarding plane typically uses a neighbour discovery protocol (theNeighbour Discovery (ND) protocol[RFC4861] in the case ofIPv6 and the Address Resolution Protocol (ARP)[RFC0826] inthe case of IPv4) to map the next-hop address to a link-layer address (a"Media Access Control (MAC) address"), which is then used to construct the link-layer frames thatencapsulate forwarded packets.¶
It is apparent from the description above that there is no fundamentalreason why the destination prefix and the next-hop address should be inthe same address family: there is nothing preventing an IPv6 packet frombeing routed through a next hop with an IPv4 address (in which case thenext hop's MAC address will be obtained using ARP) or, conversely, anIPv4 packet from being routed through a next hop with an IPv6 address.(In fact, it is even possible to store link-layer addresses directly inthe next-hop entry of the routing table, which is commonly done innetworks using the OSI protocol suite).¶
The case of routing IPv4 packets through an IPv6 next hop isparticularly interesting, since it makes it possible to build networksthat have no IPv4 addresses except at the edges and still provide IPv4connectivity to edge hosts. In addition, since an IPv6 next hop can usea link-local address that is autonomously configured, the use of suchroutes enables a mode of operation where the network core has nostatically assigned IP addresses of either family, which significantlyreduces the amount of manual configuration required. (See also[RFC7404] for a discussion of the issues involved with suchan approach.)¶
We call a route towards an IPv4 prefix that uses an IPv6 next hopa "v4-via-v6" route. This document describes an extension that allows theBabel routing protocol[RFC8966] to announce v4-via-v6routes across interfaces that have no IPv4 addresses assigned but arecapable of forwarding IPv4 traffic.Section 3 describesprocedures that ensure that all routers can originate ICMPv4 packets, evenif they have not been assigned any IPv4 addresses.¶
The extension described in this document is inspired by a previouslydefined extension to BGP[RFC5549].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The Babel protocol fully supports dual-stack operation: all data thatrepresent a neighbour address or a network prefix are tagged by an AddressEncoding (AE), a small integer that identifies the address family (IPv4 orIPv6) of the address of prefix and describes how it is encoded. Thisextension defines a new AE, called "v4-via-v6", which has the same format asthe existing AE for IPv4 addresses (AE 1). This new AE is onlyallowed in TLVs that carry network prefixes: TLVs that carry an IPv6neighbour address use one of the normal encodings for IPv6 addresses.¶
A Babel node can use a v4-via-v6 announcement to announce an IPv4 routeover an interface that has no assigned IPv4 address. In order to do so,it first establishes an IPv6 next-hop address in the usual manner (eitherby sending the Babel packet over IPv6, or by including a Next Hop TLVcontaining an IPv6 address and using AE 2 or 3); it then sends an Update,with AE equal to 4 (v4-via-v6) containing the IPv4 prefix beingannounced.¶
If the outgoing interface has been assigned an IPv4 address, then, inthe interest of maximising compatibility with existing routers, the senderSHOULD prefer an ordinary IPv4 announcement; even in that case, however,itMAY send a v4-via-v6 announcement. A nodeSHOULD NOT send bothordinary IPv4 and v4-via-v6 announcements for the same prefix overa single interface (if the update is sent to a multicast address) or toa single neighbour (if sent to a unicast address), since doing thatprovides no benefit while doubling the amount of routing traffic.¶
Updates with infinite metric are retractions: they indicate thata previously announced route is no longer available. Retractions do notrequire a next hop; therefore, there is no difference between v4-via-v6retractions and ordinary retractions. A nodeMAY send IPv4 retractionsonly, or itMAY send v4-via-v6 retractions on interfaces that have notbeen assigned an IPv4 address.¶
Upon reception of an Update TLV with AE equal to 4 (v4-via-v6) andfinite metric, a Babel node computes the IPv6 next hop, as described inSection 4.6.9 of [RFC8966]. If no IPv6 next hop exists,then the UpdateMUST be ignored. If an IPv6 next hop exists,then the nodeMAY acquire the route being announced, as described inSection 3.5.3 of [RFC8966]; the parameters of the route areas follows:¶
An Update TLV with a v4-via-v6 AE and metric equal to infinity isa retraction: it announces that a previously available route is beingretracted. In that case, no next hop is necessary, and the retraction istreated as described inSection 4.6.9 of [RFC8966].¶
As usual, a nodeMAY ignore the update, e.g., due to filtering(seeAppendix C of [RFC8966]). If a node cannot installv4-via-v6 routes, e.g., due to hardware or software limitations, thenroutes to an IPv4 prefix with an IPv6 next hopMUST NOT be selected.¶
Route and seqno requests are used to request an update for a givenprefix. Since they are not related to a specific next hop, there is nosemantic difference between IPv4 and v4-via-v6 requests. Therefore,a nodeSHOULD NOT send requests of either kind with the AE field being setto 4 (v4-via-v6); instead, itSHOULD request IPv4 updates by sendingrequests with the AE field being set to 1 (IPv4).¶
When receiving requests, AEs 1 (IPv4) and 4 (v4-via-v6)MUST be treatedin the same manner: the receiver processes the request as described inSection 3.8 of [RFC8966]. If an Update is sent, then itMAY be an ordinary IPv4 announcement (AE = 1) or a v4-via-v6announcement (AE = 4), as described inSection 2.1, irrespective of which AE was used in the request.¶
When receiving a request with AE 0 (wildcard), the receiverSHOULD senda full route dump, as described inSection 3.8.1.1 of [RFC8966]. Any IPv4 routes contained in the route dump may useeither AE 1 (IPv4) or AE 4 (v4-via-v6), as describedSection 2.1.¶
The only other TLVs defined by[RFC8966] that carry anAE field are Next Hop and IHU. Next Hop and IHU TLVsMUST NOT carry theAE 4 (v4-via-v6).¶
The Internet Control Message Protocol (ICMPv4, or simply ICMP)[RFC0792] is a protocol related to IPv4 that is primarily used tocarry diagnostic and debugging information. ICMPv4 packets may beoriginated by end hosts (e.g., the "destination unreachable, portunreachable" ICMPv4 packet), but they may also be originated byintermediate routers (e.g., most other kinds of "destination unreachable"packets).¶
Some protocols deployed in the Internet rely on ICMPv4 packets sent byintermediate routers. Most notably, Path MTU Discovery (PMTUD)[RFC1191] is an algorithm executed by end hosts to discover themaximum packet size that a route is able to carry. While there existvariants of PMTUD that are purely end-to-end[RFC4821], thevariant most commonly deployed in the Internet has a hard dependency onICMPv4 packets originated by intermediate routers: if intermediate routersare unable to send ICMPv4 packets, PMTUD may lead to persistentblackholing of IPv4 traffic.¶
Due to this kind of dependency, every Babel router that is able toforward IPv4 trafficMUST be able originate ICMPv4 traffic. Since theextension described in this document enables routers to forward IPv4traffic received over an interface that has not been assigned an IPv4address, a router implementing this extensionMUST be able to originateICMPv4 packets even when the outgoing interface has not been assigned anIPv4 address.¶
In such a situation, if a Babel router has an interface that has beenassigned an IPv4 address (other than a loopback address) or if an IPv4address has been assigned to the router itself (to the "loopbackinterface"), then that IPv4 address may be used as the source oforiginated ICMPv4 packets. If no IPv4 address is available, a Babelrouter could use the experimental mechanism described in RequirementR-22 ofSection 4.8 of [RFC7600], which consists ofusing the dummy address 192.0.0.8 as the source address of originatedICMPv4 packets. Note, however, that using the same address on multiplerouters may hamper debugging and fault isolation, e.g., when using the"traceroute" utility.¶
This extension defines the v4-via-v6 AE, whose value is 4. This AE issolely used to tag network prefixes andMUST NOT be used to tag neighbouraddresses, e.g., in Next Hop or IHU TLVs.¶
This extension defines no new TLVs or sub-TLVs.¶
Network prefixes tagged with AE 4 (v4-via-v6)MUST be encoded anddecoded just like prefixes tagged with AE 1 (IPv4), as described inSection 4.1.5 of [RFC8966].¶
A new compression state for AE 4 (v4-via-v6) distinct from that of AE1 (IPv4) is introduced andMUST be used for address compression ofprefixes tagged with AE 4, as described in Sections4.5 and4.6.9 of[RFC8966]¶
The following TLVsMAY be tagged with AE 4 (v4-via-v6):¶
As AE 4 (v4-via-v6) is suitable only for network prefixes, IHU(Type = 5) and Next Hop (Type = 7) TLVs are never sentwith AE 4. Such (incorrect) TLVsMUST be ignored upon reception.¶
An Update (Type = 8) TLV with AE 4 (v4-via-v6) is constructed as described inSection 4.6.9 of [RFC8966] for AE 1 (IPv4), with thefollowing specificities:¶
When tagged with the AE 4 (v4-via-v6), Route Request and Seqno Request TLVsMUST be constructed and decoded as described inSection 4.6 of [RFC8966], and the network prefixes contained within themMUST be decoded as described inSection 4.1 (see alsoSection 2.3).¶
This protocol extension adds no new TLVs or sub-TLVs.¶
This protocol extension uses a new AE. As discussed inAppendix D of [RFC8966] and specified in the same document, implementationsthat do not understand the present extension will silently ignore the variousTLVs that use this new AE. As a result, incompatible versions will ignorev4-via-v6 routes. They will also ignore requests with AE 4 (v4-via-v6), which, asstated inSection 2.3, are not recommended.¶
Using a new AE introduces a new compression state, which is used to parse the network prefixes. As this compression state is separate from the states of other AEs, it will not interfere with the compression state of unextended nodes.¶
This extension reuses the next-hop state from AEs 2 and 3 (IPv6) butmakes no changes to the way in which it is updated. Therefore, it causesno compatibility issues.¶
As mentioned inSection 2.1, ordinary IPv4 announcementsare preferred to v4-via-v6 announcements when the outgoing interface hasan assigned IPv4 address; doing otherwise would prevent routers that donot implement this extension from learning the route being announced.¶
IANA has allocated value 4 in the "Babel Address Encodings" registry asfollows:¶
| AE | Name | Reference |
|---|---|---|
| 4 | v4-via-v6 | RFC 9229 |
The extension defined in this document does not fundamentally changethe security properties of the Babel protocol. However, by allowing IPv4routes to be propagated across routers that have not been assigned IPv4addresses, it might invalidate the assumptions made by networkadministrators, which could conceivably lead to security issues.¶
For example, if an island of IPv4-only hosts is separated from the IPv4Internet by routers that have not been assigned IPv4 addresses, a networkadministrator might reasonably assume that the IPv4-only hosts areunreachable from the IPv4 Internet. This assumption is broken if theintermediary 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 theuse of suitable filtering rules (seeAppendix C of [RFC8966])together with matching packet filters in the data plane.¶
This protocol extension was originally designed, described, andimplemented in collaboration withTheophile Bastian.Margaret Cullenpointed out the issues with ICMP and helped coin the phrase "v4-via-v6".The author is also indebted toDonald Eastlake,Toke Høiland-Jørgensen,David Schinazi, andDonald Sharp.¶