Network Working Group A. Rodriguez-Natal Internet-Draft V. Ermagan Intended status: Experimental F. Maino Expires: October 7, 2018 Cisco Systems A. Cabellos Technical University of Catalonia April 5, 2018 LISP control-plane for Identifier Locator Addressing (ILA) draft-rodrigueznatal-ila-lisp-01 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 October 7, 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 October 7, 2018 [Page 1] Internet-Draft ILA-LISP April 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. LISP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 4. ILA encoding in LISP . . . . . . . . . . . . . . . . . . . . 4 4.1. ILA LCAF . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.1. Identifier Subtype . . . . . . . . . . . . . . . . . 5 4.1.2. Locator Subtype . . . . . . . . . . . . . . . . . . . 7 4.1.3. SIR Prefix Subtype . . . . . . . . . . . . . . . . . 8 4.2. IPv6 addresses . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Identifiers . . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Locators . . . . . . . . . . . . . . . . . . . . . . 9 5. Device Roles and Provision . . . . . . . . . . . . . . . . . 9 5.1. Map Server (MS) . . . . . . . . . . . . . . . . . . . . . 10 5.2. Map Resolver (MR) . . . . . . . . . . . . . . . . . . . . 10 5.3. ILA-Router (ILA-R) . . . . . . . . . . . . . . . . . . . 10 5.4. ILA-Node (ILA-N) . . . . . . . . . . . . . . . . . . . . 10 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. ILA Identifier to Locator Mappings . . . . . . . . . . . 11 6.1.1. Resolution (via Map-Request to MR) . . . . . . . . . 12 6.1.2. Resolution (via Map-Notify from ILA-R/MS) . . . . . . 12 6.1.3. Registration . . . . . . . . . . . . . . . . . . . . 13 6.1.4. PubSub . . . . . . . . . . . . . . . . . . . . . . . 13 6.1.5. Mobility . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Endpoint Address to ILA Identifier/Locator Mappings . . . 14 6.2.1. Resolution . . . . . . . . . . . . . . . . . . . . . 15 6.2.2. Registration . . . . . . . . . . . . . . . . . . . . 16 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 16 7.1. Protocol Transport . . . . . . . . . . . . . . . . . . . 16 7.2. Mapping System Internal Resolution . . . . . . . . . . . 16 7.3. Mapping System Replication and Synchronization . . . . . 17 7.4. Multiple ILA Domains . . . . . . . . . . . . . . . . . . 17 7.5. Proactive Mapping Push . . . . . . . . . . . . . . . . . 17 7.6. Checksum Adjustment per Locator . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8.1. Signaling Protection . . . . . . . . . . . . . . . . . . 18 8.2. Map-Cache Attacks . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Rodriguez-Natal, et al. Expires October 7, 2018 [Page 2] Internet-Draft ILA-LISP April 2018 1. Introduction The Locator/ID Separation Protocol (LISP) control-plane document [I-D.ietf-lisp-rfc6833bis] defines a generic Mapping Service that in addition to encapsulation-based Loc-ID separation data-planes, such as the LISP data-plane [I-D.ietf-lisp-rfc6830bis], can be also applied to translation-based Loc-ID separation data-planes. Between the translation-based Loc-ID separation data-planes, this document focuses on the use of LISP control-plane with the Identifier Locator Addressing (ILA) [I-D.herbert-intarea-ila] data-plane, but a similar approach can be used with other translation-based Loc-ID separation data-planes such as the SRv6 Network Programming [I-D.filsfils-spring-srv6-network-programming] data-plane, or the Identifier-Locator Network Protocol (ILNP) [RFC6740] data-plane. The Identifier Locator Addressing (ILA) is an IPv6 data-plane protocol that relies on address splitting for ID/location separation. Part of the IPv6 address expresses the 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 describes how the LISP control-plane 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]. Rodriguez-Natal, et al. Expires October 7, 2018 [Page 3] Internet-Draft ILA-LISP April 2018 3. LISP Overview TBD 4. ILA encoding in LISP ILA Identifiers and Locators can be encoded in LISP messages using an ILA-specific LCAF type or within IPv6 addresses. This section describes both options. 4.1. ILA LCAF To support explicit ILA mappings and associated data using the LISP control-plane the following LISP Canonical Address Format (LCAF) [RFC8060] is introduced. The ILA LCAF permits to explicitly identify addresses as ILA Identifiers or Locators, allows to explicitly indicate the length of the Identifier or Locator and enables to carry ILA specific metadata with the ILA Identifiers and Locators. The ILA LCAF type defines several subtypes, 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: 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.1 Rodriguez-Natal, et al. Expires October 7, 2018 [Page 4] Internet-Draft ILA-LISP April 2018 0x2: Locator Subtype. Used to encode ILA Locators as described in Section 4.1.2 0x3: SIR Prefix Subtype. Used to encode SIR Prefixes as described in Section 4.1.3 4.1.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. 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Rodriguez-Natal, et al. Expires October 7, 2018 [Page 5] Internet-Draft ILA-LISP April 2018 For reference and using an 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) 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) Rodriguez-Natal, et al. Expires October 7, 2018 [Page 6] Internet-Draft ILA-LISP April 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x4 |0| VNID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope | Virtual Multicast IPv6 (lower 28 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Virtual Multicast IPv6 Identifier (0x4) 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.1.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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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.6 for more details. Rodriguez-Natal, et al. Expires October 7, 2018 [Page 7] Internet-Draft ILA-LISP April 2018 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. 4.1.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.4. 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. 4.2. IPv6 addresses Alternatively, ILA Identifiers and Locators can be encoded in LISP messages using just IPv6 addresses. This section describes how to encode each. Using an IPv6 representation does not require to use any LCAF but prevents from being explicit on the length and ILA semantics of the Identifiers and Locators, as well as from carrying associated metadata. 4.2.1. Identifiers ILA Identifiers are encoded in the lower end bits of an IPv6 address when used within LISP control messages. The upper bits of the IPv6 address encode the SIR prefix to which the Identifier belongs to. Rodriguez-Natal, et al. Expires October 7, 2018 [Page 8] Internet-Draft ILA-LISP April 2018 4.2.2. Locators ILA Locators are encoded in the upper end bits of an IPv6 address when used within LISP control messages. There are two options on what to encode in the lower bits of the IPv6 address carrying the ILA Locator. One option is to encode the ILA Identifier that triggered the LISP control message. Another option is to encode the Control- Plane Identifier described in Section 5. In the latter case, there is no longer needed to statically configure the Control-Plane Identifier in the different devices. 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 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. Rodriguez-Natal, et al. Expires October 7, 2018 [Page 9] Internet-Draft ILA-LISP April 2018 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.2 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.4) to a MS (or to the MS responsible for its shard) to populate and keep its map-cache updated. 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. Normally, an ILA-R has no endpoint (e.g. task, user-endpoint, etc) directly attached. Instead, it serves to translate packets that were not transformed 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. An ILA-R has to be pre-provisioned with the following: Shard index: of the shard the ILA-R is assigned to. 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) Rodriguez-Natal, et al. Expires October 7, 2018 [Page 10] Internet-Draft ILA-LISP April 2018 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.3. 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) 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.6). 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. 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. Two different modes of resolving the Identifier are described, one on which the ILA-N sends a Map-Request to a MR and another where a ILA-R with a co-located MS reacts to data-plane traffic and sends a Map- Notify towards the ILA-N. Rodriguez-Natal, et al. Expires October 7, 2018 [Page 11] Internet-Draft ILA-LISP April 2018 6.1.1. Resolution (via Map-Request to MR) When an ILA-N has to send traffic towards a remote Identifier for which it does not have the associated Locator, it can obtain the Locator via sending a request to the MR. 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 as described in Section 4. 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 as discussed in Section 4. 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 still send the data packets to the underlay using the SIR address as described in [I-D.herbert-intarea-ila]. In that way, they can be attracted and transformed 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. Resolution (via Map-Notify from ILA-R/MS) As described in [I-D.herbert-intarea-ila], the ILA-N sends the SIR traffic to the underlay if it has no map-cache entry to transform packets. The SIR traffic will be eventually attracted to an ILA-R announcing the SIR prefix. Thus, the cache of an ILA-N can also be populated via unsolicited Map-Notifies (as described in [I-D.rodrigueznatal-lisp-pubsub]) when the MS is co-located with the ILA-R. In this scenario, the ILA-R/MS reacts to the data-plane traffic received sending unsolicited Map-Notify to the origin of the traffic. To build the Map-Notify, the ILA-R extracts the ILA Identifier from the data-packet received and finds the matching mapping entry in its co-located MS. The ILA-R/MS then encodes the Identifier and Locators from that mapping as EID and RLOC(s) respectively in the Map-Notify, using the encoding described in Section 4. In general, the unsolicited Map-Notify resolution mode assumes that the ILA-R/MS has both the mapping for the destination Identifier as well as the source Identifier received in the data-packet. If the Rodriguez-Natal, et al. Expires October 7, 2018 [Page 12] Internet-Draft ILA-LISP April 2018 ILA domain is sharded and the ILA-R/MS does not contain the mapping for the source Identifier, the Map-Notify has to be routed towards another ILA-R/MS that contains the Locator for the source Identifier. 6.1.3. 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 encoding defined in Section 4 to include the ILA Identifier 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 encoding defined in Section 4. 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. 6.1.4. PubSub An ILA-N can explicitly subscribe to mapping updates using the mechanisms described in [I-D.rodrigueznatal-lisp-pubsub]. When using the mapping resolution described in Section 6.1.1 to populate its map-cache, an ILA-N can combine the resolution and subscription into the same Map-Request/Map-Reply exchange. Additionally, when ILA-Rs are not co-located with the MSs they need to subscribe to mappings in the domain (or their shard). 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 encodes the ILA Identifier as described in Section 4 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 encodes the Identifier with the proper shard index set and the rest of the Identifier bits set to 0. 6.1.5. 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 Rodriguez-Natal, et al. Expires October 7, 2018 [Page 13] Internet-Draft ILA-LISP April 2018 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, transformed 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 transformed 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. 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 Rodriguez-Natal, et al. Expires October 7, 2018 [Page 14] Internet-Draft ILA-LISP April 2018 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. 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 as defined in Section 4. 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, and when using the encoding described in Section 4.1.1, the Identifier is sent as EID in the Map-Request with the 'E' bit (defined in Section 4.1.1) set to '1'. The 'E' bit is used to signal that the requested mapping is "Identifier to Rodriguez-Natal, et al. Expires October 7, 2018 [Page 15] Internet-Draft ILA-LISP April 2018 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. If the encoding described in Section 4.2 is used instead, both the Endpoint Address and the Locators have to be returned when querying for an ILA Identifier. In this latter case, the Endpoint Address is still encoded in the Map-Reply 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 encoding discussed in Section 4). 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. 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. 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) Rodriguez-Natal, et al. Expires October 7, 2018 [Page 16] Internet-Draft ILA-LISP April 2018 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. 7.3. 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.4. Multiple ILA Domains When different ILA domains co-exist using the same infrastructure, it may be needed to distinguish the particular domain to which a control message refers to. In that case, the Identifiers and Endpoint Addresses 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.1.3 when needed. If the encoding described in Section 4.1 is used both the ILA Identifiers and Endpoint Addresses need to be qualified when used as EIDs in LISP messages. When the encoding described in Section 4.2 is used only Endpoint Addresses need to be qualified. 7.5. Proactive Mapping Push Optionally, when a MS receives a Map-Request (or when an ILA-R/MS receives data-traffic) for an Identifier, it can send a proactive Map-Notify towards the ILA-N associated with that Identifier. In this Map-Notify the MS (or ILA-R/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. This mechanism assumes that the MS (or ILA-R/MS) has both the mapping for the destination and source Identifiers. Rodriguez-Natal, et al. Expires October 7, 2018 [Page 17] Internet-Draft ILA-LISP April 2018 7.6. 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.1.2. 8. Security Considerations 8.1. Signaling Protection All LISP messages have a field for authentication data defined in either [I-D.ietf-lisp-rfc6833bis] or [I-D.ietf-lisp-sec]. 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. Discussion on how to apply heavy hitter counters to LISP in particular can be found in [CMS-LISP]. 9. Acknowledgments The authors would like to thank Sri Gundavelli, Marc Portoles- Comeras, Tom Herbert, Dino Farinacci, Joel Halpern and Luigi Iannone for their comments and feedback regarding this document. Rodriguez-Natal, et al. Expires October 7, 2018 [Page 18] Internet-Draft ILA-LISP April 2018 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.1 | +---------+---------------------+-------------+ Table 1: ILA LCAF assignment 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI 10.17487/RFC6740, November 2012, . [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, . [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . [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, . Rodriguez-Natal, et al. Expires October 7, 2018 [Page 19] Internet-Draft ILA-LISP April 2018 11.2. Informative 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. [CMS-LISP] Almasan, P., Paillisse, J., Rodriguez-Natal, A., Barlet- Ros, P., Coras, F., Ermagan, V., Maino, F., and A. Cabellos-Aparicio, "Securing the Control-plane Channel and Cache of Pull-based ID/LOC Protocols", ArXiv e-prints 1803.08568, March 2018. [I-D.filsfils-spring-srv6-network-programming] Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and M. Sharif, "SRv6 Network Programming", draft-filsfils- spring-srv6-network-programming-04 (work in progress), March 2018. [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-01 (work in progress), March 2018. [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-rfc6830bis] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos-Aparicio, "The Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress), March 2018. Rodriguez-Natal, et al. Expires October 7, 2018 [Page 20] Internet-Draft ILA-LISP April 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-10 (work in progress), March 2018. [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. [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. stefano.secci@lip6.fr, "Publish/Subscribe Functionality for LISP", draft-rodrigueznatal-lisp-pubsub-02 (work in progress), March 2018. Authors' Addresses Alberto Rodriguez-Natal Cisco Systems 170 Tasman Drive San Jose, CA USA Email: natal@cisco.com Vina Ermagan Cisco Systems 170 Tasman Drive San Jose, CA USA Email: vermagan@cisco.com Rodriguez-Natal, et al. Expires October 7, 2018 [Page 21] Internet-Draft ILA-LISP April 2018 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 October 7, 2018 [Page 22]