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