idnits 2.17.1 draft-farinacci-lisp-decent-03.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 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 19 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 266: '... An ITR SHOULD lookup its mapping sy...' RFC 2119 keyword, line 413: '... The Hash Mask MUST include the stri...' RFC 2119 keyword, line 425: '...t messages, xTRs MAY round robin EID l...' RFC 2119 keyword, line 468: '... However, an implementation SHOULD do...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2019) is 1877 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-12) exists of draft-ietf-lisp-ecdsa-auth-00 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-02 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-24 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-17 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental C. Cantrell 5 Expires: September 8, 2019 Nexus 6 March 7, 2019 8 A Decent LISP Mapping System (LISP-Decent) 9 draft-farinacci-lisp-decent-03 11 Abstract 13 This draft describes how the LISP mapping system designed to be 14 distributed for scale can also be decentralized for management and 15 trust. 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 September 8, 2019. 34 Copyright Notice 36 Copyright (c) 2019 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 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Push-Based Mapping System . . . . . . . . . . . . . . . . . . 5 55 4.1. Components of a Pushed-Based LISP-Decent xTR . . . . . . 5 56 4.2. No LISP Protocol Changes . . . . . . . . . . . . . . . . 6 57 4.3. Configuration and Authentication . . . . . . . . . . . . 7 58 4.4. Core Seed-Group . . . . . . . . . . . . . . . . . . . . . 7 59 5. Pull-Based Mapping System . . . . . . . . . . . . . . . . . . 9 60 5.1. Components of a Pulled-Based LISP-Decent xTR . . . . . . 9 61 5.2. Deployment Example . . . . . . . . . . . . . . . . . . . 10 62 5.3. Management Considerations . . . . . . . . . . . . . . . . 11 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 67 8.2. Informative References . . . . . . . . . . . . . . . . . 13 68 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 69 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14 70 B.1. Changes to draft-farinacci-lisp-decent-03 . . . . . . . . 14 71 B.2. Changes to draft-farinacci-lisp-decent-02 . . . . . . . . 14 72 B.3. Changes to draft-farinacci-lisp-decent-01 . . . . . . . . 14 73 B.4. Changes to draft-farinacci-lisp-decent-00 . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 The LISP architecture and protocols [RFC6830] introduces two new 79 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 80 (RLOCs) which is intended to provide overlay network functionality. 81 To map from EID to a set or RLOCs, a control-plane mapping system are 82 used [RFC6836] [RFC8111]. These mapping systems are distributed in 83 nature in their deployment for scalability but are centrally managed 84 by a third- party entity, namely a Mapping System Provider (MSP). 85 The entities that use the mapping system, such as data-plane xTRs, 86 depend on and trust the MSP. They do not participate in the mapping 87 system other than to register and retrieve information to/from the 88 mapping system [RFC6833]. 90 This document introduces a Decentralized Mapping System (DMS) so the 91 xTRs can participate in the mapping system as well as use it. They 92 can trust each other rather than rely on third-party infrastructure. 93 The xTRs act as Map-Servers to maintain distributed state for scale 94 and reducing attack surface. 96 2. Definition of Terms 98 Mapping System Provider (MSP): is an infrastructure service that 99 deploys LISP Map-Resolvers and Map-Servers [RFC6833] and possibly 100 ALT-nodes [RFC6836] or DDT-nodes [RFC8111]. The MSP can be 101 managed by a separate organization other than the one that manages 102 xTRs. This model provides a business separation between who 103 manages and is responsible for the control-plane versus who 104 manages the data-plane overlay service. 106 Decentralized Mapping System (DMS): is a mapping system entity that 107 is not third-party to the xTR nodes that use it. The xTRs 108 themselves are part of the mapping system. The state of the 109 mapping system is fully distributed, decentralized, and the trust 110 relies on the xTRs that use and participate in their own mapping 111 system. 113 Pull-Based Mapping System: the mapping system is pull-based meaning 114 that xTRs will lookup and register mappings by algorithmic 115 transformation to locate which Map-Resolvers and Map-Servers are 116 used. It is required that the lookup and registration uses a 117 consistent algorithmic transformation function. Map-Registers are 118 pushed to specific Map-Servers. Map-Requests are external lookups 119 to Map-Resolvers on xTRs that do not participate in the mapping 120 system and internal lookups when they do. 122 Modulus Value: this value is used in the Pull-Based Mapping System. 123 It defines the number of map-server sets used for the mapping 124 system. The modulus value is used to produce a Name Index used 125 for a DNS lookup. 127 Name Index: this index value is used in the Pull-Based 128 Mapping System. For a mapping system that is configured with a 129 map-server set of DNS names in the form of .domain.com, the 130 name index is prepended to to form the lookup name 131 ..domain.com. If the Modulus Value is 8, then the 132 name indexes are 0 through 7. 134 Hash Mask: The Hash Mask is used in the Pull-Based Mapping System. 135 It is a mask value with 1 bits left justified. The mask is used 136 to select what high-order bits of an EID-prefix is used in the 137 hash function. 139 Push-Based Mapping System: the mapping system is push-based meaning 140 that xTRs will push registrations via IP multicast to a group of 141 Map-Servers and do local lookups acting as their own Map- 142 Resolvers. 144 Replication List Entry (RLE): is an RLOC-record format that contains 145 a list of RLOCs that an ITR replicates multicast packets on a 146 multicast overlay. The RLE format is specified in [RFC8060]. 147 RLEs are used with the Pushed-Based mapping system. 149 Group Address EID: is an EID-record format that contains IPv4 150 (0.0.0.0/0, G) or IPv6 (0::/0, G) state. This state is encoded as 151 a Multicast Info Type LCAF specified in [RFC8060]. Members of a 152 seed-group send Map-Registers for (0.0.0.0/0, G) or (0::/0, G) 153 with an RLOC-record that RLE encodes its RLOC address. Details 154 are specified in [RFC8378]. 156 Seed-Group: is a set of Map-Servers joined to a multicast group for 157 the Push-Based Mapping system or are mapped by DNS names in a 158 Pull-Based Mapping System. A core seed-group is used to bootstrap 159 a set of LISP-Decent xTRs so they can learn about each other and 160 use each other's mapping system service. A seed-group can be 161 pull-based to bootstrap a push-based mapping system. That is, a 162 set of DNS mapped map-servers can be used to join the mapping 163 system's IP multicast group. 165 3. Overview 167 The clients of the Decentralized Mapping System (DMS) are also the 168 providers of mapping state. Clients are typically ETRs that Map- 169 Register EID-to-RLOC mapping state to the mapping database system. 170 ITRs are clients in that they send Map-Requests to the mapping 171 database system to obtain EID-to-RLOC mappings that are cached for 172 data-plane use. When xTRs participate in a DMS, they are also acting 173 as Map-Resolvers and Map-Servers using the protocol machinery defined 174 in LISP control-plane specifications [RFC6833], [I-D.ietf-lisp-sec], 175 and [I-D.ietf-lisp-ecdsa-auth]. The xTRs are not required to run the 176 database mapping transport system protocols specified in [RFC6836] or 177 [RFC8111]. 179 This document will describe two decentralized and distributed mapping 180 system mechanisms. A Push-Based Mapping System uses IP multicast so 181 xTRs can find each other by locally joining an IP multicast group. A 182 Pull-Based Mapping System uses DNS with an algorithmic transformation 183 function so xTRs can find each other. 185 4. Push-Based Mapping System 187 The xTRs are organized in a mapping-system group. The group is 188 identified by an IPv4 or IPv6 multicast group address or using a 189 pull-based approach in described in Section 5. When using multicast, 190 the xTRs join the same multicast group and receive LISP control-plane 191 messages addressed to the group. Messages sent to the multicast 192 group are distributed when the underlay network supports IP multicast 193 [RFC6831] or is achieved with the overlay multicast mechanism 194 described in [RFC8378]. When overlay multicast is used and LISP Map- 195 Register messages are sent to the group, they are LISP data 196 encapsulated with a instance-ID set to 0xffffff in the LISP header. 197 The inner header of the encapsulated packet has the destination 198 address set to the multicast group address and the outer header that 199 is prepended has the destination address set to the RLOC of mapping 200 system member. The members of the mapping system group are kept in 201 the LISP data-plane map-cache so packets for the group can be 202 replicated to each member RLOC. 204 All xTRs in a mapping system group will store the same registered 205 mappings and maintain the state as Map-Servers normally do. The 206 members are not only receivers of the multicast group but also send 207 packets to the group. 209 4.1. Components of a Pushed-Based LISP-Decent xTR 211 When an xTR is configured to be a LISP-Decent xTR (or PxTR 212 [RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP 213 network functions. 215 The following diagram shows 3 LISP-Decent xTRs joined to mapping 216 system group 224.1.1.1. When the ETR function of xTR1 originates a 217 Map-Register, it is sent to all xTRs (including itself) synchronizing 218 all 3 Map-Servers in xTR1, xTR2, and xTR3. The ITR function can 219 populate its map-cache by sending a Map-Request locally to its Map- 220 Resolver so it can replicate packets to each RLOC for EID 224.1.1.1. 222 xTR1 223 Map-Request +--------------------+ 224 (always local) | +-----+ +-----+ | 225 +---------------| ITR | | ETR |-------------+ 226 | | +-----+ +-----+ | | 227 | | | | Map-Register to EID 228 | | +-------+ | | 224.1.1.1 encapsulated to 229 +------------------>| MR/MS |<---------------+ RLOCs xTR1, xTR2, and xTR3 230 | +-------+ | | 231 +--------------------+ | 232 | 233 +--------------------+------------+ 234 | | 235 | | 236 +----------v---------+ +----------v---------+ 237 | +--------+ | | +--------+ | 238 | | MR/MS | | | | MR/MS | | 239 | +--------+ | | +--------+ | 240 | +-----+ +-----+ | | +-----+ +-----+ | 241 | | ITR | | ETR | | | | ITR | | ETR | | 242 | +-----+ +-----+ | | +-----+ +-----+ | 243 +--------------------+ +--------------------+ 244 xTR2 xTR3 246 Note if any external xTR would like to use a Map-Resolver from the 247 mapping system group, it only needs to have one of the LISP-Decent 248 Map-Resolvers configured. By doing a looking to this Map-Resolver 249 for EID 224.1.1,1, the external xTR could get the complete list of 250 members for the mapping system group. 252 For future study, an external xTR could multicast the Map-Request to 253 224.1.1.1 and either one of the LISP-Decent Map-Resolvers would 254 return a Map-Reply or the external xTR is prepared to receive 255 multiple Map-Replies. 257 4.2. No LISP Protocol Changes 259 There are no LISP protocol changes required to support the push-based 260 LISP-Decent set of procedures. However, an implementation that sends 261 Map-Register messages to a multicast group versus a specific Map- 262 Server unicast address must change to call the data-plane component 263 so the ITR functionality in the node can encapsulate the Map-Register 264 as a unicast packet to each member of the mapping system group. 266 An ITR SHOULD lookup its mapping system group address periodically to 267 determine if the membership has changed. The ITR can also use the 268 pubsub capability documented in [I-D.ietf-lisp-pubsub] to be notified 269 when a new member joins or leaves the multicast group. 271 4.3. Configuration and Authentication 273 When xTRs are joined to a multicast group, they must have their site 274 registration configuration consistent. Any policy or authentication 275 key material must be configured correctly and consistently among all 276 members. When [I-D.ietf-lisp-ecdsa-auth] is used to sign Map- 277 Register messages, public-keys can be registered to the mapping 278 system group using the site authentication key mentioned above or 279 using a different authentication key from the one used for 280 registering EID records. 282 4.4. Core Seed-Group 284 A core seed-group can be discovered using a multicast group in a 285 push-based system or a Map-Server set of DNS names in a pull-based 286 system (see Section 5 for details). 288 When using multicast for the mapping system group, a core seed-group 289 multicast group address can be preconfigured to bootstrap the 290 decentralized mapping system. The group address (or DNS name that 291 maps to a group address) can be explicitly configured in a few xTRs 292 to start building up the registrations. Then as other xTRs come 293 online, they can add themselves to the core seed-group by joining the 294 seed-group multicast group. 296 Alternatively or additionally, new xTRs can join a new mapping system 297 multicast group to form another layer of a decentralized mapping 298 system. The group address and members of this new layer seed-group 299 would be registered to the core seed-group address and stored in the 300 core seed-group mapping system. Note each mapping system layer could 301 have a specific function or a specific circle of trust. 303 This multi-layer mapping system can be illustrated: 305 __________ --------- 306 / core \ 224.2.2.2 / layer-1 \ 307 | seed-group | --------> | I | 308 | 224.1.1.1 | | / \ | 309 \__________/ | J---K | 310 | \_________/ 311 | 224.3.3.3 312 | 313 v 314 --------- 315 / layer-2 \ 316 | X | 317 | / \ | 318 | Y---Z | 319 \_________/ 321 Configured in xTRs A, B, and C (they make up the core seed-group): 322 224.1.1.1 -> RLE: A, B, C 324 core seed-group DMS, mapping state in A, B, and C: 325 224.2.2.2 -> RLE: I, J, K 326 224.3.3.3 -> RLE: X, Y, Z 328 layer-1 seed-group DMS (inter-continental), mapping state in I, J, K: 329 EID1 -> RLOCs: i(1), j(2) 330 ... 331 EIDn -> RLOCs: i(n), j(n) 333 layer-2 seed-group DMS (intra-continental), mapping sate in X, Y, Z:: 334 EIDa -> RLOCs: x(1), y(2) 335 ... 336 EIDz -> RLOCs: x(n), y(n) 338 The core seed-group multicast address 224.1.1.1 is configured in xTRs 339 A, B and C so when each of them send Map-Register messages, they 340 would all be able to maintain synchronized mapping state. Any EID 341 can be registered to this DMS but in this example, seed-group 342 multicast group EIDs are being registered only to find other mapping 343 system groups. 345 For example, lets say that xTR I boots up and it wants to find its 346 other peers in its mapping system group 224.2.2.2. Group address 347 224.2.2.2 is configured so xTR I knows what group to join for its 348 mapping system group. But xTR I needs a mapping system to register 349 to, so the core seed-group is used and available to receive Map- 350 Registers. The other xTRs J and K in the mapping system group do the 351 same so when any of I, J or K needs to register EIDs, they can now 352 send their Map-Register messages to group 224.2.2.2. Examples of 353 EIDs being register are EID1 through EIDn shown above. 355 When Map-Registers are sent to group 224.2.2.2, they are encapsulated 356 by the LISP data-plane by looking up EID 224.2.2.2 in the core seed- 357 group mapping system. For the map-cache entry to be populated for 358 224.2.2.2, the data-plane must send a Map-Request so the RLOCs I, J, 359 and K are cached for replication. To use the core seed-group mapping 360 system, the data-plane must know of at least one of the RLOCs A, B, 361 and/or C. 363 5. Pull-Based Mapping System 365 5.1. Components of a Pulled-Based LISP-Decent xTR 367 When an xTR is configured to be a LISP-Decent xTR (or PxTR 368 [RFC6832]), it runs the ITR, ETR, Map-Resolver, and Map-Server LISP 369 network functions. 371 Unlike the Push-Based Mapping System, the xTRs do not need to be 372 organized by joining a multicast group. In a Pull-Based Mappig 373 System, a hash function over an EID is used to identify which xTR is 374 used as the Map-Resolver and Map-Server. The Domain Name System 375 (DNS) [RFC1034] [RFC1035] is used as a resource discovery mechanism. 377 The RLOC addresses of the xTRs will be A and AAAA records for DNS 378 names that map algorithmically from the hash of the EID. A SHA-256 379 hash function [RFC6234] over the following ASCII formatted EID string 380 is used: 382 []/ 383 []/-/ 385 Where is the instance-ID and is the EID of any EID-type 386 defined in [RFC8060]. And then the Modulus Value is used to 387 produce the Name Index used to build the DNS lookup name: 389 eid = "[]/" 390 index = hash.sha_256(eid) MOD mv 392 The Hash Mask is used to select what bits are used in the SHA-256 393 hash function. This is required to support longest match lookups in 394 the mapping system. The same map-server set needs to be selected 395 when looking up a more-specific EID found in the Map-Request message 396 with one that could match a less-specific EID-prefix registered and 397 found in the Map-Register message. For example, if an EID-prefix 399 [0]240.0.1.0/24 is registered to the mapping system and EID 400 [0]240.0.1.1/32 is looked up to match the registered prefix, a Hash 401 Mask of 8 bytes can be used to AND both the /32 or /24 entries to 402 produce the same hash string bits of "[0]240.0". 404 For (*,G) and (S,G) multicast entries in the mapping system, the hash 405 strings are: 407 sg-eid = "[]/-/" 408 index = hash.sha_256(sg-eid) MOD mv 410 starg-eid = "[]/-0.0.0.0/0" 411 index = hash.sha_256(starg-eid) MOD mv 413 The Hash Mask MUST include the string "[]" and not string 414 . So when looking up [0](2.2.2.2, 224.1.1.1) that will match 415 a (*, 224.1.1.1/32), the hash string produced with a Hash Mask of 12 416 bytes is "[0]224.1.1.1". 418 When the is computed from a unicast or multicast EID, the DNS 419 lookup name becomes: 421 .map-server.domain.com 423 When an xTR does a DNS lookup on the lookup name, it will send Map- 424 Register messages to all A and AAAA records for EID registrations. 425 For Map-Request messages, xTRs MAY round robin EID lookup requests 426 among the A and AAAA records. 428 5.2. Deployment Example 430 Here is an example deployment of a pull-based model. Let's say 4 431 map-server sets are provisioned for the mapping system. Therefore 4 432 distinct DNS names are allocated and a Modulus Value 4 is used. Each 433 DNS name is allocated Name Index 0 through 3: 435 0.map-server.lispers.net 436 1.map-server.lispers.net 437 2.map-server.lispers.net 438 3.map-server.lispers.net 440 The A records for each name can be assigned as: 442 0.map-server.lispers.net: 443 A 444 A 445 1.map-server.lispers.net: 446 A 447 A 448 2.map-server.lispers.net: 449 A 450 A 451 3.map-server.lispers.net: 452 A 453 A 455 When an xTR wants to register "[1000]fd::2222", it hashes the EID 456 string to produce, for example, hash value 0x66. Using the modulus 457 value 4 (0x67 & 0x3) produces index 0x3, so the DNS name 3.map- 458 server.lispers.net is used and a Map-Regiter is sent to 459 and . 461 Note that the pull-based method can be used for a core seed-group for 462 bootstraping a push-based mapping system where multicast groups are 463 registered. 465 5.3. Management Considerations 467 There are no LISP protocol changes required to support the pull-based 468 LISP-Decent set of procedures. However, an implementation SHOULD do 469 periodic DNS lookups to determine if A records have changed for a DNS 470 entry. 472 When xTRs derive Map-Resolver and Map-Server names from the DNS, they 473 need to use the same Modulus Value otherwise some xTRs will lookup 474 EIDs to the wrong place they were registered. 476 The Modulus Value can be configured or pushed to the LISP-Decent 477 xTRs. A future version of this document will describe a push 478 mechanism so all xTRs use a consistent modulus value. 480 6. Security Considerations 482 Refer to the Security Considerations section of 483 [I-D.ietf-lisp-rfc6833bis] for a complete list of security mechanisms 484 as well as pointers to threat analysis drafts. 486 7. IANA Considerations 488 At this time there are no specific requests for IANA. 490 8. References 492 8.1. Normative References 494 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 495 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 496 . 498 [RFC1035] Mockapetris, P., "Domain names - implementation and 499 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 500 November 1987, . 502 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 503 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 504 DOI 10.17487/RFC6234, May 2011, 505 . 507 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 508 Locator/ID Separation Protocol (LISP)", RFC 6830, 509 DOI 10.17487/RFC6830, January 2013, 510 . 512 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 513 Locator/ID Separation Protocol (LISP) for Multicast 514 Environments", RFC 6831, DOI 10.17487/RFC6831, January 515 2013, . 517 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 518 "Interworking between Locator/ID Separation Protocol 519 (LISP) and Non-LISP Sites", RFC 6832, 520 DOI 10.17487/RFC6832, January 2013, 521 . 523 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 524 Protocol (LISP) Map-Server Interface", RFC 6833, 525 DOI 10.17487/RFC6833, January 2013, 526 . 528 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 529 "Locator/ID Separation Protocol Alternative Logical 530 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 531 January 2013, . 533 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 534 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 535 February 2017, . 537 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 538 Smirnov, "Locator/ID Separation Protocol Delegated 539 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 540 May 2017, . 542 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 543 Separation Protocol (LISP) Multicast", RFC 8378, 544 DOI 10.17487/RFC8378, May 2018, 545 . 547 8.2. Informative References 549 [I-D.ietf-lisp-ecdsa-auth] 550 Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA 551 Authentication and Authorization", draft-ietf-lisp-ecdsa- 552 auth-00 (work in progress), September 2018. 554 [I-D.ietf-lisp-pubsub] 555 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 556 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 557 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 558 Subscribe Functionality for LISP", draft-ietf-lisp- 559 pubsub-02 (work in progress), November 2018. 561 [I-D.ietf-lisp-rfc6833bis] 562 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 563 "Locator/ID Separation Protocol (LISP) Control-Plane", 564 draft-ietf-lisp-rfc6833bis-24 (work in progress), February 565 2019. 567 [I-D.ietf-lisp-sec] 568 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 569 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-17 570 (work in progress), November 2018. 572 Appendix A. Acknowledgments 574 The authors would like to thank the LISP WG for their review and 575 acceptance of this draft. 577 The authors would also like to give a special thanks to Roman 578 Shaposhnik for several discussions that occured before the first 579 draft was published. 581 Appendix B. Document Change Log 583 [RFC Editor: Please delete this section on publication as RFC.] 585 B.1. Changes to draft-farinacci-lisp-decent-03 587 o Posted March 2019. 589 o Introduce the Hash Mask which is used to grab common bits from a 590 registered prefix and a lookup prefix. 592 o Spec how multicast lookups are done in the pull-based mapping 593 system. 595 o Indicate the hash string includes the unicast EID mask-length and 596 multicast group and source mask-lengths. 598 B.2. Changes to draft-farinacci-lisp-decent-02 600 o Posted November 2018. 602 o Changed references from peer-group to seed-group to make the 603 algorithms in this document more like how blockchain networks 604 initialize the peer-to-peer network. 606 o Added pull mechanism to compliment the push mechanism. The pull 607 mechanism could be used as a seed-group to bootstrap the push 608 mechanism. 610 B.3. Changes to draft-farinacci-lisp-decent-01 612 o Posted July 2018. 614 o Document timer and reference update. 616 B.4. Changes to draft-farinacci-lisp-decent-00 618 o Initial draft posted January 2018. 620 Authors' Addresses 622 Dino Farinacci 623 lispers.net 624 San Jose, CA 625 USA 627 Email: farinacci@gmail.com 628 Colin Cantrell 629 Nexus 630 Tempe, AZ 631 USA 633 Email: colin@nexus.io