draft-ietf-geopriv-l7-lcp-ps-05.txt		draft-ietf-geopriv-l7-lcp-ps-06.txt
	Network Working Group H. Tschofenig		Network Working Group H. Tschofenig
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Informational H. Schulzrinne		Intended status: Informational H. Schulzrinne
	Expires: March 15, 2008 Columbia University		Expires: May 22, 2008 Columbia University
	September 12, 2007		November 19, 2007
	GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and		GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and
	Requirements		Requirements
	draft-ietf-geopriv-l7-lcp-ps-05.txt		draft-ietf-geopriv-l7-lcp-ps-06.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 15, 2008.		This Internet-Draft will expire on May 22, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document provides a problem statement, lists requirements and		This document provides a problem statement, lists requirements and
	captures design aspects for a Geopriv Layer 7 Location Configuration		captures design aspects for a Geopriv Layer 7 Location Configuration
	Protocol L7 (LCP). This protocol aims to allow an end host to obtain		Protocol L7 (LCP). This protocol aims to allow an end host to obtain
	skipping to change at page 11, line 11		skipping to change at page 11, line 11
	+------+		+------+
	Figure 3: Wireless Access Scenario		Figure 3: Wireless Access Scenario
	4. Discovery of the Location Information Server		4. Discovery of the Location Information Server
	When a Target wants to retrieve location information from the LIS it		When a Target wants to retrieve location information from the LIS it
	first needs to discover it. Based on the problem statement of		first needs to discover it. Based on the problem statement of
	determining the location of the Target, which is known best by		determining the location of the Target, which is known best by
	entities close to the Target itself, we assume that the LIS is		entities close to the Target itself, we assume that the LIS is
	located in the access network. Several procedures have been		located in the local subnet or in access network. Several procedures
	investigated that aim to discover the LIS in such an access network.		have been investigated that aim to discover the LIS in such an access
			network.
	DHCP-based Discovery:		DHCP-based Discovery:
	In some environments the Dynamic Host Configuration Protocol		In some environments the Dynamic Host Configuration Protocol
	(DHCP) might be a good choice for discovering the FQDN or the IP		(DHCP) might be a good choice for discovering the FQDN or the IP
	address of the LIS. In environments where DHCP can be used it is		address of the LIS. In environments where DHCP can be used it is
	also possible to use the already defined location extensions. In		also possible to use the already defined location extensions. In
	environments with legacy devices, such as the one shown in		environments with legacy devices, such as the one shown in
	Section 3.1, a DHCP based discovery solution may not be possible.		Section 3.1, a DHCP based discovery solution may not be possible.
	DNS-based Discovery:		DNS-based Discovery:
	With this approach the end host obtains its public IP address		Before a DNS lookup can be started it is necessary to learn the
	(e.g., via STUN [6]) in order to obtain its domain name (via a		domain name of the access network that runs a LIS. Several ways
	reverse DNS lookup). Then, the SRV or NAPTR record for that		to learn the domain name exist. For example, the end host obtains
	domain is retrieved. This relies on the user's public IP address		its own public IP address, for example via STUN [6], and performs
	having a DNS entry. A more detailed description of this approach		a reverse DNS lookup (assuming the data is provisioned into the
	can be found in [7].		DNS). Then, the SRV or NAPTR record for that domain is retrieved.
			A more detailed description of this approach can be found in [7].
	Redirect Rule:		Redirect Rule:
	A redirect rule at a device in the access network, for example at		A redirect rule at a device in the access network, for example at
	the AAA client, could be used to redirect the L7 LCP signalling		the AAA client, could be used to redirect the L7 LCP signalling
	messages (destined to a specific port) to the LIS. The end host		messages (destined to a specific port) to the LIS. The end host
	could then discover the LIS by sending a packet to almost any		could then discover the LIS by sending a packet with a specific
	address (as long as the destination IP address does not target a		(registered) port number to almost any address (as long as the
	device in the local network). The packet would be redirected to		destination IP address does not target a device in the local
	the respective LIS being configured. The same procedure is used		network). The packet would be redirected to the respective LIS
	by captive portals whereby any HTTP traffic is intercepted and		being configured. The same procedure is used by captive portals
	redirected.		whereby any HTTP traffic is intercepted and redirected.
	To some extend this approach is similar to packets that are marked		To some extend this approach is similar to packets that are marked
	with a Router Alert option [8] and intercepted by entities that		with a Router Alert option [8] and intercepted by entities that
	understand the specific marking. In the above-mentioned case,		understand the specific marking. In the above-mentioned case,
	however, the marking is provided via a registered port number		however, the marking is provided via a registered port number
	instead of relying on a Router Alert option.		instead of relying on a Router Alert option.
	Multicast Query:		Multicast Query:
	An end node could also discover a LIS by sending a DNS query to a		An end node could also discover a LIS by sending a DNS query to a
	skipping to change at page 22, line 23		skipping to change at page 22, line 23
	Levels", RFC 2119, BCP 14, March 1997.		Levels", RFC 2119, BCP 14, March 1997.
	[3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency		[3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
	Context Resolution with Internet Technologies",		Context Resolution with Internet Technologies",
	draft-ietf-ecrit-requirements-13 (work in progress),		draft-ietf-ecrit-requirements-13 (work in progress),
	March 2007.		March 2007.
	11.2. Informative References		11.2. Informative References
	[4] Marshall, R., "Requirements for a Location-by-Reference		[4] Marshall, R., "Requirements for a Location-by-Reference
	Mechanism", draft-ietf-geopriv-lbyr-requirements-00 (work in		Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work in
	progress), September 2007.		progress), October 2007.
	[5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol		[5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
	Requirements", draft-winterbottom-geopriv-lis2lis-req-00 (work		Requirements", draft-winterbottom-geopriv-lis2lis-req-01 (work
	in progress), June 2007.		in progress), November 2007.
	[6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN		[6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
	- Simple Traversal of User Datagram Protocol (UDP) Through		- Simple Traversal of User Datagram Protocol (UDP) Through
	Network Address Translators (NATs)", RFC 3489, March 2003.		Network Address Translators (NATs)", RFC 3489, March 2003.
	[7] Thomson, M. and J. Winterbottom, "Discovering the Local		[7] Thomson, M. and J. Winterbottom, "Discovering the Local
	Location Information Server (LIS)",		Location Information Server (LIS)",
	draft-thomson-geopriv-lis-discovery-02 (work in progress),		draft-thomson-geopriv-lis-discovery-03 (work in progress),
	July 2007.		September 2007.
	[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.		[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
	[9] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast		[9] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast
	Name Resolution (LLMNR)", RFC 4795, January 2007.		Name Resolution (LLMNR)", RFC 4795, January 2007.
	[10] Cheshire, S. and M. Krochmal, "Multicast DNS",		[10] Cheshire, S. and M. Krochmal, "Multicast DNS",
	draft-cheshire-dnsext-multicastdns-06 (work in progress),		draft-cheshire-dnsext-multicastdns-06 (work in progress),
	August 2006.		August 2006.
	[11] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",		[11] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
	RFC 3068, June 2001.		RFC 3068, June 2001.
	[12] Ward, N., "Teredo Server Selection",		[12] Ward, N., "Teredo Server Selection",
	draft-nward-v6ops-teredo-server-selection-00 (work in		draft-nward-v6ops-teredo-server-selection-00 (work in
	progress), July 2007.		progress), July 2007.
	[13] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-08		[13] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
	(work in progress), June 2007.		"Host Identity Protocol", draft-ietf-hip-base-10 (work in
			progress), October 2007.
	[14] Aura, T., "Cryptographically Generated Addresses (CGA)",		[14] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, March 2005.		RFC 3972, March 2005.
	[15] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network		[15] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
	Access Identifier", RFC 4282, December 2005.		Access Identifier", RFC 4282, December 2005.
	[16] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote		[16] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
	Authentication Dial In User Service (RADIUS)", RFC 2865,		Authentication Dial In User Service (RADIUS)", RFC 2865,
	June 2000.		June 2000.
	skipping to change at page 23, line 36		skipping to change at page 23, line 37
	[19] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol		[19] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
	(NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in progress),		(NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in progress),
	July 2007.		July 2007.
	[20] Peterson, J., "A Presence-based GEOPRIV Location Object		[20] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.		Format", RFC 4119, December 2005.
	[21] Rosenberg, J., "A Data Model for Presence", RFC 4479,		[21] Rosenberg, J., "A Data Model for Presence", RFC 4479,
	July 2006.		July 2006.
	[22] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,		[22] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
	Considerations and Recommendations",		PIDF-LO Usage Clarification, Considerations and
	draft-ietf-geopriv-pdif-lo-profile-08 (work in progress),		Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work
	July 2007.		in progress), October 2007.
	[23] Barnes, R., "Threats to GEOPRIV Location Objects",		[23] Barnes, R., "Threats to GEOPRIV Location Objects",
	draft-barnes-geopriv-lo-sec-00 (work in progress), July 2007.		draft-barnes-geopriv-lo-sec-00 (work in progress), July 2007.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
End of changes. 11 change blocks.
	30 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/