--- 1/draft-ietf-lisp-mn-03.txt 2018-10-03 17:13:08.218150377 -0700 +++ 2/draft-ietf-lisp-mn-04.txt 2018-10-03 17:13:08.270151632 -0700 @@ -1,23 +1,23 @@ Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental D. Lewis -Expires: April 5, 2019 cisco Systems +Expires: April 6, 2019 cisco Systems D. Meyer 1-4-5.net C. White Logical Elegance, LLC. - October 2, 2018 + October 3, 2018 LISP Mobile Node - draft-ietf-lisp-mn-03 + draft-ietf-lisp-mn-04 Abstract This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. Status of This Memo @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 5, 2019. + This Internet-Draft will expire on April 6, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,21 +58,21 @@ 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 6 4.1. User Requirements . . . . . . . . . . . . . . . . . . . . 6 4.2. Network Requirements . . . . . . . . . . . . . . . . . . 7 5. LISP Mobile Node Operation . . . . . . . . . . . . . . . . . 7 5.1. Addressing Architecture . . . . . . . . . . . . . . . . . 8 5.2. Control Plane Operation . . . . . . . . . . . . . . . . . 9 5.3. Data Plane Operation . . . . . . . . . . . . . . . . . . 9 6. Updating Remote Caches . . . . . . . . . . . . . . . . . . . 10 - 7. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 10 + 7. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 11 7.1. LISP Mobile Node to a Stationary Node in a LISP Site . . 11 7.1.1. Handling Unidirectional Traffic . . . . . . . . . . . 11 7.2. LISP Mobile Node to a Non-LISP Stationary Node . . . . . 12 7.3. LISP Mobile Node to LISP Mobile Node . . . . . . . . . . 12 7.3.1. One Mobile Node is Roaming . . . . . . . . . . . . . 12 7.4. Non-LISP Site to a LISP Mobile Node . . . . . . . . . . . 13 7.5. LISP Site to LISP Mobile Node . . . . . . . . . . . . . . 13 8. Multicast and Mobility . . . . . . . . . . . . . . . . . . . 14 9. RLOC Considerations . . . . . . . . . . . . . . . . . . . . . 15 9.1. Mobile Node's RLOC is an EID . . . . . . . . . . . . . . 15 @@ -83,44 +83,45 @@ 12. LISP Implementation in a Mobile Node . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 13.1. Proxy ETR Hijacking . . . . . . . . . . . . . . . . . . 20 13.2. LISP Mobile Node using an EID as its RLOC . . . . . . . 20 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 15.1. Normative References . . . . . . . . . . . . . . . . . . 21 15.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 22 - B.1. Changes to draft-ietf-lisp-mn-03 . . . . . . . . . . . . 22 - B.2. Changes to draft-ietf-lisp-mn-02 . . . . . . . . . . . . 22 - B.3. Changes to draft-ietf-lisp-mn-01 . . . . . . . . . . . . 22 - B.4. Changes to draft-ietf-lisp-mn-00 . . . . . . . . . . . . 23 - + B.1. Changes to draft-ietf-lisp-mn-04 . . . . . . . . . . . . 22 + B.2. Changes to draft-ietf-lisp-mn-03 . . . . . . . . . . . . 23 + B.3. Changes to draft-ietf-lisp-mn-02 . . . . . . . . . . . . 23 + B.4. Changes to draft-ietf-lisp-mn-01 . . . . . . . . . . . . 23 + B.5. Changes to draft-ietf-lisp-mn-00 . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction - The Locator/ID Separation Protocol (LISP) [RFC6830] specifies a - design and mechanism for replacing the addresses currently used in - the Internet with two separate name spaces: Endpoint Identifiers - (EIDs), used within sites, and Routing Locators (RLOCs), used by the - transit networks that make up the Internet infrastructure. To - achieve this separation, LISP defines protocol mechanisms for mapping - from EIDs to RLOCs. The mapping infrastructure is comprised of LISP - Map-Servers and Map-Resolvers [RFC6833] and is tied together with - LISP+ALT [RFC6836]. + The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6830bis] + specifies a design and mechanism for replacing the addresses + currently used in the Internet with two separate name spaces: + Endpoint Identifiers (EIDs), used within sites, and Routing Locators + (RLOCs), used by the transit networks that make up the Internet + infrastructure. To achieve this separation, LISP defines protocol + mechanisms for mapping from EIDs to RLOCs. The mapping + infrastructure is comprised of LISP Map-Servers and Map-Resolvers + [I-D.ietf-lisp-rfc6833bis] and is tied together with LISP+ALT + [RFC6836]. This document specifies the behavior of a new LISP network element: the LISP Mobile Node. The LISP Mobile Node implements a subset of the standard Ingress Tunnel Router and Egress Tunnel Router - functionality [RFC6830]. Design goals for the LISP mobility design - include: + functionality [I-D.ietf-lisp-rfc6830bis]. Design goals for the LISP + mobility design include: o Allowing TCP connections to stay alive while roaming. o Allowing the mobile node to communicate with other mobile nodes while either or both are roaming. o Allowing the mobile node to multi-home (i.e., use multiple interfaces concurrently). o Allowing the mobile node to be a server. That is, any mobile node @@ -171,26 +172,27 @@ 2. Definition of Terms This section defines the terms used in this document. Stationary Node (SN): A non-mobile node who's IP address changes infrequently. That is, its IP address does not change as frequently as a fast roaming mobile hand-set or a broadband connection and therefore the EID to RLOC mapping is relatively static. - Endpoint ID (EID): This is the traditional LISP EID [RFC6830], and - is the address that a LISP mobile node uses as its address for - transport connections. A LISP mobile node never changes its EID, - which is typically a /32 or /128 prefix and is assigned to a - loopback interface. Note that the mobile node can have multiple - EIDs, and these EIDs can be from different address families. + Endpoint ID (EID): This is the traditional LISP EID + [I-D.ietf-lisp-rfc6830bis], and is the address that a LISP mobile + node uses as its address for transport connections. A LISP mobile + node never changes its EID, which is typically a /32 or /128 + prefix and is assigned to a loopback interface. Note that the + mobile node can have multiple EIDs, and these EIDs can be from + different address families. Routing Locator (RLOC): This is the traditional LISP RLOC, and is in general a routable address that can be used to reach a mobile node. Note that there are cases in which an mobile node may receive an address that it thinks is an RLOC (perhaps via DHCP) which is either an EID or an RFC 1918 address [RFC1918]. This could happen if, for example, if the mobile node roams into a LISP domain or a domain behind a Network Address Translator (NAT)) See Section 10 for more details. @@ -271,23 +273,24 @@ Transport Connection Survivability: The LISP-MN design must allow a LISP-MN to roam while keeping transport connections alive. Simultaneous Roaming: The LISP-MN design must allow a LISP-MN to talk to another LISP-MN while both are roaming. Multihoming: The LISP-MN design must allow for simultaneous use of multiple Internet connections by a LISP-MN. In addition, the design must allow for the LISP mobile node to specify ingress - traffic engineering policies as documented in [RFC6830]. That is, - the LISP-MN must be able to specify both active/active and active/ - passive policies for ingress traffic. + traffic engineering policies as documented in + [I-D.ietf-lisp-rfc6830bis]. That is, the LISP-MN must be able to + specify both active/active and active/passive policies for ingress + traffic. Shortest Path Data Plane: The LISP-MN design must allow for shortest path bidirectional traffic between a LISP-MN and a stationary node, and between a LISP-MN and another LISP-MN (i.e., without triangle routing in the data path). This provides a low-latency data path between the LISP-MN and the nodes that it is communicating with. 4.2. Network Requirements @@ -313,30 +316,30 @@ Readdressing: The LISP-MN design must not require TCP connections to be reset when the mobile node roams. In particular, since the IP address associated with a transport connection will not change as the mobile node roams, TCP connections will not reset. 5. LISP Mobile Node Operation The LISP-MN design is built from three existing LISP components: A lightweight LISP implementation that runs in an LISP-MN, and the - existing Map-Server [RFC6833] and Interworking [RFC6832] - infrastructures. A LISP mobile node typically sends and receives - LISP encapsulated packets (exceptions include management protocols - such as DHCP). + existing Map-Server [I-D.ietf-lisp-rfc6833bis] and Interworking + [RFC6832] infrastructures. A LISP mobile node typically sends and + receives LISP encapsulated packets (exceptions include management + protocols such as DHCP). The LISP-MN design makes a single mobile node look like a LISP site - as described in in [RFC6830] by implementing ITR and ETR - functionality. Note that one subtle difference between standard ITR - behavior and LISP-MN is that the LISP-MN encapsulates all non-local, - non-LISP site destined outgoing packets to a PETR. + as described in in [I-D.ietf-lisp-rfc6830bis] by implementing ITR and + ETR functionality. Note that one subtle difference between standard + ITR behavior and LISP-MN is that the LISP-MN encapsulates all non- + local, non-LISP site destined outgoing packets to a PETR. When a LISP-MN roams onto a new network, it receives a new RLOC. Since the LISP-MN is the authoritative ETR for its EID-prefix, it must Map-Register it's updated RLOC set. New sessions can be established as soon as the registration process completes. Sessions that are encapsulating to RLOCs that did not change during the roaming event are not affected by the roaming event (or subsequent mapping update). However, the LISP-MN must update the ITRs and PITRs that have cached a previous mapping. It does this using the techniques described in Section 6. @@ -377,31 +380,33 @@ Finally, note that if, for some reason, a LISP-MN's EID is re- provisioned, the LISP-MN's Map-Server address may also have to change in order to keep LISP-MN's EID within the aggregate advertised by the Map-Server (this is discussed in greater detail in Section 5.2). 5.2. Control Plane Operation A roaming event occurs when the LISP-MN receives a new RLOC. Because the new address is a new RLOC from the LISP-MN's perspective, it must update its EID-to-RLOC mapping with its Map-Server; it does this - using the Map-Register mechanism described in [RFC6830]. + using the Map-Register mechanism described in + [I-D.ietf-lisp-rfc6830bis]. A LISP-MN may want the Map-Server to respond on its behalf for a variety of reasons, including minimizing control traffic on radio links and minimizing battery utilization. A LISP-MN may instruct its Map-Server to proxy respond to Map-Requests by setting the Proxy-Map- - Reply bit in the Map-Register message [RFC6830]. In this case the - Map-Server responds with a non-authoritative Map-Reply so that an ITR - or PITR will know that the ETR didn't directly respond. A Map-Server - will proxy reply only for "registered" EID-prefixes using the - registered EID-prefix mask-length in proxy replies. + Reply bit in the Map-Register message [I-D.ietf-lisp-rfc6830bis]. In + this case the Map-Server responds with a non-authoritative Map-Reply + so that an ITR or PITR will know that the ETR didn't directly + respond. A Map-Server will proxy reply only for "registered" EID- + prefixes using the registered EID-prefix mask-length in proxy + replies. Because the LISP-MN's Map-Server is pre-configured to advertise an aggregate covering the LISP-MN's EID prefix, the database mapping change associated with the roaming event is confined to the Map- Server and those ITRs and PITRs that may have cached the previous mapping. 5.3. Data Plane Operation A key feature of LISP-MN control-plane design is the use of the Map- @@ -434,24 +439,24 @@ 6. Updating Remote Caches A LISP-MN has five mechanisms it can use to cause the mappings cached in remote ITRs and PITRs to be refreshed: Map Versioning: If Map Versioning [RFC6834] is used, an ETR can detect if an ITR is using the most recent database mapping. In particular, when mobile node's ETR decapsulates a packet and detects the Destination Map-Version Number is less than the current version for its mapping, in invokes the SMR procedure - described in [RFC6830]. In general, SMRs are used to fix the out - of sync mapping while Map-Versioning is used to detect they are - out of sync. [RFC6834] provides additional details of the Map - Versioning process. + described in [I-D.ietf-lisp-rfc6830bis]. In general, SMRs are + used to fix the out of sync mapping while Map-Versioning is used + to detect they are out of sync. [RFC6834] provides additional + details of the Map Versioning process. Data Driven SMRs: An ETR may elect to send SMRs to those sites it has been receiving encapsulated packets from. This will occur when an ITR is sending to an old RLOC (for which there is one-to- one mapping between EID-to-RLOC) and the ETR may not have had a chance to send an SMR the ITR. Setting Small TTL on Map Replies: The ETR (or Map Server) may set a small Time to Live (TTL) on its mappings when responding to Map Requests. The TTL value should be chosen such that changes in @@ -574,23 +579,24 @@ mapping via one of the mechanisms described in Section 6) and the stationary LISP-MN can encapsulate data directly to the roaming LISP- MN. 7.4. Non-LISP Site to a LISP Mobile Node When a stationary ITR is talking to a non-LISP site, it may forward packets natively (unencapsulated) to the non-LISP site. This will occur when the ITR has received a negative Map Reply for a prefix covering the non-LISP site's address with the Natively-Forward action - bit set [RFC6830]. As a result, packets may be natively forwarded to - non-LISP sites by an ITR (the return path will through a PITR, - however, since the packet flow will be non-LISP site to LISP site). + bit set [I-D.ietf-lisp-rfc6830bis]. As a result, packets may be + natively forwarded to non-LISP sites by an ITR (the return path will + through a PITR, however, since the packet flow will be non-LISP site + to LISP site). A LISP-MN behaves differently when talking to non-LISP sites. In particular, the LISP-MN always encapsulates packets to a PETR. The PETR then decapsulates the packet and forwards it natively to its destination. As in the stationary case, packets from the non-LISP site host return to the LISP-MN through a PITR. Since traffic forwarded through a PITR is unidirectional, a LISP-MN should use the cache management techniques described in Section 7.1.1. 7.5. LISP Site to LISP Mobile Node @@ -764,21 +770,21 @@ port so they can encapsulate to the LISP-MN traversing the NAT device. Procedures a LISP-MN should follow when it resides behind a NAT, will follow the LISP xTRs procedures in specification [I-D.ermagan-lisp-nat-traversal]. 11. Mobility Example This section provides an example of how the LISP-MN is integrated - into the base LISP Design [RFC6830]. + into the base LISP Design [I-D.ietf-lisp-rfc6830bis]. 11.1. Provisioning The LISP-MN needs to be configured with the following information: An EID, assigned to its loopback address A key for map-registration An IP address of a Map-Resolver (this could be learned @@ -828,21 +834,21 @@ For incoming unicast packets, the LISP sub-layer simply decapsulates the packets and delivers to the IP layer. The loc-reach-bits can be processed by the LISP sub-layer. Specifically, the source EID from the packet is looked up in the map-cache and if the loc-reach-bits settings have changed, store the loc-reach-bits from the packet and note which RLOCs for the map-cache entry should not be used. In terms of the LISP-MN detecting which RLOCs from each stored map- cache entry is reachable, it can use any of the Locator Reachability - Algorithms from [RFC6830]. + Algorithms from [I-D.ietf-lisp-rfc6830bis]. A background task that runs off a timer should be run so the LISP-MN can send periodic Map-Register messages to the Map-Server. The Map- Register message should also be triggered when the LISP-MN detects a change in IP address for a given interface. The LISP-MN should send Map-Registers to the same Map-Register out each of it's operational links. This will provide for robustness on radio links with which the mobile node is associated. A LISP-MN receives a Map-Request when it has Map-Registered to a Map- @@ -866,77 +872,99 @@ o Sending Map-Register messages periodically. The key point about the LISP sub-layer is that no other components in the protocol stack need changing; just the insertion of this sub- layer between the IP layer and the interface layer-2 encapsulation/ decapsulation layer. 13. Security Considerations Security for the LISP-MN design builds upon the security fundamentals - found in LISP [RFC6830] for data-plane security and the LISP Map - Server [RFC6833] registration security. Security issues unique to - the LISP-MN design are considered below. + found in LISP [I-D.ietf-lisp-rfc6830bis] for data-plane security and + the LISP Map Server [I-D.ietf-lisp-rfc6833bis] registration security. + Security issues unique to the LISP-MN design are considered below. 13.1. Proxy ETR Hijacking The Proxy ETR (or PETR) that a LISP-MN uses as its destination for non-LISP traffic must use the security association used by the registration process outlined in Section 5.2 and explained in detail - in the LISP-MS specification [RFC6833]. These measures prevent third - party injection of LISP encapsulated traffic into a Proxy ETR. - Importantly, a PETR must not decapsulate packets from non-registered - RLOCs. + in the LISP-MS specification [I-D.ietf-lisp-rfc6833bis]. These + measures prevent third party injection of LISP encapsulated traffic + into a Proxy ETR. Importantly, a PETR must not decapsulate packets + from non-registered RLOCs. 13.2. LISP Mobile Node using an EID as its RLOC For LISP packets to be sent to a LISP-MN which has an EID assigned to it as an RLOC as described in Section 9.1), the LISP site must allow for incoming and outgoing LISP data packets. Firewalls and stateless packet filtering mechanisms must be configured to allow UDP port 4341 and UDP port 4342 packets. 14. IANA Considerations This document is requesting bit allocations in the Map-Request and - Map-Register messages. + Map-Register messages. The registry is introduced in + [I-D.ietf-lisp-rfc6833bis] and named "LISP Bit Flags". This document + is adding bits to the sub-registry "Map-Request Header Bits' and + "Map-Register Header Bits". A LISP mobile-node will set the m-bit to + 1 when it sends Map-Request and Map-Register messages. - The first 4 octets of the Map-Request message are: + Sub-Registry: Map-Request Header Bits: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |Type=1 |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count | + |Type=1 |A|M|P|S|p|s|m|R| Rsvd |L|D| IRC | Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - This document requests allocation of bit position 10 labeled "m" in - the above diagram. The IANA name label is "map-request-m-bit". When - a LISP mobile-node sends a Map-Request message to the mapping system, - it sets the m-bit to 1. + +-----------+---------------+--------------+-----------------+ + | Spec Name | IANA Name | Bit Position | Description | + +-----------+---------------+--------------+-----------------+ + | m | map-request-m | 10 | Mobile Node Bit | + +-----------+---------------+--------------+-----------------+ - The first 4 octets of the Map-Register message are: + LISP Map-Request Header Bits + + Sub-Registry: Map-Register Header Bits: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |Type=3 |P|S|I| Reserved |E|T|a|m|M| Record Count | + |Type=3 |P|S|R| Reserved |E|T|a|m|M| Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - This document requests allocation of bit position 22 labeled "m" in - the above diagram. The IANA name label is "map-register-m-bit". - When a LISP mobile-node sends a Map-Register message to the mapping - system, it sets the m-bit to 1. + +-----------+----------------+--------------+----------------------+ + | Spec Name | IANA Name | Bit Position | Description | + +-----------+----------------+--------------+----------------------+ + | m | map-register-m | 22 | LISP Mobile Node Bit | + +-----------+----------------+--------------+----------------------+ + + LISP Map-Register Header Bits 15. References 15.1. Normative References + [I-D.ietf-lisp-rfc6830bis] + Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. + Cabellos-Aparicio, "The Locator/ID Separation Protocol + (LISP)", draft-ietf-lisp-rfc6830bis-23 (work in progress), + October 2018. + + [I-D.ietf-lisp-rfc6833bis] + Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, + "Locator/ID Separation Protocol (LISP) Control-Plane", + draft-ietf-lisp-rfc6833bis-17 (work in progress), October + 2018. + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", @@ -945,41 +973,31 @@ [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, DOI 10.17487/RFC3775, June 2004, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . - [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The - Locator/ID Separation Protocol (LISP)", RFC 6830, - DOI 10.17487/RFC6830, January 2013, - . - [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, 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, DOI 10.17487/RFC6832, January 2013, . - [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation - Protocol (LISP) Map-Server Interface", RFC 6833, - DOI 10.17487/RFC6833, January 2013, - . - [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, DOI 10.17487/RFC6834, January 2013, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . @@ -993,40 +1011,50 @@ Appendix A. Acknowledgments Albert Cabellos, Noel Chiappa, Pierre Francois, Michael Menth, Andrew Partan, Chris White and John Zwiebel provided insightful comments on the mobile node concept and on this document. A special thanks goes to Mary Nickum for her attention to detail and effort in editing early versions of this document. Appendix B. Document Change Log -B.1. Changes to draft-ietf-lisp-mn-03 +B.1. Changes to draft-ietf-lisp-mn-04 + + o Posted October 2018. + + o Make IANA Considerations section formatted like + [I-D.ietf-lisp-rfc6833bis]. + + o Change all references for RFC6830 to [I-D.ietf-lisp-rfc6830bis] + and for RFC6833 to [I-D.ietf-lisp-rfc6833bis]. + +B.2. Changes to draft-ietf-lisp-mn-03 o Posted October 2018. o Request m-bit allocation in Map-Register message in IANA Considerations section. -B.2. Changes to draft-ietf-lisp-mn-02 +B.3. Changes to draft-ietf-lisp-mn-02 o Posted April 2018. o Update document timer and references. -B.3. Changes to draft-ietf-lisp-mn-01 +B.4. Changes to draft-ietf-lisp-mn-01 o Posted October 2017. o Update document timer and references. -B.4. Changes to draft-ietf-lisp-mn-00 +B.5. Changes to draft-ietf-lisp-mn-00 o Posted April 2017. o Changed draft-meyer-lisp-mn-16 to working group document. Authors' Addresses Dino Farinacci lispers.net San Jose, CA 95134