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/