draft-ietf-lisp-ddt-04.txt   draft-ietf-lisp-ddt-05.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: September 22, 2016 V. Ermagan Expires: October 24, 2016 V. Ermagan
Cisco Systems Cisco Systems
A. Jain A. Jain
Juniper Networks Juniper Networks
March 21, 2016 A. Smirnov
Cisco Systems
April 22, 2016
LISP Delegated Database Tree LISP Delegated Database Tree
draft-ietf-lisp-ddt-04 draft-ietf-lisp-ddt-05
Abstract Abstract
This draft describes the LISP Delegated Database Tree (LISP-DDT), a This draft describes the LISP Delegated Database Tree (LISP-DDT), a
hierarchical, distributed database which embodies the delegation of 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 41 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 September 22, 2016. This Internet-Draft will expire on October 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Database organization . . . . . . . . . . . . . . . . . . . . 6 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
3.1. EID-prefix tree structure and instance IDs . . . . . . . 6 4. Database organization . . . . . . . . . . . . . . . . . . . . 7
3.2. Configuring prefix delegation . . . . . . . . . . . . . . 7 4.1. EID-prefix tree structure and instance IDs . . . . . . . 7
3.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7 4.2. Configuring prefix delegation . . . . . . . . . . . . . . 7
4. The Map-Referral message . . . . . . . . . . . . . . . . . . 7 4.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7
4.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 8 5. DDT Map-Request . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 8 6. The Map-Referral message . . . . . . . . . . . . . . . . . . 8
4.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 9 6.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 9
5. DDT network elements and their operation . . . . . . . . . . 9 6.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 9
5.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 9 6.4. Map-Referral Message Format . . . . . . . . . . . . . . . 10
5.1.2. Missing delegation from an authoritative prefix . . . 10 6.4.1. SIG section . . . . . . . . . . . . . . . . . . . . . 12
5.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 10 7. DDT network elements and their operation . . . . . . . . . . 13
5.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 10 7.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 10 7.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 13
5.3.2. Receiving and following referrals . . . . . . . . . . 11 7.1.2. Missing delegation from an authoritative prefix . . . 14
5.3.3. Handling referral errors . . . . . . . . . . . . . . 13 7.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 14
5.3.4. Referral loop detection . . . . . . . . . . . . . . . 13 7.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 14
6. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 14 7.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 15
6.1. Map Resolver processing of ITR Map-Request . . . . . . . 14 7.3.2. Receiving and following referrals . . . . . . . . . . 15
6.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 14 7.3.3. Handling referral errors . . . . . . . . . . . . . . 17
6.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 14 7.3.4. Referral loop detection . . . . . . . . . . . . . . . 17
6.2. Map Resolver processing of Map-Referral message . . . . . 15 8. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 18
6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 15 8.1. Map Resolver processing of ITR Map-Request . . . . . . . 18
6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 17 8.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 18
6.3. DDT Node processing of DDT Map-Request message . . . . . 19 8.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 19
6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 8.2. Map Resolver processing of Map-Referral message . . . . . 19
6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 19 8.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19
7. Example topology and request/referral following . . . . . . . 20 8.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 21
7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 22 8.3. DDT Node processing of DDT Map-Request message . . . . . 23
7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . 23 8.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 23
7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 24 8.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 24
7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . 24 9. Example topology and request/referral following . . . . . . . 24
7.5. Lookup of 10.16.0.1/32 (non-existent EID) by ITR2 . . . . 25 9.1. Lookup of 2001:db8:0103:1::1/128 . . . . . . . . . . . . 26
8. Securing the database and message exchanges . . . . . . . . . 25 9.2. Lookup of 2001:db8:0501:8:4::1/128 . . . . . . . . . . . 27
8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 26 9.3. Lookup of 2001:db8:0104:2::2/128 . . . . . . . . . . . . 28
8.2. DDT node operation . . . . . . . . . . . . . . . . . . . 26 9.4. Lookup of 2001:db8:0500:2:4::1/128 . . . . . . . . . . . 29
8.2.1. DDT public key revocation . . . . . . . . . . . . . . 27 9.5. Lookup of 2001:db8:0500::1/128 (non-existent EID) . . . . 29
8.3. Map Server operation . . . . . . . . . . . . . . . . . . 27 10. Securing the database and message exchanges . . . . . . . . . 30
8.4. Map Resolver operation . . . . . . . . . . . . . . . . . 27 10.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 30
9. Open Issues and Considerations . . . . . . . . . . . . . . . 28 10.2. DDT node operation . . . . . . . . . . . . . . . . . . . 31
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10.2.1. DDT public key revocation . . . . . . . . . . . . . 31
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 10.3. Map Server operation . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.4. Map Resolver operation . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 29 11. Open Issues and Considerations . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . 30 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31 13. Security Considerations . . . . . . . . . . . . . . . . . . . 33
Appendix B. Map-Referral Message Format . . . . . . . . . . . . 31 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 33 14.1. Normative References . . . . . . . . . . . . . . . . . . 34
Appendix C. Encapsulated Control Message Format . . . . . . . . 34 14.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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:
relatively static Endpoint Identifiers (EIDs), used end-to-end for relatively static Endpoint Identifiers (EIDs), used end-to-end for
terminating transport-layer associations, and Routing Locators terminating transport-layer associations, and Routing Locators
(RLOCs), which are more dynamic, are bound to topological location, (RLOCs), which are more dynamic, are bound to topological location,
and are used for routing and forwarding through the Internet and are used for routing and forwarding through the Internet
infrastructure. infrastructure.
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, 24-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 term "Extended EID" (XEID) is also used for an individual LISP
EID that is further qualified through the use of an Instance ID. See
[LCAF] for further discussion of the use of Instance IDs.
The DBID is provided for possible use in case a need evolves for The DBID is provided for possible use in case a need evolves for
another, higher level in the hierarchy, to allow the creation of another, higher level in the hierarchy, to allow the creation of
multiple, separate database trees. multiple, separate database trees.
LISP-DDT is a hierarchical distributed database, which embodies the LISP-DDT is a hierarchical distributed database, which embodies the
delegation of authority to provide mappings, i.e. its internal delegation of authority to provide mappings, i.e. its internal
structure mirrors the hierarchical delegation of address space. It structure mirrors the hierarchical delegation of address space. It
also provides delegation information to Map Resolvers, which use the also provides delegation information to Map Resolvers, which use the
information to locate EID-to-RLOC mappings. A Map Resolver, which information to locate EID-to-RLOC mappings. A Map Resolver, which
needs to locate a given mapping, will follow a path through the tree- needs to locate a given mapping, will follow a path through the tree-
skipping to change at page 4, line 28 skipping to change at page 4, line 27
to another DDT node in the database tree that further delegates the to another DDT node in the database tree that further delegates the
sub-prefix. See [RFC6833] for a description of the functionality of sub-prefix. See [RFC6833] for a description of the functionality of
the Map Server and Map Resolver. Note that the target of a the Map Server and Map Resolver. Note that the target of a
delegation must always be an RLOC (not an EID) to avoid any circular delegation must always be an 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 4 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-
Referral message that either indicates that it will find the Referral message that either indicates that it will find the
requested mapping to complete processing of the request or that the requested mapping to complete processing of the request or that the
DDT client should contact another DDT node that has more-specific DDT client should contact another DDT node that has more-specific
information; in the latter case, the DDT node then sends a new information; in the latter case, the DDT node then sends a new
Encapsulated Map-Request to the next DDT node and the process repeats Encapsulated Map-Request to the next DDT node and the process repeats
in an iterative manner. in an iterative manner.
Conceptually, this is similar to the way that a client of the Domain Conceptually, this is similar to the way that a client of the Domain
Name System (DNS) follows referrals (DNS responses that contain only Name System (DNS) follows referrals (DNS responses that contain only
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. Definition of Terms 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Definition of Terms
Extended EID (XEID): a LISP EID, optionally extended with a non- Extended EID (XEID): a LISP EID, optionally extended with a non-
zero Instance ID (IID) if the EID is intended for use in a context zero Instance ID (IID) if the EID is intended for use in a context
where it may not be a unique value, such as on a Virtual Private where it may not be a unique value, such as on a Virtual Private
Network where [RFC1918] address space is used. See "Using Network where [RFC1918] address space is used. See "Using
Virtualization and Segmentation with LISP" in [RFC6830] for more Virtualization and Segmentation with LISP" in [RFC6830] for more
discussion of Instance IDs. discussion of Instance IDs.
XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided
to allow the definition of multiple databases; currently always to allow the definition of multiple databases; currently always
zero in this version of DDT, with other values reserved for future zero in this version of DDT, with other values reserved for future
use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used use), 24-bit IID and 16-bit AFI prepended. An XEID-prefix is used
as a key index into the database. as a key index into 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 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 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 but it is also possible for an ITR to implement DDT client
skipping to change at page 5, line 35 skipping to change at page 5, line 44
DDT Map Resolver: a network infrastructure element that accepts a DDT Map Resolver: a network infrastructure element that accepts a
Map-Request, adds the XEID to its pending request list, then Map-Request, adds the XEID to its pending request list, then
queries one or more DDT nodes for the requested EID, following queries one or more DDT nodes for the requested EID, following
returned referrals until it receives one with action code MS-ACK returned referrals until it receives one with action code MS-ACK
(or an error indication). MS-ACK indicates that the Map-Request (or an error indication). MS-ACK indicates that the Map-Request
has been sent to a Map Server that will forward it to an ETR that, 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 in turn, will provide a Map-Reply to the original sender. A DDT
Map Resolver maintains both a cache of Map-Referral message Map Resolver maintains both a cache of Map-Referral message
results containing RLOCs for DDT nodes responsible for XEID- results containing RLOCs for DDT nodes responsible for XEID-
prefixes of interest (termed the "referral cache") a pending prefixes of interest (termed the "referral cache") and a pending
request list of XEIDs that are being resolved through iterative request list of XEIDs that are being resolved through iterative
querying of DDT nodes. querying of DDT nodes.
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
a DDT node. The "DDT-originated" flag is set in the encapsulation a DDT node. The "DDT-originated" flag is set in the encapsulation
header indicating that the DDT node should return Map-Referral header indicating that the DDT node should return Map-Referral
messages if the Map-Request EID matches a delegated XEID-prefix messages if the Map-Request EID matches a delegated XEID-prefix
known to the DDT node. Section 5.3.1 describes how DDT Map- known to the DDT node. Section 7.3.1 describes how DDT Map-
Requests are sent. Requests are sent. Section 5 defines position of the "DDT-
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 more information about the
sub-prefix; a DDT client "follows the referral" by sending another sub-prefix; a DDT client "follows the referral" by sending another
DDT Map-Request to one of those RLOCs to obtain either an answer DDT Map-Request to one of those RLOCs to obtain either an answer
or another referral to DDT nodes responsible for a more-specific or another referral to DDT nodes responsible for a more-specific
XEID-prefix. See Section 5.1 and Section 5.3.2 for details on the XEID-prefix. See Section 7.1 and Section 7.3.2 for details on the
sending and processing of Map-Referral messages. sending and processing of Map-Referral messages.
negative Map-Referral: a Map-Referral sent in response to a DDT Map- Negative Map-Referral: a Map-Referral sent in response to a DDT Map-
Request that matches an authoritative XEID-prefix but for which Request that matches an authoritative XEID-prefix but for which
there is no delegation configured (or no ETR registration if sent there is no delegation configured (or no ETR registration if sent
by a DDT Map-Server). 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 a DDT
client for an XEID. Each entry in the list contains additional client for an XEID. Each entry in the list contains additional
state needed by the referral following process, including the state needed by the referral following process, including the
requestor(s) of the XEID (typically, one or more ITRs), saved requestor(s) of the XEID (typically, one or more ITRs), saved
information about the last referral received and followed information about the last referral received and followed
(matching XEID-prefix, action code, RLOC set, index of last RLOC (matching XEID-prefix, action code, RLOC set, index of last RLOC
queried in the RLOC set), and any [LISP-SEC] information that was queried in the RLOC set), and any LISP-SEC information
included in the DDT client Map-Request. An entry in the list may ([I-D.ietf-lisp-sec]) that was included in the DDT client Map-
be interchangeably termed a "pending request list entry" or simply Request. An entry in the list may be interchangeably termed a
a "pending request". "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].
3. Database organization 4. Database organization
3.1. EID-prefix tree structure and instance IDs 4.1. EID-prefix tree structure and instance IDs
LISP-DDT defines a tree structure that is indexed by a binary LISP-DDT defines a tree structure that is indexed by a binary
encoding of five fields, in order of significance: DBID (16 bits), encoding of five fields, in order of significance: DBID (16 bits),
Instance Identifier (IID, 32 bits), Address Family Identifier (AFI, Instance Identifier (IID, 24 bits), Address Family Identifier (AFI,
16 bits), and EID-prefix (variable, according to AFI value). The 16 bits), and EID-prefix (variable, according to AFI value). The
fields are concatenated, with the most significant fields as listed fields are concatenated, with the most significant fields as listed
above. The index into this structure is also referred to as an above. The index into this structure is also referred to as an
Extended EID-prefix (XEID-prefix). Extended EID-prefix (XEID-prefix).
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 (Map Servers and their registered EIDs) that can be
queried with LISP to obtain those mappings. Changes to EID-to-RLOC queried with LISP to obtain those mappings. Changes to EID-to-RLOC
mappings are made on the ETRs which define them, not to any DDT node mappings are made on the ETRs which define them, not to any DDT node
configuration. DDT node configuration changes are only required when configuration. DDT node configuration changes are only required when
branches of the database hierarchy are added, removed, or modified. branches of the database hierarchy are added, removed, or modified.
3.2. Configuring prefix delegation 4.2. 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
Those RLOCs are returned in Map-Referral messages when the DDT node (for details of security infomation exchange and its use see
receives a DDT Map-Request with an xEID that matches a delegation. A Section 10). Those RLOCs are returned in Map-Referral messages when
DDT Map Server will also have a set of sub-prefixes for which it the DDT node receives a DDT Map-Request with an XEID that matches a
accepts ETR mapping registrations and for which it will forward (or delegation. A DDT Map Server will also have a set of sub-prefixes
answer, if it provides proxy Map-Reply service) Map-Requests. For for which it accepts ETR mapping registrations and for which it will
details of security infomation in Map-Referrals see Section 8. forward (or answer, if it provides proxy Map-Reply service) Map-
Requests.
3.2.1. The root DDT node 4.2.1. The root DDT node
The root DDT node is the logical "top" of the database hierarchy: The root DDT node is the logical "top" of the database hierarchy:
DBID=0, IID=0, AFI=0, EID-prefix=0/0. A DDT Map-Request that matches 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. The no configured XEID-prefix will be referred to the root node. The
root node in a particular instantiation of LISP-DDT must therefore be root node in a particular instantiation of LISP-DDT must therefore be
configured with delegations for at least all defined IIDs and AFIs. configured with delegations for at least all defined IIDs and AFIs.
To aid in defining a "sub-root" DDT node that is responsible for all 5. DDT Map-Request
EID-prefixes within multiple IIDs (say, for using LISP to create
virtual networks that use overlapping address space), it may be
useful to implement configuration language that allows for a range of
IIDs to be delegated together. Additional configuration shorthand
for delegating a range of IIDs (and all of the EIDs under them) may
also be helpful.
4. The Map-Referral message 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
is defined by [RFC6830]. This specification adds to ECM flag "DDT-
originated".
A Map-Referral message is sent by a DDT node to a DDT client in 0 1 2 3
response to a DDT Map-Request message. The message consists of an 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
action code along with delegation information about the XEID-prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
that matches the XEID requested. / | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LH |Type=8 |S|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See Appendix B for a detailed layout of the Map-Referral message D-bit is the "DDT-originated" flag and is set by a DDT client to
fields. indicate that the receiver SHOULD return Map-Referral messages as
appropriate. Use of the flag is further described in Section 7.3.1.
4.1. Action codes 6. The Map-Referral message
This specification defines a new LISP message, the Map-Referral. It
is sent by a DDT node to a DDT client in response to a DDT Map-
Request message. See Section 6.4 for a detailed layout of the Map-
Referral message fields.
The message consists of an action code along with delegation
information about the XEID-prefix that matches the requested XEID.
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 Map Resolver 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 5.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 a replying DDT Map Server received a DDT
Map-Request that matches an authoritative XEID-prefix for which is Map-Request that matches an authoritative XEID-prefix for which it
has one or more registered ETRs. This means that the request can has one or more registered ETRs. This means that the request has
be forwarded to one of those ETRs to provide an answer to the been forwarded to one of those ETRs to provide an answer to the
querying ITR. 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 5.1.2 for details. See Section 7.1.2 for details.
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-request for which it is not
authoritative. This can occur if a cached referral has become authoritative. This can occur if a cached referral has become
invalid due to a change in the database hierarchy. invalid due to a change in the database hierarchy.
4.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 includes in the Map-Referral message a list of RLOCs for all DDT node includes in the Map-Referral message a list of RLOCs for all
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 Map Resolver uses this information to contact one of those DDT
nodes as it "follows" a referral. nodes as it "follows" a referral.
4.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 Map
Resolver from caching a referral with incomplete information. A DDT Resolver 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 does
not have configuration for other "peer" DDT nodes that are also not have configuration for other "peer" DDT nodes that are also
authoritative for the matched XEID-prefix. authoritative for the matched XEID-prefix.
o If it is setting action code NOT-AUTHORITATIVE. o If it is setting action code NOT-AUTHORITATIVE.
5. DDT network elements and their operation 6.4. Map-Referral Message Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=6 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Referral Count| EID mask-len | ACT |A|I| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c |SigCnt | Map Version Number | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix ... |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| e | Unused Flags |L|p|R| Loc/LCAF-AFI |
| f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~ Sig section ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Map-Referral is LISP message type 6.
ACT: The "action" field of the mapping record in a Map-Referral
message encodes 6 action types. The values for the action types are:
NODE-REFERRAL (0): Sent by a DDT node with a child delegation, which
is authoritative for the EID.
MS-REFERRAL (1): Sent by a DDT node that has information about Map
Server(s) for the EID but it is not one of the Map Servers listed,
i.e. the DDT-Node sending the referral is not a Map Server.
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
locators is incomplete and the receiver of this message SHOULD NOT
cache the referral. A DDT sets the "incomplete" flag, the TTL, and
the Action Type field as follows:
-------------------------------------------------------------------
Type (Action field) Incomplete Referral-set TTL values
-------------------------------------------------------------------
0 NODE-REFERRAL NO YES 1440
1 MS-REFERRAL NO YES 1440
2 MS-ACK * * 1440
3 MS-NOT-REGISTERED * * 1
4 DELEGATION-HOLE NO NO 15
5 NOT-AUTHORITATIVE YES NO 0
-------------------------------------------------------------------
*: The "Incomplete" flag setting on Map Server originated referral of
MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map
Server has the full peer Map Server configuration for the same
prefix and has encoded the information in the mapping record.
Incomplete bit is not set when the Map Server has encoded the
information, which means the referral-set includes all the RLOCs
of all Map Servers that serve the prefix. It is set when the Map
Server has not encoded the Map Server set information.
SigCnt: Indicates the number of signatures (sig section) present in
the Record. If SigCnt is larger than 0, the signature information
captured in a sig section as described in Section 6.4.1 will be
appended to the end of the record. The number of sig sections at the
end of the Record must match the SigCnt.
Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the
record. If this is a LCAF AFI, the contents of the LCAF depend on
the Type field of the LCAF. Security material are stored in LCAF
Type 11. DDT nodes and Map Servers can use this LCAF Type to include
public keys associated with their Child DDT nodes for a XEID-prefix
referral record. LCAF types and formats are defined in
[I-D.ietf-lisp-lcaf].
All other fields and their descriptions are equivalent to those in
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
result of the referral not the RLOCs for an actual EID-to-RLOC
mapping.
6.4.1. SIG section
If SigCnt field in the Map-Referral is not 0, the signature
information is included at the end of captured in a sig section as
described below. SigCnt counts the number of sig sections that
appear at the end of the Record.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| Original Record TTL |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Signature Expiration |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s | Signature Inception |
i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
g | Key Tag | Sig Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Sig-Algorithm | Reserved | Reserved |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ~ Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Original Record TTL: The original Record TTL for this record that is
covered by the signature. Record TTL is in minutes.
Signature Expiration and Inception: Specify the validity period for
the signature. The signature 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
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
order.
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.
Sig Length: The length of the Signature field.
Sig-Algorithm: The identifier of the cryptographic algorithm used for
the signature. This specification defines only one algorithm: Sig-
Algorithm type 1 is RSA-SHA1 (see [RFC3447]).
Reserved: This field must be set to 0 on transmit and must be ignored
on receipt.
Signature: Contains the cryptographic signature that covers the
entire record. The Record TTL and the sig fields are set to zero for
the purpose of computing the Signature.
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.
5.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:
5.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 8 for details on security). If the delegation is known to be Section 10 for details on security). If the delegation is known to
a DDT Map Server, then the Map-Referral message is sent with action be a DDT Map Server, then the Map-Referral message is sent with
code MS-REFERRAL to indicate to the receiver that LISP-SEC action code MS-REFERRAL to indicate to the receiver that LISP-SEC
information (if saved in the pending request) should be included in information (if saved in the pending request) should be included in
the next DDT Map-Request; otherwise, the action code NODE-REFERRAL is the next DDT Map-Request; otherwise, the action code NODE-REFERRAL is
used. 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.
5.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 returns a match an authoritative XEID-prefix, then the DDT node returns 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 or
an authoritative XEID-prefix, then the request is dropped and a an authoritative XEID-prefix, then the request is dropped and a
negative Map-Referral with action code NOT-AUTHORITATIVE is returned. negative Map-Referral with action code NOT-AUTHORITATIVE is returned.
5.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 is Reply service) and a Map-Referral with the MS-ACK action is
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 is returned to the sender of with action code MS-NOT-REGISTERED is returned to the sender of
the DDT Map-Request. the DDT Map-Request.
5.3. DDT Map Resolver 7.3. DDT Map Resolver
Just as any other Map Resolver, a DDT Map Resolver accepts Map- Just as any other Map Resolver, a DDT Map Resolver accepts Map-
Requests from its clients (typically, ITRs) and ensures that those Requests from its clients (typically, ITRs) and ensures that those
Map-Requests are forwarded to the correct ETR, which generates Map- Map-Requests are forwarded to the correct ETR, which generates Map-
Replies. Unlike a Map Resolver that uses the ALT mapping system (see Replies. Unlike a Map Resolver that uses the ALT mapping system (see
[RFC6836]), however, a DDT Map Resolver uses an iterative process of [RFC6836]), however, a DDT Map Resolver uses an iterative process of
following referrals to find the correct ETR to answer a Map-Request; following referrals to find the correct ETR to answer a Map-Request;
this requires a DDT Map Resolver to maintain additional state: a Map- this requires a DDT Map Resolver to maintain additional state: a Map-
Referral cache and pending request list of XEIDs that are going Referral cache and pending request list of XEIDs that are going
through the iterative referral process. through the iterative referral process.
5.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 Map Resolver receives an encapsulated Map-Request, it
first performs a longest-match search for the XEID in its referral first performs a longest-match search for the XEID in its referral
cache. If no match is found or if a negative cache entry is found, cache. If no match is found or if a negative cache entry is found,
then the destination is not in the database; a negative Map-Reply is then the destination is not in the database; a negative Map-Reply is
returned and no further processing is performed by the DDT Map returned and no further processing is performed by the DDT Map
Resolver. Resolver.
If a match is found, the DDT Map Resolver creates a pending request If a match is found, the DDT Map Resolver creates a pending request
list entry for the XEID and saves the original Map-Request (minus the list entry for the XEID and saves the original Map-Request (minus the
skipping to change at page 11, line 34 skipping to change at page 15, line 47
configured initial referral cache for a DDT Map Resolver should configured initial referral cache for a DDT Map Resolver should
include a "default" entry with RLOCs for one or more DDT nodes that include a "default" entry with RLOCs for one or more DDT nodes that
can reach the DDT root node. If a Map Resolver does not have such can reach the DDT root node. If a Map Resolver does not have such
configuration, it will return a Negative Map-Reply if it receives a configuration, it will return a Negative Map-Reply if it receives a
query for an EID outside the subset of the mapping database known to query for an EID outside the subset of the mapping database known to
it. While this may be desirable on private network deployments or it. While this may be desirable on private network deployments or
during early transition to LISP when few sites are using it, this during early transition to LISP when few sites are using it, this
behavior is not appropriate when LISP is in general use on the behavior is not appropriate when LISP is in general use on the
Internet. Internet.
5.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 Map Resolver expects to
receive a Map-Referral response. If none occurs within the timeout receive a Map-Referral response. If none occurs within the timeout
period, the DDT Map Resolver retransmits the request, sending to the period, the DDT Map Resolver retransmits the request, sending to the
next RLOC in the referral cache entry if one is available. If the next RLOC in the referral cache entry if one is available. If the
maximum number of retransmissions has occurred and all RLOCs have maximum number of retransmissions has occurred and all RLOCs have
been tried, then the pending request list entry is dequeued. been tried, then the pending request list entry is dequeued.
A DDT Map Resolver processes a received Map-Referral message A DDT Map Resolver processes a received Map-Referral message
according to each action code: according to each action code:
NODE-REFERRAL: The DDT Map Resolver checks for a possible referral NODE-REFERRAL: The DDT Map Resolver checks for a possible referral
loop as as described in Section 5.3.4. If no loop is found, the loop as as described in Section 7.3.4. If no loop is found, the
DDT Map Resolver saves the prefix returned in the Map-Referral DDT Map Resolver saves the prefix returned in the Map-Referral
message in the referral cache, updates the saved prefix and saved message in the referral cache, updates the saved prefix and saved
RLOCs in the pending request list entry, and follows the referral RLOCs in the pending request list entry, and follows the referral
by sending a new DDT Map-Request to one of the DDT node RLOCs by sending a new DDT Map-Request to one of the DDT node RLOCs
listed in the Referral Set; security information saved with the listed in the Referral Set; security information saved with the
original Map-Request is not included. original Map-Request is not included.
MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same
manner as a NODE-REFERRAL except that that security information manner as a NODE-REFERRAL except that that security information
saved with the original Map-Request is included in the new Map- saved with the original Map-Request is included in the new Map-
Request sent to a Map Server (see Section 8 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. If the pending request did not include saved LISP-SEC XEID. If the pending request did not include saved LISP-SEC
information or if that information was already included in the information or if that information was already included in the
previous DDT Map-Request (sent by the DDT Map Resolver in response previous DDT Map-Request (sent by the DDT Map Resolver in response
to either an MS-REFERRAL or a previous MS-ACK referral), then the to either an MS-REFERRAL or a previous MS-ACK referral), then the
pending request for the XEID is complete and is dequeued. pending request for the XEID is complete and is dequeued.
Otherwise, LISP-SEC information is required and has not yet been Otherwise, LISP-SEC information is required and has not yet been
skipping to change at page 13, line 5 skipping to change at page 17, line 19
Reply will indicate the least-specific XEID-prefix matching the Reply will indicate the least-specific XEID-prefix matching the
requested XEID for which no delegations exist and will have a TTL requested XEID for which no delegations exist and will have a TTL
value of 15 minutes. A negative referral cache entry is created value of 15 minutes. A negative referral cache entry is created
for the prefix (also with TTL of 15 minutes) and the pending for the prefix (also with TTL of 15 minutes) and the pending
request is dequeued. request is dequeued.
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 Map Resolver receiving this message can determine that it is
using old cached information, it may choose to delete that cached using 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 was not to 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 list entry that caused this answer is error. The pending request list entry that caused this answer is
removed, with no answer returned to the original requestor. removed, with no answer returned to the original requestor.
5.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. Map Resolver; they should be considered errors and logged as such.
It is not clear exactly what else the DDT Map Resolver should do in It is not clear exactly what else the DDT Map Resolver should do in
such cases; one possibility is to remove the pending request list such cases; one possibility is to remove the pending request list
entry and send a negative Map-Reply to the original Map-Request entry and send a negative Map-Reply to the original Map-Request
sender. Alternatively, if a DDT Map Resolver detects unexpected sender. Alternatively, if a DDT Map Resolver detects unexpected
behavior by a DDT node, it could mark that node as unusable in its behavior by a DDT node, it could mark that node as unusable in its
referral cache and update the pending request to try a different DDT referral cache and update the pending request to try a different DDT
node if more than one is listed in the referral cache. In any case, node if more than one is listed in the referral cache. In any case,
any prefix contained in a Map-Referral message that causes a referral any prefix contained in a Map-Referral message that causes a referral
error (including a referral loop) is not saved in the DDT Map- error (including a referral loop) is not saved in the DDT Map-
Resolver referral cache. Resolver referral cache.
5.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 Map Resolver is directed to query a new set of
DDT node RLOCs that are expected to have more-specific XEID-prefix DDT 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 Map Resolver saves the last
received referral XEID-prefix for each pending request and checks received referral XEID-prefix for each pending request and checks
that a newly received NODE-REFERRAL or MS-REFERRAL message contains a that a newly received NODE-REFERRAL or MS-REFERRAL message contains a
more-specific referral XEID-prefix; an exact or less-specific match more-specific referral XEID-prefix; an exact or less-specific match
of the saved XEID-prefix indicates a referral loop. If a loop is of the saved XEID-prefix indicates a referral loop. If a loop is
detected, the DDT Map Resolver handles the request as described in detected, the DDT Map Resolver handles the request as described in
Section 5.3.3. Otherwise, the Map Resolver saves the most recently Section 7.3.3. Otherwise, the Map Resolver 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 Map Resolver adds an entry to its lookup queue
and sends an initial Map-Request for an XEID, the queue entry has no and 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 Map Resolver 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 Map Resolvers.
6. 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 aid in implementation, each of the major DDT Map Server and DDT
Map Resolver functions are described below, first using simple Map Resolver functions are described below, first using simple
"psuedo-code" and then in the form of a decision tree. "psuedo-code" and then in the form of a decision tree.
6.1. Map Resolver processing of ITR Map-Request 8.1. Map Resolver processing of ITR Map-Request
6.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
} else if ( match type delegation hole ) { } else if ( match type delegation hole ) {
return negative map-reply to ITR return negative map-reply to ITR
} else if ( match type ms-ack ) { } else if ( match type ms-ack ) {
fwd DDT request to map-server fwd DDT request to map-server
} else { } else {
store & fwd DDT request w/o OTK to node delegation store & fwd DDT request w/o security material to node delegation
} }
8.1.2. Decision tree diagram
6.1.2. Decision tree diagram
+------------+ +------------+
| Is Request | Yes | Is Request | Yes
| |----> Replace old request with | |----> Replace old request with
| Pending? | new nonce for future requests | Pending? | new nonce for future requests
+------------+ +------------+
| |
|No |No
| |
V V
+------------+ +------------+
skipping to change at page 15, line 40 skipping to change at page 19, line 43
V V
+------------+ +------------+
| Match Type | Yes | Match Type | Yes
| MS-ACK? |----> Forward DDT Map-request to Map-Server | MS-ACK? |----> Forward DDT Map-request to Map-Server
| | | |
+------------+ +------------+
| |
|No |No
| |
V V
Store request & Fwd DDT Request w/o OTK Store request & Fwd DDT Request w/o security material
to DDT node delegation to DDT node delegation
6.2. Map Resolver processing of Map-Referral message 8.2. Map Resolver processing of Map-Referral message
6.2.1. Pseudo-code summary 8.2.1. Pseudo-code summary
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 {
goto root send request to root
} }
} }
switch (map_referral_type) { switch (map_referral_type) {
case NOT_AUTHORITATIVE : case NOT_AUTHORITATIVE :
if ( gone through root ) { if ( gone through root ) {
return negative map-reply to ITR return negative map-reply to ITR
} else { } else {
goto root send request to root
} }
case DELEGATION_HOLE: case DELEGATION_HOLE:
cache & send negative map-reply to ITR cache & send negative map-reply to ITR
case MS_REFERRAL: case MS_REFERRAL:
if ( referral equal to last used ) { if ( referral equal to last used ) {
if ( gone through root ) { if ( gone through root ) {
return negative map-reply to ITR return negative map-reply to ITR
} else { } else {
goto root send request to root
} }
} else { } else {
cache & follow the referral cache
follow the referral, include security material
} }
case NODE_REFERRAL: case NODE_REFERRAL:
if ( referral equal to last used ) { if ( referral equal to last used ) {
if ( gone through root ) { if ( gone through root ) {
return negative map-reply to ITR return negative map-reply to ITR
} else { } else {
goto root send request to root
} }
} else { } else {
cache & follow the referral cache
follow the referral, strip security material
} }
case MS_ACKNOWLEDGEMENT: case MS_ACK:
if ( OTK stripped ) { if ( security material stripped ) {
if ( incomplete ) { resend request with security material
resend request with OTK if { !incomplete } {
} else { cache
cache & resend request with OTK
} }
} }
case MS_NOT_REGISTERED: case MS_NOT_REGISTERED:
if { all map-server delegations not tried } { if { all map-server delegations not tried } {
follow delegations not tried follow delegations not tried
if ( !incomplete ) { if ( !incomplete ) {
cache cache
} }
} else { } else {
send negative map-reply to ITR send negative map-reply to ITR
if { !incomplete } { if { !incomplete } {
cache cache
} }
} }
case DEFAULT: case DEFAULT:
skipping to change at page 17, line 22 skipping to change at page 21, line 23
} }
} else { } else {
send negative map-reply to ITR send negative map-reply to ITR
if { !incomplete } { if { !incomplete } {
cache cache
} }
} }
case DEFAULT: case DEFAULT:
drop drop
} }
} }
6.2.2. Decision tree diagram 8.2.2. Decision tree diagram
+------------+ +------------+
| 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 18, line 25 skipping to change at page 22, line 25
+---------------------------------------------------+ +---------------------------------------------------+
| What is Map-Referral Type? |--UNKNOWN-+ | What is Map-Referral Type? |--UNKNOWN-+
+---------------------------------------------------+ | +---------------------------------------------------+ |
| | | | | | V | | | | | | V
| | | | | DEL_HOLE DROP | | | | | DEL_HOLE DROP
| | | | MS_ACK | | | | | MS_ACK |
| | | | | V | | | | | V
| | MS_REF NODE_REF | Cache & return | | MS_REF NODE_REF | Cache & return
| | | | V negative map-reply | | | | V negative map-reply
| | | | +---------+ | | | | +---------+
| NOT_AUTH | | | Was OTK | Yes | NOT_AUTH | | | Was sec | Yes
| | | | | material|
| | | | |Stripped?|----> Done | | | | |Stripped?|----> Done
| | V V +---------+ | | V V +---------+
| | +------------+ | No | | +------------+ | No
| | Yes | Pfx equal | V | | Yes | Pfx equal | V
MS_NOT_REGISTERED | +---| to last | +------------+ MS_NOT_REGISTERED | +---| to last | +------------+
| | | | used? | | Incomplete | Yes | | | | used? | | Incomplete | Yes
| | | +------------+ | bit set? |---> Resend DDT | | | +------------+ | bit set? |---> Resend DDT
| V V |No +------------+ request | V V |No +------------+ request w
| +------------+ | |No with OTK | +------------+ | |No security
| | Gone | V | | | Gone | V | material
| | Through | Cache & follow V | | Through | Cache & follow V
| | Root? | the referral Cache & resend DDT | | Root? | the referral Cache & resend DDT
| +------------+ request with OTK | +------------+ request with
| |No |Yes | |No |Yes security material
| | | | | |
| V V | V V
| Goto root Send negative map-reply | Send req Send negative map-reply
| to root
V V
+-----------+ Yes +-----------+ Yes +-----------+ Yes +-----------+ Yes
| Other MS |----Follow other MS-------->|Incomplete |----> Don't cache | Other MS |----Follow other MS-------->|Incomplete |----> Don't cache
| not tried?| |bit set? | | not tried?| |bit set? |
| |---Send negative map-reply->| |----> Cache | |---Send negative map-reply->| |----> Cache
+-----------+ No +-----------+ No +-----------+ No +-----------+ No
6.3. DDT Node processing of DDT Map-Request message 8.3. DDT Node processing of DDT Map-Request message
6.3.1. Pseudo-code summary 8.3.1. Pseudo-code summary
if ( I am not authoritative ) { if ( I am not authoritative ) {
send map-referral NOT_AUTHORITATIVE with send map-referral NOT_AUTHORITATIVE with
incomplete bit set and ttl 0 incomplete bit set and ttl 0
} else if ( delegation exists ) { } else if ( delegation exists ) {
if ( delegated map-servers ) { if ( delegated map-servers ) {
send map-referral MS_REFERRAL with send map-referral MS_REFERRAL with
ttl 'Default_DdtNode_Ttl' ttl 'Default_DdtNode_Ttl'
} else { } else {
send map-referral NODE_REFERRAL with send map-referral NODE_REFERRAL with
ttl 'Default_DdtNode_Ttl' ttl 'Default_DdtNode_Ttl'
} }
} else { } else {
if ( eid in site) { if ( eid in site) {
if ( site registered ) { if ( site registered ) {
forward map-request to etr forward map-request to etr
if ( map-server peers configured ) { if ( map-server peers configured ) {
send map-referral MS_ACKNOWLEDGEMENT with send map-referral MS_ACK with
ttl 'Default_Registered_Ttl' ttl 'Default_Registered_Ttl'
} else { } else {
send map-referral MS_ACKNOWLEDGEMENT with send map-referral MS_ACK with
ttl 'Default_Registered_Ttl' and incomplete bit set ttl 'Default_Registered_Ttl' and incomplete bit set
} }
} else { } else {
if ( map-server peers configured ) { if ( map-server peers configured ) {
send map-referral MS_NOT_REGISTERED with send map-referral MS_NOT_REGISTERED with
ttl 'Default_Configured_Not_Registered_Ttl' ttl 'Default_Configured_Not_Registered_Ttl'
} else { } else {
send map-referral MS_NOT_REGISTERED with send map-referral MS_NOT_REGISTERED with
ttl 'Default_Configured_Not_Registered_Ttl' ttl 'Default_Configured_Not_Registered_Ttl'
and incomplete bit set and incomplete bit set
} }
} }
} else { } else {
send map-referral DELEGATION_HOLE with send map-referral DELEGATION_HOLE with
ttl 'Default_Negative_Referral_Ttl' ttl 'Default_Negative_Referral_Ttl'
} }
} }
6.3.2. Decision tree diagram where architectural constants for TTL are set as follows:
Default_DdtNode_Ttl 1440 minutes
Default_Registered_Ttl 1440 minutes
Default_Negative_Referral_Ttl 15 minutes
Default_Configured_Not_Registered_Ttl 1 minute
8.3.2. Decision tree diagram
+------------+ +------------+
| Am I | No | Am I | No
| Authori- |----> Return NOT_AUTHORITATIVE | Authori- |----> Return NOT_AUTHORITATIVE
| tative? | Incomplete = 1 | tative? | Incomplete = 1
+------------+ ttl = Default_DdtNode_Ttl +------------+ ttl = Default_DdtNode_Ttl
| |
|Yes |Yes
| |
V V
+------------+ +------------+ +------------+ +------------+
skipping to change at page 20, line 45 skipping to change at page 24, line 48
| | peers |----> Return MS_NOT_REGISTERED | | peers |----> Return MS_NOT_REGISTERED
| | configured?| ttl = Default_Negative_Referral_Ttl | | configured?| ttl = Default_Negative_Referral_Ttl
| +------------+ | +------------+
| \ No | \ No
|No +--> Return MS_NOT_REGISTERED |No +--> Return MS_NOT_REGISTERED
| Incomplete = 1 | Incomplete = 1
V ttl = Default_Negative_Referral_Ttl V ttl = Default_Negative_Referral_Ttl
Return DELEGATION_HOLE Return DELEGATION_HOLE
ttl = Default_Negative_Referral_Ttl ttl = Default_Negative_Referral_Ttl
7. Example topology and request/referral following 9. Example topology and request/referral following
This chapter shows example DDT tree and several possible scenarios of
Map-Requests coming to a Map Resolver and subsequent iterative DDT
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
of hierarchical delegation and pinpointing referrals is equally
applicable to any AF whose address hierarchy can be expressed as a
bitstring with associated length. DDT tree of IPv4 prefixes is
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=1, 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/0 | | authoritative: 0/0 | | authoritative: ::/0 | | authoritative: ::/0 |
+---------------------+ +---------------------+ +---------------------+ +---------------------+
| \ / | | \ / |
| \ / | | \ / |
| / \ | | / \ |
| / \ | | / \ |
| | | | | | | |
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: 10.0.0.0/8| | authoritative: 10.0.0.0/8| | authoritative: | | authoritative: |
+--------------------------+ +--------------------------+ | 2001:db8::/32 | | 2001:db8::/32 |
+-------------------------+ +--------------------------+
| \ / | | \ / |
| \ / | | \ / |
| / \ | | / \ |
| / \ | | / \ |
| | | | | | | |
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: 10.0.0.0/12| |authoritative: 10.16.0.0/12| | authoritative: | | authoritative: |
| site1: 10.1.0.0/16 | +---------------------------+ | 2001:db8:0100::/40 | | 2001:db8:0500::/40 |
| site2: 10.2.0.0/16 | | | | site1: 2001:db8:0103::/48| +---------------------------+
| site2: 2001:db8:0104::/48| | |
+--------------------------+ | | +--------------------------+ | |
| | | |
| | | |
V V V V
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
| Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 | | Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 |
|authoritative: 10.16.0.0/16| |authoritative: 10.17.0.0/16| | authoritative: | | authoritative: |
| site3: 10.16.1.0/24 | | site5: 10.17.8.0/24 | | 2001:db8:0500::/48 | | 2001:db8:0501::/48 |
| site4: 10.16.2.0/24 | | site6: 10.17.9.0/24 | |site3: 2001:db8:0500:1::/64| |site5: 2001:db8:0501:8::/64|
|site4: 2001:db8:0500:2::/64| |site6: 2001:db8:0501:9::/64|
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
DDT nodes are configured for this "root" at IP addresses 192.0.2.1 DDT nodes are configured for this "root" at IP addresses 192.0.2.1
and 192.0.2.2. DDT Map Resolvers are configured with default and 192.0.2.2. DDT Map Resolvers are configured with default
referral cache entries to these addresses. referral cache entries to these addresses.
The root DDT nodes delegate 10.0.0/8 to two DDT nodes with IP The root DDT nodes delegate 2001:db8::/32 to two DDT nodes with IP
addresses 192.0.2.11 and 192.0.2.12. addresses 192.0.2.11 and 192.0.2.12.
The DDT nodes for 10.0.0.0/8 delegate 10.0.0.0/12 to a DDT Map Server The DDT nodes for 2001:db8::/32 delegate 2001:db8:0100::/40 to a DDT
with RLOC 192.0.2.101 Map Server with RLOC 192.0.2.101
The DDT Map Server for 10.0.0.0/12 is configured to allow ETRs to The DDT Map Server for 2001:db8:0100::/40 is configured to allow ETRs
register the sub-prefixes 10.1.0.0/16 and 10.2.0.0/16 to register the sub-prefixes 2001:db8:0103::/48 and
The DDT nodes for 10.0.0.0/8 also delegate 10.16.0.0/12 to a DDT node 2001:db8:0104::/48
with RLOC 192.0.2.201
The DDT node for 10.16.0.0/12 is further configured to delegate The DDT nodes for 2001:db8::/32 also delegate 2001:db8:0500::/40 to a
10.16.0.0/16 to a DDT Map Server with RLOC 192.0.2.211 and 10.17.0.0/ DDT node with RLOC 192.0.2.201
16 to a DDT Map Server with RLOC 192.0.2.221
The DDT Map Server for 10.16.0.0/16 is configured to allow ETRs to The DDT node for 2001:db8:0500::/40 is further configured to delegate
register the sub-prefixes 10.16.1.0/24 and 10.16.2.0/24 2001:db8:0500::/48 to a DDT Map Server with RLOC 192.0.2.211 and
2001:db8:0501::/48 to a DDT Map Server with RLOC 192.0.2.221
The DDT Map Server for 10.17.0.0/16 is configured to allow ETRs to The DDT Map Server for 2001:db8:0500::/48 is configured to allow ETRs
register the sub-prefixes 10.17.8.0/24 and 10.17.9.0/24 to register the sub-prefixes 2001:db8:0500:1::/64 and
2001:db8:0500:2::/64
7.1. Lookup of 10.1.1.1/32 by ITR1 The DDT Map Server for 2001:db8:0501::/48 is configured to allow ETRs
to register the sub-prefixes 2001:db8:0501:8::/64 and
2001:db8:0501:9::/64
9.1. Lookup of 2001:db8:0103:1::1/128
The first example shows a DDT Map Resolver following a delegation The first example shows a DDT Map Resolver following a delegation
from the root to a DDT node followed by another delegation to a DDT from the root to a DDT node followed by another delegation to a DDT
Map Server. Map Server.
ITR1 sends an Encapsulated Map-Request for 10.1.1.1 to one of its ITR1 sends an Encapsulated Map-Request for 2001:db8:0103:1::1 to one
configured (DDT) Map Resolvers. The DDT Map Resolver proceeds as of its configured (DDT) Map Resolvers. The DDT Map Resolver proceeds
follows: as follows:
1. Send DDT Map-Request (for 10.1.1.1) to one of the root DDT nodes, 1. Send DDT Map-Request (for 2001:db8:0103:1::1) to one of the root
192.0.2.1 or 192.0.2.2 DDT nodes, 192.0.2.1 or 192.0.2.2
2. Receive (and save in referral cache) Map-Referral for EID-prefix 2. Receive (and save in referral cache) Map-Referral for EID-prefix
10.0.0.0/8, action code NODE-REFERRAL, RLOC set (192.0.2.11, 2001:db8::/32, action code NODE-REFERRAL, RLOC set (192.0.2.11,
192.0.2.12) 192.0.2.12)
3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12
4. Receive (and save in referral cache) Map-Referral for EID-prefix 4. Receive (and save in referral cache) Map-Referral for EID-prefix
10.0.0.0/12, action code MS-REFERRAL, RLOC set (192.0.2.101) 2001:db8:0100::/40, action code MS-REFERRAL, RLOC set
(192.0.2.101)
5. Send DDT Map-Request to 192.0.2.101; if the ITR-originated 5. Send DDT Map-Request to 192.0.2.101; if the ITR-originated
Encapsulated Map-Request had a LISP-SEC signature, it is included Encapsulated Map-Request had a LISP-SEC signature, it is included
6. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 6. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request
and forwards to a registered site1 ETR for 10.1.0.0/16 and forwards to a registered site1 ETR for 2001:db8:0103::/48
7. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 7. DDT Map Server at 192.0.2.101 sends a Map-Referral message for
EID-prefix 10.1.0.0/16, action code MS-ACK to the DDT Map EID-prefix 2001:db8:0103::/48, action code MS-ACK to the DDT Map
Resolver Resolver
8. DDT Map Resolver receives Map-Referral message and dequeues the 8. DDT Map Resolver receives Map-Referral message and dequeues the
pending request for 10.1.1.1 pending request for 2001:db8:0103:1::1
9. site1 ETR for 10.1.0.0/16 receives Map-Request forwarded by DDT 9. site1 ETR for 2001:db8:0103::/48 receives Map-Request forwarded
Map Server and sends Map-Reply to ITR1 by DDT Map Server and sends Map-Reply to ITR1
7.2. Lookup of 10.17.8.1/32 by ITR2 9.2. Lookup of 2001:db8:0501:8:4::1/128
The next example shows a three-level delegation: root to first DDT The next example shows a three-level delegation: root to first DDT
node, first DDT node to second DDT node, second DDT node to DDT Map node, first DDT node to second DDT node, second DDT node to DDT Map
Server. Server.
ITR2 sends an Encapsulated Map-Request for 10.17.8.1 to one of its ITR2 sends an Encapsulated Map-Request for 2001:db8:0501:8:4::1 to
configured (DDT) Map Resolvers, which are different from those for one of its configured (DDT) Map Resolvers, which are different from
ITR1. The DDT Map Resolver proceeds as follows: those for ITR1. The DDT Map Resolver proceeds as follows:
1. Send DDT Map-Request (for 10.17.8.1) to one of the root DDT 1. Send DDT Map-Request (for 2001:db8:0501:8:4::1) to one of the
nodes, 192.0.2.1 or 192.0.2.2 root DDT nodes, 192.0.2.1 or 192.0.2.2
2. Receive (and save in referral cache) Map-Referral for EID-prefix 2. Receive (and save in referral cache) Map-Referral for EID-prefix
10.0.0.0/8, action code NODE-REFERRAL, RLOC set (192.0.2.11, 2001:db8::/32, action code NODE-REFERRAL, RLOC set (192.0.2.11,
192.0.2.12) 192.0.2.12)
3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12 3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12
4. Receive (and save in referral cache) Map-Referral for EID-prefix 4. Receive (and save in referral cache) Map-Referral for EID-prefix
10.16.0.0/12, action code NODE-REFERRAL, RLOC set (192.0.2.201) 2001:db8:0500::/40, action code NODE-REFERRAL, RLOC set
5. (192.0.2.201)
5. Send DDT Map-Request to 192.0.2.201 5. Send DDT Map-Request to 192.0.2.201
6. Receive (and save in referral cache) Map-Referral for EID-prefix 6. Receive (and save in referral cache) Map-Referral for EID-prefix
10.17.0.0/16, action code MS-REFERRAL, RLOC set (192.0.2.221) 2001:db8:0501::/48, action code MS-REFERRAL, RLOC set
(192.0.2.221)
7. Send DDT Map-Request to 192.0.2.221; if the ITR-originated 7. Send DDT Map-Request to 192.0.2.221; if the ITR-originated
Encapsulated Map-Request had a LISP-SEC signature, it is Encapsulated Map-Request had a LISP-SEC signature, it is
included included
8. DDT Map Server at 192.0.2.221 decapsulates the DDT Map-Request 8. DDT Map Server at 192.0.2.221 decapsulates the DDT Map-Request
and forwards to a registered site5 ETR for 10.17.8.0/24 and forwards to a registered site5 ETR for 2001:db8:0501:8::/64
9. DDT Map Server at 192.0.2.221 sends a Map-Referral message for 9. DDT Map Server at 192.0.2.221 sends a Map-Referral message for
EID-prefix 10.17.8.0/24, action code MS-ACK, to the DDT Map EID-prefix 2001:db8:0501:8::/64, action code MS-ACK, to the DDT
Resolver Map Resolver
10. DDT Map Resolver receives Map-Referral(MS-ACK) message and 10. DDT Map Resolver receives Map-Referral(MS-ACK) message and
dequeues the pending request for 10.17.8.1 dequeues the pending request for 2001:db8:0501:8:4::1
11. site5 ETR for 10.17.8.0/24 receives Map-Request forwarded by DDT 11. site5 ETR for 2001:db8:0501:8::/64 receives Map-Request
Map Server and sends Map-Reply to ITR2 forwarded by DDT Map Server and sends Map-Reply to ITR2
7.3. Lookup of 10.2.2.2/32 by ITR1 9.3. Lookup of 2001:db8:0104:2::2/128
This example shows how a DDT Map Resolver uses a saved referral cache This example shows how a DDT Map Resolver uses a saved referral cache
entry to skip the referral process and go directly to a DDT Map entry to skip the referral process and go directly to a DDT Map
Server for a prefix that is similar to one previously requested. Server for a prefix that is similar to one previously requested.
In this case, ITR1 uses the same Map Resolver used in example In this case, ITR1 uses the same Map Resolver used in example
Section 7.1. It sends an Encapsulated Map-Request for 10.2.2.2 to Section 9.1. It sends an Encapsulated Map-Request for
that (DDT) Map Resolver. The DDT Map-Resolver finds an MS-REFERRAL 2001:db8:0104:2::2 to that (DDT) Map Resolver. The DDT Map-Resolver
cache entry for 10.0.0.0/12 with RLOC set (192.0.2.101) and proceeds finds an MS-REFERRAL cache entry for 2001:db8:0100::/40 with RLOC set
as follows: (192.0.2.101) and proceeds as follows:
1. Send DDT Map-Request (for 10.2.2.2) to 192.0.2.101; if the ITR- 1. Send DDT Map-Request (for 2001:db8:0104:2::2) to 192.0.2.101; if
originated Encapsulated Map-Request had a LISP-SEC signature, it the ITR-originated Encapsulated Map-Request had a LISP-SEC
is included signature, it is included
2. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request 2. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request
and forwards to a registered site2 ETR for 10.2.0.0/16 and forwards to a registered site2 ETR for 2001:db8:0104::/48
3. DDT Map Server at 192.0.2.101 sends a Map-Referral message for 3. DDT Map Server at 192.0.2.101 sends a Map-Referral message for
EID-prefix 10.2.0.0/16, action code MS-ACK to the DDT Map EID-prefix 2001:db8:0104::/48, action code MS-ACK to the DDT Map
Resolver Resolver
4. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 4. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the
pending request for 10.2.2.2 pending request for 2001:db8:0104:2::2
5. site2 ETR for 10.2.0.0/16 receives Map-Request and sends Map- 5. site2 ETR for 2001:db8:0104::/48 receives Map-Request and sends
Reply to ITR1 Map-Reply to ITR1
7.4. Lookup of 10.16.2.1/32 by ITR2 9.4. Lookup of 2001:db8:0500:2:4::1/128
This example shows how a DDT Map Resolver uses a saved referral cache This example shows how a DDT Map Resolver uses a saved referral cache
entry to start the referral process at a non-root, intermediate DDT entry to start the referral process at a non-root, intermediate DDT
node for a prefix that is similar to one previously requested. node for a prefix that is similar to one previously requested.
In this case, ITR2 asks the same Map Resolver used in example In this case, ITR2 asks the same Map Resolver used in example
Section 7.2. It sends an Encapsulated Map-Request for 10.16.2.1 to Section 9.2. It sends an Encapsulated Map-Request for
that (DDT) Map Resolver, which finds a NODE-REFERRAL cache entry for 2001:db8:0500:2:4::1 to that (DDT) Map Resolver, which finds a NODE-
10.16.0.0/12 with RLOC set (192.0.2.201). It proceeds as follows: REFERRAL cache entry for 2001:db8:0500::/40 with RLOC set
(192.0.2.201). It proceeds as follows:
1. Send DDT Map-Request (for 10.16.2.1) to 192.0.2.201 1. Send DDT Map-Request (for 2001:db8:0500:2:4::1) to 192.0.2.201
2. Receive (and save in referral cache) Map-Referral for EID-prefix 2. Receive (and save in referral cache) Map-Referral for EID-prefix
10.16.0.0/16, action code MS-REFERRAL, RLOC set (192.0.2.211) 2001:db8:0500::/48, action code MS-REFERRAL, RLOC set
(192.0.2.211)
3. Send DDT Map-Request to 192.0.2.211; if the ITR-originated 3. Send DDT Map-Request to 192.0.2.211; if the ITR-originated
Encapsulated Map-Request had a LISP-SEC signature, it is included Encapsulated Map-Request had a LISP-SEC signature, it is included
4. DDT Map Server at 192.0.2.211 decapsulates the DDT Map-Request 4. DDT Map Server at 192.0.2.211 decapsulates the DDT Map-Request
and forwards to a registered site4 ETR for 10.16.2.0/24 and forwards to a registered site4 ETR for 2001:db8:0500:2::/64
5. DDT Map Server at 192.0.2.211 sends a Map-Referral message for 5. DDT Map Server at 192.0.2.211 sends a Map-Referral message for
EID-prefix 10.16.2.0/24, action code MS-ACK to the DDT Map EID-prefix 2001:db8:0500:2::/64, action code MS-ACK to the DDT
Resolver Map Resolver
6. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the 6. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the
pending request for 10.16.2.1 pending request for 2001:db8:0500:2:4::1
7. site4 ETR for 10.16.2.0/24 receives Map-Request and sends Map- 7. site4 ETR for 2001:db8:0500:2::/64 receives Map-Request and sends
Reply to ITR2 Map-Reply to ITR2
7.5. Lookup of 10.16.0.1/32 (non-existent EID) by ITR2 9.5. Lookup of 2001:db8:0500::1/128 (non-existent EID)
This example uses the cached MS-REFERRAL for 10.16.0.0/16 learned This example uses the cached MS-REFERRAL for 2001:db8:0500::/48
above to start the lookup process at the DDT Map-Server at learned above to start the lookup process at the DDT Map-Server at
192.0.2.211. The DDT Map Resolver proceeds as follows: 192.0.2.211. The DDT Map Resolver proceeds as follows:
1. Send DDT Map-Request (for 10.16.0.1) to 192.0.2.211; if the ITR- 1. Send DDT Map-Request (for 2001:db8:0500::1) to 192.0.2.211; if
originated Encapsulated Map-Request had a LISP-SEC signature, it the ITR-originated Encapsulated Map-Request had a LISP-SEC
is included signature, it is included
2. DDT Map Server at 192.0.2.211, which is authoritative for 2. DDT Map Server at 192.0.2.211, which is authoritative for
10.16.0.0/16, does not have a matching delegation for 10.16.0.1. 2001:db8:0500::/48, does not have a matching delegation for
It responds with a Map-Referral message for 10.16.0.0/24, action 2001:db8:0500::1. It responds with a Map-Referral message for
code DELEGATION-HOLE to the DDT Map Resolver. The prefix 2001:db8:0500::/64, action code DELEGATION-HOLE to the DDT Map
10.16.0.0/24 is used because it is the least-specific prefix that Resolver. The prefix 2001:db8:0500::/64 is used because it is
does match the requested EID, but does not match one of the least-specific prefix that does match the requested EID, but
configured delegations (10.16.1.0/24 and 10.16.2.0/24). does not match one of configured delegations
(2001:db8:0500:1::/64 and 2001:db8:0500:2::/64).
3. DDT Map Resolver receives the delegation, adds a negative 3. DDT Map Resolver receives the delegation, adds a negative
referral cache entry for 10.16.0.0/24, dequeues the pending referral cache entry for 2001:db8:0500::/64, dequeues the pending
request for 10.16.0.1, and returns a negative Map-Reply to ITR2. request for 2001:db8:0500::1, and returns a negative Map-Reply to
ITR2.
8. Securing the database and message exchanges 10. Securing the database and message exchanges
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
skipping to change at page 26, line 22 skipping to change at page 30, line 45
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
anchors. Once a Map Resolver authenticates a public key it locally anchors. Once a Map Resolver authenticates a public key it locally
caches the key along with the associated DDT node RLOC and XEID- caches the key along with the associated DDT node RLOC and XEID-
prefix for future use. prefix for future use.
8.1. XEID-prefix Delegation 10.1. XEID-prefix Delegation
In order to delegate XEID sub-prefixes to its children, a parent DDT In order to delegate XEID sub-prefixes to its children, a parent DDT
node signs its Map-Referrals. Every signed Map-Referral also node signs its Map-Referrals. Every signed Map-Referral also
includes the public keys associated with each child DDT node. Such a includes the public keys associated with each child DDT node. Such a
signature indicates that the parent node is delegating the specified signature indicates that the parent node is delegating the specified
XEID -prefix to a given child DDT node. The signature is also XEID -prefix to a given child DDT node. The signature is also
authenticating the public keys associated with the children nodes, authenticating the public keys associated with the children nodes,
and authorizing them to be used by the children DDT nodes to provide and authorizing them to be used by the children DDT nodes to provide
origin authentication and integrity protection for further origin authentication and integrity protection for further
delegations and mapping information of the XEID-prefix allocated to delegations and mapping information of the XEID-prefix allocated to
the DDT node. the DDT node.
As a result, for a given XEID-prefix, a Map Resolver can form an As a result, for a given XEID-prefix, a Map Resolver can form an
authentication chain from a configured trust anchor (typically the authentication chain from a configured trust anchor (typically the
root DDT node) to the leaf nodes (Map Servers). Map Resolvers root DDT node) to the leaf nodes (Map Servers). Map Resolvers
leverage this authentication chain to verify the Map-Referral leverage this authentication chain to verify the Map-Referral
signatures while walking the DDT tree until they reach a Map Server signatures while walking the DDT tree until they reach a Map Server
authoritative for the given XEID-prefix. authoritative for the given XEID-prefix.
8.2. DDT node operation 10.2. DDT node operation
Upon receiving a Map-Request, the DDT node responds with a Map- Upon receiving a Map-Request, the DDT node responds with a Map-
Referral as specified in Section 5. For every record present in the Referral as specified in Section 7. For every record present in the
Map-Referral, the DDT node also includes the public keys associated Map-Referral, the DDT node also includes the public keys associated
with the record's XEID-prefix and the RLOCs of the children DDT with the record's XEID-prefix and the RLOCs of the children DDT
nodes. Each record contained in the Map-Referral is signed using the nodes. Each record contained in the Map-Referral is signed using the
DDT node's private key. DDT node's private key.
8.2.1. DDT public key revocation 10.2.1. DDT public key revocation
The node that owns a public key can also revoke that public key. For The node that owns a public key can also revoke that public key. For
instance if a parent node advertises a public key for one of its instance if a parent node advertises a public key for one of its
child DDT nodes, the child DDT node can at a later time revoke that child DDT nodes, the child DDT node can at a later time revoke that
key. Since DDT nodes do not keep track of the Map Resolvers that key. Since DDT nodes do not keep track of the Map Resolvers that
query them, revocation is done in a pull model, where the Map query them, revocation is done in a pull model, where the Map
Resolver is informed of the revocation of a key only when it queries Resolver is informed of the revocation of a key only when it queries
the node that owns that key. If the parent DDT is configured to the node that owns that key. If the parent DDT is configured to
advertise this key, the parent node must also be signaled to remove advertise this key, the parent node must also be signaled to remove
the key from the records it advertises for the child DDT node; this the key from the records it advertises for the child DDT node; this
is necessary to avoid further distribution of the revoked key. is necessary to avoid further distribution of the revoked key.
To securely revoke a key, the DDT node creates a new Record for the To securely revoke a key, the DDT node creates a new Record for the
associated XEID-prefix and locator, including the revoked key with associated XEID-prefix and locator, including the revoked key with
the R bit set. The DDT node must also include a signature in the the R bit set. The DDT node must also include a signature in the
Record that covers this record; this is computed using the private Record that covers this record; this is computed using the private
key corresponding to the key being revoked. Such a record is termed key corresponding to the key being revoked. Such a record is termed
a "revocation record". By including this record in its Map- a "revocation record". By including this record in its Map-
Referrals, the DDT node informs querying Map Resolvers about the Referrals, the DDT node informs querying Map Resolvers about the
revoked key. A digital signature computed with a revoked key can revoked key. A digital signature computed with a revoked key can
only be used to authenticate the revocation, and should not be used only be used to authenticate the revocation, and SHOULD NOT be used
to validate any data. To prevent a compromised key from revoking to validate any data. To prevent a compromised key from revoking
other valid keys, a given key can only be used to sign a revocation other valid keys, a given key can only be used to sign a revocation
for that specific key; it cannot be used to revoke other keys. This for that specific key; it cannot be used to revoke other keys. This
prevents the use of a compromised key to revoke other valid keys as prevents the use of a compromised key to revoke other valid keys as
described in [RFC5011]. A revocation record must be advertised for a described in [RFC5011]. A revocation record must be advertised for a
period of time equal to or greater than the TTL value of the Record period of time equal to or greater than the TTL value of the Record
that initially advertised the key, starting from the time that the that initially advertised the key, starting from the time that the
advertisement of the key was stopped by removal from the parent DDT advertisement of the key was stopped by removal from the parent DDT
node. node.
8.3. Map Server operation 10.3. Map Server operation
Similar to a DDT node, a Map Server is configured with one (or more) Similar to a DDT node, a Map Server is configured with one (or more)
public/private key pairs that it must use to sign Map-Referrals. public/private key pairs that it must use to sign Map-Referrals.
However unlike DDT nodes, Map Servers do not delegate prefixes and as However unlike DDT nodes, Map Servers do not delegate prefixes and as
a result they do not need to include keys in the Map-Referrals they a result they do not need to include keys in the Map-Referrals they
generate. generate.
8.4. Map Resolver operation 10.4. Map Resolver operation
Upon receiving a Map-Referral, the Map Resolver must first verify the Upon receiving a Map-Referral, the Map Resolver must first verify the
signature(s) by using a trust anchor, or a previously authenticated signature(s) by using a trust anchor, or a previously authenticated
public key, associated with the DDT node sending the Map-Referral. public key, associated with the DDT node sending the Map-Referral.
If multiple authenticated keys are associated with the DDT node If multiple authenticated keys are associated with the DDT node
sending this Map-Referral, the Key Tag field of the signature can be sending this Map-Referral, the Key Tag field of the signature can be
used to select the right public key for verifying the signature. If used to select the right public key for verifying the signature. If
the key tag matches more than one key associated with that DDT node, the key tag matches more than one key associated with that DDT node,
the Map Resolver must try verifying the signature with all matching the Map Resolver must try verifying the signature with all matching
keys. For every matching key that is found the Map Resolver must keys. For every matching key that is found the Map Resolver must
skipping to change at page 28, line 29 skipping to change at page 33, line 5
to avoid repeating this process if the resolver cannot verify the to avoid repeating this process if the resolver cannot verify the
signature after several trials. signature after several trials.
Once the signature is verified, the Map Resolver has verified the Once the signature is verified, the Map Resolver has verified the
XEID-prefix delegation in the Map-Referral, and authenticated the XEID-prefix delegation in the Map-Referral, and authenticated the
public keys of the children DDT nodes. The Map Resolver must add public keys of the children DDT nodes. The Map Resolver must add
these keys to the authenticated keys associated with each child DDT these keys to the authenticated keys associated with each child DDT
node and XEID-prefix. These keys are considered valid for the node and XEID-prefix. These keys are considered valid for the
duration specified in the record's TTL field. duration specified in the record's TTL field.
9. Open Issues and Considerations 11. Open Issues and Considerations
There are a number of issues with the organization of the mapping There are a number of issues with the organization of the mapping
database that need further investigation. Among these are: database that need further investigation. Among these are:
o Unlike in LISP-ALT (see [RFC6836]), DDT does not currently define
a mechanism for propagating ETR-to-Map Server registration state.
This requires DDT Map Servers to suppress returning negative Map-
Reply messages for defined but unregistered XEID-prefixes to avoid
loss of connectivity during partial ETR registration failures.
Suppressing these messages may cause a delay for an ITR obtaining
a mapping entry when such a failure is occurring.
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
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 [LCAF]. o support additional EID formats as defined in [I-D.ietf-lisp-lcaf]
o Authentication of delegations between DDT nodes.
o Possibility of a new, more general format for the Map-Referral
messages to facilitate the use of LISP-DDT with additional DBID/
IID/EID combinations. Currently-defined packet formats should be
considered to be preliminary and provisional until this issue has
received greater attention. o
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.
The authors expect that experimentation on the LISP pilot network Operational experience will help answer open questions surrounding
will help answer open questions surrounding these and other issues. these and other issues.
10. IANA Considerations 12. IANA Considerations
This document makes no request of the IANA. This document makes no request of the IANA.
11. Security Considerations 13. Security Considerations
Section 8 describes a DDT security architecture that provides data Section 10 describes a DDT security architecture that provides data
origin authentication, data integrity protection, and XEID-prefix origin authentication, data integrity protection, and XEID-prefix
delegation within the DDT Infrastructure. delegation within the DDT Infrastructure.
Global XEID-prefix authorization is beyond the scope of this Global XEID-prefix authorization is beyond the scope of this
document, but the SIDR working group [RFC6480] is developing an document, but the SIDR working group [RFC6480] is developing an
infrastructure to support improved security of Internet routing. infrastructure to support improved security of Internet routing.
Further work is required to determine if SIDR's public key Further work is required to determine if SIDR's public key
infrastructure (PKI) and the distributed repository system it uses infrastructure (PKI) and the distributed repository system it uses
for storing and disseminating PKI data objects may also be used by for storing and disseminating PKI data objects may also be used by
DDT devices to verifiably assert that they are the legitimate holders DDT devices to verifiably assert that they are the legitimate holders
of a set of XEID prefixes. of a set of XEID prefixes.
DDT security and [LISP-SEC] complement each other in securing the DDT This document specifies how DDT security and LISP-SEC
infrastructure, Map-Referral messages and the Map-Request/Map-Reply ([I-D.ietf-lisp-sec]) complement one another to secure the DDT
protocol. In addition LISP-SEC can use the DDT public key infrastructure, Map-Referral messages, and the Map-Request/Map-Reply
infrastructure to secure the transport of LISP-SEC key material (the protocols. In the future other LISP security mechanisms may be
One-Time Key) from a Map-Resolver to the corresponding Map-Server. developed to replace LISP-SEC. Such future security mechanisms
For this reason, when LISP-SEC is deployed in conjunction with a should describe how they can be used together with DDT to provide
LISP-DDT mapping database and the path between Map-Resolver and Map- similar levels of protection.
Server needs to be protected, DDT security should be enabled as well.
12. References
12.1. Normative References
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format",
<http://www.ietf.org/id/draft-ietf-lisp-lcaf>.
[RFC1035] Mockapetris, P., "Domain names - implementation and LISP-SEC can use the DDT public key infrastructure to secure the
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, transport of LISP-SEC key material (the One-Time Key) from a Map-
November 1987, <http://www.rfc-editor.org/info/rfc1035>. Resolver to the corresponding Map-Server. For this reason, when
LISP-SEC is deployed in conjunction with a LISP-DDT mapping database
and the path between Map-Resolver and Map-Server needs to be
protected, DDT security should be enabled as well.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 14. References
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>.
[RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 14.1. Normative References
(SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July
2006, <http://www.rfc-editor.org/info/rfc4634>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, Requirement Levels", BCP 14, RFC 2119,
September 2007, <http://www.rfc-editor.org/info/rfc5011>. DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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>.
12.2. Informative References 14.2. Informative References
[LISP-SEC] [I-D.ietf-lisp-lcaf]
Maino, F., Ermagan, V., Cabellos, A., and D. Sanchez, Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
"LISP-Security", Address Format (LCAF)", draft-ietf-lisp-lcaf-12 (work in
<http://www.ietf.org/id/draft-ietf-lisp-sec>. progress), March 2016.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-09
(work in progress), October 2015.
[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)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/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>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
skipping to change at page 31, line 21 skipping to change at page 35, line 30
described in this document. Thanks also go to Dino Farinacci and described in this document. Thanks also go to Dino Farinacci and
Isidor Kouvelas for their implementation work; to Selina Heimlich and Isidor Kouvelas for their implementation work; to Selina Heimlich and
Srin Subramanian for testing; to Fabio Maino for work on security Srin Subramanian for testing; to Fabio Maino for work on security
processing; and to Job Snijders, Glen Wiley, Neel Goyal, and Mike processing; and to Job Snijders, Glen Wiley, Neel Goyal, and Mike
Gibbs for work on operational considerations and initial deployment Gibbs for work on operational considerations and initial deployment
of a prototype database infrastructure. Special thanks go to Jesper of a prototype database infrastructure. Special thanks go to Jesper
Skriver, Andrew Partan, and Noel Chiappa; all of whom have Skriver, Andrew Partan, and Noel Chiappa; all of whom have
participated in (and put up with) seemingly endless hours of participated in (and put up with) seemingly endless hours of
discussion of mapping database ideas, concepts, and issues. discussion of mapping database ideas, concepts, and issues.
Appendix B. Map-Referral Message Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=6 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Referral Count| EID mask-len | ACT |A|I| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c |SigCnt | Map Version Number | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix ... |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |R| Loc/LCAF-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator ... |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACT: The "action" field of the mapping record in a Map-Referral
message encodes 6 action types. The values for the action types are:
NODE-REFERRAL (0): Sent by a DDT node with a child delegation, which
is authoritative for the EID.
MS-REFERRAL (1): Sent by a DDT node that has information about Map
Server(s) for the EID but it is not one of the Map Servers listed,
i.e. the DDT-Node sending the referral is not a Map Server.
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 child delegation
covering the requested EID, it may choose to return NODE-REFERRAL
or MS-REFERRAL as appropriate. A DDT Map Server with site
information may choose to return of type MS-ACK or MS-NOT-
REGISTERED as appropriate.
Incomplete: The "I" bit indicates that a DDT node's referral-set of
locators is incomplete and the receiver of this message should not
cache the referral. A DDT sets the "incomplete" flag, the TTL, and
the Action Type field as follows:
-------------------------------------------------------------------
Type (Action field) Incomplete Referral-set TTL values
-------------------------------------------------------------------
0 NODE-REFERRAL NO YES 1440
1 MS-REFERRAL NO YES 1440
2 MS-ACK * * 1440
3 MS-NOT-REGISTERED * * 1
4 DELEGATION-HOLE NO NO 15
5 NOT-AUTHORITATIVE YES NO 0
-------------------------------------------------------------------
*: The "Incomplete" flag setting on Map Server originated referral of
MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map
Server has the full peer Map Server configuration for the same
prefix and has encoded the information in the mapping record.
Incomplete bit is not set when the Map Server has encoded the
information, which means the referral-set includes all the RLOCs
of all Map Servers that serve the prefix. It is set when the Map
Server has not encoded the Map Server set information.
SigCnt: Indicates the number of signatures (sig section) present in
the Record. If SigCnt is larger than 0, the signature information
captured in a sig section as described in Appendix B.1 will be
appended to the end of the record. The number of sig sections at the
end of the Record must match the SigCnt.
Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the
record. If this is a LCAF AFI, the contents of the LCAF depend on
the Type field of the LCAF. Security material are stored in LCAF
Type 11. DDT nodes and Map Servers can use this LCAF Type to include
public keys associated with their Child DDT nodes for a XEID-prefix
referral record. LCAF types and formats are defined in [LCAF].
All the field descriptions are equivalent to those in 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 result of the
referral not the RLOCs for an actual EID-to-RLOC mapping.
B.1. SIG section
If SigCnt field in the Map-Referral is not 0, the signature
information is included at the end of captured in a sig section as
described below. SigCnt counts the number of sig sections that
appear at the end of the Record.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| Original Record TTL |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Signature Expiration |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s | Signature Inception |
i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
g | Key Tag | Sig Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Sig-Algorithm | Reserved | Reserved |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ~ Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Original Record TTL: The original Record TTL for this record that is
covered by the signature. Record TTL is in minutes.
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.
Sig Length: The length of the Signature field.
Sig-Algorithm: The identifier of the cryptographic algorithm used for
the signature. Default value is RSA-SHA1.
Reserved: This field must be set to 0 on transmit and must be ignored
on receipt.
Signature Expiration and Inception: Specify the validity period for
the signature. Each specify a date and time in 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 order.
Signature: Contains the cryptographic signature that covers the
entire record. The Record TTL and the sig fields are set to zero for
the purpose of computing the Signature
Appendix C. Encapsulated Control Message Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LH |Type=8 |S|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"D" is the "DDT-originated" flag and is set by a DDT client to
indicate that the receiver can and should return Map-Referral
messages as appropriate.
Authors' Addresses Authors' Addresses
Vince Fuller Vince Fuller
Email: vaf@vaf.net Email: vaf@vaf.net
Darrel Lewis Darrel Lewis
Cisco Systems Cisco Systems
Email: darlewis@cisco.com Email: darlewis@cisco.com
Vina Ermagan Vina Ermagan
Cisco Systems Cisco Systems
Email: vermagan@cisco.com Email: vermagan@cisco.com
Amit Jain Amit Jain
Juniper Networks Juniper Networks
Email: atjain@juniper.net Email: atjain@juniper.net
Anton Smirnov
Cisco Systems
Email: as@cisco.com
 End of changes. 155 change blocks. 
513 lines changed or deleted 545 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/