RFC 9079

Abstract ✨

okay bestie, let's get into it 🦋 this is RFC 9079, Source-Specific Routing in the Babel Routing Protocol. The authors are M. Boutier and J. Chroboczek from IRIF at the University of Paris. It's a Standards Track doc, dated August 2021, with ISSN 2070-1721. The header doesn't list any Obsoletes or Updates, so it's not replacing or changing another RFC 💅

Source-specific routing (also called Source Address Dependent Routing, or SADR) is an upgrade to normal next-hop routing, where packets get forwarded based on both their destination address AND their source address 👀 This doc describes how to add that to the Babel routing protocol 🧚

Status of This Memo 🌸

This is an Internet Standards Track document.

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841.

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9079.

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) as they stand on the date this document was published. Please read these carefully, because they explain your rights and restrictions for this doc. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 📜

Table of Contents 🍓

1.  Introduction and Background
  1.1.  Application to Multihoming
  1.2.  Other Applications
  1.3.  Specificity of Prefix Pairs
2.  Specification of Requirements
3.  Data Structures
  3.1.  The Source Table
  3.2.  The Route Table
  3.3.  The Table of Pending Seqno Requests
4.  Data Forwarding
5.  Protocol Operation
  5.1.  Protocol Messages
  5.2.  Wildcard Messages
6.  Compatibility with the Base Protocol
  6.1.  Starvation and Blackholes
7.  Protocol Encoding
  7.1.  Source Prefix Sub-TLV
  7.2.  Source-Specific Update
  7.3.  Source-Specific Route Request
  7.4.  Source-Specific Seqno Request
8.  IANA Considerations
9.  Security Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction and Background ✨

okay so the Babel routing protocol [RFC8966] is a distance vector routing protocol for next-hop routing 🦋 In next-hop routing, every node keeps a forwarding table that maps destination prefixes to next hops. The forwarding decision is made per packet, and it depends on the packet's destination address and the entries in that table. When a packet is about to be routed, its destination address gets compared against the prefixes in the routing table. The entry with the most specific prefix that contains the destination address wins, and the packet goes to the matching next hop. Next-hop routing is simple, well understood, and works fine in a huge number of cases 💅

BUT it's kinda limiting in two ways 😭 First, since each router makes its own decision, router A can only pick a route ABC...Z if its neighbouring router B already picked the route BC...Z. Second, the only thing a router uses to choose a route is the destination address, so two packets with the same destination always take the same route. Like, there's other stuff in the IP header that could help guide the decision, such as the Type of Service (ToS) octet and, of course, the source address 👀

Source-specific routing [SS-ROUTING], or Source Address Dependent Routing (SADR), is a modest upgrade to next-hop routing 🌈 The forwarding decision depends not only on the destination address but also on the source address of the packet being routed. That means two packets with the same destination but different source addresses can follow different paths 🔥

This document describes a source-specific routing extension for the Babel routing protocol [RFC8966]. It makes some minor changes to the data structures. They now have to include a source prefix in addition to the destination prefix they already had. It also changes the Update, Route Request, and Seqno Request TLVs, which get extended with a source prefix. The source prefix is encoded using a mandatory sub-TLV ([RFC8966], Section 4.4) ✨

1.1. Application to Multihoming 🌸

Multihoming is when a single network connects to two or more transit networks 🧚 The main use for source-specific routing is a form of multihoming called "multihoming with multiple addresses".

Classical multihoming means assigning a provider-independent range of addresses to the multihomed network and announcing it to all transit providers. This works great for big networks, but for small networks, the cost of getting a provider-independent address range and announcing it globally on the Internet is prohibitive 😩 And you can't do classical multihoming with ordinary provider-dependent addresses. Picture a network connected to two providers, A and B. A packet with a source address allocated by A needs to go through the edge router connected to A. If it goes through the edge router connected to B instead, it will most likely be filtered (dropped), in accordance with [BCP84] 💀

In multihoming with multiple addresses, every host in the multihomed network gets multiple addresses, one for each transit provider 🎀 Extra mechanisms are needed to do two things: (i) choose, for each packet, a source address tied to a provider that's currently up, and (ii) route each packet toward the router connected to the provider linked with its source address. You could argue that multihoming with multiple addresses splits the tough multihoming problem into two simpler sub-problems. Iconic, honestly 👑

Choosing a suitable source address is a decision made locally by the sending host, and it's an area of active research 🔬 The simplest solution is to use a traditional transport-layer protocol, like TCP, and probe all available source addresses at connection time, the same way it's already done with destination addresses. You can probe them sequentially [RFC6724] or in parallel [RFC8305]. But since the transport-layer protocol doesn't know about the multiple addresses, flows get interrupted when the selected provider goes down. From the user's point of view, all TCP connections drop when the network environment changes 😭 A better experience comes from making all the potential source and destination addresses available to higher-layer protocols, either at the transport layer [RFC8684] [RFC4960] or at the application layer [RFC8445] 🫶

Source-specific routing solves the problem of routing a packet to the edge router indicated by its source address. Every edge router announces a default route into the routing domain, specific to the prefix associated with the provider it's connected to. That route gets propagated all the way to the routers on the access link, which can therefore route every packet to the correct router 🦋 Hosts just send packets to their default router, so no host changes are needed at the network layer. Zero host drama ✨

1.2. Other Applications 💜

Besides multihoming with multiple addresses, the authors know of two other applications of source-specific routing 🌈 The first is tunnels and VPNs. These are packet encapsulation techniques commonly used on the Internet to build a network-layer topology that's different from the physical one. In some deployments, the default route points at the tunnel. That makes the network stack try to send encapsulated packets through the tunnel, which makes it break 🙈 There are various fixes, and the most common is to point a host route at the tunnel endpoint.

With source-specific routing, it becomes possible to announce a default route through the tunnel that's specific to the prefix the tunnel serves. The encapsulated packets have a source address outside that prefix, so they don't get routed through the tunnel anymore. Problem solved, bestie 💖

The third application is controlled anycast. Anycast is a technique where a single destination address stands in for multiple network endpoints, collectively called an "anycast group" 🧚 A packet sent to the anycast group gets routed to an arbitrary member of the group, usually the one nearest according to the routing protocol.

Anycast's randomness is fine for a lot of applications, like DNS root servers. Some applications need finer control though 💅 For example, in some Content Distribution Networks (CDNs), every endpoint is expected to handle a well-defined subset of the client population. With source-specific routing, each member of the anycast group can announce a route specific to its own client population. That's both simpler and more robust than manually tweaking the routing protocol's metric ("prepending" in BGP) 🌸

1.3. Specificity of Prefix Pairs 💅

okay so in normal next-hop routing, when more than one routing table entry matches a packet's destination, the "longest prefix rule" says the most specific entry wins 🎯 and honestly it makes sense because the set of prefixes has this "tree property":

For any prefixes P and P', either P and P' are disjoint, or one is
more specific than the other.

so it would be super natural to order pairs of prefixes pointwise, meaning (D,S) is more specific than (D',S') when D is more specific than D and S is more specific than S' 🤔 but the set of pairs with the pointwise ordering does NOT satisfy the tree property 💀 check these two pairs:

(2001:db8:0:1::/64, ::/0) and (::/0, 2001:db8:0:2::/64)

they're not disjoint (a packet with destination 2001:db8:0:1::1 and source 2001:db8:0:2::1 matches both), but neither one is more specific than the other. so there's no natural, unambiguous way to read a routing table like this:

             destination                source     next-hop
       2001:db8:0:1::/64                  ::/0            A
                    ::/0     2001:db8:0:2::/64            B

we need a finer ordering of pairs of prefixes to avoid every ambiguity 🫶 there are two natural choices:

• destination-first ordering, where (D,S) is more specific than (D',S') when
  • D is strictly more specific than D', or
  • D = D', and S is more specific than S'
• source-first ordering, which is the symmetric version: sources get compared first and destinations second.

leaving the choice up to the implementation sounds tempting, but it's not an option 🙅‍♀️ all routers in a routing domain must use the same ordering, or persistent routing loops can happen. picture this topology:

      A --- B --- C --- D

say A announces a route for (::/0, 2001:db8:0:2::/64), and D announces a route for (2001:db8:0:1::/64, ::/0). now say B uses destination-first ordering and C uses source-first ordering. a packet that matches both routes, like one with destination 2001:db8:0:1::1 and source 2001:db8:0:2::1, would get sent by B toward D and by C toward A. so it would loop forever between B and C 😭

this document mandates (Section 4) that all routers use destination-first ordering, which is generally believed to be more useful than source-first ordering ✨ check this topology, where A is an edge router connected to the Internet and B is an internal router connected to an access network N:

  (::/0, S)             (D, ::/0)
   Internet --- A --- B --- N

A announces a source-specific default route with source S, (::/0, S), while B announces a nonspecific route to prefix D. now think about a packet with a destination in D and a source in S. with destination-first ordering, the packet gets routed toward network N, which is the only way it can ever reach its destination 🎀 with source-first ordering, though, the packet gets sent toward the Internet, with zero hope of reaching its destination in N 💔

2. Specification of Requirements ✨

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.

3. Data Structures 🧚

A bunch of the conceptual data structures described in Section 3.2 of [RFC8966] contain a destination prefix. this spec extends those data structures with a source prefix 🌸 data from the original protocol that doesn't specify a source prefix gets stored with a zero-length source prefix. that matches the exact same set of packets as the original, non-source-specific data, so it's all good 💖

3.1. The Source Table 🦋

every Babel node maintains a source table, as described in [RFC8966], Section 3.2.5. a source-specific Babel node extends this table with the following field:

• The source prefix (sprefix, splen) specifying the source address of packets to which this entry applies.

the source table is now indexed by 5-tuples of the form (prefix, plen, sprefix, splen, router-id).

note that the route entry contains a source (see Sections 2 and 3.2.5 of [RFC8966]) that itself contains both destination and source prefixes. these are two different concepts and must not be confused 🙈

3.2. The Route Table 🗺️

every Babel node maintains a route table, as described in [RFC8966], Section 3.2.6. each route table entry contains, among other data, a source, which this specification extends with a source prefix as described above. the route table is now indexed by 5-tuples of the form (prefix, plen, sprefix, splen, neighbour), where the first four components are obtained from the source 💜

3.3. The Table of Pending Seqno Requests 📝

every Babel node maintains a table of pending seqno requests, as described in [RFC8966], Section 3.2.7. a source-specific Babel node extends this table with the following entry:

• The source prefix (sprefix, splen) being requested.

the table of pending seqno requests is now indexed by 5-tuples of the form (prefix, plen, sprefix, splen, router-id).

4. Data Forwarding 🚀

as noted in Section 1.3, source-specific tables can, in general, be ambiguous, so all routers in a routing domain must use the same algorithm for choosing applicable routes. an implementation of the extension described in this document MUST choose routing table entries by using destination-first ordering, where routing table entry R1 is preferred to routing table entry R2 when either R1's destination prefix is more specific than R2's or the destination prefixes are equal and R1's source prefix is more specific than R2's 👑

in practice, this means a source-specific Babel implementation must take care that any lower layer that does packet forwarding obeys these semantics. more precisely:

• if the lower layers implement destination-first ordering, then the Babel implementation SHOULD use them directly;
• if the lower layers can hold source-specific routes but not with the right semantics, then the Babel implementation MUST either silently ignore any source-specific routes or disambiguate the routing table by using a suitable disambiguation algorithm (see Section V.B of [SS-ROUTING] for such an algorithm);
• if the lower layers cannot hold source-specific routes, then a Babel implementation MUST silently ignore any source-specific routes.

5. Protocol Operation 🎀

this extension doesn't fundamentally change how the Babel protocol operates, so we only describe the differences between the original protocol and the extended protocol 🫶

in the original protocol, three TLVs carry a destination prefix: Update, Route Request, and Seqno Request TLVs. this spec extends these messages so they may carry a Source Prefix sub-TLV, as described in Section 7. the sub-TLV is marked as mandatory, so an unextended implementation will silently ignore the whole enclosing TLV. a node obeying this specification MUST NOT send a TLV with a zero-length source prefix; instead, it sends a TLV with no Source Prefix sub-TLV. conversely, an extended implementation MUST interpret an unextended TLV as carrying a source prefix of zero length. taken together, these properties keep the original and extended protocols interoperable (see Section 6) 🌈

5.1. Protocol Messages 💌

this extension lets three TLVs of the original Babel protocol carry a source prefix: Update TLVs, Route Request TLVs, and Seqno Request TLVs.

to advertise a route with a non-zero length source prefix, a node sends a source-specific update, i.e., an update with a Source Prefix sub-TLV. when a node receives a source-specific update (prefix, source prefix, router-id, seqno, metric) from a neighbour neigh, it behaves as described in [RFC8966], Section 3.5.3, except that the entry under consideration is indexed by (prefix, plen, sprefix, splen, neigh) rather than just (prefix, plen, neigh) ✨

similarly, when a node needs to send a request of either kind that applies to a route with a non-zero length source prefix, it sends a source-specific request, i.e., a request with a Source Prefix sub-TLV. when a node receives a source-specific request, it behaves as described in Section 3.8 of [RFC8966], except that the request applies to the route table entry carrying the source prefix indicated by the Source Prefix sub-TLV 🦋

5.2. Wildcard Messages 🌟

in the original protocol, the address encoding (AE) value 0 is used for wildcard messages: messages that apply to all routes of any address family and with any destination prefix. wildcard messages are allowed in two places in the protocol. wildcard retractions retract all of the routes previously advertised by a node on a given interface, and wildcard route requests request a full dump of the route table from a given node. wildcard messages are meant to apply to all routes, including routes decorated with additional data and AE values to be defined by future extensions. so this specification extends wildcard operations to apply to all routes, whatever the value of the source prefix 💅

more precisely, a node receiving an update with the AE field set to 0 and the Metric field set to infinity (a wildcard retraction) MUST apply the route acquisition procedure described in Section 3.5.3 of [RFC8966] to all of the routes that it has learned from the sending node, whatever the value of the source prefix. a node MUST NOT send a wildcard retraction with an attached source prefix, and a node that receives a wildcard retraction with a source prefix MUST ignore the retraction. ⚠️

similarly, a node that receives a route request with the AE field set to 0 (a wildcard route request) SHOULD send a full routing table dump, including routes with a non-zero length source prefix. a node MUST NOT send a wildcard request that carries a source prefix, and a node receiving a wildcard request with a source prefix MUST ignore the request 🙈

6. Compatibility with the Base Protocol 🫧

the protocol extension defined in this document is, to a great extent, interoperable with the base protocol defined in [RFC8966] (and all previously standardised extensions). more precisely, if non-source-specific routers and source-specific routers are mixed in a single routing domain, Babel's loop-avoidance properties are preserved, and in particular, no persistent routing loops will occur 🥹

however, this extension is encoded using mandatory sub-TLVs, introduced in [RFC8966], so it is not compatible with the older version of the Babel routing protocol [RFC6126], which does not support mandatory sub-TLVs. because of this, this extension MUST NOT be used in a routing domain in which some routers implement [RFC6126]; otherwise, persistent routing loops may occur 🚫💀

6.1. Starvation and Blackholes 🕳️

okay so bestie, if non-source-specific routers keep throwing away source-specific routes, route starvation is gonna happen 😭. Like, unless the network has enough non-source-specific routes floating around, those routers are gonna starve and drop packets for destinations that only source-specific routers announce 💀. It's giving blackhole energy, fr.

In the usual setup, all the source-specific routes come from a small group of edge routers 🌸. In that case, the simple yet sufficient fix is to build a connected source-specific backbone that includes every single edge router, then announce a non-source-specific default route towards that backbone 🦋. Easy win, no cap.

7. Protocol Encoding 🎀

okay this part is where the new sub-TLV comes in ✨. It's called the Source Prefix sub-TLV, and it carries a source prefix. You can attach it to an Update, Route Request, or Seqno Request TLV, and it matches a source-specific entry in the route table together with the destination prefix those TLVs already carry 🫶.

A source-specific route only has one destination prefix and one source prefix, so a source-specific message carries exactly one Source Prefix sub-TLV 💅.

Rule time 🚨: a node MUST NOT send more than one Source Prefix sub-TLV in a TLV. And if a node gets more than one in a single TLV, it MUST ignore that TLV. It MAY ignore the whole packet too 👑.

7.1. Source Prefix Sub-TLV 🌸

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 128  |    Length     |  Source Plen  | Source Prefix...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Here's the breakdown of the fields 🧚:

• Type is set to 128, which marks it as a Source Prefix sub-TLV.
• Length is the body length in octets, not counting the Type and Length fields themselves.
• Source Plen is how long the advertised source prefix is, in bits. It MUST NOT be 0 🙅.
• Source Prefix is the source prefix being advertised 🌈. Its size is (Source Plen)/8 octets, rounded upwards.

The body is normally 1+(Source Plen)/8 rounded upwards. If the Length field says it's smaller than that, the sub-TLV is corrupt and the whole enclosing TLV must be ignored 💀. If Length says it's bigger, then the extra octets in the sub-TLV MUST be silently ignored 🤫.

The contents of the Source Prefix sub-TLV get interpreted based on the AE of the enclosing TLV. If a TLV with AE equal to 0 contains a Source Prefix sub-TLV, then the whole enclosing TLV MUST be ignored. If a TLV contains multiple Source Prefix sub-TLVs, then the whole TLV MUST be ignored 🙈.

Also, this sub-TLV is a mandatory sub-TLV 🔒. So, as described in Section 4.4 of [RFC8966], the whole TLV MUST be ignored if that sub-TLV is not understood (or malformed).

7.2. Source-Specific Update 📣

The source-specific update is an Update TLV with a Source Prefix sub-TLV. It advertises or retracts source-specific routes the same way regular non-source-specific updates do (see [RFC8966]). A wildcard retraction (update with AE equal to 0) MUST NOT carry a Source Prefix sub-TLV 🚫.

Babel uses a stateful compression scheme to shrink the destination prefixes in Update TLVs (see Section 4.5 of [RFC8966]) 🗜️. The source prefix defined by this extension is not compressed. On the other hand, compression is allowed for the destination prefixes carried by source-specific updates. As described in Section 4.5 of [RFC8966], unextended implementations will still correctly update their parser state while otherwise ignoring the whole TLV 🧠.

7.3. Source-Specific Route Request 🙋

A source-specific route request is a Route Request TLV with a Source Prefix sub-TLV. It prompts the receiver to send an update for a given pair of destination and source prefixes, as described in Section 3.8.1.1 of [RFC8966] 📬. A wildcard request (route request with AE equal to 0) MUST NOT carry a Source Prefix sub-TLV. If a wildcard request with a Source Prefix sub-TLV is received, then the request MUST be ignored ❌.

7.4. Source-Specific Seqno Request 🔢

A source-specific seqno request is a Seqno Request TLV with a Source Prefix sub-TLV. It asks the receiving node to perform the procedure described in Section 3.8.1.2 of [RFC8966], but applied to a pair made of a destination prefix and a source prefix 🫧.

8. IANA Considerations 🏷️

IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV in the "Babel Sub-TLV Types" registry 🎟️.

9. Security Considerations 🚨

The extension in this document adds a new sub-TLV to three sub-TLVs already in the original Babel protocol, and it does not change the security properties of the protocol itself 🛡️. However, the extra flexibility from source-specific routing might invalidate assumptions some network administrators are making, and that could conceivably lead to security issues 😬.

For example, an administrator might be tempted to abuse route filtering (Appendix C of [RFC8966]) as a security mechanism. Unless the filtering rules are designed to take source-specific routing into account, a source-specific route might bypass them, and that could cause traffic to reach a part of the network that was thought to be protected 🫣. An administrator might also assume that no route is more specific than a host route, and use a host route to direct traffic for a given destination through a security device (e.g., a firewall). Source-specific routing breaks this assumption, and in some topologies, announcing a source-specific route might conceivably be used to bypass the security device 💀.

🚨 Bestie, this is the big one. Filters and host routes are not the security wall you think they are once source-specific routes show up. Double-check your assumptions before you ship 🫶.

10. References 📚

10.1. Normative References 📖

[BCP84]    Baker, F. and P. Savola, "Ingress Filtering for Multihomed
           Networks", BCP 84, RFC 3704, March 2004.

           Sriram, K., Montgomery, D., and J. Haas, "Enhanced
           Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
           RFC 8704, February 2020.

           <https://www.rfc-editor.org/info/bcp84>

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8966]  Chroboczek, J. and D. Schinazi, "The Babel Routing
           Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021,
           <https://www.rfc-editor.org/info/rfc8966>.

10.2. Informative References 📚

[RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
           RFC 4960, DOI 10.17487/RFC4960, September 2007,
           <https://www.rfc-editor.org/info/rfc4960>.

[RFC6126]  Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
           DOI 10.17487/RFC6126, April 2011,
           <https://www.rfc-editor.org/info/rfc6126>.

[RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
           "Default Address Selection for Internet Protocol Version 6
           (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
           <https://www.rfc-editor.org/info/rfc6724>.

[RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
           Better Connectivity Using Concurrency", RFC 8305,
           DOI 10.17487/RFC8305, December 2017,
           <https://www.rfc-editor.org/info/rfc8305>.

[RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
           Connectivity Establishment (ICE): A Protocol for Network
           Address Translator (NAT) Traversal", RFC 8445,
           DOI 10.17487/RFC8445, July 2018,
           <https://www.rfc-editor.org/info/rfc8445>.

[RFC8684]  Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
           Paasch, "TCP Extensions for Multipath Operation with
           Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
           2020, <https://www.rfc-editor.org/info/rfc8684>.

[SS-ROUTING]
           Boutier, M. and J. Chroboczek, "Source-Specific Routing",
           IFIP Networking Conference,
           DOI 10.1109/IFIPNetworking.2015.7145305, May 2015,
           <http://arxiv.org/pdf/1403.0445>.

Acknowledgments 🫶

The authors are so grateful to Donald Eastlake, Joel Halpern, and Toke Hoiland-Jorgensen for helping out with this document 🙏.

Authors' Addresses 💌

Matthieu Boutier
IRIF, University of Paris
Case 7014
75205 Paris Cedex 13
France

Email: boutier@irif.fr


Juliusz Chroboczek
IRIF, University of Paris
Case 7014
75205 Paris Cedex 13
France

Email: jch@irif.fr