A Decent LISP Mapping System (LISP-Decent)lispers.netSan JoseCAUSAfarinacci@gmail.comNexusTempeAZUSAcolin@nexus.ioThis draft describes how the LISP mapping system designed to be
distributed for scale can also be decentralized for management and
trust.The LISP architecture and protocols
introduces two new numbering spaces, Endpoint Identifiers (EIDs)
and Routing Locators (RLOCs) which is intended to provide overlay
network functionality. To map from EID to a set or RLOCs, a
control-plane mapping system are used . These mapping systems are distributed in
nature in their deployment for scalability but are centrally
managed by a third- party entity, namely a Mapping System Provider
(MSP). The entities that use the mapping system, such as
data-plane xTRs, depend on and trust the MSP. They do not participate
in the mapping system other than to register and retrieve information
to/from the mapping system .This document introduces a Decentralized Mapping System (DMS)
so the xTRs can participate in the mapping system as well as use
it. They can trust each other rather than rely on third-party
infrastructure. The xTRs act as Map-Servers to maintain
distributed state for scale and reducing attack surface.is an
infrastructure service that deploys LISP Map-Resolvers and
Map-Servers and possibly ALT-nodes
or DDT-nodes . The MSP can be managed by a separate
organization other than the one that manages xTRs. This model provides
a business separation between who manages and is responsible for
the control-plane versus who manages the data-plane overlay service.is a mapping
system entity that is not third-party to the xTR nodes that use
it. The xTRs themselves are part of the mapping system. The
state of the mapping system is fully distributed, decentralized,
and the trust relies on the xTRs that use and participate in their own
mapping system.the mapping system is
pull-based meaning that xTRs will lookup and register mappings
by algorithmic transformation to locate which Map-Resolvers and
Map-Servers are used. It is required that the lookup and
registration uses a consistent algorithmic transformation
function. Map-Registers are pushed to specific Map-Servers.
Map-Requests are external lookups to Map-Resolvers on xTRs that do
not participate in the mapping system and internal lookups when
they do.this value is used in the Pull-Based
Mapping System. It defines the number of map-server sets used for
the mapping system. The modulus value is used to produce a Name Index
used for a DNS lookup.this index value <index> is used in
the Pull-Based Mapping System. For a mapping system that is
configured with a map-server set of DNS names in the form of
<name>.domain.com, the name index is prepended to <name> to
form the lookup name <index>.<name>.domain.com. If
the Modulus Value is 8, then the name indexes are 0 through 7.The Hash Mask is used in the Pull-Based
Mapping System. It is a mask value with 1 bits left justified.
The mask is used to select what high-order bits of an EID-prefix is
used in the hash function.the mapping system is
push-based meaning that xTRs will push registrations via IP
multicast to a group of Map-Servers and do local lookups acting
as their own Map-Resolvers.is an RLOC-record
format that contains a list of RLOCs that an ITR replicates
multicast packets on a multicast overlay. The RLE format is
specified in . RLEs are used with the
Pushed-Based mapping system.is an EID-record format that contains
IPv4 (0.0.0.0/0, G) or IPv6 (0::/0, G) state. This state is encoded as a
Multicast Info Type LCAF specified in . Members
of a seed-group send Map-Registers for (0.0.0.0/0, G) or (0::/0, G)
with an RLOC-record that RLE encodes its RLOC address. Details are
specified in .is a set of Map-Servers joined to a
multicast group for the Push-Based Mapping system or are mapped
by DNS names in a Pull-Based Mapping System. A core seed-group is used
to bootstrap a set of LISP-Decent xTRs so they can learn about each
other and use each other's mapping system service. A seed-group can
be pull-based to bootstrap a push-based mapping system. That is,
a set of DNS mapped map-servers can be used to join the mapping
system's IP multicast group.The clients of the Decentralized Mapping System (DMS) are also
the providers of mapping state. Clients are typically ETRs that
Map-Register EID-to-RLOC mapping state to the mapping database
system. ITRs are clients in that they send Map-Requests to the
mapping database system to obtain EID-to-RLOC mappings that are
cached for data-plane use. When xTRs participate in a DMS, they
are also acting as Map-Resolvers and Map-Servers using the
protocol machinery defined in LISP control-plane specifications , , and . The xTRs are not
required to run the database mapping transport system protocols
specified in or .This document will describe two decentralized and distributed mapping
system mechanisms. A Push-Based Mapping System uses IP multicast so
xTRs can find each other by locally joining an IP multicast group. A
Pull-Based Mapping System uses DNS with an algorithmic transformation
function so xTRs can find each other.The xTRs are organized in a mapping-system group. The group is
identified by an IPv4 or IPv6 multicast group address or using a
pull-based approach in described in . When
using multicast, the xTRs join the same multicast group and
receive LISP control-plane messages addressed to the
group. Messages sent to the multicast group are distributed when
the underlay network supports IP multicast or is achieved with the overlay multicast
mechanism described in . When overlay
multicast is used and LISP Map-Register messages are sent to the
group, they are LISP data encapsulated with a instance-ID set to
0xffffff in the LISP header. The inner header of the encapsulated
packet has the destination address set to the multicast group
address and the outer header that is prepended has the destination
address set to the RLOC of mapping system member. The members of
the mapping system group are kept in the LISP data-plane map-cache
so packets for the group can be replicated to each member
RLOC.All xTRs in a mapping system group will store the same
registered mappings and maintain the state as Map-Servers normally
do. The members are not only receivers of the multicast group but
also send packets to the group.When an xTR is configured to be a LISP-Decent xTR (or PxTR
), it runs the ITR, ETR, Map-Resolver,
and Map-Server LISP network functions.The following diagram shows 3 LISP-Decent xTRs joined to
mapping system group 224.1.1.1. When the ETR function of xTR1
originates a Map-Register, it is sent to all xTRs (including
itself) synchronizing all 3 Map-Servers in xTR1, xTR2, and
xTR3. The ITR function can populate its map-cache by sending a
Map-Request locally to its Map-Resolver so it can replicate
packets to each RLOC for EID 224.1.1.1.| MR/MS |<---------------+ RLOCs xTR1, xTR2, and xTR3
| +-------+ | |
+--------------------+ |
|
+--------------------+------------+
| |
| |
+----------v---------+ +----------v---------+
| +--------+ | | +--------+ |
| | MR/MS | | | | MR/MS | |
| +--------+ | | +--------+ |
| +-----+ +-----+ | | +-----+ +-----+ |
| | ITR | | ETR | | | | ITR | | ETR | |
| +-----+ +-----+ | | +-----+ +-----+ |
+--------------------+ +--------------------+
xTR2 xTR3
]]>Note if any external xTR would like to use a Map-Resolver
from the mapping system group, it only needs to have one of the
LISP-Decent Map-Resolvers configured. By doing a looking to this
Map-Resolver for EID 224.1.1,1, the external xTR could get the
complete list of members for the mapping system group.For future study, an external xTR could multicast the
Map-Request to 224.1.1.1 and either one of the LISP-Decent
Map-Resolvers would return a Map-Reply or the external xTR is
prepared to receive multiple Map-Replies.There are no LISP protocol changes required to support the
push-based LISP-Decent set of procedures. However, an implementation
that sends Map-Register messages to a multicast group versus a
specific Map-Server unicast address must change to call the
data-plane component so the ITR functionality in the node can
encapsulate the Map-Register as a unicast packet to each member
of the mapping system group.An ITR SHOULD lookup its mapping system group address
periodically to determine if the membership has changed. The ITR
can also use the pubsub capability documented in to be notified when a new member
joins or leaves the multicast group.When xTRs are joined to a multicast group, they must have
their site registration configuration consistent. Any policy or
authentication key material must be configured correctly and
consistently among all members. When is used to sign Map-Register
messages, public-keys can be registered to the mapping system
group using the site authentication key mentioned above or using
a different authentication key from the one used for registering
EID records.A core seed-group can be discovered using a multicast group in
a push-based system or a Map-Server set of DNS names in a pull-based
system (see for details).When using multicast for the mapping system group, a core seed-group
multicast group address can be preconfigured to bootstrap the
decentralized mapping system. The group address (or DNS name
that maps to a group address) can be explicitly configured in a
few xTRs to start building up the registrations. Then as other xTRs
come online, they can add themselves to the core seed-group by
joining the seed-group multicast group.Alternatively or additionally, new xTRs can join a new
mapping system multicast group to form another layer of a
decentralized mapping system. The group address and members of
this new layer seed-group would be registered to the core
seed-group address and stored in the core seed-group mapping
system. Note each mapping system layer could have a specific
function or a specific circle of trust.This multi-layer mapping system can be illustrated: | I |
| 224.1.1.1 | | / \ |
\__________/ | J---K |
| \_________/
| 224.3.3.3
|
v
---------
/ layer-2 \
| X |
| / \ |
| Y---Z |
\_________/
Configured in xTRs A, B, and C (they make up the core seed-group):
224.1.1.1 -> RLE: A, B, C
core seed-group DMS, mapping state in A, B, and C:
224.2.2.2 -> RLE: I, J, K
224.3.3.3 -> RLE: X, Y, Z
layer-1 seed-group DMS (inter-continental), mapping state in I, J, K:
EID1 -> RLOCs: i(1), j(2)
...
EIDn -> RLOCs: i(n), j(n)
layer-2 seed-group DMS (intra-continental), mapping sate in X, Y, Z::
EIDa -> RLOCs: x(1), y(2)
...
EIDz -> RLOCs: x(n), y(n)
]]>The core seed-group multicast address 224.1.1.1 is configured
in xTRs A, B and C so when each of them send Map-Register
messages, they would all be able to maintain synchronized
mapping state. Any EID can be registered to this DMS but in this
example, seed-group multicast group EIDs are being registered
only to find other mapping system groups.For example, lets say that xTR I boots up and it wants to
find its other peers in its mapping system group
224.2.2.2. Group address 224.2.2.2 is configured so xTR I knows
what group to join for its mapping system group. But xTR I needs
a mapping system to register to, so the core seed-group is used
and available to receive Map-Registers. The other xTRs J and K
in the mapping system group do the same so when any of I, J or K
needs to register EIDs, they can now send their Map-Register
messages to group 224.2.2.2. Examples of EIDs being register are
EID1 through EIDn shown above.When Map-Registers are sent to group 224.2.2.2, they are
encapsulated by the LISP data-plane by looking up EID 224.2.2.2
in the core seed-group mapping system. For the map-cache entry
to be populated for 224.2.2.2, the data-plane must send a
Map-Request so the RLOCs I, J, and K are cached for
replication. To use the core seed-group mapping system, the
data-plane must know of at least one of the RLOCs A, B, and/or
C.When an xTR is configured to be a LISP-Decent xTR (or PxTR
), it runs the ITR, ETR, Map-Resolver,
and Map-Server LISP network functions.Unlike the Push-Based Mapping System, the xTRs do not need to
be organized by joining a multicast group. In a Pull-Based
Mappig System, a hash function over an EID is used to identify
which xTR is used as the Map-Resolver and Map-Server. The Domain
Name System (DNS) is used as a resource discovery mechanism.The RLOC addresses of the xTRs will be A and AAAA records for
DNS names that map algorithmically from the hash of the EID. A
SHA-256 hash function over the
following ASCII formatted EID string is used:]/
[]/-/
]]>Where <iid> is the instance-ID and <eid> is the
EID of any EID-type defined in . And
then the Modulus Value <mv> is used to produce the Name
Index <index> used to build the DNS lookup name:]/"
index = hash.sha_256(eid) MOD mv
]]>The Hash Mask is used to select what bits are used in the
SHA-256 hash function. This is required to support longest match
lookups in the mapping system. The same map-server set needs to be
selected when looking up a more-specific EID found in the
Map-Request message with one that could match a less-specific
EID-prefix registered and found in the Map-Register message. For
example, if an EID-prefix [0]240.0.1.0/24 is registered to the
mapping system and EID [0]240.0.1.1/32 is looked up to match the
registered prefix, a Hash Mask of 8 bytes can be used to AND both
the /32 or /24 entries to produce the same hash string bits
of "[0]240.0".For (*,G) and (S,G) multicast entries in the mapping system,
the hash strings are:]/-/"
index = hash.sha_256(sg-eid) MOD mv
starg-eid = "[]/-0.0.0.0/0"
index = hash.sha_256(starg-eid) MOD mv
]]>The Hash Mask MUST include the string
"[<iid>]<group>" and not string <source>. So
when looking up [0](2.2.2.2, 224.1.1.1) that will match a (*,
224.1.1.1/32), the hash string produced with a Hash Mask of 12
bytes is "[0]224.1.1.1".When the <index> is computed from a unicast or multicast EID,
the DNS lookup name becomes:.map-server.domain.com
]]>When an xTR does a DNS lookup on the lookup name, it will send
Map-Register messages to all A and AAAA records for EID
registrations. For Map-Request messages, xTRs MAY round robin EID
lookup requests among the A and AAAA records.Here is an example deployment of a pull-based model. Let's
say 4 map-server sets are provisioned for the mapping system.
Therefore 4 distinct DNS names are allocated and a Modulus Value 4
is used. Each DNS name is allocated Name Index 0 through 3:The A records for each name can be assigned as:
A
1.map-server.lispers.net:
A
A
2.map-server.lispers.net:
A
A
3.map-server.lispers.net:
A
A
]]>When an xTR wants to register "[1000]fd::2222", it hashes the
EID string to produce, for example, hash value 0x66. Using the
modulus value 4 (0x67 & 0x3) produces index 0x3, so the DNS name
3.map-server.lispers.net is used and a Map-Regiter is sent to
<rloc1-au> and <rloc2-nz>.Note that the pull-based method can be used for a core
seed-group for bootstraping a push-based mapping system where
multicast groups are registered.There are no LISP protocol changes required to support the
pull-based LISP-Decent set of procedures. However, an implementation
SHOULD do periodic DNS lookups to determine if A records have
changed for a DNS entry.When xTRs derive Map-Resolver and Map-Server names from the DNS,
they need to use the same Modulus Value otherwise some xTRs will lookup
EIDs to the wrong place they were registered.The Modulus Value can be configured or pushed to the LISP-Decent xTRs.
A future version of this document will describe a push mechanism so all
xTRs use a consistent modulus value.Refer to the Security Considerations section of for a complete list of security
mechanisms as well as pointers to threat analysis drafts.At this time there are no specific requests for IANA.The authors would like to thank the LISP WG for their review
and acceptance of this draft.The authors would also like to give a special thanks to Roman
Shaposhnik for several discussions that occured before the first
draft was published.[RFC Editor: Please delete this section on publication as RFC.]Posted February 2023.Update references and document expiry timer.Posted August 2022.Update references and document expiry timer.Posted February 2022.Update references and document expiry timer.Posted August 2021.Update references and document expiry timer.Posted March 2021.Update references and document expiry timer.Posted September 2020.Update references and document expiry timer.Posted March 2020.Update references and document expiry timer.Posted September 2019.Update references and document expiry timer.Posted March 2019.Introduce the Hash Mask which is used to grab common bits from
a registered prefix and a lookup prefix.Spec how multicast lookups are done in the pull-based mapping
system.Indicate the hash string includes the unicast EID mask-length
and multicast group and source mask-lengths.Posted November 2018.Changed references from peer-group to seed-group to make the
algorithms in this document more like how blockchain networks
initialize the peer-to-peer network.Added pull mechanism to compliment the push mechanism. The
pull mechanism could be used as a seed-group to bootstrap the
push mechanism.Posted July 2018.Document timer and reference update.Initial draft posted January 2018.