draft-ietf-geopriv-res-gw-lis-discovery-08.txt		rfc7216.txt
	GEOPRIV M. Thomson		Internet Engineering Task Force (IETF) M. Thomson
	Internet-Draft Mozilla		Request for Comments: 7216 Mozilla
	Intended status: Standards Track R. Bellis		Category: Standards Track R. Bellis
	Expires: June 22, 2014 Nominet UK		ISSN: 2070-1721 Nominet UK
	December 19, 2013		April 2014
	Location Information Server (LIS) Discovery using IP address and Reverse		Location Information Server (LIS) Discovery
	DNS		Using IP Addresses and Reverse DNS
	draft-ietf-geopriv-res-gw-lis-discovery-08
	Abstract		Abstract
	The residential gateway is a device that has become an integral part		The residential gateway is a device that has become an integral part
	of home networking equipment. Discovering a Location Information		of home networking equipment. Discovering a Location Information
	Server (LIS) is a necessary part of acquiring location information		Server (LIS) is a necessary part of acquiring location information
	for location-based services. However, discovering a LIS when a		for location-based services. However, discovering a LIS when a
	residential gateway is present poses a configuration challenge,		residential gateway is present poses a configuration challenge,
	requiring a method that is able to work around the obstacle presented		requiring a method that is able to work around the obstacle presented
	by the gateway.		by the gateway.
	This document describes a solution to this problem. The solution		This document describes a solution to this problem. The solution
	provides alternative domain names as input to the LIS discovery		provides alternative domain names as input to the LIS discovery
	process based on the network addresses assigned to a Device.		process based on the network addresses assigned to a Device.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on June 22, 2014.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7216.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions used in this document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 4
	3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 5		3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6
	3.2. Residential Gateway Security Features . . . . . . . . . . 6		3.2. Security Features of Residential Gateways . . . . . . . . 7
	4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 6		4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 7
	4.1. Identification of IP Addresses . . . . . . . . . . . . . 7		4.1. Identification of IP Addresses . . . . . . . . . . . . . 8
	4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 8		4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9
	4.3. Shortened DNS Names . . . . . . . . . . . . . . . . . . . 8		4.3. Shortened DNS Names . . . . . . . . . . . . . . . . . . . 9
	4.4. When To Use The Reverse DNS Method . . . . . . . . . . . 9		4.4. When To Use the Reverse DNS Method . . . . . . . . . . . 10
	4.5. Private Address Spaces . . . . . . . . . . . . . . . . . 9		4.5. Private Address Spaces . . . . . . . . . . . . . . . . . 10
	4.6. Necessary Assumptions and Restrictions . . . . . . . . . 10		4.6. Necessary Assumptions and Restrictions . . . . . . . . . 11
	4.7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 10		4.7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 12
	4.8. Deployment Considerations . . . . . . . . . . . . . . . . 11		4.8. Deployment Considerations . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 15
	8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		9.1. Normative References . . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	A Location Information Server (LIS) is a service provided by an		A Location Information Server (LIS) is a service provided by an
	access network. The LIS uses knowledge of the access network		access network. The LIS uses knowledge of the access network
	topology and other information to generate location information for		topology and other information to generate location information for
	Devices. Devices within an access network are able to acquire		Devices. Devices within an access network are able to acquire
	location information from a LIS.		location information from a LIS.
	The relationship between a Device and an access network might be		The relationship between a Device and an access network might be
	skipping to change at page 3, line 13		skipping to change at page 3, line 26
	information, some network services are not available.		information, some network services are not available.
	The configuration of a LIS IP address on a Device requires some		The configuration of a LIS IP address on a Device requires some
	automated process. This is particularly relevant when one considers		automated process. This is particularly relevant when one considers
	that Devices might move between different access networks served by		that Devices might move between different access networks served by
	different LISs. LIS Discovery [RFC5986] describes a method that		different LISs. LIS Discovery [RFC5986] describes a method that
	employs the Dynamic Host Configuration Protocol (DHCPv4 [RFC2131],		employs the Dynamic Host Configuration Protocol (DHCPv4 [RFC2131],
	DHCPv6 [RFC3315]) as input to U-NAPTR [RFC4848] discovery.		DHCPv6 [RFC3315]) as input to U-NAPTR [RFC4848] discovery.
	A residential gateway, or home router, provides a range of networking		A residential gateway, or home router, provides a range of networking
	functions for Devices within the network it serves. Unfortunately in		functions for Devices within the network it serves. Unfortunately,
	most cases these functions effectively prevent the successful use of		in most cases these functions effectively prevent the successful use
	DHCP for LIS discovery.		of DHCP for LIS discovery.
	One drawback with DHCP is that universal deployment of a new option		One drawback with DHCP is that universal deployment of a new option
	takes a considerable amount of time. Often, networking equipment		takes a considerable amount of time. Often, networking equipment
	needs to be updated in order to support the new option. Of		needs to be updated in order to support the new option. Of
	particular concern are the millions of residential gateway devices		particular concern are the millions of residential gateway devices
	used to provide Internet access to homes and businesses. While		used to provide Internet access to homes and businesses. While
	[RFC5986] describes functions that can be provided by residential		[RFC5986] describes functions that can be provided by residential
	gateways to support LIS discovery, gateways built before the		gateways to support LIS discovery, gateways built before the
	publication of this specification are not expected (and are likely		publication of this specification are not expected (and are likely
	not able) to provide these functions.		not able) to provide these functions.
	This document explores the problem of configuring Devices with a LIS		This document explores the problem of configuring Devices with a LIS
	address when a residential gateway is interposed between the Device		address when a residential gateway is interposed between the Device
	and access network. Section 3 defines the problem and Section 4		and access network. Section 3 defines the problem, and Section 4
	describes a method for determining a domain name that can be used for		describes a method for determining a domain name that can be used for
	discovery of the LIS.		discovery of the LIS.
	In some cases, the solution described in this document is based on a		In some cases, the solution described in this document is based on a
	UNilateral Self-Address Fixing (UNSAF) [RFC3424] method. For those		UNilateral Self-Address Fixing (UNSAF) [RFC3424] method. For those
	cases, this solution is considered transitional until such time as		cases, this solution is considered transitional until such time as
	the recommendations for residential gateways in [RFC5986] are more		the recommendations for residential gateways in [RFC5986] are more
	widely deployed. Considerations relating to UNSAF applications are		widely deployed. Considerations relating to UNSAF applications are
	described in Section 8.		described in Section 7.
	2. Conventions used in this document		2. Conventions Used in This Document
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	This document uses terminology established in [RFC6280] and		This document uses terminology established in [RFC6280] and
	[RFC5012]. The terms Device and LIS are capitalized throughout when		[RFC5012]. The terms "Device" and "LIS" are capitalized throughout
	they are used to identify the roles defined in [RFC6280].		when they are used to identify the roles defined in [RFC6280].
	3. Problem Statement		3. Problem Statement
	Figure 1 shows a simplified network topology for fixed wire-line		Figure 1 shows a simplified network topology for fixed wire-line
	Internet access. This arrangement is typical when wired Internet		Internet access. This arrangement is typical when wired Internet
	access is provided. The diagram shows two network segments: the		access is provided. The diagram shows two network segments: the
	access network provided by an internet service provider (ISP), and		access network provided by an Internet service provider (ISP), and
	the residential network served by the residential gateway.		the residential network served by the residential gateway.
	There are a number of variations on this arrangement, as documented		There are a number of variations on this arrangement, as documented
	in Section 3.1 of [RFC5687]. In each of these variations the goal of		in Section 3.1 of [RFC5687]. In each of these variations, the goal
	LIS discovery is to identify the LIS in the access network.		of LIS discovery is to identify the LIS in the access network.
	________		________
	(/ \)		(/ \)
	(( Internet ))		(( Internet ))
	(\________/)		(\________/)
	|		|
	|		|
	.- - -|- - - - - - - - - - - -.		.- - -|- - - - - - - - - - - -.
	( | )		( | )
	( +--------+ +-------+ )		( +--------+ +-------+ )
	skipping to change at page 5, line 27		skipping to change at page 6, line 15
	The goal of LIS discovery is to identify a LIS that is able to		The goal of LIS discovery is to identify a LIS that is able to
	provide the Device with accurate location information. In the		provide the Device with accurate location information. In the
	network topology described, this means identifying the LIS in the		network topology described, this means identifying the LIS in the
	access network. The residential gateway is a major obstacle in		access network. The residential gateway is a major obstacle in
	achieving this goal.		achieving this goal.
	3.1. Residential Gateway		3.1. Residential Gateway
	A residential gateway can encompass several different functions		A residential gateway can encompass several different functions
	including: modem, Ethernet switch, wireless access point, router,		including: modem, Ethernet switch, wireless access point, router,
	network address translation (NAT), DHCP server, DNS relay and		network address translation (NAT), DHCP server, DNS relay, and
	firewall. Of the common functions provided, the NAT function of a		firewall. Of the common functions provided, the NAT function of a
	residential gateway has the greatest impact on LIS discovery.		residential gateway has the greatest impact on LIS discovery.
	An ISP is typically parsimonious about their IP address allocations;		An ISP is typically parsimonious about their IP address allocations;
	each customer is allocated a limited number of IP addresses.		each customer is allocated a limited number of IP addresses.
	Therefore, NAT is an extremely common function of gateways. NAT		Therefore, NAT is an extremely common function of gateways. NAT
	enables the use of multiple Devices within the residential network.		enables the use of multiple Devices within the residential network.
	However NAT also means that Devices within the residence are not		However, NAT also means that Devices within the residence are not
	configured by the ISP directly.		configured by the ISP directly.
	When it comes to discovering a LIS, the fact that Devices are not		When it comes to discovering a LIS, the fact that Devices are not
	configured by the ISP causes a significant problem. Configuration is		configured by the ISP causes a significant problem. Configuration is
	the ideal method of conveying the information necessary for		the ideal method of conveying the information necessary for
	discovery. Devices attached to residential gateways are usually		discovery. Devices attached to residential gateways are usually
	given a generic configuration that includes no information about the		given a generic configuration that includes no information about the
	ISP network. For instance, DNS configuration typically points to a		ISP network. For instance, DNS configuration typically points to a
	DNS relay on the gateway device. This approach ensures that the		DNS relay on the gateway device. This approach ensures that the
	local network served by the gateway is able to operate without a		local network served by the gateway is able to operate without a
	skipping to change at page 6, line 23		skipping to change at page 7, line 12
	the gateway still fills its primary function: Internet access.		the gateway still fills its primary function: Internet access.
	Furthermore, updating the software in such devices is not feasible in		Furthermore, updating the software in such devices is not feasible in
	many cases. Even if software updates were made available, many		many cases. Even if software updates were made available, many
	residential gateways cannot be updated remotely, inevitably leading		residential gateways cannot be updated remotely, inevitably leading
	to some proportion that is not updated.		to some proportion that is not updated.
	This document therefore describes a method that can be used by		This document therefore describes a method that can be used by
	Devices to discover their LIS without any assistance from the		Devices to discover their LIS without any assistance from the
	network.		network.
	3.2. Residential Gateway Security Features		3.2. Security Features of Residential Gateways
	A network firewall function is often provided by residential gateways		A network firewall function is often provided by residential gateways
	as a security measure. Security features like intrusion detection		as a security measure. Security features like intrusion detection
	systems help protect users from attacks. Amongst these protections		systems help protect users from attacks. Amongst these protections
	is a port filter that prevents both inbound and outbound traffic on		is a port filter that prevents both inbound and outbound traffic on
	certain TCP and UDP ports. Therefore, any solution needs to consider		certain TCP and UDP ports. Therefore, any solution needs to consider
	the likelihood of traffic being blocked.		the likelihood of traffic being blocked.
	4. IP-based DNS Solution		4. IP-based DNS Solution
	LIS discovery [RFC5986] uses a DNS-based Dynamic Delegation Discovery		LIS discovery [RFC5986] uses a DNS-based Dynamic Delegation Discovery
	Service (DDDS) system as the basis of discovery. Input to this		Service (DDDS) system as the basis of discovery. Input to this
	process is a domain name. Use of DHCP for acquiring the domain name		process is a domain name. Use of DHCP for acquiring the domain name
	is specified, but alternative methods of acquisition are permitted.		is specified, but alternative methods of acquisition are permitted.
	This document specifies a means for a Device to discover several		This document specifies a means for a Device to discover several
	alternative domain names that can be used as input to the DDDS		alternative domain names that can be used as input to the DDDS
	process. These domain names are based on the IP address of the		process. These domain names are based on the IP address of the
	Device. Specifically, the domain names are a portion of the reverse		Device. Specifically, the domain names are a portion of the reverse
	DNS trees - either the ".in-addr.arpa." or ".ip6.arpa." tree.		DNS trees -- either the ".in-addr.arpa." or ".ip6.arpa." tree.
	The goal of this process is to make a small number of DDDS queries in		The goal of this process is to make a small number of DDDS queries in
	order to find a LIS. After LIS discovery using the DHCP-based		order to find a LIS. After LIS discovery using the DHCP-based
	process in [RFC5986] has failed, a Device can:		process in [RFC5986] has failed, a Device can:
	1. Collect a set of IP addresses that refer to the Device		1. Collect a set of IP addresses that refer to the Device
	(Section 4.1).		(Section 4.1).
	2. Convert each IP address into DNS names in the "in-addr.arpa." or		2. Convert each IP address into DNS names in the "in-addr.arpa." or
	"ip6.arpa." tree (Section 4.2).		"ip6.arpa." tree (Section 4.2).
	3. Perform the DDDS process for LIS discovery on those DNS names		3. Perform the DDDS process for LIS discovery on those DNS names
	([RFC5986]).		([RFC5986]).
	4. Shorten the DNS names by some number of labels and repeat the		4. Shorten the DNS names by some number of labels and repeat the
	DDDS process (Section 4.3).		DDDS process (Section 4.3).
	A Device might be reachable at one of a number of IP addresses. In		A Device might be reachable at one of a number of IP addresses. In
	the process described, a Device first identifies each IP address that		the process described, a Device first identifies each IP address from
	it is potentially reachable from. From each of these addresses, the		which it is potentially reachable. From each of these addresses, the
	Device then selects up to three domain names for use in discovery.		Device then selects up to three domain names for use in discovery.
	These domain names are then used as input to the DDDS process.		These domain names are then used as input to the DDDS process.
	4.1. Identification of IP Addresses		4.1. Identification of IP Addresses
	A Device identifies a set of potential IP addresses that currently		A Device identifies a set of potential IP addresses that currently
	result in packets being routed to it. These are ordered by		result in packets being routed to it. These are ordered by
	proximity, with those addresses that are used in adjacent network		proximity, with those addresses that are used in adjacent network
	segments being favoured over those used in public or remote networks.		segments being favored over those used in public or remote networks.
	The first addresses in the set are those that are assigned to local		The first addresses in the set are those that are assigned to local
	network interfaces.		network interfaces.
	A Device can use the Session Traversal Utilities for NAT (STUN)		A Device can use the Session Traversal Utilities for NAT (STUN)
	[RFC5389] mechanism to determine its public reflexive transport		[RFC5389] mechanism to determine its public, reflexive transport
	address. The host uses the "Binding Request" message and the		address. The host uses the "Binding Request" message and the
	resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the		resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the
	response.		response.
	Alternative methods for determining other IP addresses MAY be used by		Alternative methods for determining other IP addresses MAY be used by
	the Device. Port Control Protocol (PCP) [RFC6887], Universal Plug		the Device. If enabled, the Port Control Protocol (PCP) [RFC6887],
	and Play (UPnP) [UPnP-IGD-WANIPConnection1] and NAT Port Mapping		Universal Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1], and NAT
	Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] are both able to provide		Port Mapping Protocol (NAT-PMP) [RFC6886] are each able to provide
	the external address of a residential gateway device when enabled.		the external address of a residential gateway device. These, as well
	These as well as proprietary methods for determining other addresses		as proprietary methods for determining other addresses, might be
	might also be available. Because there is no assurance that these		available. Because there is no assurance that these methods will be
	methods will be supported by any access network, these methods are		supported by any access network, these methods are not mandated.
	not mandated. Note also that in some cases, methods that rely on the		Note also that in some cases, methods that rely on the view of the
	view of the network from the residential gateway device could reveal		network from the residential gateway device could reveal an address
	an address in a private address range (see Section 4.6).		in a private address range (see Section 4.6).
	In many instances, the IP address produced might be from a private		In many instances, the IP address produced might be from a private
	address range. For instance, the address on a local network		address range. For instance, the address on a local network
	interface could be from a private range allocated by the residential		interface could be from a private range allocated by the residential
	gateway. In other cases, methods that rely on the view of the		gateway. In other cases, methods that rely on the view of the
	network (UPnP, NAT-PMP) from the residential gateway device could		network (UPnP, NAT-PMP) from the residential gateway device could
	reveal an address in a private address range if the access network		reveal an address in a private address range if the access network
	also uses NAT. For a private IP address, the derived domain name is		also uses NAT. For a private IP address, the derived domain name is
	only usable where the DNS server used contains data for the		only usable where the employed DNS server contains data for the
	corresponding private IP address range.		corresponding private IP address range.
	4.2. Domain Name Selection		4.2. Domain Name Selection
	The domain name selected for each resulting IP address is the name		The domain name selected for each resulting IP address is the name
	that would be used for a reverse DNS lookup. The domain name derived		that would be used for a reverse DNS lookup. The domain name derived
	from an IP version 4 address is in the ".in-addr.arpa." tree and		from an IP version 4 address is in the ".in-addr.arpa." tree and
	follows the construction rules in Section 3.5 of [RFC1035]. The		follows the construction rules in Section 3.5 of [RFC1035]. The
	domain name derived from an IP version 6 address is in the		domain name derived from an IP version 6 address is in the
	".ip6.arpa." tree and follows the construction rules in Section 2.5		".ip6.arpa." tree and follows the construction rules in Section 2.5
	skipping to change at page 8, line 27		skipping to change at page 9, line 24
	4.3. Shortened DNS Names		4.3. Shortened DNS Names
	Additional domain names are added to allow for a single DNS record to		Additional domain names are added to allow for a single DNS record to
	cover a larger set of addresses. If the search on the domain derived		cover a larger set of addresses. If the search on the domain derived
	from the full IP address does not produce a NAPTR record with the		from the full IP address does not produce a NAPTR record with the
	desired service tag (e.g., "LIS:HELD"), a similar search is repeated		desired service tag (e.g., "LIS:HELD"), a similar search is repeated
	based on a shorter domain name, using a part of the IP address:		based on a shorter domain name, using a part of the IP address:
	o For IP version 4, the resulting domain name SHOULD be shortened		o For IP version 4, the resulting domain name SHOULD be shortened
	successively by one and two labels and the query repeated. This		successively by one and two labels, and the query repeated. This
	corresponds to a search on a /24 or /16 network prefix. This		corresponds to a search on a /24 or /16 network prefix. This
	allows for fewer DNS records in the case where a single access		allows for fewer DNS records in the case where a single access
	network covering an entire /24 or /16 network is served by the		network covering an entire /24 or /16 network is served by the
	same LIS.		same LIS.
	o For IP version 6, the resulting domain SHOULD be shortened		o For IP version 6, the resulting domain SHOULD be shortened
	successively by 16, 18, 20 and 24 labels and the query repeated.		successively by 16, 18, 20, and 24 labels, and the query repeated.
	This corresponds to a search on a /64, /56, /48 or /32 network		This corresponds to a search on a /64, /56, /48, or /32 network
	prefix.		prefix.
	This set of labels is intended to provide network operators with a		This set of labels is intended to provide network operators with a
	degree of flexibility in where LIS discovery records can be placed		degree of flexibility in where LIS discovery records can be placed
	without significantly increasing the number of DNS names that are		without significantly increasing the number of DNS names that are
	searched. This does not attach any other significance to these		searched. This does not attach any other significance to these
	specific zone cuts, or create a classful addressing hierachy based on		specific zone cuts or create a classful addressing hierarchy based on
	the reverse DNS tree.		the reverse DNS tree.
	For example, the IPv4 address "192.0.2.75" could result in queries		For example, the IPv4 address "192.0.2.75" could result in queries
	to:		to:
	o 75.2.0.192.in-addr.arpa.		o 75.2.0.192.in-addr.arpa.
	o 2.0.192.in-addr.arpa.		o 2.0.192.in-addr.arpa.
	o 0.192.in-addr.arpa.		o 0.192.in-addr.arpa.
	skipping to change at page 9, line 26		skipping to change at page 10, line 24
	o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.		o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
	o 8.b.d.0.1.0.0.2.ip6.arpa.		o 8.b.d.0.1.0.0.2.ip6.arpa.
	The limited number of labels by which each name is shortened is		The limited number of labels by which each name is shortened is
	intended to limit the number of DNS queries performed by Devices. If		intended to limit the number of DNS queries performed by Devices. If
	no LIS is discovered by this method, the result will be that no more		no LIS is discovered by this method, the result will be that no more
	than five U-NAPTR resolutions are invoked for each IP address.		than five U-NAPTR resolutions are invoked for each IP address.
	4.4. When To Use The Reverse DNS Method		4.4. When To Use the Reverse DNS Method
	The DHCP method described in [RFC5986] MUST be attempted on all local		The DHCP method described in [RFC5986] MUST be attempted on all local
	network interfaces before attempting this method. This method is		network interfaces before attempting this method. This method is
	employed either because DHCP is unavailable, when the DHCP server		employed either because DHCP is unavailable, when the DHCP server
	does not provide a value for the access network domain name option,		does not provide a value for the access network domain name option,
	or if a request to the resulting LIS results in a HELD "notLocatable"		or because a request to the resulting LIS results in a HELD
	error or equivalent.		"notLocatable" error or equivalent.
	4.5. Private Address Spaces		4.5. Private Address Spaces
	Addresses from a private use address space can be used as input to		Addresses from a private-use address space can be used as input to
	this method. In many cases, this applies to addresses defined in		this method. In many cases, this applies to addresses defined in
	[RFC1918], though other address ranges could have limited		[RFC1918], though other address ranges could have limited
	reachability where this advice also applies. This is only possible		reachability where this advice also applies. This is only possible
	if a DNS server with a view of the same address space is used.		if a DNS server with a view of the same address space is used.
	Public DNS servers cannot provide useful records for private		Public DNS servers cannot provide useful records for private
	addresses.		addresses.
	Using an address from a private space in discovery can provide a more		Using an address from a private space in discovery can provide a more
	specific answer if the DNS server has records for that space.		specific answer if the DNS server has records for that space.
	Figure 2 shows a network configuration where addresses from an ISP		Figure 2 shows a network configuration where addresses from an ISP
	skipping to change at page 10, line 14		skipping to change at page 11, line 14
	_____ ________		_____ ________
	( DNS ).....(/ \) Public		( DNS ).....(/ \) Public
	(__A__) (( Internet )) Address		(__A__) (( Internet )) Address
	(\________/) Space		(\________/) Space
	|		|
	[NAT]		[NAT]
	_____ _____|_____		_____ _____|_____
	( DNS )....(/ \) Private		( DNS )....(/ \) Private
	(__B__) (( ISP Network )) Address Space		(__B__) (( ISP Network )) Address Space
	(\___________/) (e.g. 10.0.0.0/8)		(\___________/) (e.g., 10.0.0.0/8)
	|		|
	[Gateway]		[Gateway]
	____|____		____|____
	(/ \) Private		(/ \) Private
	(( Residence )) Address Space		(( Residence )) Address Space
	(\_________/) (e.g. 192.168.0.0/16)		(\_________/) (e.g., 192.168.0.0/16)
	Figure 2: Address Space Example		Figure 2: Address Space Example
	The goal of automatic DNS configuration is usually to select a local		The goal of automatic DNS configuration is usually to select a local
	DNS, which suits configurations like the one shown. However, use of		DNS, which suits configurations like the one shown. However, use of
	public DNS or STUN servers means that a public IP address is likely		public DNS or STUN servers means that a public IP address is likely
	to be found. For STUN in particular, selecting a public server		to be found. For STUN in particular, selecting a public server
	minimizes the need for reconfiguration when a Device moves. Adding		minimizes the need for reconfiguration when a Device moves. Adding
	records for the public address space used by an access network		records for the public address space used by an access network
	ensures that the discovery process succeeds when a public address is		ensures that the discovery process succeeds when a public address is
	used.		used.
	4.6. Necessary Assumptions and Restrictions		4.6. Necessary Assumptions and Restrictions
	When used by a Device for LIS discovery this is an UNSAF application		When used by a Device for LIS discovery, this is an UNSAF application
	and is subject to the limitations described in Section 8.		and is subject to the limitations described in Section 7.
	It is not necessary that the IP address used is unique to the Device,		It is not necessary that the IP address used is unique to the Device,
	only that the address can be somehow related to the Device or the		only that the address can be somehow related to the Device or the
	access network that serves the Device. This allows a degree of		access network that serves the Device. This allows a degree of
	flexibility in determining this value, although security		flexibility in determining this value, although security
	considerations (Section 7) might require that the address be verified		considerations (Section 6) might require that the address be verified
	to limit the chance of falsification.		to limit the chance of falsification.
	This solution assumes that the public reflexive transport address		This solution assumes that the public, reflexive transport address
	used by a Device is in some way controlled by the access network		used by a Device is in some way controlled by the access network
	provider, or some other related party. This implies that the		provider or some other related party. This implies that the
	corresponding ".in-addr.arpa." or ".ip6.arpa." record can be updated		corresponding ".in-addr.arpa." or ".ip6.arpa." record can be updated
	by that entity to include a useful value for the LIS address.		by that entity to include a useful value for the LIS address.
	4.7. Failure Modes		4.7. Failure Modes
	Successful use of private addresses relies on a DNS server that has		Successful use of private addresses relies on a DNS server that has
	records for the address space that is used. Using a public IP		records for the address space that is used. Using a public IP
	address increases the likelihood of this. This document relies on		address increases the likelihood of this. This document relies on
	STUN to provide the Device with a public reflexive transport address.		STUN to provide the Device with a public, reflexive transport
	Configuration of a STUN server is necessary to ensure that this is		address. Configuration of a STUN server is necessary to ensure that
	successful.		this is successful.
	In cases where a virtual private network (VPN) or other tunnel is		In cases where a virtual private network (VPN) or other tunnel is
	used, the entity providing a public IP address might not be able to		used, the entity providing a public IP address might not be able to
	provide the Device with location information. It is assumed that		provide the Device with location information. It is assumed that
	this entity is able to identify this problem and indicate this to the		this entity is able to identify this problem and indicate this to the
	Device (using the "notLocatable" HELD error, or similar). This		Device (using the "notLocatable" HELD error or similar). This
	problem is described in more detail in [RFC5985].		problem is described in more detail in [RFC5985].
	4.8. Deployment Considerations		4.8. Deployment Considerations
	An access network provider SHOULD provide NAPTR records for each		An access network provider SHOULD provide NAPTR records for each
	public IP address that is used for Devices within the access network.		public IP address that is used for Devices within the access network.
	Any DNS server internal to a NAT SHOULD also include records for the		Any DNS server internal to a NAT SHOULD also include records for the
	private address range. These records might only be provided to		private address range. These records might only be provided to
	clients making requests from the private address range. Doing so		clients making requests from the private address range. Doing so
	allows clients within the private address range to discover a LIS		allows clients within the private address range to discover a LIS
	based on their IP address prior to any address translation. In		based on their IP address prior to any address translation. In
	geographically distributed networks that use a private address range,		geographically distributed networks that use a private address range,
	this enables the use of a different LIS for different locations,		this enables the use of a different LIS for different locations,
	based on the IP address range used at each location. Use of a		based on the IP address range used at each location. Use of a
	public, translated IP address for the network can still work, but it		public, translated IP address for the network can still work, but it
	might result in a suboptimal LIS selection.		might result in a suboptimal LIS selection.
	A network that operates network address translation SHOULD provide		A network that operates network address translation SHOULD provide
	NAPTR records that reference a LIS endpoint with a public address.		NAPTR records that reference a LIS endpoint with a public address.
	This requires the reservation of an IP and port for the LIS. To		This requires the reservation of an IP address and port for the LIS.
	ensure requests toward the LIS from within the private address space		To ensure requests toward the LIS from within the private address
	do not traverse the NAT and have source addresses mapped by the NAT,		space do not traverse the NAT and have source addresses mapped by the
	networks can provide direct route to the LIS. Clients that perform		NAT, networks can provide a direct route to the LIS. Clients that
	discovery based on public DNS or STUN servers are thereby easier to		perform discovery based on public DNS or STUN servers are thereby
	trace based on source address information.		easier to trace based on source address information.
	NAPTR records can be provided for individual IP addresses. To limit		NAPTR records can be provided for individual IP addresses. To limit
	the proliferation of identical records, a single record can be placed		the proliferation of identical records, a single record can be placed
	at higher nodes of the tree (corresponding to /24 and /16 for IPv4; /		at higher nodes of the tree (corresponding to /24 and /16 for IPv4;
	64, /56, /48 and /32 for IPv6). A record at a higher point in the		/64, /56, /48, and /32 for IPv6). A record at a higher point in the
	tree (those with a shorter prefix) applies to all addresses lower in		tree (those with a shorter prefix) applies to all addresses lower in
	the tree (those with a longer prefix); records at the lower point		the tree (those with a longer prefix); records at the lower point
	override those at higher points, thus allowing for exceptions to be		override those at higher points, thus allowing for exceptions to be
	specified.		specified.
	5. IANA Considerations		5. Privacy Considerations
	This document has no IANA actions.
	6. Privacy Considerations
	As with all uses of geolocation information, it is very important		As with all uses of geolocation information, it is very important
	that measures be taken to ensure that location information is not		that measures be taken to ensure that location information is not
	provided to unauthorized parties. The mechanism defined in this		provided to unauthorized parties. The mechanism defined in this
	document is focused on the case where a device is learning its own		document is focused on the case where a device is learning its own
	location, so that it can provide that location information to		location so that it can provide that location information to
	applications. We assume that the device learning its own location is		applications. We assume that the device learning its own location is
	not a privacy risk. There are then two remaining privacy risks: The		not a privacy risk. There are then two remaining privacy risks: the
	use of geolocation by applications, and abuse of the location		use of geolocation by applications, and the abuse of the location
	configuration protocol.		configuration protocol.
	The privacy considerations around the use of geolocation by		The privacy considerations around the use of geolocation by
	applications vary considerably by application context. A framework		applications vary considerably by application context. A framework
	for location privacy in applications is provided in [RFC6280].		for location privacy in applications is provided in [RFC6280].
	The mechanism specified in this document allows a device to discover		The mechanism specified in this document allows a device to discover
	its local LIS, from which it then acquires its location using a		its local LIS, from which it then acquires its location using a
	Location Configuration Protocol [RFC5687]. If an unauthorized third		Location Configuration Protocol (LCP) [RFC5687]. If an unauthorized
	party can spoof the LCP to obtain a target's location information,		third party can spoof the LCP to obtain a target's location
	then the mechanism in this document could allow them to discover the		information, then the mechanism in this document could allow them to
	proper server to attack for a given IP address. Thus, it is		discover the proper server to attack for a given IP address. Thus,
	important that a LIS meet the security requirements of the LCP it		it is important that a LIS meet the security requirements of the LCP
	implements. For HELD, these requirements are laid out in Section 9		it implements. For HELD, these requirements are laid out in
	of [RFC5985].		Section 9 of [RFC5985].
	A Device that discovers a LIS using the methods in this document MUST		A Device that discovers a LIS using the methods in this document MUST
	NOT provide that LIS with additional information that might reveal		NOT provide that LIS with additional information that might reveal
	its position, such as the location measurements described in		its position, such as the location measurements described in
	[I-D.ietf-geopriv-held-measurements], unless it has a secondary		[RFC7105], unless it has a secondary method for determining the
	method for determining the authenticity of the LIS, such as a white		authenticity of the LIS, such as a white list.
	list.
	7. Security Considerations		6. Security Considerations
	The security considerations described in [RFC5986] apply to the		The security considerations described in [RFC5986] apply to the
	discovery process as a whole. The primary security concern is with		discovery process as a whole. The primary security concern is with
	the potential for an attacker to impersonate a LIS.		the potential for an attacker to impersonate a LIS.
	The added ability for a third party to discover the identity of a LIS		The added ability for a third party to discover the identity of a LIS
	does not add any concerns, since the identity of a LIS is considered		does not add any concerns, since the identity of a LIS is considered
	public information.		public information.
	In addition to existing considerations, this document introduces		In addition to existing considerations, this document introduces
	skipping to change at page 13, line 24		skipping to change at page 14, line 24
	Device. Even though STUN messages are protected by a STUN MESSAGE-		Device. Even though STUN messages are protected by a STUN MESSAGE-
	INTEGRITY attribute, which is an HMAC that uses a shared secret, an		INTEGRITY attribute, which is an HMAC that uses a shared secret, an
	on-path attacker can capture and modify packets, altering source and		on-path attacker can capture and modify packets, altering source and
	destination addresses to provide falsified addresses.		destination addresses to provide falsified addresses.
	This attack could result in an effective means of denial of service,		This attack could result in an effective means of denial of service,
	or a means to provide a deliberately misleading service. Notably,		or a means to provide a deliberately misleading service. Notably,
	any LIS that is identified based on a falsified IP address could		any LIS that is identified based on a falsified IP address could
	still be a valid LIS for the given IP address, just not one that is		still be a valid LIS for the given IP address, just not one that is
	useful for providing the Device with location information. In this		useful for providing the Device with location information. In this
	case, the LIS provides a HELD "notLocatable" error, or an equivalent.		case, the LIS provides a HELD "notLocatable" error or an equivalent.
	If the falsified IP address is under the control of the attacker, it		If the falsified IP address is under the control of the attacker, it
	is possible that misleading (but verifiable) DNS records could		is possible that misleading (but verifiable) DNS records could
	indicate a malicious LIS that provides false location information.		indicate a malicious LIS that provides false location information.
	In all cases of falsification, the best remedy is to perform some		In all cases of falsification, the best remedy is to perform some
	form of independent verification of the result. No specific		form of independent verification of the result. No specific
	mechanism is currently available to prevent attacks based on		mechanism is currently available to prevent attacks based on
	falsification of reflexive addresses; it is suggested that Devices		falsification of reflexive addresses; it is suggested that Devices
	attempt to independently verify that the reflexive transport address		attempt to independently verify that the reflexive transport address
	provided is accurate. An independent, trusted source of location		provided is accurate. An independent, trusted source of location
	skipping to change at page 13, line 47		skipping to change at page 14, line 47
	discovered LIS.		discovered LIS.
	Use of private address space effectively prevents use of the usual		Use of private address space effectively prevents use of the usual
	set of trust anchors for DNSSEC. Only a DNS server that is able to		set of trust anchors for DNSSEC. Only a DNS server that is able to
	see the same private address space can provide useful records. A		see the same private address space can provide useful records. A
	Device that relies on DNS records in the private address space		Device that relies on DNS records in the private address space
	portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use		portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use
	an alternative trust anchor for these records or rely on other means		an alternative trust anchor for these records or rely on other means
	of ensuring the veracity of the DNS records.		of ensuring the veracity of the DNS records.
	8. IAB Considerations		DNS queries that are not blocked as [RFC6303] demands, or directed to
			servers outside the network, can cause the addresses that are in use
			within the network to be exposed outside of the network. For
			resolvers within the network, implementing [RFC6303] avoids this
			issue; otherwise, the problem cannot be avoided without blocking DNS
			queries to external servers.
			7. IAB Considerations
	The IAB has studied the problem of Unilateral Self-Address Fixing		The IAB has studied the problem of Unilateral Self-Address Fixing
	(UNSAF) [RFC3424], which is the general process by which a client		(UNSAF) [RFC3424], which is the general process by which a client
	attempts to determine its address in another realm on the other side		attempts to determine its address in another realm on the other side
	of a NAT through a collaborative protocol reflection mechanism, such		of a NAT through a collaborative protocol reflection mechanism, such
	as STUN.		as STUN.
	This section only applies to the use of this method of LIS discovery		This section only applies to the use of this method of LIS discovery
	by Devices and does not apply to its use for third-party LIS		by Devices and does not apply to its use for third-party LIS
	discovery.		discovery.
	skipping to change at page 14, line 25		skipping to change at page 15, line 28
	mechanisms document a set of considerations.		mechanisms document a set of considerations.
	1. Precise definition of a specific, limited-scope problem that is		1. Precise definition of a specific, limited-scope problem that is
	to be solved with the UNSAF proposal.		to be solved with the UNSAF proposal.
	Section 3 describes the limited scope of the problem addressed in		Section 3 describes the limited scope of the problem addressed in
	this document.		this document.
	2. Description of an exit strategy/transition plan.		2. Description of an exit strategy/transition plan.
	[RFC5986] describes behaviour that residential gateways require		[RFC5986] describes behavior that residential gateways require in
	in order for this short term solution to be rendered unnecessary.		order for this short-term solution to be rendered unnecessary.
	When implementations of the recommendations in LIS discovery are		When implementations of the recommendations in LIS discovery are
	widely available, this UNSAF mechanism can be made obsolete.		widely available, this UNSAF mechanism can be made obsolete.
	3. Discussion of specific issues that may render systems more		3. Discussion of specific issues that may render systems more
	"brittle".		"brittle".
	A description of the necessary assumptions and limitations of		A description of the necessary assumptions and limitations of
	this solution are included in Section 4.6.		this solution are included in Section 4.6.
	Use of STUN for discovery of a reflexive transport address is		Use of STUN for discovery of a reflexive transport address is
	inherently brittle in the presence of multiple NATs or address		inherently brittle in the presence of multiple NATs or address
	realms. In particular, brittleness is added by the requirement		realms. In particular, brittleness is added by the requirement
	of using a DNS server that is able to view the address realm that		of using a DNS server that is able to view the address realm that
	contains the IP address in question. If address realms use		contains the IP address in question. If address realms use
	overlapping addressing space, then there is a risk that the DNS		overlapping addressing space, then there is a risk that the DNS
	server provides information that is not useful to the Device.		server provides information that is not useful to the Device.
	4. Identify requirements for longer term, sound technical solutions;		4. Identify requirements for longer-term, sound technical solutions;
	contribute to the process of finding the right longer term		contribute to the process of finding the right longer-term
	solution.		solution.
	A longer term solution is already provided in [RFC5986].		A longer-term solution is already provided in [RFC5986].
	However, that solution relies on widespread deployment. The		However, that solution relies on widespread deployment. The
	UNSAF solution provided here is provided as an interim solution		UNSAF solution provided here is an interim solution that enables
	that enables LIS access for Devices that are not able to benefit		LIS access for Devices that are not able to benefit from
	from deployment of the recommendations in [RFC5986].		deployment of the recommendations in [RFC5986].
	5. Discussion of the impact of the noted practical issues with		5. Discussion of the impact of the noted practical issues with
	existing deployed NATs and experience reports.		existing deployed NATs and experience reports.
	The UNSAF mechanism depends on the experience in deployment of		The UNSAF mechanism depends on the experience in deployment of
	STUN [RFC5389]. On the whole, existing residential gateway		STUN [RFC5389]. On the whole, existing residential gateway
	devices are able to provide access to STUN and DNS service		devices are able to provide access to STUN and DNS service
	reliably, although regard should be given to the size of the DNS		reliably, although regard should be given to the size of the DNS
	response (see [RFC5625]).		response (see [RFC5625]).
	9. Acknowledgements		8. Acknowledgements
	Richard Barnes provided the text in Section 6.		Richard Barnes provided the text in Section 5.
	10. References		9. References
	10.1. Normative References		9.1. Normative References
	[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.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,		[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
	"DNS Extensions to Support IP Version 6", RFC 3596,		"DNS Extensions to Support IP Version 6", RFC 3596,
	October 2003.		October 2003.
	[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local		[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
	Location Information Server (LIS)", RFC 5986, September		Location Information Server (LIS)", RFC 5986, September
	2010.		2010.
	[I-D.ietf-geopriv-held-measurements]		[RFC7105] Thomson, M. and J. Winterbottom, "Using Device-Provided
	Thomson, M. and J. Winterbottom, "Using Device-provided
	Location-Related Measurements in Location Configuration		Location-Related Measurements in Location Configuration
	Protocols", draft-ietf-geopriv-held-measurements-09 (work		Protocols", RFC 7105, January 2014.
	in progress), September 2013.
	10.2. Informative References		9.2. Informative References
	[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", BCP		E. Lear, "Address Allocation for Private Internets", BCP
	5, RFC 1918, February 1996.		5, RFC 1918, February 1996.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
	2131, March 1997.		2131, March 1997.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
	and M. Carney, "Dynamic Host Configuration Protocol for		and M. Carney, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
	[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral		[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
	Self-Address Fixing (UNSAF) Across Network Address		Self-Address Fixing (UNSAF) Across Network Address
	Translation", RFC 3424, November 2002.		Translation", RFC 3424, November 2002.
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
	[RFC4848] Daigle, L., "Domain-Based Application Service Location		[RFC4848] Daigle, L., "Domain-Based Application Service Location
	Using URIs and the Dynamic Delegation Discovery Service		Using URIs and the Dynamic Delegation Discovery Service
	(DDDS)", RFC 4848, April 2007.		(DDDS)", RFC 4848, April 2007.
	[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for		[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
	Emergency Context Resolution with Internet Technologies",		Emergency Context Resolution with Internet Technologies",
	RFC 5012, January 2008.		RFC 5012, January 2008.
	[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,		[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
	"Session Traversal Utilities for NAT (STUN)", RFC 5389,		"Session Traversal Utilities for NAT (STUN)", RFC 5389,
	skipping to change at page 16, line 46		skipping to change at page 17, line 37
	[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7		[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
	Location Configuration Protocol: Problem Statement and		Location Configuration Protocol: Problem Statement and
	Requirements", RFC 5687, March 2010.		Requirements", RFC 5687, March 2010.
	[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,		[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
	Tschofenig, H., and H. Schulzrinne, "An Architecture for		Tschofenig, H., and H. Schulzrinne, "An Architecture for
	Location and Location Privacy in Internet Applications",		Location and Location Privacy in Internet Applications",
	BCP 160, RFC 6280, July 2011.		BCP 160, RFC 6280, July 2011.
			[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC
			6303, July 2011.
	[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.		[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
	Selkirk, "Port Control Protocol (PCP)", RFC 6887, April		Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
	2013.		2013.
	[UPnP-IGD-WANIPConnection1]		[UPnP-IGD-WANIPConnection1]
	UPnP Forum, "Internet Gateway Device (IGD) Standardized		UPnP Forum, "Internet Gateway Device (IGD) Standardized
	Device Control Protocol V 1.0: WANIPConnection:1 Service		Device Control Protocol V 1.0: WANIPConnection:1 Service
	Template Version 1.01 For UPnP Version 1.0", DCP 05-001,		Template Version 1.01 For UPnP Version 1.0", DCP 05-001,
	Nov 2001.		Nov. 2001, <http://upnp.org/specs/gw/
			UPnP-gw-WANIPConnection-v1-Service.pdf>.
	[I-D.cheshire-nat-pmp]		[RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol
	Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol		(NAT-PMP)", RFC 6886, April 2013.
	(NAT-PMP)", draft-cheshire-nat-pmp-07 (work in progress),
	January 2013.
	[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP		[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP
	152, RFC 5625, August 2009.		152, RFC 5625, August 2009.
	[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC		[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC
	5985, September 2010.		5985, September 2010.
	Authors' Addresses		Authors' Addresses
	Martin Thomson		Martin Thomson
	Mozilla		Mozilla
	Suite 300		Suite 300
	650 Castro Street		650 Castro Street
	Mountain View, CA 94041		Mountain View, CA 94041
	US		US
	Email: martin.thomson@gmail.com		EMail: martin.thomson@gmail.com
	Ray Bellis		Ray Bellis
	Nominet UK		Nominet UK
	Edmund Halley Road		Edmund Halley Road
	Oxford OX4 4DQ		Oxford OX4 4DQ
	United Kingdom		United Kingdom
	Phone: +44 1865 332211		Phone: +44 1865 332211
	Email: ray.bellis@nominet.org.uk		EMail: ray.bellis@nominet.org.uk
	URI: http://www.nominet.org.uk/		URI: http://www.nominet.org.uk/
End of changes. 66 change blocks.
	149 lines changed or deleted		145 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/