<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY % RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc rfcedstyle="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<rfc category="exp" docName="draft-boucadair-lisp-triggered-map-request-00"
     ipr="trust200902">
  <front>
    <title abbrev="Triggered Map-Request">Triggered LISP Map-Request for
    Inter-Domain LISP Deployments</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <date day="" month="" year="" />

    <area>Internet</area>

    <keyword>IPv4 service continuity</keyword>

    <keyword>IPv4 address exhaustion</keyword>

    <keyword>Service Availability</keyword>

    <keyword>Address sharing</keyword>

    <keyword>IPv6</keyword>

    <keyword>Reliability</keyword>

    <keyword>IPv4 over IPv6</keyword>

    <abstract>
      <t>It is commonly acknowledged that one of the issues raised by the
      current Locator/ID Separation Protocol (LISP) design is that some
      packets are likely to be lost in specific situations such as the absence
      of a mapping entry in the mapping cache maintained by an ITR. This issue
      is usually referred to as the "first packet loss" problem.</t>

      <t>This document specifies a new LISP capability called Triggered
      Map-Request which aims at addressing the "first packet loss" issue.
      Also, it proposes to extend the LISP mapping entries with names instead
      of achieving RLOC resolution based upon EID prefixes only.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Problem Statement">
      <t>Locator/ID Separation Protocol (LISP, <xref target="RFC6830"></xref>
      ) operation relies upon a mapping mechanism that is used by
      ingress/egress Tunnel Routers (xTR) to forward traffic over the LISP
      network. It is commonly acknowledged that some packets are likely to be
      lost in some specific situations, such as the absence of a mapping entry
      in the mapping cache maintained by an ITR. This problem is usually
      denoted as the "first packet loss" issue.</t>

      <t>Deploying LISP at the scale of the Internet heavily relies upon the
      reliability of the LISP Mapping service. In particular, LISP deployments
      at large scale must not degrade the level of quality as currently
      provided by several decades of inter-domain routing practices.</t>

      <t>This document describes a solution to prepare the local mapping
      service by anticipating the process of retrieving appropriate mapping
      entries by ITRs of a LISP-enabled domain before a packet is actually
      received by one of these ITRs. The LISP resolution result may remain
      valid until a Map-Request reaches the ultimate ETR.</t>

      <t>In addition to better accommodating the risk raised by the "first
      packet loss" issue, this proposal reduces the delivery time that is
      likely to be exacerbated by the two indirection levels (DNS and LISP)
      together with the delay between the DNS resolution and the LISP
      resolution. An example is shown in <xref target="issue"></xref> for
      illustration purposes.</t>

      <t>This document focuses on the sole LISP inter-domain use case. As
      such, the applicability of the proposed solution to other LISP uses
      cases is out of the scope of this document.</t>

      <t>In addition to the terms defined in <xref target="RFC6830"></xref>
      and <xref target="RFC6833"></xref>, this document makes uses of the
      following terms:<?rfc subcompact="yes" ?><list style="symbols">
          <t>Authoritative server: A DNS server that can answer
          authoritatively for a given DNS query.</t>

          <t>Stub resolver: A resolver with minimum functionality, typically
          used by endpoints that depend on a recursive resolver.</t>

          <t>Recursive resolver: A DNS server that accepts requests from one
          resolver, and asks another resolver for the answer on behalf of the
          first resolver.</t>
        </list></t>

      <t><?rfc subcompact="no" ?>Within this document, "Triggered Map-Request"
      is used to refer to a Map-Request that is issued by an ITR based on some
      other events than presenting a packet to the ITR forwarding engine.</t>
    </section>

    <section anchor="issue"
             title="Sample LISP Flow Example (Focus on the Source Side)">
      <t>In order to further illustrate the issue related to the processing of
      the first packet, let's consider this example in which Host1 wants to
      communicate with a remote Host2, identified with
      "host2.xyz.example.com". To do so, the following steps need to be
      followed:<?rfc subcompact="yes" ?></t>

      <t><list style="format %d">
          <t>Host1 does a DNS lookup on host2.xyz.example.com. DNS queries (A
          and/or AAAA) are issued by the local stub-resolver of Host1 and
          forwarded to a pre-configured recursive resolver.</t>

          <t>If the recursive resolver is the authoritative server for this
          record, corresponding records are returned to the requesting stub
          resolver, otherwise the request is forwarded upstream following the
          normal DNS resolution procedure.</t>

          <t>Once the recursive resolver receives a response from the DNS
          infrastructure, it will relay it to the requesting resolver. As a
          result of this procedure, A and/or AAAA records are returned to the
          requesting host (i.e., Host1).</t>

          <t>One of returned IPv4 or IPv6 addresses will be used by Host1 as
          the destination EID. The locally assigned address of
          host1.abc.example.com that belongs to the same address family is
          used as the source EID. An IPv4 or IPv6 packet is then built and
          forwarded through the LISP site as a normal IP packet until it
          reaches an ITR.</t>

          <t>Upon receipt of this packet by an ITR, because no mapping entry
          is present for the destination EID, the ITR must invoke the LISP
          Mapping Service to retrieve the appropriate mapping entry to forward
          the packet outside the LISP leaf domain. According to <xref
          target="RFC6830"></xref>:<list style="format 5.%d">
              <t>When an alternate mapping system is not in use, the
              Map-Request packet is routed through the underlying routing
              system. Otherwise, the Map-Request packet is routed on an
              alternate logical topology, for example, the <xref
              target="RFC6836"></xref> database mapping system. In either
              case, when the Map-Request arrives at one of the ETRs at the
              destination site, it will process the packet as a control
              message.</t>

              <t>The ETR looks at the destination EID of the Map-Request and
              matches it against the prefixes stored in the EID-to-RLOC
              mapping database maintained by the ETR. This is the list of the
              EID-Prefixes the ETR is aware of, and which have been assigned
              to the ETR is connected to. If there is no match, the
              Map-Request is dropped. Otherwise, a LISP Map-Reply is returned
              to the ITR.</t>

              <t>The ITR receives the Map-Reply message, parses the message
              (to check for format validity), and extracts the mapping
              information from the packet. This information is stored in the
              ITR's EID-to-RLOC mapping cache. Note that the map-cache is an
              on-demand cache. Map-cache management by the ITR is optimized to
              accommodate the ITR's resource constraints.</t>
            </list></t>
        </list><?rfc subcompact="no" ?></t>
    </section>

    <section anchor="trig" title="Triggered Map-Request">
      <t>The rationale adopted by this document is that, instead of waiting
      for a packet to be received by an ITR for issuing a Map-Request message,
      the request can be triggered by other events so that the local mapping
      cache is ready to process a packet that needs to be forwarded outside a
      LISP leaf domain. This mode is called Triggered Map-Request.</t>

      <t>Triggered Map-Request has the same message format as a normal
      Map-Request: that is, an external entity receiving a triggered
      Map-Request or a normal Map-Request won't be able to make the difference
      between the two messages. Whether the Map-Request is triggered by an
      external entity or carried by a packet that needs to be forwarded
      outside a LISP leaf domain reflects a context that is local to the LISP
      domain that originates the Map-Request message.</t>

      <t>Triggered Map-Request is meant to anticipate the receipt of a packet
      that would have to be forwarded outside so that the ITR installs the
      required state and proceed with the forwarding of the packet over a LISP
      infrastructure accordingly.</t>

      <t>An example of Triggered Map-Request is shown in <xref
      target="ex"></xref>. This example does not explicitly identify which
      entity has triggered the Map-Request in Step (a).</t>

      <t><figure anchor="ex" title="Triggered Map-Request: A Flow Example">
          <artwork align="center"><![CDATA[+--------+             +-------+         +--------+     +-------+
|  Host  |             |  ITR  |         |   MR   |     |  ETR  |
+--------+             +-------+         +--------+     +-------+
    |                      |                  |              |            
    |    (a)Map-Request--->|-(b)Map-Request-->|              |
    |                      |<-(c)Map-Response-|              |
    |src=s_EID     st=d_EID|                  |              |
    |--------(1)---------->|src=RLOC_itr         dst=RLOC_etr|
    |                      |==(2)==Encapsulated Packet======>|
    |                      |                                 |
    |                      |                                 |  
    |src=s_EID     st=d_EID|                                 |
    |--------------------->|src=RLOC_itr         dst=RLOC_etr|
    |                      |======Encapsulated Packet=======>|
    |                      |                                 |
]]></artwork>
        </figure>An example of the use of triggered Map-Requests is detailed
      in <xref target="proc"></xref>.</t>
    </section>

    <section anchor="message"
             title="Name as an EID: Updated Map-Request Message Format">
      <t><xref target="neid"></xref> illustrates the changes that are required
      to the Map-Request message in order to support names as EID identifiers.
      The design relies upon the definition of one of the reserved bits for
      this purpose. This bit is called the N-bit. When set (name-as-an-eid
      bit), this is an indication that the EID-Prefix field must be
      interpreted as a name. <list style="empty">
          <t>Note: Another design option is to assign a dedicated value to the
          "EID-Prefix-AFI" when a name is carried in the message. This design
          option may offend some purists, since a name is usually not
          considered as an address family.</t>
        </list></t>

      <t><figure anchor="neid" title="Name as an EID">
          <artwork><![CDATA[OLD: 
        0                   1                   2                   3
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=1 |A|M|P|S|p|s|    Reserved     |   IRC   | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |   Source EID Address  ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-Prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-Prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW:
        0                   1                   2                   3
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=1 |A|M|P|S|p|s|N|  Reserved     |   IRC   | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |   Source EID Address  ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | Name-Len      |       EID-Prefix-AFI          |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                           Name  ...                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure></t>

      <t>The "Reserved" bits MUST each be set to zero and MUST be ignored upon
      receipt.</t>

      <t>When this N-bit is set, the EID-Prefix-AFI MUST be set to zeros and
      MUST be ignored upon receipt. Also, EID mask-len ( Name-Len) MUST
      indicate the length of the enclosed "Name". Name is a domain name (as
      per Section 3.1 of <xref target="RFC1035"></xref>) that contains one or
      more labels. The Name encoding MUST follow the Name Syntax defined in
      <xref target="RFC1035"></xref><xref target="RFC1123"></xref><xref
      target="RFC2181"></xref> and are represented in ASCII form.<!--adjouter une note pour expliquer que le flag bit peut ?tre eviter si on red?finit le champ pref/name. Le bit N assure une "backward-compatibilit?"--></t>
    </section>

    <section anchor="proc" title="Operation">
      <t>The solution relies upon an extension to the DNS resolver (and
      possibly a management platform) to trigger the sending of Map-Request
      messages for a given destination EID (that is eventually encoded as a
      name or an IP address/prefix) by all the ITRs deployed in a given
      LISP-enabled domain.</t>

      <t>This document assumes that in the context of inter-domain LISP
      deployment use cases, interconnection between Mapping Systems is
      required for the sake of global reachability. Furthermore, these Mapping
      Systems are supposed to deploy massive cache systems so that they can
      service resolution requests as close to the leaf LISP domain as
      possible, rather than forwarding the Map-Request until it reaches the
      ultimate ETR. Furthermore, some service innovation can be encouraged by
      coupling DNS/LISP Mapping services.</t>

      <t>The proposed procedure also takes into account CDN environments, at
      the benefit of relaxing the constraint on the traffic increase on
      interconnection links, thereby minimizing the need for soliciting
      inter-domain LISP forwarding.</t>

      <t>The solution also acknowledges that DNS replies can be policy-based.
      In particular, this document does not interfere with DNS policies that
      are enforced on a subnet basis (e.g., <xref
      target="I-D.ietf-dnsop-edns-client-subnet"></xref>). When the Mapping
      System has to undertake a DNS resolution, it will supply the same subnet
      value as the one that would be indicated by a host connected to the leaf
      LISP network. Doing so ensures that the address that will be returned to
      the requesting host during the DNS resolution will match a mapping entry
      that will be retrieved when Triggered Map-Request operation is
      enabled.</t>

      <t>The detailed procedure to be implemented to minimize the risk of the
      "first packet loss" issue is specified hereafter:</t>

      <t><list style="format %d">
          <t>(Inter-domain) ITRs MUST support a configuration parameter to
          enable/disable the Triggered-Map-Request procedure. The default
          value of this parameter is "Disabled".</t>

          <t>All (inter-domain) ITRs MUST subscribe to a well-known multicast
          group (@MCAST) and listen to port 4342 (default port number).<list
              style="format 2.%d">
              <t>The use of multicast transport will help ITRs of the
              different domains to maintain the same database.</t>

              <t>Also, it does not interfere with the underlying routing and
              forwarding policies that are configured locally. Whatever the
              ITR that will be selected when forwarding an outgoing packet,
              that ITR has issued a triggered Map-Request.</t>
            </list></t>

          <t>The DNS resolver is configured with the same @MCAST. If a
          different port than port number 4342 is used, this port number MUST
          be explicitly configured on the recursive DNS resolver.</t>

          <t>A recursive DNS resolver within a LISP-enabled domain is updated
          with one of the following capabilities. The decision about which one
          to enable is deployment-specific. This decision will help
          identifying which DNS forwarders will be impacted.<list
              style="format 4.%d">
              <t>When receiving a DNS query from a stub-resolver, duplicate
              that query and forward the duplicate to @MCAST:4342. The
              original query is forwarded according to normal DNS procedures
              (see the example shown in <xref target="ex2"></xref>).<vspace
              blankLines="1" />This query is duplicated as close to the
              stub-resolver as possible so that the LISP resolution process
              can occur while the DNS resolution is in progress.<list
                  style="format 4.1.%d">
                  <t>If the recursive resolver is the authoritative server for
                  this record, or the authoritative server is within the local
                  LISP domain, or a cache is invoked for that name, then
                  corresponding records are returned to the requesting stub
                  resolver following normal DNS procedures. Packets will
                  remain within the same LISP domain. (Inter-domain) ITRs
                  won't be solicited for this communication.</t>

                  <t>Otherwise, the request is forwarded upstream following
                  the normal DNS resolution procedure. In addition, the DNS
                  recursive resolver MUST duplicate the query and forward it
                  to @MCAST:4342.</t>

                  <t>Upon receipt of the DNS query, an ITR will build a
                  Map-Request with a name (<xref target="message"></xref>).
                  This triggered Map-Request is then forwarded to a
                  Map-Resolver. If the Map-Resolver is updated to support the
                  capability to associate a name with a mapping entry, it can
                  make a query based on the name carried in the Map-Request.
                  If not, the Map-Resolver must proceed first with a DNS
                  resolution locally and then the LISP resolution.<figure
                      anchor="ex2"
                      title="Processing Triggered Map-Request: Close to the Stub-resolver">
                      <artwork align="center"><![CDATA[+--------+  +--------+
|  Host  |  |Resolver|
+--------+  +--------+
    |           |
    |Query      |Query
    |---------->|---->
    |           |               Triggered
    |Response   |(a)Query->|-(b)Map-Request-->|
    |<----------|          |<-(c)Map-Response-|
    |                      |                  |               
    |                   +-------+         +--------+     +-------+
    |                   |  ITR  |         |   MR   |     |  ETR  |
    |                   +-------+         +--------+     +-------+
    |                      |                                 |
    |src=s_EID     st=d_EID|                                 |
    |--------(1)---------->|src=RLOC_itr         dst=RLOC_etr|
    |                      |==(2)==Encapsulated Packet======>|
    |                      |                                 |
    |                      |                                 |
    |src=s_EID     st=d_EID|                                 |
    |--------------------->|src=RLOC_itr         dst=RLOC_etr|
    |                      |======Encapsulated Packet=======>|
    |                      |                                 |]]></artwork>
                    </figure></t>
                </list></t>

              <t>When forwarding a DNS response to another DNS server,
              duplicate that response and forward the duplicate to
              @MCAST:4342. The original response is forwarded according to
              normal DNS procedures (see the example shown in <xref
              target="ex3"></xref>).<vspace blankLines="1" />The farthest DNS
              resolver of a leaf LISP network (i.e., a resolver that forwards
              DNS queries outside a LISP domain) is updated to fork a query
              for DNS records that cannot be serviced locally, either because
              the authoritative server belongs to the local LISP domain or
              because there is a cache platform that is enabled in the local
              LISP domain. This DNS Query is carried into a Triggered
              Map-Request message that is forwarded to all the ITRs of that
              LISP domain. Concretely:<list style="format 4.2.%d">
                  <t>If the recursive resolver is the authoritative server for
                  this record, or the authoritative server is within the local
                  domain, or a cache is invoked for that name, then
                  corresponding records are returned to the requesting stub
                  resolver following normal DNS procedures. Packets will
                  remain within the same LISP domain. (Inter-domain) ITRs
                  won't be solicited for this communication.</t>

                  <t>Otherwise, the request is forwarded upstream following
                  the normal DNS resolution procedure. In addition, the DNS
                  recursive resolver MUST duplicate the DNS response and
                  forward it to @MCAST:4342.<figure anchor="ex3"
                      title="Processing Triggered Map-Request: Far from to the Stub-Resolver">
                      <artwork align="center"><![CDATA[+--------+  +--------+            +----
|  Host  |  |Resolver|   ...      |Resolver
+--------+  +--------+            +-------
    |           |                     |  
    |Query      |Query                |
    |---------->|-----..------------->|  
    |           |             Response|  
    |           |<-----..-------------|
    |Response   |       |<--Response--|
    |<----------|       |  Triggered
    |                   |--Map-Request->|
    |                   |<-Map-Response>|
    |                   |               |    
    |                +-------+      +--------+     +-------+
    |                |  ITR  |      |   MR   |     |  ETR  |
    |                +-------+      +--------+     +-------+
    |                    |                             |
    |src=s_EID   st=d_EID|                             |
    |------------------->|src=RLOC_itr     dst=RLOC_etr|
    |                    |======Encapsulated Packet===>|
    |                    |                             |
    |                    |                             |
    |src=s_EID   st=d_EID|                             |
    |------------------->|src=RLOC_itr     dst=RLOC_etr|
    |                    |======Encapsulated Packet===>|
    |                    |                             |]]></artwork>
                    </figure></t>
                </list></t>

              <t>When forwarding a DNS query to another DNS server, build a
              corresponding Triggered Map-Request from the contents of the
              initial DNS query message. The request is then forwarded to
              @MCAST:4342. The original query is forwarded according to normal
              DNS procedures (see the example shown in <xref
              target="ex4"></xref>).<list style="format 4.3.%d:">
                  <t>This procedure is similar to the one described in Bullet
                  4.1. The only difference is that, instead of forking a DNS
                  message, appropriate Triggered Map-Request messages are
                  generated. The DNS resolvers rely upon the contents of the
                  DNS query to build the Triggered Map-Request message;
                  especially, the destination EID is set to the addresses
                  (IPv4 and/or IPv6) that were included in the DNS
                  response(s). Furthermore, the Map-Request message uses the
                  format defined in <xref target="message"></xref> to set the
                  destination EID.</t>

                  <t>Upon receipt of the Map-Request that carries a name, an
                  ITR will froward the request to its Map-Resolvers. If the
                  Map-Resolver is updated to support the capability to
                  associate a name with a mapping entry, then it can initiate
                  a query based on the name carried in the Map-Request. If
                  not, the Map-Resolver must proceed first to DNS resolution
                  locally and then a LISP resolution. <figure anchor="ex4"
                      title="Processing Triggered Map-Request: Close to the Stub-Resolver">
                      <artwork align="center"><![CDATA[+--------+ +--------+
|  Host  | |Resolver|
+--------+ +--------+
    |        |
    |Query   |Query
    |------->|---->
    |        |  
    |Response|Map-Request->|-(b)Map-Request-->|
    |<-------|             |<-(c)Map-Response-|
    |                      |                  |
    |                   +-------+         +--------+     +-------+
    |                   |  ITR  |         |   MR   |     |  ETR  |
    |                   +-------+         +--------+     +-------+
    |                      |                                 |
    |src=s_EID     st=d_EID|                                 |
    |--------(1)---------->|src=RLOC_itr         dst=RLOC_etr|
    |                      |==(2)==Encapsulated Packet======>|
    |                      |                                 |
    |                      |                                 |
    |src=s_EID     st=d_EID|                                 |
    |--------------------->|src=RLOC_itr         dst=RLOC_etr|
    |                      |======Encapsulated Packet=======>|
    |                      |                                 |]]></artwork>
                    </figure></t>
                </list></t>

              <t>When forwarding a DNS response to another DNS server, trigger
              a corresponding Map-Request that is formed after the contents of
              the said DNS response. The request is then forwarded to
              @MCAST:4342. The original response is forwarded according to
              normal DNS procedures (see the example shown in <xref
              target="ex5"></xref>).<list style="format 4.4.%d:">
                  <t>This procedure is similar to the one described in Bullet
                  4.2. The only difference is that, instead of forking a DNS
                  message, appropriate Map-Request messages are generated. The
                  DNS resolver relies upon the content of the DNS response to
                  build the Map-Request message; especially, the destination
                  EID is set to the addresses (IPv4 and/or IPv6) that were
                  included in the DNS response(s).<figure anchor="ex5"
                      title="Processing Triggered Map-Request: Far from to the Stub-resolver">
                      <artwork align="center"><![CDATA[+--------+  +--------+            +----
|  Host  |  |Resolver|   ...      |Resolver
+--------+  +--------+            +-------
    |           |                     |
    |Query      |Query                |
    |---------->|-----..------------->| 
    |           |             Response|
    |           |<-----..-------------|
    |Response   |      |<-Map-Request-|
    |<----------|      |  Triggered             
    |                  |--Map-Request->|               
    |                  |<-Map-Response-|               
    |                  |               |    
    |                +-------+      +--------+     +-------+
    |                |  ITR  |      |   MR   |     |  ETR  |
    |                +-------+      +--------+     +-------+
    |                    |                             |
    |src=s_EID   st=d_EID|                             |
    |------------------->|src=RLOC_itr     dst=RLOC_etr|
    |                    |======Encapsulated Packet===>|
    |                    |                             |
    |                    |                             |
    |src=s_EID   st=d_EID|                             |
    |------------------->|src=RLOC_itr     dst=RLOC_etr|
    |                    |======Encapsulated Packet===>|
    |                    |                             |]]></artwork>
                    </figure></t>
                </list></t>
            </list></t>

          <t>Subsequent packets associated with the same flow are handled
          locally (i.e., normal LISP operation applies).<!--Med: Add some text to discuss NETCONF-YANG to confifured triggered Map Request--></t>
        </list></t>
    </section>

    <section title="Security Considerations">
      <t>Security considerations discussed in <xref target="RFC6830"></xref>
      and <xref target="RFC6833"></xref> should be taken into account.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>To be completed.</t>

      <!--CJ: probably requires IANA to allocate a value for the WKP multicast prefix, right?-->
    </section>

    <section title="Acknowledgments">
      <t>This work is partly funded by ANR LISP-Lab project
      #ANR-13-INFR-009-X.</t>
    </section>
  </middle>

  <back>
    <references title="Normative references">
      <?rfc include='reference.RFC.6833'
?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.6830'?>

      <?rfc include='reference.RFC.1035'?>

      <?rfc include='reference.RFC.1123'?>

      <?rfc include='reference.RFC.2181'?>
    </references>

    <references title="Informative references">
      <?rfc include='reference.RFC.6836'?>

      <?rfc include='reference.I-D.ietf-dnsop-edns-client-subnet'?>
    </references>
  </back>
</rfc>
