idnits 2.17.1 draft-ietf-lisp-ddt-02.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 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 (October 13, 2014) is 3481 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 1344, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 1347, but no explicit reference was found in the text == Unused Reference: 'RFC4634' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'LISP-TREE' is defined on line 1372, 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: April 16, 2015 V. Ermagan 6 Cisco Systems 7 A. Jain 8 Juniper Networks 9 October 13, 2014 11 LISP Delegated Database Tree 12 draft-ietf-lisp-ddt-02.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 April 16, 2015. 42 Copyright Notice 44 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 61 3. Database organization . . . . . . . . . . . . . . . . . . . . 6 62 3.1. EID-prefix tree structure and instance IDs . . . . . . . 6 63 3.2. Configuring prefix delegation . . . . . . . . . . . . . . 7 64 3.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7 65 4. The Map-Referral message . . . . . . . . . . . . . . . . . . 7 66 4.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 8 67 4.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 8 68 4.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 9 69 5. DDT network elements and their operation . . . . . . . . . . 9 70 5.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 9 72 5.1.2. Missing delegation from an authoritative prefix . . . 10 73 5.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 10 74 5.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 10 75 5.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 10 76 5.3.2. Receiving and following referrals . . . . . . . . . . 11 77 5.3.3. Handling referral errors . . . . . . . . . . . . . . 13 78 5.3.4. Referral loop detection . . . . . . . . . . . . . . . 13 79 6. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 14 80 6.1. Map Resolver processing of ITR Map-Request . . . . . . . 14 81 6.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 14 82 6.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 14 83 6.2. Map Resolver processing of Map-Referral message . . . . . 15 84 6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 15 85 6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 17 86 6.3. DDT Node processing of DDT Map-Request message . . . . . 19 87 6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 88 6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 19 89 7. Example topology and request/referral following . . . . . . . 20 90 7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 22 91 7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . 23 92 7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 24 93 7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . 24 94 7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 . . . . 25 95 8. Securing the database and message exchanges . . . . . . . . . 25 96 8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 26 97 8.2. DDT node operation . . . . . . . . . . . . . . . . . . . 26 98 8.2.1. DDT public key revocation . . . . . . . . . . . . . . 27 99 8.3. Map Server operation . . . . . . . . . . . . . . . . . . 27 100 8.4. Map Resolver operation . . . . . . . . . . . . . . . . . 27 101 9. Open Issues and Considerations . . . . . . . . . . . . . . . 28 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 103 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 106 12.2. Informative References . . . . . . . . . . . . . . . . . 30 107 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 30 108 Appendix B. Map-Referral Message Format . . . . . . . . . . . . 31 109 B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 33 110 Appendix C. Encapsulated Control Message Format . . . . . . . . 34 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 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. 594 It is not clear exactly what else the DDT Map Resolver should do in 595 such cases; one possibility is to remove the pending request list 596 entry and send a negative Map-Reply to the original Map-Request 597 sender. Alternatively, if a DDT Map Resolver detects unexpected 598 behavior by a DDT node, it could mark that node as unusable in its 599 referral cache and update the pending request to try a different DDT 600 node if more than one is listed in the referral cache. In any case, 601 any prefix contained in a Map-Referral message that causes a referral 602 error (including a referral loop) is not saved in the DDT Map- 603 Resolver referral cache. 605 5.3.4. Referral loop detection 607 In response to a Map-Referral message with action code NODE-REFERRAL 608 or MS-REFERRAL, a DDT Map Resolver is directed to query a new set of 609 DDT node RLOCs that are expected to have more-specific XEID-prefix 610 information for the requested XEID. To prevent a possible "iteration 611 loop" (following referrals back-and-forth among a set of DDT nodes 612 without ever finding an answer), a DDT Map Resolver saves the last 613 received referral XEID-prefix for each pending request and checks 614 that a newly received NODE-REFERRAL or MS-REFERRAL message contains a 615 more-specific referral XEID-prefix; an exact or less-specific match 616 of the saved XEID-prefix indicates a referral loop. If a loop is 617 detected, the DDT Map Resolver handles the request as described in 618 Section 5.3.3. Otherwise, the Map Resolver saves the most recently 619 received referral XEID-prefix with the pending request when it 620 follows the referral. 622 As an extra measure to prevent referral loops, it is probably also 623 wise to limit the total number of referrals for any request to some 624 reasonable number; the exact value of that number will be determined 625 during experimental deployment of LISP-DDT but is bounded by the 626 maximum length of the XEID. 628 Note that when a DDT Map Resolver adds an entry to its lookup queue 629 and sends an initial Map-Request for an XEID, the queue entry has no 630 previous referral XEID-prefix; this means that the first DDT node 631 contacted by a DDT Map Resolver may provide a referral to anywhere in 632 the DDT hierarchy. This, in turn, allows a DDT Map Resolver to use 633 essentially any DDT node RLOCs for its initial cache entries and 634 depend on the initial referral to provide a good starting point for 635 Map-Requests; there is no need to configure the same set of root DDT 636 nodes on all DDT Map Resolvers. 638 6. Pseudo Code and Decision Tree diagrams 640 To aid in implementation, each of the major DDT Map Server and DDT 641 Map Resolver functions are described below, first using simple 642 "pseudo-code" and then in the form of a decision tree. 644 6.1. Map Resolver processing of ITR Map-Request 646 6.1.1. Pseudo-code summary 648 if ( request pending i.e., (ITR,EID) of request same ) { 649 replace old request with new & use new request nonce 650 for future requests 651 } else if ( no match in refcache ) { 652 return negative map-reply to ITR 653 } else if ( match type delegation hole ) { 654 return negative map-reply to ITR 655 } else if ( match type ms-ack ) { 656 fwd DDT request to map-server 657 } else { 658 store & fwd DDT request w/o OTK to node delegation 659 } 661 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 749 } 751 case MS_ACKNOWLEDGEMENT: 752 if ( OTK stripped ) { 753 if ( incomplete ) { 754 resend request with OTK 755 } else { 756 cache & resend request with OTK 757 } 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 781 +------------+ 782 | Is Request | No 783 | Pending? |----> Silently drop 784 +------------+ 785 | Yes 786 V 787 +------------------------------+ Yes 788 | Pfx less specific than last? |----> Silently drop 789 +------------------------------+ 790 |No 791 V 792 +---------------------------------------------------+ 793 | What is Map-Referral Type? |--UNKNOWN-+ 794 +---------------------------------------------------+ | 795 | | | | | | V 796 | | | | | DEL_HOLE DROP 797 | | | | MS_ACK | 798 | | | | | V 799 | | MS_REF NODE_REF | Cache & return 800 | | | | V negative map-reply 801 | | | | +---------+ 802 | NOT_AUTH | | | Was OTK | Yes 803 | | | | |Stripped?|----> Done 804 | | V V +---------+ 805 | | +------------+ | No 806 | | Yes | Pfx equal | V 807 MS_NOT_REGISTERED | +---| to last | +------------+ 808 | | | | used? | | Incomplete | Yes 809 | | | +------------+ | bit set? |---> Resend DDT 810 | V V |No +------------+ request 811 | +------------+ | |No with OTK 812 | | Gone | V | 813 | | Through | Cache & follow V 814 | | Root? | the referral Cache & resend DDT 815 | +------------+ request with OTK 816 | |No |Yes 817 | | | 818 | V V 819 | Goto root Send negative map-reply 820 V 821 +-----------+ Yes +-----------+ Yes 822 | Other MS |-----Follow other MS-------->|Incomplete |----> Dont cache 823 | not tried?| |bit set? | 824 | |----Send negative map-reply->| |----> Cache 825 +-----------+ No +-----------+ No 827 6.3. DDT Node processing of DDT Map-Request message 829 6.3.1. Pseudo-code summary 831 if ( I am not authoritative ) { 832 send map-referral NOT_AUTHORITATIVE with 833 incomplete bit set and ttl 0 834 } else if ( delegation exists ) { 835 if ( delegated map-servers ) { 836 send map-referral MS_REFERRAL with 837 ttl 'Default_DdtNode_Ttl' 838 } else { 839 send map-referral NODE_REFERRAL with 840 ttl 'Default_DdtNode_Ttl' 841 } 842 } else { 843 if ( eid in site) { 844 if ( site registered ) { 845 forward map-request to etr 846 if ( map-server peers configured ) { 847 send map-referral MS_ACKNOWLEDGEMENT with 848 ttl 'Default_Registered_Ttl' 849 } else { 850 send map-referral MS_ACKNOWLEDGEMENT with 851 ttl 'Default_Registered_Ttl' and incomplete bit set 852 } 853 } else { 854 if ( map-server peers configured ) { 855 send map-referral MS_NOT_REGISTERED with 856 ttl 'Default_Configured_Not_Registered_Ttl' 857 } else { 858 send map-referral MS_NOT_REGISTERED with 859 ttl 'Default_Configured_Not_Registered_Ttl' 860 and incomplete bit set 861 } 862 } 863 } else { 864 send map-referral DELEGATION_HOLE with 865 ttl 'Default_Negative_Referral_Ttl' 866 } 867 } 869 6.3.2. Decision tree diagram 870 +------------+ 871 | Am I | No 872 | Authori- |----> Return NOT_AUTHORITATIVE 873 | tative? | Incomplete = 1 874 +------------+ ttl = Default_DdtNode_Ttl 875 | 876 |Yes 877 | 878 V 879 +------------+ +------------+ 880 | Delegation | Yes | Delegations| Yes 881 | Exists? |---->| are map |----> Return MS_REFERRAL 882 | | | servers? | ttl = Default_DdtNode_Ttl 883 +------------+ +------------+ 884 | \ No 885 |No +--> Return NODE_REFERRAL 886 | ttl = Default_DdtNode_Ttl 887 V 888 +------------+ +------------+ +------------+ 889 | EID in | Yes | Site | Yes | Map-server | 890 | Site |---->| Registered?|----> Forward---->| peers | 891 | Config? | | | Map-request | configured?| 892 +------------+ +------------+ to ETR +------------+ 893 | | | | 894 | |No No| |Yes 895 | | | | 896 | | V V 897 | | Return MS_ACK Return MS_ACK 898 | V with INC=1 899 | +------------+ ttl=Default_Registered_Ttl 900 | | Map-server | Yes 901 | | peers |----> Return MS_NOT_REGISTERED 902 | | configured?| ttl = Default_Negative_Referral_Ttl 903 | +------------+ 904 | \ No 905 |No +--> Return MS_NOT_REGISTERED 906 | Incomplete = 1 907 V ttl = Default_Negative_Referral_Ttl 908 Return DELEGATION_HOLE 909 ttl = Default_Negative_Referral_Ttl 911 7. Example topology and request/referral following 913 To show how referrals are followed to find the RLOCs for a number of 914 EIDs, consider the following example EID topology for DBID=0, IID=0, 915 AFI=1, and EID=0/0 916 +---------------------+ +---------------------+ 917 | root1: 192.0.2.1 | | root2: 192.0.2.2 | 918 | authoritative: 0/0 | | authoritative: 0/0 | 919 +---------------------+ +---------------------+ 920 | \ / | 921 | \ / | 922 | / \ | 923 | / \ | 924 | | | | 925 V V V V 926 +--------------------------+ +--------------------------+ 927 | DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 | 928 | authoritative: 10.0.0.0/8| | authoritative: 10.0.0.0/8| 929 +--------------------------+ +--------------------------+ 930 | \ / | 931 | \ / | 932 | / \ | 933 | / \ | 934 | | | | 935 V V V V 936 +--------------------------+ +---------------------------+ 937 | Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 | 938 |authoritative: 10.0.0.0/12| |authoritative: 10.16.0.0/12| 939 | site1: 10.1.0.0/16 | +---------------------------+ 940 | site2: 10.2.0.0/16 | | | 941 +--------------------------+ | | 942 | | 943 | | 944 V V 945 +---------------------------+ +---------------------------+ 946 | Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 | 947 |authoritative: 10.16.0.0/16| |authoritative: 10.17.0.0/16| 948 | site3: 10.16.1.0/24 | | site5: 10.17.8.0/24 | 949 | site4: 10.16.2.0/24 | | site6: 10.17.9.0/24 | 950 +---------------------------+ +---------------------------+ 952 DDT nodes are configured for this "root" at IP addresses 192.0.2.1 953 and 192.0.2.2. DDT Map Resolvers are configured with default 954 referral cache entries to these addresses. 956 The root DDT nodes delegate 10.0.0/8 to two DDT nodes with IP 957 addresses 192.0.2.11 and 192.0.2.12. 959 The DDT nodes for 10.0.0.0/8 delegate 10.0.0.0/12 to a DDT Map Server 960 with RLOC 192.0.2.101 962 The DDT Map Server for 10.0.0.0/12 is configured to allow ETRs to 963 register the sub-prefixes 10.1.0.0/16 and 10.2.0.0/16 964 The DDT nodes for 10.0.0.0/8 also delegate 10.16.0.0/12 to a DDT node 965 with RLOC 192.0.2.201 967 The DDT node for 10.16.0.0/12 is further configured to delegate 968 10.16.0.0/16 to a DDT Map Server with RLOC 192.0.2.211 and 10.17.0.0/ 969 16 to a DDT Map Server with RLOC 192.0.2.221 971 The DDT Map Server for 10.16.0.0/16 is configured to allow ETRs to 972 register the sub-prefixes 10.16.1.0/24 and 10.16.2.0/24 974 The DDT Map Server for 10.17.0.0/16 is configured to allow ETRs to 975 register the sub-prefixes 10.17.8.0/24 and 10.17.9.0/24 977 7.1. Lookup of 10.1.1.1/32 by ITR1 979 The first example shows a DDT Map Resolver following a delegation 980 from the root to a DDT node followed by another delegation to a DDT 981 Map Server. 983 ITR1 sends an Encapsulated Map-Request for 10.1.1.1 to one of its 984 configured (DDT) Map Resolvers. The DDT Map Resolver proceeds as 985 follows: 987 1. Send DDT Map-Request (for 10.1.1.1) to one of the root DDT nodes, 988 192.0.2.1 or 192.0.2.2 990 2. Receive (and save in referral cache) Map-Referral for EID-prefix 991 10.0.0.0/8, action code NODE-REFERRAL, RLOC set (192.0.2.11, 992 192.0.2.12) 994 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 996 4. Receive (and save in referral cache) Map-Referral for EID-prefix 997 10.0.0.0/12, action code MS-REFERRAL, RLOC set (192.0.2.101) 999 5. Send DDT Map-Request to 192.0.2.101; if the ITR-originated 1000 Encapsulated Map-Request had a LISP-SEC signature, it is included 1002 6. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 1003 and forwards to a registered site1 ETR for 10.1.0.0/16 1005 7. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 1006 EID-prefix 10.1.0.0/16, action code MS-ACK to the DDT Map 1007 Resolver 1009 8. DDT Map Resolver receives Map-Referral message and dequeues the 1010 pending request for 10.1.1.1 1012 9. site1 ETR for 10.1.0.0/16 receives Map-Request forwarded by DDT 1013 Map Server and sends Map-Reply to ITR1 1015 7.2. Lookup of 10.17.8.1/32 by ITR2 1017 The next example shows a three-level delegation: root to first DDT 1018 node, first DDT node to second DDT node, second DDT node to DDT Map 1019 Server. 1021 ITR2 sends an Encapsulated Map-Request for 10.17.8.1 to one of its 1022 configured (DDT) Map Resolvers, which are different from those for 1023 ITR1. The DDT Map Resolver proceeds as follows: 1025 1. Send DDT Map-Request (for 10.17.8.1) to one of the root DDT 1026 nodes, 192.0.2.1 or 192.0.2.2 1028 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1029 10.0.0.0/8, action code NODE-REFERRAL, RLOC set (192.0.2.11, 1030 192.0.2.12) 1032 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 1034 4. Receive (and save in referral cache) Map-Referral for EID-prefix 1035 10.16.0.0/12, action code NODE-REFERRAL, RLOC set (192.0.2.201) 1037 5. Send DDT Map-Request to 192.0.2.201 1039 6. Receive (and save in referral cache) Map-Referral for EID-prefix 1040 10.17.0.0/16, action code MS-REFERRAL, RLOC set (192.0.2.221) 1042 7. Send DDT Map-Request to 192.0.2.221; if the ITR-originated 1043 Encapsulated Map-Request had a LISP-SEC signature, it is 1044 included 1046 8. DDT Map Server at 192.0.2.221 decapsulates the DDT Map-Request 1047 and forwards to a registered site5 ETR for 10.17.8.0/24 1049 9. DDT Map Server at 192.0.2.221 sends a Map-Referral message for 1050 EID-prefix 10.17.8.0/24, action code MS-ACK, to the DDT Map 1051 Resolver 1053 10. DDT Map Resolver receives Map-Referral(MS-ACK) message and 1054 dequeues the pending request for 10.17.8.1 1056 11. site5 ETR for 10.17.8.0/24 receives Map-Request forwarded by DDT 1057 Map Server and sends Map-Reply to ITR2 1059 7.3. Lookup of 10.2.2.2/32 by ITR1 1061 This example shows how a DDT Map Resolver uses a saved referral cache 1062 entry to skip the referral process and go directly to a DDT Map 1063 Server for a prefix that is similar to one previously requested. 1065 In this case, ITR1 uses the same Map Resolver used in example 1066 Section 7.1. It sends an Encapsulated Map-Request for 10.2.2.2 to 1067 that (DDT) Map Resolver. The DDT Map-Resolver finds an MS-REFERRAL 1068 cache entry for 10.0.0.0/12 with RLOC set (192.0.2.101) and proceeds 1069 as follows: 1071 1. Send DDT Map-Request (for 10.2.2.2) to 192.0.2.101; if the ITR- 1072 originated Encapsulated Map-Request had a LISP-SEC signature, it 1073 is included 1075 2. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 1076 and forwards to a registered site2 ETR for 10.2.0.0/16 1078 3. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 1079 EID-prefix 10.2.0.0/16, action code MS-ACK to the DDT Map 1080 Resolver 1082 4. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 1083 pending request for 10.2.2.2 1085 5. site2 ETR for 10.2.0.0/16 receives Map-Request and sends Map- 1086 Reply to ITR1 1088 7.4. Lookup of 10.16.2.1/32 by ITR2 1090 This example shows how a DDT Map Resolver uses a saved referral cache 1091 entry to start the referral process at a non-root, intermediate DDT 1092 node for a prefix that is similar to one previously requested. 1094 In this case, ITR2 asks the same Map Resolver used in example 1095 Section 7.2. It sends an Encapsulated Map-Request for 10.16.2.1 to 1096 that (DDT) Map Resolver, which finds a NODE-REFERRAL cache entry for 1097 10.16.0.0/12 with RLOC set (192.0.2.201). It proceeds as follows: 1099 1. Send DDT Map-Request (for 10.16.2.1) to 192.0.2.201 1101 2. Receive (and save in referral cache) Map-Referral for EID-prefix 1102 10.16.0.0/16, action code MS-REFERRAL, RLOC set (192.0.2.211) 1104 3. Send DDT Map-Request to 192.0.2.211; if the ITR-originated 1105 Encapsulated Map-Request had a LISP-SEC signature, it is included 1107 4. DDT Map Server at 192.0.2.211 decapsulates the DDT Map-Request 1108 and forwards to a registered site4 ETR for 10.16.2.0/24 1110 5. DDT Map Server at 192.0.2.211 sends a Map-Referral message for 1111 EID-prefix 10.16.2.0/24, action code MS-ACK to the DDT Map 1112 Resolver 1114 6. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 1115 pending request for 10.16.2.1 1117 7. site4 ETR for 10.16.2.0/24 receives Map-Request and sends Map- 1118 Reply to ITR2 1120 7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 1122 This example uses the cached MS-REFERRAL for 10.16.0.0/16 learned 1123 above to start the lookup process at the DDT Map-Server at 1124 192.0.2.211. The DDT Map Resolver proceeds as follows: 1126 1. Send DDT Map-Request (for 10.16.0.1) to 192.0.2.211; if the ITR- 1127 originated Encapsulated Map-Request had a LISP-SEC signature, it 1128 is included 1130 2. DDT Map Server at 192.0.2.211, which is authoritative for 1131 10.16.0.0/16, does not have a matching delegation for 10.16.0.1. 1132 It respondes with a Map-Referral message for 10.16.0.0/24, action 1133 code DELEGATION-HOLE to the DDT Map Resolver. The prefix 1134 10.16.0.0/24 is used because it is the least-specific prefix that 1135 does match the requested EID but does not match one of configured 1136 delegations (10.16.1.0/24 and 10.16.2.0/24). 1138 3. DDT Map Resolver receives the delegation, adds a negative 1139 referral cache entry for 10.16.0.0/24, dequeues the pending 1140 request for 10.16.0.1, and returns a negative Map-Reply to ITR2. 1142 8. Securing the database and message exchanges 1144 This section specifies the DDT security architecture that provides 1145 data origin authentication, data integrity protection, and XEID- 1146 prefix delegation. Global XEID-prefix authorization is out of the 1147 scope of this document. 1149 Each DDT node is configured with one or more public/private key 1150 pair(s) that are used to digitally sign referral records for XEID- 1151 prefix(es) that the DDT node is authoritative for. In other words, 1152 each public/private key pair is associated with the combination of a 1153 DDT node and the XEID-prefix that it is authoritative for. Every DDT 1154 node is also configured with the public keys of its children DDT 1155 nodes. By including public keys of target child DDT nodes in the 1156 Map-Referral records, and signing each record with the DDT node's 1157 private key, a DDT node can securely delegate sub-prefixes of its 1158 authoritative XEID-prefixes to its children DDT nodes. 1160 Map Resolvers are configured with one or more trusted public keys 1161 referred to as trust anchors. Trust anchors are used to authenticate 1162 the DDT security infrastructure. Map Resolvers can discover a DDT 1163 node's public key either by having it configured as a trust anchor, 1164 or by obtaining it from the node's parent as part of a signed Map- 1165 Referral. When a public key is obtained from a node's parent, it is 1166 considered trusted if it is signed by a trust anchor, or if it is 1167 signed by a key that was previously trusted. Typically, in a Map 1168 Resolver, the root DDT node public keys should be configured as trust 1169 anchors. Once a Map Resolver authenticates a public key it locally 1170 caches the key along with the associated DDT node RLOC and XEID- 1171 prefix for future use. 1173 8.1. XEID-prefix Delegation 1175 In order to delegate XEID sub-prefixes to its children, a parent DDT 1176 node signs its Map-Referrals. Every signed Map-Referral also 1177 includes the public keys associated with each child DDT node. Such a 1178 signature indicates that the parent node is delegating the specified 1179 XEID -prefix to a given child DDT node. The signature is also 1180 authenticating the public keys associated with the children nodes, 1181 and authorizing them to be used by the children DDT nodes to provide 1182 origin authentication and integrity protection for further 1183 delegations and mapping information of the XEID-prefix allocated to 1184 the DDT node. 1186 As a result, for a given XEID-prefix, a Map Resolver can form an 1187 authentication chain from a configured trust anchor (typically the 1188 root DDT node) to the leaf nodes (Map Servers). Map Resolvers 1189 leverage this authentication chain to verify the Map-Referral 1190 signatures while walking the DDT tree until they reach a Map Server 1191 authoritative for the given XEID-prefix. 1193 8.2. DDT node operation 1195 Upon receiving a Map-Request, the DDT node responds with a Map- 1196 Referral as specified in Section 5. For every record present in the 1197 Map-Referral, the DDT node also includes the public keys associated 1198 with the record's XEID-prefix and the RLOCs of the children DDT 1199 nodes. Each record contained in the Map-Referral is signed using the 1200 DDT node's private key. 1202 8.2.1. DDT public key revocation 1204 The node that owns a public key can also revoke that public key. For 1205 instance if a parent node advertises a public key for one of its 1206 child DDT nodes, the child DDT node can at a later time revoke that 1207 key. Since DDT nodes do not keep track of the Map Resolvers that 1208 query them, revocation is done in a pull model, where the Map 1209 Resolver is informed of the revocation of a key only when it queries 1210 the node that owns that key. If the parent DDT is configured to 1211 advertise this key, the parent node must also be signaled to remove 1212 the key from the records it advertises for the child DDT node; this 1213 is necessary to avoid further distribution of the revoked key. 1215 To securely revoke a key, the DDT node creates a new Record for the 1216 associated XEID-prefix and locator, including the revoked key with 1217 the R bit set. The DDT node must also include a signature in the 1218 Record that covers this record; this is computed using the private 1219 key corresponding to the key being revoked. Such a record is termed 1220 a "revocation record". By including this record in its Map- 1221 Referrals, the DDT node informs querying Map Resolvers about the 1222 revoked key. A digital signature computed with a revoked key can 1223 only be used to authenticate the revocation, and should not be used 1224 to validate any data. To prevent a compromised key from revoking 1225 other valid keys, a given key can only be used to sign a revocation 1226 for that specific key; it cannot be used to revoke other keys. This 1227 prevents the use of a compromised key to revoke other valid keys as 1228 described in [RFC5011]. A revocation record must be advertised for a 1229 period of time equal to or greater than the TTL value of the Record 1230 that initially advertisied the key, starting from the time that the 1231 advertisement of the key was stopped by removal from the parent DDT 1232 node. 1234 8.3. Map Server operation 1236 Similar to a DDT node, a Map Server is configured with one (or more) 1237 public/private key pairs that it must use to sign Map-Referrals. 1239 However unlike DDT nodes, Map Servers do not delegate prefixes and as 1240 a result they do not need to include keys in the Map-Referrals they 1241 generate. 1243 8.4. Map Resolver operation 1245 Upon receiving a Map-Referral, the Map Resolver must first verify the 1246 signature(s) by using a trust anchor, or a previously authenticated 1247 public key, associated with the DDT node sending the Map-Referral. 1248 If multiple authenticated keys are associated with the DDT node 1249 sending this Map-Referral, the Key Tag field of the signature can be 1250 used to select the right public key for verifying the signature. If 1251 the key tag matches more than one key associated with that DDT node, 1252 the Map Resolver must try verifying the signature with all matching 1253 keys. For every matching key that is found the Map Resolver must 1254 also verify that the key is authoritative for the XEID-prefix in the 1255 Map-Referral record. If such a key is found, the Map Resolver must 1256 use it to verify the associated signature in the record. If no 1257 matching key is found, or if none of the matching keys is 1258 authoritative for the XEID-prefix in the Map-Referral record, or if 1259 such a key is found but the signature is not valid the Map-Referral 1260 record is considered corrupted and must be discarded. This may be 1261 due to expired keys. The Map Resolver can try other siblings of this 1262 node if there is an alternative node authoritative for the same 1263 prefix. If not, the Map Resolver can query the DDT node's parent to 1264 retrieve a valid key. It is good practice to use a counter or timer 1265 to avoid repeating this process if the resolver cannot verify the 1266 signature after several trials. 1268 Once the signature is verified, the Map Resolver has verified the 1269 XEID-prefix delegation in the Map-Referral, and authenticated the 1270 public keys of the children DDT nodes. The Map Resolver must add 1271 these keys to the authenticated keys associated with each child DDT 1272 node and XEID-prefix. These keys are considered valid for the 1273 duration specified in the record's TTL field. 1275 9. Open Issues and Considerations 1277 There are a number of issues with the organization of the mapping 1278 database that need further investigation. Among these are: 1280 o Unlike in LISP-ALT (see [RFC6836]), DDT does not currently define 1281 a mechanism for propagating ETR-to-Map Server registration state. 1282 This requires DDT Map Servers to suppress returning negative Map- 1283 Reply messages for defined but unregistered XEID-prefixes to avoid 1284 loss of connectivity during partial ETR registration failures. 1285 Suppressing these messages may cause a delay for an ITR obtaining 1286 a mapping entry when such a failure is occurring. 1288 o Defining an interface to implement interconnection and/or 1289 interoperability with other mapping databases, such as LISP+ALT. 1291 o Additional key structures for use with LISP-DDT, such as to 1292 support additional EID formats as defined in [LCAF]. 1294 o Authentication of delegations between DDT nodes. 1296 o Possibility of a new, more general format for the Map-Referral 1297 messages to facilitate the use of LISP-DDT with additional DBID/ 1298 IID/EID combinations. Currently-defined packet formats should be 1299 considered to be preliminary and provisional until this issue has 1300 received greater attention. 1302 o Management of the DDT Map Resolver referral cache, in particular, 1303 detecting and removing outdated entries. 1305 The authors expect that experimentation on the LISP pilot network 1306 will help answer open questions surrounding these and other issues. 1308 10. IANA Considerations 1310 This document makes no request of the IANA. 1312 11. Security Considerations 1314 Section 8 describes a DDT security architecture that provides data 1315 origin authentication, data integrity protection, and XEID-prefix 1316 delegation within the DDT Infrastructure. 1318 Global XEID-prefix authorization is beyond the scope of this 1319 document, but the SIDR working group [RFC6480] is developing an 1320 infrastructure to support improved security of Internet routing. 1321 Further work is required to determine if SIDR's public key 1322 infrastructure (PKI) and the distributed repository system it uses 1323 for storing and disseminating PKI data objects may also be used by 1324 DDT devices to verifiably assert that they are the legitimate holders 1325 of a set of XEID prefixes. 1327 DDT security and [LISP-SEC] complement each other in securing the DDT 1328 infrastructure, Map-Referral messages and the Map-Request/Map-Reply 1329 protocol. In addition LISP-SEC can use the DDT public key 1330 infrastructure to secure the transport of LISP-SEC key material (the 1331 One-Time Key) from a Map-Resolver to the corresponding Map-Server. 1332 For this reason, when LISP-SEC is deployed in conjunction with a 1333 LISP-DDT mapping database and the path between Map-Resolver and Map- 1334 Server needs to be protected, DDT security should be enabled as well. 1336 12. References 1338 12.1. Normative References 1340 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1341 Address Format", 1342 . 1344 [RFC1035] Mockapetris, P., "Domain names - implementation and 1345 specification", STD 13, RFC 1035, November 1987. 1347 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1348 Hashing for Message Authentication", RFC 2104, February 1349 1997. 1351 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1352 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1354 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 1355 Trust Anchors", STD 74, RFC 5011, September 2007. 1357 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1358 Locator/ID Separation Protocol (LISP)", RFC 6830, January 1359 2013. 1361 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 1362 Protocol (LISP) Map-Server Interface", RFC 6833, January 1363 2013. 1365 12.2. Informative References 1367 [LISP-SEC] 1368 Maino, F., Ermagan, V., Cabellos, A., and D. Sanchez, 1369 "LISP-Security", 1370 . 1372 [LISP-TREE] 1373 Jakab, L., Cabellos, A., Coras, F., and D. Sauceez, "LISP- 1374 TREE", 10 2010, 1375 . 1377 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1378 E. Lear, "Address Allocation for Private Internets", BCP 1379 5, RFC 1918, February 1996. 1381 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1382 Secure Internet Routing", RFC 6480, February 2012. 1384 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1385 "Locator/ID Separation Protocol Alternative Logical 1386 Topology (LISP+ALT)", RFC 6836, January 2013. 1388 Appendix A. Acknowledgments 1390 The authors with to express their thanks to Damien Saucez, Lorand 1391 Jakab, Olivier Bonaventure, Albert Cabellos-Asparicio, and FLorin 1392 Coras for work on LISP-TREE and LISP iterable mappings that inspired 1393 the hierarchical database structure and lookup iteration approach 1394 described in this document. Thanks also go to Dino Farinacci and 1395 Isidor Kouvelas for their implementation work; to Selina Heimlich and 1396 Srin Subramanian for testing; to Fabio Maino for work on security 1397 processing; and to Job Snijders, Glen Wiley, Neel Goyal, and Mike 1398 Gibbs for work on operational considerations and initial deployment 1399 of a prototype database infrastructure. Special thanks go to Jesper 1400 Skriver, Andrew Partan, and Noel Chiappa; all of whom have 1401 participated in (and put up with) seemingly endless hours of 1402 discussion of mapping database 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 [RFC6830]. Note, though, that the set of 1506 RLOCs correspond to the DDT node to be queried as a result of the 1507 referral 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 1587 Email: vaf@vaf.net 1589 Darrel Lewis 1590 Cisco Systems 1592 Email: darlewis@cisco.com 1594 Vina Ermagan 1595 Cisco Systems 1597 Email: vermagan@cisco.com 1599 Amit Jain 1600 Juniper Networks 1602 Email: atjain@juniper.net