draft-ietf-lisp-ddt-08.txt   draft-ietf-lisp-ddt-09.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft Internet-Draft
Intended status: Experimental D. Lewis Intended status: Experimental D. Lewis
Expires: March 12, 2017 V. Ermagan Expires: July 22, 2017 V. Ermagan
Cisco Systems Cisco Systems
A. Jain A. Jain
Juniper Networks Juniper Networks
A. Smirnov A. Smirnov
Cisco Systems Cisco Systems
September 8, 2016 January 18, 2017
LISP Delegated Database Tree LISP Delegated Database Tree
draft-ietf-lisp-ddt-08 draft-ietf-lisp-ddt-09
Abstract Abstract
This document describes the LISP Delegated Database Tree (LISP-DDT), This document describes the LISP Delegated Database Tree (LISP-DDT),
a hierarchical, distributed database which embodies the delegation of a hierarchical, distributed database which embodies the delegation of
authority to provide mappings from LISP Endpoint Identifiers (EIDs) authority to provide mappings from LISP Endpoint Identifiers (EIDs)
to Routing Locators (RLOCs). It is a statically-defined distribution to Routing Locators (RLOCs). It is a statically-defined distribution
of the EID namespace among a set of LISP-speaking servers, called DDT of the EID namespace among a set of LISP-speaking servers, called DDT
nodes. Each DDT node is configured as "authoritative" for one or nodes. Each DDT node is configured as "authoritative" for one or
more EID-prefixes, along with the set of RLOCs for Map Servers or more EID-prefixes, along with the set of RLOCs for Map Servers or
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2017. This Internet-Draft will expire on July 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
4. Database organization . . . . . . . . . . . . . . . . . . . . 7 4. Database organization . . . . . . . . . . . . . . . . . . . . 7
4.1. EID-prefix tree structure and instance IDs . . . . . . . 7 4.1. XEID prefixes . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Configuring prefix delegation . . . . . . . . . . . . . . 7 4.2. DDT database tree structure . . . . . . . . . . . . . . . 7
4.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7 4.3. Configuring prefix delegation . . . . . . . . . . . . . . 8
5. DDT Map-Request . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. The root DDT node . . . . . . . . . . . . . . . . . . 9
6. The Map-Referral message . . . . . . . . . . . . . . . . . . 8 5. DDT Map-Request . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 9 6. The Map-Referral message . . . . . . . . . . . . . . . . . . 10
6.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 10 6.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Map-Referral Message Format . . . . . . . . . . . . . . . 10 6.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 11
6.4.1. SIG section . . . . . . . . . . . . . . . . . . . . . 12 6.4. Map-Referral Message Format . . . . . . . . . . . . . . . 11
7. DDT network elements and their operation . . . . . . . . . . 13 6.4.1. SIG section . . . . . . . . . . . . . . . . . . . . . 14
7.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 14 7. DDT network elements and their operation . . . . . . . . . . 15
7.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 14 7.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.2. Missing delegation from an authoritative prefix . . . 14 7.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 15
7.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 14 7.1.2. Missing delegation from an authoritative prefix . . . 16
7.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 15 7.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 16
7.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 15 7.3. DDT client . . . . . . . . . . . . . . . . . . . . . . . 17
7.3.2. Receiving and following referrals . . . . . . . . . . 16 7.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 17
7.3.3. Handling referral errors . . . . . . . . . . . . . . 18 7.3.2. Receiving and following referrals . . . . . . . . . . 18
7.3.4. Referral loop detection . . . . . . . . . . . . . . . 18 7.3.3. Handling referral errors . . . . . . . . . . . . . . 20
8. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 19 7.3.4. Referral loop detection . . . . . . . . . . . . . . . 20
8.1. Map Resolver processing of ITR Map-Request . . . . . . . 19 8. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 21
8.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 8.1. Map Resolver processing of ITR Map-Request . . . . . . . 21
8.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 19 8.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 21
8.2. Map Resolver processing of Map-Referral message . . . . . 20 8.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 21
8.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 20 8.2. Map Resolver processing of Map-Referral message . . . . . 22
8.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 22 8.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 22
8.3. DDT Node processing of DDT Map-Request message . . . . . 24 8.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 24
8.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 24 8.3. DDT Node processing of DDT Map-Request message . . . . . 25
8.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 25 8.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 25
9. Example topology and request/referral following . . . . . . . 25 8.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 27
9.1. Lookup of 2001:db8:0103:1::1/128 . . . . . . . . . . . . 27 9. Example topology and request/referral following . . . . . . . 27
9.2. Lookup of 2001:db8:0501:8:4::1/128 . . . . . . . . . . . 28 9.1. Lookup of 2001:db8:0103:1::1/128 . . . . . . . . . . . . 30
9.3. Lookup of 2001:db8:0104:2::2/128 . . . . . . . . . . . . 29 9.2. Lookup of 2001:db8:0501:8:4::1/128 . . . . . . . . . . . 31
9.4. Lookup of 2001:db8:0500:2:4::1/128 . . . . . . . . . . . 30 9.3. Lookup of 2001:db8:0104:2::2/128 . . . . . . . . . . . . 32
9.5. Lookup of 2001:db8:0500::1/128 (non-existent EID) . . . . 30 9.4. Lookup of 2001:db8:0500:2:4::1/128 . . . . . . . . . . . 32
10. Securing the database and message exchanges . . . . . . . . . 31 9.5. Lookup of 2001:db8:0500::1/128 (non-existent EID) . . . . 33
10.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 31 10. Securing the database and message exchanges . . . . . . . . . 34
10.2. DDT node operation . . . . . . . . . . . . . . . . . . . 32 10.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 34
10.2.1. DDT public key revocation . . . . . . . . . . . . . 32 10.2. DDT node operation . . . . . . . . . . . . . . . . . . . 35
10.3. Map Server operation . . . . . . . . . . . . . . . . . . 33 10.2.1. DDT public key revocation . . . . . . . . . . . . . 35
10.4. Map Resolver operation . . . . . . . . . . . . . . . . . 33 10.3. Map Server operation . . . . . . . . . . . . . . . . . . 36
11. Open Issues and Considerations . . . . . . . . . . . . . . . 34 10.4. Map Resolver operation . . . . . . . . . . . . . . . . . 36
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. Open Issues and Considerations . . . . . . . . . . . . . . . 37
13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. Security Considerations . . . . . . . . . . . . . . . . . . . 37
14.1. Normative References . . . . . . . . . . . . . . . . . . 35 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
14.2. Informative References . . . . . . . . . . . . . . . . . 35 14.1. Normative References . . . . . . . . . . . . . . . . . . 38
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 36 14.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
LISP [RFC6830] specifies an architecture and mechanism for replacing LISP [RFC6830] specifies an architecture and mechanism for replacing
the addresses currently used by IP with two separate name spaces: the addresses currently used by IP with two separate name spaces:
Endpoint Identifiers (EIDs), used end-to-end for terminating Endpoint Identifiers (EIDs), used end-to-end for terminating
transport-layer associations, and Routing Locators (RLOCs), which are transport-layer associations, and Routing Locators (RLOCs), which are
bound to topological location, and are used for routing and bound to topological location, and are used for routing and
forwarding through the Internet infrastructure. forwarding through the Internet infrastructure.
[RFC6833] specifies an interface between database storing EID-to-RLOC
mappings and LISP devices which need this information for packet
forwarding. Internal organization of such database is out the scope
of [RFC6833]. Multiple architectures of the database have been
proposed, each having its advantages and disadvantages (see for
example [RFC6836] and [RFC6837]).
This document specifies architecture for database of LISP EID-to-RLOC
mappings with emphasis on high scalability. LISP-DDT is a
hierarchical distributed database, which embodies the delegation of
authority to provide mappings, i.e. its internal structure mirrors
the hierarchical delegation of address space. It also provides
delegation information to Map Resolvers, which use the information to
locate EID-to-RLOC mappings. A Map Resolver, which needs to locate a
given mapping, will follow a path through the tree-structured
database, contacting, one after another, the DDT nodes along that
path until it reaches the leaf DDT node(s) authoritative for the
mapping it is seeking.
LISP offers a general-purpose mechanism for mapping between EIDs and LISP offers a general-purpose mechanism for mapping between EIDs and
RLOCs. In organizing a database of EID to RLOC mappings, this RLOCs. In organizing a database of EID to RLOC mappings, this
specification extends the definition of the EID numbering space by specification extends the definition of the EID numbering space by
logically prepending and appending several fields for purposes of logically prepending and appending several fields for purposes of
defining the database index key: Database-ID (DBID, 16 bits), defining the database index key: Database-ID (DBID, 16 bits),
Instance identifier (IID, 32-bits), Address Family Identifier (16 Instance identifier (IID, 32-bits), Address Family Identifier (16
bits), and EID-prefix (variable, according to AFI value). The bits), and EID-prefix (variable, according to AFI value). The
resulting concatenation of these fields is termed an "Extended EID resulting concatenation of these fields is termed an "Extended EID
prefix" or XEID-prefix. 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
structure mirrors the hierarchical delegation of address space. It
also provides delegation information to Map Resolvers, which use the
information to locate EID-to-RLOC mappings. A Map Resolver, which
needs to locate a given mapping, will follow a path through the tree-
structured database, contacting, one after another, the DDT nodes
along that path until it reaches the leaf DDT node(s) authoritative
for the mapping it is seeking.
LISP-DDT defines a new device type, the DDT node, that is configured LISP-DDT defines a new device type, the DDT node, that is configured
as authoritative for one or more XEID-prefixes. It also is as authoritative for one or more XEID-prefixes. It also is
configured with the set of more-specific sub-prefixes that are configured with the set of more-specific sub-prefixes that are
further delegated to other DDT nodes. To delegate a sub-prefix, the further delegated to other DDT nodes. To delegate a sub-prefix, the
"parent" DDT node is configured with the RLOCs of each child DDT node "parent" DDT node is configured with the RLOCs of each child DDT node
that is authoritative for the sub-prefix. Each RLOC either points to that is authoritative for the sub-prefix. Each RLOC either points to
a Map Server (sometimes termed a "terminal DDT node") to which an a DDT Map Server to which an Egress Tunnel Router (ETR) has
Egress Tunnel Router (ETR) has registered that sub-prefix or points registered that sub-prefix or points to another DDT node in the
to another DDT node in the database tree that further delegates the database tree that further delegates the sub-prefix. See [RFC6833]
sub-prefix. See [RFC6833] for a description of the functionality of for a description of the functionality of the Map Server and Map
the Map Server and Map Resolver. Note that the target of a Resolver. Note that the target of a delegation must always be an
delegation must always be an RLOC (not an EID) to avoid any circular RLOC (not an EID) to avoid any circular dependency.
dependency.
To provide a mechanism for traversing the database tree, LISP-DDT To provide a mechanism for traversing the database tree, LISP-DDT
defines a new LISP message type, the Map-Referral, which is returned defines a new LISP message type, the Map-Referral, which is returned
to the sender of a Map-Request when the receiving DDT node can refer to the sender of a Map-Request when the receiving DDT node can refer
the sender to another DDT node that has more detailed information. the sender to another DDT node that has more detailed information.
See Section 6 for the definition of the Map-Referral message. See Section 6 for the definition of the Map-Referral message.
To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map
Resolver, starts by sending an Encapsulated Map-Request to a Resolver, starts by sending an Encapsulated Map-Request to a
preconfigured DDT node RLOC. The DDT node responds with a Map- preconfigured DDT node RLOC. The DDT node responds with a Map-
skipping to change at page 5, line 7 skipping to change at page 5, line 7
NS records) from a series of DNS servers until it finds an answer. NS records) from a series of DNS servers until it finds an answer.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definition of Terms 3. Definition of Terms
Extended EID (XEID): a LISP EID, optionally extended with a non- Extended EID (XEID): a LISP EID extended with data uniquely
zero Instance ID (IID) if the EID is intended for use in a context identifying address space to which it belongs, such as LISP
where it may not be a unique value, such as on a Virtual Private instance ID, Address Family etc. See Section 4.1 for detailed
Network where [RFC1918] address space is used. See "Using description of XEID data.
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 XEID-prefix: Extended EID-prefix (XEID-prefix) is a LISP EID-prefix
to allow the definition of multiple databases; currently always prepended with XEID data. An XEID-prefix is used as a key index
zero in this version of DDT, with other values reserved for future into the DDT database. XEID prefixes are used to describe
use), 32-bit IID and 16-bit AFI prepended. Encoding of the database organization and are not seen as a single entity in
prefix, its AFI and the instance ID (IID) are specified by protocol messages, though messages contain individual fields
[I-D.ietf-lisp-lcaf]. An XEID-prefix is used as a key index into constituting XEID prefix.
the database.
DDT node: a network infrastructure component responsible for DDT node: a network infrastructure component responsible for
specific XEID-prefix and for delegation of more-specific sub- specific XEID-prefix(es) and for delegation of more-specific sub-
prefixes to other DDT nodes. prefixes to other DDT nodes.
DDT client: a network infrastructure component that sends Map- DDT client: a network infrastructure component that sends DDT Map-
Request messages and implements the iterative following of Map- Request messages and implements the iterative following of Map-
Referral results. Typically, a DDT client will be a Map Resolver, Referral results. Typically, a DDT client will be a Map Resolver
but it is also possible for an ITR to implement DDT client (as defined by [RFC6833]), but it is also possible for an ITR to
functionality. implement DDT client functionality.
DDT Map Server: a DDT node that also implements Map Server DDT Map Server: a DDT node that also implements Map Server
functionality (forwarding Map-Requests and/or returning Map- functionality (forwarding Map-Requests and/or returning Map-
Replies if offering proxy Map-Reply service) for a subset of its Replies if offering proxy Map-Reply service) for a subset of its
delegated prefixes. Map Server functions including proxying Map- delegated prefixes. Map Server functions including proxying Map-
Replies are described in [RFC6833]. Replies are described in [RFC6833].
DDT Map Resolver: a network infrastructure element that accepts a DDT Map Server peers: list of all DDT Map Servers performing Map
Map-Request, adds the XEID to its pending request list, then Server functionality for the same prefix. If peers are configured
queries one or more DDT nodes for the requested EID, following on a DDT Map Server then the latter will provide complete
returned referrals until it receives one with action code MS-ACK information about the prefix in its Map-Replies; otherwise the Map
(or an error indication). MS-ACK indicates that the Map-Request Server will mark returned reply as potentially incomplete.
has been sent to a Map Server that will forward it to an ETR that,
in turn, will provide a Map-Reply to the original sender. A DDT DDT Map Resolver: a network infrastructure element which implements
Map Resolver maintains both a cache of Map-Referral message both the DDT client functionality and Map Resolver functionality
results containing RLOCs for DDT nodes responsible for XEID- as defined by [RFC6833]. DDT Map Resolver accepts Map-Requests
prefixes of interest (termed the "referral cache") and a pending from ITRs, sends DDT Map-Requests to DDT nodes and implements
request list of XEIDs that are being resolved through iterative iterative following of Map-Referrals. Note that Map Resolvers do
querying of DDT nodes. not respond to clients which sent Map-Requests, they only ensure
that the Map-Request has been forwarded to a LISP device (ETR or
proxy Map-Server) which will provide authoritative response to the
original requestor. A DDT Map Resolver will typically maintain a
cache of previously received Map-Referral message results
containing RLOCs for DDT nodes responsible for XEID- prefixes of
interest (termed the "referral cache").
Encapsulated Map-Request: a LISP Map-Request carried within an Encapsulated Map-Request: a LISP Map-Request carried within an
Encapsulated Control Message, which has an additional LISP header Encapsulated Control Message, which has an additional LISP header
prepended. Sent to UDP destination port 4342. The "outer" prepended. Sent to UDP destination port 4342. The "outer"
addresses are globally-routable IP addresses, also known as RLOCs. addresses are globally-routable IP addresses, also known as RLOCs.
Used by an ITR when sending to a Map Resolver and by a Map Server Used by an ITR when sending to a Map Resolver and by a Map Server
when forwarding a Map-Request to an ETR as documented in LISP-MS when forwarding a Map-Request to an ETR as documented in LISP-MS
[RFC6833]. [RFC6833].
DDT Map-Request: an Encapsulated Map-Request sent by a DDT client to DDT Map-Request: an Encapsulated Map-Request sent by a DDT client to
skipping to change at page 6, line 25 skipping to change at page 6, line 28
Requests are sent. Section 5 defines position of the "DDT- Requests are sent. Section 5 defines position of the "DDT-
originated" flag in the Encapsulated Control Message header. originated" flag in the Encapsulated Control Message header.
Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node
and for which the DDT node may provide further delegations of and for which the DDT node may provide further delegations of
more-specific sub-prefixes. more-specific sub-prefixes.
Map-Referral: a LISP message sent by a DDT node in response to a DDT Map-Referral: a LISP message sent by a DDT node in response to a DDT
Map-Request for an XEID that matches a configured XEID-prefix Map-Request for an XEID that matches a configured XEID-prefix
delegation. A non-negative Map-Referral includes a "referral", a delegation. A non-negative Map-Referral includes a "referral", a
set of RLOCs for DDT nodes that have more information about the set of RLOCs for DDT nodes that have information about the more
sub-prefix; a DDT client "follows the referral" by sending another specific XEID prefix covering requested XEID; a DDT client
DDT Map-Request to one of those RLOCs to obtain either an answer "follows the referral" by sending another DDT Map-Request to one
or another referral to DDT nodes responsible for a more-specific of those RLOCs to obtain either an answer or another referral to
XEID-prefix. See Section 7.1 and Section 7.3.2 for details on the DDT nodes responsible for even more specific XEID-prefix. See
sending and processing of Map-Referral messages. Section 7.1 and Section 7.3.2 for details on the sending and
processing of Map-Referral messages.
Negative Map-Referral: a Map-Referral sent in response to a DDT Map- Negative Map-Referral: an answer from an authoritative DDT node that
Request that matches an authoritative XEID-prefix but for which there is no mapping for the requested XEID. Negative Map-Referral
there is no delegation configured (or no ETR registration if sent is a Map-Referral sent in response to a DDT Map-Request that
by a DDT Map-Server). matches an authoritative XEID-prefix but for which there is no
delegation configured (or no ETR registration if sent by a DDT
Map-Server).
Pending Request List: the set of outstanding requests for which a Pending Request List: the set of outstanding requests for which a
DDT Map Resolver has received encapsulated Map-Requests from a DDT DDT Map Resolver has received encapsulated Map-Requests from its
client for an XEID. Each entry in the list contains additional clients seeking EID-to-RLOC mapping for a XEID. Each entry in the
state needed by the referral following process, including the list contains additional state needed by the referral following
requestor(s) of the XEID (typically, one or more ITRs), saved process, including the XEID, requestor(s) of the XEID (typically,
information about the last referral received and followed one or more ITRs), saved information about the last referral
(matching XEID-prefix, action code, RLOC set, index of last RLOC received and followed (matching XEID-prefix, action code, RLOC
queried in the RLOC set), and any LISP-SEC information set, index of last RLOC queried in the RLOC set), and any LISP-SEC
([I-D.ietf-lisp-sec]) that was included in the DDT client Map- information ([I-D.ietf-lisp-sec]) that was included in the DDT
Request. An entry in the list may be interchangeably termed a client Map-Request. An entry in the list may be interchangeably
"pending request list entry" or simply a "pending request". termed a "pending request list entry" or simply a "pending
request".
For definitions of other terms, notably Map-Request, Map-Reply, For definitions of other terms, notably Map-Request, Map-Reply,
Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server,
and Map Resolver, please consult the LISP specification [RFC6830] and and Map Resolver, please consult the LISP specification [RFC6830] and
the LISP Mapping Service specification [RFC6833]. the LISP Mapping Service specification [RFC6833].
4. Database organization 4. Database organization
4.1. EID-prefix tree structure and instance IDs 4.1. XEID prefixes
LISP-DDT defines a tree structure that is indexed by a binary DDT database is indexed by Extended EID-prefixes (XEID-prefixes).
encoding of five fields, in order of significance: DBID (16 bits), XEID-prefix is LISP EID-prefix together with data extending it to
Instance Identifier (IID, 32 bits), Address Family Identifier (AFI, uniquely identify address space of the prefix. XEID-prefix is
16 bits), and EID-prefix (variable, according to AFI value). The composed as binary encoding of five fields, in order of significance:
fields are concatenated, with the most significant fields as listed DBID (16 bits), Instance Identifier (IID, 32 bits), Address Family
above. The index into this structure is also referred to as an Identifier (AFI, 16 bits), and EID-prefix (variable, according to AFI
Extended EID-prefix (XEID-prefix). value). The fields are concatenated, with the most significant
fields as listed above.
DBID is LISP-DDT database ID, a 16-bit field provided to allow the
definition of multiple databases. In this version of DDT DBID MUST
always be set to zero. Other values of DBID are reserved for future
use.
Instance ID (IID) is 32-bit value describing context of EID prefix if
the latter is intended for use in an environment where addresses may
not be unique, 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.
Encoding of the instance ID (IID) is specified by
[I-D.ietf-lisp-lcaf].
Address Family Identifier (AFI) is a 16-bit value defining syntax of
EID-prefix. AFI values are assigned by IANA ([AFI].
4.2. DDT database tree structure
LISP-DDT database of each DDT node is organised as a tree structure
that is indexed by XEID prefixes. Leaves of the database tree
describe delegation of authority between DDT nodes (see more on
delegation and information kept in the database entries in
Section 4.3).
DDT Map-Requests sent by the DDT client to DDT nodes always contain
specific values for DBID, IID and AFI; never a range or unspecified
value for any of these fields. Thus XEID prefix used as key for
search in the database tree will have length of at least 64 bits.
DDT node may, for example, be authoritative for a consecutive range
of 3-tuples (DBID, IID, AFI) and all associated EID prefixes; or only
for a specific EID prefix of a single 3-tuple. Thus XEID prefixes/
keys of the database tree leaves may have length less, equal or more
than 64 bits.
It is important to note that LISP-DDT does not store actual EID-to- 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 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 find the devices (ETRs which registered their EIDs with DDT Map
queried with LISP to obtain those mappings. Changes to EID-to-RLOC Servers) that can be queried with LISP to obtain those mappings.
mappings are made on the ETRs which define them, not to any DDT node Changes to EID-to-RLOC mappings are made on the ETRs which define
configuration. DDT node configuration changes are only required when them, not to any DDT node configuration. DDT node configuration
branches of the database hierarchy are added, removed, or modified. changes are only required when branches of the database hierarchy are
added, removed, or modified.
4.2. Configuring prefix delegation 4.3. Configuring prefix delegation
Every DDT node is configured with one or more XEID-prefixes for which Every DDT node is configured with one or more XEID-prefixes for which
it is authoritative along with a list of delegations of XEID-prefixes it is authoritative along with a list of delegations of XEID-prefixes
to other DDT nodes. A DDT node is required to maintain a list of to other DDT nodes. A DDT node is required to maintain a list of
delegations for all sub-prefixes of its authoritative XEID-prefixes; delegations for all sub-prefixes of its authoritative XEID-prefixes;
it also may list "hints", which are prefixes that it knows about that it also may list "hints", which are prefixes that it knows about that
belong to its parents, to the root, or to any other point in the belong to its parents, to the root, or to any other point in the
XEID-prefix hierarchy. A delegation (or hint) consists of an XEID- XEID-prefix hierarchy. A delegation (or hint) consists of an XEID-
prefix, a set of RLOCs for DDT nodes that have more detailed prefix, a set of RLOCs for DDT nodes that have more detailed
knowledge of the XEID-prefix, and accompanying security information knowledge of the XEID-prefix, and accompanying security information
(for details of security infomation exchange and its use see (for details of security infomation exchange and its use see
Section 10). Those RLOCs are returned in Map-Referral messages when Section 10). Those RLOCs are returned in Map-Referral messages when
the DDT node receives a DDT Map-Request with an XEID that matches a the DDT node receives a DDT Map-Request with an XEID that matches a
delegation. A DDT Map Server will also have a set of sub-prefixes delegation. A DDT Map Server will also have a set of sub-prefixes
for which it accepts ETR mapping registrations and for which it will for which it accepts ETR mapping registrations and for which it will
forward (or answer, if it provides proxy Map-Reply service) Map- forward (or answer, if it provides proxy Map-Reply service) Map-
Requests. Requests.
4.2.1. The root DDT node XEID prefix (or prefixes) for which DDT node is authoritative and
delegation of authority for sub-prefixes is provided as configuration
of the DDT node. Implementations will likely develop a language to
express this prefix authority and delegation. Since DDT
configuration is static (i.e. not exchanged between DDT nodes as part
of the protocol itself) such language is implementation-dependant and
is outside the scope of this specification.
The root DDT node is the logical "top" of the database hierarchy: 4.3.1. The root DDT node
DBID=0, IID=0, AFI=0, EID-prefix=0/0. A DDT Map-Request that matches
no configured XEID-prefix will be referred to the root node (see The root DDT node is the logical "top" of the distributed database
Section 8 for formal description of conditions when DDT Request is hierarchy. It is authoritative for all XEID prefixes, that is for
forwarded to the root node). The root node in a particular all valid 3-tuples (DBID, IID, AFI) and their EID prefixes. A DDT
instantiation of LISP-DDT therefore MUST be configured with Map-Request that matches no configured XEID-prefix will be referred
delegations for at least all defined IIDs and AFIs. to the root node (see Section 8 for formal description of conditions
when DDT Request is forwarded to the root node). The root node in a
particular instantiation of LISP-DDT therefore MUST be configured
with delegations for at least all defined IIDs and AFIs.
5. DDT Map-Request 5. DDT Map-Request
A DDT client (usualy a Map Resolver) uses LISP Encapsulated Control A DDT client (usualy a Map Resolver) uses LISP Encapsulated Control
Message (ECM) to send Map-Request to a DDT node. Format of the ECM Message (ECM) to send Map-Request to a DDT node. Format of the ECM
is defined by [RFC6830]. This specification adds to ECM flag "DDT- is defined by [RFC6830]. This specification adds to ECM flag "DDT-
originated". originated".
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 9, line 17 skipping to change at page 10, line 24
6.1. Action codes 6.1. Action codes
The action codes are as follows: The action codes are as follows:
NODE-REFERRAL (0): indicates that the replying DDT node has NODE-REFERRAL (0): indicates that the replying DDT node has
delegated an XEID-prefix that matches the requested XEID to one or delegated an XEID-prefix that matches the requested XEID to one or
more other DDT nodes. The Map-Referral message contains a "map- more other DDT nodes. The Map-Referral message contains a "map-
record" with additional information, most significantly the set of record" with additional information, most significantly the set of
RLOCs to which the prefix has been delegated, that is used by a RLOCs to which the prefix has been delegated, that is used by a
DDT Map Resolver to "follow" the referral. DDT client to "follow" the referral.
MS-REFERRAL (1): indicates that the replying DDT node has delegated MS-REFERRAL (1): indicates that the replying DDT node has delegated
an XEID-prefix that matches the requested XEID to one or more DDT an XEID-prefix that matches the requested XEID to one or more DDT
Map Servers. It contains the same additional information as a Map Servers. It contains the same additional information as a
NODE-REFERRAL, but is handled slightly differently by the NODE-REFERRAL, but is handled slightly differently by the
receiving DDT client (see Section 7.3.2). receiving DDT client (see Section 7.3.2).
MS-ACK (2): indicates that a replying DDT Map Server received a DDT MS-ACK (2): indicates that the replying DDT Map Server received a
Map-Request that matches an authoritative XEID-prefix for which it DDT Map-Request that matches an authoritative XEID-prefix for
has one or more registered ETRs. This means that the request has which it has one or more registered ETRs. This means that the
been forwarded to one of those ETRs to provide an answer to the request has been forwarded to one of those ETRs to provide an
querying ITR. answer to the querying ITR.
MS-NOT-REGISTERED (3): indicates that the replying DDT Map Server MS-NOT-REGISTERED (3): indicates that the replying DDT Map Server
received a Map-Request for one of its configured XEID-prefixes received a Map-Request for one of its configured XEID-prefixes
which has no ETRs registered. which has no ETRs registered.
DELEGATION-HOLE (4): indicates that the requested XEID matches a DELEGATION-HOLE (4): indicates that the requested XEID matches a
non-delegated sub-prefix of the XEID space. This is a non-LISP non-delegated sub-prefix of the XEID space. This is a non-LISP
"hole", which has not been delegated to any DDT Map Server or ETR. "hole", which has not been delegated to any DDT Map Server or ETR.
See Section 7.1.2 for details. See Section 7.1.2 for details. Also sent by a DDT Map Server with
authoritative configuration covering the requested EID, but for
which no specific site ETR is configured.
NOT-AUTHORITATIVE (5): indicates that the replying DDT node received NOT-AUTHORITATIVE (5): indicates that the replying DDT node received
a Map-Request for an XEID-request for which it is not a Map-Request for an XEID for which it is not authoritative and
authoritative. This can occur if a cached referral has become has no configured matching hint referrals. This can occur if a
invalid due to a change in the database hierarchy. cached referral has become invalid due to a change in the database
hierarchy. However, if such a DDT node has a "hint" delegation
covering the requested EID, it MAY choose to return NODE-REFERRAL
or MS-REFERRAL as appropriate. When returning action code NOT-
AUTHORITATIVE DDT node MUST provide EID-prefix received in the
request and the TTL MUST be set to 0.
6.2. Referral set 6.2. Referral set
For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a
DDT node MUST include in the Map-Referral message a list of RLOCs for DDT node MUST include in the Map-Referral message a list of RLOCs for
DDT nodes that are authoritative for the XEID-prefix being returned; DDT nodes that are authoritative for the XEID-prefix being returned;
a DDT Map Resolver uses this information to contact one of those DDT a DDT client uses this information to contact one of those DDT nodes
nodes as it "follows" a referral. as it "follows" a referral.
6.3. Incomplete flag 6.3. Incomplete flag
A DDT node sets the "Incomplete" flag in a Map-Referral message if A DDT node sets the "Incomplete" flag in a Map-Referral message if
the Referral Set is incomplete; this is intended to prevent a DDT Map the Referral Set is incomplete; this is intended to prevent a DDT
Resolver from caching a referral with incomplete information. A DDT client from caching a referral with incomplete information. A DDT
node MUST set the "incomplete" flag in the following cases: node MUST set the "incomplete" flag in the following cases:
o If it is setting action code MS-ACK or MS-NOT-REGISTERED but does o If it is setting action code MS-ACK or MS-NOT-REGISTERED but the
not have configuration for other "peer" DDT nodes that are also matching XEID-prefix is not flagged in configuration as
authoritative for the matched XEID-prefix. "complete". XEID-prefix configuration on DDT Mapping Server
SHOULD be marked as "complete" when configuration of the XEID-
prefix lists all "peer" DDT nodes that are also authoritative for
the same XEID-prefix or when it is known that local DDT node is
the only one authoritative for the XEID-prefix.
o If it is setting action code NOT-AUTHORITATIVE. o If it is setting action code NOT-AUTHORITATIVE.
6.4. Map-Referral Message Format 6.4. Map-Referral Message Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=6 | Reserved | Record Count | |Type=6 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
skipping to change at page 10, line 39 skipping to change at page 12, line 23
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Referral Count| EID mask-len | ACT |A|I| Reserved | R | Referral Count| EID mask-len | ACT |A|I| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c |SigCnt | Map Version Number | EID-AFI | c |SigCnt | Map Version Number | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix ... | r | EID-prefix ... |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| e | Unused Flags |L|p|R| Loc/LCAF-AFI | | e | Unused Flags |L|p|R| Loc-AFI |
| f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator ... | | \| Locator ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~ Sig section ~ | ~ Sig section ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type value 6 was reserved for future use in RFC6830, this Type: Type value 6 was reserved for future use in RFC6830, this
document allocates this value to identify Map-Referral messages. document allocates this value to identify Map-Referral messages.
ACT: The "action" field of the mapping record in a Map-Referral ACT: The "action" field of the mapping record in a Map-Referral
message encodes 6 action types. The values for the action types are: message encodes one of the 6 action types: NODE-REFERRAL, MS-
REFERRAL, MS-ACK, MS-NOT-REGISTERED, DELEGATION-HOLE, NOT-
NODE-REFERRAL (0): Sent by a DDT node with a child delegation, which AUTHORITATIVE. See Section 6.1 for description of their meaning.
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.
MS-ACK (2): Sent by a DDT Map Server that has one or more ETR
registered for the EID.
MS-NOT-REGISTERED (3): Sent by a DDT Map Server that is configured
for the EID-prefix, but for which no ETRs are registered.
DELEGATION-HOLE (4): Sent by an intermediate DDT node with
authoritative configuration covering the requested EID but without
any child delegation for the EID. Also sent by a DDT Map Server
with authoritative configuration covering the requested EID, but
for which no specific site ETR is configured.
NOT-AUTHORITATIVE (5): Sent by a DDT node that does not have
authoritative configuration for the requested EID. The EID-prefix
returned MUST be the original requested EID and the TTL MUST be
set to 0. However, if such a DDT node has a "hint" delegation
covering the requested EID, it MAY choose to return NODE-REFERRAL
or MS-REFERRAL as appropriate.
Incomplete: The "I" bit indicates that a DDT node's referral-set of Incomplete: The "I" bit indicates that a DDT node's referral-set of
locators is incomplete and the receiver of this message SHOULD NOT locators is incomplete and the receiver of this message SHOULD NOT
cache the referral. A DDT sets the "incomplete" flag, the TTL, and cache the referral. A DDT sets the "incomplete" flag, the TTL, and
the Action Type field as follows: the Action Type field as follows:
------------------------------------------------------------------- -------------------------------------------------------------------
Type (Action field) Incomplete Referral-set TTL values Type (Action field) Incomplete Referral-set TTL values
------------------------------------------------------------------- -------------------------------------------------------------------
0 NODE-REFERRAL NO YES 1440 0 NODE-REFERRAL NO YES 1440
skipping to change at page 12, line 4 skipping to change at page 13, line 20
1 MS-REFERRAL NO YES 1440 1 MS-REFERRAL NO YES 1440
2 MS-ACK * * 1440 2 MS-ACK * * 1440
3 MS-NOT-REGISTERED * * 1 3 MS-NOT-REGISTERED * * 1
4 DELEGATION-HOLE NO NO 15 4 DELEGATION-HOLE NO NO 15
5 NOT-AUTHORITATIVE YES NO 0 5 NOT-AUTHORITATIVE YES NO 0
------------------------------------------------------------------- -------------------------------------------------------------------
*: The "Incomplete" flag setting on Map Server originated referral of *: The "Incomplete" flag setting on Map Server originated referral of
MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map MS-ACK and MS-NOT-REGISTERED types depend on whether the Map
Server has the full peer Map Server configuration for the same Server has the full peer Map Server configuration for the same
prefix and has encoded the information in the mapping record. prefix and has encoded the information in the mapping record.
Incomplete bit is not set when the Map Server has encoded the Incomplete bit is not set when the Map Server has encoded the
information, which means the referral-set includes all the RLOCs information, which means the referral-set includes all the RLOCs
of all Map Servers that serve the prefix. It MUST be set when the of all Map Servers that serve the prefix. It MUST be set when
Map Server has not encoded the complete Map Server set configuration of the Map Server does not flag matching prefix as
information. configured with the complete information about "peer" Map Servers
or when the Map Server does not return all configured locators.
Referral Count: number of RLOCs in the current Referral set, it is
equal to the number of Ref sections in the message.
SigCnt: Indicates the number of signatures (sig section) present in SigCnt: Indicates the number of signatures (sig section) present in
the Record. If SigCnt is larger than 0, the signature information 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 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 appended to the end of the record. The number of sig sections at the
end of the Record MUST match the SigCnt. Note that bits occupied by end of the Record MUST match the SigCnt. Note that bits occupied by
SigCnt were Reserved in Records embedded into messages defined by SigCnt were Reserved in Records embedded into messages defined by
[RFC6830] and were required to be set to zero. [RFC6830] and were required to be set to zero.
Loc/LCAF-AFI: If this is a Loc AFI, keys SHOULD NOT be included in Loc-AFI: AFI of the Locator field. If AFI value is different from
the record. If this is a LCAF AFI, the contents of the LCAF depend LCAF AFI, security keys are not included in the record. If AFI is
on the Type field of the LCAF. Security material are stored in LCAF equal to the LCAF AFI, the contents of the LCAF depend on the Type
Type 11. DDT nodes and Map Servers can use this LCAF Type to include field of the LCAF. LCAF Type 11 is used to store security material
public keys associated with their Child DDT nodes for a XEID-prefix along with the AFI of the locator. DDT nodes and DDT Map Servers can
referral record. LCAF types and formats are defined in use this LCAF Type to include public keys associated with their Child
[I-D.ietf-lisp-lcaf]. DDT nodes for a XEID-prefix referral record. LCAF types and formats
are defined in [I-D.ietf-lisp-lcaf].
Locator: RLOC of a DDT node the DDT client is being referred to.
Lenght of this variable-length field is determined by the Loc-AFI.
All other fields and their descriptions are equivalent to those in All other fields and their descriptions are equivalent to those in
the Map-Reply message, as defined in LISP [RFC6830]. Note, though, the Map-Reply message, as defined in LISP [RFC6830]. Note, though,
that the set of RLOCs correspond to the DDT node to be queried as a that the set of RLOCs correspond to the DDT node to be queried as a
result of the referral not the RLOCs for an actual EID-to-RLOC result of the referral not the RLOCs for an actual EID-to-RLOC
mapping. mapping.
6.4.1. SIG section 6.4.1. SIG section
SigCnt counts the number of signature sections that appear at the end SigCnt counts the number of signature sections that appear at the end
skipping to change at page 13, line 33 skipping to change at page 14, line 47
the signature. The signature MUST NOT be used for authentication the signature. The signature MUST NOT be used for authentication
prior to the inception date and MUST NOT be used for authentication prior to the inception date and MUST NOT be used for authentication
after the expiration date. Each field specifies a date and time in after the expiration date. Each field specifies a date and time in
the form of a 32-bit unsigned number of seconds elapsed since 1 the form of a 32-bit unsigned number of seconds elapsed since 1
January 1970 00:00:00 UTC, ignoring leap seconds, in network byte January 1970 00:00:00 UTC, ignoring leap seconds, in network byte
order. order.
Key Tag: An identifier to specify which key is used for this Key Tag: An identifier to specify which key is used for this
signature if more than one valid key exists for the signing DDT node. signature if more than one valid key exists for the signing DDT node.
Sig Length: The length of the Signature field. Sig Length: The length of the Signature field in bytes.
Sig-Algorithm: The identifier of the cryptographic algorithm used for Sig-Algorithm: The identifier of the cryptographic algorithm used for
the signature. This specification defines only one algorithm: Sig- the signature. Sig-Algorithm values defined in this specification
Algorithm type 1 is RSA-SHA1 (see [RFC3447]). are listed in Table 1. Implementation conforming to this
specification MUST implement at least RSA-SHA256 for DDT signing.
Sig-Algorithm type 1 RSA-SHA1 is deprecated and SHOULD NOT be used.
+---------------+------------+-----------+------------+
| Sig-Algorithm | Name | Reference | Notes |
+---------------+------------+-----------+------------+
| 1 | RSA-SHA1 | [RFC3447] | DEPRECATED |
| | | | |
| 2 | RSA-SHA256 | [RFC3447] | MANDATORY |
+---------------+------------+-----------+------------+
Table 1: Sig-Algorithm Values
Reserved: This field MUST be set to 0 on transmit and MUST be ignored Reserved: This field MUST be set to 0 on transmit and MUST be ignored
on receipt. on receipt.
Signature: Contains the cryptographic signature that covers the Signature: Contains the cryptographic signature that covers the
entire record. The Record TTL and the sig fields are set to zero for entire referral record that this signature belongs to. The Record
the purpose of computing the Signature. TTL is set to Original Record TTL and the sig fields are Signature
field is set to zero for the purpose of computing the Signature.
7. DDT network elements and their operation 7. DDT network elements and their operation
As described above, DDT introduces a new network element, the "DDT As described above, DDT introduces a new network element, the "DDT
node", extends the functionality of Map Servers and Map Resolvers to node", extends the functionality of Map Servers and Map Resolvers to
send and receive Map-Referral messages. The operation of each of send and receive Map-Referral messages. The operation of each of
these devices is described as follows. these devices is described as follows.
7.1. DDT node 7.1. DDT node
When a DDT node receives a DDT Map-Request, it compares the requested When a DDT node receives a DDT Map-Request, it compares the requested
XEID against its list of XEID-prefix delegations and its list of XEID against its list of XEID-prefix delegations and its list of
authoritative XEID-prefixes and acts as follows: authoritative XEID-prefixes and acts as follows:
7.1.1. Match of a delegated prefix (or sub-prefix) 7.1.1. Match of a delegated prefix (or sub-prefix)
If the requested XEID matches one of the DDT node's delegated If the requested XEID matches one of the DDT node's delegated
prefixes, then a Map-Referral message is returned with the matching prefixes, then a Map-Referral message is returned with the matching
more-specific XEID-prefix and the set of RLOCs for the referral more-specific XEID-prefix and the set of RLOCs for the referral
target DDT nodes including associated security information (see target DDT nodes including associated security information (see
Section 10 for details on security). If the delegation is known to Section 10 for details on security). If at least one DDT node of the
be a DDT Map Server, then the Map-Referral message SHOULD be sent delegation is known to be a DDT Map Server, then the Map-Referral
with action code MS-REFERRAL to indicate to the receiver that LISP- message SHOULD be sent with action code MS-REFERRAL to indicate to
SEC information (if saved in the pending request) SHOULD be included the receiver that LISP-SEC information (if saved in the pending
in the next DDT Map-Request; otherwise, the action code NODE-REFERRAL request) SHOULD be included in the next DDT Map-Request; otherwise,
SHOULD be used. the action code NODE-REFERRAL SHOULD be used.
Note that a matched delegation does not have to be for a sub-prefix Note that a matched delegation does not have to be for a sub-prefix
of an authoritative prefix; in addition to being configured to of an authoritative prefix; in addition to being configured to
delegate sub-prefixes of an authoritative prefix, a DDT node may also delegate sub-prefixes of an authoritative prefix, a DDT node may also
be configured with other XEID-prefixes for which it can provide be configured with other XEID-prefixes for which it can provide
referrals to DDT nodes anywhere in the database hierarchy. This referrals to DDT nodes anywhere in the database hierarchy. This
capability to define "shortcut hints" is never required to be capability to define "shortcut hints" is never required to be
configured, but may be a useful heuristic for reducing the number of configured, but may be a useful heuristic for reducing the number of
iterations needed to find an EID, particular for private network iterations needed to find an EID, particular for private network
deployments. deployments.
Referral hints, if used properly, may reduce number of referrals a
DDT client needs to follow to locate DDT Map Server authoritative for
XEID prefix being resolved. On the other hand, incorrect use of
hints may create circular dependencies between DDT nodes (or
"referral loops"). DDT client MUST be prepared to handle such
circular referrals. See Section 7.3.4 for discussion of referral
loops and measures DDT client must implement in order to detect
circular referrals and prevent infinite looping.
Another danger with use of hints is when DDT deployment spans
multiple administrative domains (i.e. different authorities manage
DDT nodes in the same DDT database). In this case operator managing
a DDT node may not be aware of the fact that the node is being
referred to by hints. Locator addresses in hints may become stale
when referred DDT nodes are taken out of service or change their
locator addresses.
7.1.2. Missing delegation from an authoritative prefix 7.1.2. Missing delegation from an authoritative prefix
If the requested XEID did not match a configured delegation but does If the requested XEID did not match a configured delegation but does
match an authoritative XEID-prefix, then the DDT node MUST return a match an authoritative XEID-prefix, then the DDT node MUST return a
negative Map-Referral that uses the least-specific XEID-prefix that negative Map-Referral that uses the least-specific XEID-prefix that
does not match any XEID-prefix delegated by the DDT node. The action does not match any XEID-prefix delegated by the DDT node. The action
code is set to DELEGATION-HOLE; this indicates that the XEID is not a code is set to DELEGATION-HOLE; this indicates that the XEID is not a
LISP destination. LISP destination.
If the requested XEID did not match either a configured delegation or If the requested XEID did not match either a configured delegation,
an authoritative XEID-prefix, then negative Map-Referral with action an authoritative XEID-prefix or a "hint", then negative Map-Referral
code NOT-AUTHORITATIVE MUST be returned. with action code NOT-AUTHORITATIVE MUST be returned.
7.2. DDT Map Server 7.2. DDT Map Server
When a DDT Map Server receives a DDT Map-Request, its operation is When a DDT Map Server receives a DDT Map-Request, its operation is
similar to that of a DDT node with additional processing as follows: similar to that of a DDT node with additional processing as follows:
o If the requested XEID matches a registered XEID-prefix, then the o If the requested XEID matches a registered XEID-prefix, then the
Map-Request is forwarded to one of the destination ETR RLOCs (or Map-Request is forwarded to one of the destination ETR RLOCs (or
the Map Server sends a Map-Reply, if it is providing proxy Map- the Map Server sends a Map-Reply, if it is providing proxy Map-
Reply service) and a Map-Referral with the MS-ACK action MUST be Reply service) and a Map-Referral with the MS-ACK action MUST be
returned to the sender of the DDT Map-Request. returned to the sender of the DDT Map-Request.
o If the requested XEID matches a configured XEID-prefix for which o If the requested XEID matches a configured XEID-prefix for which
no ETR registration has been received then a negative Map-Referral no ETR registration has been received then a negative Map-Referral
with action code MS-NOT-REGISTERED MUST be returned to the sender with action code MS-NOT-REGISTERED MUST be returned to the sender
of the DDT Map-Request. of the DDT Map-Request.
7.3. DDT Map Resolver 7.3. DDT client
Just as any other Map Resolver, a DDT Map Resolver accepts Map- A DDT client queries one or more DDT nodes and uses an iterative
Requests from its clients (typically, ITRs) and ensures that those process of following returned referrals until it receives one with
Map-Requests are forwarded to the correct ETR, which generates Map- action code MS-ACK (or an error indication). MS-ACK indicates that
Replies. Unlike a Map Resolver that uses the ALT mapping system (see the Map-Request has been sent to a Map Server that will forward it to
[RFC6836]), however, a DDT Map Resolver uses an iterative process of an ETR that, in turn, will provide a Map-Reply to the locator address
following referrals to find the correct ETR to answer a Map-Request; in the Map-Request.
this requires a DDT Map Resolver to maintain additional state: a Map-
Referral cache and pending request list of XEIDs that are going DDT client functionality will typically be implemented by DDT Map
through the iterative referral process. Resolvers. Just as any other Map Resolver, a DDT Map Resolver
accepts Map-Requests from its clients (typically, ITRs) and ensures
that those Map-Requests are forwarded to the correct ETR, which
generates Map-Replies. Unlike a Map Resolver that uses the ALT
mapping system (see [RFC6836]), however, a DDT Map Resolver
implements a DDT client functionality to find the correct ETR to
answer a Map-Request; this requires a DDT Map Resolver to maintain
additional state: a Map-Referral cache and pending request list of
XEIDs that are going through the iterative referral process.
DDT client functionality may be implemented on ITRs. In this case
the DDT client will not receive Map-Request from another network
element; instead, equivalent information will be provided to the DDT
client by the means of programming interface.
7.3.1. Queuing and sending DDT Map-Requests 7.3.1. Queuing and sending DDT Map-Requests
When a DDT Map Resolver receives an encapsulated Map-Request, it When a DDT client receives a request to resolve XEID (in case of DDT
first performs a longest-match search for the XEID in its referral Map Resolver this will be in the form of received encapsulated Map-
cache. If no match is found or if a negative cache entry is found, Request), it first performs a longest-match search for the XEID in
then the destination is not in the database; a negative Map-Reply its referral cache. If no match is found or if a negative cache
MUST be returned and no further processing is performed by the DDT entry is found, then the destination is not in the database; a
Map Resolver. negative Map-Reply MUST be returned and no further processing is
performed by the DDT client.
If a match is found, the DDT Map Resolver creates a pending request If a match is found, the DDT client creates a pending request list
list entry for the XEID and saves the original Map-Request (minus the entry for the XEID and saves the original request (in case of DDT
encapsulation header) along with other information needed to track Map-Resolved, original Map-Request minus the encapsulation header)
progress through the iterative referral process; the "referral XEID- along with other information needed to track progress through the
prefix" is also initialized to the null value since no referral has iterative referral process; the "referral XEID-prefix" is also
yet been received. The Map Resolver then creates a DDT Map-Request initialized to indicate that no referral has yet been received. The
(which is an encapsulated Map-Request with the "DDT-originated" flag DDT client then creates a DDT Map-Request (which is an encapsulated
set in the message header) for the XEID but without any Map-Request with the "DDT-originated" flag set in the message header)
authentication data that may have been included in the original Map- for the XEID but without any authentication data that may have been
Request. It sends the DDT Map-Request to one of the RLOCs in the included in the original request. It sends the DDT Map-Request to
chosen referral cache entry. The referral cache is initially one of the RLOCs in the chosen referral cache entry. The referral
populated with one or more statically-configured entries; additional cache is initially populated with one or more statically-configured
entries are added when referrals are followed, as described below. A entries; additional entries are added when referrals are followed, as
DDT Map Resolver is not absolutely required to cache referrals, but described below. A DDT client is not absolutely required to cache
it doing so decreases latency and reduces lookup delays. referrals, but it doing so decreases latency and reduces lookup
delays.
Note that in normal use on the public Internet, the statically- Note that in normal use on the public Internet, the statically-
configured initial referral cache for a DDT Map Resolver should configured initial referral cache for a DDT client should include a
include a "default" entry with RLOCs for one or more DDT nodes that "default" entry with RLOCs for either the DDT root node or one or
can reach the DDT root node. If a Map Resolver does not have such more DDT nodes that contain hints for the DDT root node. If a DDT
configuration, it will return a Negative Map-Reply if it receives a client does not have such configuration, it will return a Negative
query for an EID outside the subset of the mapping database known to Map-Reply if it receives a query for an EID outside the subset of the
it. While this may be desirable on private network deployments or mapping database known to it. While this may be desirable on private
during early transition to LISP when few sites are using it, this network deployments or during early transition to LISP when few sites
behavior is not appropriate when LISP is in general use on the are using it, this behavior is not appropriate when LISP is in
Internet. general use on the Internet. If DDT message exchange is
authenticated as described in Section 10 then DDT client MUST also be
configured with public keys of DDT nodes pointed to by the "default"
cache entry. In this case the "default" entry will typically be for
the DDT root node.
7.3.2. Receiving and following referrals 7.3.2. Receiving and following referrals
After sending a DDT Map-Request, a DDT Map Resolver expects to After sending a DDT Map-Request, a DDT client expects to receive a
receive a Map-Referral response. If none occurs within the timeout Map-Referral response. If none occurs within the timeout period, the
period, the DDT Map Resolver retransmits the request, sending to the DDT client retransmits the request, sending to the next RLOC in the
next RLOC in the referral cache entry if one is available. If the referral cache entry if one is available. If all RLOCs have been
maximum number of retransmissions has occurred and all RLOCs have tried and the maximum number of retransmissions has occurred for
been tried, then the pending request list entry is dequeued. each, then the pending request list entry is dequeued and discarded.
In this case DDT client returns no response to sender of the original
request.
A DDT Map Resolver processes a received Map-Referral message A DDT client processes a received Map-Referral message according to
according to each action code: each action code:
NODE-REFERRAL: The DDT Map Resolver checks for a possible referral NODE-REFERRAL: The DDT client checks for a possible referral loop as
loop as as described in Section 7.3.4. If no loop is found, the as described in Section 7.3.4. If no loop is found, the DDT
DDT Map Resolver saves the prefix returned in the Map-Referral client saves the prefix returned in the Map-Referral message in
message in the referral cache, updates the saved prefix and saved the referral cache, updates the saved prefix and saved RLOCs in
RLOCs in the pending request list entry, and follows the referral the pending request list entry, and follows the referral by
by sending a new DDT Map-Request to one of the DDT node RLOCs sending a new DDT Map-Request to one of the DDT node RLOCs listed
listed in the Referral Set; security information saved with the in the Referral Set; security information saved with the original
original Map-Request SHOULD NOT be included. Map-Request SHOULD NOT be included.
MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same MS-REFERRAL: The DDT client processes an MS-REFERRAL in the same
manner as a NODE-REFERRAL except that security information saved manner as a NODE-REFERRAL except that security information saved
with the original Map-Request MUST be included in the new Map- with the original Map-Request MUST be included in the new Map-
Request sent to a Map Server (see Section 10 for details on Request sent to a Map Server (see Section 10 for details on
security). security).
MS-ACK: This is returned by a DDT Map Server to indicate that it has MS-ACK: This is returned by a DDT Map Server to indicate that it has
one or more registered ETRs that can answer a Map-Request for the one or more registered ETRs that can answer a Map-Request for the
XEID and the request has been forwarded to one of them (or if the XEID and the request has been forwarded to one of them (or if the
Map Server is doing proxy service for the prefix then reply has Map Server is doing proxy service for the prefix then reply has
been sent to the querying ITR). If the pending request did not been sent to the querying ITR). If the pending request did not
include saved LISP-SEC information or if that information was include saved LISP-SEC information or if that information was
already included in the previous DDT Map-Request (sent by the DDT already included in the previous DDT Map-Request (sent by the DDT
Map Resolver in response to either an MS-REFERRAL or a previous client in response to either an MS-REFERRAL or a previous MS-ACK
MS-ACK referral), then the pending request for the XEID is referral), then the pending request for the XEID is complete;
complete; processing of the request stops and all request state processing of the request stops and all request state can be
can be discarded. Otherwise, LISP-SEC information is required and discarded. Otherwise, LISP-SEC information is required and has
has not yet been sent to the authoritative DDT Map-Server; the DDT not yet been sent to the authoritative DDT Map-Server; the DDT
Map Resolver MUST re-send the DDT Map-Request with LISP-SEC client MUST re-send the DDT Map-Request with LISP-SEC information
information included and the pending request queue entry remains included and the pending request queue entry remains until another
until another Map-Referral with MS-ACK action code is received. Map-Referral with MS-ACK action code is received. If the
If the "incomplete" flag is not set, the prefix is saved in the "incomplete" flag is not set, the prefix is saved in the referral
referral cache. cache.
MS-NOT-REGISTERED: The DDT Map Server queried could not process the MS-NOT-REGISTERED: The DDT Map Server queried could not process the
request because it did not have any ETRs registered for a request because it did not have any ETRs registered for a
matching, authoritative XEID-prefix. If the DDT Map Resolver has matching, authoritative XEID-prefix. If the DDT client has not
not yet tried all of the RLOCs saved with the pending request, yet tried all of the RLOCs saved with the pending request, then it
then it sends a Map-Request to the next RLOC in that list. If all sends a Map-Request to the next RLOC in that list. If all RLOCs
RLOCs have been tried, then the destination XEID is not registered have been tried, then the destination XEID is not registered and
and is unreachable. The DDT Map Resolver MUST return a negative is unreachable. The DDT client MUST return a negative Map-Reply
Map-Reply to the original Map-Request sender; this Map-Reply to the requester (in case of DDT Map Resolver to the sender of
contains the non-registered XEID-prefix whose TTL value SHOULD be original Map-Request); this Map-Reply contains the least-specific
set to one minute. A negative referral cache entry is created for XEID-prefix in the range for which this DDT Map Server is
the prefix (whose TTL also SHOULD be set to one minute) and autoritative and no registrations exist and whose TTL value SHOULD
be set to one minute. A negative referral cache entry is created
for the prefix (whose TTL also SHOULD be set to one minute) and
processing of the request stops. processing of the request stops.
DELEGATION-HOLE: The DDT Map Server queried did not have an XEID- DELEGATION-HOLE: The DDT Map Server queried did not have an XEID-
prefix defined that matched the requested XEID so it does not prefix defined that matched the requested XEID so it does not
exist in the mapping database. The DDT Map Resolver MUST return a exist in the mapping database. The DDT client MUST return a
negative Map-Reply to the original Map-Request sender; this Map- negative Map-Reply to the requester (in case of DDT Map Resolver
Reply SHOULD indicate the least-specific XEID-prefix matching the to the sender of original Map-Request); this Map-Reply SHOULD
requested XEID for which no delegations exist and SHOULD have a indicate the least-specific XEID-prefix matching the requested
TTL value of 15 minutes. A negative referral cache entry is XEID for which no delegations exist and SHOULD have a TTL value of
created for the prefix (which also SHOULD have TTL of 15 minutes) 15 minutes. A negative referral cache entry is created for the
and processing of the pending request stops. prefix (which also SHOULD have TTL of 15 minutes) and processing
of the pending request stops.
NOT-AUTHORITATIVE: The DDT Map Server queried is not authoritative NOT-AUTHORITATIVE: The DDT Map Server queried is not authoritative
for the requested XEID. This can occur if a cached referral has for the requested XEID. This can occur if a cached referral has
become invalid due to a change in the database hierarchy. If the become invalid due to a change in the database hierarchy. If the
DDT Map Resolver receiving this message can determine that it is DDT client receiving this message can determine that it is using
using old cached information, it MAY choose to delete that cached old cached information, it MAY choose to delete that cached
information and re-try the original Map-Request, starting from its information and re-try the original Map-Request, starting from its
"root" cache entry. If this action code is received in response "root" cache entry. If this action code is received in response
to a query that did not use a cached referral information, then it to a query that did not use a cached referral information, then it
indicates a database synchronization problem or configuration indicates a database synchronization problem or configuration
error. The pending request is silently discarded, i.e. all state error. The pending request is silently discarded, i.e. all state
for the request that caused this answer is removed and no answer for the request that caused this answer is removed and no answer
is returned to the original requestor. is returned to the original requestor.
7.3.3. Handling referral errors 7.3.3. Handling referral errors
Other states are possible, such as a misconfigured DDT node (acting Other states are possible, such as a misconfigured DDT node (acting
as a proxy Map Server, for example) returning a Map-Reply to the DDT as a proxy Map Server, for example) returning a Map-Reply to the DDT
Map Resolver; they should be considered errors and logged as such. client; they should be considered errors and logged as such. It is
It is not clear exactly what else the DDT Map Resolver should do in not clear exactly what else the DDT client should do in such cases;
such cases; one possibility is to remove the pending request list one possibility is to remove the pending request list entry and send
entry and send a negative Map-Reply to the original Map-Request a negative Map-Reply to the requester (in case of DDT Map Resolver to
sender. Alternatively, if a DDT Map Resolver detects unexpected the sender of original Map-Request). Alternatively, if a DDT client
behavior by a DDT node, it could mark that node as unusable in its detects unexpected behavior by a DDT node, it could mark that node as
referral cache and update the pending request to try a different DDT unusable in its referral cache and update the pending request to try
node if more than one is listed in the referral cache. In any case, a different DDT node if more than one is listed in the referral
any prefix contained in a Map-Referral message that causes a referral cache. In any case, any prefix contained in a Map-Referral message
error (including a referral loop) is not saved in the DDT Map- that causes a referral error (including a referral loop) is not saved
Resolver referral cache. in the DDT client referral cache.
7.3.4. Referral loop detection 7.3.4. Referral loop detection
In response to a Map-Referral message with action code NODE-REFERRAL In response to a Map-Referral message with action code NODE-REFERRAL
or MS-REFERRAL, a DDT Map Resolver is directed to query a new set of or MS-REFERRAL, a DDT client is directed to query a new set of DDT
DDT node RLOCs that are expected to have more-specific XEID-prefix node RLOCs that are expected to have more-specific XEID-prefix
information for the requested XEID. To prevent a possible "iteration information for the requested XEID. To prevent a possible "iteration
loop" (following referrals back-and-forth among a set of DDT nodes loop" (following referrals back-and-forth among a set of DDT nodes
without ever finding an answer), a DDT Map Resolver saves the last without ever finding an answer), a DDT client saves the last received
received referral XEID-prefix for each pending request and checks referral XEID-prefix for each pending request and checks that a newly
that a newly received NODE-REFERRAL or MS-REFERRAL message contains a received NODE-REFERRAL or MS-REFERRAL message contains a more-
more-specific referral XEID-prefix; an exact or less-specific match specific referral XEID-prefix; an exact or less-specific match of the
of the saved XEID-prefix indicates a referral loop. If a loop is saved XEID-prefix indicates a referral loop. If a loop is detected,
detected, the DDT Map Resolver handles the request as described in the DDT Map Resolver handles the request as described in
Section 7.3.3. Otherwise, the Map Resolver saves the most recently Section 7.3.3. Otherwise, the DDT client saves the most recently
received referral XEID-prefix with the pending request when it received referral XEID-prefix with the pending request when it
follows the referral. follows the referral.
As an extra measure to prevent referral loops, it is probably also As an extra measure to prevent referral loops, it is probably also
wise to limit the total number of referrals for any request to some wise to limit the total number of referrals for any request to some
reasonable number; the exact value of that number will be determined reasonable number; the exact value of that number will be determined
during experimental deployment of LISP-DDT, but is bounded by the during experimental deployment of LISP-DDT, but is bounded by the
maximum length of the XEID. maximum length of the XEID.
Note that when a DDT Map Resolver adds an entry to its lookup queue Note that when a DDT client adds an entry to its lookup queue and
and sends an initial Map-Request for an XEID, the queue entry has no sends an initial Map-Request for an XEID, the queue entry has no
previous referral XEID-prefix; this means that the first DDT node previous referral XEID-prefix; this means that the first DDT node
contacted by a DDT Map Resolver may provide a referral to anywhere in contacted by a DDT Map Resolver may provide a referral to anywhere in
the DDT hierarchy. This, in turn, allows a DDT Map Resolver to use the DDT hierarchy. This, in turn, allows a DDT client to use
essentially any DDT node RLOCs for its initial cache entries and essentially any DDT node RLOCs for its initial cache entries and
depend on the initial referral to provide a good starting point for depend on the initial referral to provide a good starting point for
Map-Requests; there is no need to configure the same set of root DDT Map-Requests; there is no need to configure the same set of root DDT
nodes on all DDT Map Resolvers. nodes on all DDT clients.
8. Pseudo Code and Decision Tree diagrams 8. Pseudo Code and Decision Tree diagrams
To aid in implementation, each of the major DDT Map Server and DDT To illustrate DDT algorithms described above and to aid in
Map Resolver functions are described below, first using simple implementation, each of the major DDT Map Server and DDT Map Resolver
"psuedo-code" and then in the form of a decision tree. functions are described below, first using simple "psuedo-code" and
then in the form of a decision tree.
8.1. Map Resolver processing of ITR Map-Request 8.1. Map Resolver processing of ITR Map-Request
8.1.1. Pseudo-code summary 8.1.1. Pseudo-code summary
if ( request pending i.e., (ITR,EID) of request same ) { if ( request pending i.e., (ITR,EID) of request same ) {
replace old request with new & use new request nonce replace old request with new & use new request nonce
for future requests for future requests
} else if ( no match in refcache ) { } else if ( no match in refcache ) {
return negative map-reply to ITR return negative map-reply to ITR
skipping to change at page 20, line 16 skipping to change at page 22, line 16
| |----> Replace old request with | |----> Replace old request with
| Pending? | new nonce for future requests | Pending? | new nonce for future requests
+------------+ +------------+
| |
|No |No
| |
V V
+------------+ +------------+
| Match In | No | Match In | No
| Referral |----> Send Negative Map-Reply | Referral |----> Send Negative Map-Reply
| cache? | (not a likely event as root | cache? | (not a likely event as root or
+------------+ configured on every MR) +------------+ hint configured on every MR)
| |
|Yes |Yes
| |
V V
+------------+ +------------+
| Match Type | Yes | Match Type | Yes
| Delegation |----> Send Negative Map-Reply | Delegation |----> Send Negative Map-Reply
| Hole? | | Hole? |
+------------+ +------------+
| |
skipping to change at page 20, line 47 skipping to change at page 22, line 47
|No |No
| |
V V
Store request & Fwd DDT Request w/o security material Store request & Fwd DDT Request w/o security material
to DDT node delegation to DDT node delegation
8.2. Map Resolver processing of Map-Referral message 8.2. Map Resolver processing of Map-Referral message
8.2.1. Pseudo-code summary 8.2.1. Pseudo-code summary
if ( authentication signature validation failed ) {
silently drop
}
if ( no request pending matched by referral nonce ) { if ( no request pending matched by referral nonce ) {
silently drop silently drop
} }
if ( pfx in referral less specific than last referral used ) { if ( pfx in referral less specific than last referral used ) {
if ( gone through root ) { if ( gone through root ) {
silently drop silently drop
} else { } else {
send request to root send request to root
} }
skipping to change at page 23, line 4 skipping to change at page 24, line 31
cache cache
} }
} }
case DEFAULT: case DEFAULT:
drop drop
} }
} }
8.2.2. Decision tree diagram 8.2.2. Decision tree diagram
+----------------+
| Auth Signature | No
| Valid? |----> Silently drop
+----------------+
| Yes
V
+------------+ +------------+
| Is Request | No | Is Request | No
| Pending? |----> Silently drop | Pending? |----> Silently drop
+------------+ +------------+
| Yes | Yes
V V
+------------------------------+ Yes +------------------------------+ Yes
| Pfx less specific than last? |----> Silently drop | Pfx less specific than last? |----> Silently drop
+------------------------------+ +------------------------------+
|No |No
skipping to change at page 26, line 13 skipping to change at page 29, line 4
referrals. For the sake of example RLOCs of DDT nodes are shown in referrals. For the sake of example RLOCs of DDT nodes are shown in
IPv4 address space while the EIDs are in IPv6 AF. The same principle IPv4 address space while the EIDs are in IPv6 AF. The same principle
of hierarchical delegation and pinpointing referrals is equally of hierarchical delegation and pinpointing referrals is equally
applicable to any AF whose address hierarchy can be expressed as a applicable to any AF whose address hierarchy can be expressed as a
bitstring with associated length. DDT tree of IPv4 prefixes is bitstring with associated length. DDT tree of IPv4 prefixes is
another AF with immediate practical value. another AF with immediate practical value.
To show how referrals are followed to find the RLOCs for a number of To show how referrals are followed to find the RLOCs for a number of
EIDs, consider the following example EID topology for DBID=0, IID=0, EIDs, consider the following example EID topology for DBID=0, IID=0,
AFI=2, and EID=0/0 AFI=2, and EID=0/0
+---------------------+ +---------------------+ +---------------------+ +---------------------+
| root1: 192.0.2.1 | | root2: 192.0.2.2 | | root1: 192.0.2.1 | | root2: 192.0.2.2 |
| authoritative: ::/0 | | authoritative: ::/0 | | authoritative: ::/0 | | authoritative: ::/0 |
+---------------------+ +---------------------+ +---------------------+ +---------------------+
| \ / | | \ / |
| \ / | | \ / |
| X |
| / \ | | / \ |
| / \ | | / \ |
| | | | | | | |
V V V V V V V V
+-------------------------+ +--------------------------+ +-------------------------+ +--------------------------+
| DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 | | DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 |
| authoritative: | | authoritative: | | authoritative: | | authoritative: |
| 2001:db8::/32 | | 2001:db8::/32 | | 2001:db8::/32 | | 2001:db8::/32 |
+-------------------------+ +--------------------------+ +-------------------------+ +--------------------------+
| \ / | | \ / |
| \ / | | \ / |
| X |
| / \ | | / \ |
| / \ | | / \ |
| | | | | | | |
V V V V V V V V
+--------------------------+ +---------------------------+ +--------------------------+ +---------------------------+
| Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 | | Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 |
| authoritative: | | authoritative: | | authoritative: | | authoritative: |
| 2001:db8:0100::/40 | | 2001:db8:0500::/40 | | 2001:db8:0100::/40 | | 2001:db8:0500::/40 |
| site1: 2001:db8:0103::/48| +---------------------------+ | site1: 2001:db8:0103::/48| +---------------------------+
| site2: 2001:db8:0104::/48| | | | site2: 2001:db8:0104::/48| | |
skipping to change at page 31, line 25 skipping to change at page 34, line 16
This section specifies the DDT security architecture that provides This section specifies the DDT security architecture that provides
data origin authentication, data integrity protection, and XEID- data origin authentication, data integrity protection, and XEID-
prefix delegation. Global XEID-prefix authorization is out of the prefix delegation. Global XEID-prefix authorization is out of the
scope of this document. scope of this document.
Each DDT node is configured with one or more public/private key Each DDT node is configured with one or more public/private key
pair(s) that are used to digitally sign referral records for XEID- pair(s) that are used to digitally sign referral records for XEID-
prefix(es) that the DDT node is authoritative for. In other words, prefix(es) that the DDT node is authoritative for. In other words,
each public/private key pair is associated with the combination of a each public/private key pair is associated with the combination of a
DDT node and the XEID-prefix that it is authoritative for. Every DDT DDT node and a XEID-prefix that it is authoritative for. Every DDT
node is also configured with the public keys of its children DDT node is also configured with the public keys of its children DDT
nodes. By including public keys of target child DDT nodes in the nodes. By including public keys of target child DDT nodes in the
Map-Referral records, and signing each record with the DDT node's Map-Referral records, and signing each record with the DDT node's
private key, a DDT node can securely delegate sub-prefixes of its private key, a DDT node can securely delegate sub-prefixes of its
authoritative XEID-prefixes to its children DDT nodes. authoritative XEID-prefixes to its children DDT nodes. A DDT node
configured to provide hints must also have the public keys of the DDT
nodes that its hints point to. DDT node keys can be encoded using
LCAF type 11 to associate the key to the RLOC of the referred DDT
node. If a node has more than one public key, it should sign its
records with at least one of these keys. When a node has N keys, it
can sustain up to N-1 key compromises. Revocation mechanism is
described in Section 10.2.1.
Map Resolvers are configured with one or more trusted public keys Map Resolvers are configured with one or more trusted public keys
referred to as trust anchors. Trust anchors are used to authenticate referred to as trust anchors. Trust anchors are used to authenticate
the DDT security infrastructure. Map Resolvers can discover a DDT the DDT security infrastructure. Map Resolvers can discover a DDT
node's public key either by having it configured as a trust anchor, node's public key either by having it configured as a trust anchor,
or by obtaining it from the node's parent as part of a signed Map- or by obtaining it from the node's parent as part of a signed Map-
Referral. When a public key is obtained from a node's parent, it is Referral. When a public key is obtained from a node's parent, it is
considered trusted if it is signed by a trust anchor, or if it is considered trusted if it is signed by a trust anchor, or if it is
signed by a key that was previously trusted. Typically, in a Map signed by a key that was previously trusted. Typically, in a Map
Resolver, the root DDT node public keys should be configured as trust Resolver, the root DDT node public keys should be configured as trust
skipping to change at page 34, line 19 skipping to change at page 37, line 19
o Defining an interface to implement interconnection and/or o Defining an interface to implement interconnection and/or
interoperability with other mapping databases, such as LISP+ALT. interoperability with other mapping databases, such as LISP+ALT.
o Additional key structures for use with LISP-DDT, such as to o Additional key structures for use with LISP-DDT, such as to
support additional EID formats as defined in [I-D.ietf-lisp-lcaf] support additional EID formats as defined in [I-D.ietf-lisp-lcaf]
o Management of the DDT Map Resolver referral cache, in particular, o Management of the DDT Map Resolver referral cache, in particular,
detecting and removing outdated entries. detecting and removing outdated entries.
o Best practices for configuring hint referrals (or vice verse
avoiding using them).
Operational experience will help answer open questions surrounding Operational experience will help answer open questions surrounding
these and other issues. these and other issues.
12. IANA Considerations 12. IANA Considerations
This document makes no request of the IANA. This document makes no request of the IANA.
13. Security Considerations 13. Security Considerations
Section 10 describes a DDT security architecture that provides data Section 10 describes a DDT security architecture that provides data
skipping to change at page 35, line 5 skipping to change at page 38, line 10
protocols. In the future other LISP security mechanisms may be protocols. In the future other LISP security mechanisms may be
developed to replace LISP-SEC. Such future security mechanisms developed to replace LISP-SEC. Such future security mechanisms
should describe how they can be used together with DDT to provide should describe how they can be used together with DDT to provide
similar levels of protection. similar levels of protection.
LISP-SEC can use the DDT public key infrastructure to secure the LISP-SEC can use the DDT public key infrastructure to secure the
transport of LISP-SEC key material (the One-Time Key) from a Map- transport of LISP-SEC key material (the One-Time Key) from a Map-
Resolver to the corresponding Map-Server. For this reason, when Resolver to the corresponding Map-Server. For this reason, when
LISP-SEC is deployed in conjunction with a LISP-DDT mapping database LISP-SEC is deployed in conjunction with a LISP-DDT mapping database
and the path between Map-Resolver and Map-Server needs to be and the path between Map-Resolver and Map-Server needs to be
protected, DDT security should be enabled as well. protected, DDT security as described in Section 10 should be enabled
as well.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-22 (work in
progress), November 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <http://www.rfc-editor.org/info/rfc6830>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, Protocol (LISP) Map-Server Interface", RFC 6833,
DOI 10.17487/RFC6833, January 2013, DOI 10.17487/RFC6833, January 2013,
<http://www.rfc-editor.org/info/rfc6833>. <http://www.rfc-editor.org/info/rfc6833>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-lisp-lcaf] [AFI] "Address Family Identifier (AFIs)", IANA , Febuary 2007,
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical <http://www.iana.org/assignments/address-family-numbers/
Address Format (LCAF)", draft-ietf-lisp-lcaf-13 (work in address-family-numbers.xhtml>.
progress), May 2016.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-10 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12
(work in progress), April 2016. (work in progress), November 2016.
[LISP-TREE] [LISP-TREE]
Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D.,
and O. Bonaventure, "LISP-TREE: a DNS hierarchy to support and O. Bonaventure, "LISP-TREE: a DNS hierarchy to support
the lisp mapping system", Selected Areas in the lisp mapping system", Selected Areas in
Communications, IEEE Journal , 2010, Communications, IEEE Journal , 2010,
<http://ieeexplore.ieee.org/xpls/ <http://ieeexplore.ieee.org/xpls/
abs_all.jsp?arnumber=5586446>. abs_all.jsp?arnumber=5586446>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>. <http://www.rfc-editor.org/info/rfc1918>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <http://www.rfc-editor.org/info/rfc5011>. September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>. February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <http://www.rfc-editor.org/info/rfc6836>. January 2013, <http://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,
<http://www.rfc-editor.org/info/rfc6837>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to express their thanks to Lorand Jakab, The authors would like to express their thanks to Lorand Jakab,
Albert Cabellos-Asparicio, Florin Coras, Damien Saucez, and Olivier Albert Cabellos-Asparicio, Florin Coras, Damien Saucez, and Olivier
Bonaventure for their work on LISP-TREE [LISP-TREE] and LISP iterable Bonaventure for their work on LISP-TREE [LISP-TREE] and LISP iterable
mappings that inspired the hierarchical database structure and lookup mappings that inspired the hierarchical database structure and lookup
iteration approach described in this document. Thanks also go to iteration approach described in this document. Thanks also go to
Dino Farinacci and Isidor Kouvelas for their implementation work; to Dino Farinacci and Isidor Kouvelas for their implementation work; to
Selina Heimlich and Srin Subramanian for testing; to Fabio Maino for Selina Heimlich and Srin Subramanian for testing; to Fabio Maino for
work on security processing; and to Job Snijders, Glen Wiley, Neel work on security processing; and to Job Snijders, Glen Wiley, Neel
 End of changes. 80 change blocks. 
348 lines changed or deleted 488 lines changed or added

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