idnits 2.17.00 (12 Aug 2021) /tmp/idnits36717/draft-boucadair-lisp-triggered-map-request-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 17, 2015) is 2431 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-dnsop-edns-client-subnet has been published as RFC 7871 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental France Telecom 5 Expires: March 20, 2016 September 17, 2015 7 Triggered LISP Map-Request for Inter-Domain LISP Deployments 8 draft-boucadair-lisp-triggered-map-request-00 10 Abstract 12 It is commonly acknowledged that one of the issues raised by the 13 current Locator/ID Separation Protocol (LISP) design is that some 14 packets are likely to be lost in specific situations such as the 15 absence of a mapping entry in the mapping cache maintained by an ITR. 16 This issue is usually referred to as the "first packet loss" problem. 18 This document specifies a new LISP capability called Triggered Map- 19 Request which aims at addressing the "first packet loss" issue. 20 Also, it proposes to extend the LISP mapping entries with names 21 instead of achieving RLOC resolution based upon EID prefixes only. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 20, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Sample LISP Flow Example (Focus on the Source Side) . . . . . 3 65 3. Triggered Map-Request . . . . . . . . . . . . . . . . . . . . 4 66 4. Name as an EID: Updated Map-Request Message Format . . . . . 5 67 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 9.1. Normative references . . . . . . . . . . . . . . . . . . 14 73 9.2. Informative references . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Problem Statement 78 Locator/ID Separation Protocol (LISP, [RFC6830] ) operation relies 79 upon a mapping mechanism that is used by ingress/egress Tunnel 80 Routers (xTR) to forward traffic over the LISP network. It is 81 commonly acknowledged that some packets are likely to be lost in some 82 specific situations, such as the absence of a mapping entry in the 83 mapping cache maintained by an ITR. This problem is usually denoted 84 as the "first packet loss" issue. 86 Deploying LISP at the scale of the Internet heavily relies upon the 87 reliability of the LISP Mapping service. In particular, LISP 88 deployments at large scale must not degrade the level of quality as 89 currently provided by several decades of inter-domain routing 90 practices. 92 This document describes a solution to prepare the local mapping 93 service by anticipating the process of retrieving appropriate mapping 94 entries by ITRs of a LISP-enabled domain before a packet is actually 95 received by one of these ITRs. The LISP resolution result may remain 96 valid until a Map-Request reaches the ultimate ETR. 98 In addition to better accommodating the risk raised by the "first 99 packet loss" issue, this proposal reduces the delivery time that is 100 likely to be exacerbated by the two indirection levels (DNS and LISP) 101 together with the delay between the DNS resolution and the LISP 102 resolution. An example is shown in Section 2 for illustration 103 purposes. 105 This document focuses on the sole LISP inter-domain use case. As 106 such, the applicability of the proposed solution to other LISP uses 107 cases is out of the scope of this document. 109 In addition to the terms defined in [RFC6830] and [RFC6833], this 110 document makes uses of the following terms: 112 o Authoritative server: A DNS server that can answer authoritatively 113 for a given DNS query. 114 o Stub resolver: A resolver with minimum functionality, typically 115 used by endpoints that depend on a recursive resolver. 116 o Recursive resolver: A DNS server that accepts requests from one 117 resolver, and asks another resolver for the answer on behalf of 118 the first resolver. 120 Within this document, "Triggered Map-Request" is used to refer to a 121 Map-Request that is issued by an ITR based on some other events than 122 presenting a packet to the ITR forwarding engine. 124 2. Sample LISP Flow Example (Focus on the Source Side) 126 In order to further illustrate the issue related to the processing of 127 the first packet, let's consider this example in which Host1 wants to 128 communicate with a remote Host2, identified with 129 "host2.xyz.example.com". To do so, the following steps need to be 130 followed: 132 1 Host1 does a DNS lookup on host2.xyz.example.com. DNS queries (A 133 and/or AAAA) are issued by the local stub-resolver of Host1 and 134 forwarded to a pre-configured recursive resolver. 135 2 If the recursive resolver is the authoritative server for this 136 record, corresponding records are returned to the requesting stub 137 resolver, otherwise the request is forwarded upstream following 138 the normal DNS resolution procedure. 139 3 Once the recursive resolver receives a response from the DNS 140 infrastructure, it will relay it to the requesting resolver. As a 141 result of this procedure, A and/or AAAA records are returned to 142 the requesting host (i.e., Host1). 143 4 One of returned IPv4 or IPv6 addresses will be used by Host1 as 144 the destination EID. The locally assigned address of 145 host1.abc.example.com that belongs to the same address family is 146 used as the source EID. An IPv4 or IPv6 packet is then built and 147 forwarded through the LISP site as a normal IP packet until it 148 reaches an ITR. 149 5 Upon receipt of this packet by an ITR, because no mapping entry is 150 present for the destination EID, the ITR must invoke the LISP 151 Mapping Service to retrieve the appropriate mapping entry to 152 forward the packet outside the LISP leaf domain. According to 153 [RFC6830]: 155 5.1 When an alternate mapping system is not in use, the Map- 156 Request packet is routed through the underlying routing 157 system. Otherwise, the Map-Request packet is routed on an 158 alternate logical topology, for example, the [RFC6836] 159 database mapping system. In either case, when the Map- 160 Request arrives at one of the ETRs at the destination site, 161 it will process the packet as a control message. 162 5.2 The ETR looks at the destination EID of the Map-Request and 163 matches it against the prefixes stored in the EID-to-RLOC 164 mapping database maintained by the ETR. This is the list of 165 the EID-Prefixes the ETR is aware of, and which have been 166 assigned to the ETR is connected to. If there is no match, 167 the Map-Request is dropped. Otherwise, a LISP Map-Reply is 168 returned to the ITR. 169 5.3 The ITR receives the Map-Reply message, parses the message 170 (to check for format validity), and extracts the mapping 171 information from the packet. This information is stored in 172 the ITR's EID-to-RLOC mapping cache. Note that the map-cache 173 is an on-demand cache. Map-cache management by the ITR is 174 optimized to accommodate the ITR's resource constraints. 176 3. Triggered Map-Request 178 The rationale adopted by this document is that, instead of waiting 179 for a packet to be received by an ITR for issuing a Map-Request 180 message, the request can be triggered by other events so that the 181 local mapping cache is ready to process a packet that needs to be 182 forwarded outside a LISP leaf domain. This mode is called Triggered 183 Map-Request. 185 Triggered Map-Request has the same message format as a normal Map- 186 Request: that is, an external entity receiving a triggered Map- 187 Request or a normal Map-Request won't be able to make the difference 188 between the two messages. Whether the Map-Request is triggered by an 189 external entity or carried by a packet that needs to be forwarded 190 outside a LISP leaf domain reflects a context that is local to the 191 LISP domain that originates the Map-Request message. 193 Triggered Map-Request is meant to anticipate the receipt of a packet 194 that would have to be forwarded outside so that the ITR installs the 195 required state and proceed with the forwarding of the packet over a 196 LISP infrastructure accordingly. 198 An example of Triggered Map-Request is shown in Figure 1. This 199 example does not explicitly identify which entity has triggered the 200 Map-Request in Step (a). 202 +--------+ +-------+ +--------+ +-------+ 203 | Host | | ITR | | MR | | ETR | 204 +--------+ +-------+ +--------+ +-------+ 205 | | | | 206 | (a)Map-Request--->|-(b)Map-Request-->| | 207 | |<-(c)Map-Response-| | 208 |src=s_EID st=d_EID| | | 209 |--------(1)---------->|src=RLOC_itr dst=RLOC_etr| 210 | |==(2)==Encapsulated Packet======>| 211 | | | 212 | | | 213 |src=s_EID st=d_EID| | 214 |--------------------->|src=RLOC_itr dst=RLOC_etr| 215 | |======Encapsulated Packet=======>| 216 | | | 218 Figure 1: Triggered Map-Request: A Flow Example 220 An example of the use of triggered Map-Requests is detailed in 221 Section 5. 223 4. Name as an EID: Updated Map-Request Message Format 225 Figure 2 illustrates the changes that are required to the Map-Request 226 message in order to support names as EID identifiers. The design 227 relies upon the definition of one of the reserved bits for this 228 purpose. This bit is called the N-bit. When set (name-as-an-eid 229 bit), this is an indication that the EID-Prefix field must be 230 interpreted as a name. 232 Note: Another design option is to assign a dedicated value to the 233 "EID-Prefix-AFI" when a name is carried in the message. This 234 design option may offend some purists, since a name is usually not 235 considered as an address family. 237 OLD: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Nonce . . . | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | . . . Nonce | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Source-EID-AFI | Source EID Address ... | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | ... | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 / | Reserved | EID mask-len | EID-Prefix-AFI | 256 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 \ | EID-Prefix ... | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Map-Reply Record ... | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 NEW: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |Type=1 |A|M|P|S|p|s|N| Reserved | IRC | Record Count | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Nonce . . . | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | . . . Nonce | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Source-EID-AFI | Source EID Address ... | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | ... | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 / | Reserved | Name-Len | EID-Prefix-AFI | 280 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 \ | Name ... | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Map-Reply Record ... | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 2: Name as an EID 287 The "Reserved" bits MUST each be set to zero and MUST be ignored upon 288 receipt. 290 When this N-bit is set, the EID-Prefix-AFI MUST be set to zeros and 291 MUST be ignored upon receipt. Also, EID mask-len ( Name-Len) MUST 292 indicate the length of the enclosed "Name". Name is a domain name 293 (as per Section 3.1 of [RFC1035]) that contains one or more labels. 294 The Name encoding MUST follow the Name Syntax defined in 295 [RFC1035][RFC1123][RFC2181] and are represented in ASCII form. 297 5. Operation 299 The solution relies upon an extension to the DNS resolver (and 300 possibly a management platform) to trigger the sending of Map-Request 301 messages for a given destination EID (that is eventually encoded as a 302 name or an IP address/prefix) by all the ITRs deployed in a given 303 LISP-enabled domain. 305 This document assumes that in the context of inter-domain LISP 306 deployment use cases, interconnection between Mapping Systems is 307 required for the sake of global reachability. Furthermore, these 308 Mapping Systems are supposed to deploy massive cache systems so that 309 they can service resolution requests as close to the leaf LISP domain 310 as possible, rather than forwarding the Map-Request until it reaches 311 the ultimate ETR. Furthermore, some service innovation can be 312 encouraged by coupling DNS/LISP Mapping services. 314 The proposed procedure also takes into account CDN environments, at 315 the benefit of relaxing the constraint on the traffic increase on 316 interconnection links, thereby minimizing the need for soliciting 317 inter-domain LISP forwarding. 319 The solution also acknowledges that DNS replies can be policy-based. 320 In particular, this document does not interfere with DNS policies 321 that are enforced on a subnet basis (e.g., 322 [I-D.ietf-dnsop-edns-client-subnet]). When the Mapping System has to 323 undertake a DNS resolution, it will supply the same subnet value as 324 the one that would be indicated by a host connected to the leaf LISP 325 network. Doing so ensures that the address that will be returned to 326 the requesting host during the DNS resolution will match a mapping 327 entry that will be retrieved when Triggered Map-Request operation is 328 enabled. 330 The detailed procedure to be implemented to minimize the risk of the 331 "first packet loss" issue is specified hereafter: 333 1 (Inter-domain) ITRs MUST support a configuration parameter to 334 enable/disable the Triggered-Map-Request procedure. The default 335 value of this parameter is "Disabled". 337 2 All (inter-domain) ITRs MUST subscribe to a well-known multicast 338 group (@MCAST) and listen to port 4342 (default port number). 340 2.1 The use of multicast transport will help ITRs of the 341 different domains to maintain the same database. 343 2.2 Also, it does not interfere with the underlying routing and 344 forwarding policies that are configured locally. Whatever 345 the ITR that will be selected when forwarding an outgoing 346 packet, that ITR has issued a triggered Map-Request. 348 3 The DNS resolver is configured with the same @MCAST. If a 349 different port than port number 4342 is used, this port number 350 MUST be explicitly configured on the recursive DNS resolver. 352 4 A recursive DNS resolver within a LISP-enabled domain is updated 353 with one of the following capabilities. The decision about which 354 one to enable is deployment-specific. This decision will help 355 identifying which DNS forwarders will be impacted. 357 4.1 When receiving a DNS query from a stub-resolver, duplicate 358 that query and forward the duplicate to @MCAST:4342. The 359 original query is forwarded according to normal DNS 360 procedures (see the example shown in Figure 3). 362 This query is duplicated as close to the stub-resolver as 363 possible so that the LISP resolution process can occur while 364 the DNS resolution is in progress. 366 4.1.1 If the recursive resolver is the authoritative server 367 for this record, or the authoritative server is within 368 the local LISP domain, or a cache is invoked for that 369 name, then corresponding records are returned to the 370 requesting stub resolver following normal DNS 371 procedures. Packets will remain within the same LISP 372 domain. (Inter-domain) ITRs won't be solicited for 373 this communication. 375 4.1.2 Otherwise, the request is forwarded upstream following 376 the normal DNS resolution procedure. In addition, the 377 DNS recursive resolver MUST duplicate the query and 378 forward it to @MCAST:4342. 380 4.1.3 Upon receipt of the DNS query, an ITR will build a 381 Map-Request with a name (Section 4). This triggered 382 Map-Request is then forwarded to a Map-Resolver. If 383 the Map-Resolver is updated to support the capability 384 to associate a name with a mapping entry, it can make 385 a query based on the name carried in the Map-Request. 386 If not, the Map-Resolver must proceed first with a DNS 387 resolution locally and then the LISP resolution. 389 +--------+ +--------+ 390 | Host | |Resolver| 391 +--------+ +--------+ 392 | | 393 |Query |Query 394 |---------->|----> 395 | | Triggered 396 |Response |(a)Query->|-(b)Map-Request-->| 397 |<----------| |<-(c)Map-Response-| 398 | | | 399 | +-------+ +--------+ +-------+ 400 | | ITR | | MR | | ETR | 401 | +-------+ +--------+ +-------+ 402 | | | 403 |src=s_EID st=d_EID| | 404 |--------(1)---------->|src=RLOC_itr dst=RLOC_etr| 405 | |==(2)==Encapsulated Packet======>| 406 | | | 407 | | | 408 |src=s_EID st=d_EID| | 409 |--------------------->|src=RLOC_itr dst=RLOC_etr| 410 | |======Encapsulated Packet=======>| 411 | | | 413 Figure 3: Processing Triggered Map-Request: Close to the Stub- 414 resolver 416 4.2 When forwarding a DNS response to another DNS server, 417 duplicate that response and forward the duplicate to 418 @MCAST:4342. The original response is forwarded according to 419 normal DNS procedures (see the example shown in Figure 4). 421 The farthest DNS resolver of a leaf LISP network (i.e., a 422 resolver that forwards DNS queries outside a LISP domain) is 423 updated to fork a query for DNS records that cannot be 424 serviced locally, either because the authoritative server 425 belongs to the local LISP domain or because there is a cache 426 platform that is enabled in the local LISP domain. This DNS 427 Query is carried into a Triggered Map-Request message that is 428 forwarded to all the ITRs of that LISP domain. Concretely: 430 4.2.1 If the recursive resolver is the authoritative server 431 for this record, or the authoritative server is within 432 the local domain, or a cache is invoked for that name, 433 then corresponding records are returned to the 434 requesting stub resolver following normal DNS 435 procedures. Packets will remain within the same LISP 436 domain. (Inter-domain) ITRs won't be solicited for 437 this communication. 439 4.2.2 Otherwise, the request is forwarded upstream following 440 the normal DNS resolution procedure. In addition, the 441 DNS recursive resolver MUST duplicate the DNS response 442 and forward it to @MCAST:4342. 444 +--------+ +--------+ +---- 445 | Host | |Resolver| ... |Resolver 446 +--------+ +--------+ +------- 447 | | | 448 |Query |Query | 449 |---------->|-----..------------->| 450 | | Response| 451 | |<-----..-------------| 452 |Response | |<--Response--| 453 |<----------| | Triggered 454 | |--Map-Request->| 455 | |<-Map-Response>| 456 | | | 457 | +-------+ +--------+ +-------+ 458 | | ITR | | MR | | ETR | 459 | +-------+ +--------+ +-------+ 460 | | | 461 |src=s_EID st=d_EID| | 462 |------------------->|src=RLOC_itr dst=RLOC_etr| 463 | |======Encapsulated Packet===>| 464 | | | 465 | | | 466 |src=s_EID st=d_EID| | 467 |------------------->|src=RLOC_itr dst=RLOC_etr| 468 | |======Encapsulated Packet===>| 469 | | | 471 Figure 4: Processing Triggered Map-Request: Far from to the Stub- 472 Resolver 474 4.3 When forwarding a DNS query to another DNS server, build a 475 corresponding Triggered Map-Request from the contents of the 476 initial DNS query message. The request is then forwarded to 477 @MCAST:4342. The original query is forwarded according to 478 normal DNS procedures (see the example shown in Figure 5). 480 4.3.1: This procedure is similar to the one described in 481 Bullet 4.1. The only difference is that, instead of 482 forking a DNS message, appropriate Triggered Map- 483 Request messages are generated. The DNS resolvers 484 rely upon the contents of the DNS query to build the 485 Triggered Map-Request message; especially, the 486 destination EID is set to the addresses (IPv4 and/or 487 IPv6) that were included in the DNS response(s). 488 Furthermore, the Map-Request message uses the format 489 defined in Section 4 to set the destination EID. 491 4.3.2: Upon receipt of the Map-Request that carries a name, 492 an ITR will froward the request to its Map-Resolvers. 493 If the Map-Resolver is updated to support the 494 capability to associate a name with a mapping entry, 495 then it can initiate a query based on the name 496 carried in the Map-Request. If not, the Map-Resolver 497 must proceed first to DNS resolution locally and then 498 a LISP resolution. 500 +--------+ +--------+ 501 | Host | |Resolver| 502 +--------+ +--------+ 503 | | 504 |Query |Query 505 |------->|----> 506 | | 507 |Response|Map-Request->|-(b)Map-Request-->| 508 |<-------| |<-(c)Map-Response-| 509 | | | 510 | +-------+ +--------+ +-------+ 511 | | ITR | | MR | | ETR | 512 | +-------+ +--------+ +-------+ 513 | | | 514 |src=s_EID st=d_EID| | 515 |--------(1)---------->|src=RLOC_itr dst=RLOC_etr| 516 | |==(2)==Encapsulated Packet======>| 517 | | | 518 | | | 519 |src=s_EID st=d_EID| | 520 |--------------------->|src=RLOC_itr dst=RLOC_etr| 521 | |======Encapsulated Packet=======>| 522 | | | 524 Figure 5: Processing Triggered Map-Request: Close to the Stub- 525 Resolver 527 4.4 When forwarding a DNS response to another DNS server, trigger 528 a corresponding Map-Request that is formed after the contents 529 of the said DNS response. The request is then forwarded to 530 @MCAST:4342. The original response is forwarded according to 531 normal DNS procedures (see the example shown in Figure 6). 533 4.4.1: This procedure is similar to the one described in 534 Bullet 4.2. The only difference is that, instead of 535 forking a DNS message, appropriate Map-Request 536 messages are generated. The DNS resolver relies upon 537 the content of the DNS response to build the Map- 538 Request message; especially, the destination EID is 539 set to the addresses (IPv4 and/or IPv6) that were 540 included in the DNS response(s). 542 +--------+ +--------+ +---- 543 | Host | |Resolver| ... |Resolver 544 +--------+ +--------+ +------- 545 | | | 546 |Query |Query | 547 |---------->|-----..------------->| 548 | | Response| 549 | |<-----..-------------| 550 |Response | |<-Map-Request-| 551 |<----------| | Triggered 552 | |--Map-Request->| 553 | |<-Map-Response-| 554 | | | 555 | +-------+ +--------+ +-------+ 556 | | ITR | | MR | | ETR | 557 | +-------+ +--------+ +-------+ 558 | | | 559 |src=s_EID st=d_EID| | 560 |------------------->|src=RLOC_itr dst=RLOC_etr| 561 | |======Encapsulated Packet===>| 562 | | | 563 | | | 564 |src=s_EID st=d_EID| | 565 |------------------->|src=RLOC_itr dst=RLOC_etr| 566 | |======Encapsulated Packet===>| 567 | | | 569 Figure 6: Processing Triggered Map-Request: Far from to the Stub- 570 resolver 572 5 Subsequent packets associated with the same flow are handled 573 locally (i.e., normal LISP operation applies). 575 6. Security Considerations 577 Security considerations discussed in [RFC6830] and [RFC6833] should 578 be taken into account. 580 7. IANA Considerations 582 To be completed. 584 8. Acknowledgments 586 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 587 009-X. 589 9. References 591 9.1. Normative references 593 [RFC1035] Mockapetris, P., "Domain names - implementation and 594 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 595 November 1987, . 597 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 598 Application and Support", STD 3, RFC 1123, 599 DOI 10.17487/RFC1123, October 1989, 600 . 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, 604 DOI 10.17487/RFC2119, March 1997, 605 . 607 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 608 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 609 . 611 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 612 Locator/ID Separation Protocol (LISP)", RFC 6830, 613 DOI 10.17487/RFC6830, January 2013, 614 . 616 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 617 Protocol (LISP) Map-Server Interface", RFC 6833, 618 DOI 10.17487/RFC6833, January 2013, 619 . 621 9.2. Informative references 623 [I-D.ietf-dnsop-edns-client-subnet] 624 Contavalli, C., Gaast, W., Lawrence, D., and W. Kumari, 625 "Client Subnet in DNS Queries", draft-ietf-dnsop-edns- 626 client-subnet-03 (work in progress), August 2015. 628 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 629 "Locator/ID Separation Protocol Alternative Logical 630 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 631 January 2013, . 633 Authors' Addresses 635 Mohamed Boucadair 636 France Telecom 637 Rennes 35000 638 France 640 EMail: mohamed.boucadair@orange.com 642 Christian Jacquenet 643 France Telecom 644 Rennes 35000 645 France 647 EMail: christian.jacquenet@orange.com