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