mappingservice/doc/rfc6833.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   2 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
   3     <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
   4     <meta name="robots" content="index,follow">
   5     <meta name="creator" content="rfcmarkup version 1.104">
   6     <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
   7 <meta name="DC.Relation.Replaces" content="draft-fuller-lisp-ms">
   8 <meta name="DC.Identifier" content="urn:ietf:rfc:6833">
   9 <meta name="DC.Date.Issued" content="January, 2013">
  10 <meta name="DC.Creator" content="Fuller, Vince">
  11 <meta name="DC.Creator" content="Farinacci, Dino">
  12 <meta name="DC.Description.Abstract" content="This document describes the Mapping Service for the Locator/ID\nSeparation Protocol (LISP), implemented by two new types of LISP-\nspeaking devices -- the LISP Map-Resolver and LISP Map-Server -- that\nprovides a simplified &quot;front end&quot; for one or more Endpoint ID to\nRouting Locator mapping databases.  By using this service interface\nand communicating with Map-Resolvers and Map-Servers, LISP Ingress\nTunnel Routers and Egress Tunnel Routers are not dependent on the\ndetails of mapping database systems, which facilitates experimentation\nwith different database designs. Since these devices implement the\n&quot;edge&quot; of the LISP infrastructure, connect directly to LISP-capable\nInternet end sites, and comprise the bulk of LISP-speaking devices,\nreducing their implementation and operational complexity should also\nreduce the overall cost and effort of deploying LISP. This document\ndefines an Experimental Protocol for the Internet community.">
  13 <meta name="DC.Title" content="Locator/ID Separation Protocol (LISP) Map-Server Interface">
  14
  15     <link rel="icon" href="http://tools.ietf.org/images/rfc.png" type="image/png">
  16     <link rel="shortcut icon" href="http://tools.ietf.org/images/rfc.png" type="image/png">
  17     <title>RFC 6833 - Locator/ID Separation Protocol (LISP) Map-Server Interface</title>
  18     <link rel="stylesheet" type="text/css" href="marking.css" />
  19
  20     <style type="text/css">
  21         body {
  22             margin: 0px 8px;
  23             font-size: 1em;
  24         }
  25         h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
  26             font-weight: bold;
  27             line-height: 0pt;
  28             display: inline;
  29             white-space: pre;
  30             font-family: monospace;
  31             font-size: 1em;
  32             font-weight: bold;
  33         }
  34         pre {
  35             font-size: 1em;
  36             margin-top: 0px;
  37             margin-bottom: 0px;
  38         }
  39         .pre {
  40             white-space: pre;
  41             font-family: monospace;
  42         }
  43         .header{
  44             font-weight: bold;
  45         }
  46         .newpage {
  47             page-break-before: always;
  48         }
  49         .invisible {
  50             text-decoration: none;
  51             color: white;
  52         }
  53         a.selflink {
  54           color: black;
  55           text-decoration: none;
  56         }
  57         @media print {
  58             body {
  59                 font-family: monospace;
  60                 font-size: 10.5pt;
  61             }
  62             h1, h2, h3, h4, h5, h6 {
  63                 font-size: 1em;
  64             }
  65
  66             a:link, a:visited {
  67                 color: inherit;
  68                 text-decoration: none;
  69             }
  70             .noprint {
  71                 display: none;
  72             }
  73         }
  74         @media screen {
  75             .grey, .grey a:link, .grey a:visited {
  76                 color: #777;
  77             }
  78             .docinfo {
  79                 background-color: #EEE;
  80             }
  81             .top {
  82                 border-top: 7px solid #EEE;
  83             }
  84             .bgwhite  { background-color: white; }
  85             .bgred    { background-color: #F44; }
  86             .bggrey   { background-color: #666; }
  87             .bgbrown  { background-color: #840; }
  88             .bgorange { background-color: #FA0; }
  89             .bgyellow { background-color: #EE0; }
  90             .bgmagenta{ background-color: #F4F; }
  91             .bgblue   { background-color: #66F; }
  92             .bgcyan   { background-color: #4DD; }
  93             .bggreen  { background-color: #4F4; }
  94
  95             .legend   { font-size: 90%; }
  96             .cplate   { font-size: 70%; border: solid grey 1px; }
  97         }
  98     </style>
  99     <!--[if IE]>
 100     <style>
 101     body {
 102        font-size: 13px;
 103        margin: 10px 10px;
 104     }
 105     </style>
 106     <![endif]-->
 107
 108     <script type="text/javascript"><!--
 109     function addHeaderTags() {
 110         var spans = document.getElementsByTagName("span");
 111         for (var i=0; i < spans.length; i++) {
 112             var elem = spans[i];
 113             if (elem) {
 114                 var level = elem.getAttribute("class");
 115                 if (level == "h1" || level == "h2" || level == "h3" || level == "h4" || level == "h5" || level == "h6") {
 116                     elem.innerHTML = "<"+level+">"+elem.innerHTML+"</"+level+">";
 117                 }
 118             }
 119         }
 120     }
 121     var legend_html = "Colour legend:<br />      <table>         <tr><td>Unknown:</td>                   <td><span class='cplate bgwhite'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Draft:</td>                     <td><span class='cplate bgred'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Informational:</td>             <td><span class='cplate bgorange'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Experimental:</td>              <td><span class='cplate bgyellow'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Best Common Practice:</td>      <td><span class='cplate bgmagenta'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Proposed Standard:</td>         <td><span class='cplate bgblue'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Internet Standard:</td>         <td><span class='cplate bggreen'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Historic:</td>                  <td><span class='cplate bggrey'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>         <tr><td>Obsolete:</td>                  <td><span class='cplate bgbrown'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr>     </table>";
 122     function showElem(id) {
 123         var elem = document.getElementById(id);
 124         elem.innerHTML = eval(id+"_html");
 125         elem.style.visibility='visible';
 126     }
 127     function hideElem(id) {
 128         var elem = document.getElementById(id);
 129         elem.style.visibility='hidden';
 130         elem.innerHTML = "";
 131     }
 132     // -->
 133     </script>
 134 </head>
 135 <body onload="addHeaderTags()">
 136    <div style="height: 13px;">
 137       <div onmouseover="this.style.cursor='pointer';" onclick="showElem('legend');" onmouseout="hideElem('legend')" style="height: 6px; position: absolute;" class="pre noprint docinfo bgyellow" title="Click for colour legend.">                                                                        </div>
 138       <div id="legend" class="docinfo noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="showElem('legend');" onmouseout="hideElem('legend');">
 139       </div>
 140    </div>
 141 <span class="pre noprint docinfo top">[<a href="http://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="http://tools.ietf.org/rfc/rfc6833.txt" title="Plaintext version of this document">txt</a>|<a href="http://tools.ietf.org/pdf/rfc6833" title="PDF version of this document">pdf</a>] [<a href="http://tools.ietf.org/html/draft-ietf-lisp-ms" title="draft-ietf-lisp-ms">draft-ietf-lisp-ms</a>] [<a href="http://tools.ietf.org/rfcdiff?difftype=--hwdiff&amp;url2=rfc6833" title="Inline diff (wdiff)">Diff1</a>] [<a href="http://tools.ietf.org/rfcdiff?url2=rfc6833" title="Side-by-side diff">Diff2</a>]                   </span><br>
 142 <span class="pre noprint docinfo">                                                                        </span><br>
 143 <span class="pre noprint docinfo">                                                            EXPERIMENTAL</span><br>
 144 <span class="pre noprint docinfo">                                                                        </span><br>
 145 <pre>Internet Engineering Task Force (IETF)                         V. Fuller
 146 Request for Comments: 6833
 147 Category: Experimental                                      D. Farinacci
 148 ISSN: 2070-1721                                            Cisco Systems
 149                                                             January 2013
 150
 151
 152        <span class="h1"><h1>Locator/ID Separation Protocol (LISP) Map-Server Interface</h1></span>
 153
 154 Abstract
 155
 156    This document describes the Mapping Service for the Locator/ID
 157    Separation Protocol (LISP), implemented by two new types of LISP-
 158    speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that
 159    provides a simplified "front end" for one or more Endpoint ID to
 160    Routing Locator mapping databases.
 161
 162    By using this service interface and communicating with Map-Resolvers
 163    and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel
 164    Routers are not dependent on the details of mapping database systems,
 165    which facilitates experimentation with different database designs.
 166    Since these devices implement the "edge" of the LISP infrastructure,
 167    connect directly to LISP-capable Internet end sites, and comprise the
 168    bulk of LISP-speaking devices, reducing their implementation and
 169    operational complexity should also reduce the overall cost and effort
 170    of deploying LISP.
 171
 172 Status of This Memo
 173
 174    This document is not an Internet Standards Track specification; it is
 175    published for examination, experimental implementation, and
 176    evaluation.
 177
 178    This document defines an Experimental Protocol for the Internet
 179    community.  This document is a product of the Internet Engineering
 180    Task Force (IETF).  It represents the consensus of the IETF
 181    community.  It has received public review and has been approved for
 182    publication by the Internet Engineering Steering Group (IESG).  Not
 183    all documents approved by the IESG are a candidate for any level of
 184    Internet Standard; see <a href="http://tools.ietf.org/html/rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.
 185
 186    Information about the current status of this document, any errata,
 187    and how to provide feedback on it may be obtained at
 188    <a href="http://www.rfc-editor.org/info/rfc6833">http://www.rfc-editor.org/info/rfc6833</a>.
 189
 190
 191
 192
 193
 194
 195
 196 <span class="grey">Fuller &amp; Farinacci            Experimental                      [Page 1]</span>
 197 </pre><!--NewPage--><pre class="newpage"><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a>
 198 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 199
 200
 201 Copyright Notice
 202
 203    Copyright (c) 2013 IETF Trust and the persons identified as the
 204    document authors.  All rights reserved.
 205
 206    This document is subject to <a href="http://tools.ietf.org/html/bcp78">BCP 78</a> and the IETF Trust's Legal
 207    Provisions Relating to IETF Documents
 208    (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
 209    publication of this document.  Please review these documents
 210    carefully, as they describe your rights and restrictions with respect
 211    to this document.  Code Components extracted from this document must
 212    include Simplified BSD License text as described in <a href="#section-4">Section 4</a>.e of
 213    the Trust Legal Provisions and are provided without warranty as
 214    described in the Simplified BSD License.
 215
 216 Table of Contents
 217
 218    <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
 219    <a href="#section-2">2</a>. Definition of Terms .............................................<a href="#page-3">3</a>
 220    <a href="#section-3">3</a>. Basic Overview ..................................................<a href="#page-4">4</a>
 221    <a href="#section-4">4</a>. Interactions with Other LISP Components .........................<a href="#page-5">5</a>
 222       <a href="#section-4.1">4.1</a>. ITR EID-to-RLOC Mapping Resolution .........................<a href="#page-5">5</a>
 223       <a href="#section-4.2">4.2</a>. EID-Prefix Configuration and ETR Registration ..............<a href="#page-6">6</a>
 224       <a href="#section-4.3">4.3</a>. Map-Server Processing ......................................<a href="#page-8">8</a>
 225       <a href="#section-4.4">4.4</a>. Map-Resolver Processing ....................................<a href="#page-9">9</a>
 226            <a href="#section-4.4.1">4.4.1</a>. Anycast Map-Resolver Operation .....................<a href="#page-10">10</a>
 227    <a href="#section-5">5</a>. Open Issues and Considerations .................................<a href="#page-10">10</a>
 228    <a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-11">11</a>
 229    <a href="#section-7">7</a>. References .....................................................<a href="#page-12">12</a>
 230       <a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-12">12</a>
 231       <a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-12">12</a>
 232    <a href="#appendix-A">Appendix A</a>. Acknowledgments .......................................<a href="#page-13">13</a>
 233
 234 <span class="h2"><h2><a class="selflink" name="section-1" href="#section-1">1</a>.  Introduction</h2></span>
 235
 236    The Locator/ID Separation Protocol [<a href="http://tools.ietf.org/html/rfc6830" title="&quot;The Locator/ID Separation Protocol (LISP)&quot;">RFC6830</a>] specifies an
 237    architecture and mechanism for replacing the addresses currently used
 238    by IP with two separate name spaces: Endpoint IDs (EIDs), used within
 239    sites; and Routing Locators (RLOCs), used on the transit networks
 240    that make up the Internet infrastructure.  To achieve this
 241    separation, LISP defines protocol mechanisms for mapping from EIDs to
 242    RLOCs.  In addition, LISP assumes the existence of a database to
 243    store and propagate those mappings globally.  Several such databases
 244    have been proposed; among them are the Content distribution Overlay
 245    Network Service for LISP (LISP-CONS) [<a href="#ref-LISP-CONS" title="&quot;LISP-CONS: A Content distribution Overlay Network Service for LISP&quot;">LISP-CONS</a>], LISP-NERD
 246    (a Not-so-novel EID-to-RLOC Database) [<a href="http://tools.ietf.org/html/rfc6837" title="&quot;NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database&quot;">RFC6837</a>], and LISP Alternative
 247    Logical Topology (LISP+ALT) [<a href="http://tools.ietf.org/html/rfc6836" title="&quot;Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)&quot;">RFC6836</a>].
 248
 249
 250
 251
 252 <span class="grey">Fuller &amp; Farinacci            Experimental                      [Page 2]</span>
 253 </pre><!--NewPage--><pre class="newpage"><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a>
 254 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 255
 256
 257    The LISP Mapping Service defines two new types of LISP-speaking
 258    devices: the Map-Resolver, which accepts Map-Requests from an Ingress
 259    Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a
 260    mapping database; and the Map-Server, which learns authoritative
 261    EID-to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes
 262    them in a database.
 263
 264    Conceptually, LISP Map-Servers share some of the same basic
 265    configuration and maintenance properties as Domain Name System (DNS)
 266    [<a href="http://tools.ietf.org/html/rfc1035" title="&quot;Domain names - implementation and specification&quot;">RFC1035</a>] servers; likewise, Map-Resolvers are conceptually similar
 267    to DNS caching resolvers.  With this in mind, this specification
 268    borrows familiar terminology (resolver and server) from the DNS
 269    specifications.
 270
 271    Note that while this document assumes a LISP+ALT database mapping
 272    infrastructure to illustrate certain aspects of Map-Server and
 273    Map-Resolver operation, the Mapping Service interface can (and likely
 274    will) be used by ITRs and ETRs to access other mapping database
 275    systems as the LISP infrastructure evolves.
 276
 277    <a href="#section-5">Section 5</a> of this document notes a number of issues with the
 278    Map-Server and Map-Resolver design that are not yet completely
 279    understood and are subjects of further experimentation.
 280
 281    The LISP Mapping Service is an important component of the LISP
 282    toolset.  Issues and concerns about the deployment of LISP for
 283    Internet traffic are discussed in [<a href="http://tools.ietf.org/html/rfc6830" title="&quot;The Locator/ID Separation Protocol (LISP)&quot;">RFC6830</a>].
 284
 285 <span class="h2"><h2><a class="selflink" name="section-2" href="#section-2">2</a>.  Definition of Terms</h2></span>
 286
 287    Map-Server:   A network infrastructure component that learns of
 288       EID-Prefix mapping entries from an ETR, via the registration
 289       mechanism described below, or some other authoritative source if
 290       one exists.  A Map-Server publishes these EID-Prefixes in a
 291       mapping database.
 292
 293    Map-Resolver:   A network infrastructure component that accepts LISP
 294       Encapsulated Map-Requests, typically from an ITR, and determines
 295       whether or not the destination IP address is part of the EID
 296       namespace; if it is not, a Negative Map-Reply is returned.
 297       Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC
 298       mapping by consulting a mapping database system.
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308 <span class="grey">Fuller &amp; Farinacci            Experimental                      [Page 3]</span>
 309 </pre><!--NewPage--><pre class="newpage"><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a>
 310 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 311
 312
 313    Encapsulated Map-Request:   A LISP Map-Request carried within an
 314       Encapsulated Control Message, which has an additional LISP header
 315       prepended.  Sent to UDP destination port 4342.  The "outer"
 316       addresses are globally routable IP addresses, also known as RLOCs.
 317       Used by an ITR when sending to a Map-Resolver and by a Map-Server
 318       when forwarding a Map-Request to an ETR.
 319
 320    Negative Map-Reply:   A LISP Map-Reply that contains an empty
 321       Locator-Set.  Returned in response to a Map-Request if the
 322       destination EID does not exist in the mapping database.
 323       Typically, this means that the "EID" being requested is an IP
 324       address connected to a non-LISP site.
 325
 326    Map-Register message:   A LISP message sent by an ETR to a Map-Server
 327       to register its associated EID-Prefixes.  In addition to the set
 328       of EID-Prefixes to register, the message includes one or more
 329       RLOCs to be used by the Map-Server when forwarding Map-Requests
 330       (re-formatted as Encapsulated Map-Requests) received through the
 331       database mapping system.  <span class="known">An ETR may request that the Map-Server
 332       answer Map-Requests on its behalf by setting the "proxy Map-Reply"
 333       flag (P-bit) in the message.</span>
 334
 335    Map-Notify message:   A LISP message sent by a Map-Server to an ETR
 336       to confirm that a Map-Register has been received and processed.
 337       <span class="impl">An ETR requests that a Map-Notify be returned by setting the
 338       "want-map-notify" flag (M-bit) in the Map-Register message.</span>
 339       <span class="impl">Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both
 340       source and destination.</span>
 341
 342    For definitions of other terms -- notably Map-Request, Map-Reply,
 343    Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please
 344    consult the LISP specification [<a href="http://tools.ietf.org/html/rfc6830" title="&quot;The Locator/ID Separation Protocol (LISP)&quot;">RFC6830</a>].
 345
 346 <span class="h2"><h2><a class="selflink" name="section-3" href="#section-3">3</a>.  Basic Overview</h2></span>
 347
 348    A Map-Server is a device that publishes EID-Prefixes in a LISP
 349    mapping database on behalf of a set of ETRs.  When it receives a Map
 350    Request (typically from an ITR), it consults the mapping database to
 351    find an ETR that can answer with the set of RLOCs for an EID-Prefix.
 352    To publish its EID-Prefixes, an ETR periodically sends Map-Register
 353    messages to the Map-Server.  A Map-Register message contains a list
 354    of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR
 355    when a Map-Server needs to forward a Map-Request to it.
 356
 357
 358
 359
 360
 361
 362
 363
 364 <span class="grey">Fuller &amp; Farinacci            Experimental                      [Page 4]</span>
 365 </pre><!--NewPage--><pre class="newpage"><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a>
 366 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 367
 368
 369    When LISP+ALT is used as the mapping database, a Map-Server connects
 370    to the ALT network and acts as a "last-hop" ALT-Router.  Intermediate
 371    ALT-Routers forward Map-Requests to the Map-Server that advertises a
 372    particular EID-Prefix, and the Map-Server forwards them to the owning
 373    ETR, which responds with Map-Reply messages.
 374
 375    A Map-Resolver receives Encapsulated Map-Requests from its client
 376    ITRs and uses a mapping database system to find the appropriate ETR
 377    to answer those requests.  On a LISP+ALT network, a Map-Resolver acts
 378    as a "first-hop" ALT-Router.  It has Generic Routing Encapsulation
 379    (GRE) tunnels configured to other ALT-Routers and uses BGP to learn
 380    paths to ETRs for different prefixes in the LISP+ALT database.  The
 381    Map-Resolver uses this path information to forward Map-Requests over
 382    the ALT to the correct ETRs.
 383
 384    Note that while it is conceivable that a Map-Resolver could cache
 385    responses to improve performance, issues surrounding cache management
 386    will need to be resolved so that doing so will be reliable and
 387    practical.  As initially deployed, Map-Resolvers will operate only in
 388    a non-caching mode, decapsulating and forwarding Encapsulated Map
 389    Requests received from ITRs.  Any specification of caching
 390    functionality is left for future work.
 391
 392    Note that a single device can implement the functions of both a
 393    Map-Server and a Map-Resolver, and in many cases the functions will
 394    be co-located in that way.
 395
 396    Detailed descriptions of the LISP packet types referenced by this
 397    document may be found in [<a href="http://tools.ietf.org/html/rfc6830" title="&quot;The Locator/ID Separation Protocol (LISP)&quot;">RFC6830</a>].
 398
 399 <span class="h2"><h2><a class="selflink" name="section-4" href="#section-4">4</a>.  Interactions with Other LISP Components</h2></span>
 400
 401 <span class="h3"><h3><a class="selflink" name="section-4.1" href="#section-4.1">4.1</a>.  ITR EID-to-RLOC Mapping Resolution</h3></span>
 402
 403    An ITR is configured with one or more Map-Resolver addresses.  These
 404    addresses are "Locators" (or RLOCs) and must be routable on the
 405    underlying core network; they must not need to be resolved through
 406    LISP EID-to-RLOC mapping, as that would introduce a circular
 407    dependency.  When using a Map-Resolver, an ITR does not need to
 408    connect to any other database mapping system.  In particular, the ITR
 409    need not connect to the LISP+ALT infrastructure or implement the BGP
 410    and GRE protocols that it uses.
 411
 412    An ITR sends an Encapsulated Map-Request to a configured Map-Resolver
 413    when it needs an EID-to-RLOC mapping that is not found in its local
 414    map-cache.  Using the Map-Resolver greatly reduces both the
 415    complexity of the ITR implementation and the costs associated with
 416    its operation.
 417
 418
 419
 420 <span class="grey">Fuller &amp; Farinacci            Experimental                      [Page 5]</span>
 421 </pre><!--NewPage--><pre class="newpage"><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a>
 422 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 423
 424
 425    In response to an Encapsulated Map-Request, the ITR can expect one of
 426    the following:
 427
 428    o  <span class="miss">An immediate Negative Map-Reply (with action code of
 429       "Natively-Forward", 15-minute Time to Live (TTL)) from the
 430       Map-Resolver if the Map-Resolver can determine that the requested
 431       EID does not exist.</span>  The ITR saves the EID-Prefix returned in the
 432       Map-Reply in its cache, marks it as non-LISP-capable, and knows
 433       not to attempt LISP encapsulation for destinations matching it.
 434
 435    o  <span class="miss">A Negative Map-Reply, with action code of "Natively-Forward", from
 436       a Map-Server that is authoritative for an EID-Prefix that matches
 437       the requested EID but that does not have an actively registered,
 438       more-specific ID-prefix.</span>  In this case, the requested EID is said
 439       to match a "hole" in the authoritative EID-Prefix.  If the
 440       requested EID matches a more-specific EID-Prefix that has been
 441       delegated by the Map-Server but for which no ETRs are currently
 442       registered, a 1-minute TTL is returned.  If the requested EID
 443       matches a non-delegated part of the authoritative EID-Prefix, then
 444       it is not a LISP EID and a 15-minute TTL is returned.  See
 445       <a href="#section-4.2">Section 4.2</a> for discussion of aggregate EID-Prefixes and details
 446       of Map-Server EID-Prefix matching.
 447
 448    o  <span class="nrel">A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
 449       possibly from a Map-Server answering on behalf of the ETR.  See
 450       <a href="#section-4.4">Section 4.4</a> for more details on Map-Resolver message processing.
 451
 452    Note that an ITR may be configured to both use a Map-Resolver and to
 453    participate in a LISP+ALT logical network.  In such a situation, the
 454    ITR should send Map-Requests through the ALT network for any
 455    EID-Prefix learned via ALT BGP.  Such a configuration is expected to
 456    be very rare, since there is little benefit to using a Map-Resolver
 457    if an ITR is already using LISP+ALT.  There would be, for example, no
 458    need for such an ITR to send a Map-Request to a possibly non-existent
 459    EID (and rely on Negative Map-Replies) if it can consult the ALT
 460    database to verify that an EID-Prefix is present before sending that
 461    Map-Request.
 462
 463 <span class="h3"><h3><a class="selflink" name="section-4.2" href="#section-4.2">4.2</a>.  EID-Prefix Configuration and ETR Registration</h3></span>
 464
 465    An ETR publishes its EID-Prefixes on a Map-Server by sending LISP
 466    Map-Register messages.  <span class="miss">A Map-Register message includes
 467    authentication data, so prior to sending a Map-Register message, the
 468    ETR and Map-Server must be configured with a shared secret or other
 469    relevant authentication information.  A Map-Server's configuration
 470    must also include a list of the EID-Prefixes for which each ETR is
 471    authoritative.  Upon receipt of a Map-Register from an ETR, a
 472    Map-Server accepts only EID-Prefixes that are configured for that</span>
 473
 474
 475
 476 <span class="grey">Fuller &amp; Farinacci            Experimental                      [Page 6]</span>
 477 </pre><!--NewPage--><pre class="newpage"><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a>
 478 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 479
 480
 481    <span class="miss">ETR.  Failure to implement such a check would leave the mapping
 482    system vulnerable to trivial EID-Prefix hijacking attacks.  As
 483    developers and operators gain experience with the mapping system,
 484    additional, stronger security measures may be added to the
 485    registration process.
 486
 487    In addition to the set of EID-Prefixes defined for each ETR that may
 488    register, a Map-Server is typically also configured with one or more
 489    aggregate prefixes that define the part of the EID numbering space
 490    assigned to it.  When LISP+ALT is the database in use, aggregate
 491    EID-Prefixes are implemented as discard routes and advertised into
 492    ALT BGP.  The existence of aggregate EID-Prefixes in a Map-Server's
 493    database means that it may receive Map Requests for EID-Prefixes that
 494    match an aggregate but do not match a registered prefix; <a href="#section-4.3">Section 4.3</a>
 495    describes how this is handled.</span>
 496
 497    Map-Register messages are sent periodically from an ETR to a
 498    Map-Server with a suggested interval between messages of one minute.
 499    <span class="miss">A Map-Server should time out and remove an ETR's registration if it
 500    has not received a valid Map-Register message within the past
 501    three minutes.  </span>When first contacting a Map-Server after restart or
 502    changes to its EID-to-RLOC database mappings, an ETR may initially
 503    send Map-Register messages at an increased frequency, up to one every
 504    20 seconds.  This "quick registration" period is limited to
 505    five minutes in duration.
 506
 507    <span class="impl">An ETR may request that a Map-Server explicitly acknowledge receipt
 508    and processing of a Map-Register message by setting the
 509    "want-map-notify" (M-bit) flag.  A Map-Server that receives a
 510    Map-Register with this flag set will respond with a Map-Notify
 511    message.</span>  Typical use of this flag by an ETR would be to set it for
 512    Map-Register messages sent during the initial "quick registration"
 513    with a Map-Server but then set it only occasionally during
 514    steady-state maintenance of its association with that Map-Server.
 515    <span class="impl">Note that the Map-Notify message is sent to UDP destination port
 516    4342, not to the source port specified in the original Map-Register
 517    message.</span>
 518
 519    <span class="miss">Note that a one-minute minimum registration interval during
 520    maintenance of an ETR-Map-Server association places a lower bound on
 521    how quickly and how frequently a mapping database entry can be
 522    updated.  This may have implications for what sorts of mobility can
 523    be supported directly by the mapping system; shorter registration
 524    intervals or other mechanisms might be needed to support faster
 525    mobility in some cases.  For a discussion on one way that faster
 526    mobility may be implemented for individual devices, please see
 527    [<a href="#ref-LISP-MN" title="&quot;LISP Mobile Node&quot;">LISP-MN</a>].</span>
 528
 529
 530
 531
 532 <span class="grey">Fuller &amp; Farinacci            Experimental                      [Page 7]</span>
 533 </pre><!--NewPage--><pre class="newpage"><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a>
 534 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 535
 536
 537    <span class="known">An ETR may also request, by setting the "proxy Map-Reply" flag
 538    (P-bit) in the Map-Register message, that a Map-Server answer
 539    Map-Requests instead of forwarding them to the ETR.</span>  See [<a href="http://tools.ietf.org/html/rfc6830" title="&quot;The Locator/ID Separation Protocol (LISP)&quot;">RFC6830</a>]
 540    for details on how the Map-Server sets certain flags (such as those
 541    indicating whether the message is authoritative and how returned
 542    Locators should be treated) when sending a Map-Reply on behalf of an
 543    ETR.  <span class="miss">When an ETR requests proxy reply service, it should include all
 544    RLOCs for all ETRs for the EID-Prefix being registered, along with
 545    the routable flag ("R-bit") setting for each RLOC.  The Map-Server
 546    includes all of this information in Map-Reply messages that it sends
 547    on behalf of the ETR.</span>  This differs from a non-proxy registration,
 548    since the latter need only provide one or more RLOCs for a Map-Server
 549    to use for forwarding Map-Requests; the registration information is
 550    not used in Map-Replies, so it being incomplete is not incorrect.
 551
 552    An ETR that uses a Map-Server to publish its EID-to-RLOC mappings
 553    does not need to participate further in the mapping database
 554    protocol(s).  When using a LISP+ALT mapping database, for example,
 555    this means that the ETR does not need to implement GRE or BGP, which
 556    greatly simplifies its configuration and reduces its cost of
 557    operation.
 558
 559    Note that use of a Map-Server does not preclude an ETR from also
 560    connecting to the mapping database (i.e., it could also connect to
 561    the LISP+ALT network), but doing so doesn't seem particularly useful,
 562    as the whole purpose of using a Map-Server is to avoid the complexity
 563    of the mapping database protocols.
 564
 565 <span class="h3"><h3><a class="selflink" name="section-4.3" href="#section-4.3">4.3</a>.  Map-Server Processing</h3></span>
 566
 567    Once a Map-Server has EID-Prefixes registered by its client ETRs, it
 568    can accept and process Map-Requests for them.
 569
 570    In response to a Map-Request (received over the ALT if LISP+ALT is in
 571    use), the Map-Server first checks to see if the destination EID
 572    matches a configured EID-Prefix.  <span class="miss">If there is no match, the
 573    Map-Server returns a Negative Map-Reply with action code
 574    "Natively-Forward" and a 15-minute TTL.  This may occur if a Map
 575    Request is received for a configured aggregate EID-Prefix for which
 576    no more-specific EID-Prefix exists; it indicates the presence of a
 577    non-LISP "hole" in the aggregate EID-Prefix.</span>
 578
 579    <span class="miss">Next, the Map-Server checks to see if any ETRs have registered the
 580    matching EID-Prefix.  If none are found, then the Map-Server returns
 581    a Negative Map-Reply with action code "Natively-Forward" and a
 582    1-minute TTL.</span>
 583
 584
 585
 586
 587
 588 <span class="grey">Fuller &amp; Farinacci            Experimental                      [Page 8]</span>
 589 </pre><!--NewPage--><pre class="newpage"><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a>
 590 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 591
 592
 593    If any of the registered ETRs for the EID-Prefix have requested proxy
 594    reply service, then the Map-Server answers the request instead of
 595    forwarding it.  <span class="part">It returns a Map-Reply with the EID-Prefix, RLOCs,
 596    and other information learned through the registration process.</span>
 597
 598    <span class="miss">If none of the ETRs have requested proxy reply service, then the
 599    Map-Server re-encapsulates and forwards the resulting Encapsulated
 600    Map-Request to one of the registered ETRs.  It does not otherwise
 601    alter the Map-Request, so any Map-Reply sent by the ETR is returned
 602    to the RLOC in the Map-Request, not to the Map-Server.</span>  Unless also
 603    acting as a Map-Resolver, a Map-Server should never receive
 604    Map-Replies; any such messages should be discarded without response,
 605    perhaps accompanied by the logging of a diagnostic message if the
 606    rate of Map-Replies is suggestive of malicious traffic.
 607
 608 <span class="h3"><h3><a class="selflink" name="section-4.4" href="#section-4.4">4.4</a>.  Map-Resolver Processing</h3></span>
 609
 610    <span class="impl">Upon receipt of an Encapsulated Map-Request, a Map-Resolver
 611    decapsulates the enclosed message and then searches for the requested
 612    EID in its local database of mapping entries (statically configured
 613    or learned from associated ETRs if the Map-Resolver is also a
 614    Map-Server offering proxy reply service).  If it finds a matching
 615    entry, it returns a LISP Map-Reply with the known mapping.</span>
 616
 617    <span class="miss">If the Map-Resolver does not have the mapping entry and if it can
 618    determine that the EID is not in the mapping database (for example,
 619    if LISP+ALT is used, the Map-Resolver will have an ALT forwarding
 620    table that covers the full EID space), it immediately returns a
 621    negative LISP Map-Reply, with action code "Natively-Forward" and a
 622    15-minute TTL.</span>  <span class="miss">To minimize the number of negative cache entries
 623    needed by an ITR, the Map-Resolver should return the least-specific
 624    prefix that both matches the original query and does not match any
 625    EID-Prefix known to exist in the LISP-capable infrastructure.</span>
 626
 627    <span class="arch">If the Map-Resolver does not have sufficient information to know
 628    whether the EID exists, it needs to forward the Map-Request to
 629    another device that has more information about the EID being
 630    requested.  To do this, it forwards the unencapsulated Map-Request,
 631    with the original ITR RLOC as the source, to the mapping database
 632    system.  Using LISP+ALT, the Map-Resolver is connected to the ALT
 633    network and sends the Map-Request to the next ALT hop learned from
 634    its ALT BGP neighbors.  The Map-Resolver does not send any response
 635    to the ITR; since the source RLOC is that of the ITR, the ETR or
 636    Map-Server that receives the Map-Request over the ALT and responds
 637    will do so directly to the ITR.</span>
 638
 639
 640
 641
 642
 643
 644 <span class="grey">Fuller &amp; Farinacci            Experimental                      [Page 9]</span>
 645 </pre><!--NewPage--><pre class="newpage"><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a>
 646 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 647
 648
 649 <span class="h4"><h4><a class="selflink" name="section-4.4.1" href="#section-4.4.1">4.4.1</a>.  Anycast Map-Resolver Operation</h4></span>
 650
 651    <span class="arch">A Map-Resolver can be set up to use "anycast", where the same address
 652    is assigned to multiple Map-Resolvers and is propagated through IGP
 653    routing, to facilitate the use of a topologically close Map-Resolver
 654    by each ITR.
 655
 656    Note that Map-Server associations with ETRs should not use anycast
 657    addresses, as registrations need to be established between an ETR and
 658    a specific set of Map-Servers, each identified by a specific
 659    registration association.</span>
 660
 661 <span class="h2"><h2><a class="selflink" name="section-5" href="#section-5">5</a>.  Open Issues and Considerations</h2></span>
 662
 663    <span class="arch">There are a number of issues with the Map-Server and Map-Resolver
 664    design that are not yet completely understood.  Among these are:
 665
 666    o  Constants, such as those used for Map-Register frequency,
 667       retransmission timeouts, retransmission limits, Negative Map-Reply
 668       TTLs, et al. are subject to further refinement as more experience
 669       with prototype deployment is gained.
 670
 671    o  Convergence time when an EID-to-RLOC mapping changes, and
 672       mechanisms for detecting and refreshing or removing stale, cached
 673       information.
 674
 675    o  Deployability and complexity tradeoffs of implementing stronger
 676       security measures in both EID-Prefix registration and Map-Request/
 677       Map-Reply processing.
 678
 679    o  Requirements for additional state in the registration process
 680       between Map-Servers and ETRs.</span>
 681
 682    A discussion of other issues surrounding LISP deployment may also be
 683    found in <a href="http://tools.ietf.org/html/rfc6830#section-15">Section&nbsp;15 of [RFC6830]</a>.
 684
 685    The authors expect that experimentation on the LISP pilot network
 686    will help answer open questions surrounding these and other issues.
 687
 688
 689
 690
 691
 692
 693
 694
 695
 696
 697
 698
 699
 700 <span class="grey">Fuller &amp; Farinacci            Experimental                     [Page 10]</span>
 701 </pre><!--NewPage--><pre class="newpage"><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a>
 702 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 703
 704
 705 <span class="h2"><h2><a class="selflink" name="section-6" href="#section-6">6</a>.  Security Considerations</h2></span>
 706
 707    The 2-way LISP header nonce exchange documented in [<a href="http://tools.ietf.org/html/rfc6830" title="&quot;The Locator/ID Separation Protocol (LISP)&quot;">RFC6830</a>] can be
 708    used to avoid ITR spoofing attacks.
 709
 710    To publish an authoritative EID-to-RLOC mapping with a Map-Server, an
 711    ETR includes authentication data that is a hash of the message using
 712    a pair-wise shared key.  An implementation must support use of
 713    HMAC-SHA-1-96 [<a href="http://tools.ietf.org/html/rfc2104" title="&quot;HMAC: Keyed- Hashing for Message Authentication&quot;">RFC2104</a>] and should support use of HMAC-SHA-256-128
 714    [<a href="http://tools.ietf.org/html/rfc6234" title="&quot;US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)&quot;">RFC6234</a>] (SHA-256 truncated to 128 bits).
 715
 716    During experimental and prototype deployment, all authentication key
 717    configuration will be manual.  Should LISP and its components be
 718    considered for IETF standardization, further work will be required to
 719    follow the <a href="http://tools.ietf.org/html/bcp107">BCP 107</a> [<a href="http://tools.ietf.org/html/rfc4107" title="&quot;Guidelines for Cryptographic Key Management&quot;">RFC4107</a>] recommendations on automated key
 720    management.
 721
 722    As noted in <a href="#section-4.2">Section 4.2</a>, a Map-Server should verify that all
 723    EID-Prefixes registered by an ETR match the configuration stored on
 724    the Map-Server.
 725
 726    The currently defined authentication mechanism for Map-Register
 727    messages does not provide protection against "replay" attacks by a
 728    "man-in-the-middle".  Additional work is needed in this area.
 729
 730    [<a name="ref-LISP-SEC" id="ref-LISP-SEC">LISP-SEC</a>] defines a proposed mechanism for providing origin
 731    authentication, integrity, anti-replay protection, and prevention of
 732    man-in-the-middle and "overclaiming" attacks on the Map-Request/
 733    Map-Reply exchange.  Work is ongoing on this and other proposals for
 734    resolving these open security issues.
 735
 736    While beyond the scope of securing an individual Map-Server or
 737    Map-Resolver, it should be noted that a BGP-based LISP+ALT network
 738    (if ALT is used as the mapping database infrastructure) can take
 739    advantage of standards work on adding security to BGP.
 740
 741
 742
 743
 744
 745
 746
 747
 748
 749
 750
 751
 752
 753
 754
 755
 756 <span class="grey">Fuller &amp; Farinacci            Experimental                     [Page 11]</span>
 757 </pre><!--NewPage--><pre class="newpage"><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a>
 758 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 759
 760
 761 <span class="h2"><h2><a class="selflink" name="section-7" href="#section-7">7</a>.  References</h2></span>
 762
 763 <span class="h3"><h3><a class="selflink" name="section-7.1" href="#section-7.1">7.1</a>.  Normative References</h3></span>
 764
 765    [<a name="ref-RFC1035" id="ref-RFC1035">RFC1035</a>]    Mockapetris, P., "Domain names - implementation and
 766                 specification", STD 13, <a href="http://tools.ietf.org/html/rfc1035">RFC 1035</a>, November 1987.
 767
 768    [<a name="ref-RFC2104" id="ref-RFC2104">RFC2104</a>]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
 769                 Hashing for Message Authentication", <a href="http://tools.ietf.org/html/rfc2104">RFC 2104</a>,
 770                 February 1997.
 771
 772    [<a name="ref-RFC6234" id="ref-RFC6234">RFC6234</a>]    Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
 773                 (SHA and SHA-based HMAC and HKDF)", <a href="http://tools.ietf.org/html/rfc6234">RFC 6234</a>, May 2011.
 774
 775    [<a name="ref-RFC6830" id="ref-RFC6830">RFC6830</a>]    Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
 776                 Locator/ID Separation Protocol (LISP)", <a href="http://tools.ietf.org/html/rfc6830">RFC 6830</a>,
 777                 January 2013.
 778
 779    [<a name="ref-RFC6836" id="ref-RFC6836">RFC6836</a>]    Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
 780                 "Locator/ID Separation Protocol Alternative Logical
 781                 Topology (LISP+ALT)", <a href="http://tools.ietf.org/html/rfc6836">RFC 6836</a>, January 2013.
 782
 783 <span class="h3"><h3><a class="selflink" name="section-7.2" href="#section-7.2">7.2</a>.  Informative References</h3></span>
 784
 785    [<a name="ref-LISP-CONS" id="ref-LISP-CONS">LISP-CONS</a>]  Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis,
 786                 D., and D. Meyer, "LISP-CONS: A Content distribution
 787                 Overlay Network Service for LISP", Work in Progress,
 788                 April 2008.
 789
 790    [<a name="ref-LISP-MN" id="ref-LISP-MN">LISP-MN</a>]    Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
 791                 Mobile Node", Work in Progress, October 2012.
 792
 793    [<a name="ref-LISP-SEC" id="ref-LISP-SEC">LISP-SEC</a>]   Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O.
 794                 Bonaventure, "LISP-Security (LISP-SEC)", Work
 795                 in Progress, October 2012.
 796
 797    [<a name="ref-RFC4107" id="ref-RFC4107">RFC4107</a>]    Bellovin, S. and R. Housley, "Guidelines for
 798                 Cryptographic Key Management", <a href="http://tools.ietf.org/html/bcp107">BCP 107</a>, <a href="http://tools.ietf.org/html/rfc4107">RFC 4107</a>,
 799                 June 2005.
 800
 801    [<a name="ref-RFC6837" id="ref-RFC6837">RFC6837</a>]    Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
 802                 Routing Locator (RLOC) Database", <a href="http://tools.ietf.org/html/rfc6837">RFC 6837</a>,
 803                 January 2013.
 804
 805
 806
 807
 808
 809
 810
 811
 812 <span class="grey">Fuller &amp; Farinacci            Experimental                     [Page 12]</span>
 813 </pre><!--NewPage--><pre class="newpage"><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a>
 814 <span class="grey"><a href="http://tools.ietf.org/html/rfc6833">RFC 6833</a>                LISP Map-Server Interface           January 2013</span>
 815
 816
 817 <span class="h2"><h2><a class="selflink" name="appendix-A" href="#appendix-A">Appendix A</a>.  Acknowledgments</h2></span>
 818
 819    The authors would like to thank Gregg Schudel, Darrel Lewis, John
 820    Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver,
 821    Fabio Maino, and members of the lisp@ietf.org mailing list for their
 822    feedback and helpful suggestions.
 823
 824    Special thanks are due to Noel Chiappa for his extensive work on
 825    caching with LISP-CONS, some of which may be used by Map-Resolvers.
 826
 827 Authors' Addresses
 828
 829    Vince Fuller
 830
 831    EMail: vaf@vaf.net
 832
 833
 834    Dino Farinacci
 835    Cisco Systems
 836    Tasman Drive
 837    San Jose, CA  95134
 838    USA
 839
 840    EMail: farinacci@gmail.com
 841
 842
 843
 844
 845
 846
 847
 848
 849
 850
 851
 852
 853
 854
 855
 856
 857
 858
 859
 860
 861
 862
 863
 864
 865
 866
 867
 868 Fuller &amp; Farinacci            Experimental                     [Page 13]
 869
 870 </pre><br>
 871 <span class="noprint"><small><small>Html markup produced by rfcmarkup 1.104, available from
 872 <a href="http://tools.ietf.org/tools/rfcmarkup/">http://tools.ietf.org/tools/rfcmarkup/</a>
 873 </small></small></span>
 874
 875 </body></html>