Internet DRAFT - draft-boucadair-lisp-triggered-map-request

draft-boucadair-lisp-triggered-map-request







Network Working Group                                       M. Boucadair
Internet-Draft                                              C. Jacquenet
Intended status: Experimental                             France Telecom
Expires: March 20, 2016                               September 17, 2015


      Triggered LISP Map-Request for Inter-Domain LISP Deployments
             draft-boucadair-lisp-triggered-map-request-00

Abstract

   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.

   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.

Requirements Language

   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 RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 20, 2016.







Boucadair & Jacquenet    Expires March 20, 2016                 [Page 1]

Internet-Draft            Triggered Map-Request           September 2015


Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Sample LISP Flow Example (Focus on the Source Side) . . . . .   3
   3.  Triggered Map-Request . . . . . . . . . . . . . . . . . . . .   4
   4.  Name as an EID: Updated Map-Request Message Format  . . . . .   5
   5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Normative references  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative references  . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Problem Statement

   Locator/ID Separation Protocol (LISP, [RFC6830] ) 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.

   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.

   This document describes a solution to prepare the local mapping
   service by anticipating the process of retrieving appropriate mapping



Boucadair & Jacquenet    Expires March 20, 2016                 [Page 2]

Internet-Draft            Triggered Map-Request           September 2015


   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.

   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 Section 2 for illustration
   purposes.

   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.

   In addition to the terms defined in [RFC6830] and [RFC6833], this
   document makes uses of the following terms:

   o  Authoritative server: A DNS server that can answer authoritatively
      for a given DNS query.
   o  Stub resolver: A resolver with minimum functionality, typically
      used by endpoints that depend on a recursive resolver.
   o  Recursive resolver: A DNS server that accepts requests from one
      resolver, and asks another resolver for the answer on behalf of
      the first resolver.

   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.

2.  Sample LISP Flow Example (Focus on the Source Side)

   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:

   1  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.
   2  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.
   3  Once the recursive resolver receives a response from the DNS
      infrastructure, it will relay it to the requesting resolver.  As a




Boucadair & Jacquenet    Expires March 20, 2016                 [Page 3]

Internet-Draft            Triggered Map-Request           September 2015


      result of this procedure, A and/or AAAA records are returned to
      the requesting host (i.e., Host1).
   4  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.
   5  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
      [RFC6830]:

      5.1  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 [RFC6836]
           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.
      5.2  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.
      5.3  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.

3.  Triggered Map-Request

   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.

   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



Boucadair & Jacquenet    Expires March 20, 2016                 [Page 4]

Internet-Draft            Triggered Map-Request           September 2015


   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.

   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.

   An example of Triggered Map-Request is shown in Figure 1.  This
   example does not explicitly identify which entity has triggered the
   Map-Request in Step (a).

     +--------+             +-------+         +--------+     +-------+
     |  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=======>|
         |                      |                                 |

              Figure 1: Triggered Map-Request: A Flow Example

   An example of the use of triggered Map-Requests is detailed in
   Section 5.

4.  Name as an EID: Updated Map-Request Message Format

   Figure 2 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.

      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.




Boucadair & Jacquenet    Expires March 20, 2016                 [Page 5]

Internet-Draft            Triggered Map-Request           September 2015


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  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Boucadair & Jacquenet    Expires March 20, 2016                 [Page 6]

Internet-Draft            Triggered Map-Request           September 2015


                         Figure 2: Name as an EID

   The "Reserved" bits MUST each be set to zero and MUST be ignored upon
   receipt.

   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 [RFC1035]) that contains one or more labels.
   The Name encoding MUST follow the Name Syntax defined in
   [RFC1035][RFC1123][RFC2181] and are represented in ASCII form.

5.  Operation

   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.

   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.

   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.

   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.,
   [I-D.ietf-dnsop-edns-client-subnet]).  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.

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




Boucadair & Jacquenet    Expires March 20, 2016                 [Page 7]

Internet-Draft            Triggered Map-Request           September 2015


   1  (Inter-domain) ITRs MUST support a configuration parameter to
      enable/disable the Triggered-Map-Request procedure.  The default
      value of this parameter is "Disabled".

   2  All (inter-domain) ITRs MUST subscribe to a well-known multicast
      group (@MCAST) and listen to port 4342 (default port number).

      2.1  The use of multicast transport will help ITRs of the
           different domains to maintain the same database.

      2.2  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.

   3  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.

   4  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.

      4.1  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 Figure 3).

           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.

           4.1.1  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.

           4.1.2  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.





Boucadair & Jacquenet    Expires March 20, 2016                 [Page 8]

Internet-Draft            Triggered Map-Request           September 2015


           4.1.3  Upon receipt of the DNS query, an ITR will build a
                  Map-Request with a name (Section 4).  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.

    +--------+  +--------+
    |  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=======>|
        |                      |                                 |

      Figure 3: Processing Triggered Map-Request: Close to the Stub-
                                 resolver

      4.2  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 Figure 4).

           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




Boucadair & Jacquenet    Expires March 20, 2016                 [Page 9]

Internet-Draft            Triggered Map-Request           September 2015


           Query is carried into a Triggered Map-Request message that is
           forwarded to all the ITRs of that LISP domain.  Concretely:

           4.2.1  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.

           4.2.2  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.

       +--------+  +--------+            +----
       |  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===>|
           |                    |                             |

     Figure 4: Processing Triggered Map-Request: Far from to the Stub-
                                 Resolver





Boucadair & Jacquenet    Expires March 20, 2016                [Page 10]

Internet-Draft            Triggered Map-Request           September 2015


      4.3  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 Figure 5).

           4.3.1:  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 Section 4 to set the destination EID.

           4.3.2:  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.


























Boucadair & Jacquenet    Expires March 20, 2016                [Page 11]

Internet-Draft            Triggered Map-Request           September 2015


    +--------+ +--------+
    |  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=======>|
        |                      |                                 |

      Figure 5: Processing Triggered Map-Request: Close to the Stub-
                                 Resolver

      4.4  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 Figure 6).

           4.4.1:  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).










Boucadair & Jacquenet    Expires March 20, 2016                [Page 12]

Internet-Draft            Triggered Map-Request           September 2015


       +--------+  +--------+            +----
       |  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===>|
           |                    |                             |

     Figure 6: Processing Triggered Map-Request: Far from to the Stub-
                                 resolver

   5  Subsequent packets associated with the same flow are handled
      locally (i.e., normal LISP operation applies).

6.  Security Considerations

   Security considerations discussed in [RFC6830] and [RFC6833] should
   be taken into account.

7.  IANA Considerations

   To be completed.

8.  Acknowledgments

   This work is partly funded by ANR LISP-Lab project #ANR-13-INFR-
   009-X.





Boucadair & Jacquenet    Expires March 20, 2016                [Page 13]

Internet-Draft            Triggered Map-Request           September 2015


9.  References

9.1.  Normative references

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123,
              DOI 10.17487/RFC1123, October 1989,
              <http://www.rfc-editor.org/info/rfc1123>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
              <http://www.rfc-editor.org/info/rfc2181>.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,
              <http://www.rfc-editor.org/info/rfc6830>.

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833,
              DOI 10.17487/RFC6833, January 2013,
              <http://www.rfc-editor.org/info/rfc6833>.

9.2.  Informative references

   [I-D.ietf-dnsop-edns-client-subnet]
              Contavalli, C., Gaast, W., Lawrence, D., and W. Kumari,
              "Client Subnet in DNS Queries", draft-ietf-dnsop-edns-
              client-subnet-03 (work in progress), August 2015.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
              January 2013, <http://www.rfc-editor.org/info/rfc6836>.








Boucadair & Jacquenet    Expires March 20, 2016                [Page 14]

Internet-Draft            Triggered Map-Request           September 2015


Authors' Addresses

   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   EMail: mohamed.boucadair@orange.com


   Christian Jacquenet
   France Telecom
   Rennes  35000
   France

   EMail: christian.jacquenet@orange.com



































Boucadair & Jacquenet    Expires March 20, 2016                [Page 15]