--- 1/draft-ietf-lisp-ddt-06.txt 2016-05-31 12:16:22.210822192 -0700 +++ 2/draft-ietf-lisp-ddt-07.txt 2016-05-31 12:16:22.290824202 -0700 @@ -1,29 +1,29 @@ Network Working Group V. Fuller Internet-Draft Intended status: Experimental D. Lewis -Expires: October 28, 2016 V. Ermagan +Expires: December 2, 2016 V. Ermagan Cisco Systems A. Jain Juniper Networks A. Smirnov Cisco Systems - April 26, 2016 + May 31, 2016 LISP Delegated Database Tree - draft-ietf-lisp-ddt-06 + draft-ietf-lisp-ddt-07 Abstract - This draft describes the LISP Delegated Database Tree (LISP-DDT), a - hierarchical, distributed database which embodies the delegation of + This document describes the LISP Delegated Database Tree (LISP-DDT), + a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -32,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 28, 2016. + This Internet-Draft will expire on December 2, 2016. Copyright Notice Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -66,76 +66,75 @@ 4.2. Configuring prefix delegation . . . . . . . . . . . . . . 7 4.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7 5. DDT Map-Request . . . . . . . . . . . . . . . . . . . . . . . 8 6. The Map-Referral message . . . . . . . . . . . . . . . . . . 8 6.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 10 6.4. Map-Referral Message Format . . . . . . . . . . . . . . . 10 6.4.1. SIG section . . . . . . . . . . . . . . . . . . . . . 12 7. DDT network elements and their operation . . . . . . . . . . 13 - 7.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 13 + 7.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 14 7.1.2. Missing delegation from an authoritative prefix . . . 14 7.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 14 - 7.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 14 + 7.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 15 7.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 15 - 7.3.2. Receiving and following referrals . . . . . . . . . . 15 + 7.3.2. Receiving and following referrals . . . . . . . . . . 16 7.3.3. Handling referral errors . . . . . . . . . . . . . . 17 - 7.3.4. Referral loop detection . . . . . . . . . . . . . . . 17 + 7.3.4. Referral loop detection . . . . . . . . . . . . . . . 18 8. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 18 - 8.1. Map Resolver processing of ITR Map-Request . . . . . . . 18 - 8.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 18 + 8.1. Map Resolver processing of ITR Map-Request . . . . . . . 19 + 8.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 8.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 19 - 8.2. Map Resolver processing of Map-Referral message . . . . . 19 - 8.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 - 8.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 21 - 8.3. DDT Node processing of DDT Map-Request message . . . . . 23 - 8.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 23 - 8.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 24 - 9. Example topology and request/referral following . . . . . . . 24 - 9.1. Lookup of 2001:db8:0103:1::1/128 . . . . . . . . . . . . 26 - 9.2. Lookup of 2001:db8:0501:8:4::1/128 . . . . . . . . . . . 27 - 9.3. Lookup of 2001:db8:0104:2::2/128 . . . . . . . . . . . . 28 - 9.4. Lookup of 2001:db8:0500:2:4::1/128 . . . . . . . . . . . 29 - 9.5. Lookup of 2001:db8:0500::1/128 (non-existent EID) . . . . 29 - 10. Securing the database and message exchanges . . . . . . . . . 30 - 10.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 30 - 10.2. DDT node operation . . . . . . . . . . . . . . . . . . . 31 - 10.2.1. DDT public key revocation . . . . . . . . . . . . . 31 - 10.3. Map Server operation . . . . . . . . . . . . . . . . . . 32 - 10.4. Map Resolver operation . . . . . . . . . . . . . . . . . 32 - 11. Open Issues and Considerations . . . . . . . . . . . . . . . 33 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 33 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 14.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 14.2. Informative References . . . . . . . . . . . . . . . . . 34 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 + 8.2. Map Resolver processing of Map-Referral message . . . . . 20 + 8.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 20 + 8.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 22 + 8.3. DDT Node processing of DDT Map-Request message . . . . . 24 + 8.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 24 + 8.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 25 + 9. Example topology and request/referral following . . . . . . . 25 + 9.1. Lookup of 2001:db8:0103:1::1/128 . . . . . . . . . . . . 27 + 9.2. Lookup of 2001:db8:0501:8:4::1/128 . . . . . . . . . . . 28 + 9.3. Lookup of 2001:db8:0104:2::2/128 . . . . . . . . . . . . 29 + 9.4. Lookup of 2001:db8:0500:2:4::1/128 . . . . . . . . . . . 30 + 9.5. Lookup of 2001:db8:0500::1/128 (non-existent EID) . . . . 30 + 10. Securing the database and message exchanges . . . . . . . . . 31 + 10.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 31 + 10.2. DDT node operation . . . . . . . . . . . . . . . . . . . 32 + 10.2.1. DDT public key revocation . . . . . . . . . . . . . 32 + 10.3. Map Server operation . . . . . . . . . . . . . . . . . . 33 + 10.4. Map Resolver operation . . . . . . . . . . . . . . . . . 33 + 11. Open Issues and Considerations . . . . . . . . . . . . . . . 34 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 35 + 14.2. Informative References . . . . . . . . . . . . . . . . . 35 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction LISP [RFC6830] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate name spaces: - relatively static Endpoint Identifiers (EIDs), used end-to-end for - terminating transport-layer associations, and Routing Locators - (RLOCs), which are more dynamic, are bound to topological location, - and are used for routing and forwarding through the Internet - infrastructure. + Endpoint Identifiers (EIDs), used end-to-end for terminating + transport-layer associations, and Routing Locators (RLOCs), which are + bound to topological location, and are used for routing and + forwarding through the Internet infrastructure. LISP offers a general-purpose mechanism for mapping between EIDs and RLOCs. In organizing a database of EID to RLOC mappings, this specification extends the definition of the EID numbering space by logically prepending and appending several fields for purposes of defining the database index key: Database-ID (DBID, 16 bits), - Instance identifier (IID, 24-bits), Address Family Identifier (16 + Instance identifier (IID, 32-bits), Address Family Identifier (16 bits), and EID-prefix (variable, according to AFI value). The resulting concatenation of these fields is termed an "Extended EID prefix" or XEID-prefix. The DBID is provided for possible use in case a need evolves for another, higher level in the hierarchy, to allow the creation of multiple, separate database trees. LISP-DDT is a hierarchical distributed database, which embodies the delegation of authority to provide mappings, i.e. its internal @@ -192,22 +191,24 @@ Extended EID (XEID): a LISP EID, optionally extended with a non- zero Instance ID (IID) if the EID is intended for use in a context where it may not be a unique value, such as on a Virtual Private Network where [RFC1918] address space is used. See "Using Virtualization and Segmentation with LISP" in [RFC6830] for more discussion of Instance IDs. XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided to allow the definition of multiple databases; currently always zero in this version of DDT, with other values reserved for future - use), 24-bit IID and 16-bit AFI prepended. An XEID-prefix is used - as a key index into the database. + use), 32-bit IID and 16-bit AFI prepended. Encoding of the + prefix, its AFI and the instance ID (IID) are specified by + [I-D.ietf-lisp-lcaf]. An XEID-prefix is used as a key index into + the database. DDT node: a network infrastructure component responsible for specific XEID-prefix and for delegation of more-specific sub- prefixes to other DDT nodes. DDT client: a network infrastructure component that sends Map- Request messages and implements the iterative following of Map- Referral results. Typically, a DDT client will be a Map Resolver, but it is also possible for an ITR to implement DDT client functionality. @@ -281,21 +282,21 @@ Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server, and Map Resolver, please consult the LISP specification [RFC6830] and the LISP Mapping Service specification [RFC6833]. 4. Database organization 4.1. EID-prefix tree structure and instance IDs LISP-DDT defines a tree structure that is indexed by a binary encoding of five fields, in order of significance: DBID (16 bits), - Instance Identifier (IID, 24 bits), Address Family Identifier (AFI, + Instance Identifier (IID, 32 bits), Address Family Identifier (AFI, 16 bits), and EID-prefix (variable, according to AFI value). The fields are concatenated, with the most significant fields as listed above. The index into this structure is also referred to as an Extended EID-prefix (XEID-prefix). It is important to note that LISP-DDT does not store actual EID-to- RLOC mappings; it is, rather, a distributed index that can be used to find the devices (Map Servers and their registered EIDs) that can be queried with LISP to obtain those mappings. Changes to EID-to-RLOC mappings are made on the ETRs which define them, not to any DDT node @@ -353,23 +354,25 @@ IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = xxxx | Dest Port = yyyy | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - D-bit is the "DDT-originated" flag and is set by a DDT client to - indicate that the receiver SHOULD return Map-Referral messages as - appropriate. Use of the flag is further described in Section 7.3.1. + D: The "DDT-originated" flag. It is set by a DDT client to indicate + that the receiver SHOULD return Map-Referral messages as + appropriate. Use of the flag is further described in + Section 7.3.1. This bit is allocated from LISP message header + bits marked as Reserved in [RFC6830]. 6. The Map-Referral message This specification defines a new LISP message, the Map-Referral. It is sent by a DDT node to a DDT client in response to a DDT Map- Request message. See Section 6.4 for a detailed layout of the Map- Referral message fields. The message consists of an action code along with delegation information about the XEID-prefix that matches the requested XEID. @@ -453,21 +456,22 @@ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e | Unused Flags |L|p|R| Loc/LCAF-AFI | | f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Sig section ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: Map-Referral is LISP message type 6. + Type: Type value 6 was reserved for future use in RFC6830, this + document allocates this value to identify Map-Referral messages. ACT: The "action" field of the mapping record in a Map-Referral message encodes 6 action types. The values for the action types are: NODE-REFERRAL (0): Sent by a DDT node with a child delegation, which is authoritative for the EID. MS-REFERRAL (1): Sent by a DDT node that has information about Map Server(s) for the EID but it is not one of the Map Servers listed, i.e. the DDT-Node sending the referral is not a Map Server. @@ -504,36 +508,36 @@ 1 MS-REFERRAL NO YES 1440 2 MS-ACK * * 1440 3 MS-NOT-REGISTERED * * 1 4 DELEGATION-HOLE NO NO 15 5 NOT-AUTHORITATIVE YES NO 0 ------------------------------------------------------------------- - *: The "Incomplete" flag setting on Map Server originated referral of MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map Server has the full peer Map Server configuration for the same prefix and has encoded the information in the mapping record. - Incomplete bit is not set when the Map Server has encoded the information, which means the referral-set includes all the RLOCs of all Map Servers that serve the prefix. It is set when the Map Server has not encoded the Map Server set information. SigCnt: Indicates the number of signatures (sig section) present in the Record. If SigCnt is larger than 0, the signature information captured in a sig section as described in Section 6.4.1 will be appended to the end of the record. The number of sig sections at the - end of the Record must match the SigCnt. + end of the Record must match the SigCnt. Note that bits occupied by + SigCnt were Reserved in Records embedded into messages defined by + [RFC6830] and were required to be set to zero. Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the record. If this is a LCAF AFI, the contents of the LCAF depend on the Type field of the LCAF. Security material are stored in LCAF Type 11. DDT nodes and Map Servers can use this LCAF Type to include public keys associated with their Child DDT nodes for a XEID-prefix referral record. LCAF types and formats are defined in [I-D.ietf-lisp-lcaf]. All other fields and their descriptions are equivalent to those in