idnits 2.17.1 draft-ietf-lisp-lig-04.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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 10, 2011) is 4643 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '-d' is mentioned on line 343, but not defined -- No information found for draft-ietfr-lisp-alt - is the name correct? == Outdated reference: A later version (-24) exists of draft-ietf-lisp-15 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-10 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-08 Summary: 0 errors (**), 0 flaws (~~), 7 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: February 11, 2012 August 10, 2011 7 LISP Internet Groper (LIG) 8 draft-ietf-lisp-lig-04 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 February 11, 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, PTR, Map-Resolvers, Map-Servers, and LISP-ALT routers, as well 92 as by a host system at either a LISP-capable or non-LISP-capable 93 site. 95 2. Definition of Terms 97 Map-Server: a network infrastructure component which learns EID-to- 98 RLOC mapping entries from an authoritative source (typically, an 99 ETR, though static configuration or another out-of-band mechanism 100 may be used). A Map-Server advertises these mappings in the 101 distributed mapping database. 103 Map-Resolver: a network infrastructure component which accepts LISP 104 Encapsulated Map-Requests, typically from an ITR, quickly 105 determines whether or not the destination IP address is part of 106 the EID namespace; if it is not, a Negative Map-Reply is 107 immediately returned. Otherwise, the Map-Resolver finds the 108 appropriate EID-to-RLOC mapping by consulting the distributed 109 mapping database system. 111 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 112 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 113 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 114 numbered from topologically-aggregatable blocks that are assigned 115 to a site at each point to which it attaches to the global 116 Internet; where the topology is defined by the connectivity of 117 provider networks, RLOCs can be thought of as PA addresses. 118 Multiple RLOCs can be assigned to the same ETR device or to 119 multiple ETR devices at a site. 121 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 122 used in the source and destination address fields of the first 123 (most inner) LISP header of a packet. The host obtains a 124 destination EID the same way it obtains an destination address 125 today, for example through a DNS lookup or SIP exchange. The 126 source EID is obtained via existing mechanisms used to set a 127 host's "local" IP address. An EID is allocated to a host from an 128 EID-prefix block associated with the site where the host is 129 located. An EID can be used by a host to refer to other hosts. 130 EIDs must not be used as LISP RLOCs. Note that EID blocks may be 131 assigned in a hierarchical manner, independent of the network 132 topology, to facilitate scaling of the mapping database. In 133 addition, an EID block assigned to a site may have site-local 134 structure (subnetting) for routing within the site; this structure 135 is not visible to the global routing system. 137 EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that 138 stores, tracks, and is responsible for timing-out and otherwise 139 validating EID-to-RLOC mappings. This cache is distinct from the 140 full "database" of EID-to-RLOC mappings, it is dynamic, local to 141 the ITR(s), and relatively small while the database is 142 distributed, relatively static, and much more global in scope. 144 EID-to-RLOC Database: a global distributed database that contains 145 all known EID-prefix to RLOC mappings. Each potential ETR 146 typically contains a small piece of the database: the EID-to-RLOC 147 mappings for the EID prefixes "behind" the router. These map to 148 one of the router's own, globally-visible, IP addresses. 150 Encapsulated Map-Request (EMR): an EMR is a Map-Request message 151 which is encapsulated with another LISP header using UDP 152 destination port number 4341. It is used so an ITR, PTR, or a 153 system initiating a 'lig' command can get the Map-Request to a 154 Map-Resolver by using locater addresses. When the Map-Request is 155 decapsulated by the Map-Resolver it will be forwarded on the ALT 156 network to the Map-Server that has injected the EID-prefix for a 157 registered site. The Map-Server will then encapsulate the Map- 158 Request in a LISP packet and send it to an an ETR at the site. 159 The ETR will then return an authoritative reply to the system that 160 initiated the request. See [LISP] for packet format details. 162 Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP 163 packet with a single IP header (more precisely, an IP packet that 164 does not contain a LISP header). The router treats this "inner" 165 IP destination address as an EID and performs an EID-to-RLOC 166 mapping lookup. The router then prepends an "outer" IP header 167 with one of its globally-routable RLOCs in the source address 168 field and the result of the mapping lookup in the destination 169 address field. Note that this destination RLOC may be an 170 intermediate, proxy device that has better knowledge of the EID- 171 to-RLOC mapping closer to the destination EID. In general, an ITR 172 receives IP packets from site end-systems on one side and sends 173 LISP-encapsulated IP packets toward the Internet on the other 174 side. 176 Egress Tunnel Router (ETR): An ETR is a router that accepts an IP 177 packet where the destination address in the "outer" IP header is 178 one of its own RLOCs. The router strips the "outer" header and 179 forwards the packet based on the next IP header found. In 180 general, an ETR receives LISP-encapsulated IP packets from the 181 Internet on one side and sends decapsulated IP packets to site 182 end-systems on the other side. ETR functionality does not have to 183 be limited to a router device. A server host can be the endpoint 184 of a LISP tunnel as well. 186 xTR: A xTR is a reference to an ITR or ETR when direction of data 187 flow is not part of the context description. xTR refers to the 188 router that is the tunnel endpoint. Used synonymously with the 189 term "Tunnel Router". For example, "An xTR can be located at the 190 Customer Edge (CE) router", meaning both ITR and ETR functionality 191 is at the CE router. 193 Provider Assigned (PA) Addresses: PA addresses are an a address 194 block assigned to a site by each service provider to which a site 195 connects. Typically, each block is sub-block of a service 196 provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and 197 is aggregated into the larger block before being advertised into 198 the global Internet. Traditionally, IP multihoming has been 199 implemented by each multi-homed site acquiring its own, globally- 200 visible prefix. LISP uses only topologically-assigned and 201 aggregatable address blocks for RLOCs, eliminating this 202 demonstrably non-scalable practice. 204 3. Basic Overview 206 When the lig command is run, a Map-Request is sent for a destination 207 EID. When a Map-Reply is returned, the contents are displayed to the 208 user. The information displayed includes: 210 o The EID-prefix for the site the queried destination EID matches. 212 o The locator address of the Map Replier. 214 o The locator-set for the mapping entry which includes the locator 215 address, up/down status, priority, and weight of each locator. 217 o An round-trip-time estimate for the Map-Request/Map-Reply 218 exchange. 220 A possible syntax for a lig command could be: 222 lig [source ] [to ] 224 Parameter description: 226 : is either a Fully Qualified Domain Name or a 227 destination EID for a remote LISP site. 229 source : is an optional source EID to be inserted in the 230 "Source EID" field of the Map-Request. 232 to : is an optional Fully Qualified Domain Name or 233 RLOC address for a Map-Resolver. 235 The lig utility has two usage cases. The first being a way to query 236 the mapping database for a particular EID. And the other to verify 237 if a site has registered successfully with a Map-Server. 239 The first usage has already been described. Verifying registration 240 is called "ligging yourself". What occurs is in the lig initiator, a 241 Map-Request is sent for one of the EIDs for the lig initiator's site. 242 The Map-Request is then returned to one of the ETRs for the lig 243 initiating site. In response to the Map-Request, a Map-Reply is sent 244 back to the locator address of the lig initiator (note the Map-Reply 245 could be sent by the lig initiator). That Map-Reply is processed and 246 the mapping data for lig initiating site is displayed for the user. 247 Refer to the syntax in section Section 4.1 for an implementation of 248 "ligging yourself". However, for host-based implementations within a 249 LISP site, "lig self" is less useful since the host may not have an 250 RLOC to receive a Map-Reply with. But, lig can be used in a non-LISP 251 site as well as from infrastructure hosts to get mapping information. 253 4. Implementation Details 255 4.1. LISP Router Implementation 257 The cisco LISP prototype implementation has support for lig for IPv4 258 and IPv6. The command line description is: 260 lig [source ] [to ] [count <1-5>] 262 This command initiates the LISP Internet Groper. It is similar to 263 the DNS analogue 'dig' but works on the LISP mapping database. When 264 this command is invoked, the local system will send a Map-Request to 265 the configured Map-Resolver. When a Map-Reply is returned, its 266 contents will be displayed to the user. By default, up to 3 Map- 267 Requests are sent if no Map-Reply is returned but once a Map-Reply is 268 returned no other Map-Requests are sent. The destination can take a 269 DNS name, or an IPv4 or IPv6 EID address. The can be 270 one of the EID addresses assigned to the site in the default VRF. 271 When is specified, then the Map-Request is sent to the address. 272 Otherwise, the Map-Request is sent to a configured Map-Resolver. 273 When a Map-Resolver is not configured then the Map-Request is sent on 274 the ALT network if the local router is attached to the ALT. When 275 "count <1-5>" is specified, 1, 2, 3, 4, or 5 Map-Requests are sent. 277 Some sample output: 279 titanium-dino# lig titanium-dmm.lisp4.net 280 Send map-request to 10.0.0.1 for 192.168.1.1 ... 281 Received map-reply from 10.0.0.2 with rtt 0.081468 secs 283 Map-cache entry for titanium-dmm.lisp4.net EID 192.168.1.1: 284 192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58, 285 via map-reply, auth 286 Locator Uptime State Priority/Weight Packets In/Out 287 10.0.0.2 13:59:59 up 1/100 0/14 289 Using lig to "lig yourself" is accomplished with the following 290 syntax: 292 lig {self | self6} [source ] [to ] [count <1-5>] 294 Use this command for a simple way to see if the site is registered 295 with the mapping database system. The destination-EID address for 296 the Map-Request will be the first configured EID-prefix for the site 297 (with the host-bits set to 0). For example, if the site's EID-prefix 298 is 192.168.1.0/24, the destination-EID for the Map-Request is 299 192.168.1.0. The source-EID address for the Map-Request will also be 300 192.168.1.0 (in this example) and the Map-Request is sent to the 301 configured Map-Resolver. If the Map-Resolver and Map-Server are the 302 same LISP system, then the "lig self" is testing if the Map-Resolver 303 can "turn back a Map-Request to the site". If another Map-Resolver 304 is used, it can test that the site's EID-prefix has been injected 305 into the ALT infrastructure in which case the lig Map-Request is 306 processed by the Map-Resolver, propagated through each ALT router hop 307 to the site's registered Map-Server. Then the Map-Server returns the 308 Map-Request to originating site. In which case, an xTR at the 309 originating site sends a Map-Reply to the source of the Map-Request 310 (could be itself or another xTR for the site). All other command 311 parameters are described above. Using "lig self6" tests for 312 registering of IPv6 EID- prefixes. 314 Some sample output for ligging yourself: 316 rutile# lig self 317 Send loopback map-request to 10.0.0.1 for 192.168.2.0 ... 318 Received map-reply from 10.0.0.3 with rtt 0.001592 secs 320 Map-cache entry for EID 192.168.2.0: 321 192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57 322 via map-reply, self 323 Locator Uptime State Priority/Weight Packets In/Out 324 10.0.0.3 00:00:02 up 1/100 0/0 326 titanium-simlo# lig self6 327 Send loopback map-request to 10.0.0.1 for 2001:db8:1:: ... 328 Received map-reply from 10::1 with rtt 0.044372 secs 330 Map-cache entry for EID 192:168:1::: 331 2001:db8:1::/48, uptime: 00:00:01, expires: 23:59:58 332 via map-reply, self 333 Locator Uptime State Priority/Weight Packets In/Out 334 10.0.0.3 00:00:01 up 1/100 0/0 335 2001:db8:ffff::1 00:00:01 up 2/0 0/0 337 4.2. Public Domain Host Implementation 339 There is a public domain implementation that can run on any x86 based 340 system. The only requirement is that the system that initiates lig 341 must have an address assigned from the locator namespace. 343 lig [-d] -m [-c ] [-t ] 345 Parameter description: 347 -d: prints additional protocol debug output. 349 : is the destination EID or FQDN of a LISP host. 351 -m : is the RLOC address or FQDN of a Map-Resolver. 353 -c : the number of Map-Requests to send before the first Map- 354 Reply is returned. The default value is 3. The range is from 1 355 to 5. 357 -t : the amount of time, in seconds, before another Map- 358 Request is sent when no Map-Reply is returned. The default value 359 is 2 seconds. The range is from 1 to 5. 361 Some sample output: 363 % lig titanium-test.lisp4.net -m 10.0.0.1 364 Send map-request to 10.0.0.1 for 192.168.1.1 ... 365 Received map-reply from 10.0.0.2 with rtt 0.04000 sec 367 Mapping entry for EID 192.168.1.1: 368 192.168.1.0/24, record ttl: 60 369 Locator State Priority/Weight 370 10.0.0.1 up 1/25 371 10.0.0.2 up 1/25 372 10.0.0.3 up 1/25 373 10.0.0.4 up 2/25 375 The public domain implementation of lig is available at 376 http://github.com/davidmeyer/lig. 378 5. Testing the ALT 380 There are cases where a Map-Reply is returned from a lig request but 381 the user doesn't really know how much of the mapping infrastructure 382 was tested. There are two cases to consider, avoiding the ALT and 383 traversing the ALT. 385 When an ITR sends a lig request to its Map-Resolver for a 386 destination-EID, the Map-Resolver could also be configured as a Map- 387 Server. And if the destination-EID is for a site that registers with 388 this Map-Server, the Map-Request is sent to the site directly without 389 testing the ALT. This occurs because the Map-Server is the source of 390 the advertisement for the site's EID-prefix. So if the map-reply is 391 returned to the lig requesting site, you cannot be sure that other 392 sites can reach the same destination-EID. 394 If a Map-Resolver is used that is not a Map-Server for the EID-prefix 395 being sought, then the ALT infrastructure can be tested. This test 396 case is testing the functionality of the Map-Resolver, traversal of 397 the ALT (testing BGP-over-GRE), and the Map-Server. 399 It is recommended that users issue 2 lig requests, each which send 400 Map-Requests to different Map-Resolvers. 402 The network can have a LISP-ALT router deployed as a "ALT looking- 403 glass" node. This type of router has BGP peering sessions with other 404 ALT routers where it does not inject any EID-prefixes into the ALT 405 but just learns ones advertised by other ALT routers and Map-Servers. 406 This router is configured as a Map-Resolver. Lig users can point to 407 the ALT looking-glass router for Map-Resolver services via the "to 408 " parameter on the lig command. The ALT looking-glass 409 node can be used to lig other sites as well as your own site. When 410 the ALT looking-glass is used as a Map-Resolver, you can be assured 411 the ALT network is being tested. 413 6. Future Enhancements 415 When negative Map-Replies have been further developed and 416 implemented, lig should be modified appropriately to process and 417 clearly indicate how and why a negative Map-Reply was received. 418 Negative Map-Replies could be sent in the following cases, the lig 419 request was initiated for a non-EID address or the Map-Request 420 initiated by lig request is being rejected due to rate-limiting on 421 the replier. 423 7. Deployed Network Diagnostic Tools 425 There is an web-based interface to do auto-polling with lig on the 426 back-end for most of the LISP sites on the LISP test network. The 427 web-page can be accessed at http://www.lisp4.net/status. 429 There is a LISP site monitoring web-based interface that can be found 430 at http://www.lisp4.net/lisp-site. 432 At http://baldomar.ccaba.upc.edu/lispmon, written by the folks at 433 UPC, shows a geographical map indicating where each LISP site 434 resides. 436 8. Security Considerations 438 The use of lig does not affect the security of the LISP 439 infrastructure as it is simply a tool that facilities diagnostic 440 querying. See [LISP], [ALT], and [LISP-MS] for descriptions of the 441 security properties of the LISP infrastructure. 443 9. IANA Considerations 445 This document makes no request of the IANA. 447 10. References 449 10.1. Normative References 451 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 452 (CIDR): The Internet Address Assignment and Aggregation 453 Plan", BCP 122, RFC 4632, August 2006. 455 10.2. Informative References 457 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 458 Alternative Topology (LISP-ALT)", 459 draft-ietfr-lisp-alt-06.txt (work in progress). 461 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 462 Content distribution Overlay Network Service for LISP", 463 draft-meyer-lisp-cons-04.txt (work in progress). 465 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 466 "Locator/ID Separation Protocol (LISP)", 467 draft-ietf-lisp-15.txt (work in progress). 469 [LISP-LIG] 470 Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", 471 draft-farinacci-lisp-lig-02.txt (work in progress). 473 [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", 474 draft-ietf-lisp-ms-10.txt (work in progress). 476 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 477 draft-lear-lisp-nerd-08.txt (work in progress). 479 Appendix A. Acknowledgments 481 Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and 482 Vince Fuller for providing critical feedback on the lig design and 483 prototype implementations. These folks as well as all the people on 484 lisp-beta@external.cisco.com who tested lig functionality and 485 continue to do so, we extend our sincere thanks. 487 This working group draft is based on individual contribution 488 draft-farinacci-lisp-lig-02.txt [LISP-LIG]. 490 Authors' Addresses 492 Dino Farinacci 493 cisco Systems 494 Tasman Drive 495 San Jose, CA 95134 496 USA 498 Email: dino@cisco.com 500 Dave Meyer 501 cisco Systems 502 170 Tasman Drive 503 San Jose, CA 504 USA 506 Email: dmm@cisco.com