idnits 2.17.1 draft-ietf-babel-v4viav6-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 February 2022) is 763 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Chroboczek 3 Internet-Draft IRIF, University of Paris 4 Intended status: Experimental 24 February 2022 5 Expires: 28 August 2022 7 IPv4 routes with an IPv6 next hop in the Babel routing protocol 8 draft-ietf-babel-v4viav6-08 10 Abstract 12 This document defines an extension to the Babel routing protocol that 13 allows announcing routes to an IPv4 prefix with an IPv6 next-hop, 14 which makes it possible for IPv4 traffic to flow through interfaces 15 that have not been assigned an IPv4 address. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 28 August 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 52 2. Protocol operation . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Announcing v4-via-v6 routes . . . . . . . . . . . . . . . 4 54 2.2. Receiving v4-via-v6 routes . . . . . . . . . . . . . . . 4 55 2.3. Route and seqno requests . . . . . . . . . . . . . . . . 5 56 2.4. Other TLVs . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. ICMPv4 and PMTU discovery . . . . . . . . . . . . . . . . . . 5 58 4. Protocol encoding . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Prefix encoding . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Changes to existing TLVs . . . . . . . . . . . . . . . . 7 61 5. Backwards compatibility . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 67 9.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 The role of a routing protocol is to build a routing table, a data 73 structure that maps network prefixes in a given family (IPv4 or IPv6) 74 to next hops, pairs of an outgoing interface and a neighbour's 75 network address, for example: 77 destination next hop 78 2001:db8:0:1::/64 eth0, fe80::1234:5678 79 203.0.113.0/24 eth0, 192.0.2.1 81 When a packet is routed according to a given routing table entry, the 82 forwarding plane typically uses a neighbour discovery protocol (the 83 Neighbour Discovery protocol (ND) [RFC4861] in the case of IPv6, the 84 Address Resolution Protocol (ARP) [RFC0826] in the case of IPv4) to 85 map the next-hop address to a link-layer address (a "MAC address"), 86 which is then used to construct the link-layer frames that 87 encapsulate forwarded packets. 89 It is apparent from the description above that there is no 90 fundamental reason why the destination prefix and the next-hop 91 address should be in the same address family: there is nothing 92 preventing an IPv6 packet from being routed through a next hop with 93 an IPv4 address (in which case the next hop's MAC address will be 94 obtained using ARP), or, conversely, an IPv4 packet from being routed 95 through a next hop with an IPv6 address. (In fact, it is even 96 possible to store link-layer addresses directly in the next-hop entry 97 of the routing table, which is commonly done in networks using the 98 OSI protocol suite). 100 The case of routing IPv4 packets through an IPv6 next hop is 101 particularly interesting, since it makes it possible to build 102 networks that have no IPv4 addresses except at the edges and still 103 provide IPv4 connectivity to edge hosts. In addition, since an IPv6 104 next hop can use a link-local address that is autonomously 105 configured, the use of such routes enables a mode of operation where 106 the network core has no statically assigned IP addresses of either 107 family, which significantly reduces the amount of manual 108 configuration required. (See also [RFC7404] for a discussion of the 109 issues involved with such an approach.) 111 We call a route towards an IPv4 prefix that uses an IPv6 next hop a 112 "v4-via-v6" route. This document describes an extension that allows 113 the Babel routing protocol [RFC8966] to announce v4-via-v6 routes 114 across interfaces that have no IPv4 addresses assigned but are 115 capable of forwarding IPv4 traffic. Section 3 describes procedures 116 that ensure that all routers can originate ICMPv4 packets, even if 117 they have not been assigned any IPv4 addresses. 119 The extension described in this document is inspired by a previously 120 defined extension to the BGP protocol [RFC5549]. 122 1.1. Specification of Requirements 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 2. Protocol operation 132 The Babel protocol fully supports dual-stack operation: all data that 133 represent a neighbour address or a network prefix are tagged by an 134 Address Encoding (AE), a small integer that identifies the address 135 family (IPv4 or IPv6) of the address of prefix, and describes how it 136 is encoded. This extension defines a new AE, called v4-via-v6, which 137 has the same format as the existing AE for IPv4 addresses (AE 1). 138 This new AE is only allowed in TLVs that carry network prefixes: TLVs 139 that carry an IPv6 neighbour address use one of the normal encodings 140 for IPv6 addresses. 142 2.1. Announcing v4-via-v6 routes 144 A Babel node can use a v4-via-v6 announcement to announce an IPv4 145 route over an interface that has no assigned IPv4 address. In order 146 to do so, it first establishes an IPv6 next-hop address in the usual 147 manner (either by sending the Babel packet over IPv6, or by including 148 a Next Hop TLV containing an IPv6 address and using AE 2 or 3); it 149 then sends an Update, with AE equal to 4 (v4-via-v6) containing the 150 IPv4 prefix being announced. 152 If the outgoing interface has been assigned an IPv4 address, then, in 153 the interest of maximising compatibility with existing routers, the 154 sender SHOULD prefer an ordinary IPv4 announcement; even in that 155 case, however, it MAY send a v4-via-v6 announcement. A node SHOULD 156 NOT send both ordinary IPv4 and v4-via-v6 announcements for the same 157 prefix over a single interface (if the update is sent to a multicast 158 address) or to a single neighbour (if sent to a unicast address), 159 since doing that provides no benefit while doubling the amount of 160 routing traffic. 162 Updates with infinite metric are retractions: they indicate that a 163 previously announced route is no longer available. Retractions do 164 not require a next hop, and there is therefore no difference between 165 v4-via-v6 retractions and ordinary retractions. A node MAY send IPv4 166 retractions only, or it MAY send v4-via-v6 retractions on interfaces 167 that have not been assigned an IPv4 address. 169 2.2. Receiving v4-via-v6 routes 171 Upon reception of an Update TLV with AE equal to 4 (v4-via-v6) and 172 finite metric, a Babel node computes the IPv6 next hop, as described 173 in Section 4.6.9 of [RFC8966]. If no IPv6 next hop exists, then the 174 Update MUST be ignored. If an IPv6 next hop exists, then the node 175 MAY acquire the route being announced, as described in Section 3.5.3 176 of [RFC8966]; the parameters of the route are as follows: 178 * the prefix, plen, router-id, seqno, metric MUST be computed as for 179 an IPv4 route, as described in Section 4.6.9 of [RFC8966]; 181 * the next hop MUST be computed as for an IPv6 route, as described 182 in Section 4.6.9 of [RFC8966]: it is taken from the last preceding 183 Next Hop TLV with an AE field equal to 2 or 3; if no such entry 184 exists, and if the Update TLV has been sent in a Babel packet 185 carried over IPv6, then the next hop is the network-layer source 186 address of the packet. 188 An Update TLV with a v4-via-v6 AE and metric equal to infinity is a 189 retraction: it announces that a previously available route is being 190 retracted. In that case, no next hop is necessary, and the 191 retraction is treated as described in Section 4.6.9 of [RFC8966]. 193 As usual, a node MAY ignore the update, e.g., due to filtering 194 (Appendix C of [RFC8966]). If a node cannot install v4-via-v6 195 routes, e.g., due to hardware or software limitations, then routes to 196 an IPv4 prefix with an IPv6 next hop MUST NOT be selected. 198 2.3. Route and seqno requests 200 Route and seqno requests are used to request an update for a given 201 prefix. Since they are not related to a specific next hop, there is 202 no semantic difference between IPv4 and v4-via-v6 requests. 203 Therefore, a node SHOULD NOT send requests of either kind with the AE 204 field being set to 4 (v4-via-v6); instead, it SHOULD request IPv4 205 updates by sending requests with the AE field being set to 1 (IPv4). 207 When receiving requests, AEs 1 (IPv4) and 4 (v4-via-v6) MUST be 208 treated in the same manner: the receiver processes the request as 209 described in Section 3.8 of [RFC8966]. If an Update is sent, then it 210 MAY be an ordinary IPv4 announcement (AE = 1) or an v4-via-v6 211 announcement (AE = 4), as described in Section 2.1 above, 212 irrespective of which AE was used in the request. 214 When receiving a request with AE 0 (wildcard), the receiver SHOULD 215 send a full route dump, as described in Section 3.8.1.1 of [RFC8966]. 216 Any IPv4 routes contained in the route dump may use either AE 1 217 (IPv4) or AE 4 (v4-via-v6), as described Section 2.1 above. 219 2.4. Other TLVs 221 The only other TLVs defined by [RFC8966] that carry an AE field are 222 Next Hop and IHU. Next Hop and IHU TLVs MUST NOT carry the AE 4 (v4- 223 via-v6). 225 3. ICMPv4 and PMTU discovery 227 The Internet Control Message Protocol (ICMPv4, or simply ICMP) 228 [RFC0792] is a protocol related to IPv4 that is primarily used to 229 carry diagnostic and debugging information. ICMPv4 packets may be 230 originated by end hosts (e.g., the "destination unreachable, port 231 unreachable" ICMPv4 packet), but they may also be originated by 232 intermediate routers (e.g., most other kinds of "destination 233 unreachable" packets). 235 Some protocols deployed in the Internet rely on ICMPv4 packets sent 236 by intermediate routers. Most notably, path MTU Discovery (PMTUd) 237 [RFC1191] is an algorithm executed by end hosts to discover the 238 maximum packet size that a route is able to carry. While there exist 239 variants of PMTUd that are purely end-to-end [RFC4821], the variant 240 most commonly deployed in the Internet has a hard dependency on 241 ICMPv4 packets originated by intermediate routers: if intermediate 242 routers are unable to send ICMPv4 packets, PMTUd may lead to 243 persistent blackholing of IPv4 traffic. 245 Due to this kind of dependency, every Babel router that is able to 246 forward IPv4 traffic MUST be able originate ICMPv4 traffic. Since 247 the extension described in this document enables routers to forward 248 IPv4 traffic received over an interface that has not been assigned an 249 IPv4 address, a router implementing this extension MUST be able to 250 originate ICMPv4 packets even when the outgoing interface has not 251 been assigned an IPv4 address. 253 In such a situation, if a Babel router has an interface that has been 254 assigned an IPv4 address (other than the loopback address), or if an 255 IPv4 address has been assigned to the router itself (to the "loopback 256 interface"), then that IPv4 address may be used as the source of 257 originated ICMPv4 packets. If no IPv4 address is available, a Babel 258 router could use the experimental mechanism described in Requirement 259 R-22 of Section 4.8 [RFC7600], which consists of using the dummy 260 address 192.0.0.8 as the source address of originated ICMPv4 packets. 261 Note however that using the same address on multiple routers may 262 hamper debugging and fault isolation, e.g., when using the 263 "traceroute" utility. 265 4. Protocol encoding 267 This extension defines the v4-via-v6 AE, whose value is 4. This AE 268 is solely used to tag network prefixes, and MUST NOT be used to tag 269 neighbour addresses, e.g. in Next Hop or IHU TLVs. 271 This extension defines no new TLVs or sub-TLVs. 273 4.1. Prefix encoding 275 Network prefixes tagged with AE 4 (v4-via-v6) MUST be encoded and 276 decoded just like prefixes tagged with AE 1 (IPv4), as described in 277 Section 4.3.1 of [RFC8966]. 279 A new compression state for AE 4 (v4-via-v6) distinct from that of AE 280 1 (IPv4) is introduced, and MUST be used for address compression of 281 prefixes tagged with AE 4, as described in Sections 4.5 and 4.6.9 of 282 [RFC8966] 284 4.2. Changes to existing TLVs 286 The following TLVs MAY be tagged with AE 4 (v4-via-v6): 288 * Update (Type = 8) 290 * Route Request (Type = 9) 292 * Seqno Request (Type = 10) 294 As AE 4 (v4-via-v6) is suitable only for network prefixes, IHU 295 (Type = 5) and Next-Hop (Type = 7) TLVs are never sent with AE 4. 296 Such (incorrect) TLVs MUST be ignored upon reception. 298 4.2.1. Update 300 An Update (Type = 8) TLV with AE 4 is constructed as described in 301 Section 4.6.9 of [RFC8966] for AE 1 (IPv4), with the following 302 specificities: 304 * Prefix. The Prefix field is constructed according to Section 4.1 305 above. 307 * Next Hop. The next hop is built and prased as described in 308 Section 2.1 and Section 2.2 above. 310 4.2.2. Requests 312 When tagged with the AE 4, Route Request and Seqno Request updates 313 MUST be constructed and decoded as described in Section 4.6 of 314 [RFC8966], and the network prefixes contained within them decoded as 315 described in Section 4.1 above (see also Section 2.3). 317 5. Backwards compatibility 319 This protocol extension adds no new TLVs or sub-TLVs. 321 This protocol extension uses a new AE. As discussed in Appendix D of 322 [RFC8966] and specified in the same document, implementations that do 323 not understand the present extension will silently ignore the various 324 TLVs that use this new AE. As a result, incompatible versions will 325 ignore v4-via-v6 routes. They will also ignore requests with AE 4, 326 which, as stated in Section 2.3, are not recommended. 328 Using a new AE introduces a new compression state, used to parse the 329 network prefixes. As this compression state is separate from other 330 AEs' states, it will not interfere with the compression state of 331 unextended nodes. 333 This extension reuses the next-hop state from AEs 2 and 3 (IPv6), but 334 makes no changes to the way in which it is updated, and therefore 335 causes no compatibility issues. 337 As mentioned in Section 2.1, ordinary IPv4 announcements are 338 preferred to v4-via-v6 announcements when the outgoing interface has 339 an assigned IPv4 address; doing otherwise would prevent routers that 340 do not implement this extension from learning the route being 341 announced. 343 6. IANA Considerations 345 IANA has allocated value 4 in the "Babel Address Encodings" registry 346 as follows: 348 +====+===========+=================+ 349 | AE | Name | Reference | 350 +====+===========+=================+ 351 | 4 | v4-via-v6 | (this document) | 352 +----+-----------+-----------------+ 354 Table 1 356 7. Security Considerations 358 The extension defined in this document does not fundamentally change 359 the security properties of the Babel protocol. However, by allowing 360 IPv4 routes to be propagated across routers that have not been 361 assigned IPv4 addresses, it might invalidate the assumptions made by 362 network administrators, which could conceivably lead to security 363 issues. 365 For example, if an island of IPv4-only hosts is separated from the 366 IPv4 Internet by routers that have not been assigned IPv4 addresses, 367 a network administrator might reasonably assume that the IPv4-only 368 hosts are unreachable from the IPv4 Internet. This assumption is 369 broken if the intermediary routers implement the extension described 370 in this document, which might expose the IPv4-only hosts to traffic 371 from the IPv4 Internet. If this is undesirable, the flow of IPv4 372 traffic must be restricted by the use of suitable filtering rules 373 (Appendix C of [RFC8966]) together with matching packet filters in 374 the data plane. 376 8. Acknowledgments 378 This protocol extension was originally designed, described and 379 implemented in collaboration with Theophile Bastian. Margaret Cullen 380 pointed out the issues with ICMP and helped coin the phrase "v4-via- 381 v6". The author is also indebted to Donald Eastlake, Toke Hoiland- 382 Jorgensen, David Schinazi, and Donald Sharp. 384 9. References 386 9.1. Normative References 388 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 389 RFC 792, DOI 10.17487/RFC0792, September 1981, 390 . 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, 394 DOI 10.17487/RFC2119, March 1997, 395 . 397 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 398 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 399 May 2017, . 401 [RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing 402 Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021, 403 . 405 9.2. Informative References 407 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 408 Converting Network Protocol Addresses to 48.bit Ethernet 409 Address for Transmission on Ethernet Hardware", STD 37, 410 RFC 826, DOI 10.17487/RFC0826, November 1982, 411 . 413 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 414 DOI 10.17487/RFC1191, November 1990, 415 . 417 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 418 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 419 . 421 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 422 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 423 DOI 10.17487/RFC4861, September 2007, 424 . 426 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 427 Layer Reachability Information with an IPv6 Next Hop", 428 RFC 5549, DOI 10.17487/RFC5549, May 2009, 429 . 431 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 432 Addressing inside an IPv6 Network", RFC 7404, 433 DOI 10.17487/RFC7404, November 2014, 434 . 436 [RFC7600] Despres, R., Jiang, S., Ed., Penno, R., Lee, Y., Chen, G., 437 and M. Chen, "IPv4 Residual Deployment via IPv6 - A 438 Stateless Solution (4rd)", RFC 7600, DOI 10.17487/RFC7600, 439 July 2015, . 441 Author's Address 443 Juliusz Chroboczek 444 IRIF, University of Paris 445 Case 7014 446 75205 Paris Cedex 13 447 France 448 Email: jch@irif.fr