Locator/ID Separation Protocol (LISP) Control-Planelispers.netfarinacci@gmail.comCisco Systemsfmaino@cisco.comvaf.net Internet Consultingvaf@vaf.netUPC/BarcelonaTechCampus Nord, C. Jordi Girona 1-3BarcelonaCatalunyaSpainacabello@ac.upc.edu This document describes the Control-Plane and Mapping Service
for the Locator/ID Separation Protocol (LISP), implemented by two
types of LISP-speaking devices -- the LISP Map-Resolver and
LISP Map-Server -- that provides a simplified "front end" for one
or more Endpoint ID to Routing Locator mapping databases.By using this Control-Plane service interface and communicating
with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers
(ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the
details of mapping database systems, which facilitates modularity
with different database designs. Since these devices implement the
"edge" of the LISP Control-Plane infrastructure, connecting EID
addressable nodes of a LISP site, their implementation and
operational complexity reduces the overall cost and effort of
deploying LISP.This document obsoletes RFC 6830 and RFC 6833.The Locator/ID Separation Protocol (see also ) specifies an architecture
and mechanism for dynamic tunneling by logically separating the
addresses currently used by IP in two separate name spaces:
Endpoint IDs (EIDs), used within sites; and Routing Locators
(RLOCs), used on the transit networks that make up the Internet
infrastructure. To achieve this separation, LISP defines protocol
mechanisms for mapping from EIDs to RLOCs. In addition, LISP
assumes the existence of a database to store and propagate those
mappings across mapping system nodes. Several such databases have
been proposed; among them are the Content distribution Overlay
Network Service for LISP-NERD (a Not-so-novel EID-to-RLOC
Database) , LISP Alternative Logical
Topology (LISP-ALT) , and LISP Delegated
Database Tree (LISP-DDT) . The LISP Mapping Service defines two types of
LISP-speaking devices: the Map-Resolver, which accepts
Map-Requests from an Ingress Tunnel Router (ITR) and "resolves"
the EID-to-RLOC mapping using a mapping database; and the
Map-Server, which learns authoritative EID-to-RLOC mappings from
an Egress Tunnel Router (ETR) and publishes them in a
database. This LISP Control-Plane Mapping Service can be used by many
different encapsulation-based or translation-based Data-Planes
which include but are not limited to the ones defined in LISP RFC
6830bis , LISP-GPE , VXLAN ,
VXLAN-GPE ,
GRE , GTP ,
ILA , and Segment Routing (SRv6)
. Conceptually, LISP Map-Servers share some of the same basic
configuration and maintenance properties as Domain Name System
(DNS) servers; likewise, Map-Resolvers
are conceptually similar to DNS caching resolvers. With this in
mind, this specification borrows familiar terminology (resolver
and server) from the DNS specifications. Note this document doesn't assume any particular database
mapping infrastructure to illustrate certain aspects of Map-Server
and Map-Resolver operation. The Mapping Service interface can (and
likely will) be used by ITRs and ETRs to access other mapping
database systems as the LISP infrastructure evolves.LISP is not intended to address problems of connectivity and
scaling on behalf of arbitrary communicating parties. Relevant
situations are described in the scoping section of the
introduction to .This document obsoletes RFC 6830 and 6833.LISP was originally developed to address the Internet-wide
route scaling problem . While there
are a number of approaches of interest for that problem, as LISP
as been developed and refined, a large number of other LISP uses
have been found and are being used. As such, the design and
development of LISP has changed so as to focus on these use
cases. The common property of these uses is a large set of
cooperating entities seeking to communicate over the public
Internet or other large underlay IP infrastructures, while
keeping the addressing and topology of the cooperating entities
separate from the underlay and Internet topology, routing, and
addressing.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they appear in all
capitals, as shown here.A network infrastructure component
that learns of EID-Prefix mapping entries from an ETR, via the
registration mechanism described below, or some other
authoritative source if one exists. A Map-Server publishes these
EID-Prefixes in a mapping database.A LISP Map-Request is a
Control-Plane message to query the mapping system to resolve an
EID. A LISP Map-Request can also be sent to an RLOC to test for
reachability and to exchange security keys between an
encapsulator and a decapsulator. This type of Map-Request is
also known as an RLOC-Probe Request.A LISP Map-Reply is a Control-Plane
message returned in response to a Map-Request sent to the mapping
system when resolving an EID. A LISP Map-Reply can also be returned by
a decapsulator in response to a Map-Request sent by an encapsulator
to test for reachability. This type of Map-Reply is known as a RLOC-Probe
Reply.A LISP Map-Request
carried within an Encapsulated Control Message (ECM), which has an
additional LISP header prepended. Sent to UDP destination port
4342. The "outer" addresses are routable IP addresses,
also known as RLOCs. Used by an ITR when sending to a
Map-Resolver and by a Map-Server when forwarding a Map-Request
to an ETR.A network infrastructure component
that accepts LISP Encapsulated (ECM) Map-Requests, typically from an
ITR, and determines whether or not the destination IP address is
part of the EID namespace; if it is not, a Negative Map-Reply is
returned. Otherwise, the Map-Resolver finds the appropriate
EID-to-RLOC mapping by consulting a mapping database system.A LISP Map-Reply that
contains an empty Locator-Set. Returned in response to a
Map-Request if the destination EID is not registered in the
mapping system, is policy denied or fails authentication.A LISP message sent by an
ETR to a Map-Server to register its associated EID-Prefixes. In
addition to the set of EID-Prefixes to register, the message
includes one or more RLOCs to reach ETR(s). The Map-Server uses
these RLOCs when forwarding Map-Requests (re-formatted as
Encapsulated Map-Requests). An ETR MAY request that the
Map-Server answer Map-Requests on its behalf by setting the
"proxy Map-Reply" flag (P-bit) in the message.A LISP message sent by a
Map-Server to an ETR to confirm that a Map-Register has been
received and processed. An ETR requests that a Map-Notify be
returned by setting the "want-map-notify" flag (M-bit) in the
Map-Register message. Unlike a Map-Reply, a Map-Notify uses UDP
port 4342 for both source and destination. Map-Notify messages
are also sent to ITRs by Map-Servers when there are RLOC-set
changes.For definitions of other terms, notably Ingress Tunnel
Router (ITR), Egress Tunnel Router (ETR), and Re-encapsulating
Tunnel Router (RTR), refer to the LISP Data-Plane specification
. A Map-Server is a device that publishes EID-Prefixes in a LISP
mapping database on behalf of a set of ETRs. When it receives a
Map Request (typically from an ITR), it consults the mapping
database to find an ETR that can answer with the set of RLOCs for
an EID-Prefix. To publish its EID-Prefixes, an ETR periodically
sends Map-Register messages to the Map-Server. A Map-Register
message contains a list of EID-Prefixes plus a set of RLOCs that
can be used to reach the ETRs. When LISP-ALT is used as the mapping
database, a Map-Server connects to the ALT network and acts as a
"last-hop" ALT-Router. Intermediate ALT-Routers forward
Map-Requests to the Map-Server that advertises a particular
EID-Prefix, and the Map-Server forwards them to the owning ETR,
which responds with Map-Reply messages. When LISP-DDT is used as
the mapping database, a Map-Server sends the final Map-Referral
messages from the Delegated Database Tree. A Map-Resolver receives Encapsulated Map-Requests from its
client ITRs and uses a mapping database system to find the
appropriate ETR to answer those requests. On a LISP-ALT network, a
Map-Resolver acts as a "first-hop" ALT-Router. It has Generic
Routing Encapsulation (GRE) tunnels configured to other
ALT-Routers and uses BGP to learn paths to ETRs for different
prefixes in the LISP-ALT database. The Map-Resolver uses this path
information to forward Map-Requests over the ALT to the correct
ETRs. On a LISP-DDT network , a
Map-Resolver maintains a referral-cache and acts as a "first-hop"
DDT-node. The Map-Resolver uses the referral information to
forward Map-Requests. Note that while it is conceivable that a Map-Resolver could
cache responses to improve performance, issues surrounding cache
management would need to be resolved so that doing so will be
reliable and practical. In this specification, Map-Resolvers will
operate only in a non-caching mode, decapsulating and forwarding
Encapsulated Map Requests received from ITRs. Any specification
of caching functionality is out of scope for this document. Note that a single device can implement the functions of both
a Map-Server and a Map-Resolver, and in many cases the functions
will be co-located in that way. Also, there can be ALT-only nodes
and DDT-only nodes, when LISP-ALT and LISP-DDT are used,
respectively, to connecting Map-Resolvers and Map-Servers together to
make up the Mapping System.The following UDP packet formats are used by the LISP
control plane.When a UDP Map-Request, Map-Register, or Map-Notify (when used
as a notification message) are sent, the UDP source port is chosen
by the sender and the destination UDP port number is set to
4342. When a UDP Map-Reply, Map-Notify (when used as an
acknowledgement to a Map-Register), or Map-Notify-Ack are sent,
the source UDP port number is set to 4342 and the destination UDP
port number is copied from the source port of either the
Map-Request or the invoking data packet. Implementations MUST be
prepared to accept packets when either the source port or
destination UDP port is set to 4342 due to NATs changing port
number values.The 'UDP Length' field will reflect the length of the UDP
header and the LISP Message payload. LISP is expected to be deployed
by cooperating entities communicating over underlays. Deployers are
expected to set the MTU according to the specific deployment guidelines
to prevent fragmentation of either the inner packet or the outer
encapsulated packet. For deployments not aware of the underlay
restrictions on path MTU, the message size MUST be limited to 576 bytes
for IPv4 or 1280 bytes for IPv6 as outlined in .The UDP checksum is computed and set to non-zero for all
messages sent to or from port 4342. It MUST be checked on
receipt, and if the checksum fails, the control message MUST be
dropped .The format of control messages includes the UDP header so the
checksum and length fields can be used to protect and delimit
message boundaries.This section defines the LISP control message formats and
summarizes for IANA the LISP Type codes assigned by this
document. For completeness, the summary below includes the LISP
Shared Extension Message assigned by . Message type definitions
are:Protocol designers experimenting with new message formats are
recommended to use the LISP Shared Extension Message Type described
in .All LISP Control-Plane messages use Address Family
Identifiers (AFI) or LISP Canonical Address
Format (LCAF) formats to encode either
fixed or variable length addresses. This includes explicit
fields in each control message or part of EID-records or
RLOC-records in commonly formatted messages.The LISP control-plane describes how other data-planes can
encode messages to support the Soliciting of Map-Requests as well as
RLOC-probing procedures.Packet field descriptions:1 (Map-Request) This is an authoritative bit, which is set
to 0 for UDP-based Map-Requests sent by an ITR. It is set to 1
when an ITR wants the destination site to return the Map-Reply
rather than the mapping database system returning a Map-Reply. This is the map-data-present bit. When set,
it indicates that a Map-Reply Record segment is included in
the Map-Request. This is the probe-bit, which indicates that a
Map-Request MUST be treated as a Locator reachability
probe. The receiver MUST respond with a Map-Reply with the
probe-bit set, indicating that the Map-Reply is a Locator
reachability probe reply, with the nonce copied from the
Map-Request. See RLOC-Probing for
more details. This RLOC-probe Map-Request MUST NOT be sent to
the mapping system. If a Map-Resolver or Map-Server receives a
Map-Request with the probe-bit set, it MUST drop the message. This is the Solicit-Map-Request (SMR)
bit. See Solicit-Map-Request (SMRs) for
details. This is the PITR bit. This bit is set to 1
when a PITR sends a Map-Request. This is the SMR-invoked bit. This bit is set
to 1 when an xTR is sending a Map-Request in response to a
received SMR-based Map-Request.This reserved and unassigned bit MUST be set to 0 on
transmit and MUST be ignored on receipt.This field MUST be set to 0 on transmit
and MUST be ignored on receipt. This is the local-xtr bit. It is used by an
xTR in a LISP site to tell other xTRs in the same site that it
is part of the RLOC-set for the LISP site. The L-bit is set to
1 when the RLOC is the sender's IP address. This is the dont-map-reply bit. It is used
in the SMR procedure described in . When
an xTR sends an SMR Map-Request message, it doesn't need a
Map-Reply returned. When this bit is set, the receiver of the
Map-Request does not return a Map-Reply. This 5-bit field is the ITR-RLOC Count,
which encodes the additional number of ('ITR-RLOC-AFI',
'ITR-RLOC Address') fields present in this message. At least
one (ITR-RLOC-AFI, ITR-RLOC-Address) pair MUST be encoded.
Multiple 'ITR-RLOC Address' fields are used, so a Map-Replier
can select which destination address to use for a
Map-Reply. The IRC value ranges from 0 to 31. For a value of
0, there is 1 ITR-RLOC address encoded; for a value of 1,
there are 2 ITR-RLOC addresses encoded, and so on up to 31,
which encodes a total of 32 ITR-RLOC addresses. This is the number of records in
this Map-Request message. A record is comprised of the
portion of the packet that is labeled 'Rec' above and occurs
the number of times equal to Record Count. For this version of
the protocol, a receiver MUST accept and process Map-Requests
that contain one or more records, but a sender MUST only send
Map-Requests containing one record. This is an 8-octet random value created
by the sender of the Map-Request. This nonce will be returned
in the Map-Reply. The nonce is used as an index to identify
the corresponding Map-Request when a Map-Reply message is received.
The nonce MUST be generated by a
properly seeded pseudo-random source, see as an example
. This is the address family of
the 'Source EID Address' field. This is the EID of the
source host that originated the packet that caused the
Map-Request. When Map-Requests are used for refreshing a
Map-Cache entry or for RLOC-Probing, an AFI value 0 is used
and this field is of zero length. This is the address family of the
'ITR-RLOC Address' field that follows this field. This is used to give the ETR
the option of selecting the destination address from any
address family for the Map-Reply message. This address MUST be
a routable RLOC address of the sender of the Map-Request
message. This is the mask length for the
EID-Prefix in decimal. This is the address family of
the EID-Prefix according to and . This prefix address length is 4
octets for an IPv4 address family and 16 octets for an IPv6
address family when the EID-Prefix-AFI is 1 or 2,
respectively. For other AFIs , the address
length varies and for the LCAF AFI the format is defined in
. When a Map-Request is sent by an
ITR because a data packet is received for a destination where
there is no mapping entry, the EID-Prefix is set to the
destination IP address of the data packet, and the 'EID
mask-len' is set to 32 or 128 for IPv4 or IPv6,
respectively. When an xTR wants to query a site about the
status of a mapping it already has cached, the EID-Prefix used
in the Map-Request has the same mask-length as the EID-Prefix
returned from the site when it sent a Map-Reply message. When the M-bit is set, this
field is the size of a single "Record" in the Map-Reply
format. This Map-Reply record contains the EID-to-RLOC mapping
entry associated with the Source EID. This allows the ETR that
will receive this Map-Request to cache the data if it chooses
to do so.A Map-Request is sent from an ITR when it needs a mapping for
an EID, wants to test an RLOC for reachability, or wants to
refresh a mapping before TTL expiration. For the initial case,
the destination IP address used for the Map-Request is the data
packet's destination address (i.e., the destination EID) that
had a mapping cache lookup failure. For the latter two cases,
the destination IP address used for the Map-Request is one of
the RLOC addresses from the Locator-Set of the Map-Cache
entry. The source address is either an IPv4 or IPv6 RLOC
address, depending on whether the Map-Request is using an IPv4
or IPv6 header, respectively. In all cases, the UDP source port
number for the Map-Request message is a 16-bit value selected by
the ITR/PITR, and the UDP destination port number is set to the
well-known destination port number 4342. A successful
Map-Reply, which is one that has a nonce that matches an
outstanding Map-Request nonce, will update the cached set of
RLOCs associated with the EID-Prefix range.One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address')
fields MUST be filled in by the ITR. The number of fields (minus
1) encoded MUST be placed in the 'IRC' field. The ITR MAY
include all locally configured Locators in this list or just
provide one locator address from each address family it
supports. If the ITR erroneously provides no ITR-RLOC addresses,
the Map-Replier MUST drop the Map-Request.Map-Requests can also be LISP encapsulated using UDP
destination port 4342 with a LISP Type value set to
"Encapsulated Control Message", when sent from an ITR to a
Map-Resolver. Likewise, Map-Requests are LISP encapsulated the
same way from a Map-Server to an ETR. Details on Encapsulated
Map-Requests and Map-Resolvers can be found in .Map-Requests MUST be rate-limited to 1 per second per EID-prefix.
After 10 retransmits without receiving the corresponding Map-Reply must wait 30 seconds.An ITR that is configured with mapping database information
(i.e., it is also an ETR) MAY optionally include those mappings
in a Map-Request. When an ETR configured to accept and verify
such "piggybacked" mapping data receives such a Map-Request and
it does not have this mapping in the Map-Cache, it MAY originate
a "verifying Map-Request", addressed to the map-requesting ITR
and the ETR MAY add a Map-Cache entry. If the ETR (when it is
an xTR co-located as an ITR) has a Map-Cache entry that matches
the "piggybacked" EID and the RLOC is in the Locator-Set for the
cached entry, then it MAY send the "verifying Map-Request" directly to
the originating Map-Request source. If the RLOC is not in the
Locator-Set, then the ETR MUST send the "verifying Map-Request"
to the "piggybacked" EID. Doing this forces the "verifying
Map-Request" to go through the mapping database system to reach
the authoritative source of information about that EID, guarding
against RLOC-spoofing in the "piggybacked" mapping data.Packet field descriptions:2 (Map-Reply) This is the probe-bit, which indicates that
the Map-Reply is in response to a Locator reachability probe
Map-Request. The 'Nonce' field MUST contain a copy of the
nonce value from the original Map-Request. See RLOC-probing
for more details. When the
probe-bit is set to 1 in a Map-Reply message, the A-bit in
each EID-record included in the message MUST be set to 1,
otherwise MUST be silently discarded. This bit indicates that the ETR that sends
this Map-Reply message is advertising that the site is enabled
for the Echo-Nonce Locator reachability algorithm. See
Echo-Nonce for more
details. This is the Security bit. When set to 1, the
following authentication information will be appended to the
end of the Map-Reply. The details can be found in . This unassigned field MUST be set to 0 on
transmit and MUST be ignored on receipt. This is the number of records in
this reply message. A record is comprised of that portion of
the packet labeled 'Record' above and occurs the number of
times equal to Record Count. This 64-bit value from the Map-Request
is echoed in this 'Nonce' field of the Map-Reply. This is the time in minutes the
recipient of the Map-Reply can store the mapping. If the TTL
is 0, the entry MUST be removed from the cache immediately.
If the value is 0xffffffff, the recipient can decide locally
how long to store the mapping. This is the number of Locator
entries in the given Record. A Locator entry comprises what is labeled above as
'Loc'. The Locator count can be 0, indicating that
there are no Locators for the EID-Prefix. This is the mask length for the
EID-Prefix in decimal. This 3-bit field describes Negative
Map-Reply actions. In any other message type, these bits are
set to 0 and ignored on receipt. These bits are used only when
the 'Locator Count' field is set to 0. The action bits are
encoded only in Map-Reply messages. They are used to tell an
ITR or PITR why a empty locator-set was returned from the
mapping system and how it stores the map-cache entry.
See for additional information.The Map-Cache is kept alive,
and no packet encapsulation occurs.The packet is not
encapsulated or dropped but natively forwarded.The Map-Cache entry is
created and flagged that any packet matching this entry
invokes sending a Map-Request.A packet that matches this
Map-Cache entry is dropped. An ICMP Destination Unreachable
message SHOULD be sent.A packet that matches
this Map-Cache entry is dropped. The reason for the Drop
action is that a Map-Request for the target-EID is being
policy denied by either an xTR or the mapping system.A packet that
matches this Map-Cache entry is dropped. The reason for the
Drop action is that a Map-Request for the target-EID fails
an authentication verification-check by either an xTR or the
mapping system. The Authoritative bit MAY only be set to 1 by an ETR.
A Map-Server generating Map-Reply messages as a proxy MUST NOT set the A-bit to 1 by an ETR, and not a Map-Server generating Map-Reply
messages as a proxy. This bit
indicates to requesting ITRs that the Map-Reply was not
originated by a LISP node managed at the site that owns the
EID-Prefix. When this 12-bit value is
non-zero, the Map-Reply sender is informing the ITR what the
version number is for the EID record contained in the
Map-Reply. The ETR can allocate this number internally but
MUST coordinate this value with other ETRs for the site. When
this value is 0, there is no versioning information
conveyed. The Map-Version Number can be included in
Map-Request and Map-Register messages. See Map-Versioning
for more details. Address family of the
EID-Prefix according to and . This prefix is 4 octets for an IPv4
address family and 16 octets for an IPv6 address family. Each RLOC is assigned a unicast
Priority. Lower values are more preferable. When multiple
RLOCs have the same Priority, they may be used in a load-split
fashion. A value of 255 means the RLOC MUST NOT be used for
unicast forwarding. When priorities are the same for
multiple RLOCs, the Weight indicates how to balance unicast
traffic between them. Weight is encoded as a relative weight
of total unicast packets that match the mapping entry. For
example, if there are 4 Locators in a Locator-Set, where the
Weights assigned are 30, 20, 20, and 10, the first Locator
will get 37.5% of the traffic, the 2nd and 3rd Locators will
get 25% of the traffic, and the 4th Locator will get 12.5% of
the traffic. If all Weights for a Locator-Set are equal, the
receiver of the Map-Reply will decide how to load-split the
traffic. See RLOC-hashing for a suggested hash
algorithm to distribute the load across Locators with the same
Priority and equal Weight values. Each RLOC is assigned a multicast
Priority used by an ETR in a receiver multicast site to select
an ITR in a source multicast site for building multicast
distribution trees. A value of 255 means the RLOC MUST NOT be
used for joining a multicast distribution tree. For more
details, see .When priorities are the same for
multiple RLOCs, the Weight indicates how to balance building
multicast distribution trees across multiple ITRs. The Weight
is encoded as a relative weight (similar to the unicast
Weights) of the total number of trees built to the source site
identified by the EID-Prefix. If all Weights for a Locator-Set
are equal, the receiver of the Map-Reply will decide how to
distribute multicast state across ITRs. For more details, see
.These are set to 0 when sending
and ignored on receipt.When this bit is set, the Locator is flagged
as a local Locator to the ETR that is sending the Map-Reply.
When a Map-Server is doing proxy Map-Replying for a LISP site,
the L-bit is set to 0 for all Locators in this
Locator-Set.When this bit is set, an ETR informs the
RLOC-Probing ITR that the locator address for which this bit
is set is the one being RLOC-probed and may be different from
the source address of the Map-Reply. An ITR that RLOC-probes a
particular Locator MUST use this Locator for retrieving the
data structure used to store the fact that the Locator is
reachable. The p-bit is set for a single Locator in the same
Locator-Set. If an implementation sets more than one p-bit
erroneously, the receiver of the Map-Reply MUST select the
first set p-bit Locator. The p-bit MUST NOT be set for Locator-Set
records sent in Map-Request and Map-Register messages.This is set when the sender of a Map-Reply
has a route to the Locator in the Locator data record. This
receiver may find this useful to know if the Locator is up but
not necessarily reachable from the receiver's point of
view. See also EID-Reachability
for another way the R-bit may be used.This is an IPv4 or IPv6 address (as
encoded by the 'Loc-AFI' field) assigned to an ETR and used by
an ITR as a destination RLOC address in the outer header of a
LISP encapsualted packet. Note that the destination RLOC
address of a LISP encapsulated packet MAY be an anycast
address. A source RLOC of a LISP encapsulated packet can be an
anycast address as well. The source or destination RLOC MUST
NOT be the broadcast address (255.255.255.255 or any subnet
broadcast address known to the router) and MUST NOT be a
link-local multicast address. The source RLOC MUST NOT be a
multicast address. The destination RLOC SHOULD be a multicast
address if it is being mapped from a multicast destination
EID.Map-Reply MUST be rate-limited, it is RECOMMENDED that a Map-Reply
for the same destination RLOC be sent no more than one packets per 3 seconds.The Record format, as defined here, is used both in the Map-Reply
and Map-Register messages, this includes all the field definitions. A Map-Reply returns an EID-Prefix with a mask-length that
is less than or equal to the EID being requested. The EID being
requested is either from the destination field of an IP header
of a Data-Probe or the EID record of a Map-Request. The RLOCs
in the Map-Reply are routable IP addresses of all ETRs for the
LISP site. Each RLOC conveys status reachability but does not
convey path reachability from a requester's
perspective. Separate testing of path reachability is
required. See RLOC-reachability for
details.Note that a Map-Reply MAY contain different EID-Prefix
granularity (prefix + mask-length) than the Map-Request that triggers
it. This might occur if a Map-Request were for a prefix that had
been returned by an earlier Map-Reply. In such a case, the
requester updates its cache with the new prefix information and
granularity. For example, a requester with two cached
EID-Prefixes that are covered by a Map-Reply containing one
less-specific prefix replaces the entry with the less-specific
EID-Prefix. Note that the reverse, replacement of one
less-specific prefix with multiple more-specific prefixes, can
also occur, not by removing the less-specific prefix but rather
by adding the more-specific prefixes that, during a lookup, will
override the less-specific prefix.When an EID moves out of a LISP site , the database mapping system
may have overlapping EID-prefixes. Or when a LISP site is
configured with multiple sets of ETRs that support different
EID-prefix mask-lengths, the database mapping system may have
overlapping EID-prefixes. When overlapping EID-prefixes exist, a
Map-Request with an EID that best matches any EID-Prefix MUST be
returned in a single Map-Reply message. For instance, if an ETR
had database mapping entries for EID-Prefixes:A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply
with a record count of 1 to be returned with a mapping record
EID-Prefix of 2001:db8:1:1::/32.A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply
with a record count of 3 to be returned with mapping records for
EID-Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32,
2001:db8:1:2::/32, filling out the /24 with more-specifics
that exist in the mapping system.Note that not all overlapping EID-Prefixes need to be
returned but only the more-specific entries (note that in the
second example above 2001:db8::/16 was not returned for requesting
EID 2001:db8:1:5::5) for the matching EID-Prefix of the requesting
EID. When more than one EID-Prefix is returned, all SHOULD use
the same Time to Live value so they can all time out at the same
time. When a more-specific EID-Prefix is received later, its
Time to Live value in the Map-Reply record can be stored even
when other less-specific entries exist. When a less-specific
EID-Prefix is received later, its Map-Cache expiration time
SHOULD be set to the minimum expiration time of any
more-specific EID-Prefix in the Map-Cache. This is done so the
integrity of the EID-Prefix set is wholly maintained and so no
more-specific entries are removed from the Map-Cache while
keeping less-specific entries.For scalability, it is expected that aggregation of EID addresses
into EID-Prefixes will allow one Map-Reply to satisfy a mapping
for the EID addresses in the prefix range, thereby reducing the
number of Map-Request messages.Map-Reply records can have an empty Locator-Set. A Negative
Map-Reply is a Map-Reply with an empty Locator-Set. Negative
Map-Replies convey special actions by the sender to the ITR or
PITR that have solicited the Map-Reply. There are two primary
applications for Negative Map-Replies. The first is for a
Map-Resolver to instruct an ITR or PITR when a destination is
for a LISP site versus a non-LISP site, and the other is to
source quench Map-Requests that are sent for non-allocated
EIDs.For each Map-Reply record, the list of Locators in a
Locator-Set MUST be sorted
in order of ascending IP address where an IPv4 locator address
is considered numerically 'less than' an IPv6 locator
address.When sending a Map-Reply message, the destination address is
copied from one of the 'ITR-RLOC' fields from the
Map-Request. The ETR can choose a locator address from one of
the address families it supports. For Data-Probes, the
destination address of the Map-Reply is copied from the source
address of the Data-Probe message that is invoking the
reply. The source address of the Map-Reply is one of the local
IP addresses chosen, to allow Unicast Reverse Path Forwarding
(uRPF) checks to succeed in the upstream service provider. The
destination port of a Map-Reply message is copied from the
source port of the Map-Request or Data-Probe, and the source
port of the Map-Reply message is set to the well-known UDP port
4342.This section specifies the encoding format for the
Map-Register message. The message is sent in UDP with a
destination UDP port of 4342 and a randomly selected UDP source
port number.The fields below are used in multiple control messages. They
are defined for Map-Register, Map-Notify and Map-Notify-Ack message
types.The Map-Register message format is:Packet field descriptions:3 (Map-Register)This is the proxy Map-Reply bit. When set to
1, the ETR sending the Map-Register message is requesting the
Map-Server to proxy a Map-Reply. The Map-Server will send
non-authoritative Map-Replies on behalf of the ETR.This is the security-capable bit. When set,
the procedures from are
supported.This bit is set to 1 to indicate that a 128
bit xTR-ID and a 64 bit Site-ID fields are present at the end
of the Map-Register message. If an xTR is configured with an
xTR-ID and Site-ID, it MUST set the I bit to 1 and include its
xTR-ID and Site-ID in the Map-Register messages it generates.
The combination of Site-ID plus xTR-ID uniquely identifies an
xTR in a LISP domain and serves to track its last seen
nonce.This unassigned field MUST be set to 0 on
transmit and MUST be ignored on receipt.This is the Map-Register EID-notify bit. This
is used by a First-Hop-Router (FHR) which discovers a
dynamic-EID. This EID-notify based Map-Register is sent by the
FHR to the same site xTR that propogates the Map-Register to
the mapping system. The site xTR keeps state to later
Map-Notify the FHR after the EID has moves away. See for a detailed
use-case.This is the use-TTL for timeout bit. When set
to 1, the xTR wants the Map-Server to time out registrations
based on the value in the "Record TTL" field of this
message. Otherwise, the default timeout described in is used.This is the merge-request bit. When set to 1,
the xTR requests to merge RLOC-records from different xTRs
registering the same EID-record. See signal-free multicast
for one
use case example.This reserved and unassigned bit MUST be set to 0 on
transmit and MUST be ignored on receipt.This is the want-map-notify bit. When set to
1, an ETR is requesting a Map-Notify message to be returned in
response to sending a Map-Register message. The Map-Notify
message sent by a Map-Server is used to acknowledge receipt of
a Map-Register message. This is the number of records in
this Map-Register message. A record is comprised of that
portion of the packet labeled 'Record' above and occurs the
number of times equal to Record Count. This 8-octet 'Nonce' field is
incremented each time a Map-Register message is sent. When a
Map-Register acknowledgement is requested, the nonce is
returned by Map-Servers in Map-Notify messages. Since the
entire Map-Register message is authenticated, the 'Nonce'
field serves to protect against Map-Register replay
attacks. An ETR that registers to the mapping system SHOULD
store the last nonce sent in persistent storage so when it
restarts it can continue using an incrementing nonce. If the
the ETR cannot support saving the nonce, then when it restarts
it MUST use a new authentication key to register to the
mapping system. A Map-Server MUST track and save in persistent
storage the last nonce received for each ETR xTR-ID and key pair.
If a Map-Register is received with a nonce
value that is not greater than the saved nonce, it drops the
Map-Register message and logs the fact a replay attack could
have occurred. A key-id value that identifies a
pre-shared secret between an ETR and a Map-Server. Per-message
keys are derived from the pre-shared secret to authenticate
the origin and protect the integrity of the Map-Register.
The Key ID allows to rotate between multiple pre-shared
secrets in a non disruptive way. The pre-shared secret MUST
be unique per each LISP "Site-ID" This field identifies the Key
Derivation Function (KDF) and Message Authentication Code (MAC)
algorithms used to derive the key and to compute the Authentication
Data of a Map-Register. This 8-bit field identifies the KDF and
MAC algorithm pair. See for codepoint assignments. This is the length
in octets of the 'Authentication Data' field that follows this
field. The length of the 'Authentication Data' field is
dependent on the MAC algorithm used. The length field allows a
device that doesn't know the MAC algorithm to correctly parse
the packet.This is the output of the
MAC algorithm placed in this field after the MAC computation.
The MAC output is computed as follows:The KDF algorithm is identified by the
field 'Algorithm ID' according to the table in .
Implementations of this specification SHOULD include
support for HMAC-SHA256-128+HKDF-SHA256
.The MAC algorithm is identified by the field 'Algorithm ID'
according to the table in .The pre-shared secret used to derive the per-message key is represented by PSK[Key ID],
that is the pre-shared secret identified by the 'Key ID'.The derived per-message key is computed as: per-msg-key=KDF(nonce+s+PSK[Key ID]).
Where the nonce is the value in the Nonce field of the Map-Register and 's'
is a string equal to "Map-Register Authentication".The MAC output is computed using the MAC algorithm and
the per-msg-key over the entire Map-Register payload
(from and including the LISP message type field through the
end of the last RLOC record) with the authenticated data field preset to 0.The definition of the rest of the Map-Register can be found
in EID-record description in . When
the I-bit is set, the following fields are added to the end of
the Map-Register message:xTR-ID is a 128 bit field at the end of
the Map-Register message, starting after the final Record in
the message. The xTR-ID is used to uniquely identify a xTR.
The same xTR-ID value MUST NOT be used in two different xTRs in the scope of the Site-ID.Site-ID is a 64 bit field at the end of
the Map- Register message, following the xTR-ID. Site-ID is
used to uniquely identify to which site the xTR that sent the
message belongs. This document does not specify a strict meaning for the Site-ID field.
Informally it provides an indication that a group of xTRs have some relation, either administratively, topologically or otherwise.This section specifies the encoding format for the Map-Notify
and Map-Notify-Ack messages. The messages are sent inside a UDP
packet with source and destination UDP ports equal to 4342.The Map-Notify and Map-Notify-Ack message formats are:Packet field descriptions:4/5 (Map-Notify/Map-Notify-Ack)The Map-Notify message has the same contents as a
Map-Register message. See the Map-Register section for field
descriptions and the Map-Reply section for EID-record and
RLOC-record descriptions.The fields of the Map-Notify are copied from the
corresponding Map-Register to acknowledge its correct
processing. In the Map-Notfiy, the 'Authentication Data'
field is recomputed according to the procedure defined
in the previous section. For an unsolicited Map-Notify, the fields of a
Map-Notify used for publish/subscribe are specified in .After sending a Map-Register, if a Map-Notify is not
received after 1 second the transmitter MUST re-transmit
the original Map-Register with an exponential backoff (base of 2, that is, the next backoff timeout interval is doubled),
the maximum backoff is 1 minute.The Map-Notify-Ack message has the same contents as a
Map-Notify message. It is used to acknowledge the receipt of a
Map-Notify and for the sender to stop
retransmitting a Map-Notify with the same nonce. The fields of
the Map-Notify-Ack are copied from the corresponding Map-Notify
message to acknowledge its correct processing. The 'Authentication Data'
field is recomputed according to the procedure defined
in the previous section.A Map-Server sends an unsolicited Map-Notify message (one
that is not used as an acknowledgment to a Map-Register message)
that follows the Congestion Control And Relability Guideline
sections of . A Map-Notify is
retransmitted until a Map-Notify-Ack is received by the
Map-Server with the same nonce used in the Map-Notify message.
If a Map-Notify-Ack is never received by the Map-Server, it
issues a log message. An implementation SHOULD retransmit up to
3 times at 3 second retransmission intervals, after which time
the retransmission interval is exponentially backed-off (base of 2, that is, the next backoff timeout interval is doubled) for
another 3 retransmission attempts.Upon reception of Map-Register, Map-Notify or Map-Notifiy-Ack, the receiver verifies
the authentication data.An Encapsulated Control Message (ECM) is used to encapsulate
control packets sent between xTRs and the mapping database
system.Packet header descriptions:The outer IPv4 or IPv6 header, which uses
RLOC addresses in the source and destination header address
fields.The outer UDP header with destination port
4342. The source port is randomly allocated. The checksum
field MUST be non-zero.Type 8 is defined to be a "LISP Encapsulated
Control Message", and what follows is either an IPv4 or IPv6
header as encoded by the first 4 bits after the 'Reserved'
field.8 (Encapsulated Control Message (ECM))This is the Security bit. When set to 1, the
field following the 'Reserved' field will have the following
Authentication Data format and follow the procedures from .This is the DDT-bit. When set to 1, the
sender is requesting a Map-Referral message to be
returned. The details of this procedure are described in .This is the to-ETR bit. When set to 1, the
Map-Server's intention is to forward the ECM to an
authoritative ETR.This is the to-MS bit. When set to 1, a
Map-Request is being sent to a co-located Map-Resolver and
Map-Server where the message can be processed directly by the
Map-Server versus the Map-Resolver using the LISP-DDT
procedures in .The inner IPv4 or IPv6 header, which can use
either RLOC or EID addresses in the header address
fields. When a Map-Request is encapsulated in this packet
format, the destination address in this header is an EID.The inner UDP header, where the port
assignments depend on the control packet being
encapsulated. When the control packet is a Map-Request or
Map-Register, the source port is selected by the ITR/PITR and
the destination port is 4342. When the control packet is a
Map-Reply, the source port is 4342 and the destination port is
assigned from the source port of the invoking
Map-Request. Port number 4341 MUST NOT be assigned to either
port. The checksum field MUST be non-zero.The format is one of the control message
formats described in . Map-Request messages are
allowed to be Control-Plane (ECM) encapsulated. When
Map-Requests are sent for RLOC-Probing purposes (i.e. the
probe-bit is set), they MUST NOT be sent inside Encapsulated
Control Messages. PIM Join/Prune messages are also allowed to be Control-Plane (ECM)
encapsulated.In the LISP architecture ITRs/PITRs use a local Map-Cache to
store EID-to-RLOC mappings for forwarding. When an ETR updates a
mapping a mechanism is required to inform ITRs/PITRs that are
using such mappings.The LISP Data-Plane defines several mechanism to update
mappings . This document
specifies the Solicit-Map Request (SMR), a Control-Plane
push-based mechanism. An additional Control-Plane mechanism based
on the Publish/subscribe paradigm is specified in
.Soliciting a Map-Request is a selective way for ETRs, at
the site where mappings change, to control the rate they
receive requests for Map-Reply messages. SMRs are also used
to tell remote ITRs to update the mappings they have cached.Since ETRs are not required to keep track of remote ITRs
that have cached their mappings, they do not know which ITRs
need to have their mappings updated. As a result, an ETR
will solicit Map-Requests (called an SMR message) to those
sites to which it has been sending LISP encapsulated data
packets for the last minute. As a result, when an ETR is also acting as ITR,
it will send an SMR to an ITR to which it has recently sent encapsulated
data.An SMR message is simply a bit set in a Map-Request message.
An ITR or PITR will send a Map-Request when they receive an SMR
message. Both the SMR sender and the SMR responder
MUST rate-limit these messages. It is RECOMMENDED that
the SMR sender rate-limits Map-Request for the same destination RLOC to
no more than one packet per 3 seconds. It is RECOMMENDED that the
SMR responder rate-limits Map-Request for the same EID-Prefix to no more than once
per 3 seconds.For security reasons, an ITR MUST NOT process
unsolicited Map-Replies. To avoid Map-Cache entry
corruption by a third party, a sender of an SMR-based
Map-Request MUST be verified. If an ITR receives an
SMR-based Map-Request and the source is not in the
Locator-Set for the stored Map-Cache entry, then the
responding Map-Request MUST be sent with an EID
destination to the mapping database system. Since the
mapping database system is a more secure way to reach an
authoritative ETR, it will deliver the Map-Request to the
authoritative source of the mapping data. Please note that
this procedure does not result in cryptographic or strongly
authenticated verification.When an ITR receives an SMR-based Map-Request for
which it does not have a cached mapping for the EID in
the SMR message, it SHOULD NOT send an SMR-invoked
Map-Request. This scenario can occur when an ETR sends
SMR messages to all Locators in the Locator-Set it has
stored in its Map-Cache but the remote ITRs that receive the
SMR may not be sending packets to the site. There is no
point in updating the ITRs until they need to send, in
which case they will send Map-Requests to obtain a
Map-Cache entry.This document defines several Control-Plane mechanisms
for determining RLOC reachability. Please note that additional Data-Plane
reachability mechanisms are defined in .An ITR may receive an ICMP Network Unreachable or Host
Unreachable message for an RLOC it is using. This
indicates that the RLOC is likely down. Note that trusting
ICMP messages may not be desirable, but neither is ignoring
them completely. Implementations are encouraged to follow
current best practices in treating these conditions
.When an ITR participates in the routing protocol that
operates in the underlay routing system, it can determine that
an RLOC is down when no Routing Information Base (RIB)
entry exists that matches the RLOC IP address.An ITR may receive an ICMP Port Unreachable message
from a destination host. This occurs if an ITR
attempts to use interworking and
LISP-encapsulated data is sent to a non-LISP-capable site.An ITR may receive a Map-Reply from an ETR in
response to a previously sent Map-Request. The RLOC
source of the Map-Reply is likely up, since the
ETR was able to send the Map-Reply to the ITR.An ITR/ETR pair can use the 'RLOC-Probing' mechanism
described below.When ITRs receive ICMP Network Unreachable or Host Unreachable
messages as a method to determine unreachability,
they will refrain from
using Locators that are described in Locator lists of Map-Replies.
However, using this approach is unreliable because many network
operators turn off generation of ICMP Destination Unreachable
messages.If an ITR does receive an ICMP Network Unreachable or Host
Unreachable message, it MAY originate its own ICMP Destination
Unreachable message destined for the host that originated
the data packet the ITR encapsulated.This assumption does create a dependency: Locator
unreachability is detected by the receipt of ICMP Host
Unreachable messages. When a Locator has been determined
to be unreachable, it is not used for active traffic; this
is the same as if it were listed in a Map-Reply with
Priority 255.The ITR can test the reachability of the unreachable
Locator by sending periodic Requests. Both Requests and
Replies MUST be rate-limited, see and for information about rate-limiting. Locator reachability testing
is never done with data packets, since that increases the
risk of packet loss for end-to-end sessions.RLOC-Probing is a method that an ITR or PITR can use to
determine the reachability status of one or more
Locators that it has cached in a Map-Cache entry. The
probe-bit of the Map-Request and Map-Reply messages is
used for RLOC-Probing.RLOC-Probing is done in the control plane on a
timer basis, where an ITR or PITR will originate a Map-Request
destined to a locator address from one of its
own locator addresses. A Map-Request used as an RLOC-probe
is NOT encapsulated and NOT sent to a Map-Server or to the
mapping database system as one would when requesting mapping data.
The EID record encoded in the Map-Request is the EID-Prefix of
the Map-Cache entry cached by the ITR or PITR. The ITR
MAY include a mapping data record for its own database mapping
information that contains the local EID-Prefixes and RLOCs for
its site. RLOC-probes are sent periodically using a jittered
timer interval. When an ETR receives a Map-Request message with the
probe-bit set, it returns a Map-Reply with the probe-bit
set. The source address of the Map-Reply is set to the IP
address of the outgoing interface the Map-Reply destination
address routes to. The Map-Reply SHOULD contain mapping data
for the EID-Prefix contained in the Map-Request. This provides
the opportunity for the ITR or PITR that sent the RLOC-probe
to get mapping updates if there were changes to the ETR's
database mapping entries.There are advantages and disadvantages of RLOC-Probing.
The main benefit of RLOC-Probing is that it can handle many
failure scenarios allowing the ITR to determine when the path
to a specific Locator is reachable or has become unreachable,
thus providing a robust mechanism for switching to using
another Locator from the cached Locator. RLOC-Probing can
also provide rough Round-Trip Time (RTT) estimates between a
pair of Locators, which can be useful for network management
purposes as well as for selecting low delay paths. The major
disadvantage of RLOC-Probing is in the number of control
messages required and the amount of bandwidth used to obtain
those benefits, especially if the requirement for failure
detection times is very small.An ITR is configured with one or more Map-Resolver addresses.
These addresses are "Locators" (or RLOCs) and MUST be routable
on the underlying core network; they MUST NOT need to be
resolved through LISP EID-to-RLOC mapping, as that would
introduce a circular dependency. When using a Map-Resolver, an
ITR does not need to connect to any other database mapping
system. An ITR sends an Encapsulated Map-Request to a configured
Map-Resolver when it needs an EID-to-RLOC mapping that is not
found in its local Map-Cache. Using the Map-Resolver greatly
reduces both the complexity of the ITR implementation and the
costs associated with its operation. In response to an Encapsulated Map-Request, the ITR can
expect one of the following: An immediate Negative Map-Reply (with action code of
"Natively-Forward", 15-minute Time to Live (TTL)) from the
Map-Resolver if the Map-Resolver can determine that the
requested EID does not exist. The ITR saves the EID-Prefix
returned in the Map-Reply in its cache, marks it as
non-LISP-capable, and knows not to attempt LISP encapsulation
for destinations matching it. A Negative Map-Reply, with action code of
"Natively-Forward", from a Map-Server that is authoritative (within the LISP deployment )
for an EID-Prefix that matches the requested EID but that does
not have an actively registered, more-specific EID-prefix. In
this case, the requested EID is said to match a "hole" in the
authoritative EID-Prefix. If the requested EID matches a
more-specific EID-Prefix that has been delegated by the
Map-Server but for which no ETRs are currently registered, a
1-minute TTL is returned. If the requested EID matches a
non-delegated part of the authoritative EID-Prefix, then it is
not a LISP EID and a 15-minute TTL is returned. See for discussion of aggregate EID-Prefixes and
details of Map-Server EID-Prefix matching. A LISP Map-Reply from the ETR that owns the EID-to-RLOC
mapping or possibly from a Map-Server answering on behalf of
the ETR. See for more details
on Map-Resolver message processing. Note that an ITR may be configured to both use a
Map-Resolver and to participate in a LISP-ALT logical
network. In such a situation, the ITR SHOULD send Map-Requests
through the ALT network for any EID-Prefix learned via ALT BGP.
Such a configuration is expected to be very rare, since there is
little benefit to using a Map-Resolver if an ITR is already
using LISP-ALT. There would be, for example, no need for such an
ITR to send a Map-Request to a possibly non-existent EID (and
rely on Negative Map-Replies) if it can consult the ALT database
to verify that an EID-Prefix is present before sending that
Map-Request. An ETR publishes its EID-Prefixes on a Map-Server by sending
LISP Map-Register messages. A Map-Register message includes
authentication data, so prior to sending a Map-Register message,
the ETR and Map-Server MUST be configured with a pre-shared secret
used to derive Map-Register authentication keys. A Map-Server's
configuration SHOULD also include a list of the EID-Prefixes for
which each ETR is authoritative. Upon receipt of a Map-Register
from an ETR, a Map-Server accepts only EID-Prefixes that are
configured for that ETR. Failure to implement such a check
would leave the mapping system vulnerable to trivial EID-Prefix
hijacking attacks. In addition to the set of EID-Prefixes defined for each ETR
that may register, a Map-Server is typically also configured
with one or more aggregate prefixes that define the part of the
EID numbering space assigned to it. When LISP-ALT is the
database in use, aggregate EID-Prefixes are implemented as
discard routes and advertised into ALT BGP. The existence of
aggregate EID-Prefixes in a Map-Server's database means that it
may receive Map Requests for EID-Prefixes that match an
aggregate but do not match a registered prefix; describes how this is handled. Map-Register messages are sent periodically from an ETR to a
Map-Server with a suggested interval between messages of one
minute. A Map-Server SHOULD time out and remove an ETR's
registration if it has not received a valid Map-Register message
within the past three minutes. When first contacting a
Map-Server after restart or changes to its EID-to-RLOC database
mappings, an ETR MAY initially send Map-Register messages at an
increased frequency, up to one every 20 seconds. This "quick
registration" period is limited to five minutes in
duration. An ETR MAY request that a Map-Server explicitly acknowledge
receipt and processing of a Map-Register message by setting the
"want-map-notify" (M-bit) flag. A Map-Server that receives a
Map-Register with this flag set will respond with a Map-Notify
message. Typical use of this flag by an ETR would be to set it
for Map-Register messages sent during the initial "quick
registration" with a Map-Server but then set it only
occasionally during steady-state maintenance of its association
with that Map-Server. Note that the Map-Notify message is sent
to UDP destination port 4342, not to the source port specified
in the original Map-Register message. Note that a one-minute minimum registration interval during
maintenance of an ETR-Map-Server association places a lower
bound on how quickly and how frequently a mapping database entry
can be updated. This may have implications for what sorts of
mobility can be supported directly by the mapping system;
shorter registration intervals or other mechanisms might be
needed to support faster mobility in some cases. For a
discussion on one way that faster mobility may be implemented
for individual devices, please see . An ETR MAY also request, by setting the "proxy Map-Reply"
flag (P-bit) in the Map-Register message, that a Map-Server
answer Map-Requests instead of forwarding them to the ETR. See
for details on how
the Map-Server sets certain flags (such as those indicating
whether the message is authoritative and how returned Locators
SHOULD be treated) when sending a Map-Reply on behalf of an ETR.
When an ETR requests proxy reply service, it SHOULD include all
RLOCs for all ETRs for the EID-Prefix being registered, along
with the routable flag ("R-bit") setting for each RLOC. The
Map-Server includes all of this information in Map-Reply
messages that it sends on behalf of the ETR. This differs from a
non-proxy registration, since the latter need only provide one
or more RLOCs for a Map-Server to use for forwarding
Map-Requests; the registration information is not used in
Map-Replies, so it being incomplete is not incorrect. An ETR that uses a Map-Server to publish its EID-to-RLOC
mappings does not need to participate further in the mapping
database protocol(s). When using a LISP-ALT mapping database,
for example, this means that the ETR does not need to implement
GRE or BGP, which greatly simplifies its configuration and
reduces its cost of operation. Note that use of a Map-Server does not preclude an ETR from
also connecting to the mapping database (i.e., it could also
connect to the LISP-ALT network), but doing so doesn't seem
particularly useful, as the whole purpose of using a Map-Server
is to avoid the complexity of the mapping database
protocols. Once a Map-Server has EID-Prefixes registered by its client
ETRs, it can accept and process Map-Requests for them. In response to a Map-Request, the Map-Server first checks to see if the
destination EID matches a configured EID-Prefix. If there is no
match, the Map-Server returns a Negative Map-Reply with action
code "Natively-Forward" and a 15-minute TTL. This can occur if a
Map Request is received for a configured aggregate EID-Prefix
for which no more-specific EID-Prefix exists; it indicates the
presence of a non-LISP "hole" in the aggregate EID-Prefix.Next, the Map-Server checks to see if any ETRs have
registered the matching EID-Prefix. If none are found, then the
Map-Server returns a Negative Map-Reply with action code
"Natively-Forward" and a 1-minute TTL.If the EID-prefix is either registered or not registered to
the mapping system and there is a policy in the Map-Server to
have the requestor drop packets for the matching EID-prefix,
then a Drop/Policy-Denied action is returned. If the EID-prefix
is registered or not registered and there is a authentication
failure, then a Drop/Authentication- failure action is
returned. If either of these actions result as a temporary state
in policy or authentication then a Send-Map-Request action with
1-minute TTL MAY be returned to allow the requestor to retry the
Map-Request. If any of the registered ETRs for the EID-Prefix have
requested proxy reply service, then the Map-Server answers the
request instead of forwarding it. It returns a Map-Reply with
the EID-Prefix, RLOCs, and other information learned through the
registration process. If none of the ETRs have requested proxy reply service, then
the Map-Server re-encapsulates and forwards the resulting
Encapsulated Map-Request to one of the registered ETRs. It does
not otherwise alter the Map-Request, so any Map-Reply sent by
the ETR is returned to the RLOC in the Map-Request, not to the
Map-Server. Unless also acting as a Map-Resolver, a Map-Server
should never receive Map-Replies; any such messages SHOULD be
discarded without response, perhaps accompanied by the logging
of a diagnostic message if the rate of Map-Replies is suggestive
of malicious traffic. Upon receipt of an Encapsulated Map-Request, a Map-Resolver
decapsulates the enclosed message and then searches for the
requested EID in its local database of mapping entries
(statically configured or learned from associated ETRs if the
Map-Resolver is also a Map-Server offering proxy reply
service). If it finds a matching entry, it returns a LISP
Map-Reply with the known mapping. If the Map-Resolver does not have the mapping entry and if
it can determine that the EID is not in the mapping database
(for example, if LISP-ALT is used, the Map-Resolver will have an
ALT forwarding table that covers the full EID space), it
immediately returns a negative LISP Map-Reply, with action code
"Natively-Forward" and a 15&nbhy;minute TTL. To minimize the
number of negative cache entries needed by an ITR, the
Map-Resolver SHOULD return the least-specific prefix that both
matches the original query and does not match any EID-Prefix
known to exist in the LISP-capable infrastructure. If the Map-Resolver does not have sufficient information to
know whether the EID exists, it needs to forward the Map-Request
to another device that has more information about the EID being
requested. To do this, it forwards the unencapsulated
Map-Request, with the original ITR RLOC as the source, to the
mapping database system. Using LISP-ALT, the Map-Resolver is
connected to the ALT network and sends the Map-Request to the
next ALT hop learned from its ALT BGP neighbors. The
Map-Resolver does not send any response to the ITR; since the
source RLOC is that of the ITR, the ETR or Map-Server that
receives the Map-Request over the ALT and responds will do so
directly to the ITR. A Map-Resolver can be set up to use "anycast", where the
same address is assigned to multiple Map-Resolvers and is
propagated through IGP routing, to facilitate the use of a
topologically close Map-Resolver by each ITR. ETRs MAY have anycast RLOC addresses which are registered
as part of their RLOC-set to the mapping system. However,
registrations MUST use their unique RLOC addresses, distinct
authentication keys or different XTR-IDs to identify security associations with the
Map-Servers.A LISP threat analysis can be found in . In what follows we highlight security
considerations that apply when LISP is deployed in environments
such as those specified in , where the
following assumptions hold:The Mapping System is secure and trusted, and for the purpose
of this security considerations the Mapping System is considered
as one trusted element.The ETRs have a pre-configured trust relationship with the
Mapping System, which includes some form of shared secret, and the
Mapping System is aware of which EIDs an ETR can advertise. How
those keys and mappings gets established is out of the scope of
this document.LISP-SEC MUST be
implemented. Network operartors should carefully weight how the
LISP-SEC threat model applies to their particular use case or
deployment. If they decide to ignore a particular
recommendation, they should make sure the risk associated with
the corresponding threats is well understood.The Map-Request/Map-Reply message exchange can be exploited by
an attacker to mount DoS and/or amplification attacks. Attackers
can send Map-Requests at high rates to overload LISP nodes and
increase the state maintained by such nodes or consume CPU
cycles. Such threats can be mitigated by systematically applying
filters and rate limiters.The Map-Request/Map-Reply message exchange to inject
forged mappings directly in the ITR EID-to-RLOC map-cache. This
can lead to traffic being redirected to the attacker, see further
details in . In addition, valid ETRs in
the system can perform overclaiming attacks. In this case,
attackers can claim to own an EID-prefix that is larger than the
prefix owned by the ETR. Such attacks can be addressed by using
LISP-SEC . The LISP-SEC protocol
defines a mechanism for providing origin authentication,
integrity, anti-replay, protection, and prevention of
'man-in-the-middle' and 'prefix overclaiming'
attacks on the Map-Request/Map-Reply exchange. In addition and
while beyond the scope of securing an individual Map-Server or
Map-Resolver, it should be noted that LISP-SEC can be complemented
by additional security mechanisms defined by the Mapping System
Infrastructure. For instance, BGP-based LISP-ALT can take advantage of standards work on adding
security to BGP while LISP-DDT defines
its own additional security mechanisms.To publish an authoritative EID-to-RLOC mapping with a
Map-Server using the Map-Register message, an ETR includes
authentication data that is a MAC of the entire message using a
key derived from the pre-shared secret. An implementation MUST support
HMAC-SHA256-128+HKDF-SHA256 . The Map-Register
message includes protection for replay
attacks by a man-in-the-middle. However, a compromised ETR can overclaim
the prefix it owns and successfully register it on its
corresponding Map-Server. To mitigate this and as noted in , a Map-Server MUST verify that all EID-Prefixes
registered by an ETR match the configuration stored on the
Map-Server.Deployments concerned about manipulations of Map-Request and
Map-Reply messages, and malicious ETR EID prefix overclaiming MUST
drop LISP Control Plane messages that do not contain LISP-SEC
material (S-bit, EID-AD, OTK-AD, PKT-AD).Mechanisms to encrypt, support privacy, prevent
eavesdroping and packet tampering for messages
exchanged between xTRs, xTRs and the mapping system, and nodes that
make up the mapping system, SHOULD be deployed. Examples of this are DTLS or
LISP-crypto .As noted by privacy is a complex issue
that greatly depends on the specific protocol use-case and
deployment. As noted in section 1.1 of LISP focuses on use-cases
where entities communicate over the public Internet while keeping
separate addressing and topology. In what follows we detail the
privacy threats introduced by the LISP Control Plane, the analysis
is based on the guidelines detailed in .LISP can use long-lived identifiers (EIDs) that survive
mobility events. Such identifiers bind to the RLOCs of the nodes,
which represents the topological location with respect to the
specific LISP deployments. In addition, EID-to-RLOC mappings are
typically considered public information within the LISP
deployment when control-plane messages are not encrypted, and can
be eavesdropped while Map-Request messages are sent to the
corresponding Map-Resolvers or Map-Register messages to
Map-Servers.In this context, attackers can correlate the EID with the RLOC
and track the corresponding user topological location and/or
mobility. This can be achieved by off-path attackers, if they are
authenticated, by querying the mapping system. Deployments
concerned about this threat can use access control-lists or stronger
authentication mechanisms in
the mapping system to make sure that only authorized users can
access this information (data minimization). Use of ephemeral EIDs
to achieve anonymity is
another mechanism to lessen persistency and identity tracking.For implementation considerations, the following major changes have
been made to this document since RFC 6833 was published:A Map-Notify-Ack message is added in this document to provide
reliability for Map-Notify messages. Any receiver of a
Map-Notify message must respond with a Map-Notify-Ack
message. Map-Servers who are senders of Map-Notify messages,
must queue the Map-Notify contents until they receive a
Map-Notify-Ack with the nonce used in the Map-Notify
message. Note that implementations for Map-Notify-Ack support
already exist and predate this document.This document is incorporating the codepoint for the
Map-Referral message from the LISP-DDT specification to indicate that a Map-Server must send the
final Map-Referral message when it participates in the LISP-DDT
mapping system procedures.The L" and "D" bits are added to the
Map-Request message. See for details.The "S", "I", "E", "T", "a", "R", and "M" bits are added to the
Map-Register message. See for details.The 16-bit Key-ID field of the Map-Register message has been
split into a 8-bit Key-ID field and a 8-bit Algorithm-ID field.The nonce and the authentication data in the Map-Register message
have a different behaviour, see for details.This document adds two new Action values that are in an
EID-record that appear in Map-Reply, Map-Register, Map-Notify,
and Map-Notify-Ack messages. The Drop/Policy-Denied and
Drop/Auth-Failure are the descriptions for the two new action
values. See for details.This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to this
LISP Control-Plane specification, in accordance with BCP 26 .There are three namespaces (listed in the sub-sections below) in
LISP that have been registered.LISP IANA registry allocations should not be made for
purposes unrelated to LISP routing or transport protocols.The following policies are used here with the meanings
defined in BCP 26: "Specification Required", "IETF Review",
"Experimental Use", and "First Come First Served".The IANA registry has allocated UDP port number 4342 for the
LISP Control-Plane. IANA has updated the description for UDP
port 4342 as follows:It is being requested that the IANA be authoritative for LISP
Packet Type definitions and it is requested to replace the registry message references with the RFC
number assigned to this document.Based on deployment experience of ,
the Map-Notify-Ack message, message type 5, was added by this
document. This document requests IANA to add it to the LISP
Packet Type Registry.New ACT values can be allocated through IETF review or IESG
approval. Four values have already been allocated by , IANA is requested to replace the reference for this registry with the RFC
number assigned to this document and the . Action values references with the RFC number
assigned to this document. This specification changes the name
of ACT type 3 value from "Drop" to "Drop/No-Reason" as well as
adding two new ACT values, the "Drop/Policy-Denied" (type 4) and
"Drop/Authentication-Failure" (type 5).ValueActionDescriptionRaeference4Drop/Policy-DeniedA packet matching this Map-Cache entry is dropped because
the target EWID is policy-denied by the xTR or the mapping
system.RFC6833bis5Drop/Auth-FailurePacket matching the Map-Cache entry is dropped beacuse the
Map-Request for the target EID fails an authentication check
by the xTR or the mapping system.RFC6833bisIn addition, LISP has a number of flag fields and reserved
fields, such as the LISP header flags field . New bits for flags in
these fields can be implemented after IETF review or IESG
approval, but these need not be managed by IANA.LISP Canonical Address Format (LCAF)
is an 8-bit field that defines LISP-specific encodings for AFI
value 16387. LCAF encodings are used for specific use-cases
where different address types for EID-records and RLOC-records
are required.The IANA registry "LISP Canonical Address Format (LCAF)
Types" is used for LCAF types. The registry for LCAF types use
the Specification Required policy . Initial values for the registry as well as
further information can be found in .Therefore, there is no longer a need for the "LISP Address Type
Codes" registry requested by . This document
requests to remove it.In , a request for a "LISP Key ID
Numbers" registry was submitted. This document renames the
registry to "LISP Algorithm ID Numbers" and requests the IANA to
make the name change.The following Algorithm ID values are defined by this
specification as used in any packet type that references a
'Algorithm ID' field:Number values are in the range of 0 to 255. The allocation of
values is on a first come first served basis.This document asks IANA to create a registry for allocation
of bits in several headers of the LISP control plane, namely in
the Map-Request, Map-Reply, Map-Register, Encapsulated Control
Message (ECM) messages. Bit allocations are also requested for
EID-records and RLOC-records. The registry created should
be named "LISP Control Plane Header Bits". A sub-registry
needs to be created per each message and EID-record. The name of each
sub-registry is indicated below, along with its format
and allocation of bits defined in this document. Any additional
bits allocation, requires a specification, according with policies.Sub-Registry: Map-Request Header Bits []:Spec NameIANA NameBit PositionDescriptionAmap-request-A4Authoritative BitMmap-request-M5Map Data Present BitPmap-request-P6RLOC-Probe Request BitSmap-request-S7Solicit Map-Request (SMR)
Bitpmap-request-p8Proxy-ITR Bitsmap-request-s9Solicit Map-Request Invoked
BitLmap-request-L17Local xTR BitDmap-request-D18Don't Map-Reply BitSub-Registry: Map-Reply Header Bits []:Spec NameIANA NameBit PositionDescriptionPmap-reply-P4RLOC-Probe BitEmap-reply-E5Echo Nonce Capable BitSmap-reply-S6Security BitSub-Registry: Map-Register Header Bits []:Spec NameIANA NameBit PositionDescriptionPmap-register-P4Proxy Map-Reply BitSmap-register-S5LISP-SEC Capable BitImap-register-I6xTR-ID present flagSub-Registry: Encapsulated Control Message (ECM) Header Bits
[]:Spec NameIANA NameBit PositionDescriptionSecm-S4Security BitDecm-D5LISP-DDT BitEecm-E6Forward to ETR BitMecm-M7Destined to Map-Server BitSub-Registry: EID-Record Header Bits []:Spec NameIANA NameBit PositionDescriptionAeid-record-A19Authoritative BitSub-Registry: RLOC-Record Header Bits []:Spec NameIANA NameBit PositionDescriptionLrloc-record-L13Local RLOC Bitprloc-record-p19RLOC-Probe Reply BitRrloc-record-R19RLOC Reachable BitAddress Family Identifier (AFIs)General Packet Radio System (GPRS) Tunnelling Protocol
User Plane (GTPv1-U)The original authors would like to thank Greg Schudel, Darrel Lewis,
John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper
Skriver, Fabio Maino, and members of the lisp@ietf.org mailing
list for their feedback and helpful suggestions. Special thanks are due to Noel Chiappa for his extensive work
and thought about caching in Map-Resolvers.The current authors would like to give a sincere thank you to
the people who help put LISP on standards track in the IETF. They
include Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio
Maino, Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks,
Pete Resnick, Colin Perkins, Mirja Kuhlewind, Francis Dupont,
Benjamin Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov,
Alissa Cooper, Suresh Krishnan, Alberto Rodriguez-Natal, Vina
Ermagen, Mohamed Boucadair, Brian Trammell, Sabrina Tanamal, and
John Drake. The contributions they offered greatly added to the
security, scale, and robustness of the LISP architecture and
protocols.[RFC Editor: Please delete this section on publication as RFC.]Posted November 2019.Fixed the required (MUST implement) authentcation algorithms.Fixed a large set of minor comments and edits.Posted June 2019.Added change requested by Mirja describing Record Count in
an EID-record.Fixed Requirements Notation section per Pete.Added KDF for shared-secretSpecified several rate-limiters for control messagesPosted February 2019.Added suggested text from Albert that Benjamin Kaduk agreed
with.Added suggested editorial comments from Alvaro's rewview.Ran document through IDnits. Fixed bugs found.Posted December 2018.Added to Security Considerations section that deployments that
care about prefix over claiming should use LISP-SEC.Added to Security Considerations section that DTLS or LISP-crypto
be used for control-plane privacy.Make LISP-SEC a normative reference.Make it more clear where field descriptions are spec'ed when
referencing to the same fields in other packet types.Posted week after IETF November 2018.No longer need to use IPSEC for replay attacks.Posted early November 2018.Added I-bit back in because its necessary to use for Map-Register
replay attack scenarios. The Map-Server tracks the nonce per xTR-ID
to detect duplicate or replayed Map-Register messages.Posted late October 2018.Changed description about "reserved" bits to state "reserved and
unassigned".Make it more clear how Map-Register nonce processing is
performed in an ETR and Map-Server.Posted mid October 2018.Added Fabio text to the Security Considerations section.Posted mid October 2018.Fixed comments from Eric after more email clarity.Posted early October 2018.Changes to reflect comments from Sep 27th Telechat.Added all flag bit definitions as request for allocation in
IANA Considersations section.Added an applicability statement in section 1 to address
security concerns from Telechat.Moved m-bit description and IANA request to
draft-ietf-lisp-mn.Moved I-bit description and IANA request to
draft-ietf-lisp-pubsub.Posted Late-September 2018.Re-wrote Security Considerations section. Thanks Albert.Added Alvaro text to be more clear about IANA actions.Posted mid-September 2018.Changes to reflect comments from Colin and Mirja.Posted September 2018.Changes to reflect comments from Genart, RTGarea, and
Secdir reviews.Posted August 2018.Final editorial changes before RFC submission for Proposed
Standard.Added section "Changes since RFC 6833" so implementators
are informed of any changes since the last RFC publication.Posted late July 2018.Moved RFC6830bis and RFC6834bis to Normative References.Posted July 2018.Fixed Luigi editorial comments to ready draft for RFC status and
ran through IDNITs again.Posted after LISP WG at IETF week March.Move AD field encoding after S-bit in the ECM packet format
description section.Say more about when the new Drop actions should be sent.Posted March IETF week 2018.Fixed editorial comments submitted by document shepherd Luigi
Iannone.Posted March 2018.Added RLOC-probing algorithm.Added Solicit-Map Request algorithm.Added several mechanisms (from 6830bis) regarding Routing
Locator Reachability.Added port 4342 to IANA Considerations section.Posted December 2017.Make it more clear in a couple of places that RLOCs are
used to locate ETRs more so than for Map-Server Map-Request
forwarding.Make it clear that "encapsualted" for a control message is
an ECM based message.Make it more clear what messages use source-port 4342 and
which ones use destinatino-port 4342.Don't make DDT references when the mapping transport system
can be of any type and the referneced text is general to
it.Generalize text when referring to the format of an
EID-prefix. Can use othe AFIs then IPv4 and IPv6.Many editorial changes to clarify text.Changed some "must", "should", and "may" to capitalized.Added definitions for Map-Request and Map-Reply messages.Ran document through IDNITs.Posted October 2017.Spec the I-bit to include the xTR-ID in a Map-Request
message to be consistent with the Map-Register message and to
anticipate the introduction of pubsub functionality to allow
Map-Requests to subscribe to RLOC-set changes.Updated references for individual submissions that became
working group documents.Updated references for working group documents that became RFCs.Posted May 2017.Update IANA Considerations section based on new requests
from this document and changes from what was requested in
.Posted May 2017.Clarify how the Key-ID field is used in Map-Register and
Map-Notify messages. Break the 16-bit field into a 8-bit
Key-ID field and a 8-bit Algorithm-ID field.Move the Control-Plane codepoints from the IANA
Considerations section of RFC6830bis to the IANA
Considerations section of this document.In the "LISP Control Packet Type Allocations" section,
indicate how message Types are IANA allocated and how
experimental RFC8113 sub-types should be requested.Posted April 2017.Add types 9-14 and specify they are not assigned.Add the "LISP Shared Extension Message" type and point to
RFC8113.Posted April 2017.Clarify that the LISP Control-Plane document defines how
the LISP Data-Plane uses Map-Requests with either the SMR-bit
set or the P-bit set supporting mapping updates and
RLOC-probing. Indicating that other Data-Planes can use the
same mechanisms or their own defined mechanisms to achieve the
same functionality.Posted March 2017.Include references to new RFCs published.Remove references to self.Change references from RFC6830 to RFC6830bis.Add two new action/reasons to a Map-Reply has posted to the
LISP WG mailing list.In intro section, add refernece to
I-D.ietf-lisp-introduction.Removed Open Issues section and references to
"experimental".Posted December 2016.Created working group document from draft-farinacci-lisp
-rfc6833-00 individual submission. No other changes made.Posted November 2016.This is the initial draft to turn RFC 6833 into RFC
6833bis.The document name has changed from the "Locator/ID
Separation Protocol (LISP) Map-Server Interface" to the
"Locator/ID Separation Protocol (LISP) Control-Plane".The fundamental change was to move the Control-Plane
messages from RFC 6830 to this document in an effort so any
IETF developed or industry created Data-Plane could use the
LISP mapping system and Control-Plane.Update Control-Plane messages to incorporate what has been
implemented in products during the early phase of LISP
development but wasn't able to make it into RFC6830 and
RFC6833 to make the Experimental RFC deadline.Indicate there may be nodes in the mapping system that are
not MRs or MSs, that is a ALT-node or a DDT-node.Include LISP-DDT in Map-Resolver section and explain how
they maintain a referral-cache.Removed open issue about additional state in Map-Servers.
With , Map-Servers have the same
registration state and can give Map-Resolvers complete
information in ms-ack Map-Referral messages.Make reference to the LISP Threats Analysis RFC
.