rfc6731v1.txt		rfc6731.txt
	skipping to change at page 2, line 30		skipping to change at page 2, line 30
	3.3. VPN Scenario . . . . . . . . . . . . . . . . . . . . . . . 8		3.3. VPN Scenario . . . . . . . . . . . . . . . . . . . . . . . 8
	3.4. Dual-Stack Accesses . . . . . . . . . . . . . . . . . . . 8		3.4. Dual-Stack Accesses . . . . . . . . . . . . . . . . . . . 8
	4. Improved RDNSS Selection . . . . . . . . . . . . . . . . . . . 8		4. Improved RDNSS Selection . . . . . . . . . . . . . . . . . . . 8
	4.1. Procedure for Prioritizing RDNSSes and Handling		4.1. Procedure for Prioritizing RDNSSes and Handling
	Responses . . . . . . . . . . . . . . . . . . . . . . . . 8		Responses . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. RDNSS Selection DHCPv6 Option . . . . . . . . . . . . . . 11		4.2. RDNSS Selection DHCPv6 Option . . . . . . . . . . . . . . 11
	4.3. RDNSS Selection DHCPv4 Option . . . . . . . . . . . . . . 13		4.3. RDNSS Selection DHCPv4 Option . . . . . . . . . . . . . . 13
	4.4. Scalability Considerations . . . . . . . . . . . . . . . . 15		4.4. Scalability Considerations . . . . . . . . . . . . . . . . 15
	4.5. Limitations on Use . . . . . . . . . . . . . . . . . . . . 15		4.5. Limitations on Use . . . . . . . . . . . . . . . . . . . . 15
	4.6. Coexistence of Various RDNSS Configuration Tools . . . . . 16		4.6. Coexistence of Various RDNSS Configuration Tools . . . . . 16
	4.7. Considerations on Follow-Up Queries . . . . . . . . . . . 16		4.7. Considerations on Follow-Up Queries . . . . . . . . . . . 17
	4.8. Closing Network Interfaces and Local Caches . . . . . . . 17		4.8. Closing Network Interfaces and Local Caches . . . . . . . 17
	5. Example of a Node Behavior . . . . . . . . . . . . . . . . . . 17		5. Example of a Node Behavior . . . . . . . . . . . . . . . . . . 17
	6. Considerations for Network Administrators . . . . . . . . . . 19		6. Considerations for Network Administrators . . . . . . . . . . 19
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 20		8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	8.1. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . 20		8.1. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . 20
	8.2. Trust Levels of Network Interfaces . . . . . . . . . . . . 21		8.2. Trust Levels of Network Interfaces . . . . . . . . . . . . 21
	8.3. Importance of Following the Algorithm . . . . . . . . . . 21		8.3. Importance of Following the Algorithm . . . . . . . . . . 21
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 21		9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	A.2. Search List Option for DNS Forward Lookup Decisions . . . 23		A.2. Search List Option for DNS Forward Lookup Decisions . . . 23
	A.3. More-Specific Routes for Reverse Lookup Decisions . . . . 24		A.3. More-Specific Routes for Reverse Lookup Decisions . . . . 24
	A.4. Longest Matching Prefix for Reverse Lookup Decisions . . . 24		A.4. Longest Matching Prefix for Reverse Lookup Decisions . . . 24
	Appendix B. DNSSEC and Multiple Answers Validating with		Appendix B. DNSSEC and Multiple Answers Validating with
	Different Trust Anchors . . . . . . . . . . . . . . . 24		Different Trust Anchors . . . . . . . . . . . . . . . 24
	Appendix C. Pseudocode for RDNSS Selection . . . . . . . . . . . 24		Appendix C. Pseudocode for RDNSS Selection . . . . . . . . . . . 24
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 29		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	A multi-interfaced node faces several problems a single-homed node		A multi-interfaced node (MIF node) faces several problems a single-
	does not encounter, as is described in [RFC6418]. This document		homed node does not encounter, as is described in [RFC6418]. This
	studies in detail the problems private namespaces might cause for		document studies in detail the problems private namespaces might
	multi-interfaced nodes and provides a solution. The node might be		cause for multi-interfaced nodes and provides a solution. The node
	implemented as a host or as a router.		might be implemented as a host or as a router.
	We start from the premise that network operators sometimes include		We start from the premise that network operators sometimes include
	private, but still globally unique, namespaces in the answers they		private, but still globally unique, namespaces in the answers they
	provide from Recursive DNS Servers (RDNSSes) and that those private		provide from Recursive DNS Servers (RDNSSes) and that those private
	namespaces are at least as useful to nodes as the answers from the		namespaces are at least as useful to nodes as the answers from the
	public DNS. When private namespaces are visible for a node, some		public DNS. When private namespaces are visible for a node, some
	RDNSSes have information other RDNSSes do not have. The node ought		RDNSSes have information other RDNSSes do not have. The node ought
	to be able to query the RDNSS that can resolve the query regardless		to be able to query the RDNSS that can resolve the query regardless
	of whether the answer comes from the public DNS or a private		of whether the answer comes from the public DNS or a private
	namespace.		namespace.
	skipping to change at page 3, line 45		skipping to change at page 3, line 45
	additional routing and source and destination address selection		additional routing and source and destination address selection
	policies (e.g., [RFC4191] and [RFC3442].		policies (e.g., [RFC4191] and [RFC3442].
	This document is organized in the following manner. Background		This document is organized in the following manner. Background
	information about problem descriptions and example deployment		information about problem descriptions and example deployment
	scenarios are included in Sections 2 and 3. Section 4 contains all		scenarios are included in Sections 2 and 3. Section 4 contains all
	normative descriptions for DHCP options and node behavior.		normative descriptions for DHCP options and node behavior.
	Section 4.4 contains informational considerations about scalability.		Section 4.4 contains informational considerations about scalability.
	Informative Section 5 illustrates behavior of a node implementing		Informative Section 5 illustrates behavior of a node implementing
	functionality described in Section 4. Section 6 contains normative		functionality described in Section 4. Section 6 contains normative
	guidelines related to creation of private namespaces. Informational		guidelines related to creation of private namespaces. The IANA
	Section 8 summarizes identified security considerations.		considerations are in Section 7. Informational Section 8 summarizes
			identified security considerations.
	Appendix A describes best current practices that are possible with		Appendix A describes best current practices that are possible with
	tools preceding this document and that are possibilities on networks		tools preceding this document and that are possibilities on networks
	not supporting the solution described in this document.		not supporting the solution described in this document. Appendix B
			discusses a scenario where multiple answers are possible to validate,
			but with different trust anchors. Appendix C illustrates with
			pseudocode the functionality described in Section 4.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Private Namespaces and Problems for Multi-Interfaced Nodes		2. Private Namespaces and Problems for Multi-Interfaced Nodes
	This section describes two private namespace scenarios related to		This section describes two private namespace scenarios related to
	skipping to change at page 9, line 12		skipping to change at page 9, line 12
	A resolver SHALL build a preference list of RDNSSes it will contact		A resolver SHALL build a preference list of RDNSSes it will contact
	depending on the query. To build the list in an optimal way, a node		depending on the query. To build the list in an optimal way, a node
	SHALL ask, with the DHCP options defined in Sections 4.2 and the 4.3,		SHALL ask, with the DHCP options defined in Sections 4.2 and the 4.3,
	which RDNSSes of each network interface are most likely to be able to		which RDNSSes of each network interface are most likely to be able to
	successfully serve forward lookup requests matching to a specific		successfully serve forward lookup requests matching to a specific
	domain or reverse (PTR record) lookup requests matching to specific		domain or reverse (PTR record) lookup requests matching to specific
	network addresses (later referred as "network").		network addresses (later referred as "network").
	A resolver lacking more specific information can assume that all		A resolver lacking more specific information can assume that all
	information is available from any RDNSS of any network interface.		information is available from any RDNSS of any network interface.
	The RDNSSes learned by other RDNSS address configuration methods MUST		The RDNSSes learned by other RDNSS address configuration methods can
	be handled as default, the medium, preference default RDNSSes (see		be considered as default RDNSSes, but preference-wise, they MUST be
	also Section 4.6).		handled as medium preference RDNSSes (see also Section 4.6).
	When a DNS query needs to be made, the resolver MUST give highest		When a DNS query needs to be made, the resolver MUST give highest
	preference to the RDNSSes explicitly known to serve a matching domain		preference to the RDNSSes explicitly known to serve a matching domain
	or network. The resolver MUST take into account differences in trust		or network. The resolver MUST take into account differences in trust
	levels (see Section 8.2) of pieces of received RDNSS selection		levels (see Section 8.2) of pieces of received RDNSS selection
	information. The resolver MUST prefer RDNSSes of trusted interfaces.		information. The resolver MUST prefer RDNSSes of trusted interfaces.
	The RDNSSes of untrusted interfaces can be of highest preference only		The RDNSSes of untrusted interfaces can be of highest preference only
	if the trusted interfaces specifically configures low preference		if the trusted interfaces specifically configures low preference
	RDNSSes. The non-exhaustive list of cases in Figure 4 illustrates		RDNSSes. The non-exhaustive list of cases in Figure 4 illustrates
	how the different trust levels of received RDNSS selection		how the different trust levels of received RDNSS selection
	skipping to change at page 10, line 29		skipping to change at page 10, line 29
	--------------------------+------------------------+-----------------		--------------------------+------------------------+-----------------
	4. Low preference default | Medium preference | Default:		4. Low preference default | Medium preference | Default:
	| default | B, then A		| default | B, then A
	Specific domains | | Specific:		Specific domains | | Specific:
	| | A, then B		| | A, then B
	--------------------------+------------------------+-----------------		--------------------------+------------------------+-----------------
	Figure 4: RDNSS Selection in the Case of Different Trust Levels		Figure 4: RDNSS Selection in the Case of Different Trust Levels
	Because DNSSEC provides cryptographic assurance of the integrity of		Because DNSSEC provides cryptographic assurance of the integrity of
	DNS data, data that can be validated under DNSSEC is necessarily to		DNS data, it is necessary to prefer data that can be validated under
	be preferred over data that cannot be. There are two ways that a		DNSSEC over data that cannot. There are two ways that a node can
	node can determine that data is valid under DNSSEC. The first is to		determine that data is valid under DNSSEC. The first is to perform
	perform DNSSEC validation itself. The second is to have a secure		DNSSEC validation itself. The second is to have a secure connection
	connection to an authenticated RDNSS and to rely on that RDNSS to		to an authenticated RDNSS and to rely on that RDNSS to perform DNSSEC
	perform DNSSEC validation (signaling that it has done so using the AD		validation (signaling that it has done so using the AD bit). DNSSEC
	bit). DNSSEC is necessary to detect forged responses, and without it		is necessary to detect forged responses, and without it any DNS
	any DNS response could be forged or altered. Unless the DNS		response could be forged or altered. Unless the DNS responses have
	responses have been validated with DNSSEC, a node cannot make a		been validated with DNSSEC, a node cannot make a decision to prefer
	decision to prefer data from any interface with any great assurance.		data from any interface with any great assurance.
	A node SHALL send requests to RDNSSes in the order defined by the		A node SHALL send requests to RDNSSes in the order defined by the
	preference list until an acceptable reply is received, all replies		preference list until an acceptable reply is received, all replies
	are received, or a timeout occurs. In the case of a requested name		are received, or a timeout occurs. In the case of a requested name
	matching to a specific domain or network rule accepted from any		matching to a specific domain or network rule accepted from any
	interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that		interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that
	cannot be validated using DNSSEC until all RDNSSes on the preference		cannot be validated using DNSSEC until all RDNSSes on the preference
	list have been contacted or timed out. This protects against		list have been contacted or timed out. This protects against
	possible redirection attacks. In the case of the requested name not		possible redirection attacks. In the case of the requested name not
	matching to any specific domain or network, the first received		matching to any specific domain or network, the first received
	skipping to change at page 16, line 20		skipping to change at page 16, line 20
	For RDNSS selection purposes, information received from all tools		For RDNSS selection purposes, information received from all tools
	MUST be combined together into a single list, as discussed in		MUST be combined together into a single list, as discussed in
	Section 4.1.		Section 4.1.
	It can happen that DHCPv4 and DHCPv6 are providing conflicting RDNSS		It can happen that DHCPv4 and DHCPv6 are providing conflicting RDNSS
	selection information on the same or on equally trusted interfaces.		selection information on the same or on equally trusted interfaces.
	In such a case, DHCPv6 MUST be preferred unless DHCPv4 is utilizing		In such a case, DHCPv6 MUST be preferred unless DHCPv4 is utilizing
	additional security frameworks for protecting the messages.		additional security frameworks for protecting the messages.
	The RDNSSes learned via tools other than OPTION_DNS_SERVER_SELECT		The RDNSSes learned via tools other than the DHCPv4 RDNSS Selection
	MUST be handled as default RDNSSes, with medium preference, when		option and the DHCPv6 OPTION_RDNSS_SELECTION MUST be handled as
	building a list of RDNSSes to talk to (see Section 4.1).		default RDNSSes, with medium preference, when building a list of
			RDNSSes to talk to (see Section 4.1).
	The non-exhaustive list of possible other sources for RDNSS address		The non-exhaustive list of possible other sources for RDNSS address
	configuration are:		configuration are:
	(1) DHCPv6 OPTION_DNS_SERVERS defined in [RFC3646].		(1) DHCPv6 OPTION_DNS_SERVERS defined in [RFC3646].
	(2) DHCPv4 Domain Name Server Option defined in [RFC2132].		(2) DHCPv4 Domain Server option defined in [RFC2132].
	(3) IPv6 Router Advertisement RDNSS Option defined in [RFC6106].		(3) IPv6 Router Advertisement RDNSS Option defined in [RFC6106].
	When OPTION_RDNSS_SELECTION contains a default RDNSS address and		When the RDNSS selection option contains a default RDNSS address and
	other sources are providing RNDSS addresses, the resolver MUST make		other sources are providing RNDSS addresses, the resolver MUST make
	the decision about which one to prefer based on the RDNSS preference		the decision about which one to prefer based on the RDNSS preference
	field value. If OPTION_RDNSS_SELECTION defines medium preference,		field value. If the RDNSS selection option defines medium
	then the RDNSS from OPTION_RDNSS_SELECTION SHALL be selected.		preference, then the RDNSS from the RDNSS selection option SHALL be
			selected.
	If multiple sources are providing same RDNSS(es) IP address(es), each		If multiple sources are providing same RDNSS(es) IP address(es), each
	address MUST be added to the RDNSS list only once.		address MUST be added to the RDNSS list only once.
	If a node had indicated support for OPTION_RDNSS_SELECTION in a		If a node had indicated support for OPTION_RDNSS_SELECTION in a
	DHCPv6 request, the DHCPv6 server MAY omit sending of		DHCPv6 request, the DHCPv6 server MAY omit sending of
	OPTION_DNS_SERVERS. This enables offloading use case where the		OPTION_DNS_SERVERS. This enables offloading use case where the
	network administrator wishes to only advertise low preference default		network administrator wishes to only advertise low preference default
	RDNSSes.		RDNSSes.
	skipping to change at page 19, line 9		skipping to change at page 19, line 9
	4. The node opens its second network interface 2.		4. The node opens its second network interface 2.
	5. The node obtains domain 'domain2.example.com' and IPv6 network		5. The node obtains domain 'domain2.example.com' and IPv6 network
	information, say '1.8.b.d.0.1.0.0.2.ip6.arpa' for the new		information, say '1.8.b.d.0.1.0.0.2.ip6.arpa' for the new
	interface 2 from the DHCPv6 server.		interface 2 from the DHCPv6 server.
	6. The node stores the learned domains and networks for later use.		6. The node stores the learned domains and networks for later use.
	Figure 8 illustrates how a resolver uses the learned domain		Figure 8 illustrates how a resolver uses the learned domain
	information. Network information use for reverse lookups is not		information. Network information use for reverse lookups is not
	illustrated, but that would go as the Figure 7 example.		illustrated, but that would be similar to the example in Figure 8.
	Application Node RDNSS RDNSS		Application Node RDNSS RDNSS
	on interface 1 on interface 2		on interface 1 on interface 2
	| | | |		| | | |
	(1) |--Name REQ-->| | |		(1) |--Name REQ-->| | |
	| | | |		| | | |
	| +----------------+ | |		| +----------------+ | |
	(2) | | RDNSS | | |		(2) | | RDNSS | | |
	| | prioritization | | |		| | prioritization | | |
	| +----------------+ | |		| +----------------+ | |
	skipping to change at page 28, line 36		skipping to change at page 28, line 36
	/* Sort the RDNSSes into preference order. */		/* Sort the RDNSSes into preference order. */
	/* This is the function with which this pseudocode starts. */		/* This is the function with which this pseudocode starts. */
	bubble_sort_rdnsses( &rdnss_list[0], rdnsses, query );		bubble_sort_rdnsses( &rdnss_list[0], rdnsses, query );
	/* Go thourgh all RDNSSes or until valid response is found. */		/* Go thourgh all RDNSSes or until valid response is found. */
	for (i = 0; i < rdnsses; i++)		for (i = 0; i < rdnsses; i++)
	{		{
	/* Use the highest preference RDNSS first. */		/* Use the highest preference RDNSS first. */
	response = send_and_vaidate_dns_query( rndss_list[i], query);		response = send_and_validate_dns_query( rndss_list[i], query);
	/* If DNSSEC validation is used. */		/* Check if DNSSEC validation is in use, and if so, validate the
			received response. */
	if (dnssec_in_use)		if (dnssec_in_use)
	{		{
	response = dnssec_validate(response);		response = dnssec_validate(response);
	/* If response is validated, use that. Otherwise, proceed to next		/* If response is validated, use that. Otherwise, proceed to next
	RDNSS. */		RDNSS. */
	if (response) return response;		if (response) return response;
	else continue;		else continue;
	}		}
	/* If acceptable response has been found, return it. */		/* If acceptable response has been found, return it. */
	if (response) return response;		if (response) return response;
	}		}
	return NULL;
			return NULL;
	}		}
	Appendix D. Acknowledgements		Appendix D. Acknowledgements
	The authors would like to thank the following people for their		The authors would like to thank the following people for their
	valuable feedback and improvement ideas: Mark Andrews, Jari Arkko,		valuable feedback and improvement ideas: Mark Andrews, Jari Arkko,
	Marcelo Bagnulo, Brian Carpenter, Stuart Cheshire, Lars Eggert,		Marcelo Bagnulo, Brian Carpenter, Stuart Cheshire, Lars Eggert,
	Stephan Farrell, Tomohiro Fujisaki, Brian Haberman, Peter Koch,		Stephan Farrell, Tomohiro Fujisaki, Brian Haberman, Peter Koch,
	Suresh Krishnan, Murray Kucherawy, Barry Leiba, Edward Lewis, Kurtis		Suresh Krishnan, Murray Kucherawy, Barry Leiba, Edward Lewis, Kurtis
	Lindqvist, Arifumi Matsumoto, Erik Nordmark, Steve Padgett, Fabien		Lindqvist, Arifumi Matsumoto, Erik Nordmark, Steve Padgett, Fabien
End of changes. 15 change blocks.
	33 lines changed or deleted		40 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/