LISP control-plane for Identifier Locator Addressing (ILA)
draft-rodrigueznatal-ila-lisp-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Alberto Rodriguez-Natal , Vina Ermagan , Fabio Maino , Albert Cabellos-Aparicio | ||
| Last updated | 2018-03-03 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rodrigueznatal-ila-lisp-00
Network Working Group A. Rodriguez-Natal
Internet-Draft V. Ermagan
Intended status: Experimental F. Maino
Expires: September 4, 2018 Cisco Systems
A. Cabellos
Technical University of Catalonia
March 3, 2018
LISP control-plane for Identifier Locator Addressing (ILA)
draft-rodrigueznatal-ila-lisp-00
Abstract
This document specifies how to use the LISP control-plane to support
an Identifier Locator Addressing (ILA) data-plane. In particular, it
describes how ILA data-plane components can use the LISP control-
plane to dynamically resolve and register Identifier-to-Locator
mappings as well as Endpoint Address to Identifier/Locator mappings.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 September 4, 2018.
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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 1]
Internet-Draft ILA-LISP March 2018
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. LISP Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
4. ILA LCAF . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Identifier Subtype . . . . . . . . . . . . . . . . . . . 4
4.2. Locator Subtype . . . . . . . . . . . . . . . . . . . . . 7
4.3. SIR Prefix Subtype . . . . . . . . . . . . . . . . . . . 7
5. Device Roles and Provision . . . . . . . . . . . . . . . . . 8
5.1. Map Server (MS) . . . . . . . . . . . . . . . . . . . . . 9
5.2. Map Resolver (MR) . . . . . . . . . . . . . . . . . . . . 9
5.3. ILA-Router (ILA-R) . . . . . . . . . . . . . . . . . . . 9
5.4. ILA-Node (ILA-N) . . . . . . . . . . . . . . . . . . . . 10
6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. ILA Identifier to Locator Mappings . . . . . . . . . . . 11
6.1.1. Resolution . . . . . . . . . . . . . . . . . . . . . 11
6.1.2. Registration . . . . . . . . . . . . . . . . . . . . 11
6.1.3. PubSub . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.4. Mobility . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Endpoint Address to ILA Identifier/Locator Mappings . . . 13
6.2.1. Resolution . . . . . . . . . . . . . . . . . . . . . 14
6.2.2. Registration . . . . . . . . . . . . . . . . . . . . 14
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 15
7.1. Protocol Transport . . . . . . . . . . . . . . . . . . . 15
7.2. ILA-R and MS Co-location . . . . . . . . . . . . . . . . 15
7.3. Mapping System Internal Resolution . . . . . . . . . . . 15
7.4. Mapping System Replication and Synchronization . . . . . 16
7.5. Multiple ILA Domains . . . . . . . . . . . . . . . . . . 16
7.6. Proactive Mapping Push . . . . . . . . . . . . . . . . . 16
7.7. Checksum Adjustment per Locator . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Signaling Protection . . . . . . . . . . . . . . . . . . 17
8.2. Map-Cache Attacks . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
The Identifier Locator Addressing (ILA) [I-D.herbert-intarea-ila] is
an IPv6 data-plane protocol that relies on address splitting for ID/
location separation. Part of the IPv6 address expresses the
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 2]
Internet-Draft ILA-LISP March 2018
Identifier of an endpoint, the immutable identity of the node (e.g.
task, end-host, mobile device, etc), while another part represents
its Locator, the topological location of the endpoint, which can be
dynamic. The Locator defines where the Identifier is currently
attached to the network and is used to route the packets through the
ILA domain. To do so, ILA Locators are prepended to the ILA
Identifier to form a routable ILA address (bitwise equivalent to an
IPv6 address).
The Identifier of an endpoint is unique and permanent for its
lifetime, meanwhile its locator is not fixed and subject to change
over time. A control-plane protocol to resolve Identifier-to-Locator
mappings is needed in order to use the ILA data-plane. The ILA data-
plane is agnostic to the control-plane mechanism in place and
therefore different control-plane protocols have been proposed
[I-D.lapukhov-bgp-ila-afi] [I-D.herbert-ila-ilamp]. This document
specifies how the Locator/ID Separation Protocol (LISP) control-plane
[I-D.ietf-lisp-rfc6833bis] can be used to support the operation of
the ILA data-plane, including the resolution of the Identifier-to-
Locator mappings and the Endpoint Address to ILA Identifier/Locator
mappings.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. LISP Overview
TBD
4. ILA LCAF
To support ILA mappings and associated data using the LISP control-
plane the following LISP Canonical Address Format (LCAF) [RFC8060] is
introduced. The ILA LCAF type defines several subtypes to carry
different ILA information. This document refers to the different
subtypes of the ILA LCAF using the syntax "ILA-Subtype" LCAF (e.g.
ILA-Identifier). All the ILA subtypes follow the format defined
below:
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 3]
Internet-Draft ILA-LISP March 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ILA |Subtype| Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ILA Subtype... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ILA LCAF
The fields specific to the the ILA LCAF Type are defined below. For
definition of the rest of fields see the LCAF specification
[RFC8060].
Subtype: This is the ILA LCAF Subtype. This field indicates which
particular ILA format the ILA LCAF encodes. Currently the
following Subtypes are defined:
0x0: Reserved. Reserved for future use.
0x1: Identifier Subtype. Used to encode ILA Identifiers as
described in Section 4.1
0x2: Locator Subtype. Used to encode ILA Locators as described
in Section 4.2
0x3: SIR Prefix Subtype. Used to encode SIR Prefixes as
described in Section 4.3
4.1. Identifier Subtype
The Identifier subtype (aka ILA-Identifier LCAF) can be used to carry
ILA Identifiers in the LISP control-plane signaling. The ILA
specification [I-D.herbert-intarea-ila] defines different Identifiers
formats that can be used in the data-plane. The same Identifier
formats are described in this document for the ILA-Identifier LCAF
Subtype. When used in this document, each Identifier format is
referred by the code point defined in [I-D.herbert-intarea-ila], e.g.
"ILA-Identifier-0x3" LCAF. The ILA data-plane formats are bitwise
compatible with their correspondent LCAF formats. It is thus
possible for an ILA data-plane device to resolve the Locator for a
particular ILA Identifier even if the ILA data-plane device does not
understand that particular Identifier type.
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 4]
Internet-Draft ILA-LISP March 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ILA | 0x1 |E|Rsvd2| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type|0| |
+-+-+-+-+ Identifier (60 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ILA-Identifier LCAF
The fields specific to the the ILA-Identifier LCAF Subtype are
defined below.
Type: This is the Type of Identifier as defined in
[I-D.herbert-intarea-ila].
E: This is the "Endpoint Address Mapping" bit. If the 'E' bit is set
to 1, it indicates that the Identifier is being resolved to an
Endpoint Address (see Section 6.2). The 'E' bit is set to 0
otherwise.
Identifier: This is a variable length field that encodes an ILA
Identifier. The length of the Identifier can be inferred from the
Length field of the LCAF. The representation above uses an
Identifier size of 64 bits (including the first 4 bits with the
Type).
Using Identifier size of 64 bits (including the first 4 bits with the
Type), the different types of Identifiers are encoded in the ILA-
Identifier LCAF as described below. The common part of the ILA-
Identifier LCAF is not shown.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 |0| |
+-+-+-+-+ Interface Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface Identifier (0x0)
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 5]
Internet-Draft ILA-LISP March 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1 |0| |
+-+-+-+-+ Locally Unique Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Locally Unique Identifier (0x1)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x2 |0| VNID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual IPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Virtual IPv4 Identifier (0x2)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x3 |0| VNID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Unicast IPv6 (lower 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Virtual Unicast IPv6 Identifier (0x3)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x4 |0| VNID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope | Virtual Multicast IPv6 (lower 28 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Virtual Multicast IPv6 Identifier (0x4)
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 6]
Internet-Draft ILA-LISP March 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x5 |0| Non-Local Address Identifier |
+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Non-Local Address Identifier (0x5)
4.2. Locator Subtype
The Locator subtype (aka ILA-Locator LCAF) can be used to carry ILA
Locators in the LISP control-plane signaling.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ILA | 0x2 |C|Rsvd2| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Locator (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ILA LCAF
The fields specific to the the ILA-Locator LCAF Subtype are defined
below.
C: This is the "Checksum-Adjustment-Needed" bit. If the 'C' bit is
set to 1 it indicates that an ILA data-plane device has to compute
the checksum adjustment as described in [I-D.herbert-intarea-ila]
when sending ILA packets to this Locator. The 'C' bit is set to 0
otherwise. See Section 7.7 for more details.
Locator: This is a variable length field that encodes an ILA
Locator. The length of the Locator can be inferred from the
Length field of the LCAF. The representation above uses an
Locator size of 64 bits.
4.3. SIR Prefix Subtype
The SIR Prefix subtype (aka ILA-SIR LCAF) can be used to encode the
SIR prefix when different ILA domains co-exist as described in
Section 7.5.
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 7]
Internet-Draft ILA-LISP March 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ILA | 0x3 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SIR Prefix Len | SIR Prefix ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... SIR Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ILA-SIR LCAF
The fields specific to the the ILA-SIR LCAF Subtype are defined
below.
SIR Prefix Len: This field indicates the length of the SIR Prefix
that follows.
Locator: This is a variable length field that encodes an ILA SIR
Prefix.
5. Device Roles and Provision
The ILA specification [I-D.herbert-intarea-ila] defines different ILA
data-plane devices (i.e. devices that can perform ILA transformations
of SIR addresses to/from ILA addresses), namely ILA-Router (ILA-R),
ILA-Host (ILA-H) and ILA-Node (ILA-N). This documents relies on the
terminology introduced in [I-D.herbert-intarea-ila] but uses ILA-
Router and ILA-Node denominations to distinguish between ILA data-
plane devices that have a complete map-cache set (ILA-R) versus those
that only have an incomplete map-cache (ILA-N). For the purpose of
this document, it is assumed that an ILA-N has endpoints assigned to
it to which it has direct connectivity (if it is an ILA-Host it may
be even hosting the endpoints itself). On the contrary, no endpoint
assignment is assumed for an ILA-R (although not precluded). This
section describes in general terms the role and required provisioning
of the different devices involved in an ILA-LISP deployment, for
operational details of these devices see Section 6
To avoid verbosity on the description of the provisioning
requirements listed below, there are two things that are assumed to
be configured in all the devices belonging to a given ILA domain:
o SIR prefix(es) of the ILA domain: This prefix serves to identify
traffic belonging to the ILA domain. It is also used to
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 8]
Internet-Draft ILA-LISP March 2018
differentiate across different ILA domains where several domains
share the same infrastructure.
o Control-Plane Identifier: a given Identifier within the ILA domain
is reserved to be used when sending control-plane messages across
devices. This Identifier is concatenated with the Locator of the
device that the control-plane message is addressed towards. When
receiving an ILA packet with this special Identifier, the packet
will be delivered to the control-plane process of the device.
5.1. Map Server (MS)
A MS has the complete mapping information for all the Identifiers in
the ILA domain. If the Identifier space is divided into different
shards, then each MS is responsible for a particular shard of
Identifiers. Then, for the Identifiers of its shard, the MS has the
complete mapping information. The mapping information at an MS can
be populated by the ILA devices registering their local mappings and/
or by an external source. A MS has to be pre-provisioned with the
following:
Shard index: of the shard the MS is responsible for (if any).
5.2. Map Resolver (MR)
A MR receives requests for mappings from ILA data-plane devices and
forwards them to the appropriate MS. If needed, a MR is also able to
find which MS is associated with a particular shard. See Section 7.3
for a discussion on different options regarding how a MR can find the
appropriate MS to forward a given mapping request.
5.3. ILA-Router (ILA-R)
An ILA-R has a complete map-cache for the mappings in the domain. If
shards are used, then each ILA-R is assigned to a particular shard of
Identifiers for which it has a complete map-cache of mappings. An
ILA-R subscribes (as described in Section 6.1.3) to a MS (or to the
MS responsible for its shard) to populate and keep its map-cache
updated. Normally, an ILA-R has no endpoint (e.g. task, user-
endpoint, etc) directly attached. Instead, it serves to translate
packets that were not translated by an ILA-N. To do so, as described
in [I-D.herbert-intarea-ila], an ILA-R announces the SIR prefix (plus
its shard index if needed) as an "anycast" address on the underlay to
attract traffic towards itself. See also Section 7.2 for discussion
on the case of co-locating the MS with the ILA-R. An ILA-R has to be
pre-provisioned with the following:
Shard index: of the shard the ILA-R is assigned to.
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 9]
Internet-Draft ILA-LISP March 2018
5.4. ILA-Node (ILA-N)
This document uses the term ILA-Node to refer to an ILA translating
device that does not have a complete map-cache, in contrast with ILA-
Router that has a complete map-cache for the domain (or its shard).
Each ILA-N has a set of endpoints (and associated Identifiers)
assigned to it for which it has complete mapping information. An
ILA-N registers its local mapping information into a MS (or set of
MSs) as described in Section 6.1.2. A given ILA-N may have
Identifiers from different shards, in that case per each Identifier
it has to register the mapping information in the appropriate MS (the
one handling the shard of the Identifier). Contrary to an ILA-R, the
ILA-N does not have a full map-cache for remote Identifiers, but
rather it populates its map-cache on demand (following the mechanisms
described in Section 6.1.1) based on the actual data-plane traffic.
An ILA-N has to be pre-provisioned with the following:
Identifiers: that the ILA-N is responsible for (if they are not
created or auto-discovered by the ILA-N).
Locators: to use on the ILA underlay (if they are not created or
auto-discovered by the ILA-N).
VNID / Tenant-Prefix pairs: if virtualization is used (see also
Section 6.2).
MR Locator: to request mappings for remote identifiers.
MS Locator: of the MS (or MSs) responsible for the Identifiers
assigned to the ILA-N.
Checksum adjustment setting: to indicate if the ILA-N has to
perform or not checksum adjustment (see also Section 7.7).
6. Operation
An ILA data-plane can leverage the LISP control-plane to support
different aspects of its operation. The main function provided by
the LISP control plane is resolving the Identifier to Locator
mappings. In addition, ILA can also use the LISP control-plane to
dynamically learn the ILA Identifier associated to an Endpoint
Address. These two steps can also be combined into a single
resolution exchange.
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 10]
Internet-Draft ILA-LISP March 2018
6.1. ILA Identifier to Locator Mappings
This section describes how ILA devices can use the LISP control-plane
to resolve, register and keep updated the Identifier to Locator
mappings required for the operation of the ILA data-plane.
6.1.1. Resolution
When an ILA-N has to send traffic towards a remote Identifier for
which it does not have the associated Locator, it has to obtain it
first from a MS. To do so, it follows the mechanisms described in
[I-D.ietf-lisp-rfc6833bis] and sends a Map-Request towards one of its
configured MRs. This Map-Request includes as EID the ILA Identifier
of the remote endpoint encoded using the LCAF defined in Section 4.1
As a response to this Map-Request, the ILA-N will get a Map-Reply
from the MS with the Locator(s) associated with the remote Identifier
(if any). Locators are carried in the Map-Reply as RLOCs and are
encoded using the LCAF defined in Section 4.2. In the current ILA
specification, Identifiers are considered to be in a flat, non-
hierarchical space. Therefore, when resolving a single Identifier
the "EID mask-len" of the Map-Request and Map-Reply is set to the
length of the Identifier. As specified in
[I-D.ietf-lisp-rfc6833bis], an ILA-N can use the priority and weight
information conveyed in the Map-Reply message to load balance data-
plane traffic across the different Locators for the remote
Identifier. While the mapping is being resolved via the Map-Request/
Map-Reply process, the ILA-N can send the data packets to the
underlay using the SIR address. In that way, they can be attracted
and translated at an ILA-R. See also Section 8.2 for discussion on
how the ILA-N can protect itself from malicious endpoints trying to
artificially force map-cache misses (and subsequent Map-Requests).
6.1.2. Registration
An ILA-N registers its local Identifier-to-Locator mappings in the
appropriate MSs (i.e. those handling its Identifiers) by sending Map-
Register messages following the process documented in
[I-D.ietf-lisp-rfc6833bis]. To do so, it uses the ILA-Identifier
LCAF defined in Section 4.1 as EID in the Map-Register. Similarly to
the mapping resolution process, the "EID mask-len" of the Map-
Register is fixed to the length of the Identifier. The ILA-N
includes its local Locators in the Map-Register using the ILA-Locator
LCAF defined in Section 4.2. As described in
[I-D.ietf-lisp-rfc6833bis], the mapping registration may happen
periodically as well as when there is a change in the mapping(s) that
the ILA-N is registering.
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 11]
Internet-Draft ILA-LISP March 2018
6.1.3. PubSub
When requesting a mapping to populate its map-cache, an ILA-N can
subscribe to updates on the mapping using the mechanisms described in
[I-D.rodrigueznatal-lisp-pubsub]. Similarly, an ILA-R subscribes
using [I-D.rodrigueznatal-lisp-pubsub] to receive updates for all the
Identifier-Locator mappings in the domain (or in its shard). To
subscribe to all Identifier mappings in the ILA domain, the ILA-R
sets the "EID mask-len" in the Map-Request to 0 and uses an ILA-
Identifier LCAF with all the Identifier bits set to 0. To subscribe
to all Identifier mappings in a particular shard, the ILA-R sets the
"EID mask-len" in the Map-Request to the shard index length and uses
an ILA Identifier LCAF with the proper shard index set and the rest
of the Identifier bits set to 0.
6.1.4. Mobility
Mobility of Identifiers is supported by the mechanisms described in
[I-D.ietf-lisp-eid-mobility]. As described there, when an Identifier
moves to a different ILA-N, its previous ILA-N is notified with the
new Locator(s) for the Identifier. When traffic is received at the
old Locator, the ILA-N there can use the updated Identifier-Locator
mapping information to replace the old Locator with the new Locator
and forward the traffic back to the underlay. In the interim between
the ILA-N detects that the Identifier has moved but the notification
with the new Locator is yet to be received, the ILA-N can translate
received traffic for the Identifier to the SIR address and forward it
back to the underlay (to be intercepted, translated and forwarded by
an ILA-R).
Following [I-D.ietf-lisp-eid-mobility], when the old ILA-N receives
traffic addressed for the Identifier that is no longer locally
connected, it sends a Solict-Map-Request (SMR) to the Locator
associated with the source Identifier to inform it that it should
update its map-cache. Note that when ILA is used as the data-plane,
the source Locator may not be present in the received data packet and
a mapping resolution (to find the ILA-N that originated the packet)
may be needed before the SMR can be sent. Note also that, if the
data packet was translated and sent by an ILA-R, the source
Identifier will not resolve to the Locator of the ILA-R (but instead
to the ILA-N where the source Identifier is attached). For this
version of the document, the case of sending this SMR to an ILA-R is
not considered.
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 12]
Internet-Draft ILA-LISP March 2018
6.2. Endpoint Address to ILA Identifier/Locator Mappings
The ILA data-plane [I-D.herbert-intarea-ila] defines some cases where
the address used by an endpoint is not a SIR address. In those
cases, the Endpoint Address needs to be mapped to an ILA Identifier
before an ILA address (or SIR address) can be formed. These mappings
of Endpoint Addresses to ILA Identifiers can be statically
provisioned at the ILA-N or can also be resolved via the LISP
control-plane. There are currently two cases defined in
[I-D.herbert-intarea-ila] where an endpoint does not use a SIR
address and requires a mapping of Endpoint Address to ILA Identifier.
o Virtualization: In virtualization scenarios, the endpoints use
virtual addresses (with a Tenant Prefix in the case of IPv6)
rather than SIR addresses. Before packets can be sent over the
ILA underlay, the Tenant Prefix has to be converted into a VNID.
Instead of pre-provisioning the Tenant Prefix to VNID pairs in
advance, the ILA data-plane can also use the LISP control-plane to
resolve the mapping of Tenant Prefix to VNID. Dynamic resolution
instead of static provisioning can be specially useful for cases
of cross-communication between different virtual networks (since
the mapping of a remote Virtual Prefix to VNID may not be
available at the ILA-N). Once the ILA-N has resolved the VNID
associated with a Tenant Prefix, it can cache this information and
only request Identifier to Locator mappings for new remote
Endpoint Addresses using the same Tenant Prefix. Note that for
virtualization cases using IPv4, the current version of this
document assumes that the VNID has to be pre-provisioned since
there is not Tenant Prefix that can be resolved into a VNID.
o Non-Local Addresses: ILA uses the concept of Non-Local Addresses
to refer to Endpoint Addresses that do not belong to the SIR
prefix(es) of the domain. To use Non-Local Addresses with an ILA
data-plane, they need to be first converted into an ILA identifier
(of 44 bits in the current ILA specification). The LISP control-
plane can be used by the ILA data-plane to retrieve the mappings
of Non-Local Addresses to Identifiers (on packet transmission) and
of Identifiers to Non-Local Addresses (on packet reception). If
the ILA data-plane devices are also performing the assignment of
Non-Local Addresses to ILA Identifiers, the LISP control-plane can
also be used to register this assignment into the Mapping System.
This section covers the resolution (including reverse resolution) and
registration of Endpoint Address mappings. Contrary to the
Identifier to Locator mappings, the mappings of Endpoint Address to
Identifier are not expected to change once they have been
established. Therefore, the cases of PubSub and mobility are not
considered in this section.
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 13]
Internet-Draft ILA-LISP March 2018
6.2.1. Resolution
As with Identifier to Locator mapping resolution, the resolution of
Endpoint Address to Identifier is done via the Map-Request/Map-Reply
exchange specified in [I-D.ietf-lisp-rfc6833bis]. It is assumed that
in the scenario where LISP is used to resolve Endpoint Address to
Identifier mappings, the MR is able to find the MS storing the
requested Endpoint Address mapping.
When Endpoint Addresses are carried as EIDs in LISP control messages
they are encoded using the same format the endpoint is using (i.e.
IPv6 in the currently defined cases). The Identifier associated to
the Endpoint Address is returned in the Map-Reply as an RLOC with
priority 255 and encoded using the LCAF defined in Section 4.1. Note
that when resolving an Endpoint Address to Identifier mapping, the
Identifier to Locator mapping can be included as well. In other
words, the Locators can also be encoded as RLOCs in the Map-Reply
returned by the MS.
In some cases (such in the Non-Local Address case) some ILA devices
may need to perform a reverse resolution of the Endpoint Address
mapping (i.e. obtain the Endpoint Address associated with a given
Identifier). In those cases, the Identifier is sent as EID in the
Map-Request with the 'E' bit (defined in Section 4.1) set to '1'.
The 'E' bit is used to signal that the requested mapping is
"Identifier to Endpoint Address" and distinguish the request from the
default "Identifier to Locator" resolution that is triggered when
sending an Identifier in the Map-Request. On this reverse
resolution, the MS will return the Endpoint Address in the Map-Reply
encoded as an RLOC with priority 255.
6.2.2. Registration
When the assignment of Endpoint Address to ILA Identifier is
performed by the ILA-N, the ILA-N can register this assignment into
its MS(s). The ILA-N encodes the Endpoint Address as EID (using the
same format the endpoint is using) and the Identifier as RLOC with
priority 255 (using the ILA-Identifier LCAF). It is assumed that the
MS(s) assigned to the ILA-N are able to understand and store the
Endpoint Address to Identifier mappings generated by the ILA-N.
Similarly to the resolution case, the Identifier to Locator mapping
can be also included when registering the Endpoint Address mapping
via means of providing too the Locators as RLOCs in the Map-Register
message.
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 14]
Internet-Draft ILA-LISP March 2018
7. Deployment Considerations
This section discusses different options and deployment scenarios to
consider when deploying an ILA data-plane using a LISP control-plane.
7.1. Protocol Transport
LISP as defined in [I-D.ietf-lisp-rfc6833bis] runs over a UDP
transport, however the exact same signaling can be used over a TCP
transport without affecting the protocol operation. If a TCP
transport is available, then the mechanisms described in
[I-D.kouvelas-lisp-map-server-reliable-transport] can also be used to
optimize the LISP control-plane protocol operation when this runs
over a reliable channel.
7.2. ILA-R and MS Co-location
The logical functions of a MS and an ILA-R serving the same domain
(or shard) can be co-located and assigned to the same box. In that
case, the ILA-R does not need to subscribe to the mappings in the
domain (or shard) since they are locally available.
In this co-location scenario it is also possible for the MS+ILA-R box
to send an unsolicited Map-Notify message (as described in
[I-D.rodrigueznatal-lisp-pubsub]) to populate the map-cache of an
ILA-N sending SIR packets towards the MS+ILA-R. This can be done
instead (or in addition) to the ILA-N sending a Map-Request message
to populate its cache.
7.3. Mapping System Internal Resolution
For small deployments where each MS has the complete mapping
information for the domain, the MRs may just be provisioned with the
Locators for all the MSs. They can then do load balancing across the
MSs based on different metrics (e.g. latency, load, etc)
If the domain is split into shards, there are different ways for a MR
to find the MS that corresponds to a given shard. Some options can
include LISP-DDT [RFC8111] or LISP-ALT [RFC6836] for instance.
There is also the option that a backend database is used as Mapping
System, in which case both the MRs and MSs are just interfaces to
interact with the backend database. In that scenario, the database
internal implementation will find the appropriate instance that is
hosting the requested mapping.
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 15]
Internet-Draft ILA-LISP March 2018
7.4. Mapping System Replication and Synchronization
For reliability and latency purposes, several MSs can be deployed for
the same domain or the same shard. In that scenario, it is required
to have a mechanism to synchronize the mapping information across
them. One option is that, as described in
[I-D.ietf-lisp-rfc6833bis], the ILA-Ns register their local mappings
to several MSs. Alternatively, when a backend database is in place,
mechanisms specific to the database implementation can be leveraged
to provide synchronization across different replicas.
7.5. Multiple ILA Domains
When different ILA domains co-exist using the same infrastructure, it
may be needed to distinguish the particular domain to which an
Identifier belongs. In that case, the Identifiers and mappings must
be qualified with the appropriate ILA domain for the control-plane
operation. This can be done by prepending the ILA-SIR LCAF described
in Section 4.3 to the ILA Identifiers or Endpoint Addresses sent as
EIDs in LISP messages.
7.6. Proactive Mapping Push
Optionally, when a MS receives a Map-Request for an Identifier, it
can send a proactive Map-Notify towards the ILA-N associated with
that Identifier. In this Map-Notify the MS includes the mapping
associated with the Identifier that triggered the Map-Request. This
will pre-populate the map-cache of the destination ILA-N and provide
the ILA-N the mapping required to handle the returning traffic. To
support this mode of operation (and following
[I-D.ietf-lisp-rfc6833bis]), the source ILA-N must include in the
Map-Request the source Identifier that triggered the Map-Request
(encoded as "Source EID" using the ILA-Identifier LCAF defined in
Section 4.1).
7.7. Checksum Adjustment per Locator
While performing ILA transformations, ILA data-plane devices
optionally perform checksum adjustments to keep the transport
checksum neutral to the transformation. As an alternative to
statically configuring the checksum-neutral adjustment option per
ILA-N (or ILA-R), the Locators associated with a particular
Identifier can be qualified with the requested selection regarding
checksum-neutral adjustment. Then, the need to perform or not this
checksum adjustment when sending traffic to a particular Locator can
be stored and retrieved from the MSs encoded in the ILA Locator LCAF
defined in Section 4.2.
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 16]
Internet-Draft ILA-LISP March 2018
8. Security Considerations
8.1. Signaling Protection
Map-Register, Map-Notify and Map-Reply messages have a field for
authentication data. As described in [I-D.ietf-lisp-rfc6833bis] a
shared key is required between the data-plane devices and their
associated MSs to sign and secure the signaling. Additional
authentication and integrity protection can be enabled by using
[I-D.ietf-lisp-sec]. Complementary, if a TCP session is in place
between the ILA data-plane elements and the LISP control-plane
components, then TLS can be used to provide authentication and
integrity protection.
8.2. Map-Cache Attacks
Malicious endpoints can try to deplete the map-cache and/or overload
the Map-Request channel of an ILA-N. To prevent against these
attacks, the ILA-N should implement efficient heavy hitters counters
such as Count-Min Sketch [CMS] to prevent data-plane traffic from
certain endpoints to trigger further control-plane processing once a
threshold has been reached. In addition, similar mechanisms can be
used to protect popular map-cache entries from eviction when the map-
cache space is being depleted.
9. Acknowledgments
The authors would like to thank Sri Gundavelli and Marc Portoles-
Comeras for their comments and feedback while writing this document.
10. IANA Considerations
Following the guidelines of [RFC5226], this document requests IANA to
update the "LISP Canonical Address Format (LCAF) Types" Registry
defined in [RFC8060] to allocate the following assignment:
+---------+---------------------+-----------+
| Value # | LISP LCAF Type Name | Reference |
+---------+---------------------+-----------+
| TBD | ILA | Section 4 |
+---------+---------------------+-----------+
Table 1: ILA LCAF assignment
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 17]
Internet-Draft ILA-LISP March 2018
11. Normative References
[CMS] Cormode, G. and S. Muthukrishnan, "An improved data stream
summary: the count-min sketch and its applications",
Journal of Algorithms 55(1), 58-75, April 2005.
[I-D.herbert-ila-ilamp]
Herbert, T., "Identifier Locator Addressing Mapping
Protocol", draft-herbert-ila-ilamp-00 (work in progress),
December 2017.
[I-D.herbert-intarea-ila]
Herbert, T. and P. Lapukhov, "Identifier-locator
addressing for IPv6", draft-herbert-intarea-ila-00 (work
in progress), October 2017.
[I-D.ietf-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-ietf-lisp-eid-mobility-01
(work in progress), November 2017.
[I-D.ietf-lisp-rfc6833bis]
Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
"Locator/ID Separation Protocol (LISP) Control-Plane",
draft-ietf-lisp-rfc6833bis-07 (work in progress), December
2017.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
(work in progress), October 2017.
[I-D.kouvelas-lisp-map-server-reliable-transport]
Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J.
Arango, "LISP Map Server Reliable Transport", draft-
kouvelas-lisp-map-server-reliable-transport-04 (work in
progress), September 2017.
[I-D.lapukhov-bgp-ila-afi]
Lapukhov, P., "Use of BGP for dissemination of ILA mapping
information", draft-lapukhov-bgp-ila-afi-02 (work in
progress), October 2016.
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 18]
Internet-Draft ILA-LISP March 2018
[I-D.rodrigueznatal-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
Boucadair, M., Jacquenet, C., and S. Secci,
"Publish/Subscribe Functionality for LISP", draft-
rodrigueznatal-lisp-pubsub-02 (work in progress), February
2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[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, <https://www.rfc-editor.org/info/rfc6836>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/info/rfc8111>.
Authors' Addresses
Alberto Rodriguez-Natal
Cisco Systems
170 Tasman Drive
San Jose, CA
USA
Email: natal@cisco.com
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 19]
Internet-Draft ILA-LISP March 2018
Vina Ermagan
Cisco Systems
170 Tasman Drive
San Jose, CA
USA
Email: vermagan@cisco.com
Fabio Maino
Cisco Systems
170 Tasman Drive
San Jose, CA
USA
Email: fmaino@cisco.com
Albert Cabellos
Technical University of Catalonia
Barcelona
Spain
Email: acabello@ac.upc.edu
Rodriguez-Natal, et al. Expires September 4, 2018 [Page 20]