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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/