11. Multicast Considerations
A multicast group address, as defined in the original Internet
architecture, is an identifier of a grouping of topologically
independent receiver host locations. The address encoding itself
does not determine the location of the receiver(s). The multicast
routing protocol, and the network-based state the protocol creates,
determine where the receivers are located.
In the context of LISP, a multicast group address is both an EID and
a Routing Locator. Therefore, no specific semantic or action needs
to be taken for a destination address, as it would appear in an IP
header. Therefore, a group address that appears in an inner IP
header built by a source host will be used as the destination EID.
The outer IP header (the destination Routing Locator address),
prepended by a LISP router, will use the same group address as the
destination Routing Locator.
Having said that, only the source EID and source Routing Locator need
to be dealt with. Therefore, an ITR merely needs to put its own IP
address in the source 'Routing Locator' field when prepending the
outer IP header. This source Routing Locator address, like any other
Routing Locator address, MUST be globally routable.
Therefore, an EID-to-RLOC mapping does not need to be performed by an
ITR when a received data packet is a multicast data packet or when
processing a source-specific Join (either by IGMPv3 or PIM). But the
source Routing Locator is decided by the multicast routing protocol
in a receiver site. That is, an EID-to-RLOC translation is done at
Another approach is to have the ITR not encapsulate a multicast
packet and allow the packet built by the host to flow into the core
even if the source address is allocated out of the EID namespace. If
the RPF-Vector TLV [RFC5496] is used by PIM in the core, then core
routers can RPF to the ITR (the locator address, which is injected
into core routing) rather than the host source address (the EID
address, which is not injected into core routing).
To avoid any EID-based multicast state in the network core, the first
approach is chosen for LISP-Multicast. Details for LISP-Multicast
and interworking with non-LISP sites are described in [RFC6831] and
12. Security Considerations
It is believed that most of the security mechanisms will be part of
the mapping database service when using control-plane procedures for
obtaining EID-to-RLOC mappings. For data-plane-triggered mappings,
as described in this specification, protection is provided against
ETR spoofing by using route-returnability (see Section 3) mechanisms
evidenced by the use of a 24-bit 'Nonce' field in the LISP
encapsulation header and a 64-bit 'Nonce' field in the LISP control
The nonce, coupled with the ITR accepting only solicited Map-Replies,
provides a basic level of security, in many ways similar to the
security experienced in the current Internet routing system. It is
hard for off-path attackers to launch attacks against these LISP
mechanisms, as they do not have the nonce values. Sending a large
number of packets to accidentally find the right nonce value is
possible but would already by itself be a denial-of-service (DoS)
attack. On-path attackers can perform far more serious attacks, but
on-path attackers can launch serious attacks in the current Internet
as well, including eavesdropping, blocking, or redirecting traffic.
See more discussion on this topic in Section 188.8.131.52.
LISP does not rely on a PKI or a more heavyweight authentication
system. These systems challenge one of the primary design goals of
LISP -- scalability.
DoS attack prevention will depend on implementations rate-limiting
Map-Requests and Map-Replies to the control plane as well as
rate-limiting the number of data-triggered Map-Replies.
An incorrectly implemented or malicious ITR might choose to ignore
the Priority and Weights provided by the ETR in its Map-Reply. This
traffic-steering would be limited to the traffic that is sent by this
ITR's site and no more severe than if the site initiated a bandwidth
DoS attack on (one of) the ETR's ingress links. The ITR's site would
typically gain no benefit from not respecting the Weights and would
likely receive better service by abiding by them.
To deal with map-cache exhaustion attempts in an ITR/PITR, the
implementation should consider putting a maximum cap on the number of
entries stored with a reserve list for special or frequently accessed
sites. This should be a configuration policy control set by the
network administrator who manages ITRs and PITRs. When overlapping
EID-Prefixes occur across multiple Map-Cache entries, the integrity
of the set must be wholly maintained. So, if a more-specific entry
cannot be added due to reaching the maximum cap, then none of the
less-specific entries should be stored in the map-cache.
Given that the ITR/PITR maintains a cache of EID-to-RLOC mappings,
cache sizing and maintenance are issues to be kept in mind during
implementation. It is a good idea to have instrumentation in place
to detect thrashing of the cache. Implementation experimentation
will be used to determine which cache management strategies work
best. In general, it is difficult to defend against cache-thrashing
attacks. It should be noted that an undersized cache in an ITR/PITR
not only causes adverse effects on the site or region it supports but
may also cause increased Map-Request loads on the mapping system.
"Piggybacked" mapping data as discussed in Section 6.1.3 specifies
how to handle such mappings and includes the possibility for an ETR
to temporarily accept such a mapping before verification when running
in "trusted" environments. In such cases, there is a potential
threat that a fake mapping could be inserted (even if only for a
short period) into a map-cache. As noted in Section 6.1.3, an ETR
MUST be specifically configured to run in such a mode and might
usefully only consider some specific ITRs as also running in that
same trusted environment.
There is a security risk implicit in the fact that ETRs generate the
EID-Prefix to which they are responding. An ETR can claim a shorter
prefix than it is actually responsible for. Various mechanisms to
ameliorate or resolve this issue will be examined in the future
Spoofing of inner-header addresses of LISP-encapsulated packets is
possible, as with any tunneling mechanism. ITRs MUST verify the
source address of a packet to be an EID that belongs to the site's
EID-Prefix range prior to encapsulation. An ETR must only
decapsulate and forward datagrams with an inner-header destination
that matches one of its EID-Prefix ranges. If, upon receipt and
decapsulation, the destination EID of a datagram does not match one
of the ETR's configured EID-Prefixes, the ETR MUST drop the datagram.
If a LISP-encapsulated packet arrives at an ETR, it SHOULD compare
the inner-header source EID address and the outer-header source RLOC
address with the mapping that exists in the mapping database. Then,
when spoofing attacks occur, the outer-header source RLOC address can
be used to trace back the attack to the source site, using existing
This experimental specification does not address automated key
management (AKM). BCP 107 [RFC4107] provides guidance in this area.
In addition, at the time of this writing, substantial work is being
undertaken to improve security of the routing system [RFC6518]
[RFC6480] [BGP-SEC] [LISP-SEC]. Future work on LISP should address
the issues discussed in BCP 107 as well as other open security
considerations, which may require changes to this specification.
13. Network Management Considerations
Considerations for network management tools exist so the LISP
protocol suite can be operationally managed. These mechanisms can be
found in [LISP-MIB] and [RFC6835].
14. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the LISP
specification, in accordance with BCP 26 [RFC5226].
There are four namespaces (listed in the sub-sections below) in LISP
that have been registered.
o LISP IANA registry allocations should not be made for purposes
unrelated to LISP routing or transport protocols.
o The following policies are used here with the meanings defined in
BCP 26: "Specification Required", "IETF Review", "Experimental
Use", and "First Come First Served".
14.1. LISP ACT and Flag Fields
New ACT values (Section 6.1.4) can be allocated through IETF review
or IESG approval. Four values have already been allocated by this
specification (Section 6.1.4).
In addition, LISP has a number of flag fields and reserved fields,
such as the LISP header flags field (Section 5.3). New bits for
flags in these fields can be implemented after IETF review or IESG
approval, but these need not be managed by IANA.
14.2. LISP Address Type Codes
LISP Address [LCAF] type codes have a range from 0 to 255. New type
codes MUST be allocated consecutively, starting at 0. Type Codes
0-127 are to be assigned by IETF review or IESG approval.
Type Codes 128-255 are available according to the [RFC5226] First
Come First Served policy.
This registry, initially empty, is constructed for future use in
experimental work related to LISP Canonical Address Format (LCAF)
values. See [LCAF] for details of other possible unapproved address
encodings. The unapproved LCAF encodings are an area for further
study and experimentation.
14.3. LISP UDP Port Numbers
The IANA registry has allocated UDP port numbers 4341 and 4342 for
lisp-data and lisp-control operation, respectively. IANA has updated
the description for UDP ports 4341 and 4342 as follows:
lisp-data 4341 udp LISP Data Packets
lisp-control 4342 udp LISP Control Packets
14.4. LISP Key ID Numbers
The following Key ID values are defined by this specification as used
in any packet type that references a 'Key ID' field:
Name Number Defined in
None 0 n/a
HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC4868]
Number values are in the range of 0 to 65535. The allocation of
values is on a first come first served basis.
15. Known Open Issues and Areas of Future Work
As an experimental specification, this work is, by definition,
incomplete. Specific areas where additional experience and work are
needed include the following:
o At present, only [RFC6836] is defined for implementing a database
of EID-to-RLOC mapping information. Additional research on other
mapping database systems is strongly encouraged.
o Failure and recovery of LISP site partitioning (see Section 6.4)
in the presence of redundant configuration (see Section 8.5) needs
further research and experimentation.
o The characteristics of map-cache management under exceptional
conditions, such as denial-of-service attacks, are not fully
understood. Further experience is needed to determine whether
current caching methods are practical or in need of further
development. In particular, the performance, scaling, and
security characteristics of the map-cache will be discovered as
part of this experiment. Performance metrics to be observed are
packet reordering associated with the LISP Data-Probe and loss of
the first packet in a flow associated with map-caching. The
impact of these upon TCP will be observed. See Section 12 for
additional thoughts and considerations.
o Preliminary work has been done to ensure that sites employing LISP
can interconnect with the rest of the Internet. This work is
documented in [RFC6832], but further experimentation and
experience are needed.
o At present, no mechanism for automated key management for message
authentication is defined. Addressing automated key management is
necessary before this specification can be developed into a
Standards Track RFC. See Section 12 for further details regarding
o In order to maintain security and stability, Internet protocols
typically isolate the control and data planes. Therefore, user
activity cannot cause control-plane state to be created or
destroyed. LISP does not maintain this separation. The degree to
which the loss of separation impacts security and stability is a
topic for experimental observation.
o LISP allows for the use of different mapping database systems.
While only one [RFC6836] is currently well defined, each mapping
database will likely have some impact on the security of the
EID-to-RLOC mappings. How each mapping database system's security
properties impact LISP overall is for further study.
o An examination of the implications of LISP on Internet traffic,
applications, routers, and security is needed. This will help
implementors understand the consequences for network stability,
routing protocol function, routing scalability, migration and
backward compatibility, and implementation scalability (as
influenced by additional protocol components; additional state;
and additional processing for encapsulation, decapsulation, and
o Experiments need to verify that LISP produces no significant
change in the behavior of protocols run between end-systems over a
LISP infrastructure versus being run directly between those same
o Experiments need to verify that the issues raised in the Critique
section of [RFC6115] are either insignificant or have been
addressed by updates to LISP.
Other LISP documents may also include open issues and areas for
16.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868,
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010.
[RFC6115] Li, T., "Recommendation for a Routing Architecture",
RFC 6115, February 2011.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833,
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834,
[RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013.
16.2. Informative References
[AFI] IANA, "Address Family Numbers",
[BGP-SEC] Lepinski, M. and S. Turner, "An Overview of BGPSEC", Work
in Progress, May 2012.
[CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed
Enhancement to the Internet Architecture", 1999,
[CONS] Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis,
D., and D. Meyer, "LISP-CONS: A Content distribution
Overlay Network Service for LISP", Work in Progress,
[EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
Mappings Multicast Across Cooperating Systems for LISP",
Work in Progress, November 2007.
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", Work in Progress, January 2013.
[LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin,
"Renumbering: Threat or Menace?", Usenix Tenth System
Administration Conference (LISA 96), October 1996.
Jakab, L., Cabellos-Aparicio, A., Coras, F.,
Domingo-Pascual, J., and D. Lewis, "LISP Network Element
Deployment Considerations", Work in Progress,
[LISP-MIB] Schudel, G., Jain, A., and V. Moreno, "LISP MIB", Work
in Progress, January 2013.
[LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", Work in Progress, October 2012.
[LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O.
Bonaventure, "LISP-Security (LISP-SEC)", Work in Progress,
Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", Work in Progress, January 2009.
[OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP
Implementation Report", Work in Progress, July 2008.
[RADIR] Narten, T., "On the Scalability of Internet Routing", Work
in Progress, February 2010.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984,
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518,
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Protocol Internet Groper (LIG)", RFC 6835, January 2013.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, January 2013.
Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", Work in Progress,
[UDP-ZERO] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the use of IPv6 UDP Datagrams with Zero Checksums",
Work in Progress, December 2012.
Appendix A. Acknowledgments
An initial thank you goes to Dave Oran for planting the seeds for the
initial ideas for LISP. His consultation continues to provide value
to the LISP authors.
A special and appreciative thank you goes to Noel Chiappa for
providing architectural impetus over the past decades on separation
of location and identity, as well as detailed reviews of the LISP
architecture and documents, coupled with enthusiasm for making LISP a
practical and incremental transition for the Internet.
The authors would like to gratefully acknowledge many people who have
contributed discussions and ideas to the making of this proposal.
They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry
Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van
Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien
Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David
Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin,
Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari
Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu,
Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri
Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina
Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White,
Clarence Filsfils, and Alia Atlas.
This work originated in the Routing Research Group (RRG) of the IRTF.
An individual submission was converted into the IETF LISP working
group document that became this RFC.
The LISP working group would like to give a special thanks to Jari
Arkko, the Internet Area AD at the time that the set of LISP
documents were being prepared for IESG last call, and for his
meticulous reviews and detailed commentaries on the 7 working group
last call documents progressing toward experimental RFCs.
San Jose, CA 95134
170 Tasman Drive
San Jose, CA
170 Tasman Drive
San Jose, CA