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/