Locator/ID Separation Protocol (LISP) (RFC 6830) is a "map-and-encapsulate" protocol which is developed by the Internet Engineering Task Force LISP Working Group. The basic idea behind the separation is that the Internet architecture combines two functions, routing locators (where a client is attached to the network) and identifiers (who the client is) in one number space: the IP address. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators can be IP addresses or arbitrary elements like a set of GPS coordinates or a MAC address.
 The Internet Architecture Board's October 2006 Routing and Addressing Workshop  renewed interest in the design of a scalable routing and addressing architecture for the Internet. Key issues driving this renewed interest include concerns about the scalability of the routing system and the impending exhaustion of IPv4 address space. Since the IAB workshop, several proposals have emerged that attempted to address the concerns expressed at the workshop. All of these proposals are based on a common concept: the separation of Locator and Identifier in the numbering of Internet devices, often termed the "Loc/ID split".
 The current namespace architecture used by the Internet Protocol uses IP addresses for two separate functions:
 There are several advantages to decoupling Location and Identifier, and to LISP specifically.
 A recent discussion of several LISP use cases may be found in 
 IETF has an active workgroup establishing standards for LISP. As of 2016, the LISP specifications are on the experimental track. The LISP workgroup started to move the core specifications onto the standards track in 2017 - as of June 2021 three revisions (for RFC 6830, RFC 6833, and 8113) are ready for publication as RFCs, but they await completion of work on a revision of RFC 6834 and the LISP Security Framework.
 In the Locator/Identifier Separation Protocol the network elements (routers) are responsible for looking up the mapping between end-point-identifiers (EID) and route locators (RLOC) and this process is invisible to the Internet end-hosts. The mappings are stored in a distributed database called the mapping system, which responds to the lookup queries. The LISP beta network initially used a BGP-based mapping system called LISP ALternative Topology (LISP+ALT), but this has now been replaced by a DNS-like indexing system called DDT inspired from LISP-TREE. The protocol design made it easy to plug in a new mapping system, when a different design proved to have benefits. Some proposals have already emerged and have been compared.
 A testbed has been developed to gain real-life experience with LISP. Participants include Google, Facebook, NTT, Level3, InTouch N.V. and the Internet Systems Consortium. As of January 2014, around 600 companies, universities, and individual contributors from 34 countries are involved. The geographical distribution of participating routers, and the prefixes they are responsible for, can be observed on the LISPmon project website (updated daily). The multi-company, LISP-community initiative LISP4.net/LISP6.net publishes relevant information about this beta network on http://www.lisp4.net/ and http://www.lisp6.net/. 
Since March 2020 the LISP Beta Network is not maintained anymore.
 The LISP-Lab project, coordinated by UPMC/LIP6, aims at building a LISP network experimentation platform exclusively built using open source LISP nodes (OpenLISP) acting as ITR/ETR tunnelling routers, MS/MR mapping servers/resolvers, DDT root and Proxy ITR/ETR. Partners include two academic institutions (UPMC, TPT), two Cloud Networking SME (Alphalink, NSS), two network operators (Renater, Orange), two SMEs on Access/Edge Networking (Border 6, Ucopia) and one Internet eXchange Point (Rezopole). The platform should be opened to external partners on 2014/2015 and is already interconnected to the LISP Beta Network with an OpenLISP DDT root.
 ICAO is considering Ground-Based LISP as a candidate technology for the next-generation Aeronautical Telecommunications Network (ATN). The solution is under further development in part of the SESAR (Single European Sky ATM Research) FCI activities.
 Several proposals for separating the two functions and allowing the Internet to scale better have been proposed, for instance GSE/8+8 as network based solution and SHIM6, HIP and ILNP as host based solutions.