draft-ietf-geopriv-res-gw-lis-discovery-00.txt		draft-ietf-geopriv-res-gw-lis-discovery-01.txt
	GEOPRIV M. Thomson		GEOPRIV M. Thomson
	Internet-Draft Andrew Corporation		Internet-Draft Andrew Corporation
	Intended status: Informational R. Bellis		Intended status: Informational R. Bellis
	Expires: August 5, 2011 Nominet UK		Expires: September 15, 2011 Nominet UK
	February 1, 2011		March 14, 2011
	Location Information Server (LIS) Discovery using IP address and Reverse		Location Information Server (LIS) Discovery using IP address and Reverse
	DNS		DNS
	draft-ietf-geopriv-res-gw-lis-discovery-00		draft-ietf-geopriv-res-gw-lis-discovery-01
	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.
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	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 August 5, 2011.		This Internet-Draft will expire on September 15, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 2, line 19		skipping to change at page 2, line 19
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions used in this document . . . . . . . . . . . . . . 4		2. Conventions used in this document . . . . . . . . . . . . . . 4
	3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6		3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6
	3.2. Use of Discovery for Third Party Queries . . . . . . . . . 7		3.2. Residential Gateway Security Features . . . . . . . . . . 7
	3.3. Additional and Optional Constraints . . . . . . . . . . . 7		4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 8
	4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 9		4.1. Identification of IP Addresses . . . . . . . . . . . . . . 8
	4.1. Identification of IP Addresses . . . . . . . . . . . . . . 9		4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9
	4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 10		4.3. When To Use This Method . . . . . . . . . . . . . . . . . 9
	4.3. When To Use This Method . . . . . . . . . . . . . . . . . 10		4.4. Private Address Spaces . . . . . . . . . . . . . . . . . . 10
	4.4. Necessary Assumptions and Restrictions . . . . . . . . . . 11		4.5. Necessary Assumptions and Restrictions . . . . . . . . . . 11
	4.5. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 11		4.6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 11
	4.6. Deployment Considerations . . . . . . . . . . . . . . . . 12		4.7. Deployment Considerations . . . . . . . . . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 15		7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 15
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . . 17		8.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	skipping to change at page 7, line 21		skipping to change at page 7, line 21
	considerable age, some well outside the period of manufacturer		considerable age, some well outside the period of manufacturer
	support. Updating the software in such devices is not feasible in		support. 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 which can be used by		This document therefore describes a method which 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. Use of Discovery for Third Party Queries		3.2. Residential Gateway Security Features
	It is desirable that any discovery mechanism is capable of being used
	by hosts outside of the access network. This facilitates third party
	queries (see [I-D.ietf-geopriv-held-identity-extensions]) by enabling
	identification of the appropriate LIS.
	For example, in some jurisdictions, interim solutions for emergency
	services require that a voice service provider (VSP) or public safety
	answering point (PSAP) be able to request location information from
	the access network provider. These architectures mandate third party
	queries to accommodate calling devices that are unable to acquire
	their own location information and subsequently convey
	[I-D.ietf-sipcore-location-conveyance] that information within call
	signalling.
	This document therefore describes a method which may also be used by
	third parties to discover the appropriate LIS based on the network
	address of the Device.
	Note that an access network that fully supports DHCP-based LIS
	discovery [RFC5986] might not need to provide a secondary discovery
	mechanism. However this method SHOULD be provided for the benefit of
	third parties and for Devices that are unable to use DHCP-based LIS
	discovery.
	3.3. Additional and Optional Constraints
	Certain other properties of residential gateways constrain the
	potential solutions to this problem.
	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
	skipping to change at page 9, line 48		skipping to change at page 8, line 48
	Alternative methods for determining other IP addresses MAY be used by		Alternative methods for determining other IP addresses MAY be used by
	the host. Universal Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1]		the host. Universal Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1]
	and NAT Port Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] are		and NAT Port Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] are
	both able to provide the external address of a residential gateway		both able to provide the external address of a residential gateway
	device when enabled. These as well as proprietary methods for		device when enabled. These as well as proprietary methods for
	determining other addresses might also be available. Because there		determining other addresses might also be available. Because there
	is no assurance that these methods will be supported by any access		is no assurance that these methods will be supported by any access
	network these methods are not mandated. Note also that in some		network these methods are not mandated. Note also that in some
	cases, methods that rely on the view of the network from the		cases, methods that rely on the view of the network from the
	residential gateway device could reveal an address in a private		residential gateway device could reveal an address in a private
	address range (see Section 4.4).		address range (see Section 4.5).
	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 DNS server used contains data for the
	corresponding private IP address range.		corresponding private IP address range.
	skipping to change at page 10, line 35		skipping to change at page 9, line 35
	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
	sucessively by 16, 20 and 24 labels and the query repeated. This		sucessively by 16, 18, 20 and 24 labels and the query repeated.
	corresponds to a search on a /64, /48 or /32 network prefix.		This corresponds to a search on a /64, /56, /48 or /32 network
			prefix.
	DNS queries on other prefixes than those listed above SHOULD NOT be		DNS queries on other prefixes than those listed above SHOULD NOT be
	performed to limit the number of DNS queries performed by Devices.		performed to limit the number of DNS queries performed by Devices.
	If no LIS is discovered by this method, no more than four U-NAPTR		If no LIS is discovered by this method, no more than four U-NAPTR
	resolutions are invoked for each IP address.		resolutions are invoked for each IP address.
	4.3. When To Use This Method		4.3. When To Use This Method
	The DHCP method described in [RFC5986] SHOULD be attempted on all		The DHCP method described in [RFC5986] SHOULD be attempted on all
	local network interfaces before attempting this method. This method		local network interfaces before attempting this method. This method
	is employed either because DHCP is unavailable, when the DHCP server		is 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 if a request to the resulting LIS results in a HELD "notLocatable"
	error or equivalent.		error or equivalent.
	This method can also be used to facilitate third party queries, as		4.4. Private Address Spaces
	described in Section 3.2. Based on a known IP address, the LIS that
	serves that address can be identified as long as the corresponding
	NAPTR records are provided.
	4.4. Necessary Assumptions and Restrictions		Addresses from a private use address space can be used as input to
			this method. In many cases, this applies to addresses defined in
			[RFC1918], though other address ranges could have limited
			reachability where this advice also applies. This is only possible
			if a DNS server with a view of the same address space is used.
			Public DNS servers cannot provide useful records for private
			addresses.
			Using an address from a private space in discovery can provide a more
			specific answer if the DNS server has records for that space.
			Figure 2 shows a network configuration where addresses from an ISP
			network could better indicate the correct LIS. Records in DNS B can
			be provided for the 10.0.0.0/8 range, potentially dividing that range
			so that a more local LIS can be selected.
			_____ ________
			( DNS ).....(/ \) Public
			(__A__) (( Internet )) Address
			(\________/) Space
			|
			[NAT]
			_____ _____|_____
			( DNS )....(/ \) Private
			(__B__) (( ISP Network )) Address Space
			(\___________/) (e.g. 10.0.0.0/8)
			|
			[Gateway]
			____|____
			(/ \) Private
			(( Residence )) Address Space
			(\_________/) (e.g. 192.168.0.0/16)
			Figure 2: Address Space Example
			The goal of automatic DNS configuration is usually to select a local
			DNS, which suits configurations like the one shown. However, use of
			public DNS or STUN servers means that a public IP address is likely
			to be found. For STUN in particular, selecting a public server
			minimizes the need for reconfiguration when a Device moves. Adding
			records for the public address space used by an access network
			ensures that the discovery process succeeds when a public address is
			used.
			4.5. 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 7.		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 6) might require that the address be verified		considerations (Section 6) might require that the address be verified
	to prevent falsification.		to limit the chance of falsification.
	Addresses from private address space [RFC1918] MAY be used as input
	to this method. However, it is assumed that a DNS server with a view
	of the same address space is used in order to provide the
	corresponding DNS mappings; the public DNS does not contain useful
	records for all possible address spaces.
	This does not preclude the use of private address spaces; use of a
	private address space in discovery can provide an access network
	operator more granular control over discovery. This assumes that the
	DNS server used in the U-NAPTR resolution is able to view the address
	realm. Addresses from the public address space are more likely to be
	able to be resolved by any DNS server. Thus, use of the public
	reflexive transport addresses acquired from a STUN server provide
	better chance of the DNS server being able to produce a usable
	result. Therefore, access to a STUN server that is able to view
	addresses from the public Internet is necessary.
	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 their ISP, or some		used by a Device is in some way controlled by the access network
	other related party. This implies that the corresponding		provider, or some other related party. This implies that the
	".in-addr.arpa." or ".ip6.arpa." record can be updated by that entity		corresponding ".in-addr.arpa." or ".ip6.arpa." record can be updated
	to include a useful value for the LIS address.		by that entity to include a useful value for the LIS address.
	4.5. Failure Modes		4.6. Failure Modes
	Successful use of private addresses relies on a DNS server that is		Successful use of private addresses relies on a DNS server that has
	able to see the private address space; therefore, a means to		records for the address space that is used. Using a public IP
	determine a public IP address is necessary. 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 address.
	Configuration of STUN server is necessary to ensure that this is		Configuration of STUN server is necessary to ensure that this is
	successful.		successful.
	Alternative methods for discovering external IP addresses are		Alternative methods for discovering external IP addresses are
	possible, including UPnP and NAT-PMP. However, these methods might		possible, including UPnP and NAT-PMP. These methods might not be
	not be enabled on the residential gateway; thus, these methods cannot		supported by the residential gateway and cannot be relied upon in all
	be relied upon.		cases.
	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.6. Deployment Considerations		4.7. 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.
	If the access network provider uses NAT, any DNS internal to that NAT		If the access network provider uses NAT, any DNS internal to that NAT
	SHOULD also include records for the private address range.		SHOULD also include records for the private address range.
	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 a the higher nodes of the tree (corresponding to /24 and /16 for		at a the higher nodes of the tree (corresponding to /24 and /16 for
	IPv4; /64, /48 and /32 for IPv6). A record at a higher point in the		IPv4; /64, /48 and /32 for IPv6). A record at a higher point in the
	skipping to change at page 15, line 37		skipping to change at page 15, line 37
	[RFC5986] describes behaviour that residential gateways require		[RFC5986] describes behaviour that residential gateways require
	in order for this short term solution to be rendered unnecessary.		in 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.4.		this solution are included in Section 4.5.
	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;
	skipping to change at page 18, line 16		skipping to change at page 18, line 16
	"Session Traversal Utilities for NAT (STUN)", RFC 5389,		"Session Traversal Utilities for NAT (STUN)", RFC 5389,
	October 2008.		October 2008.
	[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.
	[I-D.ietf-sipcore-location-conveyance]		[I-D.ietf-sipcore-location-conveyance]
	Polk, J., Rosen, B., and J. Peterson, "Location Conveyance		Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
	for the Session Initiation Protocol",		for the Session Initiation Protocol",
	draft-ietf-sipcore-location-conveyance-04 (work in		draft-ietf-sipcore-location-conveyance-06 (work in
	progress), October 2010.		progress), February 2011.
	[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.
	[I-D.cheshire-nat-pmp]		[I-D.cheshire-nat-pmp]
	Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",		Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
	draft-cheshire-nat-pmp-03 (work in progress), April 2008.		draft-cheshire-nat-pmp-03 (work in progress), April 2008.
End of changes. 17 change blocks.
	84 lines changed or deleted		79 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/