idnits 2.17.1 draft-ietf-lisp-lig-06.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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2011) is 4606 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '-d' is mentioned on line 358, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-02 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-15 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-11 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-08 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-08 Summary: 0 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: March 12, 2012 September 9, 2011 7 LISP Internet Groper (LIG) 8 draft-ietf-lisp-lig-06 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 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). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on March 12, 2012. 32 Copyright Notice 34 Copyright (c) 2011 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 51 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 52 4. Implementation Details . . . . . . . . . . . . . . . . . . . . 9 53 4.1. LISP Router Implementation . . . . . . . . . . . . . . . . 9 54 4.2. Public Domain Host Implementation . . . . . . . . . . . . 10 55 5. Testing the ALT . . . . . . . . . . . . . . . . . . . . . . . 12 56 6. Future Enhancements . . . . . . . . . . . . . . . . . . . . . 13 57 7. Deployed Network Diagnostic Tools . . . . . . . . . . . . . . 14 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 61 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 62 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 66 1. Introduction 68 LISP [LISP] specifies an architecture and mechanism for replacing the 69 addresses currently used by IP with two separate name spaces: 70 Endpoint IDs (EIDs), used within sites, and Routing Locators (RLOCs), 71 used on the transit networks that make up the Internet 72 infrastructure. To achieve this separation, the Locator/ID 73 Separation Protocol (LISP) defines protocol mechanisms for mapping 74 from EIDs to RLOCs. In addition, LISP assumes the existence of a 75 database to store and propagate those mappings globally. Several 76 such databases have been proposed, among them: LISP-CONS [CONS], 77 LISP-NERD [NERD], and LISP+ALT [ALT], with LISP+ALT being the system 78 that is currently being implemented and deployed on the pilot LISP 79 network. 81 In conjunction with the various mapping systems, there exists a 82 network based API called LISP Map-Server [LISP-MS]. Using Map- 83 Resolvers and Map-Servers allows LISP sites to query and register 84 into the database in a uniform way independent of the mapping system 85 used. Sending Map-Requests to Map-Resolvers provides a secure 86 mechanism to obtain a Map-Reply containing the authoritative EID-to- 87 RLOC mapping for a destination LISP site. 89 The 'lig' is a manual management tool to query the mapping database. 90 It can be run by all devices which implement LISP, including ITRs, 91 ETRs, PITRs, PETRs, Map-Resolvers, Map-Servers, and LISP-ALT routers, 92 as well as by a host system at either a LISP-capable or non-LISP- 93 capable site. 95 The mapping database system is typically a public database used for 96 wide-range connectivity across Internet sites. The information in 97 the public database is purposely not kept private so it can be 98 generally accessible for public use. 100 2. Definition of Terms 102 Map-Server: a network infrastructure component which learns EID-to- 103 RLOC mapping entries from an authoritative source (typically, an 104 ETR, though static configuration or another out-of-band mechanism 105 may be used). A Map-Server advertises these mappings in the 106 distributed mapping database. 108 Map-Resolver: a network infrastructure component which accepts LISP 109 Encapsulated Map-Requests, typically from an ITR, quickly 110 determines whether or not the destination IP address is part of 111 the EID namespace; if it is not, a Negative Map-Reply is 112 immediately returned. Otherwise, the Map-Resolver finds the 113 appropriate EID-to-RLOC mapping by consulting the distributed 114 mapping database system. 116 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 117 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 118 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 119 numbered from topologically-aggregatable blocks that are assigned 120 to a site at each point to which it attaches to the global 121 Internet. Thus, the topology is defined by the connectivity of 122 provider networks and RLOCs can be thought of as PA addresses. 123 Multiple RLOCs can be assigned to the same ETR device or to 124 multiple ETR devices at a site. 126 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 127 used in the source and destination address fields of the first 128 (most inner) LISP header of a packet. The host obtains a 129 destination EID the same way it obtains a destination address 130 today, for example through a DNS lookup. The source EID is 131 obtained via existing mechanisms used to set a host's "local" IP 132 address. An EID is allocated to a host from an EID-prefix block 133 associated with the site where the host is located. An EID can be 134 used by a host to refer to other hosts. EIDs must not be used as 135 LISP RLOCs. Note that EID blocks may be assigned in a 136 hierarchical manner, independent of the network topology, to 137 facilitate scaling of the mapping database. In addition, an EID 138 block assigned to a site may have site-local structure 139 (subnetting) for routing within the site; this structure is not 140 visible to the global routing system. 142 EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that 143 stores, tracks, and is responsible for timing-out and otherwise 144 validating EID-to-RLOC mappings. This cache is distinct from the 145 full "database" of EID-to-RLOC mappings, it is dynamic, local to 146 the ITR(s), and relatively small while the database is 147 distributed, relatively static, and much more global in scope. 149 EID-to-RLOC Database: a global distributed database that contains 150 all known EID-prefix to RLOC mappings. Each potential ETR 151 typically contains a small piece of the database: the EID-to-RLOC 152 mappings for the EID prefixes "behind" the router. These map to 153 one of the router's own, globally-visible, IP addresses. 155 Encapsulated Map-Request (EMR): an EMR is a Map-Request message 156 which is encapsulated with another LISP header using UDP 157 destination port number 4341. It is used so an ITR, PITR, or a 158 system initiating a 'lig' command can get the Map-Request to a 159 Map-Resolver by using locater addresses. When the Map-Request is 160 decapsulated by the Map-Resolver it will be forwarded on the ALT 161 network to the Map-Server that has injected the EID-prefix for a 162 registered site. The Map-Server will then encapsulate the Map- 163 Request in a LISP packet and send it to an an ETR at the site. 164 The ETR will then return an authoritative reply to the system that 165 initiated the request. See [LISP] for packet format details. 167 Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP 168 packet with a single IP header (more precisely, an IP packet that 169 does not contain a LISP header). The router treats this "inner" 170 IP destination address as an EID and performs an EID-to-RLOC 171 mapping lookup. The router then prepends an "outer" IP header 172 with one of its globally-routable RLOCs in the source address 173 field and the result of the mapping lookup in the destination 174 address field. Note that this destination RLOC may be an 175 intermediate, proxy device that has better knowledge of the EID- 176 to-RLOC mapping closer to the destination EID. In general, an ITR 177 receives IP packets from site end-systems on one side and sends 178 LISP-encapsulated IP packets toward the Internet on the other 179 side. 181 Egress Tunnel Router (ETR): An ETR is a router that accepts an IP 182 packet where the destination address in the "outer" IP header is 183 one of its own RLOCs. The router strips the "outer" header and 184 forwards the packet based on the next IP header found. In 185 general, an ETR receives LISP-encapsulated IP packets from the 186 Internet on one side and sends decapsulated IP packets to site 187 end-systems on the other side. ETR functionality does not have to 188 be limited to a router device. A server host can be the endpoint 189 of a LISP tunnel as well. 191 Proxy ITR (PITR): A PITR is also known as a PTR is defined and 192 described in [INTERWORK], a PITR acts like an ITR but does so on 193 behalf of non-LISP sites which send packets to destinations at 194 LISP sites. 196 Proxy ETR (PETR): A PETR is defined and described in [INTERWORK], a 197 PETR acts like an ETR but does so on behalf of LISP sites which 198 send packets to destinations at non-LISP sites. 200 xTR: A xTR is a reference to an ITR or ETR when direction of data 201 flow is not part of the context description. xTR refers to the 202 router that is the tunnel endpoint. Used synonymously with the 203 term "Tunnel Router". For example, "An xTR can be located at the 204 Customer Edge (CE) router", meaning both ITR and ETR functionality 205 is at the CE router. 207 Provider Assigned (PA) Addresses: PA addresses are an address block 208 assigned to a site by each service provider to which a site 209 connects. Typically, each block is sub-block of a service 210 provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and 211 is aggregated into the larger block before being advertised into 212 the global Internet. Traditionally, IP multihoming has been 213 implemented by each multi-homed site acquiring its own, globally- 214 visible prefix. LISP uses only topologically-assigned and 215 aggregatable address blocks for RLOCs, eliminating this 216 demonstrably non-scalable practice. 218 3. Basic Overview 220 When the lig command is run, a Map-Request is sent for a destination 221 EID. When a Map-Reply is returned, the contents are displayed to the 222 user. The information displayed includes: 224 o The EID-prefix for the site the queried destination EID matches. 226 o The locator address of the Map Replier. 228 o The locator-set for the mapping entry which includes the locator 229 address, up/down status, priority, and weight of each locator. 231 o An round-trip-time estimate for the Map-Request/Map-Reply 232 exchange. 234 A possible syntax for a lig command could be: 236 lig [source ] [to ] 238 Parameter description: 240 : is either a Fully Qualified Domain Name or a 241 destination EID for a remote LISP site. 243 source : is an optional source EID to be inserted in the 244 "Source EID" field of the Map-Request. 246 to : is an optional Fully Qualified Domain Name or 247 RLOC address for a Map-Resolver. 249 The lig utility has two use cases. The first being a way to query 250 the mapping database for a particular EID. And the other to verify 251 if a site has registered successfully with a Map-Server. 253 The first usage has already been described. Verifying registration 254 is called "ligging yourself". What occurs is in the lig initiator, a 255 Map-Request is sent for one of the EIDs for the lig initiator's site. 256 The Map-Request is then returned to one of the ETRs for the lig 257 initiating site. In response to the Map-Request, a Map-Reply is sent 258 back to the locator address of the lig initiator (note the Map-Reply 259 could be sent by the lig initiator). That Map-Reply is processed and 260 the mapping data for the lig initiating site is displayed for the 261 user. Refer to the syntax in section Section 4.1 for an 262 implementation of "ligging yourself". However, for host-based 263 implementations within a LISP site, "lig self" is less useful since 264 the host may not have an RLOC to receive a Map-Reply with. But, lig 265 can be used in a non-LISP site as well as from infrastructure hosts 266 to get mapping information. 268 4. Implementation Details 270 4.1. LISP Router Implementation 272 The cisco LISP prototype implementation has support for lig for IPv4 273 and IPv6. The command line description is: 275 lig [source ] [to ] [count <1-5>] 277 This command initiates the LISP Internet Groper. It is similar to 278 the DNS analogue 'dig' but works on the LISP mapping database. When 279 this command is invoked, the local system will send a Map-Request to 280 the configured Map-Resolver. When a Map-Reply is returned, its 281 contents will be displayed to the user. By default, up to 3 Map- 282 Requests are sent if no Map-Reply is returned but once a Map-Reply is 283 returned no other Map-Requests are sent. The destination can take a 284 DNS name, or an IPv4 or IPv6 EID address. The can be 285 one of the EID addresses assigned to the site in the default VRF. 286 When is specified, then the Map-Request is sent to the address. 287 Otherwise, the Map-Request is sent to a configured Map-Resolver. 288 When a Map-Resolver is not configured then the Map-Request is sent on 289 the ALT network if the local router is attached to the ALT. When 290 "count <1-5>" is specified, 1, 2, 3, 4, or 5 Map-Requests are sent. 292 Some sample output: 294 router# lig abc.example.com 295 Send map-request to 10.0.0.1 for 192.168.1.1 ... 296 Received map-reply from 10.0.0.2 with rtt 0.081468 secs 298 Map-cache entry for abc.example.com EID 192.168.1.1: 299 192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58, 300 via map-reply, auth 301 Locator Uptime State Priority/Weight Packets In/Out 302 10.0.0.2 13:59:59 up 1/100 0/14 304 Using lig to "lig yourself" is accomplished with the following 305 syntax: 307 lig {self | self6} [source ] [to ] [count <1-5>] 309 Use this command for a simple way to see if the site is registered 310 with the mapping database system. The destination-EID address for 311 the Map-Request will be the first configured EID-prefix for the site 312 (with the host-bits set to 0). For example, if the site's EID-prefix 313 is 192.168.1.0/24, the destination-EID for the Map-Request is 314 192.168.1.0. The source-EID address for the Map-Request will also be 315 192.168.1.0 (in this example) and the Map-Request is sent to the 316 configured Map-Resolver. If the Map-Resolver and Map-Server are the 317 same LISP system, then the "lig self" is testing if the Map-Resolver 318 can "turn back a Map-Request to the site". If another Map-Resolver 319 is used, it can test that the site's EID-prefix has been injected 320 into the ALT infrastructure in which case the lig Map-Request is 321 processed by the Map-Resolver, propagated through each ALT router hop 322 to the site's registered Map-Server. Then the Map-Server returns the 323 Map-Request to the originating site. In which case, an xTR at the 324 originating site sends a Map-Reply to the source of the Map-Request 325 (could be itself or another xTR for the site). All other command 326 parameters are described above. Using "lig self6" tests for 327 registering of IPv6 EID- prefixes. 329 Some sample output for ligging yourself: 331 router# lig self 332 Send loopback map-request to 10.0.0.1 for 192.168.2.0 ... 333 Received map-reply from 10.0.0.3 with rtt 0.001592 secs 335 Map-cache entry for EID 192.168.2.0: 336 192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57 337 via map-reply, self 338 Locator Uptime State Priority/Weight Packets In/Out 339 10.0.0.3 00:00:02 up 1/100 0/0 341 router# lig self6 342 Send loopback map-request to 10.0.0.1 for 2001:db8:1:: ... 343 Received map-reply from 10::1 with rtt 0.044372 secs 345 Map-cache entry for EID 192:168:1::: 346 2001:db8:1::/48, uptime: 00:00:01, expires: 23:59:58 347 via map-reply, self 348 Locator Uptime State Priority/Weight Packets In/Out 349 10.0.0.3 00:00:01 up 1/100 0/0 350 2001:db8:ffff::1 00:00:01 up 2/0 0/0 352 4.2. Public Domain Host Implementation 354 There is a public domain implementation that can run on any x86 based 355 system. The only requirement is that the system that initiates lig 356 must have an address assigned from the locator namespace. 358 lig [-d] -m [-c ] [-t ] 360 Parameter description: 362 -d: prints additional protocol debug output. 364 : is the destination EID or FQDN of a LISP host. 366 -m : is the RLOC address or FQDN of a Map-Resolver. 368 -c : the number of Map-Requests to send before the first Map- 369 Reply is returned. The default value is 3. The range is from 1 370 to 5. 372 -t : the amount of time, in seconds, before another Map- 373 Request is sent when no Map-Reply is returned. The default value 374 is 2 seconds. The range is from 1 to 5. 376 Some sample output: 378 % lig xyz.example.com -m 10.0.0.1 379 Send map-request to 10.0.0.1 for 192.168.1.1 ... 380 Received map-reply from 10.0.0.2 with rtt 0.04000 sec 382 Mapping entry for EID 192.168.1.1: 383 192.168.1.0/24, record ttl: 60 384 Locator State Priority/Weight 385 10.0.0.1 up 1/25 386 10.0.0.2 up 1/25 387 10.0.0.3 up 1/25 388 10.0.0.4 up 2/25 390 The public domain implementation of lig is available at 391 http://github.com/davidmeyer/lig. 393 5. Testing the ALT 395 There are cases where a Map-Reply is returned from a lig request but 396 the user doesn't really know how much of the mapping infrastructure 397 was tested. There are two cases to consider, avoiding the ALT and 398 traversing the ALT. 400 When an ITR sends a lig request to its Map-Resolver for a 401 destination-EID, the Map-Resolver could also be configured as a Map- 402 Server. And if the destination-EID is for a site that registers with 403 this Map-Server, the Map-Request is sent to the site directly without 404 testing the ALT. This occurs because the Map-Server is the source of 405 the advertisement for the site's EID-prefix. So if the map-reply is 406 returned to the lig requesting site, you cannot be sure that other 407 sites can reach the same destination-EID. 409 If a Map-Resolver is used that is not a Map-Server for the EID-prefix 410 being sought, then the ALT infrastructure can be tested. This test 411 case is testing the functionality of the Map-Resolver, traversal of 412 the ALT (testing BGP-over-GRE), and the Map-Server. 414 It is recommended that users issue 2 lig requests, each of which send 415 Map-Requests to different Map-Resolvers. 417 The network can have a LISP-ALT router deployed as a "ALT looking- 418 glass" node. This type of router has BGP peering sessions with other 419 ALT routers where it does not inject any EID-prefixes into the ALT 420 but just learns ones advertised by other ALT routers and Map-Servers. 421 This router is configured as a Map-Resolver. Lig users can point to 422 the ALT looking-glass router for Map-Resolver services via the "to 423 " parameter on the lig command. The ALT looking-glass 424 node can be used to lig other sites as well as your own site. When 425 the ALT looking-glass is used as a Map-Resolver, you can be assured 426 the ALT network is being tested. 428 6. Future Enhancements 430 When negative Map-Replies have been further developed and 431 implemented, lig should be modified appropriately to process and 432 clearly indicate how and why a negative Map-Reply was received. 433 Negative Map-Replies could be sent in the following cases, the lig 434 request was initiated for a non-EID address or the Map-Request 435 initiated by lig request is being rejected due to rate-limiting on 436 the replier. 438 7. Deployed Network Diagnostic Tools 440 There is an web-based interface to do auto-polling with lig on the 441 back-end for most of the LISP sites on the LISP test network. The 442 web-page can be accessed at http://www.lisp4.net/status. 444 There is a LISP site monitoring web-based interface that can be found 445 at http://www.lisp4.net/lisp-site. 447 At http://baldomar.ccaba.upc.edu/lispmon, written by the folks at 448 UPC, shows a geographical map indicating where each LISP site 449 resides. 451 8. Security Considerations 453 The use of lig does not affect the security of the LISP 454 infrastructure as it is simply a tool that facilities diagnostic 455 querying. See [LISP], [ALT], and [LISP-MS] for descriptions of the 456 security properties of the LISP infrastructure. 458 Lig provides easy access to the information in the public mapping 459 database. Therefore, it is important to protect the mapping 460 information for private use. This can be provided by disallowing 461 access to specific mapping entries or to place such entries in a 462 private mapping database system. 464 9. IANA Considerations 466 This document makes no request of the IANA. 468 10. References 470 10.1. Normative References 472 [INTERWORK] 473 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 474 "Interworking LISP with IPv4 and IPv6", 475 draft-ietf-lisp-interworking-02.txt (work in progress). 477 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 478 "Locator/ID Separation Protocol (LISP)", 479 draft-ietf-lisp-15.txt (work in progress). 481 [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", 482 draft-ietf-lisp-ms-11.txt (work in progress). 484 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 485 (CIDR): The Internet Address Assignment and Aggregation 486 Plan", BCP 122, RFC 4632, August 2006. 488 10.2. Informative References 490 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 491 Alternative Topology (LISP-ALT)", 492 draft-ietf-lisp-alt-08.txt (work in progress). 494 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 495 Content distribution Overlay Network Service for LISP", 496 draft-meyer-lisp-cons-04.txt (work in progress). 498 [LISP-LIG] 499 Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", 500 draft-farinacci-lisp-lig-02.txt (work in progress). 502 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 503 draft-lear-lisp-nerd-08.txt (work in progress). 505 Appendix A. Acknowledgments 507 Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and 508 Vince Fuller for providing critical feedback on the lig design and 509 prototype implementations. These folks as well as all the people on 510 lisp-beta@external.cisco.com who tested lig functionality and 511 continue to do so, we extend our sincere thanks. 513 This working group draft is based on individual contribution 514 draft-farinacci-lisp-lig-02.txt [LISP-LIG]. 516 Authors' Addresses 518 Dino Farinacci 519 cisco Systems 520 Tasman Drive 521 San Jose, CA 95134 522 USA 524 Email: dino@cisco.com 526 Dave Meyer 527 cisco Systems 528 170 Tasman Drive 529 San Jose, CA 530 USA 532 Email: dmm@cisco.com