idnits 2.17.1 draft-farinacci-lisp-rig-05.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 38 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 15, 2014) is 3413 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 363 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-04 ** 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 (-22) exists of draft-ietf-lisp-lcaf-07 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-threats-09 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental A. Jain 5 Expires: June 18, 2015 Juniper Networks 6 I. Kouvelas 7 D. Lewis 8 cisco Systems 9 December 15, 2014 11 LISP-DDT Referral Internet Groper (RIG) 12 draft-farinacci-lisp-rig-05 14 Abstract 16 A simple tool called the LISP-DDT Referral Internet Groper or 'rig' 17 can be used to query the LISP-DDT hierarchy. This draft describes 18 how the 'rig' tool works. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 18, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 57 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Implementation Details . . . . . . . . . . . . . . . . . . . 7 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 63 8.2. Informative References . . . . . . . . . . . . . . . . . 10 64 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 65 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10 66 B.1. Changes to draft-farinacci-lisp-rig-05.txt . . . . . . . 10 67 B.2. Changes to draft-farinacci-lisp-rig-04.txt . . . . . . . 10 68 B.3. Changes to draft-farinacci-lisp-rig-03.txt . . . . . . . 11 69 B.4. Changes to draft-farinacci-lisp-rig-02.txt . . . . . . . 11 70 B.5. Changes to draft-farinacci-lisp-rig-01.txt . . . . . . . 11 71 B.6. Changes to draft-farinacci-lisp-rig-00.txt . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Requirements Language 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 80 2. Introduction 82 LISP [RFC6830] specifies an architecture and mechanism for replacing 83 the semantics of an address currently used by IP with two separate 84 name spaces: Endpoint IDs (EIDs), used within sites, and Routing 85 Locators (RLOCs), used on the transit networks that make up the 86 Internet infrastructure. To achieve this separation, the Locator/ID 87 Separation Protocol (LISP) defines protocol mechanisms for mapping 88 from EIDs to RLOCs. In addition, LISP assumes the existence of a 89 database to store and propagate those mappings globally. This 90 document focuses on the LISP-DDT [LISP-DDT] mapping database system. 92 The 'rig' is a manual management tool to query LISP-DDT mapping 93 database hierarchy. It can be run by all devices which implement 94 LISP, including ITRs, ETRs, PITRs, PETRs, Map-Resolvers, Map-Servers, 95 and LISP-DDT nodes, as well as by a host system at either a LISP- 96 capable or non-LISP-capable site. 98 The LISP-DDT 'rig' tool is similar to the 'lig' [RFC6835] tool in 99 that they are both diagnostic tools to query a database. However, 100 'rig' is used to find Map-Servers serving an EID-prefix, specifically 101 within a LISP-DDT mapping database framework. And 'lig' can be used 102 on top of any mapping database system to retrieve locators used for 103 packet encapsulation. 105 3. Definition of Terms 107 Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for 108 IPv6) value (or an address encoded by [LISP-LCAF]) used in the 109 source and destination address fields of the first (most inner) 110 LISP header of a packet. The host obtains a destination EID the 111 same way it obtains a destination address today, for example 112 through a Domain Name System (DNS) [RFC1034] lookup or Session 113 Invitation Protocol (SIP) [RFC3261] exchange. The source EID is 114 obtained via existing mechanisms used to set a host's "local" IP 115 address. An EID used on the public Internet must have the same 116 properties as any other IP address used in that manner; this 117 means, among other things, that it must be globally unique. An 118 EID is allocated to a host from an EID-prefix block associated 119 with the site where the host is located. An EID can be used by a 120 host to refer to other hosts. EIDs MUST NOT be used as LISP 121 RLOCs. Note that EID blocks MAY be assigned in a hierarchical 122 manner, independent of the network topology, to facilitate scaling 123 of the mapping database. In addition, an EID block assigned to a 124 site may have site-local structure (subnetting) for routing within 125 the site; this structure is not visible to the global routing 126 system. In theory, the bit string that represents an EID for one 127 device can represent an RLOC for a different device. As the 128 architecture is realized, if a given bit string is both an RLOC 129 and an EID, it must refer to the same entity in both cases. When 130 used in discussions with other Locator/ID separation proposals, a 131 LISP EID will be called a "LEID". Throughout this document, any 132 references to "EID" refers to an LEID. 134 Extended EID (XEID): A LISP EID, optionally extended with a non- 135 zero Instance ID (IID) if the EID is intended for use in a context 136 where it may not be a unique value, such as on a Virtual Private 137 Network where "private" address space is used. See "Using 138 Virtualization and Segmentation with LISP" in [RFC6830] for more 139 discussion of Instance IDs. 141 Routing Locator (RLOC): A RLOC is an IPv4 [RFC0791] or IPv6 142 [RFC2460] address of an egress tunnel router (ETR). A RLOC is the 143 output of an EID-to-RLOC mapping lookup. An EID maps to one or 144 more RLOCs. Typically, RLOCs are numbered from topologically- 145 aggregatable blocks that are assigned to a site at each point to 146 which it attaches to the global Internet; where the topology is 147 defined by the connectivity of provider networks, RLOCs can be 148 thought of as PA addresses. Multiple RLOCs can be assigned to the 149 same ETR device or to multiple ETR devices at a site. 151 DDT Node: A network infrastructure component responsible for 152 specific XEID-prefix and for delegation of more-specific sub- 153 prefixes to other DDT nodes. 155 DDT Client: A network infrastructure component that sends Map- 156 Request messages and implements the iterative following of Map- 157 Referral results. Typically, a DDT client will be a Map Resolver 158 but it is also possible for an ITR to implement DDT client 159 functionality. A DDT client can be a device that is originating 160 'rig' requests. 162 DDT Map Server: A DDT node that also implements Map Server 163 functionality (forwarding Map-Requests and/or returning Map- 164 Replies if offering proxy-mode service) for a subset of its 165 delegated prefixes. 167 DDT Map Resolver: A network infrastructure element that accepts a 168 Map-Request, adds the XEID to its lookup queue, then queries one 169 or more DDT nodes for the requested EID, following returned 170 referrals until it receives one with the the ms-ack action. This 171 indicates that the Map-Request has been sent to a Map-Server that 172 will forward it to an ETR that, in turn, will provide a Map-Reply 173 to the original sender. A DDT Map Resolver maintains both a cache 174 of Map-Referral message results containing RLOCs for DDT nodes 175 responsible for XEID-prefixes of interest (termed the "referral 176 cache") plus a lookup queue of XEIDs that are being resolved 177 through iterative querying of DDT nodes. 179 Encapsulated Map-Request: A LISP Map-Request carried within an 180 Encapsulated Control Message, which has an additional LISP header 181 prepended. Sent to UDP destination port 4342. The "outer" 182 addresses are globally-routable IP addresses, also known as RLOCs. 183 Used by an ITR when sending to a Map-Resolver and by a Map-Server 184 when forwarding a Map-Request to an ETR as documented in 185 [RFC6833]. 187 Map-Referral: A LISP message sent by a DDT node when it receives a 188 DDT Map-Request for an XEID that matches a configured XEID-prefix 189 delegation. The Map-Referral message includes a "referral", a set 190 of RLOCs for DDT nodes that have more information about the sub- 191 prefix; a DDT client "follows the referral" by sending another DDT 192 Map-Request to one of those RLOCs to obtain either an answer or 193 another referral to DDT nodes responsible for a more-specific 194 XEID-prefix. 196 Authoritative XEID-prefix: An XEID-prefix delegated to a DDT node 197 and for which the DDT node may provide further delegations of 198 more-specific sub-prefixes. 200 4. Basic Overview 202 The LISP Delegated Database Tree [LISP-DDT], is a hierarchical, 203 distributed database which embodies the delegation of authority to 204 provide mappings from LISP Endpoint Identifiers (EIDs) to Routing 205 Locators (RLOCs). It is a statically-defined distribution of the EID 206 namespace among a set of LISP-speaking servers, called DDT nodes. 207 Each DDT node is configured as "authoritative" for one or more EID- 208 prefixes, along with the set of RLOCs for Map Servers or "child" DDT 209 nodes to which more-specific EID-prefixes are delegated. 211 Map-Resolvers send Map-Requests to the DDT hierarchy and maintain 212 referral-caches by receiving Map-Referral messages from DDT nodes. 213 Map-Resolvers follow the DDT hierarchy for a given EID lookup based 214 on the EID-prefix and delegation referrals contained in the Map- 215 Referral messages. The intention of rig is to perform the same 216 operation of a Map-Resolver but used as a management tool for the 217 network administrator. 219 When the rig command is run, an Encapsulated Control Message Map- 220 Request is sent for a destination EID. When a LISP-DDT Map-Referral 221 is returned, the contents are displayed to the user. The information 222 displayed includes: 224 o A delegated EID-prefix configured in a DDT-node or a configured 225 site EID-prefix in a DDT Map-Server that matches the requested 226 EID. 228 o The type of DDT-node which sent the Map-Referral. 230 o The action code and TTL set by the sender of the Map-Referral. 232 o The referral RLOC addresses from the Map-Referral message. 234 o A round-trip-time estimate for the ECM-Map-Request/Map-Referral 235 message exchange. 237 A possible syntax for a rig command MAY be: 239 rig [instance-id ] to [follow-all-referrals] 240 Parameter description: 242 [instance-id >]: is the instance-ID portion of the Extended 243 EID used as VPN identifier or for other future purposes. When the 244 DDT hierarchy is not configured with instance-IDs, this argument 245 is omitted from the command line. 247 : is either a Fully Qualified Domain Name or a destination EID 248 that is being queried in the LISP-DDT mapping database. 250 : is the RLOC address of any DDT-node in the DDT 251 hierarchy. This can be the DDT root node, a DDT transit node, or 252 a DDT Map-Server. 254 [follow-all-referrals]: when this keyword is used each referral 255 RLOC is queried so rig can descend the entire DDT hierarchy 256 starting from the node . When this keyword is not used, 257 one of the referral RLOCs will be selected to descend a branch of 258 the DDT hierarchy. 260 The rig utility not only shows branches of the delegation hierarchy 261 but can also report: 263 o When a DDT Map-Server would forward a Map-Request to the ETRs at a 264 registered LISP site. This is known as a 'ms-acknowledgement' 265 action. 267 o When a DDT Map-Server sends a negative referral indicating a 268 requested EID is configured but not registered to the mapping 269 database system. This is known as an 'ms-not-registered' action. 271 o When a DDT node is sending referrals for a transit or leaf node in 272 the hierarchy. These are known as 'node-referral' and 'ms- 273 referral' actions, respectively. 275 o When a DDT-node finds a hole in the address space that has not 276 been allocated or configured in the delegation hierarchy. This is 277 typically associated with a hole in a DDT node's configured 278 authoritative prefix. This is known as a 'delegation-hole' 279 action. 281 o When a DDT-node finds a hole in the address space that has not 282 been allocated or configured in the delegation hierarchy at all. 283 This is typically associated with a hole that is outside of a DDT 284 node's authoritative prefix. This is known as 'non-authoritative' 285 action. 287 Refer to [LISP-DDT] for more detail about Map-Referral actions. 289 5. Implementation Details 291 The cisco LISP prototype implementations on IOS and NX-OS has rig 292 support for IPv4 and IPv6 EIDs in either the default instance or a 293 non-zero instance-ID. 295 The IOS syntax is: 297 rig [instance-id ] to [follow-all-referrals] 299 The NX-OS syntax is: 301 rig [instance-id ] | { | }} 302 to { | { | }} 304 Here is some sample IOS output: 306 Router# rig 12.0.1.1 to 1.1.1.1 308 Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 0 ms 309 EID-prefix: [0] 12.0.0.0/16, ttl: 1440 310 referrals: 2.2.2.2 312 Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms 313 EID-prefix: [0] 12.0.1.0/24, ttl: 1440 314 referrals: 4.4.4.4, 5.5.5.5 316 Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement, 317 rtt: 0 ms 318 EID-prefix: [0] 12.0.1.0/28, ttl: 1440 319 referrals: 4.4.4.4, 5.5.5.5 320 Router# rig 12.0.1.1 to 1.1.1.1 follow-all-referrals 322 Send Map-Request to DDT-node 1.1.1.1 ... node referral, rtt: 4 ms 323 EID-prefix: [0] 12.0.0.0/16, ttl: 1440 324 referrals: 2.2.2.2 326 Send Map-Request to DDT-node 2.2.2.2 ... node referral, rtt: 0 ms 327 EID-prefix: [0] 12.0.1.0/24, ttl: 1440 328 referrals: 4.4.4.4, 5.5.5.5 330 Send Map-Request to DDT-node 4.4.4.4 ... map-server acknowledgement, 331 rtt: 0 ms 332 EID-prefix: [0] 12.0.1.0/28, ttl: 1440 333 referrals: 4.4.4.4, 5.5.5.5 335 Send Map-Request to DDT-node 5.5.5.5 ... map-server acknowledgement, 336 rtt: 0 ms 337 EID-prefix: [0] 12.0.1.0/28, ttl: 1440 338 referrals: 4.4.4.4, 5.5.5.5 340 No more referrals to pursue. 342 Here is some sample NX-OS output: 344 Router# rig 12.0.1.1 to 1.1.1.1 346 rig LISP-DDT hierarchy for EID [0] 12.0.1.1 347 Send Map-Request to DDT-node 1.1.1.1 ... replied, rtt: 0.003509 secs 348 EID-prefix [0] *, ttl: 1440, action: node-referral, referrals: 349 2.2.2.2, priority/weight: 0/0 351 Send Map-Request to DDT-node 2.2.2.2 ... replied, rtt: 0.003173 secs 352 EID-prefix [0] 12.0.0.0/20, ttl: 1440, action: node-referral, 353 referrals: 354 3.3.3.3, priority/weight: 0/0 356 Send Map-Request to DDT-node 3.3.3.3 ... replied, rtt: 0.004145 secs 357 EID-prefix [0] 12.0.1.0/24, ttl: 1440, action: node-referral, 358 referrals: 359 5.5.5.5, priority/weight: 0/0 360 6.6.6.6, priority/weight: 0/0 362 Send Map-Request to DDT-node 6.6.6.6 ... replied, rtt: 0.005800 secs 363 EID-prefix [0] 12.0.1.0/28, ttl: 1440, action: ms-ack, referrals: 364 5.5.5.5, priority/weight: 0/0 365 6.6.6.6, priority/weight: 0/0 367 6. Security Considerations 369 The use of rig does not affect the security of the LISP 370 infrastructure as it is simply a tool that facilities diagnostic 371 querying. See [RFC6830], [LISP-DDT], [RFC6833], and [LISP-THREATS] 372 for descriptions of the security properties of the LISP 373 infrastructure. 375 LISP rig provides easy access to the information in the public 376 mapping database. Therefore, it is important to protect the mapping 377 information for private use. This can be provided by disallowing 378 access to specific mapping entries or to place such entries in a 379 private mapping database system. 381 7. IANA Considerations 383 This document makes no request of the IANA. 385 8. References 387 8.1. Normative References 389 [LISP-DDT] 390 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 391 Delegated Database Tree", draft-ietf-lisp-ddt-04.txt (work 392 in progress), September 2014. 394 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 395 1981. 397 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 398 STD 13, RFC 1034, November 1987. 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 404 Locator/ID Separation Protocol (LISP)", RFC 6830, January 405 2013. 407 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 408 Protocol (LISP) Map-Server Interface", RFC 6833, January 409 2013. 411 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 412 Protocol Internet Groper (LIG)", RFC 6835, January 2013. 414 8.2. Informative References 416 [LISP-LCAF] 417 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 418 Address Format (LCAF)", draft-ietf-lisp-lcaf-07 (work in 419 progress), . 421 [LISP-THREATS] 422 Iannone, L., Saucez, D., and O. Bonaventure, "LISP Threats 423 Analysis", draft-ietf-lisp-threats-09.txt (work in 424 progress), April 2014. 426 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 427 (IPv6) Specification", RFC 2460, December 1998. 429 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 430 A., Peterson, J., Sparks, R., Handley, M., and E. 431 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 432 June 2002. 434 Appendix A. Acknowledgments 436 The authors would like to thank Damien Saucez and Fabio Maino for 437 their ideas and comments. Appreciation goes to Joel Halpern, Luigi 438 Iannone, and Nevil Brownlee for progressing this document to 439 Informational RFC. 441 Appendix B. Document Change Log 443 B.1. Changes to draft-farinacci-lisp-rig-05.txt 445 o Draft posted December 2014. 447 o Changes that reflect comments from Damien so we can move this 448 draft to Informational RFC. 450 B.2. Changes to draft-farinacci-lisp-rig-04.txt 452 o Draft posted July 2014. 454 o Added LISP-DDT basic operation description in the Basic Overview 455 section. 457 o Fix editorial comments from Luigi Iannone. 459 B.3. Changes to draft-farinacci-lisp-rig-03.txt 461 o Draft posted March 2014. 463 o Resetting timer for expired draft. 465 B.4. Changes to draft-farinacci-lisp-rig-02.txt 467 o Draft posted September 2013. 469 o Resetting timer for expired draft. 471 o Update author affliations and reference RFCs. 473 B.5. Changes to draft-farinacci-lisp-rig-01.txt 475 o Draft posted March 2012. 477 o Updated reference to LISP-DDT". 479 B.6. Changes to draft-farinacci-lisp-rig-00.txt 481 o Initial draft posted March 2012. 483 Authors' Addresses 485 Dino Farinacci 486 lispers.net 487 San Jose, California 488 USA 490 Phone: 408-718-2001 491 Email: farinacci@gmail.com 493 Amit Jain 494 Juniper Networks 495 San Jose, California 496 USA 498 Email: atjain@juniper.net 499 Isidor Kouvelas 500 cisco Systems 501 Tasman Ave. 502 San Jose, California 503 USA 505 Email: kouvelas@cisco.com 507 Darrel Lewis 508 cisco Systems 509 Tasman Ave. 510 San Jose, California 511 USA 513 Email: darlewis@cisco.com