draft-ietf-lisp-ddt-03.txt   draft-ietf-lisp-ddt-04.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: October 17, 2015 V. Ermagan Expires: September 22, 2016 V. Ermagan
Cisco Systems Cisco Systems
A. Jain A. Jain
Juniper Networks Juniper Networks
April 15, 2015 March 21, 2016
LISP Delegated Database Tree LISP Delegated Database Tree
draft-ietf-lisp-ddt-03.txt draft-ietf-lisp-ddt-04
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
"child" DDT nodes to which more-specific EID-prefixes are delegated. "child" DDT nodes to which more-specific EID-prefixes are delegated.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 17, 2015. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Database organization . . . . . . . . . . . . . . . . . . . . 8 3. Database organization . . . . . . . . . . . . . . . . . . . . 6
3.1. EID-prefix tree structure and instance IDs . . . . . . . . 8 3.1. EID-prefix tree structure and instance IDs . . . . . . . 6
3.2. Configuring prefix delegation . . . . . . . . . . . . . . 8 3.2. Configuring prefix delegation . . . . . . . . . . . . . . 7
3.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 8 3.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7
4. The Map-Referral message . . . . . . . . . . . . . . . . . . . 10 4. The Map-Referral message . . . . . . . . . . . . . . . . . . 7
4.1. Action codes . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Referral set . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 11 4.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 9
5. DDT network elements and their operation . . . . . . . . . . . 12 5. DDT network elements and their operation . . . . . . . . . . 9
5.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 12 5.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 9
5.1.2. Missing delegation from an authoritative prefix . . . 12 5.1.2. Missing delegation from an authoritative prefix . . . 10
5.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . . 13 5.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 10
5.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . . 13 5.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 10
5.3.1. Queuing and sending DDT Map-Requests . . . . . . . . . 13 5.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 10
5.3.2. Receiving and following referrals . . . . . . . . . . 14 5.3.2. Receiving and following referrals . . . . . . . . . . 11
5.3.3. Handling referral errors . . . . . . . . . . . . . . . 15 5.3.3. Handling referral errors . . . . . . . . . . . . . . 13
5.3.4. Referral loop detection . . . . . . . . . . . . . . . 16 5.3.4. Referral loop detection . . . . . . . . . . . . . . . 13
6. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . . 17 6. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 14
6.1. Map Resolver processing of ITR Map-Request . . . . . . . . 17 6.1. Map Resolver processing of ITR Map-Request . . . . . . . 14
6.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 17 6.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 14
6.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 17 6.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 14
6.2. Map Resolver processing of Map-Referral message . . . . . 18 6.2. Map Resolver processing of Map-Referral message . . . . . 15
6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 18 6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 15
6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 20 6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 17
6.3. DDT Node processing of DDT Map-Request message . . . . . . 22 6.3. DDT Node processing of DDT Map-Request message . . . . . 19
6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 22 6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19
6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 22 6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 19
7. Example topology and request/referral following . . . . . . . 24 7. Example topology and request/referral following . . . . . . . 20
7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 25 7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 22
7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . . 26 7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . 23
7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 27 7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 24
7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . . 27 7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . 24
7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 . . . . 28 7.5. Lookup of 10.16.0.1/32 (non-existent EID) by ITR2 . . . . 25
8. Securing the database and message exchanges . . . . . . . . . 29 8. Securing the database and message exchanges . . . . . . . . . 25
8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . . 29 8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 26
8.2. DDT node operation . . . . . . . . . . . . . . . . . . . . 30 8.2. DDT node operation . . . . . . . . . . . . . . . . . . . 26
8.2.1. DDT public key revocation . . . . . . . . . . . . . . 30 8.2.1. DDT public key revocation . . . . . . . . . . . . . . 27
8.3. Map Server operation . . . . . . . . . . . . . . . . . . . 30 8.3. Map Server operation . . . . . . . . . . . . . . . . . . 27
8.4. Map Resolver operation . . . . . . . . . . . . . . . . . . 31 8.4. Map Resolver operation . . . . . . . . . . . . . . . . . 27
9. Open Issues and Considerations . . . . . . . . . . . . . . . . 32 9. Open Issues and Considerations . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . . 35 12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 37 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31
Appendix B. Map-Referral Message Format . . . . . . . . . . . . . 38 Appendix B. Map-Referral Message Format . . . . . . . . . . . . 31
B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 40 B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix C. Encapsulated Control Message Format . . . . . . . . . 42 Appendix C. Encapsulated Control Message Format . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 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 dentifier (IID, 32-bits), Address Family Identifier (16 Instance identifier (IID, 32-bits), Address Family Identifier (16
bits), and EID-prefix (variable, according to AFI value). The bits), and EID-prefix (variable, according to AFI value). The
resulting concatenation of these fields is termed an "Extended EID resulting concatenation of these fields is termed an "Extended EID
prefix" or XEID-prefix. prefix" or XEID-prefix.
The term "Extended EID" (XEID) is also used for an individual LISP 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 EID that is further qualified through the use of an Instance ID. See
[LCAF] for further discussion of the use of Instance IDs. [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-
structured database, contacting, one after another, the DDT nodes structured database, contacting, one after another, the DDT nodes
along that path until it reaches the leaf DDT node(s) authoritative along that path until it reaches the leaf DDT node(s) authoritative
for the mapping it is seeking. for the mapping it is seeking.
LISP-DDT defines a new device type, the DDT node, that is configured LISP-DDT defines a new device type, the DDT node, that is configured
as authoritative for one or more XEID-prefixes. It also is as authoritative for one or more XEID-prefixes. It also is
configured with the set of more-specific sub-prefixes that are configured with the set of more-specific sub-prefixes that are
further delegated to other DDT nodes. To delegate a sub-prefix, the further delegated to other DDT nodes. To delegate a sub-prefix, the
"parent" DDT node is configured with the RLOCs of each child DDT node "parent" DDT node is configured with the RLOCs of each child DDT node
that is authoritative for the sub-prefix. Each RLOC either points to that is authoritative for the sub-prefix. Each RLOC either points to
a Map Server (sometimes termed a "terminal DDT node") to which an a Map Server (sometimes termed a "terminal DDT node") to which an
Egress Tunnel Routers (ETRs) has registered that sub-prefix or points Egress Tunnel Router (ETR) has registered that sub-prefix or points
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.
skipping to change at page 6, line 26 skipping to change at page 5, line 17
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), 32-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
functionality. functionality.
DDT Map Server: a DDT node that also implements Map Server DDT Map Server: a DDT node that also implements Map Server
functionality (forwarding Map-Requests and/or returning Map- functionality (forwarding Map-Requests and/or returning Map-
Replies if offering proxy Map-Reply service) for a subset of its Replies if offering proxy Map-Reply service) for a subset of its
delegated prefixes. delegated prefixes.
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
skipping to change at page 10, line 29 skipping to change at page 8, line 22
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 receiving NODE-REFERRAL, but is handled slightly differently by the
DDT client (see Section 5.3.2). receiving DDT client (see Section 5.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 is
has one or more registered ETRs. This means that the request can has one or more registered ETRs. This means that the request can
be forwarded to one of those ETRs to provide an answer to the be 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.
skipping to change at page 12, line 37 skipping to change at page 9, line 50
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 5.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
skipping to change at page 14, line 6 skipping to change at page 11, line 20
progress through the iterative referral process; the "referral XEID- progress through the iterative referral process; the "referral XEID-
prefix" is also initialized to the null value since no referral has prefix" is also initialized to the null value since no referral has
yet been received. The Map Resolver then creates a DDT Map-Request yet been received. The Map Resolver then creates a DDT Map-Request
(which is an encapsulated Map-Request with the "DDT-originated" flag (which is an encapsulated Map-Request with the "DDT-originated" flag
set in the message header) for the XEID but without any set in the message header) for the XEID but without any
authentication data that may have been included in the original Map- authentication data that may have been included in the original Map-
Request. It sends the DDT Map-Request to one of the RLOCs in the Request. It sends the DDT Map-Request to one of the RLOCs in the
chosen referral cache entry. The referral cache is initially chosen referral cache entry. The referral cache is initially
populated with one or more statically-configured entries; additional populated with one or more statically-configured entries; additional
entries are added when referrals are followed, as described below. A entries are added when referrals are followed, as described below. A
DDT Map Resolver is not absolutely required to cache referrals but it DDT Map Resolver is not absolutely required to cache referrals, but
doing so decreases latency and reduces lookup delays. it doing so decreases latency and reduces lookup delays.
Note that in normal use on the public Internet, the statically- Note that in normal use on the public Internet, the statically-
configured initial referral cache for a DDT Map Resolver should configured initial referral cache for a DDT 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
skipping to change at page 15, line 13 skipping to change at page 12, line 27
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
sent to the authoritative DDT Map-Server; the DDT Map Resolver re- sent to the authoritative DDT Map-Server; the DDT Map Resolver re-
sends the DDT Map-Request with LISP-SEC information included and sends the DDT Map-Request with LISP-SEC information included and
the pending request queue entry remains until another Map-Referral the pending request queue entry remains until another Map-Referral
with MS-ACK action code is received. If the "incomplete" flag is with MS-ACK action code is received. If the "incomplete" flag is
not set, the prefix is saved in the referral cache. not set, the prefix is saved in the referral cache.
MS-NOT-REGISTERED: The DDT Map Server qurieed could not process the MS-NOT-REGISTERED: The DDT Map Server queried could not process the
request because it did not have any ETRs registered for a request because it did not have any ETRs registered for a
matching, authoritative XEID-prefix. If the DDT Map Resolver has matching, authoritative XEID-prefix. If the DDT Map Resolver has
not yet tried all of the RLOCs saved with the pending request, not yet tried all of the RLOCs saved with the pending request,
then it sends a Map-Request to the next RLOC in that list. If all then it sends a Map-Request to the next RLOC in that list. If all
RLOCs have been tried, then the destination XEID is not registered RLOCs have been tried, then the destination XEID is not registered
and is unreachable. The DDT Map Resolver returns a negative Map- and is unreachable. The DDT Map Resolver returns a negative Map-
Reply to the original Map-Request sender; this Map-Reply contains Reply to the original Map-Request sender; this Map-Reply contains
the non-registered XEID-prefix with TTL value of one minute. A the non-registered XEID-prefix with TTL value of one minute. A
negative referral cache entry is created for the prefix (also with negative referral cache entry is created for the prefix (also with
TTL of one minute) and the pending request is dequeued. TTL of one minute) and the pending request is dequeued.
skipping to change at page 16, line 36 skipping to change at page 13, line 49
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 5.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 6. 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
"pseudo-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 6.1. Map Resolver processing of ITR Map-Request
6.1.1. Pseudo-code summary 6.1.1. Pseudo-code summary
if ( request pending i.e., (ITR,EID) of request same ) { if ( request pending i.e., (ITR,EID) of request same ) {
replace old request with new & use new request nonce replace old request with new & use new request nonce
for future requests for future requests
} else if ( no match in refcache ) { } else if ( no match in refcache ) {
return negative map-reply to ITR return negative map-reply to ITR
skipping to change at page 18, line 15 skipping to change at page 15, line 15
| 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
+------------+ +------------+
| Match In | No | Match In | No
| Referral |----> Send Negative Map Reply | Referral |----> Send Negative Map-Reply
| cache? | (not a likely event as root | cache? | (not a likely event as root
+------------+ configured on every MR) +------------+ configured on every MR)
| |
|Yes |Yes
| |
V V
+------------+ +------------+
| Match Type | Yes | Match Type | Yes
| Delegation |----> Send Negative Map Reply | Delegation |----> Send Negative Map-Reply
| Hole ? | | Hole? |
+------------+ +------------+
| |
|No |No
| |
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
| | | |
+------------+ +------------+
skipping to change at page 21, line 44 skipping to change at page 18, line 44
| +------------+ | |No with OTK | +------------+ | |No with OTK
| | Gone | V | | | Gone | V |
| | 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 OTK
| |No |Yes | |No |Yes
| | | | | |
| V V | V V
| Goto root Send negative map-reply | Goto root Send negative map-reply
V V
+-----------+ Yes +-----------+ Yes +-----------+ Yes +-----------+ Yes
| Other MS |-----Follow other MS-------->|Incomplete |----> Dont 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 6.3. DDT Node processing of DDT Map-Request message
6.3.1. Pseudo-code summary 6.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 ) {
skipping to change at page 26, line 36 skipping to change at page 23, line 29
nodes, 192.0.2.1 or 192.0.2.2 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, 10.0.0.0/8, 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) 10.16.0.0/12, action code NODE-REFERRAL, RLOC set (192.0.2.201)
5.
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) 10.17.0.0/16, 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
skipping to change at page 28, line 26 skipping to change at page 25, line 18
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 10.16.2.0/24, action code MS-ACK to the DDT Map
Resolver 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 10.16.2.1
7. site4 ETR for 10.16.2.0/24 receives Map-Request and sends Map- 7. site4 ETR for 10.16.2.0/24 receives Map-Request and sends Map-
Reply to ITR2 Reply to ITR2
7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 7.5. Lookup of 10.16.0.1/32 (non-existent EID) by ITR2
This example uses the cached MS-REFERRAL for 10.16.0.0/16 learned This example uses the cached MS-REFERRAL for 10.16.0.0/16 learned
above to start the lookup process at the DDT Map-Server at 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 10.16.0.1) to 192.0.2.211; if the ITR-
originated Encapsulated Map-Request had a LISP-SEC signature, it originated Encapsulated Map-Request had a LISP-SEC signature, it
is included 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. 10.16.0.0/16, does not have a matching delegation for 10.16.0.1.
It respondes with a Map-Referral message for 10.16.0.0/24, action It responds with a Map-Referral message for 10.16.0.0/24, action
code DELEGATION-HOLE to the DDT Map Resolver. The prefix code DELEGATION-HOLE to the DDT Map Resolver. The prefix
10.16.0.0/24 is used because it is the least-specific prefix that 10.16.0.0/24 is used because it is the least-specific prefix that
does match the requested EID but does not match one of configured does match the requested EID, but does not match one of
delegations (10.16.1.0/24 and 10.16.2.0/24). configured delegations (10.16.1.0/24 and 10.16.2.0/24).
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 10.16.0.0/24, dequeues the pending
request for 10.16.0.1, and returns a negative Map-Reply to ITR2. request for 10.16.0.1, and returns a negative Map-Reply to ITR2.
8. Securing the database and message exchanges 8. 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
skipping to change at page 30, line 44 skipping to change at page 27, line 33
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 advertisied 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 8.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
skipping to change at page 32, line 20 skipping to change at page 28, line 44
o Unlike in LISP-ALT (see [RFC6836]), DDT does not currently define o Unlike in LISP-ALT (see [RFC6836]), DDT does not currently define
a mechanism for propagating ETR-to-Map Server registration state. a mechanism for propagating ETR-to-Map Server registration state.
This requires DDT Map Servers to suppress returning negative Map- This requires DDT Map Servers to suppress returning negative Map-
Reply messages for defined but unregistered XEID-prefixes to avoid Reply messages for defined but unregistered XEID-prefixes to avoid
loss of connectivity during partial ETR registration failures. loss of connectivity during partial ETR registration failures.
Suppressing these messages may cause a delay for an ITR obtaining Suppressing these messages may cause a delay for an ITR obtaining
a mapping entry when such a failure is occurring. 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]. support additional EID formats as defined in [LCAF]. o
o Authentication of delegations between DDT nodes. o Authentication of delegations between DDT nodes.
o Possibility of a new, more general format for the Map-Referral o Possibility of a new, more general format for the Map-Referral
messages to facilitate the use of LISP-DDT with additional DBID/ messages to facilitate the use of LISP-DDT with additional DBID/
IID/EID combinations. Currently-defined packet formats should be IID/EID combinations. Currently-defined packet formats should be
considered to be preliminary and provisional until this issue has considered to be preliminary and provisional until this issue has
received greater attention. 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 The authors expect that experimentation on the LISP pilot network
will help answer open questions surrounding these and other issues. will help answer open questions surrounding these and other issues.
10. IANA Considerations 10. IANA Considerations
This document makes no request of the IANA. This document makes no request of the IANA.
skipping to change at page 35, line 14 skipping to change at page 30, line 6
12. References 12. References
12.1. Normative References 12.1. Normative References
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format", Address Format",
<http://www.ietf.org/id/draft-ietf-lisp-lcaf>. <http://www.ietf.org/id/draft-ietf-lisp-lcaf>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006. (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) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, September 2007. Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[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,
January 2013. DOI 10.17487/RFC6830, January 2013,
<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,
January 2013. DOI 10.17487/RFC6833, January 2013,
<http://www.rfc-editor.org/info/rfc6833>.
12.2. Informative References 12.2. Informative References
[LISP-SEC] [LISP-SEC]
Maino, F., Ermagan, V., Cabellos, A., and D. Sanchez, Maino, F., Ermagan, V., Cabellos, A., and D. Sanchez,
"LISP-Security", "LISP-Security",
<http://www.ietf.org/id/draft-ietf-lisp-sec>. <http://www.ietf.org/id/draft-ietf-lisp-sec>.
[LISP-TREE] [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
Jakab, L., Cabellos, A., Coras, F., and D. Sauceez, "LISP- and E. Lear, "Address Allocation for Private Internets",
TREE", 10 2010, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://dl.acm.org/citation.cfm?id=1878181>. <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[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, February 2012. Secure Internet Routing", RFC 6480, DOI 10.17487/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, January 2013. Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <http://www.rfc-editor.org/info/rfc6836>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors with to express their thanks to Damien Saucez, Lorand The authors with to express their thanks to Damien Saucez, Lorand
Jakab, Olivier Bonaventure, Albert Cabellos-Asparicio, and FLorin Jakab, Olivier Bonaventure, Albert Cabellos-Asparicio, and Florin
Coras for work on LISP-TREE and LISP iterable mappings that inspired Coras for work on LISP-TREE and LISP iterable mappings that inspired
the hierarchical database structure and lookup iteration approach the hierarchical database structure and lookup iteration approach
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
skipping to change at page 38, line 30 skipping to change at page 31, line 46
c |SigCnt | Map Version Number | EID-AFI | c |SigCnt | Map Version Number | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix ... | r | EID-prefix ... |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |R| Loc/LCAF-AFI | | o | Unused Flags |R| Loc/LCAF-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator ... | | \| Locator ... |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACT: The "action" field of the mapping record in a Map-Referral ACT: The "action" field of the mapping record in a Map-Referral
message encodes 6 action types. The values for the action types are: message encodes 6 action types. The values for the action types are:
NODE-REFERRAL (0): Sent by a DDT node with a child delegation which NODE-REFERRAL (0): Sent by a DDT node with a child delegation, which
is authoritative for the EID. is authoritative for the EID.
MS-REFERRAL (1): Sent by a DDT node that has information about Map 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, 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. 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 MS-ACK (2): Sent by a DDT Map Server that has one or more ETR
registered for the EID. registered for the EID.
MS-NOT-REGISTERED (3): Sent by a DDT Map Server that is configured MS-NOT-REGISTERED (3): Sent by a DDT Map Server that is configured
for the EID-prefix but for which no ETRs are registered. for the EID-prefix, but for which no ETRs are registered.
DELEGATION-HOLE (4): Sent by an intermediate DDT node with DELEGATION-HOLE (4): Sent by an intermediate DDT node with
authoritative configuration covering the requested EID but without authoritative configuration covering the requested EID but without
any child delegation for the EID. Also sent by a DDT Map Server any child delegation for the EID. Also sent by a DDT Map Server
with authoritative configuration covering the requested EID but with authoritative configuration covering the requested EID, but
for which no specific site ETR is configured. for which no specific site ETR is configured.
NOT-AUTHORITATIVE (5): Sent by a DDT node that does not have NOT-AUTHORITATIVE (5): Sent by a DDT node that does not have
authoritative configuration for the requested EID. The EID-prefix authoritative configuration for the requested EID. The EID-prefix
returned MUST be the original requested EID and the TTL MUST be 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 set to 0. However, if such a DDT node has a child delegation
covering the requested EID, it may choose to return NODE-REFERRAL covering the requested EID, it may choose to return NODE-REFERRAL
or MS-REFERRAL as appropriate. A DDT Map Server with site or MS-REFERRAL as appropriate. A DDT Map Server with site
information may choose to return of type MS-ACK or MS-NOT- information may choose to return of type MS-ACK or MS-NOT-
REGISTERED as appropriate. REGISTERED as appropriate.
 End of changes. 43 change blocks. 
109 lines changed or deleted 116 lines changed or added

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