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