Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+   SearchTech-invite World Map Symbol

RFC 6830


The Locator/ID Separation Protocol (LISP)

Part 4 of 4, p. 64 to 75
Prev RFC Part


prevText      Top      Up      ToC       Page 64 
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
   control time.

   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

Top      Up      ToC       Page 65 
   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

   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.

Top      Up      ToC       Page 66 
   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,

Top      Up      ToC       Page 67 
   when spoofing attacks occur, the outer-header source RLOC address can
   be used to trace back the attack to the source site, using existing
   operational tools.

   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.

Top      Up      ToC       Page 68 
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.

Top      Up      ToC       Page 69 
   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
      security considerations.

   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

Top      Up      ToC       Page 70 
   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
   future work.

16.  References

16.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

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

Top      Up      ToC       Page 71 
   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
              HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868,
              May 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [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,
              January 2013.

   [RFC6834]  Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
              Separation Protocol (LISP) Map-Versioning", RFC 6834,
              January 2013.

   [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,
              April 2008.

Top      Up      ToC       Page 72 
   [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,
              October 2012.

   [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,
              October 2012.

              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,
              March 2000.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

Top      Up      ToC       Page 73 
   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [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,
              September 2005.

   [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,
              September 2007.

   [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,
              February 2012.

   [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,
              January 2013.

   [UDP-ZERO] Fairhurst, G. and M. Westerlund, "Applicability Statement
              for the use of IPv6 UDP Datagrams with Zero Checksums",
              Work in Progress, December 2012.

Top      Up      ToC       Page 74 
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.

Top      Up      ToC       Page 75 
Authors' Addresses

   Dino Farinacci
   Cisco Systems
   Tasman Drive
   San Jose, CA  95134


   Vince Fuller


   Dave Meyer
   Cisco Systems
   170 Tasman Drive
   San Jose, CA


   Darrel Lewis
   Cisco Systems
   170 Tasman Drive
   San Jose, CA