One document matched: draft-boucadair-lisp-triggered-map-request-00.xml
<?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>
| PAFTECH AB 2003-2026 | 2026-04-24 05:26:17 |