draft-ietf-geopriv-lis-discovery-03.txt   draft-ietf-geopriv-lis-discovery-04.txt 
GEOPRIV M. Thomson GEOPRIV M. Thomson
Internet-Draft J. Winterbottom Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew Intended status: Standards Track Andrew
Expires: March 14, 2009 September 10, 2008 Expires: May 3, 2009 October 30, 2008
Discovering the Local Location Information Server (LIS) Discovering the Local Location Information Server (LIS)
draft-ietf-geopriv-lis-discovery-03 draft-ietf-geopriv-lis-discovery-04
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 34 skipping to change at page 1, line 34
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 14, 2009. This Internet-Draft will expire on May 3, 2009.
Abstract Abstract
A method is described for the discovery of a Location Information A method is described for the discovery of a Location Information
Server. The method uses a Dynamic Host Configuration Protocol (DHCP) Server. The method uses a Dynamic Host Configuration Protocol (DHCP)
option. DHCP options are defined for both IPv4 and IPv6 DHCP. A option. DHCP options are defined for both IPv4 and IPv6 DHCP. A
URI-enabled NAPTR (U-NAPTR) method is described for use where the URI-enabled NAPTR (U-NAPTR) method is described for use where the
DHCP option is unsuccessful. This document defines a U-NAPTR DHCP option is unsuccessful. This document defines a U-NAPTR
Application Service for a LIS, with a specific Application Protocol Application Service for a LIS, with a specific Application Protocol
for the HTTP Enabled Location Delivery (HELD) protocol. for the HTTP Enabled Location Delivery (HELD) protocol.
skipping to change at page 3, line 15 skipping to change at page 3, line 15
1. Introduction and Overview 1. Introduction and Overview
Discovering a Location Information Server (LIS) is an important part Discovering a Location Information Server (LIS) is an important part
of the location acquisition process. The LIS is an access network of the location acquisition process. The LIS is an access network
service that needs to be discovered before it can be used. This service that needs to be discovered before it can be used. This
document describes a method that a host can use to discover a URI for document describes a method that a host can use to discover a URI for
a LIS. a LIS.
The product of a discovery process, such as the one described in this The product of a discovery process, such as the one described in this
document, is the address of the service. In this document, the document, is the address of the service. In this document, the
result is a URI, which identifies a LIS. result is an http: or https: URI, which identifies a LIS.
The URI result from the discovery process is suitable for location The URI result from the discovery process is suitable for location
configuration only; that is, the client MUST dereference the URI configuration only; that is, the client MUST dereference the URI
using the process described in HELD using the process described in HELD
[I-D.ietf-geopriv-http-location-delivery]. URIs discovered in this [I-D.ietf-geopriv-http-location-delivery]. URIs discovered in this
way are not "location by reference" URIs; dereferencing one of them way are not "location by reference" URIs; dereferencing one of them
provides the location of the requester only. Clients MUST NOT embed provides the location of the requester only. Clients MUST NOT embed
these URIs in fields in other protocols designed to carry the these URIs in fields in other protocols designed to carry the
location of the client. location of the client.
skipping to change at page 8, line 51 skipping to change at page 8, line 51
DNS "PTR" records in the "in-addr.arpa." domain can be used to DNS "PTR" records in the "in-addr.arpa." domain can be used to
determine the domain name of a host, and therefore, the name of the determine the domain name of a host, and therefore, the name of the
domain for that host. The use of the "in-addr.arpa." domain is domain for that host. The use of the "in-addr.arpa." domain is
described in [RFC1034] and results in the domain name of the host. described in [RFC1034] and results in the domain name of the host.
Likewise, IPv6 hosts use the "ip6.arpa." domain. In the majority of Likewise, IPv6 hosts use the "ip6.arpa." domain. In the majority of
cases, the domain part of this name (everything excluding the first cases, the domain part of this name (everything excluding the first
label) is also the domain name for the access network. Assuming that label) is also the domain name for the access network. Assuming that
this is true, this domain name can be used as input to the U-NAPTR this is true, this domain name can be used as input to the U-NAPTR
process. process.
For example, if the for "10.1.2.3" address, if the "PTR" record at For example, for an address of "192.0.2.3", if the "PTR" record at
"3.2.1.10.in-addr.arpa." refers to "h3-2-1-10.example.com", this "3.2.0.192.in-addr.arpa." refers to "h3-2-0-192.example.com.", this
results in a U-NAPTR search for "example.com". results in a U-NAPTR search for "example.com."
The DNS hierarchy does not necessarily directly map onto a network The DNS hierarchy does not necessarily directly map onto a network
topology (see [RFC4367]); therefore, this method MUST only be used topology (see [RFC4367]); therefore, this method MUST only be used
for the domain name determined by removing the first label only. for the domain name determined by removing the first label only.
This method assumes that the access network provider also provides This method assumes that the access network provider also provides
the reverse DNS record and they control the domain that is indicated the reverse DNS record and they control the domain that is indicated
in the "PTR" record. in the "PTR" record.
Furthermore, this method might not apply where a host is given a Furthermore, this method might not apply where a host is given a
domain name that is different from the domain name of the access domain name that is different from the domain name of the access
skipping to change at page 12, line 34 skipping to change at page 12, line 34
A. DHCP Domain Name Option A. DHCP Domain Name Option
B. Reverse DNS, using the IP address from: B. Reverse DNS, using the IP address from:
1. the local network interface and immediate network segment 1. the local network interface and immediate network segment
2. the public reflexive transport address, as revealed by 2. the public reflexive transport address, as revealed by
STUN STUN
+ any network segment, as revealed by an alternative method 3. Alternative methods, including static configuration
3. Static configuration
A host that has multiple network interfaces could potentially be A host that has multiple network interfaces could potentially be
served by a different access network on each interface, each with a served by a different access network on each interface, each with a
different LIS. The host SHOULD attempt to discover the LIS different LIS. The host SHOULD attempt to discover the LIS
applicable to each network interface, stopping when a LIS is applicable to each network interface, stopping when a LIS is
successfully discovered on any interface. successfully discovered on any interface.
A host that discovers a LIS URI MUST attempt to verify that the LIS A host that discovers a LIS URI MUST attempt to verify that the LIS
is able to provide location information. For the HELD protocol, the is able to provide location information. For the HELD protocol, the
host MUST make a location request to the LIS. If the LIS responds to host MUST make a location request to the LIS. If the LIS responds to
skipping to change at page 13, line 9 skipping to change at page 13, line 7
[I-D.ietf-geopriv-http-location-delivery]), the host MUST continue [I-D.ietf-geopriv-http-location-delivery]), the host MUST continue
the discovery process and not make further requests to that LIS on the discovery process and not make further requests to that LIS on
that network interface. that network interface.
DHCP discovery MUST be attempted before DNS discovery. This allows DHCP discovery MUST be attempted before DNS discovery. This allows
the network access provider a direct and explicit means of the network access provider a direct and explicit means of
configuring a LIS address. DNS discovery is used as a failsafe, configuring a LIS address. DNS discovery is used as a failsafe,
providing a means to discover a LIS where the DHCP infrastructure providing a means to discover a LIS where the DHCP infrastructure
does not support the LIS URI option. does not support the LIS URI option.
LIS discovery through DNS requires the host to determine the domain
name of the local access network. Where DHCP is available, the DHCP
domain name option (Section 4.1) can be used to provide this
information. If the domain name cannot be determined from DHCP, or
the resulting domain name fails to yield a valid LIS address then
reverse DNS is used. Alternative methods for determining the domain
name MAY be used, providing they consider the guidance in
Section 4.2.2.
Static host configuration MAY be used to provide a LIS address if Static host configuration MAY be used to provide a LIS address if
both DHCP and DNS methods fail. Note however, that if a host has both DHCP and DNS methods fail. Note however, that if a host has
moved from its customary location, static configuration might moved from its customary location, static configuration might
indicate a LIS that is unable to provide a location. indicate a LIS that is unable to provide a location.
If the discovery process fails, user interaction is NOT RECOMMENDED. If the discovery process fails, user interaction is NOT RECOMMENDED.
The discovery process is not easily diagnosed by a user. The discovery process is not easily diagnosed by a user.
LIS discovery through DNS requires the host to determine the domain The product of the LIS discovery process is an http: or https: URI.
name of the local access network. Where DHCP is available, the DHCP Nothing distinguishes this URI from other URIs with the same scheme,
domain name option (Section 4.1) can be used to provide this aside from the fact that it is the product of this process. Only
information. If the domain name cannot be determined from DHCP, or URIs produced by the discovery process can be used for location
the resulting domain name fails to yield a valid LIS address then configuration using HELD. URIs that are not a product of LIS
reverse DNS is used. discovery MUST NOT be used for location configuration.
5.1. Virtual Private Networks (VPNs) 5.1. Virtual Private Networks (VPNs)
LIS discovery over a VPN network interface SHOULD NOT be performed LIS discovery over a VPN network interface SHOULD NOT be performed
since such a LIS does not have the physical presence generally since such a LIS does not have the physical presence generally
necessary to determine location. However, since not all interfaces necessary to determine location. However, since not all interfaces
connected to a VPN can be detected by hosts, a LIS SHOULD NOT provide connected to a VPN can be detected by hosts, a LIS SHOULD NOT provide
location information in response to requests originating from a VPN location information in response to requests originating from a VPN
pool. This ensures that even if a host discovers a LIS over the VPN, pool. This ensures that even if a host discovers a LIS over the VPN,
it does not rely on a LIS that is unable to provide accurate location it does not rely on a LIS that is unable to provide accurate location
skipping to change at page 20, line 37 skipping to change at page 20, line 37
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006. Option", RFC 4704, October 2006.
[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.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for NAT (STUN)",
draft-ietf-behave-rfc3489bis-18 (work in progress), draft-ietf-behave-rfc3489bis-18 (work in progress),
July 2008. July 2008.
[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.
10.2. Informative References 10.2. Informative References
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
skipping to change at page 21, line 23 skipping to change at page 21, line 23
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
progress), June 2008. progress), June 2008.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-09 (work in draft-ietf-geopriv-http-location-delivery-10 (work in
progress), September 2008. progress), October 2008.
[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. 10 change blocks. 
19 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/