idnits 2.17.1 draft-fuller-lisp-ddt-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 37 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 26 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. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1454: '... returned MUST be the original re...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 29, 2012) is 4220 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 1355, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1358, but no explicit reference was found in the text == Unused Reference: 'RFC4634' is defined on line 1362, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-00 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-23 ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-03 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Fuller 3 Internet-Draft D. Lewis 4 Intended status: Experimental V. Ermagan 5 Expires: April 2, 2013 A. Jain 6 cisco Systems 7 September 29, 2012 9 LISP Delegated Database Tree 10 draft-fuller-lisp-ddt-04.txt 12 Abstract 14 This draft describes the LISP Delegated Database Tree (LISP-DDT), a 15 hierarchical, distributed database which embodies the delegation of 16 authority to provide mappings from LISP Endpoint Identifiers (EIDs) 17 to Routing Locators (RLOCs). It is a statically-defined distribution 18 of the EID namespace among a set of LISP-speaking servers, called DDT 19 nodes. Each DDT node is configured as "authoritative" for one or 20 more EID-prefixes, along with the set of RLOCs for Map Servers or 21 "child" DDT nodes to which more-specific EID-prefixes are delegated. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 2, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 59 3. Database organization . . . . . . . . . . . . . . . . . . . . 8 60 3.1. EID-prefix tree structure and instance IDs . . . . . . . . 8 61 3.2. Configuring prefix delegation . . . . . . . . . . . . . . 8 62 3.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 8 63 4. The Map-Referral message . . . . . . . . . . . . . . . . . . . 10 64 4.1. Action codes . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2. Referral Set . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 11 67 5. DDT network elements and their operation . . . . . . . . . . . 12 68 5.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 5.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 12 70 5.1.2. Missing delegation from an authoritative prefix . . . 12 71 5.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . . 13 72 5.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . . 13 73 5.3.1. Queuing and sending DDT Map-Requests . . . . . . . . . 13 74 5.3.2. Receiving and following referrals . . . . . . . . . . 14 75 5.3.3. Handling referral errors . . . . . . . . . . . . . . . 15 76 5.3.4. Referral loop detection . . . . . . . . . . . . . . . 16 77 6. Psuedo Code and Decision Tree diagrams . . . . . . . . . . . . 17 78 6.1. Map Resolver processing of ITR Map-Request . . . . . . . . 17 79 6.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 17 80 6.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 18 81 6.2. Map Resolver processing of Map-Referral message . . . . . 19 82 6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 83 6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 21 84 6.3. DDT Node processing of DDT Map-Request message . . . . . . 22 85 6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 22 86 6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 23 87 7. Example topology and request/referral following . . . . . . . 24 88 7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 25 89 7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . . 26 90 7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 27 91 7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . . 27 92 7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 . . . . 28 93 8. Securing the database and message exchanges . . . . . . . . . 29 94 8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . . 29 95 8.2. DDT node operation . . . . . . . . . . . . . . . . . . . . 30 96 8.2.1. DDT public key revocation . . . . . . . . . . . . . . 30 97 8.3. Map Server operation . . . . . . . . . . . . . . . . . . . 30 98 8.4. Map Resolver operation . . . . . . . . . . . . . . . . . . 31 99 9. Open Issues and Considerations . . . . . . . . . . . . . . . . 32 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 103 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 104 12.2. Informative References . . . . . . . . . . . . . . . . . . 35 105 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36 106 Appendix B. Map-Referral Message Format . . . . . . . . . . . . . 37 107 B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 39 108 Appendix C. Encapsulated Control Message Format . . . . . . . . . 41 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 111 1. Introduction 113 [LISP] specifies an architecture and mechanism for replacing the 114 addresses currently used by IP with two separate name spaces: 115 relatively static Endpoint Identifiers (EIDs), used end-to-end for 116 terminating transport-layer associations, and Routing Locators 117 (RLOCs), which are more dynamic, are bound to topological location, 118 and are used for routing and forwarding through the Internet 119 infrastructure. 121 LISP offers a general-purpose mechanism for mapping between EIDs and 122 RLOCs. In organizing a database of EID to RLOC mappings, this 123 specification extends the definition of the EID numbering space by 124 logically prepending and appending several fields for purposes of 125 defining the database index key: Database-ID (DBID, 16 bits), 126 Instance dentifier (IID, 32-bits), Address Family Identifier (16 127 bits), and EID-prefix (variable, according to AFI value). The 128 resulting concatenation of these fields is termed an "Extended EID 129 prefix" or XEID-prefix. 131 The term "Extended EID" (XEID) is also used for an individual LISP 132 EID that is further qualified through the use of an Instance ID. See 133 [LCAF] for further discussion of the use of Instance IDs. 135 The DBID is provided for possible use in case a need evolves for 136 another, higher level in the hierarchy, to allow the creation of 137 multiple, separate database trees. 139 LISP-DDT is a hierarchical distributed database which embodies the 140 delegation of authority to provide mappings, i.e. its internal 141 structure mirrors the hierarchical delegation of address space. It 142 also provides delegation information to Map Resolvers, which use the 143 information to locate EID-to-RLOC mappings. A Map Resolver which 144 needs to locate a given mapping will follow a path through the tree- 145 structured database, contacting, one after another, the DDT nodes 146 along that path until it reaches the leaf DDT node(s) authoritative 147 for the mapping it is seeking. 149 LISP-DDT defines a new device type, the DDT node, that is configured 150 as authoritative for one or more XEID-prefixes. It also is 151 configured with the set of more-specific sub-prefixes that are 152 further delegated to other DDT nodes. To delegate a sub-prefix, the 153 "parent" DDT node is configured with the RLOCs of each child DDT node 154 that is authoritative for the sub-prefix. Each RLOC either points to 155 a Map Server (sometimes termed a "terminal DDT node") to which an 156 Egress Tunnel Routers (ETRs) has registered that sub-prefix or points 157 to another DDT node in the database tree that further delegates the 158 sub-prefix. See [LISP-MS] for a description of the functionality of 159 the Map Server and Map Resolver. Note that the target of a 160 delegation must always be an RLOC (not an EID) to avoid any circular 161 dependency. 163 To provide a mechanism for traversing the database tree, LISP-DDT 164 defines a new LISP message type, the Map-Referral, which is returned 165 to the sender of a Map-Request when the receiving DDT node can refer 166 the sender to another DDT node that has more detailed information. 167 See Section 4 for the definition of the Map-Referral message. 169 To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map 170 Resolver, starts by sending an Encapsulated Map-Request to a 171 preconfigured DDT node RLOC. The DDT node responds with a Map- 172 Referral message that either indicates that it will find the 173 requested mapping to complete processing of the request or that the 174 DDT client should contact another DDT node that has more-specific 175 information; in the latter case, the DDT node then sends a new 176 Encapsulated Map-Request to the next DDT node and the process repeats 177 in an iterative manner. 179 Conceptually, this is similar to the way that a client of the Domain 180 Name System (DNS) follows referrals (DNS responses that contain only 181 NS records) from a series of DNS servers until it finds an answer. 183 2. Definition of Terms 185 Extended EID (XEID): a LISP EID, optionally extended with a non- 186 zero Instance ID (IID) if the EID is intended for use in a context 187 where it may not be a unique value, such as on a Virtual Private 188 Network where [RFC1918] address space is used. See "Using 189 Virtualization and Segmentation with LISP" in [LISP] for more 190 discussion of Instance IDs. 192 XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided 193 to allow the definition of multiple databases; currently always 194 zero in this version of DDT, with other values reserved for future 195 use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used 196 as a key index into the database. 198 DDT node: a network infrastructure component responsible for 199 specific XEID-prefix and for delegation of more-specific sub- 200 prefixes to other DDT nodes. 202 DDT client: a network infrastructure component that sends Map- 203 Request messages and implements the iterative following of Map- 204 Referral results. Typically, a DDT client will be a Map Resolver 205 but it is also possible for an ITR to implement DDT client 206 functionality. 208 DDT Map Server: a DDT node that also implements Map Server 209 functionality (forwarding Map-Requests and/or returning Map- 210 Replies if offering proxy Map-Reply service) for a subset of its 211 delegated prefixes. 213 DDT Map Resolver: a network infrastructure element that accepts a 214 Map-Request, adds the XEID to its pending request list, then 215 queries one or more DDT nodes for the requested EID, following 216 returned referrals until it receives one with action code MS-ACK 217 (or an error indication). MS-ACK indicates that the Map-Request 218 has been sent to a Map Server that will forward it to an ETR that, 219 in turn, will provide a Map-Reply to the original sender. A DDT 220 Map Resolver maintains both a cache of Map-Referral message 221 results containing RLOCs for DDT nodes responsible for XEID- 222 prefixes of interest (termed the "referral cache") a pending 223 request list of XEIDs that are being resolved through iterative 224 querying of DDT nodes. 226 Encapsulated Map-Request: a LISP Map-Request carried within an 227 Encapsulated Control Message, which has an additional LISP header 228 prepended. Sent to UDP destination port 4342. The "outer" 229 addresses are globally-routable IP addresses, also known as RLOCs. 230 Used by an ITR when sending to a Map Resolver and by a Map Server 231 when forwarding a Map-Request to an ETR as documented in 232 [LISP-MS]. 234 DDT Map-Request: an Encapsulated Map-Request sent by a DDT client 235 to a DDT node. The "DDT-originated" flag is set in the 236 encapsulation header indicating that the DDT node should return 237 Map-Referral messages if the Map-Request EID matches a delegated 238 XEID-prefix known to the DDT node. Section 5.3.1 describes how 239 DDT Map-Requests are sent. 241 Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node 242 and for which the DDT node may provide further delegations of 243 more-specific sub-prefixes. 245 Map-Referral: a LISP message sent by a DDT node in response to a 246 DDT Map-Request for an XEID that matches a configured XEID-prefix 247 delegation. A non-negative Map-Referral includes a "referral", a 248 set of RLOCs for DDT nodes that have more information about the 249 sub-prefix; a DDT client "follows the referral" by sending another 250 DDT Map-Request to one of those RLOCs to obtain either an answer 251 or another referral to DDT nodes responsible for a more-specific 252 XEID-prefix. See Section 5.1 and Section 5.3.2 for details on the 253 sending and processing of Map-Referral messages. 255 negative Map-Referral: a Map-Referral sent in response to a DDT 256 Map-Request that matches an authoritative XEID-prefix but for 257 which there is no delegation configured (or no ETR registration if 258 sent by a DDT Map-Server). 260 Pending Request List: the set of outstanding requests for which a 261 DDT Map Resolver has received encapsulated Map-Requests from a DDT 262 client for an XEID. Each entry in the list contains additional 263 state needed by the referral following process, including the 264 requestor(s) of the XEID (typically, one or more ITRs), saved 265 information about the last referral received and followed 266 (matching XEID-prefix, action code, RLOC set, index of last RLOC 267 queried in the RLOC set), and any [LISP-SEC] information that was 268 included in the DDT client Map-Request. An entry in the list may 269 be interchangeably termed a "pending request list entry" or simply 270 a "pending request". 272 For definitions of other terms, notably Map-Request, Map-Reply, 273 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server, 274 and Map Resolver, please consult the LISP specification [LISP] and 275 the LISP Mapping Service specification [LISP-MS]. 277 3. Database organization 279 3.1. EID-prefix tree structure and instance IDs 281 LISP-DDT defines a tree structure that is indexed by a binary 282 encoding of five fields, in order of significance: DBID (16 bits), 283 Instance Identifier (IID, 32 bits), Address Family Identifier (AFI, 284 16 bits), and EID-prefix (variable, according to AFI value). The 285 fields are concatenated, with the most significant fields as listed 286 above. The index into this structure is also referred to as an 287 Extended EID-prefix (XEID-prefix). 289 It is important to note that LISP-DDT does not store actual EID-to- 290 RLOC mappings; it is, rather, a distributed index that can be used to 291 find the devices (Map Servers and their registered EIDs) that can be 292 queried with LISP to obtain those mappings. Changes to EID-to-RLOC 293 mappings are made on the ETRs which define them, not to any DDT node 294 configuration. DDT node configuration changes are only required when 295 branches of the database hierarchy are added, removed, or modified. 297 3.2. Configuring prefix delegation 299 Every DDT node is configured with one or more XEID-prefixes for which 300 it is authoritative along with a list of delegations of XEID-prefixes 301 to other DDT nodes. A DDT node is required to maintain a list of 302 delegations for all sub-prefixes of its authoritative XEID-prefixes; 303 it also may list "hints", which are prefixes that it knows about that 304 belong to its parents, to the root, or to any other point in the 305 XEID-prefix hierarchy. A delegation (or hint) consists of an XEID- 306 prefix, a set of RLOCs for DDT nodes that have more detailed 307 knowledge of the XEID-prefix, and accompanying security information. 308 Those RLOCs are returned in Map-Referral messages when the DDT node 309 receives a DDT Map-Request with an xEID that matches a delegation. A 310 DDT Map Server will also have a set of sub-prefixes for which it 311 accepts ETR mapping registrations and for which it will forward (or 312 answer, if it provides proxy Map-Reply service) Map-Requests. For 313 details of security infomation in Map-Referrals see Section 8. 315 3.2.1. The root DDT node 317 The root DDT node is the logical "top" of the database hierarchy: 318 DBID=0, IID=0, AFI=0, EID-prefix=0/0. A DDT Map-Request that matches 319 no configured XEID-prefix will be referred to the root node. The 320 root node in a particular instantiation of LISP-DDT must therefore be 321 configured with delegations for at least all defined IIDs and AFIs. 323 To aid in defining a "sub-root" DDT node that is responsible for all 324 EID-prefixes within multiple IIDs (say, for using LISP to create 325 virtual networks that use overlapping address space), it may be 326 useful to implement configuration language that allows for a range of 327 IIDs to be delegated together. Additional configuration shorthand 328 for delegating a range of IIDs (and all of the EIDs under them) may 329 also be helpful. 331 4. The Map-Referral message 333 A Map-Referral message is sent by a DDT node to a DDT client in 334 response to a DDT Map-Request message. The message consists of an 335 action code along with delegation information about the XEID-prefix 336 that matches the XEID requested. 338 See Appendix B for a detailed layout of the Map-Referral message 339 fields. 341 4.1. Action codes 343 The action codes are as follows: 345 NODE-REFERRAL (0): indicates that the replying DDT node has 346 delegated an XEID-prefix that matches the requested XEID to one or 347 more other DDT nodes. The Map-Referral message contains a "map- 348 record" with additional information, most significantly the set of 349 RLOCs to which the prefix has been delegated, that is used by a 350 DDT Map Resolver to "follow" the referral. 352 MS-REFERRAL (1): indicates that the replying DDT node has delegated 353 an XEID-prefix that matches the requested XEID to one or more DDT 354 Map Servers. It contains the same additional information as a 355 NODE-REFERRAL but is handled slightly differently by the receiving 356 DDT client (see Section 5.3.2). 358 MS-ACK (2): indicates that a replying DDT Map Server received a DDT 359 Map-Request that matches an authoritative XEID-prefix for which is 360 has one or more registered ETRs. This means that the request can 361 be forwarded to one of those ETRs to provide an answer to the 362 querying ITR. 364 MS-NOT-REGISTERED (3): indicates that the replying DDT Map Server 365 received a Map-Request for one of its configured XEID-prefixes 366 which has no ETRs registered. 368 DELEGATION-HOLE (4): indicates that the requested XEID matches a 369 non-delegated sub-prefix of the XEID space. This is a non-LISP 370 "hole", which has not been delegated to any DDT Map Server or ETR. 371 See Section 5.1.2 for details. 373 NOT-AUTHORITATIVE (5): indicates that the replying DDT node received 374 a Map-Request for an XEID-request for which it is not 375 authoritative. This can occur if a cached referral has become 376 invalid due to a change in the database hierarchy. 378 4.2. Referral Set 380 For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a 381 DDT node includes in the Map-Referral message a list of RLOCs for all 382 DDT nodes that are authoritative for the XEID-prefix being returned; 383 a DDT Map Resolver uses this information to contact one of those DDT 384 nodes as it "follows" a referral. 386 4.3. Incomplete flag 388 A DDT node sets the "Incomplete" flag in a Map-Referral message if 389 the Referral Set is incomplete; this is intended to prevent a DDT Map 390 Resolver from caching a referral with incomplete information. A DDT 391 node must set the "incomplete" flag in the following cases: 393 o If it is setting action code MS-ACK or MS-NOT-REGISTERED but does 394 not have configuration for other "peer" DDT nodes that are also 395 authoritative for the matched XEID-prefix. 397 o If it is setting action code NOT-AUTHORITATIVE. 399 5. DDT network elements and their operation 401 As described above, DDT introduces a new network element, the "DDT 402 node", extends the functionality of Map Servers and Map Resolvers to 403 send and receive Map-Referral messages. The operation of each of 404 these devices is described as follows. 406 5.1. DDT node 408 When a DDT node receives a DDT Map-Request, it compares the requested 409 XEID against its list of XEID-prefix delegations and its list of 410 authoritative XEID-prefixes and acts as follows: 412 5.1.1. Match of a delegated prefix (or sub-prefix) 414 If the requested XEID matches one of the DDT node's delegated 415 prefixes, then a Map-Referral message is returned with the matching 416 more-specific XEID-prefix and the set of RLOCs for the referral 417 target DDT nodes including associated security information (see 418 Section 8 for details on security). If the delegation is known to be 419 a DDT Map Server, then the Map-Referral message is sent with action 420 code MS-REFERRAL to indicate to the receiver that LISP-SEC 421 information (if saved in the pending request) should be included in 422 the next DDT Map-Request; otherwise, the action code NODE-REFERRAL is 423 used. 425 Note that a matched delegation does not have to be for a sub-prefix 426 of an authoritative prefix; in addition to being configured to 427 delegate sub-prefixes of an authoritative prefix, a DDT node may also 428 be configured with other XEID-prefixes for which it can provide 429 referrals to DDT nodes anywhere in the database hierarchy. This 430 capability to define "shortcut hints" is never required to be 431 configured but may be a useful heuristic for reducing the number of 432 iterations needed to find an EID, particular for private network 433 deployments. 435 5.1.2. Missing delegation from an authoritative prefix 437 If the requested XEID did not match a configured delegation but does 438 match an authoritative XEID-prefix, then the DDT node returns a 439 negative Map-Referral that uses the least-specific XEID-prefix that 440 does not match any XEID-prefix delegated by the DDT node. The action 441 code is set to DELEGATION-HOLE; this indicates that the XEID is not a 442 LISP destination. 444 If the requested XEID did not match either a configured delegation or 445 an authoritative XEID-prefix, then the request is dropped and a 446 negative Map-Referral with action code NOT-AUTHORITATIVE is returned. 448 5.2. DDT Map Server 450 When a DDT Map Server receives a DDT Map-Request, its operation is 451 similar to that of a DDT node with additional processing as follows: 453 o If the requested XEID matches a registered XEID-prefix, then the 454 Map-Request is forwarded to one of the destination ETR RLOCs (or 455 the Map Server sends a Map-Reply, if it is providing proxy Map- 456 Reply service) and a Map-Referral with the MS-ACK action is 457 returned to the sender of the DDT Map-Request. 459 o If the requested XEID matches a configured XEID-prefix for which 460 no ETR registration has been received then a negative Map-Referral 461 with action code MS-NOT-REGISTERED is returned to the sender of 462 the DDT Map-Request. 464 5.3. DDT Map Resolver 466 Just as any other Map Resolver, a DDT Map Resolver accepts Map- 467 Requests from its clients (typically, ITRs) and ensures that those 468 Map-Requests are forwarded to the correct ETR, which generates Map- 469 Replies. Unlike a Map Resolver that uses the ALT mapping system 470 [LISP-ALT], however, a DDT Map Resolver uses an iterative process of 471 following referrals to find the correct ETR to answer a Map-Request; 472 this requires a DDT Map Resolver to maintain additional state: a Map- 473 Referral cache and pending request list of XEIDs that are going 474 through the iterative referral process. 476 5.3.1. Queuing and sending DDT Map-Requests 478 When a DDT Map Resolver receives an encapsulated Map-Request, it 479 first performs a longest-match search for the XEID in its referral 480 cache. If no match is found or if a negative cache entry is found, 481 then the destination is not in the database; a negative Map-Reply is 482 returned and no further processing is performed by the DDT Map 483 Resolver. 485 If a match is found, the DDT Map Resolver creates a pending request 486 list entry for the XEID and saves the original Map-Request (minus the 487 encapsulation header) along with other information needed to track 488 progress through the iterative referral process; the "referral XEID- 489 prefix" is also initialized to the null value since no referral has 490 yet been received. The Map Resolver then creates a DDT Map-Request 491 (which is an encapsulated Map-Request with the "DDT-originated" flag 492 set in the message header) for the XEID but without any 493 authentication data that may have been included in the original Map- 494 Request. It sends the DDT Map-Request to one of the RLOCs in the 495 chosen referral cache entry. The referral cache is initially 496 populated with one or more statically-configured entries; additional 497 entries are added when referrals are followed, as described below. A 498 DDT Map Resolver is not absolutely required to cache referrals but it 499 doing so decreases latency and reduces lookup delays. 501 Note that in normal use on the public Internet, the statically- 502 configured initial referral cache for a DDT Map Resolver should 503 include a "default" entry with RLOCs for one or more DDT nodes that 504 can reach the DDT root node. If a Map Resolver does not have such 505 configuration, it will return a Negative Map-Reply if it receives a 506 query for an EID outside the subset of the mapping database known to 507 it. While this may be desirable on private network deployments or 508 during early transition to LISP when few sites are using it, this 509 behavior is not appropriate when LISP is in general use on the 510 Internet. 512 5.3.2. Receiving and following referrals 514 After sending a DDT Map-Request, a DDT Map Resolver expects to 515 receive a Map-Referral response. If none occurs within the timeout 516 period, the DDT Map Resolver retransmits the request, sending to the 517 next RLOC in the referral cache entry if one is available. If the 518 maximum number of retransmissions has occurred and all RLOCs have 519 been tried, then the pending request list entry is dequeued. 521 A DDT Map Resolver processes a received Map-Referral message 522 according to each action code: 524 NODE-REFERRAL: The DDT Map Resolver checks for a possible referral 525 loop as as described in Section 5.3.4. If no loop is found, the 526 DDT Map Resolver saves the prefix returned in the Map-Referral 527 message in the referral cache, updates the saved prefix and saved 528 RLOCs in the pending request list entry, and follows the referral 529 by sending a new DDT Map-Request to one of the DDT node RLOCs 530 listed in the Referral Set; security information saved with the 531 original Map-Request is not included. 533 MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same 534 manner as a NODE-REFERRAL except that that security information 535 saved with the original Map-Request is included in the new Map- 536 Request sent to a Map Server (see Section 8 for details on 537 security). 539 MS-ACK: This is returned by a DDT Map Server to indicate that it has 540 one or more registered ETRs that can answer a Map-Request for the 541 XEID. If the pending request did not include saved LISP-SEC 542 information or if that information was already included in the 543 previous DDT Map-Request (sent by the DDT Map Resolver in response 544 to either an MS-REFERRAL or a previous MS-ACK referral), then the 545 pending request for the XEID is complete and is dequeued. 546 Otherwise, LISP-SEC information is required and has not yet been 547 sent to the authoritative DDT Map-Server; the DDT Map Resolver re- 548 sends the DDT Map-Request with LISP-SEC information included and 549 the pending request queue entry remains until another Map-Referral 550 with MS-ACK action code is received. If the "incomplete" flag is 551 not set, the prefix is saved in the referral cache. 553 MS-NOT-REGISTERED: The DDT Map Server qurieed could not process the 554 request because it did not have any ETRs registered for a 555 matching, authoritative XEID-prefix. If the DDT Map Resolver has 556 not yet tried all of the RLOCs saved with the pending request, 557 then it sends a Map-Request to the next RLOC in that list. If all 558 RLOCs have been tried, then the destination XEID is not registered 559 and is unreachable. The DDT Map Resolver returns a negative Map- 560 Reply to the original Map-Request sender; this Map-Reply contains 561 the non-registered XEID-prefix with TTL value of one minute. A 562 negative referral cache entry is created for the prefix (also with 563 TTL of one minute) and the pending request is dequeued. 565 DELEGATION-HOLE: The DDT Map Server queried did not have an XEID- 566 prefix defined that matched the requested XEID so it does not 567 exist in the mapping database. The DDT Map Resolver returns a 568 negative Map-Reply to the original Map-Request sender; this Map- 569 Reply will indicate the least-specific XEID-prefix matching the 570 requested XEID for which no delegations exist and will have a TTL 571 value of 15 minutes. A negative referral cache entry is created 572 for the prefix (also with TTL of 15 minutes) and the pending 573 request is dequeued. 575 NOT-AUTHORITATIVE: The DDT Map Server queried is not authoritative 576 for the requested XEID. This can occur if a cached referral has 577 become invalid due to a change in the database hierarchy. If the 578 DDT Map Resolver receiving this message can determine that it is 579 using old cached information, it may choose to delete that cached 580 information and re-try the original Map-Request, starting from its 581 "root" cache entry. If this action code is received in response 582 to a query that was not to cached referral information, then it 583 indicates a database synchronization problem or configuration 584 error. The pending request list entry that caused this answer is 585 removed, with no answer returned to the original requestor. 587 5.3.3. Handling referral errors 589 Other states are possible, such as a misconfigured DDT node (acting 590 as a proxy Map Server, for example) returning a Map-Reply to the DDT 591 Map Resolver; they should be considered errors and logged as such. 593 It is not clear exactly what else the DDT Map Resolver should do in 594 such cases; one possibility is to remove the pending request list 595 entry and send a negative Map-Reply to the original Map-Request 596 sender. Alternatively, if a DDT Map Resolver detects unexpected 597 behavior by a DDT node, it could mark that node as unusable in its 598 referral cache and update the pending request to try a different DDT 599 node if more than one is listed in the referral cache. In any case, 600 any prefix contained in a Map-Referral message that causes a referral 601 error (including a referral loop) is not saved in the DDT Map- 602 Resolver referral cache. 604 5.3.4. Referral loop detection 606 In response to a Map-Referral message with action code NODE-REFERRAL 607 or MS-REFERRAL, a DDT Map Resolver is directed to query a new set of 608 DDT node RLOCs that are expected to have more-specific XEID-prefix 609 information for the requested XEID. To prevent a possible "iteration 610 loop" (following referrals back-and-forth among a set of DDT nodes 611 without ever finding an answer), a DDT Map Resolver saves the last 612 received referral XEID-prefix for each pending request and checks 613 that a newly received NODE-REFERRAL or MS-REFERRAL message contains a 614 more-specific referral XEID-prefix; an exact or less-specific match 615 of the saved XEID-prefix indicates a referral loop. If a loop is 616 detected, the DDT Map Resolver handles the request as described in 617 Section 5.3.3. Otherwise, the Map Resolver saves the most recently 618 received referral XEID-prefix with the pending request when it 619 follows the referral. 621 As an extra measure to prevent referral loops, it is probably also 622 wise to limit the total number of referrals for any request to some 623 reasonable number; the exact value of that number will be determined 624 during experimental deployment of LISP-DDT but is bounded by the 625 maximum length of the XEID. 627 Note that when a DDT Map Resolver adds an entry to its lookup queue 628 and sends an initial Map-Request for an XEID, the queue entry has no 629 previous referral XEID-prefix; this means that the first DDT node 630 contacted by a DDT Map Resolver may provide a referral to anywhere in 631 the DDT hierarchy. This, in turn, allows a DDT Map Resolver to use 632 essentially any DDT node RLOCs for its initial cache entries and 633 depend on the initial referral to provide a good starting point for 634 Map-Requests; there is no need to configure the same set of root DDT 635 nodes on all DDT Map Resolvers. 637 6. Psuedo Code and Decision Tree diagrams 639 To aid in implementation, each of the major DDT Map Server and DDT 640 Map Resolver functions are described below, first using simple 641 "psuedo-code" and then in the form of a decision tree. 643 6.1. Map Resolver processing of ITR Map-Request 645 6.1.1. Pseudo-code summary 647 if ( request pending i.e., (ITR,EID) of request same ) { 648 replace old request with new & use new request nonce 649 for future requests 650 } else if ( no match in refcache ) { 651 return negative map-reply to ITR 652 } else if ( match type delegation hole ) { 653 return negative map-reply to ITR 654 } else if ( match type ms-ack ) { 655 fwd DDT request to map-server 656 } else { 657 store & fwd DDT request w/o OTK to node delegation 658 } 660 6.1.2. Decision tree diagram 662 +------------+ 663 | Is Request | Yes 664 | |----> Replace old request with 665 | Pending? | new nonce for future requests 666 +------------+ 667 | 668 |No 669 | 670 V 671 +------------+ 672 | Match In | No 673 | Referral |----> Send Negative Map Reply 674 | cache? | (not a likely event as root 675 +------------+ configured on every MR) 676 | 677 |Yes 678 | 679 V 680 +------------+ 681 | Match Type | Yes 682 | Delegation |----> Send Negative Map Reply 683 | Hole ? | 684 +------------+ 685 | 686 |No 687 | 688 V 689 +------------+ 690 | Match Type | Yes 691 | MS-ACK? |----> Forward DDT Map-request to Map-Server 692 | | 693 +------------+ 694 | 695 |No 696 | 697 V 698 Store request & Fwd DDT Request w/o OTK 699 to DDT node delegation 701 6.2. Map Resolver processing of Map-Referral message 703 6.2.1. Pseudo-code summary 705 if ( no request pending matched by referral nonce ) { 706 silently drop 707 } 709 if ( pfx in referral less specific than last referral used ) { 710 if ( gone through root ) { 711 silently drop 712 } else { 713 goto root 714 } 715 } 717 switch (map_referral_type) { 719 case NOT_AUTHORITATIVE : 720 if ( gone through root ) { 721 return negative map-reply to ITR 722 } else { 723 goto root 724 } 726 case DELEGATION_HOLE: 727 cache & send negative map-reply to ITR 729 case MS_REFERRAL: 730 if ( referral equal to last used ) { 731 if ( gone through root ) { 732 return negative map-reply to ITR 733 } else { 734 goto root 735 } 736 } else { 737 cache & follow the referral 738 } 740 case NODE_REFERRAL: 741 if ( referral equal to last used ) { 742 if ( gone through root ) { 743 return negative map-reply to ITR 744 } else { 745 goto root 746 } 747 } else { 748 cache & follow the referral 750 } 752 case MS_ACKNOWLEDGEMENT: 753 if ( OTK stripped ) { 754 if ( incomplete ) { 755 resend request with OTK 756 } else { 757 cache & resend request with OTK 758 } 759 } 761 case MS_NOT_REGISTERED: 762 if { all map-server delegations not tried } { 763 follow delegations not tried 764 if ( !incomplete ) { 765 cache 766 } 767 } else { 768 send negative map-reply to ITR 769 if { !incomplete } { 770 cache 771 } 772 } 774 case DEFAULT: 775 drop 777 } 778 } 780 6.2.2. Decision tree diagram 782 +------------+ 783 | Is Request | No 784 | Pending? |----> Silently drop 785 +------------+ 786 | Yes 787 V 788 +------------------------------+ Yes 789 | Pfx less specific than last? |----> Silently drop 790 +------------------------------+ 791 |No 792 V 793 +---------------------------------------------------+ 794 | What is Map-Referral Type? |--UNKNOWN-+ 795 +---------------------------------------------------+ | 796 | | | | | | V 797 | | | | | DEL_HOLE DROP 798 | | | | MS_ACK | 799 | | | | | V 800 | | MS_REF NODE_REF | Cache & return 801 | | | | V negative map-reply 802 | | | | +---------+ 803 | NOT_AUTH | | | Was OTK | Yes 804 | | | | |Stripped?|----> Done 805 | | V V +---------+ 806 | | +------------+ | No 807 | | Yes | Pfx equal | V 808 MS_NOT_REGISTERED | +---| to last | +------------+ 809 | | | | used? | | Incomplete | Yes 810 | | | +------------+ | bit set? |---> Resend DDT 811 | V V |No +------------+ request 812 | +------------+ | |No with OTK 813 | | Gone | V | 814 | | Through | Cache & follow V 815 | | Root? | the referral Cache & resend DDT 816 | +------------+ request with OTK 817 | |No |Yes 818 | | | 819 | V V 820 | Goto root Send negative map-reply 821 V 822 +-----------+ Yes +-----------+ Yes 823 | Other MS |-----Follow other MS-------->|Incomplete |----> Dont cache 824 | not tried?| |bit set? | 825 | |----Send negative map-reply->| |----> Cache 826 +-----------+ No +-----------+ No 828 6.3. DDT Node processing of DDT Map-Request message 830 6.3.1. Pseudo-code summary 832 if ( I am not authoritative ) { 833 send map-referral NOT_AUTHORITATIVE with 834 incomplete bit set and ttl 0 835 } else if ( delegation exists ) { 836 if ( delegated map-servers ) { 837 send map-referral MS_REFERRAL with 838 ttl 'Default_DdtNode_Ttl' 839 } else { 840 send map-referral NODE_REFERRAL with 841 ttl 'Default_DdtNode_Ttl' 842 } 843 } else { 844 if ( eid in site) { 845 if ( site registered ) { 846 forward map-request to etr 847 if ( map-server peers configured ) { 848 send map-referral MS_ACKNOWLEDGEMENT with 849 ttl 'Default_Registered_Ttl' 850 } else { 851 send map-referral MS_ACKNOWLEDGEMENT with 852 ttl 'Default_Registered_Ttl' and incomplete bit set 853 } 854 } else { 855 if ( map-server peers configured ) { 856 send map-referral MS_NOT_REGISTERED with 857 ttl 'Default_Configured_Not_Registered_Ttl' 858 } else { 859 send map-referral MS_NOT_REGISTERED with 860 ttl 'Default_Configured_Not_Registered_Ttl' 861 and incomplete bit set 862 } 863 } 864 } else { 865 send map-referral DELEGATION_HOLE with 866 ttl 'Default_Negative_Referral_Ttl' 867 } 868 } 870 6.3.2. Decision tree diagram 872 +------------+ 873 | Am I | No 874 | Authori- |----> Return NOT_AUTHORITATIVE 875 | tative? | Incomplete = 1 876 +------------+ ttl = Default_DdtNode_Ttl 877 | 878 |Yes 879 | 880 V 881 +------------+ +------------+ 882 | Delegation | Yes | Delegations| Yes 883 | Exists? |---->| are map |----> Return MS_REFERRAL 884 | | | servers? | ttl = Default_DdtNode_Ttl 885 +------------+ +------------+ 886 | \ No 887 |No +--> Return NODE_REFERRAL 888 | ttl = Default_DdtNode_Ttl 889 V 890 +------------+ +------------+ +------------+ 891 | EID in | Yes | Site | Yes | Map-server | 892 | Site |---->| Registered?|----> Forward---->| peers | 893 | Config? | | | Map-request | configured?| 894 +------------+ +------------+ to ETR +------------+ 895 | | | | 896 | |No No| |Yes 897 | | | | 898 | | V V 899 | | Return MS_ACK Return MS_ACK 900 | V with INC=1 901 | +------------+ ttl=Default_Registered_Ttl 902 | | Map-server | Yes 903 | | peers |----> Return MS_NOT_REGISTERED 904 | | configured?| ttl = Default_Negative_Referral_Ttl 905 | +------------+ 906 | \ No 907 |No +--> Return MS_NOT_REGISTERED 908 | Incomplete = 1 909 V ttl = Default_Negative_Referral_Ttl 910 Return DELEGATION_HOLE 911 ttl = Default_Negative_Referral_Ttl 913 7. Example topology and request/referral following 915 To show how referrals are followed to find the RLOCs for a number of 916 EIDs, consider the following example EID topology for DBID=0, IID=0, 917 AFI=1, and EID=0/0 919 +---------------------+ +---------------------+ 920 | root1: 192.0.2.1 | | root2: 192.0.2.2 | 921 | authoritative: 0/0 | | authoritative: 0/0 | 922 +---------------------+ +---------------------+ 923 | \ / | 924 | \ / | 925 | / \ | 926 | / \ | 927 | | | | 928 V V V V 929 +--------------------------+ +--------------------------+ 930 | DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 | 931 | authoritative: 10.0.0.0/8| | authoritative: 10.0.0.0/8| 932 +--------------------------+ +--------------------------+ 933 | \ / | 934 | \ / | 935 | / \ | 936 | / \ | 937 | | | | 938 V V V V 939 +--------------------------+ +---------------------------+ 940 | Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 | 941 |authoritative: 10.0.0.0/12| |authoritative: 10.16.0.0/12| 942 | site1: 10.1.0.0/16 | +---------------------------+ 943 | site2: 10.2.0.0/16 | | | 944 +--------------------------+ | | 945 | | 946 | | 947 V V 948 +---------------------------+ +---------------------------+ 949 | Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 | 950 |authoritative: 10.16.0.0/16| |authoritative: 10.17.0.0/16| 951 | site3: 10.16.1.0/24 | | site5: 10.17.8.0/24 | 952 | site4: 10.16.2.0/24 | | site6: 10.17.9.0/24 | 953 +---------------------------+ +---------------------------+ 955 DDT nodes are configured for this "root" at IP addresses 192.0.2.1 956 and 192.0.2.2. DDT Map Resolvers are configured with default 957 referral cache entries to these addresses. 959 The root DDT nodes delegate 10.0.0/8 to two DDT nodes with IP 960 addresses 192.0.2.11 and 192.0.2.12. 962 The DDT nodes for 10.0.0.0/8 delegate 10.0.0.0/12 to a DDT Map Server 963 with RLOC 192.0.2.101 965 The DDT Map Server for 10.0.0.0/12 is configured to allow ETRs to 966 register the sub-prefixes 10.1.0.0/16 and 10.2.0.0/16 968 The DDT nodes for 10.0.0.0/8 also delegate 10.16.0.0/12 to a DDT node 969 with RLOC 192.0.2.201 971 The DDT node for 10.16.0.0/12 is further configured to delegate 972 10.16.0.0/16 to a DDT Map Server with RLOC 192.0.2.211 and 973 10.17.0.0/16 to a DDT Map Server with RLOC 192.0.2.221 975 The DDT Map Server for 10.16.0.0/16 is configured to allow ETRs to 976 register the sub-prefixes 10.16.1.0/24 and 10.16.2.0/24 978 The DDT Map Server for 10.17.0.0/16 is configured to allow ETRs to 979 register the sub-prefixes 10.17.8.0/24 and 10.17.9.0/24 981 7.1. Lookup of 10.1.1.1/32 by ITR1 983 The first example shows a DDT Map Resolver following a delegation 984 from the root to a DDT node followed by another delegation to a DDT 985 Map Server. 987 ITR1 sends an Encapsulated Map-Request for 10.1.1.1 to one of its 988 configured (DDT) Map Resolvers. The DDT Map Resolver proceeds as 989 follows: 991 1. Send DDT Map-Request (for 10.1.1.1) to one of the root DDT nodes, 992 192.0.2.1 or 192.0.2.2 994 2. Receive (and save in referral cache) Map-Referral for EID-prefix 995 10.0.0.0/8, action code NODE-REFERRAL, RLOC set (192.0.2.11, 996 192.0.2.12) 998 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 1000 4. Receive (and save in referral cache) Map-Referral for EID-prefix 1001 10.0.0.0/12, action code MS-REFERRAL, RLOC set (192.0.2.101) 1003 5. Send DDT Map-Request to 192.0.2.101; if the ITR-originated 1004 Encapsulated Map-Request had a LISP-SEC signature, it is included 1006 6. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 1007 and forwards to a registered site1 ETR for 10.1.0.0/16 1009 7. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 1010 EID-prefix 10.1.0.0/16, action code MS-ACK to the DDT Map 1011 Resolver 1013 8. DDT Map Resolver receives Map-Referral message and dequeues the 1014 pending request for 10.1.1.1 1016 9. site1 ETR for 10.1.0.0/16 receives Map-Request forwarded by DDT 1017 Map Server and sends Map-Reply to ITR1 1019 7.2. Lookup of 10.17.8.1/32 by ITR2 1021 The next example shows a three-level delegation: root to first DDT 1022 node, first DDT node to second DDT node, second DDT node to DDT Map 1023 Server. 1025 ITR2 sends an Encapsulated Map-Request for 10.17.8.1 to one of its 1026 configured (DDT) Map Resolvers, which are different from those for 1027 ITR1. The DDT Map Resolver proceeds as follows: 1029 1. Send DDT Map-Request (for 10.17.8.1) to one of the root DDT 1030 nodes, 192.0.2.1 or 192.0.2.2 1032 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1033 10.0.0.0/8, action code NODE-REFERRAL, RLOC set (192.0.2.11, 1034 192.0.2.12) 1036 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 1038 4. Receive (and save in referral cache) Map-Referral for EID-prefix 1039 10.16.0.0/12, action code NODE-REFERRAL, RLOC set (192.0.2.201) 1041 5. Send DDT Map-Request to 192.0.2.201 1043 6. Receive (and save in referral cache) Map-Referral for EID-prefix 1044 10.17.0.0/16, action code MS-REFERRAL, RLOC set (192.0.2.221) 1046 7. Send DDT Map-Request to 192.0.2.221; if the ITR-originated 1047 Encapsulated Map-Request had a LISP-SEC signature, it is 1048 included 1050 8. DDT Map Server at 192.0.2.221 decapsulates the DDT Map-Request 1051 and forwards to a registered site5 ETR for 10.17.8.0/24 1053 9. DDT Map Server at 192.0.2.221 sends a Map-Referral message for 1054 EID-prefix 10.17.8.0/24, action code MS-ACK, to the DDT Map 1055 Resolver 1057 10. DDT Map Resolver receives Map-Referral(MS-ACK) message and 1058 dequeues the pending request for 10.17.8.1 1060 11. site5 ETR for 10.17.8.0/24 receives Map-Request forwarded by DDT 1061 Map Server and sends Map-Reply to ITR2 1063 7.3. Lookup of 10.2.2.2/32 by ITR1 1065 This example shows how a DDT Map Resolver uses a saved referral cache 1066 entry to skip the referral process and go directly to a DDT Map 1067 Server for a prefix that is similar to one previously requested. 1069 In this case, ITR1 uses the same Map Resolver used in example 1070 Section 7.1. It sends an Encapsulated Map-Request for 10.2.2.2 to 1071 that (DDT) Map Resolver. The DDT Map-Resolver finds an MS-REFERRAL 1072 cache entry for 10.0.0.0/12 with RLOC set (192.0.2.101) and proceeds 1073 as follows: 1075 1. Send DDT Map-Request (for 10.2.2.2) to 192.0.2.101; if the ITR- 1076 originated Encapsulated Map-Request had a LISP-SEC signature, it 1077 is included 1079 2. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 1080 and forwards to a registered site2 ETR for 10.2.0.0/16 1082 3. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 1083 EID-prefix 10.2.0.0/16, action code MS-ACK to the DDT Map 1084 Resolver 1086 4. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 1087 pending request for 10.2.2.2 1089 5. site2 ETR for 10.2.0.0/16 receives Map-Request and sends Map- 1090 Reply to ITR1 1092 7.4. Lookup of 10.16.2.1/32 by ITR2 1094 This example shows how a DDT Map Resolver uses a saved referral cache 1095 entry to start the referral process at a non-root, intermediate DDT 1096 node for a prefix that is similar to one previously requested. 1098 In this case, ITR2 asks the same Map Resolver used in example 1099 Section 7.2. It sends an Encapsulated Map-Request for 10.16.2.1 to 1100 that (DDT) Map Resolver, which finds a NODE-REFERRAL cache entry for 1101 10.16.0.0/12 with RLOC set (192.0.2.201). It proceeds as follows: 1103 1. Send DDT Map-Request (for 10.16.2.1) to 192.0.2.201 1105 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1106 10.16.0.0/16, action code MS-REFERRAL, RLOC set (192.0.2.211) 1108 3. Send DDT Map-Request to 192.0.2.211; if the ITR-originated 1109 Encapsulated Map-Request had a LISP-SEC signature, it is included 1111 4. DDT Map Server at 192.0.2.211 decapsulates the DDT Map-Request 1112 and forwards to a registered site4 ETR for 10.16.2.0/24 1114 5. DDT Map Server at 192.0.2.211 sends a Map-Referral message for 1115 EID-prefix 10.16.2.0/24, action code MS-ACK to the DDT Map 1116 Resolver 1118 6. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 1119 pending request for 10.16.2.1 1121 7. site4 ETR for 10.16.2.0/24 receives Map-Request and sends Map- 1122 Reply to ITR2 1124 7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 1126 This example uses the cached MS-REFERRAL for 10.16.0.0/16 learned 1127 above to start the lookup process at the DDT Map-Server at 1128 192.0.2.211. The DDT Map Resolver proceeds as follows: 1130 1. Send DDT Map-Request (for 10.16.0.1) to 192.0.2.211; if the ITR- 1131 originated Encapsulated Map-Request had a LISP-SEC signature, it 1132 is included 1134 2. DDT Map Server at 192.0.2.211, which is authoritative for 1135 10.16.0.0/16, does not have a matching delegation for 10.16.0.1. 1136 It respondes with a Map-Referral message for 10.16.0.0/24, action 1137 code DELEGATION-HOLE to the DDT Map Resolver. The prefix 1138 10.16.0.0/24 is used because it is the least-specific prefix that 1139 does match the requested EID but does not match one of configured 1140 delegations (10.16.1.0/24 and 10.16.2.0/24). 1142 3. DDT Map Resolver receives the delegation, adds a negative 1143 referral cache entry for 10.16.0.0/24, dequeues the pending 1144 request for 10.16.0.1, and returns a negative Map-Reply to ITR2. 1146 8. Securing the database and message exchanges 1148 This section specifies the DDT security architecture that provides 1149 data origin authentication, data integrity protection, and XEID- 1150 prefix delegation. Global XEID-prefix authorization is out of the 1151 scope of this document. 1153 Each DDT node is configured with one or more public/private key 1154 pair(s) that are used to digitally sign referral records for XEID- 1155 prefix(es) that the DDT node is authoritative for. In other words, 1156 each public/private key pair is associated with the combination of a 1157 DDT node and the XEID-prefix that it is authoritative for. Every DDT 1158 node is also configured with the public keys of its children DDT 1159 nodes. By including public keys of target child DDT nodes in the 1160 Map-Referral records, and signing each record with the DDT node's 1161 private key, a DDT node can securely delegate sub-prefixes of its 1162 authoritative XEID-prefixes to its children DDT nodes. 1164 Map Resolvers are configured with one or more trusted public keys 1165 referred to as trust anchors. Trust anchors are used to authenticate 1166 the DDT security infrastructure. Map Resolvers can discover a DDT 1167 node's public key either by having it configured as a trust anchor, 1168 or by obtaining it from the node's parent as part of a signed Map- 1169 Referral. When a public key is obtained from a node's parent, it is 1170 considered trusted if it is signed by a trust anchor, or if it is 1171 signed by a key that was previously trusted. Typically, in a Map 1172 Resolver, the root DDT node public keys should be configured as trust 1173 anchors. Once a Map Resolver authenticates a public key it locally 1174 caches the key along with the associated DDT node RLOC and XEID- 1175 prefix for future use. 1177 8.1. XEID-prefix Delegation 1179 In order to delegate XEID sub-prefixes to its children, a parent DDT 1180 node signs its Map-Referrals. Every signed Map-Referral also 1181 includes the public keys associated with each child DDT node. Such a 1182 signature indicates that the parent node is delegating the specified 1183 XEID -prefix to a given child DDT node. The signature is also 1184 authenticating the public keys associated with the children nodes, 1185 and authorizing them to be used by the children DDT nodes to provide 1186 origin authentication and integrity protection for further 1187 delegations and mapping information of the XEID-prefix allocated to 1188 the DDT node. 1190 As a result, for a given XEID-prefix, a Map Resolver can form an 1191 authentication chain from a configured trust anchor (typically the 1192 root DDT node) to the leaf nodes (Map Servers). Map Resolvers 1193 leverage this authentication chain to verify the Map-Referral 1194 signatures while walking the DDT tree until they reach a Map Server 1195 authoritative for the given XEID-prefix. 1197 8.2. DDT node operation 1199 Upon receiving a Map-Request, the DDT node responds with a Map- 1200 Referral as specified in Section 5. For every record present in the 1201 Map-Referral, the DDT node also includes the public keys associated 1202 with the record's XEID-prefix and the RLOCs of the children DDT 1203 nodes. Each record contained in the Map-Referral is signed using the 1204 DDT node's private key. 1206 8.2.1. DDT public key revocation 1208 The node that owns a public key can also revoke that public key. For 1209 instance if a parent node advertises a public key for one of its 1210 child DDT nodes, the child DDT node can at a later time revoke that 1211 key. Since DDT nodes do not keep track of the Map Resolvers that 1212 query them, revocation is done in a pull model, where the Map 1213 Resolver is informed of the revocation of a key only when it queries 1214 the node that owns that key. If the parent DDT is configured to 1215 advertise this key, the parent node must also be signaled to remove 1216 the key from the records it advertises for the child DDT node; this 1217 is necessary to avoid further distribution of the revoked key. 1219 To securely revoke a key, the DDT node creates a new Record for the 1220 associated XEID-prefix and locator, including the revoked key with 1221 the R bit set. The DDT node must also include a signature in the 1222 Record that covers this record; this is computed using the private 1223 key corresponding to the key being revoked. Such a record is termed 1224 a "revocation record". By including this record in its Map- 1225 Referrals, the DDT node informs querying Map Resolvers about the 1226 revoked key. A digital signature computed with a revoked key can 1227 only be used to authenticate the revocation, and should not be used 1228 to validate any data. To prevent a compromised key from revoking 1229 other valid keys, a given key can only be used to sign a revocation 1230 for that specific key; it cannot be used to revoke other keys. This 1231 prevents the use of a compromised key to revoke other valid keys as 1232 described in [RFC5011]. A revocation record must be advertised for a 1233 period of time equal to or greater than the TTL value of the Record 1234 that initially advertisied the key, starting from the time that the 1235 advertisement of the key was stopped by removal from the parent DDT 1236 node. 1238 8.3. Map Server operation 1240 Similar to a DDT node, a Map Server is configured with one (or more) 1241 public/private key pairs that it must use to sign Map-Referrals. 1243 However unlike DDT nodes, Map Servers do not delegate prefixes and as 1244 a result they do not need to include keys in the Map-Referrals they 1245 generate. 1247 8.4. Map Resolver operation 1249 Upon receiving a Map-Referral, the Map Resolver must first verify the 1250 signature(s) by using a trust anchor, or a previously authenticated 1251 public key, associated with the DDT node sending the Map-Referral. 1252 If multiple authenticated keys are associated with the DDT node 1253 sending this Map-Referral, the Key Tag field of the signature can be 1254 used to select the right public key for verifying the signature. If 1255 the key tag matches more than one key associated with that DDT node, 1256 the Map Resolver must try verifying the signature with all matching 1257 keys. For every matching key that is found the Map Resolver must 1258 also verify that the key is authoritative for the XEID-prefix in the 1259 Map-Referral record. If such a key is found, the Map Resolver must 1260 use it to verify the associated signature in the record. If no 1261 matching key is found, or if none of the matching keys is 1262 authoritative for the XEID-prefix in the Map-Referral record, or if 1263 such a key is found but the signature is not valid the Map-Referral 1264 record is considered corrupted and must be discarded. This may be 1265 due to expired keys. The Map Resolver can try other siblings of this 1266 node if there is an alternative node authoritative for the same 1267 prefix. If not, the Map Resolver can query the DDT node's parent to 1268 retrieve a valid key. It is good practice to use a counter or timer 1269 to avoid repeating this process if the resolver cannot verify the 1270 signature after several trials. 1272 Once the signature is verified, the Map Resolver has verified the 1273 XEID-prefix delegation in the Map-Referral, and authenticated the 1274 public keys of the children DDT nodes. The Map Resolver must add 1275 these keys to the authenticated keys associated with each child DDT 1276 node and XEID-prefix. These keys are considered valid for the 1277 duration specified in the record's TTL field. 1279 9. Open Issues and Considerations 1281 There are a number of issues with the organization of the mapping 1282 database that need further investigation. Among these are: 1284 o Unlike in [LISP-ALT], DDT does not currently define a mechanism 1285 for propagating ETR-to-Map Server registration state. This 1286 requires DDT Map Servers to suppress returning negative Map-Reply 1287 messages for defined but unregistered XEID-prefixes to avoid loss 1288 of connectivity during partial ETR registration failures. 1289 Suppressing these messages may cause a delay for an ITR obtaining 1290 a mapping entry when such a failure is occurring. 1292 o Defining an interface to implement interconnection and/or 1293 interoperability with other mapping databases, such as LISP+ALT. 1295 o Additional key structures for use with LISP-DDT, such as to 1296 support additional EID formats as defined in [LCAF]. 1298 o Authentication of delegations between DDT nodes. 1300 o Possibility of a new, more general format for the Map-Referral 1301 messages to facilitate the use of LISP-DDT with additional DBID/ 1302 IID/EID combinations. Currently-defined packet formats should be 1303 considered to be preliminary and provisional until this issue has 1304 received greater attention. 1306 o Management of the DDT Map Resolver referral cache, in particular, 1307 detecting and removing outdated entries. 1309 The authors expect that experimentation on the LISP pilot network 1310 will help answer open questions surrounding these and other issues. 1312 10. IANA Considerations 1314 This document makes no request of the IANA. 1316 11. Security Considerations 1318 Section 8 describes a DDT security architecture that provides data 1319 origin authentication, data integrity protection, and XEID-prefix 1320 delegation within the DDT Infrastructure. 1322 Global XEID-prefix authorization is beyond the scope of this 1323 document, but the SIDR working group [RFC6480] is developing an 1324 infrastructure to support improved security of Internet routing. 1325 Further work is required to determine if SIDR's public key 1326 infrastructure (PKI) and the distributed repository system it uses 1327 for storing and disseminating PKI data objects may also be used by 1328 DDT devices to verifiably assert that they are the legitimate holders 1329 of a set of XEID prefixes. 1331 DDT security and [LISP-SEC] complement each other in securing the DDT 1332 infrastructure, Map-Referral messages and the Map-Request/Map-Reply 1333 protocol. In addition LISP-SEC can use the DDT public key 1334 infrastructure to secure the transport of LISP-SEC key material (the 1335 One-Time Key) from a Map-Resolver to the corresponding Map-Server. 1336 For this reason, when LISP-SEC is deployed in conjunction with a 1337 LISP-DDT mapping database and the path between Map-Resolver and Map- 1338 Server needs to be protected, DDT security should be enabled as well. 1340 12. References 1342 12.1. Normative References 1344 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1345 Address Format", draft-ietf-lisp-lcaf-00.txt (work in 1346 progress), August 2012. 1348 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1349 "Locator/ID Separation Protocol (LISP)", 1350 draft-ietf-lisp-23.txt (work in progress), May 2012. 1352 [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server Interface", 1353 draft-ietf-lisp-ms-16.txt (work in progress), March 2012. 1355 [RFC1035] Mockapetris, P., "Domain names - implementation and 1356 specification", STD 13, RFC 1035, November 1987. 1358 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1359 Hashing for Message Authentication", RFC 2104, 1360 February 1997. 1362 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1363 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1365 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 1366 Trust Anchors", RFC 5011, September 2007. 1368 12.2. Informative References 1370 [LISP-ALT] 1371 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 1372 Alternative Topology (LISP-ALT)", 1373 draft-ietf-lisp-alt-10.txt (work in progress), 1374 December 2011. 1376 [LISP-SEC] 1377 Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. 1378 Bonaventure, "LISP-Security", draft-ietf-lisp-sec-03.txt 1379 (work in progress), September 2012. 1381 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1382 E. Lear, "Address Allocation for Private Internets", 1383 BCP 5, RFC 1918, February 1996. 1385 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1386 Secure Internet Routing", RFC 6480, February 2012. 1388 Appendix A. Acknowledgments 1390 The authors with to express their thanks to Damien Saucez, Lorand 1391 Jakab, and Olivier Bonaventure for work on LISP-TREE and LISP 1392 iterable mappings that inspired the hierarchical database structure 1393 and lookup iteration approach described in this document. Thanks 1394 also go to Dino Farinacci and Isidor Kouvelas for their 1395 implementation work; to Selina Heimlich and Srin Subramanian for 1396 testing; to Fabio Maino for work on security processing; and to Job 1397 Snijders, Glen Wiley, Neel Goyal, and Mike Gibbs for work on 1398 operational considerations and initial deployment of a prototype 1399 database infrastructure. Special thanks go to Jesper Skriver, Andrew 1400 Partan, and Noel Chiappa; all of whom have participated in (and put 1401 up with) seemingly endless hours of discussion of mapping database 1402 ideas, concepts, and issues. 1404 Appendix B. Map-Referral Message Format 1406 0 1 2 3 1407 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 |Type=6 | Reserved | Record Count | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | Nonce . . . | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | . . . Nonce | 1414 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | | Record TTL | 1416 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 R | Referral Count| EID mask-len | ACT |A|I| Reserved | 1418 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 c |SigCnt | Map Version Number | EID-AFI | 1420 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 r | EID-prefix ... | 1422 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | /| Priority | Weight | M Priority | M Weight | 1424 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | o | Unused Flags |R| Loc/LCAF-AFI | 1426 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | \| Locator ... | 1428 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 ACT: The "action" field of the mapping record in a Map-Referral 1431 message encodes 6 action types. The values for the action types are: 1433 NODE-REFERRAL (0): Sent by a DDT node with a child delegation which 1434 is authoritative for the EID. 1436 MS-REFERRAL (1): Sent by a DDT node that has information about Map 1437 Server(s) for the EID but it is not one of the Map Servers listed, 1438 i.e. the DDT-Node sending the referral is not a Map Server. 1440 MS-ACK (2): Sent by a DDT Map Server that has one or more ETR 1441 registered for the EID. 1443 MS-NOT-REGISTERED (3): Sent by a DDT Map Server that is configured 1444 for the EID-prefix but for which no ETRs are registered. 1446 DELEGATION-HOLE (4): Sent by an intermediate DDT node with 1447 authoritative configuration covering the requested EID but without 1448 any child delegation for the EID. Also sent by a DDT Map Server 1449 with authoritative configuration covering the requested EID but 1450 for which no specific site ETR is configured. 1452 NOT-AUTHORITATIVE (5): Sent by a DDT node that does not have 1453 authoritative configuration for the requested EID. The EID-prefix 1454 returned MUST be the original requested EID and the TTL MUST be 1455 set to 0. However, if such a DDT node has a child delegation 1456 covering the requested EID, it may choose to return NODE-REFERRAL 1457 or MS-REFERRAL as appropriate. A DDT Map Server with site 1458 information may choose to return of type MS-ACK or MS-NOT- 1459 REGISTERED as appropriate. 1461 Incomplete: The "I" bit indicates that a DDT node's referral-set of 1462 locators is incomplete and the receiver of this message should not 1463 cache the referral. A DDT sets the "incomplete" flag, the TTL, and 1464 the Action Type field as follows: 1466 ------------------------------------------------------------------- 1467 Type (Action field) Incomplete Referral-set TTL values 1468 ------------------------------------------------------------------- 1469 0 NODE-REFERRAL NO YES 1440 1471 1 MS-REFERRAL NO YES 1440 1473 2 MS-ACK * * 1440 1475 3 MS-NOT-REGISTERED * * 1 1477 4 DELEGATION-HOLE NO NO 15 1479 5 NOT-AUTHORITATIVE YES NO 0 1480 ------------------------------------------------------------------- 1482 *: The "Incomplete" flag setting on Map Server originated referral of 1483 MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map 1484 Server has the full peer Map Server configuration for the same 1485 prefix and has encoded the information in the mapping record. 1486 Incomplete bit is not set when the Map Server has encoded the 1487 information, which means the referral-set includes all the RLOCs 1488 of all Map Servers that serve the prefix. It is set when the Map 1489 Server has not encoded the Map Server set information. 1491 SigCnt: Indicates the number of signatures (sig section) present in 1492 the Record. If SigCnt is larger than 0, the signature information 1493 captured in a sig section as described in Appendix B.1 will be 1494 appended to the end of the record. The number of sig sections at the 1495 end of the Record must match the SigCnt. 1497 Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the 1498 record. If this is a LCAF AFI, the contents of the LCAF depend on 1499 the Type field of the LCAF. Security material are stored in LCAF 1500 Type 11. DDT nodes and Map Servers can use this LCAF Type to include 1501 public keys associated with their Child DDT nodes for a XEID-prefix 1502 referral record. LCAF types and formats are defined in [LCAF]. 1504 All the field descriptions are equivalent to those in the Map-Reply 1505 message, as defined in [LISP]. Note, though, that the set of RLOCs 1506 correspond to the DDT node to be queried as a result of the referral 1507 not the RLOCs for an actual EID-to-RLOC mapping. 1509 B.1. SIG section 1511 If SigCnt field in the Map-Referral is not 0, the signature 1512 information is included at the end of captured in a sig section as 1513 described below. SigCnt counts the number of sig sections that 1514 appear at the end of the Record. 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 /| Original Record TTL | 1518 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 / | Signature Expiration | 1520 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 s | Signature Inception | 1522 i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 g | Key Tag | Sig Length | 1524 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 \ | Sig-Algorithm | Reserved | Reserved | 1526 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 \ ~ Signature ~ 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 Original Record TTL: The original Record TTL for this record that is 1531 covered by the signature. Record TTL is in minutes. 1533 Key Tag: An identifier to specify which key is used for this 1534 signature if more than one valid key exists for the signing DDT node. 1536 Sig Length: The length of the Signature field. 1538 Sig-Algorithm: The identifier of the cryptographic algorithm used for 1539 the signature. Default value is RSA-SHA1. 1541 Reserved: This field must be set to 0 on transmit and must be ignored 1542 on receipt. 1544 Signature Expiration and Inception: Specify the validity period for 1545 the signature. Each specify a date and time in the form of a 32-bit 1546 unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, 1547 ignoring leap seconds, in network byte order. 1549 Signature: Contains the cryptographic signature that covers the 1550 entire record. The Record TTL and the sig fields are set to zero for 1551 the purpose of computing the Signature 1553 Appendix C. Encapsulated Control Message Format 1555 0 1 2 3 1556 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 / | IPv4 or IPv6 Header | 1559 OH | (uses RLOC addresses) | 1560 \ | | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 / | Source Port = xxxx | Dest Port = 4342 | 1563 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 \ | UDP Length | UDP Checksum | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 LH |Type=8 |S|D| Reserved | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 / | IPv4 or IPv6 Header | 1569 IH | (uses RLOC or EID addresses) | 1570 \ | | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 / | Source Port = xxxx | Dest Port = yyyy | 1573 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 \ | UDP Length | UDP Checksum | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 LCM | LISP Control Message | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 "D" is the "DDT-originated" flag and is set by a DDT client to 1580 indicate that the receiver can and should return Map-Referral 1581 messages as appropriate. 1583 Authors' Addresses 1585 Vince Fuller 1586 cisco Systems 1587 Tasman Drive 1588 San Jose, CA 95134 1589 USA 1591 Email: vaf@cisco.com 1593 Darrel Lewis 1594 cisco Systems 1595 Tasman Drive 1596 San Jose, CA 95134 1597 USA 1599 Email: darlewis@cisco.com 1601 Vina Ermagan 1602 cisco Systems 1603 Tasman Drive 1604 San Jose, CA 95134 1605 USA 1607 Email: vermagan@cisco.com 1609 Amit Jain 1610 cisco Systems 1611 Tasman Drive 1612 San Jose, CA 95134 1613 USA 1615 Email: amijain@cisco.com