draft-ietf-lisp-ddt-00.txt		draft-ietf-lisp-ddt-01.txt
	Network Working Group V. Fuller		Network Working Group V. Fuller
	Internet-Draft D. Lewis		Internet-Draft D. Lewis
	Intended status: Experimental V. Ermagan		Intended status: Experimental V. Ermagan
	Expires: April 18, 2013 A. Jain		Expires: September 29, 2013 cisco Systems
	cisco Systems		A. Jain
	October 15, 2012		Juniper Networks
			March 28, 2013
	LISP Delegated Database Tree		LISP Delegated Database Tree
	draft-ietf-lisp-ddt-00.txt		draft-ietf-lisp-ddt-01.txt
	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 April 18, 2013.		This Internet-Draft will expire on September 29, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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. Psuedo Code and Decision Tree diagrams . . . . . . . . . . . . 17		6. Psuedo 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 . . . . . . . . . . . . . . . . 18		6.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 14
	6.2. Map Resolver processing of Map-Referral message . . . . . 19		6.2. Map Resolver processing of Map-Referral message . . . . . 16
	6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19		6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 16
	6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 21		6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 18
	6.3. DDT Node processing of DDT Map-Request message . . . . . . 22		6.3. DDT Node processing of DDT Map-Request message . . . . . 20
	6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 22		6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 20
	6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 23		6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 20
	7. Example topology and request/referral following . . . . . . . 24		7. Example topology and request/referral following . . . . . . . 21
	7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 25		7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 23
	7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . . 26		7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . 24
	7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 27		7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 25
	7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . . 27		7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . 25
	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-existant EID) by ITR2 . . . . 26
	8. Securing the database and message exchanges . . . . . . . . . 29		8. Securing the database and message exchanges . . . . . . . . . 27
	8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . . 29		8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 27
	8.2. DDT node operation . . . . . . . . . . . . . . . . . . . . 30		8.2. DDT node operation . . . . . . . . . . . . . . . . . . . 28
	8.2.1. DDT public key revocation . . . . . . . . . . . . . . 30		8.2.1. DDT public key revocation . . . . . . . . . . . . . . 28
	8.3. Map Server operation . . . . . . . . . . . . . . . . . . . 30		8.3. Map Server operation . . . . . . . . . . . . . . . . . . 28
	8.4. Map Resolver operation . . . . . . . . . . . . . . . . . . 31		8.4. Map Resolver operation . . . . . . . . . . . . . . . . . 29
	9. Open Issues and Considerations . . . . . . . . . . . . . . . . 32		9. Open Issues and Considerations . . . . . . . . . . . . . . . 29
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 34		11. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 35		12.1. Normative References . . . . . . . . . . . . . . . . . . 31
	12.2. Informative References . . . . . . . . . . . . . . . . . . 35		12.2. Informative References . . . . . . . . . . . . . . . . . 31
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32
	Appendix B. Map-Referral Message Format . . . . . . . . . . . . . 37		Appendix B. Map-Referral Message Format . . . . . . . . . . . . 32
	B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 39		B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 34
	Appendix C. Encapsulated Control Message Format . . . . . . . . . 41		Appendix C. Encapsulated Control Message Format . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	[LISP] specifies an architecture and mechanism for replacing the		LISP [RFC6830] specifies an architecture and mechanism for replacing
	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
	skipping to change at page 4, line 34		skipping to change at page 3, line 48
	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 Routers (ETRs) 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 [LISP-MS] for a description of the functionality of		sub-prefix. See LISP-MS [RFC6833] for a description of the
	the Map Server and Map Resolver. Note that the target of a		functionality of the Map Server and Map Resolver. Note that the
	delegation must always be an RLOC (not an EID) to avoid any circular		target of a delegation must always be an RLOC (not an EID) to avoid
	dependency.		any circular dependency.
	To provide a mechanism for traversing the database tree, LISP-DDT		To provide a mechanism for traversing the database tree, LISP-DDT
	defines a new LISP message type, the Map-Referral, which is returned		defines a new LISP message type, the Map-Referral, which is returned
	to the sender of a Map-Request when the receiving DDT node can refer		to the sender of a Map-Request when the receiving DDT node can refer
	the sender to another DDT node that has more detailed information.		the sender to another DDT node that has more detailed information.
	See Section 4 for the definition of the Map-Referral message.		See Section 4 for the definition of the Map-Referral message.
	To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map		To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map
	Resolver, starts by sending an Encapsulated Map-Request to a		Resolver, starts by sending an Encapsulated Map-Request to a
	preconfigured DDT node RLOC. The DDT node responds with a Map-		preconfigured DDT node RLOC. The DDT node responds with a Map-
	skipping to change at page 6, line 11		skipping to change at page 4, line 49
	Conceptually, this is similar to the way that a client of the Domain		Conceptually, this is similar to the way that a client of the Domain
	Name System (DNS) follows referrals (DNS responses that contain only		Name System (DNS) follows referrals (DNS responses that contain only
	NS records) from a series of DNS servers until it finds an answer.		NS records) from a series of DNS servers until it finds an answer.
	2. Definition of Terms		2. Definition of Terms
	Extended EID (XEID): a LISP EID, optionally extended with a non-		Extended EID (XEID): a LISP EID, optionally extended with a non-
	zero Instance ID (IID) if the EID is intended for use in a context		zero Instance ID (IID) if the EID is intended for use in a context
	where it may not be a unique value, such as on a Virtual Private		where it may not be a unique value, such as on a Virtual Private
	Network where [RFC1918] address space is used. See "Using		Network where [RFC1918] address space is used. See "Using
	Virtualization and Segmentation with LISP" in [LISP] for more		Virtualization and Segmentation with LISP" in [RFC6830] for more
	discussion of Instance IDs.		discussion of Instance IDs.
	XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided		XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided
	to allow the definition of multiple databases; currently always		to allow the definition of multiple databases; currently always
	zero in this version of DDT, with other values reserved for future		zero in this version of DDT, with other values reserved for future
	use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used		use), 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-
	skipping to change at page 7, line 4		skipping to change at page 5, line 44
	results containing RLOCs for DDT nodes responsible for XEID-		results containing RLOCs for DDT nodes responsible for XEID-
	prefixes of interest (termed the "referral cache") a pending		prefixes of interest (termed the "referral cache") a pending
	request list of XEIDs that are being resolved through iterative		request list of XEIDs that are being resolved through iterative
	querying of DDT nodes.		querying of DDT nodes.
	Encapsulated Map-Request: a LISP Map-Request carried within an		Encapsulated Map-Request: a LISP Map-Request carried within an
	Encapsulated Control Message, which has an additional LISP header		Encapsulated Control Message, which has an additional LISP header
	prepended. Sent to UDP destination port 4342. The "outer"		prepended. Sent to UDP destination port 4342. The "outer"
	addresses are globally-routable IP addresses, also known as RLOCs.		addresses are globally-routable IP addresses, also known as RLOCs.
	Used by an ITR when sending to a Map Resolver and by a Map Server		Used by an ITR when sending to a Map Resolver and by a Map Server
	when forwarding a Map-Request to an ETR as documented in		when forwarding a Map-Request to an ETR as documented in LISP-MS
	[LISP-MS].		[RFC6833].
	DDT Map-Request: an Encapsulated Map-Request sent by a DDT client		DDT Map-Request: an Encapsulated Map-Request sent by a DDT client
	to a DDT node. The "DDT-originated" flag is set in the		to a DDT node. The "DDT-originated" flag is set in the
	encapsulation header indicating that the DDT node should return		encapsulation header indicating that the DDT node should return
	Map-Referral messages if the Map-Request EID matches a delegated		Map-Referral messages if the Map-Request EID matches a delegated
	XEID-prefix known to the DDT node. Section 5.3.1 describes how		XEID-prefix known to the DDT node. Section 5.3.1 describes how
	DDT Map-Requests are sent.		DDT Map-Requests are sent.
	Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node		Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node
	and for which the DDT node may provide further delegations of		and for which the DDT node may provide further delegations of
	skipping to change at page 7, line 47		skipping to change at page 6, line 38
	requestor(s) of the XEID (typically, one or more ITRs), saved		requestor(s) of the XEID (typically, one or more ITRs), saved
	information about the last referral received and followed		information about the last referral received and followed
	(matching XEID-prefix, action code, RLOC set, index of last RLOC		(matching XEID-prefix, action code, RLOC set, index of last RLOC
	queried in the RLOC set), and any [LISP-SEC] information that was		queried in the RLOC set), and any [LISP-SEC] information that was
	included in the DDT client Map-Request. An entry in the list may		included in the DDT client Map-Request. An entry in the list may
	be interchangeably termed a "pending request list entry" or simply		be interchangeably termed a "pending request list entry" or simply
	a "pending request".		a "pending request".
	For definitions of other terms, notably Map-Request, Map-Reply,		For definitions of other terms, notably Map-Request, Map-Reply,
	Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server,		Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server,
	and Map Resolver, please consult the LISP specification [LISP] and		and Map Resolver, please consult the LISP specification [RFC6830] and
	the LISP Mapping Service specification [LISP-MS].		the LISP Mapping Service specification [RFC6833].
	3. Database organization		3. Database organization
	3.1. EID-prefix tree structure and instance IDs		3.1. EID-prefix tree structure and instance IDs
	LISP-DDT defines a tree structure that is indexed by a binary		LISP-DDT defines a tree structure that is indexed by a binary
	encoding of five fields, in order of significance: DBID (16 bits),		encoding of five fields, in order of significance: DBID (16 bits),
	Instance Identifier (IID, 32 bits), Address Family Identifier (AFI,		Instance Identifier (IID, 32 bits), Address Family Identifier (AFI,
	16 bits), and EID-prefix (variable, according to AFI value). The		16 bits), and EID-prefix (variable, according to AFI value). The
	fields are concatenated, with the most significant fields as listed		fields are concatenated, with the most significant fields as listed
	skipping to change at page 13, line 26		skipping to change at page 10, line 39
	o If the requested XEID matches a configured XEID-prefix for which		o If the requested XEID matches a configured XEID-prefix for which
	no ETR registration has been received then a negative Map-Referral		no ETR registration has been received then a negative Map-Referral
	with action code MS-NOT-REGISTERED is returned to the sender of		with action code MS-NOT-REGISTERED is returned to the sender of
	the DDT Map-Request.		the DDT Map-Request.
	5.3. DDT Map Resolver		5.3. DDT Map Resolver
	Just as any other Map Resolver, a DDT Map Resolver accepts Map-		Just as any other Map Resolver, a DDT Map Resolver accepts Map-
	Requests from its clients (typically, ITRs) and ensures that those		Requests from its clients (typically, ITRs) and ensures that those
	Map-Requests are forwarded to the correct ETR, which generates Map-		Map-Requests are forwarded to the correct ETR, which generates Map-
	Replies. Unlike a Map Resolver that uses the ALT mapping system		Replies. Unlike a Map Resolver that uses the ALT mapping system (see
	[LISP-ALT], however, a DDT Map Resolver uses an iterative process of		[RFC6836]), however, a DDT Map Resolver uses an iterative process of
	following referrals to find the correct ETR to answer a Map-Request;		following referrals to find the correct ETR to answer a Map-Request;
	this requires a DDT Map Resolver to maintain additional state: a Map-		this requires a DDT Map Resolver to maintain additional state: a Map-
	Referral cache and pending request list of XEIDs that are going		Referral cache and pending request list of XEIDs that are going
	through the iterative referral process.		through the iterative referral process.
	5.3.1. Queuing and sending DDT Map-Requests		5.3.1. Queuing and sending DDT Map-Requests
	When a DDT Map Resolver receives an encapsulated Map-Request, it		When a DDT Map Resolver receives an encapsulated Map-Request, it
	first performs a longest-match search for the XEID in its referral		first performs a longest-match search for the XEID in its referral
	cache. If no match is found or if a negative cache entry is found,		cache. If no match is found or if a negative cache entry is found,
	then the destination is not in the database; a negative Map-Reply is		then the destination is not in the database; a negative Map-Reply is
	returned and no further processing is performed by the DDT Map		returned and no further processing is performed by the DDT Map
	Resolver.		Resolver.
	If a match is found, the DDT Map Resolver creates a pending request		If a match is found, the DDT Map Resolver creates a pending request
	list entry for the XEID and saves the original Map-Request (minus the		list entry for the XEID and saves the original Map-Request (minus the
	encapsulation header) along with other information needed to track		encapsulation header) along with other information needed to track
	skipping to change at page 21, line 6		skipping to change at page 19, line 4
	}		}
	}		}
	case DEFAULT:		case DEFAULT:
	drop		drop
	}		}
	}		}
	6.2.2. Decision tree diagram		6.2.2. Decision tree diagram
			+------------+
	+------------+		| Is Request | No
	| Is Request | No		| Pending? |----> Silently drop
	| Pending? |----> Silently drop		+------------+
	+------------+		| Yes
	| Yes		V
	V		+------------------------------+ Yes
	+------------------------------+ Yes		| Pfx less specific than last? |----> Silently drop
	| Pfx less specific than last? |----> Silently drop		+------------------------------+
	+------------------------------+		|No
	|No		V
	V		+---------------------------------------------------+
	+---------------------------------------------------+		| What is Map-Referral Type? |--UNKNOWN-+
	| What is Map-Referral Type? |--UNKNOWN-+		+---------------------------------------------------+ |
	+---------------------------------------------------+ |		| | | | | | V
	| | | | | | V		| | | | | DEL_HOLE DROP
	| | | | | DEL_HOLE DROP		| | | | MS_ACK |
	| | | | MS_ACK |		| | | | | V
	| | | | | V		| | MS_REF NODE_REF | Cache & return
	| | MS_REF NODE_REF | Cache & return		| | | | V negative map-reply
	| | | | V negative map-reply		| | | | +---------+
	| | | | +---------+		| NOT_AUTH | | | Was OTK | Yes
	| NOT_AUTH | | | Was OTK | Yes		| | | | |Stripped?|----> Done
	| | | | |Stripped?|----> Done		| | V V +---------+
	| | V V +---------+		| | +------------+ | No
	| | +------------+ | No		| | Yes | Pfx equal | V
	| | Yes | Pfx equal | V		MS_NOT_REGISTERED | +---| to last | +------------+
	MS_NOT_REGISTERED | +---| to last | +------------+		| | | | used? | | Incomplete | Yes
	| | | | used? | | Incomplete | Yes		| | | +------------+ | bit set? |---> Resend DDT
	| | | +------------+ | bit set? |---> Resend DDT		| V V |No +------------+ request
	| V V |No +------------+ request		| +------------+ | |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 |----> Dont 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 23, line 7		skipping to change at page 20, line 49
	}		}
	}		}
	} else {		} else {
	send map-referral DELEGATION_HOLE with		send map-referral DELEGATION_HOLE with
	ttl 'Default_Negative_Referral_Ttl'		ttl 'Default_Negative_Referral_Ttl'
	}		}
	}		}
	6.3.2. Decision tree diagram		6.3.2. Decision tree diagram
	+------------+		+------------+
	| Am I | No		| Am I | No
	| Authori- |----> Return NOT_AUTHORITATIVE		| Authori- |----> Return NOT_AUTHORITATIVE
	| tative? | Incomplete = 1		| tative? | Incomplete = 1
	+------------+ ttl = Default_DdtNode_Ttl		+------------+ ttl = Default_DdtNode_Ttl
	|		|
	|Yes		|Yes
	|		|
	V		V
	+------------+ +------------+		+------------+ +------------+
	| Delegation | Yes | Delegations| Yes		| Delegation | Yes | Delegations| Yes
	| Exists? |---->| are map |----> Return MS_REFERRAL		| Exists? |---->| are map |----> Return MS_REFERRAL
	| | | servers? | ttl = Default_DdtNode_Ttl		| | | servers? | ttl = Default_DdtNode_Ttl
	+------------+ +------------+		+------------+ +------------+
	| \ No		| \ No
	|No +--> Return NODE_REFERRAL		|No +--> Return NODE_REFERRAL
	| ttl = Default_DdtNode_Ttl		| ttl = Default_DdtNode_Ttl
	V		V
	+------------+ +------------+ +------------+		+------------+ +------------+ +------------+
	| EID in | Yes | Site | Yes | Map-server |		| EID in | Yes | Site | Yes | Map-server |
	| Site |---->| Registered?|----> Forward---->| peers |		| Site |---->| Registered?|----> Forward---->| peers |
	| Config? | | | Map-request | configured?|		| Config? | | | Map-request | configured?|
	+------------+ +------------+ to ETR +------------+		+------------+ +------------+ to ETR +------------+
	| | | |		| | | |
	| |No No| |Yes		| |No No| |Yes
	| | | |		| | | |
	| | V V		| | V V
	| | Return MS_ACK Return MS_ACK		| | Return MS_ACK Return MS_ACK
	| V with INC=1		| V with INC=1
	| +------------+ ttl=Default_Registered_Ttl		| +------------+ ttl=Default_Registered_Ttl
	| | Map-server | Yes		| | Map-server | Yes
	| | peers |----> Return MS_NOT_REGISTERED		| | peers |----> Return MS_NOT_REGISTERED
	| | configured?| ttl = Default_Negative_Referral_Ttl		| | configured?| ttl = Default_Negative_Referral_Ttl
	| +------------+		| +------------+
	| \ No		| \ No
	|No +--> Return MS_NOT_REGISTERED		|No +--> Return MS_NOT_REGISTERED
	| Incomplete = 1		| Incomplete = 1
	V ttl = Default_Negative_Referral_Ttl		V ttl = Default_Negative_Referral_Ttl
	Return DELEGATION_HOLE		Return DELEGATION_HOLE
	ttl = Default_Negative_Referral_Ttl		ttl = Default_Negative_Referral_Ttl
	7. Example topology and request/referral following		7. Example topology and request/referral following
	To show how referrals are followed to find the RLOCs for a number of		To show how referrals are followed to find the RLOCs for a number of
	EIDs, consider the following example EID topology for DBID=0, IID=0,		EIDs, consider the following example EID topology for DBID=0, IID=0,
	AFI=1, and EID=0/0		AFI=1, and EID=0/0
			+---------------------+ +---------------------+
	+---------------------+ +---------------------+		| root1: 192.0.2.1 | | root2: 192.0.2.2 |
	| root1: 192.0.2.1 | | root2: 192.0.2.2 |		| authoritative: 0/0 | | authoritative: 0/0 |
	| authoritative: 0/0 | | authoritative: 0/0 |		+---------------------+ +---------------------+
	+---------------------+ +---------------------+		| \ / |
	| \ / |		| \ / |
	| \ / |		| / \ |
	| / \ |		| / \ |
	| / \ |		| | | |
	| | | |		V V V V
	V V V V		+--------------------------+ +--------------------------+
	+--------------------------+ +--------------------------+		| DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 |
	| DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 |		| authoritative: 10.0.0.0/8| | authoritative: 10.0.0.0/8|
	| authoritative: 10.0.0.0/8| | authoritative: 10.0.0.0/8|		+--------------------------+ +--------------------------+
	+--------------------------+ +--------------------------+		| \ / |
	| \ / |		| \ / |
	| \ / |		| / \ |
	| / \ |		| / \ |
	| / \ |		| | | |
	| | | |		V V V V
	V V V V		+--------------------------+ +---------------------------+
	+--------------------------+ +---------------------------+		| Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 |
	| Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 |		|authoritative: 10.0.0.0/12| |authoritative: 10.16.0.0/12|
	|authoritative: 10.0.0.0/12| |authoritative: 10.16.0.0/12|		| site1: 10.1.0.0/16 | +---------------------------+
	| site1: 10.1.0.0/16 | +---------------------------+		| site2: 10.2.0.0/16 | | |
	| site2: 10.2.0.0/16 | | |		+--------------------------+ | |
	+--------------------------+ | |		| |
	| |		| |
	| |		V V
	V V		+---------------------------+ +---------------------------+
	+---------------------------+ +---------------------------+		| Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 |
	| Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 |		|authoritative: 10.16.0.0/16| |authoritative: 10.17.0.0/16|
	|authoritative: 10.16.0.0/16| |authoritative: 10.17.0.0/16|		| site3: 10.16.1.0/24 | | site5: 10.17.8.0/24 |
	| site3: 10.16.1.0/24 | | site5: 10.17.8.0/24 |		| site4: 10.16.2.0/24 | | site6: 10.17.9.0/24 |
	| site4: 10.16.2.0/24 | | site6: 10.17.9.0/24 |		+---------------------------+ +---------------------------+
	+---------------------------+ +---------------------------+
	DDT nodes are configured for this "root" at IP addresses 192.0.2.1		DDT nodes are configured for this "root" at IP addresses 192.0.2.1
	and 192.0.2.2. DDT Map Resolvers are configured with default		and 192.0.2.2. DDT Map Resolvers are configured with default
	referral cache entries to these addresses.		referral cache entries to these addresses.
	The root DDT nodes delegate 10.0.0/8 to two DDT nodes with IP		The root DDT nodes delegate 10.0.0/8 to two DDT nodes with IP
	addresses 192.0.2.11 and 192.0.2.12.		addresses 192.0.2.11 and 192.0.2.12.
	The DDT nodes for 10.0.0.0/8 delegate 10.0.0.0/12 to a DDT Map Server		The DDT nodes for 10.0.0.0/8 delegate 10.0.0.0/12 to a DDT Map Server
	with RLOC 192.0.2.101		with RLOC 192.0.2.101
	The DDT Map Server for 10.0.0.0/12 is configured to allow ETRs to		The DDT Map Server for 10.0.0.0/12 is configured to allow ETRs to
	register the sub-prefixes 10.1.0.0/16 and 10.2.0.0/16		register the sub-prefixes 10.1.0.0/16 and 10.2.0.0/16
	The DDT nodes for 10.0.0.0/8 also delegate 10.16.0.0/12 to a DDT node		The DDT nodes for 10.0.0.0/8 also delegate 10.16.0.0/12 to a DDT node
	with RLOC 192.0.2.201		with RLOC 192.0.2.201
	The DDT node for 10.16.0.0/12 is further configured to delegate		The DDT node for 10.16.0.0/12 is further configured to delegate
	10.16.0.0/16 to a DDT Map Server with RLOC 192.0.2.211 and		10.16.0.0/16 to a DDT Map Server with RLOC 192.0.2.211 and 10.17.0.0/
	10.17.0.0/16 to a DDT Map Server with RLOC 192.0.2.221		16 to a DDT Map Server with RLOC 192.0.2.221
	The DDT Map Server for 10.16.0.0/16 is configured to allow ETRs to		The DDT Map Server for 10.16.0.0/16 is configured to allow ETRs to
	register the sub-prefixes 10.16.1.0/24 and 10.16.2.0/24		register the sub-prefixes 10.16.1.0/24 and 10.16.2.0/24
	The DDT Map Server for 10.17.0.0/16 is configured to allow ETRs to		The DDT Map Server for 10.17.0.0/16 is configured to allow ETRs to
	register the sub-prefixes 10.17.8.0/24 and 10.17.9.0/24		register the sub-prefixes 10.17.8.0/24 and 10.17.9.0/24
	7.1. Lookup of 10.1.1.1/32 by ITR1		7.1. Lookup of 10.1.1.1/32 by ITR1
	The first example shows a DDT Map Resolver following a delegation		The first example shows a DDT Map Resolver following a delegation
	skipping to change at page 32, line 10		skipping to change at page 29, line 46
	public keys of the children DDT nodes. The Map Resolver must add		public keys of the children DDT nodes. The Map Resolver must add
	these keys to the authenticated keys associated with each child DDT		these keys to the authenticated keys associated with each child DDT
	node and XEID-prefix. These keys are considered valid for the		node and XEID-prefix. These keys are considered valid for the
	duration specified in the record's TTL field.		duration specified in the record's TTL field.
	9. Open Issues and Considerations		9. Open Issues and Considerations
	There are a number of issues with the organization of the mapping		There are a number of issues with the organization of the mapping
	database that need further investigation. Among these are:		database that need further investigation. Among these are:
	o Unlike in [LISP-ALT], DDT does not currently define a mechanism		o Unlike in LISP-ALT (see [RFC6836]), DDT does not currently define
	for propagating ETR-to-Map Server registration state. This		a mechanism for propagating ETR-to-Map Server registration state.
	requires DDT Map Servers to suppress returning negative Map-Reply		This requires DDT Map Servers to suppress returning negative Map-
	messages for defined but unregistered XEID-prefixes to avoid loss		Reply messages for defined but unregistered XEID-prefixes to avoid
	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 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 Authentication of delegations between DDT nodes.		o Authentication of delegations between DDT nodes.
	skipping to change at page 35, line 10		skipping to change at page 31, line 10
	One-Time Key) from a Map-Resolver to the corresponding Map-Server.		One-Time Key) from a Map-Resolver to the corresponding Map-Server.
	For this reason, when LISP-SEC is deployed in conjunction with a		For this reason, when LISP-SEC is deployed in conjunction with a
	LISP-DDT mapping database and the path between Map-Resolver and Map-		LISP-DDT mapping database and the path between Map-Resolver and Map-
	Server needs to be protected, DDT security should be enabled as well.		Server needs to be protected, DDT security should be enabled as well.
	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", draft-ietf-lisp-lcaf-00.txt (work in		Address Format", draft-ietf-lisp-lcaf-02.txt (work in
	progress), August 2012.		progress), March 2013.
	[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-23.txt (work in progress), May 2012.
	[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server Interface",
	draft-ietf-lisp-ms-16.txt (work in progress), March 2012.
	[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, November 1987.
	[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
	February 1997.		1997.
	[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms		[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
	(SHA and HMAC-SHA)", RFC 4634, July 2006.		(SHA and HMAC-SHA)", RFC 4634, July 2006.
	[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)		[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
	Trust Anchors", RFC 5011, September 2007.		Trust Anchors", STD 74, RFC 5011, September 2007.
	12.2. Informative References		[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
			Locator/ID Separation Protocol (LISP)", RFC 6830, January
			2013.
	[LISP-ALT]		[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
	Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP		Protocol (LISP) Map-Server Interface", RFC 6833, January
	Alternative Topology (LISP-ALT)",		2013.
	draft-ietf-lisp-alt-10.txt (work in progress),
	December 2011.		12.2. Informative References
	[LISP-SEC]		[LISP-SEC]
	Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O.		Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O.
	Bonaventure, "LISP-Security", draft-ietf-lisp-sec-03.txt		Bonaventure, "LISP-Security", draft-ietf-lisp-sec-04.txt
	(work in progress), September 2012.		(work in progress), October 2012.
	[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and		[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
	E. Lear, "Address Allocation for Private Internets",		E. Lear, "Address Allocation for Private Internets", BCP
	BCP 5, RFC 1918, February 1996.		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, February 2012.
			[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
			"Locator/ID Separation Protocol Alternative Logical
			Topology (LISP+ALT)", RFC 6836, January 2013.
	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, and Olivier Bonaventure for work on LISP-TREE and LISP		Jakab, Olivier Bonaventure, Albert Cabellos-Asparicio, and FLorin
	iterable mappings that inspired the hierarchical database structure		Coras for work on LISP-TREE and LISP iterable mappings that inspired
	and lookup iteration approach described in this document. Thanks		the hierarchical database structure and lookup iteration approach
	also go to Dino Farinacci and Isidor Kouvelas for their		described in this document. Thanks also go to Dino Farinacci and
	implementation work; to Selina Heimlich and Srin Subramanian for		Isidor Kouvelas for their implementation work; to Selina Heimlich and
	testing; to Fabio Maino for work on security processing; and to Job		Srin Subramanian for testing; to Fabio Maino for work on security
	Snijders, Glen Wiley, Neel Goyal, and Mike Gibbs for work on		processing; and to Job Snijders, Glen Wiley, Neel Goyal, and Mike
	operational considerations and initial deployment of a prototype		Gibbs for work on operational considerations and initial deployment
	database infrastructure. Special thanks go to Jesper Skriver, Andrew		of a prototype database infrastructure. Special thanks go to Jesper
	Partan, and Noel Chiappa; all of whom have participated in (and put		Skriver, Andrew Partan, and Noel Chiappa; all of whom have
	up with) seemingly endless hours of discussion of mapping database		participated in (and put up with) seemingly endless hours of
	ideas, concepts, and issues.		discussion of mapping database ideas, concepts, and issues.
	Appendix B. Map-Referral Message Format		Appendix B. Map-Referral Message Format
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Type=6 | Reserved | Record Count |		|Type=6 | Reserved | Record Count |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Nonce . . . |		| Nonce . . . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 37, line 39		skipping to change at page 33, line 7
	+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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
	skipping to change at page 39, line 10		skipping to change at page 34, line 27
	end of the Record must match the SigCnt.		end of the Record must match the SigCnt.
	Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the		Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the
	record. If this is a LCAF AFI, the contents of the LCAF depend on		record. If this is a LCAF AFI, the contents of the LCAF depend on
	the Type field of the LCAF. Security material are stored in LCAF		the Type field of the LCAF. Security material are stored in LCAF
	Type 11. DDT nodes and Map Servers can use this LCAF Type to include		Type 11. DDT nodes and Map Servers can use this LCAF Type to include
	public keys associated with their Child DDT nodes for a XEID-prefix		public keys associated with their Child DDT nodes for a XEID-prefix
	referral record. LCAF types and formats are defined in [LCAF].		referral record. LCAF types and formats are defined in [LCAF].
	All the field descriptions are equivalent to those in the Map-Reply		All the field descriptions are equivalent to those in the Map-Reply
	message, as defined in [LISP]. Note, though, that the set of RLOCs		message, as defined in LISP [RFC6830]. Note, though, that the set of
	correspond to the DDT node to be queried as a result of the referral		RLOCs correspond to the DDT node to be queried as a result of the
	not the RLOCs for an actual EID-to-RLOC mapping.		referral not the RLOCs for an actual EID-to-RLOC mapping.
	B.1. SIG section		B.1. SIG section
	If SigCnt field in the Map-Referral is not 0, the signature		If SigCnt field in the Map-Referral is not 0, the signature
	information is included at the end of captured in a sig section as		information is included at the end of captured in a sig section as
	described below. SigCnt counts the number of sig sections that		described below. SigCnt counts the number of sig sections that
	appear at the end of the Record.		appear at the end of the Record.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/| Original Record TTL |		/| Original Record TTL |
	skipping to change at page 42, line 8		skipping to change at page 36, line 35
	LCM | LISP Control Message |		LCM | LISP Control Message |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	"D" is the "DDT-originated" flag and is set by a DDT client to		"D" is the "DDT-originated" flag and is set by a DDT client to
	indicate that the receiver can and should return Map-Referral		indicate that the receiver can and should return Map-Referral
	messages as appropriate.		messages as appropriate.
	Authors' Addresses		Authors' Addresses
	Vince Fuller		Vince Fuller
	cisco Systems
	Tasman Drive
	San Jose, CA 95134
	USA
	Email: vaf@cisco.com		Email: vaf@vaf.net
	Darrel Lewis		Darrel Lewis
	cisco Systems		cisco Systems
	Tasman Drive		Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: darlewis@cisco.com		Email: darlewis@cisco.com
	Vina Ermagan		Vina Ermagan
	cisco Systems		cisco Systems
	Tasman Drive		Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: vermagan@cisco.com		Email: vermagan@cisco.com
	Amit Jain		Amit Jain
	cisco Systems		Juniper Networks
	Tasman Drive		1133 Innovation Way
	San Jose, CA 95134		Sunnyvale, CA 94089
	USA		USA
	Email: amijain@cisco.com		Email: atjain@juniper.net
End of changes. 35 change blocks.
	251 lines changed or deleted		243 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/