idnits 2.17.1 draft-ietf-lisp-lig-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 24 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. == There are 1 instance of lines with non-RFC3849-compliant IPv6 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 (April 10, 2010) is 5102 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '-d' is mentioned on line 313, but not defined -- No information found for draft-ietfr-lisp-alt - is the name correct? == Outdated reference: A later version (-04) exists of draft-meyer-lisp-cons-03 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-07 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-05 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-04 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft D. Meyer 4 Intended status: Experimental cisco Systems 5 Expires: October 12, 2010 April 10, 2010 7 LISP Internet Groper (LIG) 8 draft-ietf-lisp-lig-00 10 Abstract 12 A simple tool called the LISP Internet Groper or 'lig' can be used to 13 query the LISP mapping database. This draft describes how it works. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 12, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the BSD License. 53 Table of Contents 55 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 58 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. Implementation Details . . . . . . . . . . . . . . . . . . . . 9 60 5.1. LISP Router Implementation . . . . . . . . . . . . . . . . 9 61 5.2. Public Domain Host Implementation . . . . . . . . . . . . 10 62 6. Testing the ALT . . . . . . . . . . . . . . . . . . . . . . . 12 63 7. Future Enhancements . . . . . . . . . . . . . . . . . . . . . 13 64 8. Deployed Network Diagnostic Tools . . . . . . . . . . . . . . 14 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 69 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 72 1. Requirements Notation 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Introduction 80 LISP [LISP] specifies an architecture and mechanism for replacing the 81 addresses currently used by IP with two separate name spaces: 82 Endpoint IDS (EIDs), used within sites, and Routing Locators (RLOCs), 83 used on the transit networks that make up the Internet 84 infrastructure. To achieve this separation, the Locator/ID 85 Separation Protocol (LISP) defines protocol mechanisms for mapping 86 from EIDs to RLOCs. In addition, LISP assumes the existence of a 87 database to store and propagate those mappings globally. Several 88 such databases have been proposed, among them: LISP-CONS [CONS], 89 LISP-NERD [NERD], and LISP+ALT [ALT], with LISP+ALT being the system 90 that is currently being implemented and deployed on the pilot LISP 91 network. 93 In conjunction with the various mapping systems, there exists a 94 network based API called LISP Map-Server [LISP-MS]. Using Map 95 Resolvers and Map Servers allows LISP sites to query and register 96 into the database in a uniform way independent of the mapping system 97 used. Sending Map-Requests to Map Resolvers provides a secure 98 mechanism mechanism to obtain a Map-Reply containing the 99 authoritative EID-to-RLOC mapping for a destination LISP site. 101 The 'lig' is a manual management tool to query the mapping database. 102 It can be run by all devices which implement LISP, including ITRs, 103 ETRs, PTR, Map-Resolvers, Map-Servers, and LISP-ALT routers, as well 104 as by a host system at either a LISP-capable or non-LISP-capable 105 site. 107 3. Definition of Terms 109 Map-Server: a network infrastructure component which learns EID-to- 110 RLOC mapping entries from an authoritative source (typically, an 111 ETR, though static configuration or another out-of-band mechanism 112 may be used). A Map-Server advertises these mappings in the 113 distributed mapping database. 115 Map-Resolver: a network infrastructure component which accepts LISP 116 Encapsulated Map-Requests, typically from an ITR, quickly 117 determines whether or not the destination IP address is part of 118 the EID namespace; if it is not, a Negative Map-Reply is 119 immediately returned. Otherwise, the Map-Resolver finds the 120 appropriate EID-to-RLOC mapping by consulting the distributed 121 mapping database system. 123 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 124 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 125 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 126 numbered from topologically-aggregatable blocks that are assigned 127 to a site at each point to which it attaches to the global 128 Internet; where the topology is defined by the connectivity of 129 provider networks, RLOCs can be thought of as PA addresses. 130 Multiple RLOCs can be assigned to the same ETR device or to 131 multiple ETR devices at a site. 133 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 134 used in the source and destination address fields of the first 135 (most inner) LISP header of a packet. The host obtains a 136 destination EID the same way it obtains an destination address 137 today, for example through a DNS lookup or SIP exchange. The 138 source EID is obtained via existing mechanisms used to set a 139 host's "local" IP address. An EID is allocated to a host from an 140 EID-prefix block associated with the site where the host is 141 located. An EID can be used by a host to refer to other hosts. 142 EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be 143 assigned in a hierarchical manner, independent of the network 144 topology, to facilitate scaling of the mapping database. In 145 addition, an EID block assigned to a site may have site-local 146 structure (subnetting) for routing within the site; this structure 147 is not visible to the global routing system. 149 EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that 150 stores, tracks, and is responsible for timing-out and otherwise 151 validating EID-to-RLOC mappings. This cache is distinct from the 152 full "database" of EID-to-RLOC mappings, it is dynamic, local to 153 the ITR(s), and relatively small while the database is 154 distributed, relatively static, and much more global in scope. 156 EID-to-RLOC Database: a global distributed database that contains 157 all known EID-prefix to RLOC mappings. Each potential ETR 158 typically contains a small piece of the database: the EID-to-RLOC 159 mappings for the EID prefixes "behind" the router. These map to 160 one of the router's own, globally-visible, IP addresses. 162 Encapsulated Map-Request (EMR): an EMR is a Map-Request message 163 which is encapsulated with another LISP header using UDP 164 destination port number 4341. It is used so an ITR, PTR, or a 165 system initiating a 'lig' command can get the Map-Request to a 166 Map-Resolver by using locater addresses. When the Map-Request is 167 decapsulated by the Map-Resolver it will be forwarded on the ALT 168 network to the Map-Server that has injected the EID-prefix for a 169 registered site. The Map-Server will then encapsulate the Map- 170 Request in a LISP packet and send it to an an ETR at the site. 171 The ETR will then return an authoritative reply to the system that 172 initiated the request. 174 4. Basic Overview 176 When the lig command is run, a Map-Request is sent for a destination 177 EID. When a Map-Reply is returned, the contents are displayed to the 178 user. The information displayed includes: 180 o The EID-prefix for the site the queried destination EID matches. 182 o The locator address of the Map Replier. 184 o The locator-set for the mapping entry which includes the locator 185 address, up/down status, priority, and weight of each locator. 187 o An round-trip-time estimate for the Map-Request/Map-Reply 188 exchange. 190 A possible syntax for a lig command could be: 192 lig [source ] [to ] 194 Parameter description: 196 : is either a Fully Qualified Domain Name or a 197 destination EID for a remote LISP site. 199 source : is an optional source EID to be inserted in the 200 "Source EID" field of the Map-Request. 202 to : is an optional Fully Qualified Domain Name or 203 RLOC address for a Map-Resolver. 205 The lig utility has two usage cases. The first being a way to query 206 the mapping database for a particular EID. And the other to verify 207 if a site has registered successfully with a Map-Server. 209 The first usage has already been described. Verifying registration 210 is called "ligging yourself". What occurs is in the lig initiator, a 211 Map-Request is sent for one of the EIDs for the lig initiator's site. 212 The Map-Request is then returned to one of the ETRs for the lig 213 initiating site. In response to the Map-Request, a Map-Reply is sent 214 back to the locator address of the lig initiator (note the Map-Reply 215 could be sent by the lig initiator). That Map-Reply is processed and 216 the mapping data for lig initiating site is displayed for the user. 217 Refer to the syntax in section Section 5.1 for an implementation of 218 "ligging yourself". However, for host-based implementations within a 219 LISP site, "lig self" is less useful since the host may not have an 220 RLOC to receive a Map-Reply with. But, lig can be used in a non-LISP 221 site as well as from infrastructure hosts to get mapping information. 223 5. Implementation Details 225 5.1. LISP Router Implementation 227 The cisco LISP prototype implementation has support for lig for IPv4 228 and IPv6. The command line description is: 230 lig [source ] [to ] [count <1-5>] 232 This command initiates the LISP Internet Groper. It is similar to 233 the DNS analogue 'dig' but works on the LISP mapping database. When 234 this command is invoked, the local system will send a Map-Request to 235 the configured Map-Resolver. When a Map-Reply is returned, its 236 contents will be displayed to the user. By default, up to 3 Map- 237 Requests are sent if no Map-Reply is returned but once a Map-Reply is 238 returned no other Map-Requests are sent. The destination can take a 239 DNS name, or an IPv4 or IPv6 EID address. The can be 240 one of the EID addresses assigned to the site in the default VRF. 241 When is specified, then the Map-Request is sent to the address. 242 Otherwise, the Map-Request is sent to a configured Map-Resolver. 243 When a Map-Resolver is not configured then the Map-Request is sent on 244 the ALT network if the local router is attached to the ALT. When 245 "count <1-5>" is specified, 1, 2, 3, 4, or 5 Map-Requests are sent. 247 Some sample output: 249 titanium-dino# lig titanium-dmm.lisp4.net 250 Send map-request to 10.0.0.1 for 192.168.1.1 ... 251 Received map-reply from 10.0.0.2 with rtt 0.081468 secs 253 Map-cache entry for titanium-dmm.lisp4.net EID 192.168.1.1: 254 192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58, 255 via map-reply, auth 256 Locator Uptime State Priority/Weight Packets In/Out 257 10.0.0.2 13:59:59 up 1/100 0/14 259 Using lig to "lig yourself" is accomplished with the following 260 syntax: 262 lig {self | self6} [source ] [to ] [count <1-5>] 264 Use this command for a simple way to see if the site is registered 265 with the mapping database system. The destination-EID address for 266 the Map-Request will be the first configured EID-prefix for the site 267 (with the host-bits set to 0). For example, if the site's EID-prefix 268 is 192.168.1.0/24, the destination-EID for the Map-Request is 269 192.168.1.0. The source-EID address for the Map-Request will also be 270 192.168.1.0 (in this example) and the Map-Request is sent to the 271 configured Map-Resolver. If the Map-Resolver and Map-Server are the 272 same LISP system, then the "lig self" is testing if the Map-Resolver 273 can "turn back a Map-Request to the site". If another Map-Resolver 274 is used, it can test that the site's EID-prefix has been injected 275 into the ALT infrastructure in which case the lig Map-Request is 276 processed by the Map-Resolver, propagated through each ALT router hop 277 to the site's registered Map-Server. Then the Map-Server returns the 278 Map-Request to originating site. In which case, an xTR at the 279 originating site sends a Map-Reply to the source of the Map-Request 280 (could be itself or another xTR for the site). All other command 281 parameters are described above. Using "lig self6" tests for 282 registering of IPv6 EID- prefixes. 284 Some sample output for ligging yourself: 286 rutile# lig self 287 Send loopback map-request to 10.0.0.1 for 192.168.2.0 ... 288 Received map-reply from 10.0.0.3 with rtt 0.001592 secs 290 Map-cache entry for EID 192.168.2.0: 291 192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57 292 via map-reply, self 293 Locator Uptime State Priority/Weight Packets In/Out 294 10.0.0.3 00:00:02 up 1/100 0/0 296 titanium-simlo# lig self6 297 Send loopback map-request to 10.0.0.1 for 192:168:1:: ... 298 Received map-reply from 10::1 with rtt 0.044372 secs 300 Map-cache entry for EID 192:168:1::: 301 192:168:1::/48, uptime: 00:00:01, expires: 23:59:58 302 via map-reply, self 303 Locator Uptime State Priority/Weight Packets In/Out 304 10.0.0.3 00:00:01 up 1/100 0/0 305 10::1 00:00:01 up 2/0 0/0 307 5.2. Public Domain Host Implementation 309 There is a public domain implementation that can run on any x86 based 310 system. The only requirement is that the system that initiates lig 311 must have an address assigned from the locator namespace. 313 lig [-d] -m [-c ] [-t ] 315 Parameter description: 317 -d: prints additional protocol debug output. 319 : is the destination EID or FQDN of a LISP host. 321 -m : is the RLOC address or FQDN of a Map-Resolver. 323 -c : the number of Map-Requests to send before the first Map- 324 Reply is returned. The default value is 3. The range is from 1 325 to 5. 327 -t : the amount of time, in seconds, before another Map- 328 Request is sent when no Map-Reply is returned. The default value 329 is 2 seconds. The range is from 1 to 5. 331 Some sample output: 333 % lig titanium-test.lisp4.net -m 10.0.0.1 334 Send map-request to 10.0.0.1 for 192.168.1.1 ... 335 Received map-reply from 10.0.0.2 with rtt 0.04000 sec 337 Mapping entry for EID 192.168.1.1: 338 192.168.1.0/24, record ttl: 60 339 Locator State Priority/Weight 340 10.0.0.1 up 1/25 341 10.0.0.2 up 1/25 342 10.0.0.3 up 1/25 343 10.0.0.4 up 2/25 345 The public domain implementation of lig is available at 346 http://github.com/davidmeyer/lig. 348 6. Testing the ALT 350 There are cases where a Map-Reply is returned from a lig request but 351 the user doesn't really know how much of the mapping infrastructure 352 was tested. There are two cases to consider, avoiding the ALT and 353 traversing the ALT. 355 When an ITR sends a lig request to its Map-Resolver for a 356 destination-EID, the Map-Resolver could also be configured as a Map- 357 Server. And if the destination-EID is for a site that registers with 358 this Map-Server, the Map-Request is sent to the site directly without 359 testing the ALT. This occurs because the Map-Server is the source of 360 the advertisement for the site's EID-prefix. So if the map-reply is 361 returned to the lig requesting site, you cannot be sure that other 362 sites can reach the same destination-EID. 364 If a Map-Resolver is used that is not a Map-Server for the EID-prefix 365 being sought, then the ALT infrastructure can be tested. This test 366 case is testing the functionality of the Map-Resolver, traversal of 367 the ALT (testing BGP-over-GRE), and the Map-Server. 369 It is recommended that users issue 2 lig requests, each which send 370 Map-Requests to different Map-Resolvers. 372 The network can have a LISP-ALT router deployed as a "ALT looking- 373 glass" node. This type of router has BGP peering sessions with other 374 ALT routers where it does not inject any EID-prefixes into the ALT 375 but just learns ones advertised by other ALT routers and Map-Servers. 376 This router is configured as a Map-Resolver. Lig users can point to 377 the ALT looking-glass router for Map-Resolver services via the "to 378 " parameter on the lig command. The ALT looking-glass 379 node can be used to lig other sites as well as your own site. When 380 the ALT looking-glass is used as a Map-Resolver, you can be assured 381 the ALT network is being tested. 383 7. Future Enhancements 385 When negative Map-Replies have been further developed and 386 implemented, lig should be modified appropriately to process and 387 clearly indicate how and why a negative Map-Reply was received. 388 Negative Map-Replies could be sent in the following cases, the lig 389 request was initiated for a non-EID address or the Map-Request 390 initiated by lig request is being rejected due to rate-limiting on 391 the replier. 393 8. Deployed Network Diagnostic Tools 395 There is an web-based interface to do auto-polling with lig on the 396 back-end for most of the LISP sites on the LISP test network. The 397 web-page can be accessed at http://www.lisp4.net/status. 399 There is a LISP site monitoring web-based interface that can be found 400 at http://www.lisp4.net/lisp-site. 402 At http://baldomar.ccaba.upc.edu/lispmon, written by the folks at 403 UPC, shows a geographical map indicating where each LISP site 404 resides. 406 9. Security Considerations 408 The use of lig does not affect the security of the LISP 409 infrastructure as it is simply a tool that facilities diagnostic 410 querying. See [LISP], [ALT], and [LISP-MS] for descriptions of the 411 security properties of the LISP infrastructure. 413 10. References 415 10.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 10.2. Informative References 422 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 423 Alternative Topology (LISP-ALT)", 424 draft-ietfr-lisp-alt-04.txt (work in progress), 425 April 2010. 427 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 428 Content distribution Overlay Network Service for LISP", 429 draft-meyer-lisp-cons-03.txt (work in progress), 430 November 2007. 432 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 433 "Locator/ID Separation Protocol (LISP)", 434 draft-ietf-lisp-07.txt (work in progress), April 2010. 436 [LISP-LIG] 437 Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", 438 draft-farinacci-lisp-lig-02.txt (work in progress), 439 February 2010. 441 [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", 442 draft-ietf-lisp-ms-05.txt (work in progress), April 2010. 444 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 445 draft-lear-lisp-nerd-04.txt (work in progress), 446 April 2008. 448 Appendix A. Acknowledgments 450 Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and 451 Vince Fuller for providing critical feedback on the lig design and 452 prototype implementations. These folks as well as all the people on 453 lisp-beta@external.cisco.com who tested lig functionality and 454 continue to do so, we extend our sincere thanks. 456 This working group draft is based on individual contribution 457 draft-farinacci-lisp-lig-02.txt [LISP-LIG]. 459 Authors' Addresses 461 Dino Farinacci 462 cisco Systems 463 Tasman Drive 464 San Jose, CA 95134 465 USA 467 Email: dino@cisco.com 469 Dave Meyer 470 cisco Systems 471 170 Tasman Drive 472 San Jose, CA 473 USA 475 Email: dmm@cisco.com