idnits 2.17.1 draft-chroboczek-int-v4-via-v6-01.txt: -(6): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area J. Chroboczek 3 Internet-Draft IRIF, University of Paris 4 Intended status: Standards Track W. Kumari 5 Expires: 8 September 2022 Google, LLC 6 T. Høiland-Jørgensen 7 Red Hat 8 7 March 2022 10 IPv4 routes with an IPv6 next hop 11 draft-chroboczek-int-v4-via-v6-01 13 Abstract 15 We propose "v4-via-v6" routing, a technique that uses IPv6 next-hop 16 addresses for routing IPv4 packets, thus making it possible to route 17 IPv4 packets across a network where routers have not been assigned 18 IPv4 addresses. We describe the technique, and discuss its 19 operational implications. 21 About This Document 23 This note is to be removed before publishing as an RFC. 25 The latest revision of this draft can be found at 26 https://wkumari.github.io/draft-chroboczek-int-v4-via-v6/draft- 27 chroboczek-int-v4-via-v6.html. Status information for this document 28 may be found at https://datatracker.ietf.org/doc/draft-chroboczek- 29 int-v4-via-v6/. 31 Source for this draft and an issue tracker can be found at 32 https://github.com/wkumari/draft-chroboczek-int-v4-via-v6. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 8 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 68 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Structure of the routing table . . . . . . . . . . . . . 4 70 3.2. Operation of the forwarding plane . . . . . . . . . . . . 4 71 3.3. Operation of routing protocols . . . . . . . . . . . . . 4 72 3.3.1. Distance-vector routing protocols . . . . . . . . . . 5 73 3.3.2. Link-state routing protocols . . . . . . . . . . . . 5 74 4. ICMP Considerations . . . . . . . . . . . . . . . . . . . . . 5 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 7.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The dominant form of routing in the Internet is next-hop routing, 86 where a routing protocol constructs a routing table which is used by 87 a forwarding process to forward packets. The routing table is a data 88 structure that maps network prefixes in a given family (IPv4 or IPv6) 89 to next hops, pairs of an outgoing interface and a neighbor's network 90 address, for example: 92 destination next hop 93 2001:db8:0:1::/64 eth0, fe80::1234:5678 94 203.0.113.0/24 eth0, 192.0.2.1 96 When a packet is routed according to a given routing table entry, the 97 forwarding plane uses a neighbor discovery protocol (the Neighbor 98 Discovery protocol (ND) [rfc4861] in the case of IPv6, the Address 99 Resolution Protocol (ARP) [rfc0826] in the case of IPv4) to map the 100 next-hop address to a link-layer address (a "MAC address"), which is 101 then used to construct the link-layer frames that encapsulate 102 forwarded packets. 104 It is apparent from the description above that there is no 105 fundamental reason why the destination prefix and the next-hop 106 address should be in the same address family: there is nothing 107 preventing an IPv6 packet from being routed through a next hop with 108 an IPv4 address (in which case the next hop's MAC address will be 109 obtained using ARP), or, conversely, an IPv4 packet from being routed 110 through a next hop with an IPv6 address. (In fact, it is even 111 possible to store link-layer addresses directly in the next-hop entry 112 of the routing table, thus avoiding the use of an address resolution 113 protocol altogether, which is commonly done in networks using the OSI 114 protocol suite). 116 The case of routing IPv4 packets through an IPv6 next hop is 117 particularly interesting, since it makes it possible to build 118 networks that have no IPv4 addresses except at the edges and still 119 provide IPv4 connectivity to edge hosts. In addition, since an IPv6 120 next hop can use a link-local address that is autonomously 121 configured, the use of such routes enables a mode of operation where 122 the network core has no statically assigned IP addresses of either 123 family, which significantly reduces the amount of manual 124 configuration required. (See also [rfc7404] for a discussion of the 125 issues involved with such an approach.) 127 We call a route towards an IPv4 prefix that uses an IPv6 next hop a 128 "v4-via-v6" route. 130 This document discusses the protocol design and operations 131 implications of such routes and is designed to be used as a reference 132 for future documents. 134 { Editor note, to be removed before publication. This document is 135 heavily based on draft-ietf-babel-v4viav6. When draft-ietf-babel- 136 v4viav6 was going through IESG eval, Warren raised concerns that 137 something this fundamental deserved to be documented in a separate, 138 standalone document, so that it can be more fully discussed, and, 139 more importantly, referenced cleanly in the future. } 141 2. Conventions and Definitions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 3. Operation 151 Next-hop routing is implemented by two separate components, the 152 routing protocol and the forwarding plane, that communicate through a 153 shared data structure, the routing table. 155 3.1. Structure of the routing table 157 The routing table is a data structure that maps address prefixes to 158 next-hops, pairs of the form (interface, address). In traditional 159 next-hop routing, the routing table maps IPv4 prefixes to IPv4 next 160 hops, and IPv6 addresses to IPv6 next hops. With v4-via-v6 routing, 161 the routing table is extended so that an IPv4 prefix may map to 162 either an IPv4 or an IPv6 next hop. 164 3.2. Operation of the forwarding plane 166 The forwarding plane is the part of the routing implementation that 167 is executed for every forwarded packet. As a packet arrives, the 168 forwarding plane consults the routing table, selects a single route 169 matching the packet, determines the next-hop address, and forwards 170 the packet to the next-hop address. 172 With v4-via-v6 routing, the address family of the next-hop address is 173 no longer dermined by the address family of the prefix: since the 174 routing table may map an IPv4 prefix to either an IPv4 or an IPv6 175 next-hop, the forwarding plane must be able to determine, on a per- 176 packet basis, whether the next-hop address is an IPv4 or an IPv6 177 address, and to use that information in order to choose the right 178 address resolution protocol to use (ARP for IP4, ND for IPv6). 180 3.3. Operation of routing protocols 182 The routing protocol is the part of the routing implementation that 183 is executed asynchronously from the forwarding plane, and whose role 184 is to build the routing table. Since v4-via-v6 routing is a 185 generalisation of traditional next-hop routing, v4-via-v6 can 186 interoperate with existing routing protocols: a traditional routing 187 protocol produces a traditional next-hop routing table, which can be 188 used by an implementation supporting v4-via-v6 routing. 190 However, in order to use the additional flexibility provided by 191 v4-via-v6 routing, routing protocols will need to be extended with 192 the ability to populate the routing table with v4-via-v6 routes when 193 an IPv4 address is not available or when the available IPv4 addresses 194 are not suitable for use as a next-hop (e.g., not stable enough). 196 3.3.1. Distance-vector routing protocols 198 3.3.2. Link-state routing protocols 200 4. ICMP Considerations 202 The Internet Control Message Protocol (ICMPv4, or simply ICMP) 203 [rfc0792] is a protocol related to IPv4 that is primarily used to 204 carry diagnostic and debugging information. ICMPv4 packets may be 205 originated by end hosts (e.g., the "destination unreachable, port 206 unreachable" ICMPv4 packet), but they may also be originated by 207 intermediate routers (e.g., most other kinds of "destination 208 unreachable" packets). 210 Some protocols deployed in the Internet rely on ICMPv4 packets sent 211 by intermediate routers. Most notably, path MTU Discovery (PMTUd) 212 [rfc1191] is an algorithm executed by end hosts to discover the 213 maximum packet size that a route is able to carry. While there exist 214 variants of PMTUd that are purely end-to-end [rfc4821], the variant 215 most commonly deployed in the Internet has a hard dependency on 216 ICMPv4 packets originated by intermediate routers: if intermediate 217 routers are unable to send ICMPv4 packets, PMTUd may lead to 218 persistent black-holing of IPv4 traffic. 220 Due to this kind of dependency, every router that is able to forward 221 IPv4 traffic SHOULD be able originate ICMPv4 traffic. Since the 222 extension described in this document enables routers to forward IPv4 223 traffic received over an interface that has not been assigned an IPv4 224 address, a router implementing this extension MUST be able to 225 originate ICMPv4 packets even when the outgoing interface has not 226 been assigned an IPv4 address. 228 In such a situation, if the router has an interface that has been 229 assigned an IPv4 address (other than the loopback address), or if an 230 IPv4 address has been assigned to the router itself (to the "loopback 231 interface"), then that IPv4 address may be used as the source of 232 originated ICMPv4 packets. If no IPv4 address is available, the 233 router could use the experimental mechanism described in Requirement 234 R-22 of Section 4.8 [rfc7600], which consists of using the dummy 235 address 192.0.0.8 as the source address of originated ICMPv4 packets. 236 Note however that using the same address on multiple routers may 237 hamper debugging and fault isolation, e.g., when using the 238 "traceroute" utility. 240 {Editor note: It would be surprising to many operators to see 241 something like: 243 > $ traceroute -n 8.8.8.8 244 traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets 245 1 192.168.0.1 1.894 ms 1.953 ms 1.463 ms 246 2 192.0.0.8 9.012 ms 8.852 ms 12.211 ms 247 3 192.0.0.8 8.445 ms 9.426 ms 9.781 ms 248 4 192.0.0.8 9.984 ms 10.282 ms 10.763 ms 249 5 192.0.0.8 13.994 ms 13.031 ms 12.948 ms 250 6 192.0.0.8 27.502 ms 26.895 ms 251 7 8.8.8.8 26.509 ms 253 Is this a problem though? If this becomes common practice, will 254 operators just come to understand that the repeated 192.0.0.8 is not 255 actually a looping packet, but rather that the packet is (probably!) 256 making forward progress? What if it goes: 192.168.0.1 -> 192.0.0.8 257 -> 10.10.10.10 -> 192.0.0.8 -> 172.16.14.2 -> dest? } 259 { Editor note / question: 192.0.0.8 is assigned in the 260 [IANA-IPV4-REGISTRY] as the "IPv4 dummy address". It may be used as 261 a Source Address, and was requested in [rfc7600] to be used as the 262 IPv4 source address when synthesizing an ICMPv4 packet to mirror an 263 ICMPv6 error message. This is all fine and good - but, 192.0.0.0/24 264 is commonly considered a bogon or martian 266 Example (from a Juniper router): 268 wkumari@rtr2.pao> show route martians 270 inet.0: 271 0.0.0.0/0 exact -- allowed 272 0.0.0.0/8 orlonger -- disallowed 273 127.0.0.0/8 orlonger -- disallowed 274 192.0.0.0/24 orlonger -- disallowed 275 240.0.0.0/4 orlonger -- disallowed 276 224.0.0.0/4 exact -- disallowed 277 224.0.0.0/24 exact -- disallowed 279 This means that these packets are likely to be filtered in many 280 places, and so ICMP packets with this source address are likely to be 281 dropped. Is this a major issue? Would requesting another address be 282 a better solution? Would it help? If it were to be allocated from 283 some more global pool, it would still likely require "magic" to allow 284 it to pass BCP38 filters. } 286 5. Security Considerations 288 The techniques described in this document make routing more flexible 289 by allowing IPv4 routes to propagate across a section of a network 290 that has only been assigned IPv6 addresses. This additional 291 flexibility might invalidate otherwise reasonable assumptions made by 292 network administrators, which could potentially cause security 293 issues. 295 For example, if an island of IPv4-only hosts is separated from the 296 IPv4 Internet by routers that have not been assigned IPv4 addresses, 297 a network administrator might reasonably assume that the IPv4-only 298 hosts are unreachable from the IPv4 Internet. This assumption is 299 broken if the intermediary routers implement v4-via-v6 routing, which 300 might make the IPv4-only hosts reachable from the IPv4 Internet. If 301 this is not desirable, then the network administrator must filter out 302 the undesirable traffic in the forwarding plane by implementing 303 suitable packet filtering rules. 305 6. IANA Considerations 307 This document has no IANA actions. 309 7. References 311 7.1. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, 315 DOI 10.17487/RFC2119, March 1997, 316 . 318 [rfc7600] Despres, R., Jiang, S., Ed., Penno, R., Lee, Y., Chen, G., 319 and M. Chen, "IPv4 Residual Deployment via IPv6 - A 320 Stateless Solution (4rd)", RFC 7600, DOI 10.17487/RFC7600, 321 July 2015, . 323 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 324 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 325 May 2017, . 327 7.2. Informative References 329 [IANA-IPV4-REGISTRY] 330 "IANA IPv4 Address Registry", Web 331 https://www.iana.org/assignments/iana-ipv4-special- 332 registry/. 334 [rfc0792] Postel, J., "Internet Control Message Protocol", STD 5, 335 RFC 792, DOI 10.17487/RFC0792, September 1981, 336 . 338 [rfc0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 339 Converting Network Protocol Addresses to 48.bit Ethernet 340 Address for Transmission on Ethernet Hardware", STD 37, 341 RFC 826, DOI 10.17487/RFC0826, November 1982, 342 . 344 [rfc1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 345 DOI 10.17487/RFC1191, November 1990, 346 . 348 [rfc4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 349 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 350 . 352 [rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 353 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 354 DOI 10.17487/RFC4861, September 2007, 355 . 357 [rfc7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 358 Addressing inside an IPv6 Network", RFC 7404, 359 DOI 10.17487/RFC7404, November 2014, 360 . 362 Acknowledgments 364 TODO acknowledge. 366 Authors' Addresses 368 Juliusz Chroboczek 369 IRIF, University of Paris 370 Case 7014 371 75205 Paris Cedex 13 372 France 373 Email: jch@irif.fr 375 Warren Kumari 376 Google, LLC 377 Email: warren@kumari.net 379 Toke Høiland-Jørgensen 380 Red Hat 381 Email: toke@toke.dk