idnits 2.17.1 draft-ietf-lisp-ddt-03.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 36 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 1456: '... 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 (April 15, 2015) is 3298 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 1347, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1350, but no explicit reference was found in the text == Unused Reference: 'RFC4634' is defined on line 1354, but no explicit reference was found in the text == Unused Reference: 'LISP-TREE' is defined on line 1375, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Fuller 3 Internet-Draft 4 Intended status: Experimental D. Lewis 5 Expires: October 17, 2015 V. Ermagan 6 Cisco Systems 7 A. Jain 8 Juniper Networks 9 April 15, 2015 11 LISP Delegated Database Tree 12 draft-ietf-lisp-ddt-03.txt 14 Abstract 16 This draft describes the LISP Delegated Database Tree (LISP-DDT), a 17 hierarchical, distributed database which embodies the delegation of 18 authority to provide mappings from LISP Endpoint Identifiers (EIDs) 19 to Routing Locators (RLOCs). It is a statically-defined distribution 20 of the EID namespace among a set of LISP-speaking servers, called DDT 21 nodes. Each DDT node is configured as "authoritative" for one or 22 more EID-prefixes, along with the set of RLOCs for Map Servers or 23 "child" DDT nodes to which more-specific EID-prefixes are delegated. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 17, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 61 3. Database organization . . . . . . . . . . . . . . . . . . . . 8 62 3.1. EID-prefix tree structure and instance IDs . . . . . . . . 8 63 3.2. Configuring prefix delegation . . . . . . . . . . . . . . 8 64 3.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 8 65 4. The Map-Referral message . . . . . . . . . . . . . . . . . . . 10 66 4.1. Action codes . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.2. Referral set . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 11 69 5. DDT network elements and their operation . . . . . . . . . . . 12 70 5.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 12 72 5.1.2. Missing delegation from an authoritative prefix . . . 12 73 5.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . . 13 74 5.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . . 13 75 5.3.1. Queuing and sending DDT Map-Requests . . . . . . . . . 13 76 5.3.2. Receiving and following referrals . . . . . . . . . . 14 77 5.3.3. Handling referral errors . . . . . . . . . . . . . . . 15 78 5.3.4. Referral loop detection . . . . . . . . . . . . . . . 16 79 6. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . . 17 80 6.1. Map Resolver processing of ITR Map-Request . . . . . . . . 17 81 6.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 17 82 6.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 17 83 6.2. Map Resolver processing of Map-Referral message . . . . . 18 84 6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 18 85 6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 20 86 6.3. DDT Node processing of DDT Map-Request message . . . . . . 22 87 6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 22 88 6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 22 89 7. Example topology and request/referral following . . . . . . . 24 90 7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 25 91 7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . . 26 92 7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 27 93 7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . . 27 94 7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 . . . . 28 95 8. Securing the database and message exchanges . . . . . . . . . 29 96 8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . . 29 97 8.2. DDT node operation . . . . . . . . . . . . . . . . . . . . 30 98 8.2.1. DDT public key revocation . . . . . . . . . . . . . . 30 99 8.3. Map Server operation . . . . . . . . . . . . . . . . . . . 30 100 8.4. Map Resolver operation . . . . . . . . . . . . . . . . . . 31 101 9. Open Issues and Considerations . . . . . . . . . . . . . . . . 32 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 103 11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 105 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 106 12.2. Informative References . . . . . . . . . . . . . . . . . . 35 107 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 37 108 Appendix B. Map-Referral Message Format . . . . . . . . . . . . . 38 109 B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 40 110 Appendix C. Encapsulated Control Message Format . . . . . . . . . 42 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 113 1. Introduction 115 LISP [RFC6830] specifies an architecture and mechanism for replacing 116 the addresses currently used by IP with two separate name spaces: 117 relatively static Endpoint Identifiers (EIDs), used end-to-end for 118 terminating transport-layer associations, and Routing Locators 119 (RLOCs), which are more dynamic, are bound to topological location, 120 and are used for routing and forwarding through the Internet 121 infrastructure. 123 LISP offers a general-purpose mechanism for mapping between EIDs and 124 RLOCs. In organizing a database of EID to RLOC mappings, this 125 specification extends the definition of the EID numbering space by 126 logically prepending and appending several fields for purposes of 127 defining the database index key: Database-ID (DBID, 16 bits), 128 Instance dentifier (IID, 32-bits), Address Family Identifier (16 129 bits), and EID-prefix (variable, according to AFI value). The 130 resulting concatenation of these fields is termed an "Extended EID 131 prefix" or XEID-prefix. 133 The term "Extended EID" (XEID) is also used for an individual LISP 134 EID that is further qualified through the use of an Instance ID. See 135 [LCAF] for further discussion of the use of Instance IDs. 137 The DBID is provided for possible use in case a need evolves for 138 another, higher level in the hierarchy, to allow the creation of 139 multiple, separate database trees. 141 LISP-DDT is a hierarchical distributed database which embodies the 142 delegation of authority to provide mappings, i.e. its internal 143 structure mirrors the hierarchical delegation of address space. It 144 also provides delegation information to Map Resolvers, which use the 145 information to locate EID-to-RLOC mappings. A Map Resolver which 146 needs to locate a given mapping will follow a path through the tree- 147 structured database, contacting, one after another, the DDT nodes 148 along that path until it reaches the leaf DDT node(s) authoritative 149 for the mapping it is seeking. 151 LISP-DDT defines a new device type, the DDT node, that is configured 152 as authoritative for one or more XEID-prefixes. It also is 153 configured with the set of more-specific sub-prefixes that are 154 further delegated to other DDT nodes. To delegate a sub-prefix, the 155 "parent" DDT node is configured with the RLOCs of each child DDT node 156 that is authoritative for the sub-prefix. Each RLOC either points to 157 a Map Server (sometimes termed a "terminal DDT node") to which an 158 Egress Tunnel Routers (ETRs) has registered that sub-prefix or points 159 to another DDT node in the database tree that further delegates the 160 sub-prefix. See [RFC6833] for a description of the functionality of 161 the Map Server and Map Resolver. Note that the target of a 162 delegation must always be an RLOC (not an EID) to avoid any circular 163 dependency. 165 To provide a mechanism for traversing the database tree, LISP-DDT 166 defines a new LISP message type, the Map-Referral, which is returned 167 to the sender of a Map-Request when the receiving DDT node can refer 168 the sender to another DDT node that has more detailed information. 169 See Section 4 for the definition of the Map-Referral message. 171 To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map 172 Resolver, starts by sending an Encapsulated Map-Request to a 173 preconfigured DDT node RLOC. The DDT node responds with a Map- 174 Referral message that either indicates that it will find the 175 requested mapping to complete processing of the request or that the 176 DDT client should contact another DDT node that has more-specific 177 information; in the latter case, the DDT node then sends a new 178 Encapsulated Map-Request to the next DDT node and the process repeats 179 in an iterative manner. 181 Conceptually, this is similar to the way that a client of the Domain 182 Name System (DNS) follows referrals (DNS responses that contain only 183 NS records) from a series of DNS servers until it finds an answer. 185 2. Definition of Terms 187 Extended EID (XEID): a LISP EID, optionally extended with a non- 188 zero Instance ID (IID) if the EID is intended for use in a context 189 where it may not be a unique value, such as on a Virtual Private 190 Network where [RFC1918] address space is used. See "Using 191 Virtualization and Segmentation with LISP" in [RFC6830] for more 192 discussion of Instance IDs. 194 XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided 195 to allow the definition of multiple databases; currently always 196 zero in this version of DDT, with other values reserved for future 197 use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used 198 as a key index into the database. 200 DDT node: a network infrastructure component responsible for 201 specific XEID-prefix and for delegation of more-specific sub- 202 prefixes to other DDT nodes. 204 DDT client: a network infrastructure component that sends Map- 205 Request messages and implements the iterative following of Map- 206 Referral results. Typically, a DDT client will be a Map Resolver 207 but it is also possible for an ITR to implement DDT client 208 functionality. 210 DDT Map Server: a DDT node that also implements Map Server 211 functionality (forwarding Map-Requests and/or returning Map- 212 Replies if offering proxy Map-Reply service) for a subset of its 213 delegated prefixes. 215 DDT Map Resolver: a network infrastructure element that accepts a 216 Map-Request, adds the XEID to its pending request list, then 217 queries one or more DDT nodes for the requested EID, following 218 returned referrals until it receives one with action code MS-ACK 219 (or an error indication). MS-ACK indicates that the Map-Request 220 has been sent to a Map Server that will forward it to an ETR that, 221 in turn, will provide a Map-Reply to the original sender. A DDT 222 Map Resolver maintains both a cache of Map-Referral message 223 results containing RLOCs for DDT nodes responsible for XEID- 224 prefixes of interest (termed the "referral cache") a pending 225 request list of XEIDs that are being resolved through iterative 226 querying of DDT nodes. 228 Encapsulated Map-Request: a LISP Map-Request carried within an 229 Encapsulated Control Message, which has an additional LISP header 230 prepended. Sent to UDP destination port 4342. The "outer" 231 addresses are globally-routable IP addresses, also known as RLOCs. 232 Used by an ITR when sending to a Map Resolver and by a Map Server 233 when forwarding a Map-Request to an ETR as documented in LISP-MS 234 [RFC6833]. 236 DDT Map-Request: an Encapsulated Map-Request sent by a DDT client to 237 a DDT node. The "DDT-originated" flag is set in the encapsulation 238 header indicating that the DDT node should return Map-Referral 239 messages if the Map-Request EID matches a delegated XEID-prefix 240 known to the DDT node. Section 5.3.1 describes how DDT Map- 241 Requests are sent. 243 Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node 244 and for which the DDT node may provide further delegations of 245 more-specific sub-prefixes. 247 Map-Referral: a LISP message sent by a DDT node in response to a DDT 248 Map-Request for an XEID that matches a configured XEID-prefix 249 delegation. A non-negative Map-Referral includes a "referral", a 250 set of RLOCs for DDT nodes that have more information about the 251 sub-prefix; a DDT client "follows the referral" by sending another 252 DDT Map-Request to one of those RLOCs to obtain either an answer 253 or another referral to DDT nodes responsible for a more-specific 254 XEID-prefix. See Section 5.1 and Section 5.3.2 for details on the 255 sending and processing of Map-Referral messages. 257 negative Map-Referral: a Map-Referral sent in response to a DDT Map- 258 Request that matches an authoritative XEID-prefix but for which 259 there is no delegation configured (or no ETR registration if sent 260 by a DDT Map-Server). 262 Pending Request List: the set of outstanding requests for which a 263 DDT Map Resolver has received encapsulated Map-Requests from a DDT 264 client for an XEID. Each entry in the list contains additional 265 state needed by the referral following process, including the 266 requestor(s) of the XEID (typically, one or more ITRs), saved 267 information about the last referral received and followed 268 (matching XEID-prefix, action code, RLOC set, index of last RLOC 269 queried in the RLOC set), and any [LISP-SEC] information that was 270 included in the DDT client Map-Request. An entry in the list may 271 be interchangeably termed a "pending request list entry" or simply 272 a "pending request". 274 For definitions of other terms, notably Map-Request, Map-Reply, 275 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server, 276 and Map Resolver, please consult the LISP specification [RFC6830] and 277 the LISP Mapping Service specification [RFC6833]. 279 3. Database organization 281 3.1. EID-prefix tree structure and instance IDs 283 LISP-DDT defines a tree structure that is indexed by a binary 284 encoding of five fields, in order of significance: DBID (16 bits), 285 Instance Identifier (IID, 32 bits), Address Family Identifier (AFI, 286 16 bits), and EID-prefix (variable, according to AFI value). The 287 fields are concatenated, with the most significant fields as listed 288 above. The index into this structure is also referred to as an 289 Extended EID-prefix (XEID-prefix). 291 It is important to note that LISP-DDT does not store actual EID-to- 292 RLOC mappings; it is, rather, a distributed index that can be used to 293 find the devices (Map Servers and their registered EIDs) that can be 294 queried with LISP to obtain those mappings. Changes to EID-to-RLOC 295 mappings are made on the ETRs which define them, not to any DDT node 296 configuration. DDT node configuration changes are only required when 297 branches of the database hierarchy are added, removed, or modified. 299 3.2. Configuring prefix delegation 301 Every DDT node is configured with one or more XEID-prefixes for which 302 it is authoritative along with a list of delegations of XEID-prefixes 303 to other DDT nodes. A DDT node is required to maintain a list of 304 delegations for all sub-prefixes of its authoritative XEID-prefixes; 305 it also may list "hints", which are prefixes that it knows about that 306 belong to its parents, to the root, or to any other point in the 307 XEID-prefix hierarchy. A delegation (or hint) consists of an XEID- 308 prefix, a set of RLOCs for DDT nodes that have more detailed 309 knowledge of the XEID-prefix, and accompanying security information. 310 Those RLOCs are returned in Map-Referral messages when the DDT node 311 receives a DDT Map-Request with an xEID that matches a delegation. A 312 DDT Map Server will also have a set of sub-prefixes for which it 313 accepts ETR mapping registrations and for which it will forward (or 314 answer, if it provides proxy Map-Reply service) Map-Requests. For 315 details of security infomation in Map-Referrals see Section 8. 317 3.2.1. The root DDT node 319 The root DDT node is the logical "top" of the database hierarchy: 320 DBID=0, IID=0, AFI=0, EID-prefix=0/0. A DDT Map-Request that matches 321 no configured XEID-prefix will be referred to the root node. The 322 root node in a particular instantiation of LISP-DDT must therefore be 323 configured with delegations for at least all defined IIDs and AFIs. 325 To aid in defining a "sub-root" DDT node that is responsible for all 326 EID-prefixes within multiple IIDs (say, for using LISP to create 327 virtual networks that use overlapping address space), it may be 328 useful to implement configuration language that allows for a range of 329 IIDs to be delegated together. Additional configuration shorthand 330 for delegating a range of IIDs (and all of the EIDs under them) may 331 also be helpful. 333 4. The Map-Referral message 335 A Map-Referral message is sent by a DDT node to a DDT client in 336 response to a DDT Map-Request message. The message consists of an 337 action code along with delegation information about the XEID-prefix 338 that matches the XEID requested. 340 See Appendix B for a detailed layout of the Map-Referral message 341 fields. 343 4.1. Action codes 345 The action codes are as follows: 347 NODE-REFERRAL (0): indicates that the replying DDT node has 348 delegated an XEID-prefix that matches the requested XEID to one or 349 more other DDT nodes. The Map-Referral message contains a "map- 350 record" with additional information, most significantly the set of 351 RLOCs to which the prefix has been delegated, that is used by a 352 DDT Map Resolver to "follow" the referral. 354 MS-REFERRAL (1): indicates that the replying DDT node has delegated 355 an XEID-prefix that matches the requested XEID to one or more DDT 356 Map Servers. It contains the same additional information as a 357 NODE-REFERRAL but is handled slightly differently by the receiving 358 DDT client (see Section 5.3.2). 360 MS-ACK (2): indicates that a replying DDT Map Server received a DDT 361 Map-Request that matches an authoritative XEID-prefix for which is 362 has one or more registered ETRs. This means that the request can 363 be forwarded to one of those ETRs to provide an answer to the 364 querying ITR. 366 MS-NOT-REGISTERED (3): indicates that the replying DDT Map Server 367 received a Map-Request for one of its configured XEID-prefixes 368 which has no ETRs registered. 370 DELEGATION-HOLE (4): indicates that the requested XEID matches a 371 non-delegated sub-prefix of the XEID space. This is a non-LISP 372 "hole", which has not been delegated to any DDT Map Server or ETR. 373 See Section 5.1.2 for details. 375 NOT-AUTHORITATIVE (5): indicates that the replying DDT node received 376 a Map-Request for an XEID-request for which it is not 377 authoritative. This can occur if a cached referral has become 378 invalid due to a change in the database hierarchy. 380 4.2. Referral set 382 For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a 383 DDT node includes in the Map-Referral message a list of RLOCs for all 384 DDT nodes that are authoritative for the XEID-prefix being returned; 385 a DDT Map Resolver uses this information to contact one of those DDT 386 nodes as it "follows" a referral. 388 4.3. Incomplete flag 390 A DDT node sets the "Incomplete" flag in a Map-Referral message if 391 the Referral Set is incomplete; this is intended to prevent a DDT Map 392 Resolver from caching a referral with incomplete information. A DDT 393 node must set the "incomplete" flag in the following cases: 395 o If it is setting action code MS-ACK or MS-NOT-REGISTERED but does 396 not have configuration for other "peer" DDT nodes that are also 397 authoritative for the matched XEID-prefix. 399 o If it is setting action code NOT-AUTHORITATIVE. 401 5. DDT network elements and their operation 403 As described above, DDT introduces a new network element, the "DDT 404 node", extends the functionality of Map Servers and Map Resolvers to 405 send and receive Map-Referral messages. The operation of each of 406 these devices is described as follows. 408 5.1. DDT node 410 When a DDT node receives a DDT Map-Request, it compares the requested 411 XEID against its list of XEID-prefix delegations and its list of 412 authoritative XEID-prefixes and acts as follows: 414 5.1.1. Match of a delegated prefix (or sub-prefix) 416 If the requested XEID matches one of the DDT node's delegated 417 prefixes, then a Map-Referral message is returned with the matching 418 more-specific XEID-prefix and the set of RLOCs for the referral 419 target DDT nodes including associated security information (see 420 Section 8 for details on security). If the delegation is known to be 421 a DDT Map Server, then the Map-Referral message is sent with action 422 code MS-REFERRAL to indicate to the receiver that LISP-SEC 423 information (if saved in the pending request) should be included in 424 the next DDT Map-Request; otherwise, the action code NODE-REFERRAL is 425 used. 427 Note that a matched delegation does not have to be for a sub-prefix 428 of an authoritative prefix; in addition to being configured to 429 delegate sub-prefixes of an authoritative prefix, a DDT node may also 430 be configured with other XEID-prefixes for which it can provide 431 referrals to DDT nodes anywhere in the database hierarchy. This 432 capability to define "shortcut hints" is never required to be 433 configured but may be a useful heuristic for reducing the number of 434 iterations needed to find an EID, particular for private network 435 deployments. 437 5.1.2. Missing delegation from an authoritative prefix 439 If the requested XEID did not match a configured delegation but does 440 match an authoritative XEID-prefix, then the DDT node returns a 441 negative Map-Referral that uses the least-specific XEID-prefix that 442 does not match any XEID-prefix delegated by the DDT node. The action 443 code is set to DELEGATION-HOLE; this indicates that the XEID is not a 444 LISP destination. 446 If the requested XEID did not match either a configured delegation or 447 an authoritative XEID-prefix, then the request is dropped and a 448 negative Map-Referral with action code NOT-AUTHORITATIVE is returned. 450 5.2. DDT Map Server 452 When a DDT Map Server receives a DDT Map-Request, its operation is 453 similar to that of a DDT node with additional processing as follows: 455 o If the requested XEID matches a registered XEID-prefix, then the 456 Map-Request is forwarded to one of the destination ETR RLOCs (or 457 the Map Server sends a Map-Reply, if it is providing proxy Map- 458 Reply service) and a Map-Referral with the MS-ACK action is 459 returned to the sender of the DDT Map-Request. 461 o If the requested XEID matches a configured XEID-prefix for which 462 no ETR registration has been received then a negative Map-Referral 463 with action code MS-NOT-REGISTERED is returned to the sender of 464 the DDT Map-Request. 466 5.3. DDT Map Resolver 468 Just as any other Map Resolver, a DDT Map Resolver accepts Map- 469 Requests from its clients (typically, ITRs) and ensures that those 470 Map-Requests are forwarded to the correct ETR, which generates Map- 471 Replies. Unlike a Map Resolver that uses the ALT mapping system (see 472 [RFC6836]), however, a DDT Map Resolver uses an iterative process of 473 following referrals to find the correct ETR to answer a Map-Request; 474 this requires a DDT Map Resolver to maintain additional state: a Map- 475 Referral cache and pending request list of XEIDs that are going 476 through the iterative referral process. 478 5.3.1. Queuing and sending DDT Map-Requests 480 When a DDT Map Resolver receives an encapsulated Map-Request, it 481 first performs a longest-match search for the XEID in its referral 482 cache. If no match is found or if a negative cache entry is found, 483 then the destination is not in the database; a negative Map-Reply is 484 returned and no further processing is performed by the DDT Map 485 Resolver. 487 If a match is found, the DDT Map Resolver creates a pending request 488 list entry for the XEID and saves the original Map-Request (minus the 489 encapsulation header) along with other information needed to track 490 progress through the iterative referral process; the "referral XEID- 491 prefix" is also initialized to the null value since no referral has 492 yet been received. The Map Resolver then creates a DDT Map-Request 493 (which is an encapsulated Map-Request with the "DDT-originated" flag 494 set in the message header) for the XEID but without any 495 authentication data that may have been included in the original Map- 496 Request. It sends the DDT Map-Request to one of the RLOCs in the 497 chosen referral cache entry. The referral cache is initially 498 populated with one or more statically-configured entries; additional 499 entries are added when referrals are followed, as described below. A 500 DDT Map Resolver is not absolutely required to cache referrals but it 501 doing so decreases latency and reduces lookup delays. 503 Note that in normal use on the public Internet, the statically- 504 configured initial referral cache for a DDT Map Resolver should 505 include a "default" entry with RLOCs for one or more DDT nodes that 506 can reach the DDT root node. If a Map Resolver does not have such 507 configuration, it will return a Negative Map-Reply if it receives a 508 query for an EID outside the subset of the mapping database known to 509 it. While this may be desirable on private network deployments or 510 during early transition to LISP when few sites are using it, this 511 behavior is not appropriate when LISP is in general use on the 512 Internet. 514 5.3.2. Receiving and following referrals 516 After sending a DDT Map-Request, a DDT Map Resolver expects to 517 receive a Map-Referral response. If none occurs within the timeout 518 period, the DDT Map Resolver retransmits the request, sending to the 519 next RLOC in the referral cache entry if one is available. If the 520 maximum number of retransmissions has occurred and all RLOCs have 521 been tried, then the pending request list entry is dequeued. 523 A DDT Map Resolver processes a received Map-Referral message 524 according to each action code: 526 NODE-REFERRAL: The DDT Map Resolver checks for a possible referral 527 loop as as described in Section 5.3.4. If no loop is found, the 528 DDT Map Resolver saves the prefix returned in the Map-Referral 529 message in the referral cache, updates the saved prefix and saved 530 RLOCs in the pending request list entry, and follows the referral 531 by sending a new DDT Map-Request to one of the DDT node RLOCs 532 listed in the Referral Set; security information saved with the 533 original Map-Request is not included. 535 MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same 536 manner as a NODE-REFERRAL except that that security information 537 saved with the original Map-Request is included in the new Map- 538 Request sent to a Map Server (see Section 8 for details on 539 security). 541 MS-ACK: This is returned by a DDT Map Server to indicate that it has 542 one or more registered ETRs that can answer a Map-Request for the 543 XEID. If the pending request did not include saved LISP-SEC 544 information or if that information was already included in the 545 previous DDT Map-Request (sent by the DDT Map Resolver in response 546 to either an MS-REFERRAL or a previous MS-ACK referral), then the 547 pending request for the XEID is complete and is dequeued. 548 Otherwise, LISP-SEC information is required and has not yet been 549 sent to the authoritative DDT Map-Server; the DDT Map Resolver re- 550 sends the DDT Map-Request with LISP-SEC information included and 551 the pending request queue entry remains until another Map-Referral 552 with MS-ACK action code is received. If the "incomplete" flag is 553 not set, the prefix is saved in the referral cache. 555 MS-NOT-REGISTERED: The DDT Map Server qurieed could not process the 556 request because it did not have any ETRs registered for a 557 matching, authoritative XEID-prefix. If the DDT Map Resolver has 558 not yet tried all of the RLOCs saved with the pending request, 559 then it sends a Map-Request to the next RLOC in that list. If all 560 RLOCs have been tried, then the destination XEID is not registered 561 and is unreachable. The DDT Map Resolver returns a negative Map- 562 Reply to the original Map-Request sender; this Map-Reply contains 563 the non-registered XEID-prefix with TTL value of one minute. A 564 negative referral cache entry is created for the prefix (also with 565 TTL of one minute) and the pending request is dequeued. 567 DELEGATION-HOLE: The DDT Map Server queried did not have an XEID- 568 prefix defined that matched the requested XEID so it does not 569 exist in the mapping database. The DDT Map Resolver returns a 570 negative Map-Reply to the original Map-Request sender; this Map- 571 Reply will indicate the least-specific XEID-prefix matching the 572 requested XEID for which no delegations exist and will have a TTL 573 value of 15 minutes. A negative referral cache entry is created 574 for the prefix (also with TTL of 15 minutes) and the pending 575 request is dequeued. 577 NOT-AUTHORITATIVE: The DDT Map Server queried is not authoritative 578 for the requested XEID. This can occur if a cached referral has 579 become invalid due to a change in the database hierarchy. If the 580 DDT Map Resolver receiving this message can determine that it is 581 using old cached information, it may choose to delete that cached 582 information and re-try the original Map-Request, starting from its 583 "root" cache entry. If this action code is received in response 584 to a query that was not to cached referral information, then it 585 indicates a database synchronization problem or configuration 586 error. The pending request list entry that caused this answer is 587 removed, with no answer returned to the original requestor. 589 5.3.3. Handling referral errors 591 Other states are possible, such as a misconfigured DDT node (acting 592 as a proxy Map Server, for example) returning a Map-Reply to the DDT 593 Map Resolver; they should be considered errors and logged as such. 595 It is not clear exactly what else the DDT Map Resolver should do in 596 such cases; one possibility is to remove the pending request list 597 entry and send a negative Map-Reply to the original Map-Request 598 sender. Alternatively, if a DDT Map Resolver detects unexpected 599 behavior by a DDT node, it could mark that node as unusable in its 600 referral cache and update the pending request to try a different DDT 601 node if more than one is listed in the referral cache. In any case, 602 any prefix contained in a Map-Referral message that causes a referral 603 error (including a referral loop) is not saved in the DDT Map- 604 Resolver referral cache. 606 5.3.4. Referral loop detection 608 In response to a Map-Referral message with action code NODE-REFERRAL 609 or MS-REFERRAL, a DDT Map Resolver is directed to query a new set of 610 DDT node RLOCs that are expected to have more-specific XEID-prefix 611 information for the requested XEID. To prevent a possible "iteration 612 loop" (following referrals back-and-forth among a set of DDT nodes 613 without ever finding an answer), a DDT Map Resolver saves the last 614 received referral XEID-prefix for each pending request and checks 615 that a newly received NODE-REFERRAL or MS-REFERRAL message contains a 616 more-specific referral XEID-prefix; an exact or less-specific match 617 of the saved XEID-prefix indicates a referral loop. If a loop is 618 detected, the DDT Map Resolver handles the request as described in 619 Section 5.3.3. Otherwise, the Map Resolver saves the most recently 620 received referral XEID-prefix with the pending request when it 621 follows the referral. 623 As an extra measure to prevent referral loops, it is probably also 624 wise to limit the total number of referrals for any request to some 625 reasonable number; the exact value of that number will be determined 626 during experimental deployment of LISP-DDT but is bounded by the 627 maximum length of the XEID. 629 Note that when a DDT Map Resolver adds an entry to its lookup queue 630 and sends an initial Map-Request for an XEID, the queue entry has no 631 previous referral XEID-prefix; this means that the first DDT node 632 contacted by a DDT Map Resolver may provide a referral to anywhere in 633 the DDT hierarchy. This, in turn, allows a DDT Map Resolver to use 634 essentially any DDT node RLOCs for its initial cache entries and 635 depend on the initial referral to provide a good starting point for 636 Map-Requests; there is no need to configure the same set of root DDT 637 nodes on all DDT Map Resolvers. 639 6. Pseudo Code and Decision Tree diagrams 641 To aid in implementation, each of the major DDT Map Server and DDT 642 Map Resolver functions are described below, first using simple 643 "pseudo-code" and then in the form of a decision tree. 645 6.1. Map Resolver processing of ITR Map-Request 647 6.1.1. Pseudo-code summary 649 if ( request pending i.e., (ITR,EID) of request same ) { 650 replace old request with new & use new request nonce 651 for future requests 652 } else if ( no match in refcache ) { 653 return negative map-reply to ITR 654 } else if ( match type delegation hole ) { 655 return negative map-reply to ITR 656 } else if ( match type ms-ack ) { 657 fwd DDT request to map-server 658 } else { 659 store & fwd DDT request w/o OTK to node delegation 660 } 662 6.1.2. Decision tree diagram 663 +------------+ 664 | Is Request | Yes 665 | |----> Replace old request with 666 | Pending? | new nonce for future requests 667 +------------+ 668 | 669 |No 670 | 671 V 672 +------------+ 673 | Match In | No 674 | Referral |----> Send Negative Map Reply 675 | cache? | (not a likely event as root 676 +------------+ configured on every MR) 677 | 678 |Yes 679 | 680 V 681 +------------+ 682 | Match Type | Yes 683 | Delegation |----> Send Negative Map Reply 684 | Hole ? | 685 +------------+ 686 | 687 |No 688 | 689 V 690 +------------+ 691 | Match Type | Yes 692 | MS-ACK? |----> Forward DDT Map-request to Map-Server 693 | | 694 +------------+ 695 | 696 |No 697 | 698 V 699 Store request & Fwd DDT Request w/o OTK 700 to DDT node delegation 702 6.2. Map Resolver processing of Map-Referral message 704 6.2.1. Pseudo-code summary 706 if ( no request pending matched by referral nonce ) { 707 silently drop 708 } 710 if ( pfx in referral less specific than last referral used ) { 711 if ( gone through root ) { 712 silently drop 713 } else { 714 goto root 715 } 716 } 718 switch (map_referral_type) { 720 case NOT_AUTHORITATIVE : 721 if ( gone through root ) { 722 return negative map-reply to ITR 723 } else { 724 goto root 725 } 727 case DELEGATION_HOLE: 728 cache & send negative map-reply to ITR 730 case MS_REFERRAL: 731 if ( referral equal to last used ) { 732 if ( gone through root ) { 733 return negative map-reply to ITR 734 } else { 735 goto root 736 } 737 } else { 738 cache & follow the referral 739 } 741 case NODE_REFERRAL: 742 if ( referral equal to last used ) { 743 if ( gone through root ) { 744 return negative map-reply to ITR 745 } else { 746 goto root 747 } 748 } else { 749 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 } 760 } 762 case MS_NOT_REGISTERED: 763 if { all map-server delegations not tried } { 764 follow delegations not tried 765 if ( !incomplete ) { 766 cache 767 } 768 } else { 769 send negative map-reply to ITR 770 if { !incomplete } { 771 cache 772 } 773 } 775 case DEFAULT: 776 drop 778 } 779 } 781 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 871 +------------+ 872 | Am I | No 873 | Authori- |----> Return NOT_AUTHORITATIVE 874 | tative? | Incomplete = 1 875 +------------+ ttl = Default_DdtNode_Ttl 876 | 877 |Yes 878 | 879 V 880 +------------+ +------------+ 881 | Delegation | Yes | Delegations| Yes 882 | Exists? |---->| are map |----> Return MS_REFERRAL 883 | | | servers? | ttl = Default_DdtNode_Ttl 884 +------------+ +------------+ 885 | \ No 886 |No +--> Return NODE_REFERRAL 887 | ttl = Default_DdtNode_Ttl 888 V 889 +------------+ +------------+ +------------+ 890 | EID in | Yes | Site | Yes | Map-server | 891 | Site |---->| Registered?|----> Forward---->| peers | 892 | Config? | | | Map-request | configured?| 893 +------------+ +------------+ to ETR +------------+ 894 | | | | 895 | |No No| |Yes 896 | | | | 897 | | V V 898 | | Return MS_ACK Return MS_ACK 899 | V with INC=1 900 | +------------+ ttl=Default_Registered_Ttl 901 | | Map-server | Yes 902 | | peers |----> Return MS_NOT_REGISTERED 903 | | configured?| ttl = Default_Negative_Referral_Ttl 904 | +------------+ 905 | \ No 906 |No +--> Return MS_NOT_REGISTERED 907 | Incomplete = 1 908 V ttl = Default_Negative_Referral_Ttl 909 Return DELEGATION_HOLE 910 ttl = Default_Negative_Referral_Ttl 912 7. Example topology and request/referral following 914 To show how referrals are followed to find the RLOCs for a number of 915 EIDs, consider the following example EID topology for DBID=0, IID=0, 916 AFI=1, and EID=0/0 918 +---------------------+ +---------------------+ 919 | root1: 192.0.2.1 | | root2: 192.0.2.2 | 920 | authoritative: 0/0 | | authoritative: 0/0 | 921 +---------------------+ +---------------------+ 922 | \ / | 923 | \ / | 924 | / \ | 925 | / \ | 926 | | | | 927 V V V V 928 +--------------------------+ +--------------------------+ 929 | DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 | 930 | authoritative: 10.0.0.0/8| | authoritative: 10.0.0.0/8| 931 +--------------------------+ +--------------------------+ 932 | \ / | 933 | \ / | 934 | / \ | 935 | / \ | 936 | | | | 937 V V V V 938 +--------------------------+ +---------------------------+ 939 | Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 | 940 |authoritative: 10.0.0.0/12| |authoritative: 10.16.0.0/12| 941 | site1: 10.1.0.0/16 | +---------------------------+ 942 | site2: 10.2.0.0/16 | | | 943 +--------------------------+ | | 944 | | 945 | | 946 V V 947 +---------------------------+ +---------------------------+ 948 | Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 | 949 |authoritative: 10.16.0.0/16| |authoritative: 10.17.0.0/16| 950 | site3: 10.16.1.0/24 | | site5: 10.17.8.0/24 | 951 | site4: 10.16.2.0/24 | | site6: 10.17.9.0/24 | 952 +---------------------------+ +---------------------------+ 954 DDT nodes are configured for this "root" at IP addresses 192.0.2.1 955 and 192.0.2.2. DDT Map Resolvers are configured with default 956 referral cache entries to these addresses. 958 The root DDT nodes delegate 10.0.0/8 to two DDT nodes with IP 959 addresses 192.0.2.11 and 192.0.2.12. 961 The DDT nodes for 10.0.0.0/8 delegate 10.0.0.0/12 to a DDT Map Server 962 with RLOC 192.0.2.101 964 The DDT Map Server for 10.0.0.0/12 is configured to allow ETRs to 965 register the sub-prefixes 10.1.0.0/16 and 10.2.0.0/16 967 The DDT nodes for 10.0.0.0/8 also delegate 10.16.0.0/12 to a DDT node 968 with RLOC 192.0.2.201 970 The DDT node for 10.16.0.0/12 is further configured to delegate 971 10.16.0.0/16 to a DDT Map Server with RLOC 192.0.2.211 and 10.17.0.0/ 972 16 to a DDT Map Server with RLOC 192.0.2.221 974 The DDT Map Server for 10.16.0.0/16 is configured to allow ETRs to 975 register the sub-prefixes 10.16.1.0/24 and 10.16.2.0/24 977 The DDT Map Server for 10.17.0.0/16 is configured to allow ETRs to 978 register the sub-prefixes 10.17.8.0/24 and 10.17.9.0/24 980 7.1. Lookup of 10.1.1.1/32 by ITR1 982 The first example shows a DDT Map Resolver following a delegation 983 from the root to a DDT node followed by another delegation to a DDT 984 Map Server. 986 ITR1 sends an Encapsulated Map-Request for 10.1.1.1 to one of its 987 configured (DDT) Map Resolvers. The DDT Map Resolver proceeds as 988 follows: 990 1. Send DDT Map-Request (for 10.1.1.1) to one of the root DDT nodes, 991 192.0.2.1 or 192.0.2.2 993 2. Receive (and save in referral cache) Map-Referral for EID-prefix 994 10.0.0.0/8, action code NODE-REFERRAL, RLOC set (192.0.2.11, 995 192.0.2.12) 997 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 999 4. Receive (and save in referral cache) Map-Referral for EID-prefix 1000 10.0.0.0/12, action code MS-REFERRAL, RLOC set (192.0.2.101) 1002 5. Send DDT Map-Request to 192.0.2.101; if the ITR-originated 1003 Encapsulated Map-Request had a LISP-SEC signature, it is included 1005 6. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 1006 and forwards to a registered site1 ETR for 10.1.0.0/16 1008 7. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 1009 EID-prefix 10.1.0.0/16, action code MS-ACK to the DDT Map 1010 Resolver 1012 8. DDT Map Resolver receives Map-Referral message and dequeues the 1013 pending request for 10.1.1.1 1015 9. site1 ETR for 10.1.0.0/16 receives Map-Request forwarded by DDT 1016 Map Server and sends Map-Reply to ITR1 1018 7.2. Lookup of 10.17.8.1/32 by ITR2 1020 The next example shows a three-level delegation: root to first DDT 1021 node, first DDT node to second DDT node, second DDT node to DDT Map 1022 Server. 1024 ITR2 sends an Encapsulated Map-Request for 10.17.8.1 to one of its 1025 configured (DDT) Map Resolvers, which are different from those for 1026 ITR1. The DDT Map Resolver proceeds as follows: 1028 1. Send DDT Map-Request (for 10.17.8.1) to one of the root DDT 1029 nodes, 192.0.2.1 or 192.0.2.2 1031 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1032 10.0.0.0/8, action code NODE-REFERRAL, RLOC set (192.0.2.11, 1033 192.0.2.12) 1035 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 1037 4. Receive (and save in referral cache) Map-Referral for EID-prefix 1038 10.16.0.0/12, action code NODE-REFERRAL, RLOC set (192.0.2.201) 1040 5. Send DDT Map-Request to 192.0.2.201 1042 6. Receive (and save in referral cache) Map-Referral for EID-prefix 1043 10.17.0.0/16, action code MS-REFERRAL, RLOC set (192.0.2.221) 1045 7. Send DDT Map-Request to 192.0.2.221; if the ITR-originated 1046 Encapsulated Map-Request had a LISP-SEC signature, it is 1047 included 1049 8. DDT Map Server at 192.0.2.221 decapsulates the DDT Map-Request 1050 and forwards to a registered site5 ETR for 10.17.8.0/24 1052 9. DDT Map Server at 192.0.2.221 sends a Map-Referral message for 1053 EID-prefix 10.17.8.0/24, action code MS-ACK, to the DDT Map 1054 Resolver 1056 10. DDT Map Resolver receives Map-Referral(MS-ACK) message and 1057 dequeues the pending request for 10.17.8.1 1059 11. site5 ETR for 10.17.8.0/24 receives Map-Request forwarded by DDT 1060 Map Server and sends Map-Reply to ITR2 1062 7.3. Lookup of 10.2.2.2/32 by ITR1 1064 This example shows how a DDT Map Resolver uses a saved referral cache 1065 entry to skip the referral process and go directly to a DDT Map 1066 Server for a prefix that is similar to one previously requested. 1068 In this case, ITR1 uses the same Map Resolver used in example 1069 Section 7.1. It sends an Encapsulated Map-Request for 10.2.2.2 to 1070 that (DDT) Map Resolver. The DDT Map-Resolver finds an MS-REFERRAL 1071 cache entry for 10.0.0.0/12 with RLOC set (192.0.2.101) and proceeds 1072 as follows: 1074 1. Send DDT Map-Request (for 10.2.2.2) to 192.0.2.101; if the ITR- 1075 originated Encapsulated Map-Request had a LISP-SEC signature, it 1076 is included 1078 2. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 1079 and forwards to a registered site2 ETR for 10.2.0.0/16 1081 3. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 1082 EID-prefix 10.2.0.0/16, action code MS-ACK to the DDT Map 1083 Resolver 1085 4. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 1086 pending request for 10.2.2.2 1088 5. site2 ETR for 10.2.0.0/16 receives Map-Request and sends Map- 1089 Reply to ITR1 1091 7.4. Lookup of 10.16.2.1/32 by ITR2 1093 This example shows how a DDT Map Resolver uses a saved referral cache 1094 entry to start the referral process at a non-root, intermediate DDT 1095 node for a prefix that is similar to one previously requested. 1097 In this case, ITR2 asks the same Map Resolver used in example 1098 Section 7.2. It sends an Encapsulated Map-Request for 10.16.2.1 to 1099 that (DDT) Map Resolver, which finds a NODE-REFERRAL cache entry for 1100 10.16.0.0/12 with RLOC set (192.0.2.201). It proceeds as follows: 1102 1. Send DDT Map-Request (for 10.16.2.1) to 192.0.2.201 1104 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1105 10.16.0.0/16, action code MS-REFERRAL, RLOC set (192.0.2.211) 1107 3. Send DDT Map-Request to 192.0.2.211; if the ITR-originated 1108 Encapsulated Map-Request had a LISP-SEC signature, it is included 1110 4. DDT Map Server at 192.0.2.211 decapsulates the DDT Map-Request 1111 and forwards to a registered site4 ETR for 10.16.2.0/24 1113 5. DDT Map Server at 192.0.2.211 sends a Map-Referral message for 1114 EID-prefix 10.16.2.0/24, action code MS-ACK to the DDT Map 1115 Resolver 1117 6. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 1118 pending request for 10.16.2.1 1120 7. site4 ETR for 10.16.2.0/24 receives Map-Request and sends Map- 1121 Reply to ITR2 1123 7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 1125 This example uses the cached MS-REFERRAL for 10.16.0.0/16 learned 1126 above to start the lookup process at the DDT Map-Server at 1127 192.0.2.211. The DDT Map Resolver proceeds as follows: 1129 1. Send DDT Map-Request (for 10.16.0.1) to 192.0.2.211; if the ITR- 1130 originated Encapsulated Map-Request had a LISP-SEC signature, it 1131 is included 1133 2. DDT Map Server at 192.0.2.211, which is authoritative for 1134 10.16.0.0/16, does not have a matching delegation for 10.16.0.1. 1135 It respondes with a Map-Referral message for 10.16.0.0/24, action 1136 code DELEGATION-HOLE to the DDT Map Resolver. The prefix 1137 10.16.0.0/24 is used because it is the least-specific prefix that 1138 does match the requested EID but does not match one of configured 1139 delegations (10.16.1.0/24 and 10.16.2.0/24). 1141 3. DDT Map Resolver receives the delegation, adds a negative 1142 referral cache entry for 10.16.0.0/24, dequeues the pending 1143 request for 10.16.0.1, and returns a negative Map-Reply to ITR2. 1145 8. Securing the database and message exchanges 1147 This section specifies the DDT security architecture that provides 1148 data origin authentication, data integrity protection, and XEID- 1149 prefix delegation. Global XEID-prefix authorization is out of the 1150 scope of this document. 1152 Each DDT node is configured with one or more public/private key 1153 pair(s) that are used to digitally sign referral records for XEID- 1154 prefix(es) that the DDT node is authoritative for. In other words, 1155 each public/private key pair is associated with the combination of a 1156 DDT node and the XEID-prefix that it is authoritative for. Every DDT 1157 node is also configured with the public keys of its children DDT 1158 nodes. By including public keys of target child DDT nodes in the 1159 Map-Referral records, and signing each record with the DDT node's 1160 private key, a DDT node can securely delegate sub-prefixes of its 1161 authoritative XEID-prefixes to its children DDT nodes. 1163 Map Resolvers are configured with one or more trusted public keys 1164 referred to as trust anchors. Trust anchors are used to authenticate 1165 the DDT security infrastructure. Map Resolvers can discover a DDT 1166 node's public key either by having it configured as a trust anchor, 1167 or by obtaining it from the node's parent as part of a signed Map- 1168 Referral. When a public key is obtained from a node's parent, it is 1169 considered trusted if it is signed by a trust anchor, or if it is 1170 signed by a key that was previously trusted. Typically, in a Map 1171 Resolver, the root DDT node public keys should be configured as trust 1172 anchors. Once a Map Resolver authenticates a public key it locally 1173 caches the key along with the associated DDT node RLOC and XEID- 1174 prefix for future use. 1176 8.1. XEID-prefix Delegation 1178 In order to delegate XEID sub-prefixes to its children, a parent DDT 1179 node signs its Map-Referrals. Every signed Map-Referral also 1180 includes the public keys associated with each child DDT node. Such a 1181 signature indicates that the parent node is delegating the specified 1182 XEID -prefix to a given child DDT node. The signature is also 1183 authenticating the public keys associated with the children nodes, 1184 and authorizing them to be used by the children DDT nodes to provide 1185 origin authentication and integrity protection for further 1186 delegations and mapping information of the XEID-prefix allocated to 1187 the DDT node. 1189 As a result, for a given XEID-prefix, a Map Resolver can form an 1190 authentication chain from a configured trust anchor (typically the 1191 root DDT node) to the leaf nodes (Map Servers). Map Resolvers 1192 leverage this authentication chain to verify the Map-Referral 1193 signatures while walking the DDT tree until they reach a Map Server 1194 authoritative for the given XEID-prefix. 1196 8.2. DDT node operation 1198 Upon receiving a Map-Request, the DDT node responds with a Map- 1199 Referral as specified in Section 5. For every record present in the 1200 Map-Referral, the DDT node also includes the public keys associated 1201 with the record's XEID-prefix and the RLOCs of the children DDT 1202 nodes. Each record contained in the Map-Referral is signed using the 1203 DDT node's private key. 1205 8.2.1. DDT public key revocation 1207 The node that owns a public key can also revoke that public key. For 1208 instance if a parent node advertises a public key for one of its 1209 child DDT nodes, the child DDT node can at a later time revoke that 1210 key. Since DDT nodes do not keep track of the Map Resolvers that 1211 query them, revocation is done in a pull model, where the Map 1212 Resolver is informed of the revocation of a key only when it queries 1213 the node that owns that key. If the parent DDT is configured to 1214 advertise this key, the parent node must also be signaled to remove 1215 the key from the records it advertises for the child DDT node; this 1216 is necessary to avoid further distribution of the revoked key. 1218 To securely revoke a key, the DDT node creates a new Record for the 1219 associated XEID-prefix and locator, including the revoked key with 1220 the R bit set. The DDT node must also include a signature in the 1221 Record that covers this record; this is computed using the private 1222 key corresponding to the key being revoked. Such a record is termed 1223 a "revocation record". By including this record in its Map- 1224 Referrals, the DDT node informs querying Map Resolvers about the 1225 revoked key. A digital signature computed with a revoked key can 1226 only be used to authenticate the revocation, and should not be used 1227 to validate any data. To prevent a compromised key from revoking 1228 other valid keys, a given key can only be used to sign a revocation 1229 for that specific key; it cannot be used to revoke other keys. This 1230 prevents the use of a compromised key to revoke other valid keys as 1231 described in [RFC5011]. A revocation record must be advertised for a 1232 period of time equal to or greater than the TTL value of the Record 1233 that initially advertisied the key, starting from the time that the 1234 advertisement of the key was stopped by removal from the parent DDT 1235 node. 1237 8.3. Map Server operation 1239 Similar to a DDT node, a Map Server is configured with one (or more) 1240 public/private key pairs that it must use to sign Map-Referrals. 1242 However unlike DDT nodes, Map Servers do not delegate prefixes and as 1243 a result they do not need to include keys in the Map-Referrals they 1244 generate. 1246 8.4. Map Resolver operation 1248 Upon receiving a Map-Referral, the Map Resolver must first verify the 1249 signature(s) by using a trust anchor, or a previously authenticated 1250 public key, associated with the DDT node sending the Map-Referral. 1251 If multiple authenticated keys are associated with the DDT node 1252 sending this Map-Referral, the Key Tag field of the signature can be 1253 used to select the right public key for verifying the signature. If 1254 the key tag matches more than one key associated with that DDT node, 1255 the Map Resolver must try verifying the signature with all matching 1256 keys. For every matching key that is found the Map Resolver must 1257 also verify that the key is authoritative for the XEID-prefix in the 1258 Map-Referral record. If such a key is found, the Map Resolver must 1259 use it to verify the associated signature in the record. If no 1260 matching key is found, or if none of the matching keys is 1261 authoritative for the XEID-prefix in the Map-Referral record, or if 1262 such a key is found but the signature is not valid the Map-Referral 1263 record is considered corrupted and must be discarded. This may be 1264 due to expired keys. The Map Resolver can try other siblings of this 1265 node if there is an alternative node authoritative for the same 1266 prefix. If not, the Map Resolver can query the DDT node's parent to 1267 retrieve a valid key. It is good practice to use a counter or timer 1268 to avoid repeating this process if the resolver cannot verify the 1269 signature after several trials. 1271 Once the signature is verified, the Map Resolver has verified the 1272 XEID-prefix delegation in the Map-Referral, and authenticated the 1273 public keys of the children DDT nodes. The Map Resolver must add 1274 these keys to the authenticated keys associated with each child DDT 1275 node and XEID-prefix. These keys are considered valid for the 1276 duration specified in the record's TTL field. 1278 9. Open Issues and Considerations 1280 There are a number of issues with the organization of the mapping 1281 database that need further investigation. Among these are: 1283 o Unlike in LISP-ALT (see [RFC6836]), DDT does not currently define 1284 a mechanism for propagating ETR-to-Map Server registration state. 1285 This requires DDT Map Servers to suppress returning negative Map- 1286 Reply messages for defined but unregistered XEID-prefixes to avoid 1287 loss of connectivity during partial ETR registration failures. 1288 Suppressing these messages may cause a delay for an ITR obtaining 1289 a mapping entry when such a failure is occurring. 1291 o Defining an interface to implement interconnection and/or 1292 interoperability with other mapping databases, such as LISP+ALT. 1294 o Additional key structures for use with LISP-DDT, such as to 1295 support additional EID formats as defined in [LCAF]. 1297 o Authentication of delegations between DDT nodes. 1299 o Possibility of a new, more general format for the Map-Referral 1300 messages to facilitate the use of LISP-DDT with additional DBID/ 1301 IID/EID combinations. Currently-defined packet formats should be 1302 considered to be preliminary and provisional until this issue has 1303 received greater attention. 1305 o Management of the DDT Map Resolver referral cache, in particular, 1306 detecting and removing outdated entries. 1308 The authors expect that experimentation on the LISP pilot network 1309 will help answer open questions surrounding these and other issues. 1311 10. IANA Considerations 1313 This document makes no request of the IANA. 1315 11. Security Considerations 1317 Section 8 describes a DDT security architecture that provides data 1318 origin authentication, data integrity protection, and XEID-prefix 1319 delegation within the DDT Infrastructure. 1321 Global XEID-prefix authorization is beyond the scope of this 1322 document, but the SIDR working group [RFC6480] is developing an 1323 infrastructure to support improved security of Internet routing. 1324 Further work is required to determine if SIDR's public key 1325 infrastructure (PKI) and the distributed repository system it uses 1326 for storing and disseminating PKI data objects may also be used by 1327 DDT devices to verifiably assert that they are the legitimate holders 1328 of a set of XEID prefixes. 1330 DDT security and [LISP-SEC] complement each other in securing the DDT 1331 infrastructure, Map-Referral messages and the Map-Request/Map-Reply 1332 protocol. In addition LISP-SEC can use the DDT public key 1333 infrastructure to secure the transport of LISP-SEC key material (the 1334 One-Time Key) from a Map-Resolver to the corresponding Map-Server. 1335 For this reason, when LISP-SEC is deployed in conjunction with a 1336 LISP-DDT mapping database and the path between Map-Resolver and Map- 1337 Server needs to be protected, DDT security should be enabled as well. 1339 12. References 1341 12.1. Normative References 1343 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1344 Address Format", 1345 . 1347 [RFC1035] Mockapetris, P., "Domain names - implementation and 1348 specification", STD 13, RFC 1035, November 1987. 1350 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1351 Hashing for Message Authentication", RFC 2104, 1352 February 1997. 1354 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1355 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1357 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 1358 Trust Anchors", STD 74, RFC 5011, September 2007. 1360 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1361 Locator/ID Separation Protocol (LISP)", RFC 6830, 1362 January 2013. 1364 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1365 Protocol (LISP) Map-Server Interface", RFC 6833, 1366 January 2013. 1368 12.2. Informative References 1370 [LISP-SEC] 1371 Maino, F., Ermagan, V., Cabellos, A., and D. Sanchez, 1372 "LISP-Security", 1373 . 1375 [LISP-TREE] 1376 Jakab, L., Cabellos, A., Coras, F., and D. Sauceez, "LISP- 1377 TREE", 10 2010, 1378 . 1380 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1381 E. Lear, "Address Allocation for Private Internets", 1382 BCP 5, RFC 1918, February 1996. 1384 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1385 Secure Internet Routing", RFC 6480, February 2012. 1387 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1388 "Locator/ID Separation Protocol Alternative Logical 1389 Topology (LISP+ALT)", RFC 6836, January 2013. 1391 Appendix A. Acknowledgments 1393 The authors with to express their thanks to Damien Saucez, Lorand 1394 Jakab, Olivier Bonaventure, Albert Cabellos-Asparicio, and FLorin 1395 Coras for work on LISP-TREE and LISP iterable mappings that inspired 1396 the hierarchical database structure and lookup iteration approach 1397 described in this document. Thanks also go to Dino Farinacci and 1398 Isidor Kouvelas for their implementation work; to Selina Heimlich and 1399 Srin Subramanian for testing; to Fabio Maino for work on security 1400 processing; and to Job Snijders, Glen Wiley, Neel Goyal, and Mike 1401 Gibbs for work on operational considerations and initial deployment 1402 of a prototype database infrastructure. Special thanks go to Jesper 1403 Skriver, Andrew Partan, and Noel Chiappa; all of whom have 1404 participated in (and put up with) seemingly endless hours of 1405 discussion of mapping database ideas, concepts, and issues. 1407 Appendix B. Map-Referral Message Format 1409 0 1 2 3 1410 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 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 |Type=6 | Reserved | Record Count | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | Nonce . . . | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | . . . Nonce | 1417 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | | Record TTL | 1419 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 R | Referral Count| EID mask-len | ACT |A|I| Reserved | 1421 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 c |SigCnt | Map Version Number | EID-AFI | 1423 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 r | EID-prefix ... | 1425 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | /| Priority | Weight | M Priority | M Weight | 1427 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | o | Unused Flags |R| Loc/LCAF-AFI | 1429 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | \| Locator ... | 1431 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 ACT: The "action" field of the mapping record in a Map-Referral 1433 message encodes 6 action types. The values for the action types are: 1435 NODE-REFERRAL (0): Sent by a DDT node with a child delegation which 1436 is authoritative for the EID. 1438 MS-REFERRAL (1): Sent by a DDT node that has information about Map 1439 Server(s) for the EID but it is not one of the Map Servers listed, 1440 i.e. the DDT-Node sending the referral is not a Map Server. 1442 MS-ACK (2): Sent by a DDT Map Server that has one or more ETR 1443 registered for the EID. 1445 MS-NOT-REGISTERED (3): Sent by a DDT Map Server that is configured 1446 for the EID-prefix but for which no ETRs are registered. 1448 DELEGATION-HOLE (4): Sent by an intermediate DDT node with 1449 authoritative configuration covering the requested EID but without 1450 any child delegation for the EID. Also sent by a DDT Map Server 1451 with authoritative configuration covering the requested EID but 1452 for which no specific site ETR is configured. 1454 NOT-AUTHORITATIVE (5): Sent by a DDT node that does not have 1455 authoritative configuration for the requested EID. The EID-prefix 1456 returned MUST be the original requested EID and the TTL MUST be 1457 set to 0. However, if such a DDT node has a child delegation 1458 covering the requested EID, it may choose to return NODE-REFERRAL 1459 or MS-REFERRAL as appropriate. A DDT Map Server with site 1460 information may choose to return of type MS-ACK or MS-NOT- 1461 REGISTERED as appropriate. 1463 Incomplete: The "I" bit indicates that a DDT node's referral-set of 1464 locators is incomplete and the receiver of this message should not 1465 cache the referral. A DDT sets the "incomplete" flag, the TTL, and 1466 the Action Type field as follows: 1468 ------------------------------------------------------------------- 1469 Type (Action field) Incomplete Referral-set TTL values 1470 ------------------------------------------------------------------- 1471 0 NODE-REFERRAL NO YES 1440 1473 1 MS-REFERRAL NO YES 1440 1475 2 MS-ACK * * 1440 1477 3 MS-NOT-REGISTERED * * 1 1479 4 DELEGATION-HOLE NO NO 15 1481 5 NOT-AUTHORITATIVE YES NO 0 1482 ------------------------------------------------------------------- 1484 *: The "Incomplete" flag setting on Map Server originated referral of 1485 MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map 1486 Server has the full peer Map Server configuration for the same 1487 prefix and has encoded the information in the mapping record. 1488 Incomplete bit is not set when the Map Server has encoded the 1489 information, which means the referral-set includes all the RLOCs 1490 of all Map Servers that serve the prefix. It is set when the Map 1491 Server has not encoded the Map Server set information. 1493 SigCnt: Indicates the number of signatures (sig section) present in 1494 the Record. If SigCnt is larger than 0, the signature information 1495 captured in a sig section as described in Appendix B.1 will be 1496 appended to the end of the record. The number of sig sections at the 1497 end of the Record must match the SigCnt. 1499 Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the 1500 record. If this is a LCAF AFI, the contents of the LCAF depend on 1501 the Type field of the LCAF. Security material are stored in LCAF 1502 Type 11. DDT nodes and Map Servers can use this LCAF Type to include 1503 public keys associated with their Child DDT nodes for a XEID-prefix 1504 referral record. LCAF types and formats are defined in [LCAF]. 1506 All the field descriptions are equivalent to those in the Map-Reply 1507 message, as defined in LISP [RFC6830]. Note, though, that the set of 1508 RLOCs correspond to the DDT node to be queried as a result of the 1509 referral not the RLOCs for an actual EID-to-RLOC mapping. 1511 B.1. SIG section 1513 If SigCnt field in the Map-Referral is not 0, the signature 1514 information is included at the end of captured in a sig section as 1515 described below. SigCnt counts the number of sig sections that 1516 appear at the end of the Record. 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 /| Original Record TTL | 1520 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 / | Signature Expiration | 1522 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 s | Signature Inception | 1524 i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 g | Key Tag | Sig Length | 1526 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 \ | Sig-Algorithm | Reserved | Reserved | 1528 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 \ ~ Signature ~ 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 Original Record TTL: The original Record TTL for this record that is 1533 covered by the signature. Record TTL is in minutes. 1535 Key Tag: An identifier to specify which key is used for this 1536 signature if more than one valid key exists for the signing DDT node. 1538 Sig Length: The length of the Signature field. 1540 Sig-Algorithm: The identifier of the cryptographic algorithm used for 1541 the signature. Default value is RSA-SHA1. 1543 Reserved: This field must be set to 0 on transmit and must be ignored 1544 on receipt. 1546 Signature Expiration and Inception: Specify the validity period for 1547 the signature. Each specify a date and time in the form of a 32-bit 1548 unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, 1549 ignoring leap seconds, in network byte order. 1551 Signature: Contains the cryptographic signature that covers the 1552 entire record. The Record TTL and the sig fields are set to zero for 1553 the purpose of computing the Signature 1555 Appendix C. Encapsulated Control Message Format 1557 0 1 2 3 1558 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 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 / | IPv4 or IPv6 Header | 1561 OH | (uses RLOC addresses) | 1562 \ | | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 / | Source Port = xxxx | Dest Port = 4342 | 1565 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 \ | UDP Length | UDP Checksum | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 LH |Type=8 |S|D| Reserved | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 / | IPv4 or IPv6 Header | 1571 IH | (uses RLOC or EID addresses) | 1572 \ | | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 / | Source Port = xxxx | Dest Port = yyyy | 1575 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 \ | UDP Length | UDP Checksum | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 LCM | LISP Control Message | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 "D" is the "DDT-originated" flag and is set by a DDT client to 1582 indicate that the receiver can and should return Map-Referral 1583 messages as appropriate. 1585 Authors' Addresses 1587 Vince Fuller 1589 Email: vaf@vaf.net 1591 Darrel Lewis 1592 Cisco Systems 1594 Email: darlewis@cisco.com 1596 Vina Ermagan 1597 Cisco Systems 1599 Email: vermagan@cisco.com 1601 Amit Jain 1602 Juniper Networks 1604 Email: atjain@juniper.net