[lisp] Review 6833bis
Luigi Iannone <ggx@gigix.net> Fri, 16 March 2018 11:28 UTC
Return-Path: <ggx@gigix.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643F1127735 for <lisp@ietfa.amsl.com>; Fri, 16 Mar 2018 04:28:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxTTHxEdWSmR for <lisp@ietfa.amsl.com>; Fri, 16 Mar 2018 04:27:52 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB108126BF7 for <lisp@ietf.org>; Fri, 16 Mar 2018 04:27:51 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id l8so11356526wrg.5 for <lisp@ietf.org>; Fri, 16 Mar 2018 04:27:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=EEWrDcszi1y/DhNNcxjcv+ZZVf6/VW5VusEdSixUE2k=; b=oV8jRCzGCnqeJvmrz8jYh5m+ALTYWUg3GzThT8bDFJCP8NqvypdElB1OVJVV4QC4b3 aIMpQGSEjqnwVMqMffhn6T8HEoq5futuwGmP730SPwVd9B6tDufXmZv5dsBM1dAXpGVu suKx7YA+S8fHbV3XzBsO3p7mQ8fTFRvkSCZyJQla06cqn1kXUr2naPj+eJr59IHjGTcO HYcRfF9cq7PoXk5+d8j8UO51hUbNCi8RYTK6pFvKtS2fQxKgVdtdXNn3uNDMsAk7igw5 ZWScKl79d78b10jYSuu0xldyYZNpYIJ+nQECHBmrdyw4PcQlCvCOtfwsVCDyBEwE3XG/ qr0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=EEWrDcszi1y/DhNNcxjcv+ZZVf6/VW5VusEdSixUE2k=; b=EAgHoKDxwM2HLH743tYV3MohatgHvCMJ5MnYQ7eFRzWaRq2JW97D5uNtcLEnZwq+1V /xU6OpRvTx9eEJzckV8wBPjG29mu7XtFNnlCwC3+n/+hThFmdw/7lgAe+K10WxZlagqb 5tvhL2fvkj0AAEHmc7Oey1zLSHoWIIUroN54wHgwN5F5ajWCULMJBxQkWPZtMvq1kLFg SSkpBJT//eh1D9hvMY3cdriYYUKGG7IqjBpSka1FPpuVUisUlHBJT2Loms/YE1fy1Sfl 8oV1s4fM8RcHJb9VS2FGByTndZoW26QY90/F+YH1iaI0oN4OeWI54tPEQoTHuxkj3H+L yNfA==
X-Gm-Message-State: AElRT7GBSY1E+XQ7EGqrHcRZ+e0dC3rM0nNwbt9h4cf+nHjjHwu/NsjW WN8TnJZgZby6umLUmbZ1G746NyVo3nE=
X-Google-Smtp-Source: AG47ELuTKCKvHOUz65h0MeANotAq4LwrrgxaHC0aIdbumzlhqfzJHL07Jj8+rbkwPGXW9yRMEDl0zQ==
X-Received: by 10.223.164.158 with SMTP id g30mr1230984wrb.62.1521199667092; Fri, 16 Mar 2018 04:27:47 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:8452:5945:5fad:4d8e? ([2001:660:330f:a4:8452:5945:5fad:4d8e]) by smtp.gmail.com with ESMTPSA id v124sm5357537wme.27.2018.03.16.04.27.45 for <lisp@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Mar 2018 04:27:45 -0700 (PDT)
From: Luigi Iannone <ggx@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E838CF2A-7ACF-4F14-B8D9-6E5BDD241AC9"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Message-Id: <B6E99388-F4B4-4980-B1F7-3351B4889AB4@gigix.net>
Date: Fri, 16 Mar 2018 12:27:44 +0100
To: "lisp@ietf.org list" <lisp@ietf.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/2X8cJhEZKLk8iCyJaX1OO3oFgUA>
Subject: [lisp] Review 6833bis
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2018 11:28:05 -0000
Hi All, I’ve read 6833bis document. My few comments cab be found inline. Ciao L. A general remark, the document mixes the use of: map-cache vs Map-Cache data-plane vs Data-Plane control-plane vs Control-Plane Should be changed to be the same everywhere, just choose one. > > > > > > Network Working Group V. Fuller > Internet-Draft D. Farinacci > Intended status: Standards Track Cisco Systems > Expires: September 5, 2018 A. Cabellos (Ed.) > UPC/BarcelonaTech > March 4, 2018 > > > Locator/ID Separation Protocol (LISP) Control-Plane > draft-ietf-lisp-rfc6833bis-08 > > Abstract > > This document describes the Control-Plane and Mapping Service for the > Locator/ID Separation Protocol (LISP), implemented by two new types > of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server > -- that provides a simplified "front end" for one or more Endpoint ID > to Routing Locator mapping databases. > > By using this control-plane service interface and communicating with > Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and > Egress Tunnel Routers (ETRs) are not dependent on the details of > mapping database systems, which facilitates modularity with different > database designs. Since these devices implement the "edge" of the > LISP infrastructure, I would put “LISP Control-Plane infrastructure”. > connect directly to LISP-capable Internet end s/connect/connecting/ > sites, and comprise s/comprise/comprising/ > the bulk of LISP-speaking devices, reducing their > implementation and operational complexity should also reduce the > overall cost and effort of deploying LISP. > > 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 5, 2018. > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 1] > > Internet-Draft LISP Control-Plane March 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 > 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 Notation . . . . . . . . . . . . . . . . . . . . 4 > 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 > 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 > 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 > 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 > 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 > 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 > 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15 > 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 > 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22 > 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 > 5.8. Encapsulated Control Message Format . . . . . . . . . . . 26 > 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 > 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28 > 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 29 > 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 > 8. Interactions with Other LISP Components . . . . . . . . . . . 32 > 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 > 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 33 > 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 35 > 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 35 > 8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 36 > 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 > 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 > 10.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 37 > 10.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 37 > 10.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 38 > 10.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 38 > 10.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 38 > 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 > > > > Fuller, et al. Expires September 5, 2018 [Page 2] > > Internet-Draft LISP Control-Plane March 2018 > > > 11.1. Normative References . . . . . . . . . . . . . . . . . . 39 > 11.2. Informative References . . . . . . . . . . . . . . . . . 40 > Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 43 > Appendix B. Document Change Log . . . . . . . . . . . . . . . . 43 > B.1. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 43 > B.2. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 43 > B.3. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 44 > B.4. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 44 > B.5. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 44 > B.6. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 44 > B.7. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 45 > B.8. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 45 > B.9. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 45 > B.10. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 45 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 > > 1. Introduction > > The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and > [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism > for replacing the addresses currently used by IP with two separate > name spaces: I would rephrase the above as follows: The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism for dynamic tunnelling by logically separating the addresses currently used by IP in two separate name spaces: > Endpoint IDs (EIDs), used within sites; and Routing > Locators (RLOCs), used on the transit networks that make up the > Internet infrastructure. To achieve this separation, LISP defines > protocol mechanisms for mapping from EIDs to RLOCs. In addition, > LISP assumes the existence of a database to store and propagate those > mappings globally. Several such databases have been proposed; among > them are the Content distribution Overlay Network Service for LISP > (LISP-CONS) [LISP-CONS], I would delete LISP-CONS that proposal went nowhere. > LISP-NERD (a Not-so-novel EID-to-RLOC > Database) [RFC6837], LISP Alternative Logical Topology (LISP+ALT) > [RFC6836], and LISP Delegated Database Tree (LISP-DDT) [RFC8111]. > > The LISP Mapping Service defines two new types of LISP-speaking > devices: the Map-Resolver, which accepts Map-Requests from an Ingress > Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a > mapping database; and the Map-Server, which learns authoritative EID- > to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes > them in a database. > > This LISP Control-Plane Mapping Service can be used by many different > encapsulation-based or translation-based data-planes which include > but are not limited to the ones defined in LISP RFC 6830bis > [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN > [RFC7348], and VXLAN-GPE [I-D.quinn-vxlan-gpe]. > I would add a reference to ILA. > Conceptually, LISP Map-Servers share some of the same basic > configuration and maintenance properties as Domain Name System (DNS) > [RFC1035] servers; likewise, Map-Resolvers are conceptually similar > > > > Fuller, et al. Expires September 5, 2018 [Page 3] > > Internet-Draft LISP Control-Plane March 2018 > > > to DNS caching resolvers. With this in mind, this specification > borrows familiar terminology (resolver and server) from the DNS > specifications. > > Note that while this document assumes a LISP+ALT database mapping > infrastructure to illustrate certain aspects of Map-Server and Map- > Resolver operation, the Mapping Service interface can (and likely > will) be used by ITRs and ETRs to access other mapping database > systems as the LISP infrastructure evolves. > > The LISP Mapping Service is an important component of the LISP > toolset. Issues and concerns about the deployment of LISP for > Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis]. > The last sentence above should reference the upcoming OAM document and RFC7215. > 2. Requirements Notation > > 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. Definition of Terms > > Map-Server: A network infrastructure component that learns of EID- > Prefix mapping entries from an ETR, via the registration mechanism > described below, or some other authoritative source if one exists. > A Map-Server publishes these EID-Prefixes in a mapping database. > > Map-Request: A LISP Map-Request is a control-plane message to query > the mapping system to resolve an EID. A LISP Map-Request can also > be sent to an RLOC to test for reachability and to exchange > security keys between an encapsulator and a decapsulator. This > type of Map-Request is also known as an RLOC-Probe Request. > > Map-Reply: A LISP Map-Reply is a control-plane message returned in > response to a Map-Request sent to the mapping system when > resolving an EID. A LISP Map-Reply can also be returned by a > decapsulator in response to a Map-Request sent by an encapsulator > to test for reachability. This type of Map-Reply is known as a > RLOC-Probe Reply. > > Encapsulated Map-Request: A LISP Map-Request carried within an > Encapsulated Control Message (ECM), which has an additional LISP > header prepended. Sent to UDP destination port 4342. The "outer" > addresses are routable IP addresses, also known as RLOCs. Used by > an ITR when sending to a Map-Resolver and by a Map-Server when > forwarding a Map-Request to an ETR. > > > > > > Fuller, et al. Expires September 5, 2018 [Page 4] > > Internet-Draft LISP Control-Plane March 2018 > > > Map-Resolver: A network infrastructure component that accepts LISP > Encapsulated (ECM) Map-Requests, typically from an ITR, and > determines whether or not the destination IP address is part of > the EID namespace; if it is not, a Negative Map-Reply is returned. > Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC > mapping by consulting a mapping database system. > > Negative Map-Reply: A LISP Map-Reply that contains an empty > Locator-Set. Returned in response to a Map-Request if the > destination EID does not exist in the mapping database. > Typically, this means that the "EID" being requested is an IP > address connected to a non-LISP site. > > Map-Register message: A LISP message sent by an ETR to a Map-Server > to register its associated EID-Prefixes. In addition to the set > of EID-Prefixes to register, the message includes one or more > RLOCs to reach ETR(s). The Map-Server uses these RLOCs when > forwarding Map-Requests (re-formatted as Encapsulated Map- > Requests). An ETR MAY request that the Map-Server answer Map- > Requests on its behalf by setting the "proxy Map-Reply" flag > (P-bit) in the message. > > Map-Notify message: A LISP message sent by a Map-Server to an ETR > to confirm that a Map-Register has been received and processed. > An ETR requests that a Map-Notify be returned by setting the > "want-map-notify" flag (M-bit) in the Map-Register message. > Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both > source and destination. Map-Notify messages are also sent to ITRs > by Map-Servers when there are RLOC-set changes. > > For definitions of other terms, notably Ingress Tunnel Router (ITR), > Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR), > refer to the LISP Data-Plane specification > [I-D.ietf-lisp-rfc6830bis]. > > 4. Basic Overview > > A Map-Server is a device that publishes EID-Prefixes in a LISP > mapping database on behalf of a set of ETRs. When it receives a Map > Request (typically from an ITR), it consults the mapping database to > find an ETR that can answer with the set of RLOCs for an EID-Prefix. > To publish its EID-Prefixes, an ETR periodically sends Map-Register > messages to the Map-Server. A Map-Register message contains a list > of EID-Prefixes plus a set of RLOCs that can be used to reach the > ETRs. > > When LISP+ALT Add reference [RFC6836] > is used as the mapping database, a Map-Server connects > to the ALT network and acts as a "last-hop" ALT-Router. Intermediate > > > > Fuller, et al. Expires September 5, 2018 [Page 5] > > Internet-Draft LISP Control-Plane March 2018 > > > ALT-Routers forward Map-Requests to the Map-Server that advertises a > particular EID-Prefix, and the Map-Server forwards them to the owning > ETR, which responds with Map-Reply messages. > > When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server > sends the final Map-Referral messages from the Delegated Database > Tree. > > A Map-Resolver receives Encapsulated Map-Requests from its client > ITRs and uses a mapping database system to find the appropriate ETR > to answer those requests. On a LISP+ALT network, a Map-Resolver acts > as a "first-hop" ALT-Router. It has Generic Routing Encapsulation > (GRE) tunnels configured to other ALT-Routers and uses BGP to learn > paths to ETRs for different prefixes in the LISP+ALT database. The > Map-Resolver uses this path information to forward Map-Requests over > the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map- > Resolver maintains a referral-cache and acts as a "first-hop" DDT- > node. The Map-Resolver uses the referral information to forward Map- > Requests. > > Note that while it is conceivable that a Map-Resolver could cache > responses to improve performance, issues surrounding cache management > will need to be resolved so that doing so will be reliable and > practical. As initially deployed, Map-Resolvers will operate only in > a non-caching mode, decapsulating and forwarding Encapsulated Map > Requests received from ITRs. Any specification of caching > functionality is left for future work. s/left for future work/ out of the scope of this document/ > > Note that a single device can implement the functions of both a Map- > Server and a Map-Resolver, and in many cases the functions will be > co-located in that way. Also, there can be ALT-only nodes and DDT- > only nodes, when LISP+ALT and LISP-DDT are used, respectively, to > connect Map-Resolvers and Map-Servers together to make up the Mapping > System. > > Detailed descriptions of the LISP packet types referenced by this > document may be found in [I-D.ietf-lisp-rfc6830bis]. Last sentece to be deleted. This document describe the various packet types. > > > > > > > > > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 6] > > Internet-Draft LISP Control-Plane March 2018 > > > 5. LISP IPv4 and IPv6 Control-Plane Packet Formats > > The following UDP packet formats are used by the LISP control plane. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| IHL |Type of Service| Total Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification |Flags| Fragment Offset | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Time to Live | Protocol = 17 | Header Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source Routing Locator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination Routing Locator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | Source Port | Dest Port | > UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ | UDP Length | UDP Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | LISP Message | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| Traffic Class | Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Length | Next Header=17| Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Source Routing Locator + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Destination Routing Locator + > | | > + + > > > > Fuller, et al. Expires September 5, 2018 [Page 7] > > Internet-Draft LISP Control-Plane March 2018 > > > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | Source Port | Dest Port | > UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ | UDP Length | UDP Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | LISP Message | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > When a UDP Map-Request, Map-Register, or Map-Notify (when used as a > notification message) are sent, the UDP source port is chosen by the > sender and the destination UDP port number is set to 4342. When a > UDP Map-Reply Map-Notify (when used as an acknowledgement to a Map- > Register), or Map-Notify-Ack are sent, the source UDP port number is > set to 4342 and the destination UDP port number is copied from the > source port of either the Map-Request or the invoking data packet. > Implementations MUST be prepared to accept packets when either the > source port or destination UDP port is set to 4342 due to NATs > changing port number values. > > The 'UDP Length' field will reflect the length of the UDP header and > the LISP Message payload. > > The UDP checksum is computed and set to non-zero for all messages > sent to or from port 4342. It MUST be checked on receipt, and if the > checksum fails, the control message MUST be dropped. I would put a reference to RFC1071 for the UDP checksum calculation > > The format of control messages includes the UDP header so the > checksum and length fields can be used to protect and delimit message > boundaries. > > > > > > > > > > > > > > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 8] > > Internet-Draft LISP Control-Plane March 2018 > > > 5.1. LISP Control Packet Type Allocations > > This section defines the LISP control message formats and summarizes > for IANA the LISP Type codes assigned by this document. For > completeness, this document references the LISP Shared Extension > Message assigned by [RFC8113]. Message type definitions are: > > Reserved: 0 b'0000' > LISP Map-Request: 1 b'0001' > LISP Map-Reply: 2 b'0010' > LISP Map-Register: 3 b'0011' > LISP Map-Notify: 4 b'0100' > LISP Map-Notify-Ack: 5 b'0101' > LISP Map-Referral: 6 b'0110' > LISP Encapsulated Control Message: 8 b'1000' > Not Assigned 9-14 b'1001'- b'1110' > LISP Shared Extension Message: 15 b'1111' [RFC8113] > > Values in the "Not Assigned" range can be assigned according to > procedures in [RFC8126]. Documents that request for a new LISP > packet type MAY indicate a preferred value in Section 10.4. Don’t understand the “in Section 10.4” part. Should be deleted. > > Protocol designers experimenting with new message formats SHOULD use > the LISP Shared Extension Message Type and request a [RFC8113] sub- > type assignment. > > All LISP control-plane messages use Address Family Identifiers (AFI) > [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to > encode either fixed or variable length addresses. This includes > explicit fields in each control message or part of EID-records or > RLOC-records in commonly formatted messages. > > The LISP control-plane describes how other data-planes can encode > messages to support the SMR and RLOC-probing procedures of the LISP > data-plane defined in [I-D.ietf-lisp-rfc6830bis]. SMR and RLOC probing are in this document so the sentence above should be: The LISP control-plane describes how other data-planes can encode messages to support the SMR and RLOC-probing procedures. > This control-plane > specification itself does not offer such functionality and other > data-planes can use their own mechanisms that do not rely on the LISP > control-plane. > > > > > > > > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 9] > > Internet-Draft LISP Control-Plane March 2018 > > > 5.2. Map-Request Message Format > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Type=1 |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Nonce . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | . . . Nonce | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source-EID-AFI | Source EID Address ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ITR-RLOC-AFI n | ITR-RLOC Address n ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | Reserved | EID mask-len | EID-Prefix-AFI | > Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ | EID-Prefix ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Map-Reply Record ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Packet field descriptions: > > Type: 1 (Map-Request) > > A: This is an authoritative bit, which is set to 0 for UDP-based Map- > Requests sent by an ITR. It is set to 1 when an ITR wants the > destination site to return the Map-Reply rather than the mapping > database system. > > M: This is the map-data-present bit. When set, it indicates that a > Map-Reply Record segment is included in the Map-Request. > > P: This is the probe-bit, which indicates that a Map-Request SHOULD > be treated as a Locator reachability probe. The receiver SHOULD > respond with a Map-Reply with the probe-bit set, indicating that > the Map-Reply is a Locator reachability probe reply, with the > nonce copied from the Map-Request. Technical question: If P is set we are specifically contacting an RLOC, an xTR that is authoritative. What happens if P=1 and A=0? Or if P=1 then A should as well be 1? > See RLOC-Probing > [I-D.ietf-lisp-rfc6830bis] for more details Reference should be updated to Section 7. > . > > S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map- > Request (SMRs) [I-D.ietf-lisp-rfc6830bis] for details. Reference to be updated to Section 6. > > > > > Fuller, et al. Expires September 5, 2018 [Page 10] > > Internet-Draft LISP Control-Plane March 2018 > > > p: This is the PITR bit. This bit is set to 1 when a PITR sends a > Map-Request. > > s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is > sending a Map-Request in response to a received SMR-based Map- > Request. > > m: This is the LISP mobile-node m-bit. This bit is set by xTRs that > operate as a mobile node as defined in [I-D.ietf-lisp-mn]. > > I: This is the xTR-ID bit. When this bit is set, what is appended to > the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage > procedures in [I-D.rodrigueznatal-lisp-pubsub] for details. > > Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on > receipt. > > L: This is the local-xtr bit. It is used by an xTR in a LISP site to > tell other xTRs in the same site that it is local to the site. > That is, that it is part of the RLOC-set for the LISP site. The L bit definition is not so clear: What exactly is local to the LISP site? > > D: This is the dont-map-reply bit. It is used in the SMR procedure > described in [I-D.ietf-lisp-rfc6830bis]. Update reference to Section 6. > When an xTR sends an SMR > Map-Request message, it doesn't need a Map-Reply returned. When > this bit is set, the receiver of the Map-Request does not return a > Map-Reply. > > IRC: This 5-bit field is the ITR-RLOC Count, which encodes the > additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields > present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- > Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields > are used, so a Map-Replier can select which destination address to > use for a Map-Reply. The IRC value ranges from 0 to 31. For a > value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, > there are 2 ITR-RLOC addresses encoded, and so on up to 31, which > encodes a total of 32 ITR-RLOC addresses. > > Record Count: This is the number of records in this Map-Request > message. A record is comprised of the portion of the packet that > is labeled 'Rec' above and occurs the number of times equal to > Record Count. For this version of the protocol, a receiver MUST > accept and process Map-Requests that contain one or more records, > but a sender MUST only send Map-Requests containing one record. > Support for requesting multiple EIDs in a single Map-Request > message will be specified in a future version of the protocol. > > Nonce: This is an 8-octet random value created by the sender of the > Map-Request. This nonce will be returned in the Map-Reply. The > > > > Fuller, et al. Expires September 5, 2018 [Page 11] > > Internet-Draft LISP Control-Plane March 2018 > > > security of the LISP mapping protocol critically depends on the > strength of the nonce in the Map-Request message. The nonce > SHOULD be generated by a properly seeded pseudo-random (or strong > random) source. See [RFC4086] for advice on generating security- > sensitive random data. > > Source-EID-AFI: This is the address family of the 'Source EID > Address' field. > > Source EID Address: This is the EID of the source host that > originated the packet that caused the Map-Request. When Map- > Requests are used for refreshing a Map-Cache entry or for RLOC- > Probing, an AFI value 0 is used and this field is of zero length. > > ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' > field that follows this field. > > ITR-RLOC Address: This is used to give the ETR the option of > selecting the destination address from any address family for the > Map-Reply message. This address MUST be a routable RLOC address > of the sender of the Map-Request message. > > EID mask-len: This is the mask length for the EID-Prefix. > > EID-Prefix-AFI: This is the address family of the EID-Prefix > according to [AFI] and [RFC8060]. > > EID-Prefix: This prefix is 4 octets for an IPv4 address family and > 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 > or 2, respectively. For other AFIs [AFI], the length varies and > for the LCAF AFI the format is defined in [RFC8060]. When a Map- > Request is sent by an ITR because a data packet is received for a > destination where there is no mapping entry, the EID-Prefix is set > to the destination IP address of the data packet, and the 'EID > mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. > When an xTR wants to query a site about the status of a mapping it > already has cached, the EID-Prefix used in the Map-Request has the > same mask length as the EID-Prefix returned from the site when it > sent a Map-Reply message. > > Map-Reply Record: When the M-bit is set, this field is the size of a > single "Record" in the Map-Reply format. This Map-Reply record > contains the EID-to-RLOC mapping entry associated with the Source > EID. This allows the ETR that will receive this Map-Request to > cache the data if it chooses to do so. > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 12] > > Internet-Draft LISP Control-Plane March 2018 > > > 5.3. EID-to-RLOC UDP Map-Request Message > > A Map-Request is sent from an ITR when it needs a mapping for an EID, > wants to test an RLOC for reachability, or wants to refresh a mapping > before TTL expiration. For the initial case, the destination IP > address used for the Map-Request is the data packet's destination > address (i.e., the destination EID) that had a mapping cache lookup > failure. For the latter two cases, the destination IP address used > for the Map-Request is one of the RLOC addresses from the Locator-Set > of the Map-Cache entry. The source address is either an IPv4 or IPv6 > RLOC address, depending on whether the Map-Request is using an IPv4 > or IPv6 header, respectively. In all cases, the UDP source port > number for the Map-Request message is a 16-bit value selected by the > ITR/PITR, and the UDP destination port number is set to the well- > known destination port number 4342. A successful Map-Reply, which is > one that has a nonce that matches an outstanding Map-Request nonce, > will update the cached set of RLOCs associated with the EID-Prefix > range. > > One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') fields > MUST be filled in by the ITR. The number of fields (minus 1) encoded > MUST be placed in the 'IRC' field. The ITR MAY include all locally > configured Locators in this list or just provide one locator address > from each address family it supports. If the ITR erroneously > provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- > Request. > > Map-Requests can also be LISP encapsulated using UDP destination > port 4342 with a LISP Type value set to "Encapsulated Control > Message", when sent from an ITR to a Map-Resolver. Likewise, Map- > Requests are LISP encapsulated the same way from a Map-Server to an > ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be > found in Section 5.8. > > Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- > Request for the same EID-Prefix be sent no more than once per second. > > An ITR that is configured with mapping database information (i.e., it > is also an ETR) MAY optionally include those mappings in a Map- > Request. When an ETR configured to accept and verify such > "piggybacked" mapping data receives such a Map-Request and it does > not have this mapping in the map-cache, it MAY originate a "verifying > Map-Request", addressed to the map-requesting ITR and the ETR MAY add > a Map-Cache entry. If the ETR has a Map-Cache entry that matches the > "piggybacked" EID and the RLOC is in the Locator-Set for the entry, > then it MAY send the "verifying Map-Request" directly to the > originating Map-Request source. If the RLOC is not in the Locator- > Set, then the ETR MUST send the "verifying Map-Request" to the > > > > Fuller, et al. Expires September 5, 2018 [Page 13] > > Internet-Draft LISP Control-Plane March 2018 > > > "piggybacked" EID. Doing this forces the "verifying Map-Request" to > go through the mapping database system to reach the authoritative > source of information about that EID, guarding against RLOC-spoofing > in the "piggybacked" mapping data. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 14] > > Internet-Draft LISP Control-Plane March 2018 > > > 5.4. Map-Reply Message Format > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Type=2 |P|E|S| Reserved | Record Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Nonce . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | . . . Nonce | > +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Record TTL | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > R | Locator Count | EID mask-len | ACT |A| Reserved | > e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > c | Rsvd | Map-Version Number | EID-Prefix-AFI | > o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > r | EID-Prefix | > d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | /| Priority | Weight | M Priority | M Weight | > | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | o | Unused Flags |L|p|R| Loc-AFI | > | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | \| Locator | > +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Packet field descriptions: > > Type: 2 (Map-Reply) > > P: This is the probe-bit, which indicates that the Map-Reply is in > response to a Locator reachability probe Map-Request. The 'Nonce' > field MUST contain a copy of the nonce value from the original > Map-Request. See RLOC-probing [I-D.ietf-lisp-rfc6830bis] for more > details. Update reference to section 7. > > E: This bit indicates that the ETR that sends this Map-Reply message > is advertising that the site is enabled for the Echo-Nonce Locator > reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis] > for more details. > > S: This is the Security bit. When set to 1, the following > authentication information will be appended to the end of the Map- > Reply. The details of signing a Map-Reply message can be found in > [I-D.ietf-lisp-sec]. > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 15] > > Internet-Draft LISP Control-Plane 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AD Type | Authentication Data Content . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Reserved: This field MUST be set to 0 on transmit and MUST be > ignored on receipt. > > Record Count: This is the number of records in this reply message. > A record is comprised of that portion of the packet labeled > 'Record' above and occurs the number of times equal to Record > Count. > > Nonce: This is a 24-bit value set in a Data-Probe packet, “Data-Probe” has never been defined. A ref should be put to the document defining Data-Probe. > or a > 64-bit value from the Map-Request is echoed in this 'Nonce' field > of the Map-Reply. When a 24-bit value is supplied, it resides in > the low-order 64 bits of the 'Nonce' field. > > Record TTL: This is the time in minutes the recipient of the Map- > Reply will Should the above will be a SHOULD??? > store the mapping. If the TTL is 0, the entry SHOULD > be removed from the cache immediately. If the value is > 0xffffffff, the recipient can decide locally how long to store the > mapping. > > Locator Count: This is the number of Locator entries. A Locator > entry comprises what is labeled above as 'Loc'. The Locator count > can be 0, indicating that there are no Locators for the EID- > Prefix. > > EID mask-len: This is the mask length for the EID-Prefix. > > ACT: This 3-bit field describes Negative Map-Reply actions. In any > other message type, these bits are set to 0 and ignored on > receipt. These bits are used only when the 'Locator Count' field > is set to 0. The action bits are encoded only in Map-Reply > messages. The actions defined are used by an ITR or PITR when a > destination EID matches a negative Map-Cache entry. Unassigned > values SHOULD cause a Map-Cache entry to be created, and when > packets match this negative cache entry, they will be dropped. > The current assigned values are: > > > > (0) No-Action: The map-cache is kept alive, and no packet > encapsulation occurs. > > > > > > Fuller, et al. Expires September 5, 2018 [Page 16] > > Internet-Draft LISP Control-Plane March 2018 > > > (1) Natively-Forward: The packet is not encapsulated or dropped > but natively forwarded. > > (2) Send-Map-Request: The packet invokes sending a Map-Request. > > (3) Drop/No-Reason: A packet that matches this map-cache entry is > dropped. An ICMP Destination Unreachable message SHOULD be > sent. > > (4) Drop/Policy-Denied: A packet that matches this map-cache > entry is dropped. The reason for the Drop action is that a > Map-Request for the target-EID is being policy denied by > either an xTR or the mapping system. > > (5) Drop/Authentication-Failure: A packet that matches this map- > cache entry is dropped. The reason for the Drop action is > that a Map-Request for the target-EID fails an authentication > verification-check by either an xTR or the mapping system. > > A: The Authoritative bit, when sent, is always set to 1 by an ETR. > When a Map-Server is proxy Map-Replying for a LISP site, the > Authoritative bit is set to 0. This indicates to requesting ITRs > that the Map-Reply was not originated by a LISP node managed at > the site that owns the EID-Prefix. > > Map-Version Number: When this 12-bit value is non-zero, the Map- > Reply sender is informing the ITR what the version number is for > the EID record contained in the Map-Reply. The ETR can allocate > this number internally but MUST coordinate this value with other > ETRs for the site. When this value is 0, there is no versioning > information conveyed. The Map-Version Number can be included in > Map-Request and Map-Register messages. See Map-Versioning > [I-D.ietf-lisp-rfc6830bis] Add reference [RFC6834]. > for more details. > > EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] > and [RFC8060]. > > EID-Prefix: This prefix is 4 octets for an IPv4 address family and > 16 octets for an IPv6 address family. > > Priority: Each RLOC is assigned a unicast Priority. Lower values > are more preferable. When multiple RLOCs have the same Priority, > they MAY be used in a load-split fashion. A value of 255 means > the RLOC MUST NOT be used for unicast forwarding. > > Weight: When priorities are the same for multiple RLOCs, the Weight > indicates how to balance unicast traffic between them. Weight is > encoded as a relative weight of total unicast packets that match > > > > Fuller, et al. Expires September 5, 2018 [Page 17] > > Internet-Draft LISP Control-Plane March 2018 > > > the mapping entry. For example, if there are 4 Locators in a > Locator-Set, where the Weights assigned are 30, 20, 20, and 10, > the first Locator will get 37.5% of the traffic, the 2nd and 3rd > Locators will get 25% of the traffic, and the 4th Locator will get > 12.5% of the traffic. If all Weights for a Locator-Set are equal, > the receiver of the Map-Reply will decide how to load-split the > traffic. See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a > suggested hash algorithm to distribute the load across Locators > with the same Priority and equal Weight values. > > M Priority: Each RLOC is assigned a multicast Priority used by an > ETR in a receiver multicast site to select an ITR in a source > multicast site for building multicast distribution trees. A value > of 255 means the RLOC MUST NOT be used for joining a multicast > distribution tree. For more details, see [RFC6831]. > > M Weight: When priorities are the same for multiple RLOCs, the > Weight indicates how to balance building multicast distribution > trees across multiple ITRs. The Weight is encoded as a relative > weight (similar to the unicast Weights) of the total number of > trees built to the source site identified by the EID-Prefix. If > all Weights for a Locator-Set are equal, the receiver of the Map- > Reply will decide how to distribute multicast state across ITRs. > For more details, see [RFC6831]. > > Unused Flags: These are set to 0 when sending and ignored on > receipt. > > L: When this bit is set, the Locator is flagged as a local Locator to > the ETR that is sending the Map-Reply. When a Map-Server is doing > proxy Map-Replying for a LISP site, the L-bit is set to 0 for all > Locators in this Locator-Set. > > p: When this bit is set, an ETR informs the RLOC-Probing ITR that the > locator address for which this bit is set is the one being RLOC- > probed and MAY be different from the source address of the Map- > Reply. An ITR that RLOC-probes a particular Locator MUST use this > Locator for retrieving the data structure used to store the fact > that the Locator is reachable. The p-bit is set for a single > Locator in the same Locator-Set. If an implementation sets more > than one p-bit erroneously, the receiver of the Map-Reply MUST > select the first Locator. The p-bit MUST NOT be set for Locator- > Set records sent in Map-Request and Map-Register messages. > > R: This is set when the sender of a Map-Reply has a route to the > Locator in the Locator data record. This receiver MAY find this > useful to know if the Locator is up but not necessarily reachable > > > > > Fuller, et al. Expires September 5, 2018 [Page 18] > > Internet-Draft LISP Control-Plane March 2018 > > > from the receiver's point of view. See also EID-Reachability > [I-D.ietf-lisp-rfc6830bis] for another way the R-bit MAY be used. update reference to section 7. > > Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- > AFI' field) assigned to an ETR. Note that the destination RLOC > address MAY be an anycast address. A source RLOC can be an > anycast address as well. The source or destination RLOC MUST NOT > be the broadcast address (255.255.255.255 or any subnet broadcast > address known to the router) and MUST NOT be a link-local > multicast address. The source RLOC MUST NOT be a multicast > address. The destination RLOC SHOULD be a multicast address if it > is being mapped from a multicast destination EID. > > 5.5. EID-to-RLOC UDP Map-Reply Message > > A Map-Reply returns an EID-Prefix with a prefix length that is less > than or equal to the EID being requested. The EID being requested is > either from the destination field of an IP header of a Data-Probe or > the EID record of a Map-Request. The RLOCs in the Map-Reply are > routable IP addresses of all ETRs for the LISP site. Each RLOC > conveys status reachability but does not convey path reachability > from a requester's perspective. Separate testing of path > reachability is required. See RLOC-reachability > [I-D.ietf-lisp-rfc6830bis] for details. Update reference to Section 7. > > Note that a Map-Reply MAY contain different EID-Prefix granularity > (prefix + length) than the Map-Request that triggers it. This might > occur if a Map-Request were for a prefix that had been returned by an > earlier Map-Reply. In such a case, the requester updates its cache > with the new prefix information and granularity. For example, a > requester with two cached EID-Prefixes that are covered by a Map- > Reply containing one less-specific prefix replaces the entry with the > less-specific EID-Prefix. Note that the reverse, replacement of one > less-specific prefix with multiple more-specific prefixes, can also > occur, not by removing the less-specific prefix but rather by adding > the more-specific prefixes that, during a lookup, will override the > less-specific prefix. > > When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], > the database mapping system may have overlapping EID-prefixes. Or > when a LISP site is configured with multiple sets of ETRs that > support different EID-prefix lengths, the database mapping system may > have overlapping EID-prefixes. When overlapping EID-prefixes exist, > a Map-Request with an EID that best matches any EID-Prefix MUST be > returned in a single Map-Reply message. For instance, if an ETR had > database mapping entries for EID-Prefixes: > > > > > > Fuller, et al. Expires September 5, 2018 [Page 19] > > Internet-Draft LISP Control-Plane March 2018 > > > 10.0.0.0/8 > 10.1.0.0/16 > 10.1.1.0/24 > 10.1.2.0/24 > > A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record > count of 1 to be returned with a mapping record EID-Prefix of > 10.1.1.0/24. > > A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record > count of 3 to be returned with mapping records for EID-Prefixes > 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. > > Note that not all overlapping EID-Prefixes need to be returned but > only the more-specific entries (note that in the second example above > 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) for the > matching EID-Prefix of the requesting EID. When more than one EID- > Prefix is returned, all SHOULD use the same Time to Live value so > they can all time out at the same time. When a more-specific EID- > Prefix is received later, its Time to Live value in the Map-Reply > record can be stored even when other less-specific entries exist. > When a less-specific EID-Prefix is received later, its map-cache > expiration time SHOULD be set to the minimum expiration time of any > more-specific EID-Prefix in the map-cache. This is done so the > integrity of the EID-Prefix set is wholly maintained and so no more- > specific entries are removed from the map-cache while keeping less- > specific entries. > > Map-Replies SHOULD be sent for an EID-Prefix no more often than once > per second to the same requesting router. For scalability, it is > expected that aggregation of EID addresses into EID-Prefixes will > allow one Map-Reply to satisfy a mapping for the EID addresses in the > prefix range, thereby reducing the number of Map-Request messages. > > Map-Reply records can have an empty Locator-Set. A Negative Map- > Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies > convey special actions by the sender to the ITR or PITR that have > solicited the Map-Reply. There are two primary applications for > Negative Map-Replies. The first is for a Map-Resolver to instruct an > ITR or PITR when a destination is for a LISP site versus a non-LISP > site, and the other is to source quench Map-Requests that are sent > for non-allocated EIDs. > > For each Map-Reply record, the list of Locators in a Locator-Set MUST > appear in the same order for each ETR that originates a Map-Reply > message. The Locator-Set MUST be sorted in order of ascending IP > address where an IPv4 locator address is considered numerically 'less > than' an IPv6 locator address. > > > > Fuller, et al. Expires September 5, 2018 [Page 20] > > Internet-Draft LISP Control-Plane March 2018 > > > When sending a Map-Reply message, the destination address is copied > from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can > choose a locator address from one of the address families it > supports. For Data-Probes, the destination address of the Map-Reply > is copied from the source address of the Data-Probe message that is > invoking the reply. The source address of the Map-Reply is one of > the local IP addresses chosen to allow Unicast Reverse Path > Forwarding (uRPF) checks to succeed in the upstream service provider. > The destination port of a Map-Reply message is copied from the source > port of the Map-Request or Data-Probe, and the source port of the > Map-Reply message is set to the well-known UDP port 4342. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 21] > > Internet-Draft LISP Control-Plane March 2018 > > > 5.6. Map-Register Message Format > > This section specifies the encoding format for the Map-Register > message. The message is sent in UDP with a destination UDP port of > 4342 and a randomly selected UDP source port number. > > The Map-Register message format is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Type=3 |P|S|I| Reserved |E|T|a|m|M| Record Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Nonce . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | . . . Nonce | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key ID | Algorithm ID | Authentication Data Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Authentication Data ~ > +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Record TTL | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > R | Locator Count | EID mask-len | ACT |A| Reserved | > e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > c | Rsvd | Map-Version Number | EID-Prefix-AFI | > o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > r | EID-Prefix | > d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | /| Priority | Weight | M Priority | M Weight | > | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | o | Unused Flags |L|p|R| Loc-AFI | > | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | \| Locator | > +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Packet field descriptions: > > Type: 3 (Map-Register) > > P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a > Map-Register message requesting the Map-Server to proxy a Map- > Reply. The Map-Server will send non-authoritative Map-Replies on > behalf of the ETR. > > S: This is the security-capable bit. When set, the procedures from > [I-D.ietf-lisp-sec] are supported. > > > > > Fuller, et al. Expires September 5, 2018 [Page 22] > > Internet-Draft LISP Control-Plane March 2018 > > > I: This is the xTR-ID bit. When this bit is set, what is appended to > the Map-Register is a 128-bit xTR router-ID and then a 64-bit > site-ID. See LISP NAT-Traversal procedures in > [I-D.ermagan-lisp-nat-traversal] for details. > > Reserved: This field MUST be set to 0 on transmit and MUST be > ignored on receipt. > > E: This is the Map-Register EID-notify bit. This is used by a First- > Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify > based Map-Register is sent by the FHR to the same site xTR that > propogates the Map-Register to the mapping system. The site xTR > keeps state to later Map-Notify the FHR after the EID has moves > away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case. > > T: This is the use-TTL for timeout bit. When set to 1, the xTR wants > the Map-Server to time out registrations based on the value in the > "Record TTL" field of this message. > > a: This is the merge-request bit. When set to 1, the xTR requests to > merge RLOC-records from different xTRs registering the same EID- > record. See signal-free multicast > [I-D.ietf-lisp-signal-free-multicast] for one use case example. > > m: This is the mobile-node bit. When set to 1, the registering xTR > supports the procedures in [I-D.ietf-lisp-mn]. > > M: This is the want-map-notify bit. When set to 1, an ETR is > requesting a Map-Notify message to be returned in response to > sending a Map-Register message. The Map-Notify message sent by a > Map-Server is used to acknowledge receipt of a Map-Register > message. > > Record Count: This is the number of records in this Map-Register > message. A record is comprised of that portion of the packet > labeled 'Record' above and occurs the number of times equal to > Record Count. > > Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register > messages if no Map-Notify message is expected to acknowledge it. > Since the Map-Register message is authenticated, the 'Nonce' field > is not currently used for any security function but MAY be in the > future as part of an anti-replay solution. > > Key ID: This is a configured key-id value that corresponds to a > shared-secret password that is used to authenticate the sender. > Multiple shared-secrets can be used to roll over keys in a non- > disruptive way. > > > > Fuller, et al. Expires September 5, 2018 [Page 23] > > Internet-Draft LISP Control-Plane March 2018 > > > Algorithm ID: This is the configured Message Authentication Code > (MAC) algorithm value used for the authentication function. See > Algorithm ID Numbers in the Section 10.4 for codepoint Is section 10.5 NOT 10.4. > assignments. > > Authentication Data Length: This is the length in octets of the > 'Authentication Data' field that follows this field. The length > of the 'Authentication Data' field is dependent on the MAC > algorithm used. The length field allows a device that doesn't > know the MAC algorithm to correctly parse the packet. > > Authentication Data: This is the message digest used from the output > of the MAC algorithm. The entire Map-Register payload is > authenticated with this field preset to 0. After the MAC is > computed, it is placed in this field. Implementations of this > specification MUST include support for HMAC-SHA-1-96 [RFC2404], > and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. > > The definition of the rest of the Map-Register can be found in > Section 5.4. I would rephrase it as: The definition of the rest of the Map-Register, namely the record, can be found in Section 5.4. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 24] > > Internet-Draft LISP Control-Plane March 2018 > > > 5.7. Map-Notify/Map-Notify-Ack Message Format > > This section specifies the encoding format for the Map-Notify and > Map-Notify-Ack messages. The messages are sent inside a UDP packet > with source and destination UDP ports equal to 4342. > > The Map-Notify and Map-Notify-Ack message formats are: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Type=4/5| Reserved | Record Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Nonce . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | . . . Nonce | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key ID | Algorithm ID | Authentication Data Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Authentication Data ~ > +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Record TTL | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > R | Locator Count | EID mask-len | ACT |A| Reserved | > e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > c | Rsvd | Map-Version Number | EID-Prefix-AFI | > o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > r | EID-Prefix | > d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | /| Priority | Weight | M Priority | M Weight | > | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | o | Unused Flags |L|p|R| Loc-AFI | > | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | \| Locator | > +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Packet field descriptions: > > Type: 4/5 (Map-Notify/Map-Notify-Ack) > > The Map-Notify message has the same contents as a Map-Register > message. See the Map-Register section for field descriptions. > > The Map-Notify-Ack message has the same contents as a Map-Notify > message. It is used to acknowledge the receipt of a Map-Notify and > for the sender to stop retransmitting a Map-Notify with the same > nonce. > > > > > Fuller, et al. Expires September 5, 2018 [Page 25] > > Internet-Draft LISP Control-Plane March 2018 > > > 5.8. Encapsulated Control Message Format > > An Encapsulated Control Message (ECM) is used to encapsulate control > packets sent between xTRs and the mapping database system. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | IPv4 or IPv6 Header | > OH | (uses RLOC addresses) | > \ | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | Source Port = xxxx | Dest Port = 4342 | > UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ | UDP Length | UDP Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > LH |Type=8 |S|D|E|M| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | IPv4 or IPv6 Header | > IH | (uses RLOC or EID addresses) | > \ | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / | Source Port = xxxx | Dest Port = yyyy | > UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > \ | UDP Length | UDP Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > LCM | LISP Control Message | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Packet header descriptions: > > OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the > source and destination header address fields. > > UDP: The outer UDP header with destination port 4342. The source > port is randomly allocated. The checksum field MUST be non- > zero. > > LH: Type 8 is defined to be a "LISP Encapsulated Control Message", > and what follows is either an IPv4 or IPv6 header as encoded by > the first 4 bits after the 'Reserved' field. > > Type: 8 (Encapsulated Control Message (ECM)) > > S: This is the Security bit. When set to 1, the procedures from > [I-D.ietf-lisp-sec] are followed. > > > > > > Fuller, et al. Expires September 5, 2018 [Page 26] > > Internet-Draft LISP Control-Plane March 2018 > > > D: This is the DDT-bit. When set to 1, the sender is requesting a > Map-Referral message to be returned. The details of this > procedure are described in [RFC8111]. > > E: This is the to-ETR bit. When set to 1, the Map-Server's > intention is to forward the ECM to an authoritative ETR. > > M: This is the to-MS bit. When set to 1, a Map-Request is being > sent to a co-located Map-Resolver and Map-Server where the > message can be processed directly by the Map-Server versus the > Map-Resolver using the LISP-DDT procedures in [RFC8111]. > The following should be after the S bit not after the M bit. > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AD Type | Authentication Data Content . . . | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID > addresses in the header address fields. When a Map-Request is > encapsulated in this packet format, the destination address in > this header is an EID. > > UDP: The inner UDP header, where the port assignments depend on the > control packet being encapsulated. When the control packet is > a Map-Request or Map-Register, the source port is selected by > the ITR/PITR and the destination port is 4342. When the > control packet is a Map-Reply, the source port is 4342 and the > destination port is assigned from the source port of the > invoking Map-Request. Port number 4341 MUST NOT be assigned to > either port. The checksum field MUST be non-zero. > > LCM: The format is one of the control message formats described in > this section. At this time, only Map-Request messages are > allowed to be control-plane (ECM) encapsulated. In the future, > PIM Join/Prune messages [RFC6831] might be allowed. > Encapsulating other types of LISP control messages is for > further study. When Map-Requests are sent for RLOC-Probing > purposes (i.e., the probe-bit is set), they MUST NOT be sent > inside Encapsulated Control Messages. > > > > > > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 27] > > Internet-Draft LISP Control-Plane March 2018 > > > 6. Changing the Contents of EID-to-RLOC Mappings > > In the LISP architecture ITRs/PITRs use a local map-cache to store > EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a > mechanism is required to inform ITRs/PITRs that are using such > mappings. > > The LISP data-plane defines several mechanism to update mappings > [I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map > Request (SMR), a control-plane push-based mechanism. An additional > control-plane mechanism based on the Publish/subscribe paradigm is > specified in [I-D.rodrigueznatal-lisp-pubsub]. > > 6.1. Solicit-Map-Request (SMR) > > Soliciting a Map-Request is a selective way for ETRs, at the site > where mappings change, to control the rate they receive requests for > Map-Reply messages. SMRs are also used to tell remote ITRs to update > the mappings they have cached. > > Since the ETRs don't keep track of remote ITRs that have cached their > mappings, they do not know which ITRs need to have their mappings > updated. As a result, an ETR will solicit Map-Requests (called an > SMR message) from those sites to which it has been sending > encapsulated data for the last minute. In particular, an ETR will > send an SMR to an ITR to which it has recently sent encapsulated > data. This can only occur when both ITR and ETR functionality reside > in the same router. > > An SMR message is simply a bit set in a Map-Request message. An ITR > or PITR will send a Map-Request when they receive an SMR message. > Both the SMR sender and the Map-Request responder MUST rate-limit > these messages. Rate-limiting can be implemented as a global rate- > limiter or one rate-limiter per SMR destination. > > The following procedure shows how an SMR exchange occurs when a site > is doing Locator-Set compaction for an EID-to-RLOC mapping: > > 1. When the database mappings in an ETR change, the ETRs at the site > begin to send Map-Requests with the SMR bit set for each Locator > in each Map-Cache entry the ETR caches. > > 2. A remote ITR that receives the SMR message will schedule sending > a Map-Request message to the source locator address of the SMR > message or to the mapping database system. A newly allocated > random nonce is selected, and the EID-Prefix used is the one > copied from the SMR message. If the source Locator is the only > Locator in the cached Locator-Set, the remote ITR SHOULD send a > > > > Fuller, et al. Expires September 5, 2018 [Page 28] > > Internet-Draft LISP Control-Plane March 2018 > > > Map-Request to the database mapping system just in case the > single Locator has changed and may no longer be reachable to > accept the Map-Request. > > 3. The remote ITR MUST rate-limit the Map-Request until it gets a > Map-Reply while continuing to use the cached mapping. When > Map-Versioning as described in [I-D.ietf-lisp-rfc6830bis] replace the reference with [RFC6834]. > is > used, an SMR sender can detect if an ITR is using the most up-to- > date database mapping. > > 4. The ETRs at the site with the changed mapping will reply to the > Map-Request with a Map-Reply message that has a nonce from the > SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- > limited. This is important to avoid Map-Reply implosion. > > 5. The ETRs at the site with the changed mapping record the fact > that the site that sent the Map-Request has received the new > mapping data in the Map-Cache entry for the remote site so the > Locator-Status-Bits are reflective of the new mapping for packets > going to the remote site. The ETR then stops sending SMR > messages. > > For security reasons, an ITR MUST NOT process unsolicited Map- > Replies. To avoid Map-Cache entry corruption by a third party, a > sender of an SMR-based Map-Request MUST be verified. If an ITR > receives an SMR-based Map-Request and the source is not in the > Locator-Set for the stored Map-Cache entry, then the responding Map- > Request MUST be sent with an EID destination to the mapping database > system. Since the mapping database system is a more secure way to > reach an authoritative ETR, it will deliver the Map-Request to the > authoritative source of the mapping data. > > When an ITR receives an SMR-based Map-Request for which it does not > have a cached mapping for the EID in the SMR message, it may not send > an SMR-invoked Map-Request. This scenario can occur when an ETR > sends SMR messages to all Locators in the Locator-Set it has stored > in its map-cache but the remote ITRs that receive the SMR may not be > sending packets to the site. There is no point in updating the ITRs > until they need to send, in which case they will send Map-Requests to > obtain a Map-Cache entry. > > 7. Routing Locator Reachability > > This document defines several control-plane mechanisms for > determining RLOC reachability. Please note that additional data- > plane reachability mechanisms are defined in > [I-D.ietf-lisp-rfc6830bis]. > > > > > Fuller, et al. Expires September 5, 2018 [Page 29] > > Internet-Draft LISP Control-Plane March 2018 > > > 1. An ITR MAY receive an ICMP Network Unreachable or Host > Unreachable message for an RLOC it is using. This indicates that > the RLOC is likely down. Note that trusting ICMP messages may > not be desirable, but neither is ignoring them completely. > Implementations are encouraged to follow current best practices > in treating these conditions [I-D.ietf-opsec-icmp-filtering]. > > 2. When an ITR participates in the routing protocol that operates in > the underlay routing system, it can determine that an RLOC is > down when no Routing Information Base (RIB) entry exists that > matches the RLOC IP address. > > 3. An ITR MAY receive an ICMP Port Unreachable message from a > destination host. This occurs if an ITR attempts to use > interworking [RFC6832] and LISP-encapsulated data is sent to a > non-LISP-capable site. > > 4. An ITR MAY receive a Map-Reply from an ETR in response to a > previously sent Map-Request. The RLOC source of the Map-Reply is > likely up, since the ETR was able to send the Map-Reply to the > ITR. > > 5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described > below. > > When ITRs receive ICMP Network Unreachable or Host Unreachable > messages as a method to determine unreachability, they will refrain > from using Locators that are described in Locator lists of Map- > Replies. However, using this approach is unreliable because many > network operators turn off generation of ICMP Destination Unreachable > messages. > > If an ITR does receive an ICMP Network Unreachable or Host > Unreachable message, it MAY originate its own ICMP Destination > Unreachable message destined for the host that originated the data > packet the ITR encapsulated. > > Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a > locator address from a Locator-Set in a mapping entry matches a > prefix. If it does not find one and BGP is running in the Default- > Free Zone (DFZ), it can decide to not use the Locator even though the > Locator-Status-Bits indicate that the Locator is up. In this case, > the path from the ITR to the ETR that is assigned the Locator is not > available. More details are in [I-D.meyer-loc-id-implications]. > > Optionally, an ITR can send a Map-Request to a Locator, and if a Map- > Reply is returned, reachability of the Locator has been determined. > Obviously, sending such probes increases the number of control > > > > Fuller, et al. Expires September 5, 2018 [Page 30] > > Internet-Draft LISP Control-Plane March 2018 > > > messages originated by Tunnel Routers for active flows, so Locators > are assumed to be reachable when they are advertised. > > This assumption does create a dependency: Locator unreachability is > detected by the receipt of ICMP Host Unreachable messages. When a > Locator has been determined to be unreachable, it is not used for > active traffic; this is the same as if it were listed in a Map-Reply > with Priority 255. > > The ITR can test the reachability of the unreachable Locator by > sending periodic Requests. Both Requests and Replies MUST be rate- > limited. Locator reachability testing is never done with data > packets, since that increases the risk of packet loss for end-to-end > sessions. > > 7.1. RLOC-Probing Algorithm > > RLOC-Probing is a method that an ITR or PITR can use to determine the > reachability status of one or more Locators that it has cached in a > Map-Cache entry. The probe-bit of the Map-Request and Map-Reply > messages is used for RLOC-Probing. > > RLOC-Probing is done in the control plane on a timer basis, where an > ITR or PITR will originate a Map-Request destined to a locator > address from one of its own locator addresses. A Map-Request used as > an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to > the mapping database system as one would when soliciting mapping > data. The EID record encoded in the Map-Request is the EID-Prefix of > the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a > mapping data record for its own database mapping information that > contains the local EID-Prefixes and RLOCs for its site. RLOC-probes > are sent periodically using a jittered timer interval. > > When an ETR receives a Map-Request message with the probe-bit set, it > returns a Map-Reply with the probe-bit set. The source address of > the Map-Reply is set according to the procedure described in > [I-D.ietf-lisp-rfc6830bis]. The Map-Reply SHOULD contain mapping > data for the EID-Prefix contained in the Map-Request. This provides > the opportunity for the ITR or PITR that sent the RLOC-probe to get > mapping updates if there were changes to the ETR's database mapping > entries. > > There are advantages and disadvantages of RLOC-Probing. The greatest > benefit of RLOC-Probing is that it can handle many failure scenarios > allowing the ITR to determine when the path to a specific Locator is > reachable or has become unreachable, thus providing a robust > mechanism for switching to using another Locator from the cached > Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) > > > > Fuller, et al. Expires September 5, 2018 [Page 31] > > Internet-Draft LISP Control-Plane March 2018 > > > estimates between a pair of Locators, which can be useful for network > management purposes as well as for selecting low delay paths. The > major disadvantage of RLOC-Probing is in the number of control > messages required and the amount of bandwidth used to obtain those > benefits, especially if the requirement for failure detection times > is very small. > > 8. Interactions with Other LISP Components > > 8.1. ITR EID-to-RLOC Mapping Resolution > > An ITR is configured with one or more Map-Resolver addresses. These > addresses are "Locators" (or RLOCs) and MUST be routable on the > underlying core network; they MUST NOT need to be resolved through > LISP EID-to-RLOC mapping, as that would introduce a circular > dependency. When using a Map-Resolver, an ITR does not need to > connect to any other database mapping system. In particular, the ITR > need not connect to the LISP+ALT infrastructure or implement the BGP > and GRE protocols that it uses. > > An ITR sends an Encapsulated Map-Request to a configured Map-Resolver > when it needs an EID-to-RLOC mapping that is not found in its local > map-cache. Using the Map-Resolver greatly reduces both the > complexity of the ITR implementation and the costs associated with > its operation. > > In response to an Encapsulated Map-Request, the ITR can expect one of > the following: > > o An immediate Negative Map-Reply (with action code of "Natively- > Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if > the Map-Resolver can determine that the requested EID does not > exist. The ITR saves the EID-Prefix returned in the Map-Reply in > its cache, marks it as non-LISP-capable, and knows not to attempt > LISP encapsulation for destinations matching it. > > o A Negative Map-Reply, with action code of "Natively-Forward", from > a Map-Server that is authoritative for an EID-Prefix that matches > the requested EID but that does not have an actively registered, > more-specific ID-prefix. In this case, the requested EID is said > to match a "hole" in the authoritative EID-Prefix. If the > requested EID matches a more-specific EID-Prefix that has been > delegated by the Map-Server but for which no ETRs are currently > registered, a 1-minute TTL is returned. If the requested EID > matches a non-delegated part of the authoritative EID-Prefix, then > it is not a LISP EID and a 15-minute TTL is returned. See > Section 8.2 for discussion of aggregate EID-Prefixes and details > of Map-Server EID-Prefix matching. > > > > Fuller, et al. Expires September 5, 2018 [Page 32] > > Internet-Draft LISP Control-Plane March 2018 > > > o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or > possibly from a Map-Server answering on behalf of the ETR. See > Section 8.4 for more details on Map-Resolver message processing. > > Note that an ITR MAY be configured to both use a Map-Resolver and to > participate in a LISP+ALT logical network. In such a situation, the > ITR SHOULD send Map-Requests through the ALT network for any EID- > Prefix learned via ALT BGP. Such a configuration is expected to be > very rare, since there is little benefit to using a Map-Resolver if > an ITR is already using LISP+ALT. There would be, for example, no > need for such an ITR to send a Map-Request to a possibly non-existent > EID (and rely on Negative Map-Replies) if it can consult the ALT > database to verify that an EID-Prefix is present before sending that > Map-Request. > > 8.2. EID-Prefix Configuration and ETR Registration > > An ETR publishes its EID-Prefixes on a Map-Server by sending LISP > Map-Register messages. A Map-Register message includes > authentication data, so prior to sending a Map-Register message, the > ETR and Map-Server SHOULD be configured with a shared secret or other > relevant authentication information. A Map-Server's configuration > SHOULD also include a list of the EID-Prefixes for which each ETR is > authoritative. Upon receipt of a Map-Register from an ETR, a Map- > Server accepts only EID-Prefixes that are configured for that ETR. > Failure to implement such a check would leave the mapping system > vulnerable to trivial EID-Prefix hijacking attacks. As developers > and operators gain experience with the mapping system, additional, > stronger security measures MAY be added to the registration process. > > In addition to the set of EID-Prefixes defined for each ETR that MAY > register, a Map-Server is typically also configured with one or more > aggregate prefixes that define the part of the EID numbering space > assigned to it. When LISP+ALT is the database in use, aggregate EID- > Prefixes are implemented as discard routes and advertised into ALT > BGP. The existence of aggregate EID-Prefixes in a Map-Server's > database means that it MAY receive Map Requests for EID-Prefixes that > match an aggregate but do not match a registered prefix; Section 8.3 > describes how this is handled. > > Map-Register messages are sent periodically from an ETR to a Map- > Server with a suggested interval between messages of one minute. A > Map-Server SHOULD time out and remove an ETR's registration if it has > not received a valid Map-Register message within the past > three minutes. When first contacting a Map-Server after restart or > changes to its EID-to-RLOC database mappings, an ETR MAY initially > send Map-Register messages at an increased frequency, up to one every > > > > > Fuller, et al. Expires September 5, 2018 [Page 33] > > Internet-Draft LISP Control-Plane March 2018 > > > 20 seconds. This "quick registration" period is limited to > five minutes in duration. > > An ETR MAY request that a Map-Server explicitly acknowledge receipt > and processing of a Map-Register message by setting the "want-map- > notify" (M-bit) flag. A Map-Server that receives a Map-Register with > this flag set will respond with a Map-Notify message. Typical use of > this flag by an ETR would be to set it for Map-Register messages sent > during the initial "quick registration" with a Map-Server but then > set it only occasionally during steady-state maintenance of its > association with that Map-Server. Note that the Map-Notify message > is sent to UDP destination port 4342, not to the source port > specified in the original Map-Register message. > > Note that a one-minute minimum registration interval during > maintenance of an ETR-Map-Server association places a lower bound on > how quickly and how frequently a mapping database entry can be > updated. This MAY have implications for what sorts of mobility can > be supported directly by the mapping system; shorter registration > intervals or other mechanisms might be needed to support faster > mobility in some cases. For a discussion on one way that faster > mobility MAY be implemented for individual devices, please see > [I-D.ietf-lisp-mn]. > > An ETR MAY also request, by setting the "proxy Map-Reply" flag > (P-bit) in the Map-Register message, that a Map-Server answer Map- > Requests instead of forwarding them to the ETR. See > [I-D.ietf-lisp-rfc6830bis] Replace reference with Section 5.4. > for details on how the Map-Server sets > certain flags (such as those indicating whether the message is > authoritative and how returned Locators SHOULD be treated) when > sending a Map-Reply on behalf of an ETR. When an ETR requests proxy > reply service, it SHOULD include all RLOCs for all ETRs for the EID- > Prefix being registered, along with the routable flag ("R-bit") > setting for each RLOC. The Map-Server includes all of this > information in Map-Reply messages that it sends on behalf of the ETR. > This differs from a non-proxy registration, since the latter need > only provide one or more RLOCs for a Map-Server to use for forwarding > Map-Requests; the registration information is not used in Map- > Replies, so it being incomplete is not incorrect. > > An ETR that uses a Map-Server to publish its EID-to-RLOC mappings > does not need to participate further in the mapping database > protocol(s). When using a LISP+ALT mapping database, for example, > this means that the ETR does not need to implement GRE or BGP, which > greatly simplifies its configuration and reduces its cost of > operation. > > > > > > Fuller, et al. Expires September 5, 2018 [Page 34] > > Internet-Draft LISP Control-Plane March 2018 > > > Note that use of a Map-Server does not preclude an ETR from also > connecting to the mapping database (i.e., it could also connect to > the LISP+ALT network), but doing so doesn't seem particularly useful, > as the whole purpose of using a Map-Server is to avoid the complexity > of the mapping database protocols. > > 8.3. Map-Server Processing > > Once a Map-Server has EID-Prefixes registered by its client ETRs, it > can accept and process Map-Requests for them. > > In response to a Map-Request (received over the ALT if LISP+ALT is in > use), the Map-Server first checks to see if the destination EID > matches a configured EID-Prefix. If there is no match, the Map- > Server returns a Negative Map-Reply with action code "Natively- > Forward" and a 15-minute TTL. This MAY occur if a Map Request is > received for a configured aggregate EID-Prefix for which no more- > specific EID-Prefix exists; it indicates the presence of a non-LISP > "hole" in the aggregate EID-Prefix. > > Next, the Map-Server checks to see if any ETRs have registered the > matching EID-Prefix. If none are found, then the Map-Server returns > a Negative Map-Reply with action code "Natively-Forward" and a > 1-minute TTL. > > If any of the registered ETRs for the EID-Prefix have requested proxy > reply service, then the Map-Server answers the request instead of > forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, > and other information learned through the registration process. > > If none of the ETRs have requested proxy reply service, then the Map- > Server re-encapsulates and forwards the resulting Encapsulated Map- > Request to one of the registered ETRs. It does not otherwise alter > the Map-Request, so any Map-Reply sent by the ETR is returned to the > RLOC in the Map-Request, not to the Map-Server. Unless also acting > as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; any > such messages SHOULD be discarded without response, perhaps > accompanied by the logging of a diagnostic message if the rate of > Map-Replies is suggestive of malicious traffic. > > 8.4. Map-Resolver Processing > > Upon receipt of an Encapsulated Map-Request, a Map-Resolver > decapsulates the enclosed message and then searches for the requested > EID in its local database of mapping entries (statically configured > or learned from associated ETRs if the Map-Resolver is also a Map- > Server offering proxy reply service). If it finds a matching entry, > it returns a LISP Map-Reply with the known mapping. > > > > Fuller, et al. Expires September 5, 2018 [Page 35] > > Internet-Draft LISP Control-Plane March 2018 > > > If the Map-Resolver does not have the mapping entry and if it can > determine that the EID is not in the mapping database (for example, > if LISP+ALT is used, the Map-Resolver will have an ALT forwarding > table that covers the full EID space), it immediately returns a > negative LISP Map-Reply, with action code "Natively-Forward" and a > 15-minute TTL. To minimize the number of negative cache entries > needed by an ITR, the Map-Resolver SHOULD return the least-specific > prefix that both matches the original query and does not match any > EID-Prefix known to exist in the LISP-capable infrastructure. > > If the Map-Resolver does not have sufficient information to know > whether the EID exists, it needs to forward the Map-Request to > another device that has more information about the EID being > requested. To do this, it forwards the unencapsulated Map-Request, > with the original ITR RLOC as the source, to the mapping database > system. Using LISP+ALT, the Map-Resolver is connected to the ALT > network and sends the Map-Request to the next ALT hop learned from > its ALT BGP neighbors. The Map-Resolver does not send any response > to the ITR; since the source RLOC is that of the ITR, the ETR or Map- > Server that receives the Map-Request over the ALT and responds will > do so directly to the ITR. > > 8.4.1. Anycast Map-Resolver Operation > > A Map-Resolver can be set up to use "anycast", where the same address > is assigned to multiple Map-Resolvers and is propagated through IGP > routing, to facilitate the use of a topologically close Map-Resolver > by each ITR. > > Note that Map-Server associations with ETRs SHOULD NOT use anycast > addresses, as registrations need to be established between an ETR and > a specific set of Map-Servers, each identified by a specific > registration association. > > 9. Security Considerations > > The 2-way LISP header nonce exchange documented in > [I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing attacks. > > To publish an authoritative EID-to-RLOC mapping with a Map-Server, an > ETR includes authentication data that is a hash of the message using > a pair-wise shared key. An implementation MUST support use of HMAC- > SHA-1-96 [RFC2104] and SHOULD support use of HMAC-SHA-256-128 > [RFC6234] (SHA-256 truncated to 128 bits). > > As noted in Section 8.2, a Map-Server SHOULD verify that all EID- > Prefixes registered by an ETR match the configuration stored on the > Map-Server. > > > > Fuller, et al. Expires September 5, 2018 [Page 36] > > Internet-Draft LISP Control-Plane March 2018 > > > The currently defined authentication mechanism for Map-Register > messages does not provide protection against "replay" attacks by a > "man-in-the-middle". Additional work is needed in this area. > > [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin > authentication, integrity, anti-replay protection, and prevention of > man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- > Reply exchange. Work is ongoing on this and other proposals for > resolving these open security issues. > > While beyond the scope of securing an individual Map-Server or Map- > Resolver, it SHOULD be noted that a BGP-based LISP+ALT network (if > ALT is used as the mapping database infrastructure) can take > advantage of standards work on adding security to BGP. > > A complete LISP threat analysis has been published in [RFC7835]. > Please refer to it for more security related details. > > 10. IANA Considerations > > This section provides guidance to the Internet Assigned Numbers > Authority (IANA) regarding registration of values related to this > LISP control-plane specification, in accordance with BCP 26 > [RFC8126]. > > There are three namespaces (listed in the sub-sections below) in LISP > that have been registered. > > o LISP IANA registry allocations SHOULD NOT be made for purposes > unrelated to LISP routing or transport protocols. > > o The following policies are used here with the meanings defined in > BCP 26: "Specification Required", "IETF Review", "Experimental > Use", and "First Come First Served". > > 10.1. LISP UDP Port Numbers > > The IANA registry has allocated UDP port number 4342 for the LISP > control-plane. IANA has updated the description for UDP port 4342 as > follows: > > lisp-control 4342 udp LISP Control Packets > > 10.2. LISP Packet Type Codes > > It is being requested that the IANA be authoritative for LISP Packet > Type definitions and that it refers to this document as well as > [RFC8113] as references. > > > > Fuller, et al. Expires September 5, 2018 [Page 37] > > Internet-Draft LISP Control-Plane March 2018 > > > Based on deployment experience of [RFC6830], the Map-Notify-Ack > message, message type 5, was added to this document. This document > requests IANA to add it to the LISP Packet Type Registry. Please add the following table for clarity: Message Code Reference ================================= ==== =============== LISP Map-Notify-Ack 5 [This Document] > > 10.3. LISP ACT and Flag Fields > > New ACT values can be allocated through IETF review or IESG approval. > Four values have already been allocated by [RFC6830]. This > specification changes the name of ACT type 3 value from "Drop" to > "Drop/No-Reason" as well as adding two new ACT values, the "Drop/ > Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). Please add the following table for clarity: Value Action Description Reference ====== =========================== ====================================== =============== 4 Drop/Policy-Denied A Packet matching this map-cache entry is dropped because the target EID is [This Document] policy-denied by the xTR or the mapping system. 5 Drop/Authentication-Failure A Packet matching this map-cache entry is dropped because the Map-Request for target EID fails an authentication check [This Document] by the xTR or the mapping system. > > In addition, LISP has a number of flag fields and reserved fields, > such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New > bits for flags in these fields can be implemented after IETF review > or IESG approval, but these need not be managed by IANA. > > 10.4. LISP Address Type Codes > > LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that > defines LISP-specific encodings for AFI value 16387. LCAF encodings > are used for specific use-cases where different address types for > EID-records and RLOC-records are required. > > The IANA registry "LISP Canonical Address Format (LCAF) Types" is > used for LCAF types, the registry for LCAF types use the > Specification Required policy [RFC8126]. Initial values for the > registry as well as further information can be found in [RFC8060]. > > Therefore, there is no longer a need for the "LISP Address Type > Codes" registry requested by [RFC6830]. This document requests to > remove it. > > 10.5. LISP Algorithm ID Numbers > > In [RFC6830], a request for a "LISP Key ID Numbers" registry was > submitted. This document renames the registry to "LISP Algorithm ID > Numbers" and requests the IANA to make the name change. > > The following Algorithm ID values are defined by this specification > as used in any packet type that references a 'Algorithm ID' field: > > Name Number Defined in > ----------------------------------------------- > None 0 n/a Not sure what you mean with “n/a”?? Never been defined? Can be defined here? > HMAC-SHA-1-96 1 [RFC2404] > HMAC-SHA-256-128 2 [RFC4868] > > > > > Fuller, et al. Expires September 5, 2018 [Page 38] > > Internet-Draft LISP Control-Plane March 2018 > > > Number values are in the range of 0 to 255. The allocation of values > is on a first come first served basis. > > 11. References > > 11.1. Normative References > > [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within > ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November > 1998, <https://www.rfc-editor.org/info/rfc2404>. > > [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, > "Randomness Requirements for Security", BCP 106, RFC 4086, > DOI 10.17487/RFC4086, June 2005, > <https://www.rfc-editor.org/info/rfc4086>. > > [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- > 384, and HMAC-SHA-512 with IPsec", RFC 4868, > DOI 10.17487/RFC4868, May 2007, > <https://www.rfc-editor.org/info/rfc4868>. > > [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 > Locator/ID Separation Protocol (LISP) for Multicast > Environments", RFC 6831, DOI 10.17487/RFC6831, January > 2013, <https://www.rfc-editor.org/info/rfc6831>. > > [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>. > > [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to > Routing Locator (RLOC) Database", RFC 6837, > DOI 10.17487/RFC6837, January 2013, > <https://www.rfc-editor.org/info/rfc6837>. > > [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>. > > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 39] > > Internet-Draft LISP Control-Plane March 2018 > > > [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>. > > [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation > Protocol (LISP): Shared Extension Message & IANA Registry > for Packet Type Allocations", RFC 8113, > DOI 10.17487/RFC8113, March 2017, > <https://www.rfc-editor.org/info/rfc8113>. > > 11.2. Informative References > > [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY > NUMBERS http://www.iana.org/assignments/address-family- > numbers/address-family-numbers.xhtml?, Febuary 2007. > > [I-D.ermagan-lisp-nat-traversal] > Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, > F., and C. White, "NAT traversal for LISP", draft-ermagan- > lisp-nat-traversal-13 (work in progress), September 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-introduction] > Cabellos-Aparicio, A. and D. Saucez, "An Architectural > Introduction to the Locator/ID Separation Protocol > (LISP)", draft-ietf-lisp-introduction-13 (work in > progress), April 2015. > > [I-D.ietf-lisp-mn] > Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP > Mobile Node", draft-ietf-lisp-mn-01 (work in progress), > October 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-09 (work in progress), > February 2018. > > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 40] > > Internet-Draft LISP Control-Plane 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.ietf-lisp-signal-free-multicast] > Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", > draft-ietf-lisp-signal-free-multicast-08 (work in > progress), February 2018. > > [I-D.ietf-opsec-icmp-filtering] > Gont, F., Gont, G., and C. Pignataro, "Recommendations for > filtering ICMP messages", draft-ietf-opsec-icmp- > filtering-04 (work in progress), July 2013. > > [I-D.lewis-lisp-gpe] > Lewis, D., Lemon, J., Agarwal, P., Kreeger, L., Quinn, P., > Smith, M., Yadav, N., and F. Maino, "LISP Generic Protocol > Extension", draft-lewis-lisp-gpe-04 (work in progress), > December 2017. > > [I-D.meyer-loc-id-implications] > Meyer, D. and D. Lewis, "Architectural Implications of > Locator/ID Separation", draft-meyer-loc-id-implications-01 > (work in progress), January 2009. > > [I-D.quinn-vxlan-gpe] > Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., > Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, > P., and D. Melman, "Generic Protocol Extension for VXLAN", > draft-quinn-vxlan-gpe-04 (work in progress), February > 2015. > > [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. > > [LISP-CONS] > Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, > D., and D. Meyer, "LISP-CONS: A Content distribution > Overlay Network Service for LISP", Work in Progress, April > 2008. > > > > > > Fuller, et al. Expires September 5, 2018 [Page 41] > > Internet-Draft LISP Control-Plane March 2018 > > > [RFC1035] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, > November 1987, <https://www.rfc-editor.org/info/rfc1035>. > > [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- > Hashing for Message Authentication", RFC 2104, > DOI 10.17487/RFC2104, February 1997, > <https://www.rfc-editor.org/info/rfc2104>. > > [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>. > > [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms > (SHA and SHA-based HMAC and HKDF)", RFC 6234, > DOI 10.17487/RFC6234, May 2011, > <https://www.rfc-editor.org/info/rfc6234>. > > [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, > "Interworking between Locator/ID Separation Protocol > (LISP) and Non-LISP Sites", RFC 6832, > DOI 10.17487/RFC6832, January 2013, > <https://www.rfc-editor.org/info/rfc6832>. > > [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, > L., Sridhar, T., Bursell, M., and C. Wright, "Virtual > eXtensible Local Area Network (VXLAN): A Framework for > Overlaying Virtualized Layer 2 Networks over Layer 3 > Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, > <https://www.rfc-editor.org/info/rfc7348>. > > [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID > Separation Protocol (LISP) Threat Analysis", RFC 7835, > DOI 10.17487/RFC7835, April 2016, > <https://www.rfc-editor.org/info/rfc7835>. > > [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for > Writing an IANA Considerations Section in RFCs", BCP 26, > RFC 8126, DOI 10.17487/RFC8126, June 2017, > <https://www.rfc-editor.org/info/rfc8126>. > > > > > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 42] > > Internet-Draft LISP Control-Plane March 2018 > > > Appendix A. Acknowledgments > > The authors would like to thank Greg Schudel, Darrel Lewis, John > Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, > Fabio Maino, and members of the lisp@ietf.org mailing list for their > feedback and helpful suggestions. > > Special thanks are due to Noel Chiappa for his extensive work on > caching with LISP-CONS, some of which may be used by Map-Resolvers. > > Appendix B. Document Change Log > > [RFC Editor: Please delete this section on publication as RFC.] > > B.1. Changes to draft-ietf-lisp-rfc6833bis-08 > > o Posted March 2018. > > o Added RLOC-probing algorithm. > > o Added Solicit-Map Request algorithm. > > o Added several mechanisms (from 6830bis) regarding Routing Locator > Reachability. > > o Added port 4342 to IANA Considerations section. > > B.2. Changes to draft-ietf-lisp-rfc6833bis-07 > > o Posted December 2017. > > o Make it more clear in a couple of places that RLOCs are used to > locate ETRs more so than for Map-Server Map-Request forwarding. > > o Make it clear that "encapsualted" for a control message is an ECM > based message. > > o Make it more clear what messages use source-port 4342 and which > ones use destinatino-port 4342. > > o Don't make DDT references when the mapping transport system can be > of any type and the referneced text is general to it. > > o Generalize text when referring to the format of an EID-prefix. > Can use othe AFIs then IPv4 and IPv6. > > o Many editorial changes to clarify text. > > > > > Fuller, et al. Expires September 5, 2018 [Page 43] > > Internet-Draft LISP Control-Plane March 2018 > > > o Changed some "must", "should", and "may" to capitalized. > > o Added definitions for Map-Request and Map-Reply messages. > > o Ran document through IDNITs. > > B.3. Changes to draft-ietf-lisp-rfc6833bis-06 > > o Posted October 2017. > > o Spec the I-bit to include the xTR-ID in a Map-Request message to > be consistent with the Map-Register message and to anticipate the > introduction of pubsub functionality to allow Map-Requests to > subscribe to RLOC-set changes. > > o Updated references for individual submissions that became working > group documents. > > o Updated references for working group documents that became RFCs. > > B.4. Changes to draft-ietf-lisp-rfc6833bis-05 > > o Posted May 2017. > > o Update IANA Considerations section based on new requests from this > document and changes from what was requested in [RFC6830]. > > B.5. Changes to draft-ietf-lisp-rfc6833bis-04 > > o Posted May 2017. > > o Clarify how the Key-ID field is used in Map-Register and Map- > Notify messages. Break the 16-bit field into a 8-bit Key-ID field > and a 8-bit Algorithm-ID field. > > o Move the control-plane codepoints from the IANA Considerations > section of RFC6830bis to the IANA Considerations section of this > document. > > o In the "LISP Control Packet Type Allocations" section, indicate > how message Types are IANA allocated and how experimental RFC8113 > sub-types should be requested. > > B.6. Changes to draft-ietf-lisp-rfc6833bis-03 > > o Posted April 2017. > > o Add types 9-14 and specify they are not assigned. > > > > Fuller, et al. Expires September 5, 2018 [Page 44] > > Internet-Draft LISP Control-Plane March 2018 > > > o Add the "LISP Shared Extension Message" type and point to RFC8113. > > B.7. Changes to draft-ietf-lisp-rfc6833bis-02 > > o Posted April 2017. > > o Clarify that the LISP control-plane document defines how the LISP > data-plane uses Map-Requests with either the SMR-bit set or the > P-bit set supporting mapping updates and RLOC-probing. Indicating > that other data-planes can use the same mechanisms or their own > defined mechanisms to achieve the same functionality. > > B.8. Changes to draft-ietf-lisp-rfc6833bis-01 > > o Posted March 2017. > > o Include references to new RFCs published. > > o Remove references to self. > > o Change references from RFC6830 to RFC6830bis. > > o Add two new action/reasons to a Map-Reply has posted to the LISP > WG mailing list. > > o In intro section, add refernece to I-D.ietf-lisp-introduction. > > o Removed Open Issues section and references to "experimental". > > B.9. Changes to draft-ietf-lisp-rfc6833bis-00 > > o Posted December 2016. > > o Created working group document from draft-farinacci-lisp > -rfc6833-00 individual submission. No other changes made. > > B.10. Changes to draft-farinacci-lisp-rfc6833bis-00 > > o Posted November 2016. > > o This is the initial draft to turn RFC 6833 into RFC 6833bis. > > o The document name has changed from the "Locator/ID Separation > Protocol (LISP) Map-Server Interface" to the "Locator/ID > Separation Protocol (LISP) Control-Plane". > > o The fundamental change was to move the control-plane messages from > RFC 6830 to this document in an effort so any IETF developed or > > > > Fuller, et al. Expires September 5, 2018 [Page 45] > > Internet-Draft LISP Control-Plane March 2018 > > > industry created data-plane could use the LISP mapping system and > control-plane. > > o Update control-plane messages to incorporate what has been > implemented in products during the early phase of LISP development > but wasn't able to make it into RFC6830 and RFC6833 to make the > Experimental RFC deadline. > > o Indicate there may be nodes in the mapping system that are not MRs > or MSs, that is a ALT-node or a DDT-node. > > o Include LISP-DDT in Map-Resolver section and explain how they > maintain a referral-cache. > > o Removed open issue about additional state in Map-Servers. With > [RFC8111], Map-Servers have the same registration state and can > give Map-Resolvers complete information in ms-ack Map-Referral > messages. > > o Make reference to the LISP Threats Analysis RFC [RFC7835]. > > Authors’ Addresses This is a new document shouldn’t contain the addresses of the authors as for now? > > Vince Fuller > Cisco Systems > > EMail: vaf@vaf.net > > > Dino Farinacci > Cisco Systems > > EMail: farinacci@gmail.com > > > Albert Cabellos > UPC/BarcelonaTech > Campus Nord, C. Jordi Girona 1-3 > Barcelona, Catalunya > Spain > > EMail: acabello@ac.upc.edu > > > > > > > > > > Fuller, et al. Expires September 5, 2018 [Page 46]
- [lisp] Review 6833bis Luigi Iannone
- Re: [lisp] Review 6833bis Dino Farinacci
- Re: [lisp] Review 6833bis Luigi Iannone
- Re: [lisp] Review 6833bis Dino Farinacci
- Re: [lisp] Review 6833bis Dino Farinacci
- Re: [lisp] Review 6833bis Joel M. Halpern
- Re: [lisp] Review 6833bis Dino Farinacci
- Re: [lisp] Review 6833bis Joel M. Halpern
- Re: [lisp] Review 6833bis Dino Farinacci
- Re: [lisp] Review 6833bis Joel M. Halpern
- Re: [lisp] Review 6833bis Dino Farinacci