Location Information Server (LIS) Discovery From Behind Residential Gateways
draft-thomson-geopriv-res-gw-lis-discovery-00

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 16, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

The residential gateway is an ubiquitous device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of aquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway.

This document describes the problem of discovering a LIS in the presence of a residential gateway. The current version includes two proposed solutions to this problem, which will be evaluated.

Table of Contents

1.  Introduction
2.  Conventions used in this document
3.  Problem Statement
    3.1.  Residential Gateway
    3.2.  Use of Discovery for Third Party Queries
    3.3.  Additional and Optional Constraints
    3.4.  Solution Descriptions
4.  IP-based DNS Solution
    4.1.  Identification of IP Addresses
    4.2.  DDDS Lookup
    4.3.  When To Use This Method
    4.4.  Necessary Assumptions and Restrictions
    4.5.  Failure Modes
    4.6.  Deployment Considerations
5.  Anycast DNS Method
    5.1.  Overview of Operation
        5.1.1.  Choice of Domain Name
    5.2.  When To Use This Method
    5.3.  Necessary Assumptions and Restrictions
    5.4.  Failure Modes
    5.5.  Deployment Considerations
    5.6.  Speculation On This Method
    5.7.  Alternatives
6.  IANA Considerations
7.  Security Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References

1.  Introduction

A Location Information Server (LIS) is a service provided by an access network. The LIS uses knowledge of the access network topology and other information to generate location for Devices. Devices within an access network are able to acquire location information from a LIS.

The relationship between a Device and an access network might be transient. Configuration of the correct LIS at the Device ensures that accurate location information is available. Without location information, some network services are not available.

The configuration of a LIS address on a Device requires some automated configuration process. This is particularly relevant when it is considered that Devices might move between different access networks. LIS Discovery (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) [I‑D.ietf‑geopriv‑lis‑discovery] describes a method that employs the Dynamic Host Configuration Protocol (DHCPv4 (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [RFC2131], DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315]) for Device configuration.

The drawback with DHCP is that universal deployment of a relatively new option takes a considerable amount of time. Often, networking equipment needs to be updated in order to support the new option. Of particular concern are the millions of residential gateway devices used to provide Internet access to homes and businesses.

A residential gateway, or home router, provides a range of networking functions for Devices within the network it serves. In most cases, these functions effectively prevent the successful use of DHCP for LIS discovery.

This document explores the problem of configuring Devices with a LIS address when a residential gateway is interposed between the Device and access network. Section 3 (Problem Statement) defines the problem and subsequent sections explore alternative solutions to this problem.

2.  Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

This document uses terminology established in [RFC3693] (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.) and [I‑D.ietf‑ecrit‑requirements] (Schulzrinne, H. and R. Marshall, “Requirements for Emergency Context Resolution with Internet Technologies,” March 2007.).

3.  Problem Statement

Figure 1 (Simplified Network Topology) shows a simplified network topology for fixed wireline Internet access. This arrangement is typical when wired Internet access is provided. The diagram shows two network segments: the access network provided by an internet service provider (ISP), and the residential network served by the residential gateway.

There are a number of variations on this arrangement, as documented in Section 3.1 of [I‑D.ietf‑geopriv‑l7‑lcp‑ps] (Tschofenig, H. and H. Schulzrinne, “GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements,” July 2009.). Irrespective of any variations, the goal of LIS discovery in this scenario is to identify the LIS in the access network.

                 ________
               (/        \)
              (( Internet ))
               (\________/)
                    |
                    |
              .- - -|- - - - - - - - - - - -.
             (      |                        )
            (   +--------+       +-------+    )
  Access    (   | Access |. . . .|  LIS  |    )
  Network   (   |  Node  |       |       |    )
   (ISP)    (   +--------+       +-------+    )
             (       \               \       )
              `- - - -\- - - - - - - -\- - -'
                       \               \
                        \               |
               .- - - - -\- - - - - - - + -.
              (           \             |   )
             (      +-------------+     :    )
             (      | Residential |     |    )
 Residential (      |   Gateway   |     :    )
   Network   (      +-------------+     |    )
             (         /        \      /     )
             (        /          \    /      )
             (   +--------+    +--------+    )
             (   | Device |    | Device |    )
             (   +--------+    +--------+    )
              (                             )
               `- - - - - - - - - - - - - -'

A particularly important characteristic of this arrangement is the relatively small area served by the residential gateway. Given a small enough area, it is reasonable to delegate the responsibility for providing location information to Devices in the residential network to the ISP. The ISP is able to provide location information that identifies the residence, which is currently considered adequate for a range of purposes. A network that covered a larger area might require a dedicated LIS, a case that is outside the scope of this document.

In the network topology described, the goal of LIS discovery at a Device is to successfully identify the LIS in the access network. The residential gateway is a major obstacle in achieving this goal.

R1.

An alternative method for LIS discovery MUST be provided such that a Device is able to successfully discover a LIS when a residential gateway exists between the Device and the access network providing the LIS.

3.1.  Residential Gateway

A residential gateway can encompass several different functions including: modem, Ethernet switch, wireless access point, router, network address translation (NAT), DHCP server, DNS relay and firewall. Of the common functions provided, the NAT function of a residential gateway has the greatest impact on LIS discovery.

An ISP is typically parsimonious about their IP address allocations; each customer is allocated a limited number of IP addresses. Therefore, NAT is an extremely common function of gateways. NAT enables the use of multiple Devices within the residential network and it could be argued that such widespread use of NAT has delayed the inevitable exhaustion of the IPv4 address pool. However, NAT also means that Devices within the residence are not configured by the ISP directly.

When it comes to discovering a LIS, the fact that Devices are not configured by the ISP causes a significant problem. Configuration is the ideal method of conveying the information necessary for discovery. Devices attached to residential gateways are usually given a generic configuration that includes no information about the ISP network. For instance, DNS configuration typically points to a DNS relay on the gateway device. This approach ensures that the local network served by the gateway is able to operate without a connectionto the ISP, but it also means that Devices are effectively ignorant of the ISP network.

A residential gateway could forward LIS address information to hosts within the network it serves. If the residential gateway were able to acquire LIS address configuration from the access network, it could distribute this information using DHCP to hosts within that network. Alternatively, a similar approach to that taken for DNS could be used—a relay would ensure that Devices configured before the gateway is able to acquire configuration from the ISP network. This approach is recommended for new residential gateway devices.

Where residential gateways already exist, direct involvement of the gateway in LIS discovery requires that the residential gateway be updated or replaced. The cost of replacement is difficult to justify to the owner of the gateway, especially when it is considered that the gateway still fills its intended function.

Existing residential gateways have proven to be quite reliable devices, some operating continuously for many years without failure. As a result, there are many operational gateways that are a considerable age, some well outside the period of manufacturer support. Updating the software in such devices is not feasible in many cases. Even if software updates were made available, many residential gateways cannot be updated remotely, inevitably leading to some proportion that is not updated.

R2.

The alternative LIS discovery method MUST be able to successfully discover a LIS without any assistance from a residential gateway.

3.2.  Use of Discovery for Third Party Queries

It is desirable that any discovery mechanism is able to be used by hosts outside of the access network. This facilitates third party queries (see [I‑D.winterbottom‑geopriv‑held‑identity‑extensions] (Thomson, M., Tschofenig, H., Barnes, R., and J. Winterbottom, “Use of Target Identity in HTTP-Enabled Location Delivery (HELD),” August 2009.)) by enabling identification of the correct LIS to ask.

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 accomodate calling devices that are unable to acquire location information and convey ([I‑D.ietf‑sip‑location‑conveyance] (Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” March 2009.)) that information with call signalling. In these circumstances

Additional methods for third parties to determine the correct LIS to query are possible. Within the confines of a particular jurisdiction, it is more feasible to coordinate such things as national ISP databases, which are one potential solution to this problem. However, if a discovery solution also enabled third party discovery, that would be a distinct advantage of that solution.

R3.

The alternative LIS discovery method MAY provide a means for a third party to discover a LIS.

A network that is able to guarantee availability of DHCP does not need to provide a secondary discovery capability for the benefit of the Devices within the network. However, if third party requests are desired, the supplementary discovery method could still be provided for the benefit of those third parties.

3.3.  Additional and Optional Constraints

Certain other properties of residential gateways constrain the potential solutions to this problem.

Operation of a network firewall function is often provided by residential gateways as a security measure. Security features like intrusion detection systems help protect users from attacks. Amoungst these protections is a port filter that prevents both inbound and outbound traffic on certain TCP and UDP ports. Therefore, any solution needs to consider the likelihood of traffic being blocked.

3.4.  Solution Descriptions

Any solution that addresses the problem of LIS discovery from a residential network SHOULD provide:

• A thorough description of the procedure that a Device follows to discover a LIS.
• A set of criteria used in selecting the procedure. E.g., are there any indications to a Device that this procedure should or should not be attempted?
• An exploration of the necessary assumptions associated with the procedure.
• Any applicability restrictions. E.g., does this only apply to networks that employ a particular access technology?
• A discussion of the failure modes and the consequences of particular failures. E.g., how can each step in the process fail? What happens? Be certain to consider use of the method in scenarios that do not involve residential gateways, such as within an corporate Ethernet network, or on a cellular network.

An appraisal of the benefits and shortcomings of the solution is not necessary, but unobvious advantages or disadvantages can be highlighted.

4.  IP-based DNS Solution

In this option, the Device first identifies its IP address or addresses. For each address, it attempts up to three Dynamic Delegation Discovery Service (DDDS) queries against the .in-addr.arpa. or .ip6.arpa. tree. The first resulting URI is used as the address of the LIS.

4.1.  Identification of IP Addresses

A Device identifies a set of potential IP addresses that currently result in packets being routed to it. These are ordered by proximity, with those addresses that are used in adjacent network segments being favoured over those used in public or remote networks. The first addresses in the set are those that are assigned to local network interfaces.

A Device can use the Session Traversal Utilities for NAT (STUN) [I‑D.ietf‑behave‑rfc3489bis] (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for (NAT) (STUN),” July 2008.) to determine its public reflexive transport address. The host uses the Binding Request message and the resulting XOR-MAPPED-ADDRESS parameter that is returned in the response.

Alternative methods for determining other IP addresses MAY be used by the host. Universal Plug and Play (UPnP) (UPnP Forum, “Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0: WANIPConnection:1 Service Template Version 1.01 For UPnP Version 1.0,” Nov 2001.) [UPnP‑IGD‑WANIPConnection1] and NAT Port Mapping Protocol (NAT-PMP) (Cheshire, S., “NAT Port Mapping Protocol (NAT-PMP),” April 2008.) [I‑D.cheshire‑nat‑pmp] are both able to provide the external address of a routing device. Proprietary methods for determining other addresses might also be available. Because there is no assurance that these methods will be supported by any access network these methods are not mandated.

4.2.  DDDS Lookup

The U-NAPTR (Daigle, L., “Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS),” April 2007.) [RFC4848] application defined in [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) is used based on an input domain name derived from each IP address. The input domain name is the exact same as 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 follows the construction rules in Section 3.5 of [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.). 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 of [RFC3596] (Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, “DNS Extensions to Support IP Version 6,” October 2003.).

If the search on the domain derived 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 based on a part of the IP address.

• For IP version 4, the resulting domain name SHOULD be shortened by one or two labels and the query repeated. This corresponds to a search on a /24 or /16 network prefix. This allows for fewer DNS records in the case where a single ISP controls an entire /24 or /16 network.
• For IP version 6, the resulting domain SHOULD be shortened by either 16 or 20 labels and the query repeated. This corresponds to a search on a /64 or /48 network prefix.

DNS queries on other prefixes than those listed above SHOULD NOT be performed to limit the number of DNS queries performed by Devices. If no LIS is discovered by this method, three U-NAPTR resolutions are invoked for each IP address.

4.3.  When To Use This Method

The DHCP method described in [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) SHOULD be attempted on all local network interfaces before attempting this method. This method is employed either because DHCP is unavailable, when the DHCP server does not provide a value for the LIS address option, or if a request the address identified results in a HELD notLocatable error or equivalent.

This method can also be used to facilitate third party queries, as described in Section 3.2 (Use of Discovery for Third Party Queries). Based on a known IP address, the LIS that serves that address can be identified.

4.4.  Necessary Assumptions and Restrictions

Addresses for private address ranges (10.0.0.0/8, 192.168.0.0/16 or similar) MAY be used as input to this method. However, if private addresses are used, only a DNS server within that network is able to provide the DNS mappings for the private address used; the public DNS does not contain useful records for private address ranges.

Private addresses are never the final option for this method. Public reflexive transport addresses acquired from a STUN server ensure that the entity providing access to the public Internet is identified. This solution assumes access to a STUN server that is able to view addresses from the public Internet.

This solution assumes that the public reflexive transport address used by a Device is in some way controlled by their ISP, or some other related party. This imples that the corresponding .in-addr.arpa. or .ip6.arpa. record can be updated by that entity to include a useful value for the LIS address.

4.5.  Failure Modes

Configuration of STUN server is vital to the success of this method. Alternative methods for discovering external IP addresses are possible, including UPnP and NAT-PMP. These methods might not be enabled on the residential gateway.

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 provide the Device with location information. It is assumed that this entity is able to identify this problem and indicate this to the Device (using the notLocatable HELD error, or similar).

4.6.  Deployment Considerations

An access network provider SHOULD provide NAPTR records for each 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 SHOULD also include records for the private address range.

NAPTR records can be provided for individual IP addresses. To limit 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 IPv4, /64 abnd /48 for IPv6). A record at a higher point in the tree applies to all addresses lower in the tree, records at the lower point are only necessary in the case of exceptions.

5.  Anycast DNS Method

Anycast is practice of making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available network locations [RFC4786] (Abley, J. and K. Lindqvist, “Operation of Anycast Services,” December 2006.).

One potential advantage of anycast is that datagrams can be routed to the node that is nearest according to the network topology. This discovery method relies on network routing configuration that directs requests to a server within the access network.

This solution uses a specially allocated IP address for anycast to contact the nearest host. Any access network MAY use this IP address for the purpose described here. The advantage is that this avoids any need for Device configuration; successful operation relies on routing configuration alone. This solutions is unaffected by use of network address translation (NAT) by intermediate network segmentss; the first network segment that provides the anycast address is the one that is contacted.

The special IP address is constrained to an access network, and routes to this address MUST NOT be advertised globally over Border Gateway Protocol (BGP) [RFC4271] (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.). This ensures that only Devices within the access network are able to access the host using this address.

Stateless transport is preferred for use with anycast unless routing is known to be stable on the duration of a typical session. Therefore, relying on anycast for use with HELD or any other protocol that relies on stateful protocols would be inadvisable. The discovery process need only rely on anycast for initial stages.

Use of anycast for DNS deployment is well established. This method relies upon use of a specific IP address that is directed to the nearest DNS server.

5.1.  Overview of Operation

A Device sends a DNS request to the allocated IP address. The request retrieves NAPTR records for the .access. top level domain. The U-NAPTR (Daigle, L., “Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS),” April 2007.) [RFC4848] DDDS application defined in [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) is used to determine a LIS URI.

[Open question: From RFC 2181 and the anti-forgery work, it appears that the source IP in the response datagram should be the anycast address. However, other discussion on anycast seems to indicate that an alternative (unicast) address could be used. If a unicast address is provided in the response, then when truncation is indicated, the Device could establish a TCP connection to the unicast address directly. This has none of the negative ramifications normally associated with use of TCP and anycast. Need to confirm, more for completeness than anything else.]

5.1.1.  Choice of Domain Name

The choice of a DNS name to use in the request is an important consideration, perhaps the most important. It is unlikely that a Device is able to select a name that has equal significance to the access network unless that name is fixed by specification.

Several potential options for the domain name have been presented. One option is to use the .local. suffix established in [I‑D.cheshire‑dnsext‑multicastdns] (Cheshire, S. and M. Krochmal, “Multicast DNS,” March 2010.). However, the semantics associated with that method appear not to be consistent with this usage. A new subdomain under the .arpa. root is also possible, although this implies allocation by the IANA, which is a small misrepresentation.

This document proposes that a new .access. root suffix be established for the purpose of identifying services associated with the network access. Any server can claim to be authoritative for this domain. All records associated with this domain and all sub-domains are MUST NOT be propagated and recursing resolvers MUST NOT recurse on queries to this domain. The root servers do not provide NS records for this domain. Servers SHOULD NOT propagate this information in zone transfers.

Because any server can be considered authoritative for .access., DNSSEC (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) [RFC4033] cannot be used to authenticate the RRs provided. What surety this method provides lies solely in the use of anycast to contact the DNS server.

5.2.  When To Use This Method

The DHCP method described in [I‑D.ietf‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” March 2010.) SHOULD be attempted on all local network interfaces before attempting this method. This method is employed either because DHCP is unavailable, when the DHCP server does not provide a value for the LIS address option, or if a request the address identified results in a HELD notLocatable error or equivalent.

5.3.  Necessary Assumptions and Restrictions

This solution requires specific network configuration where the allocated IP address is advertised within an access network. The allocated IP address MUST NOT be advertised globally on BGP. This method also assumes relative stability of the route between Device and DNS server.

5.4.  Failure Modes

This method is subject to any redirections that might happen to all Internet traffic. For instance, some residential gateways redirect all traffic through a virtual private network or other type of tunnel. If such a blanket redirection is used, the DNS request will traverse that tunnel and potentially reach the wrong server at the other end. Successful recognition of this situation relies on that LIS that is discovered using the HELD notLocatable error correctly.

5.5.  Deployment Considerations

An access network provider MAY use split-view DNS to ensure that the .access. tree doesn't appear to requesters outside the access network. This ensures that this information does not result in misleading information being accidentally propagated.

5.6.  Speculation On This Method

The use of a newly minted TLD and the special semantics associated with that label is likely to be the biggest problem with this solution. As happened with "Multicast DNS" (Cheshire, S. and M. Krochmal, “Multicast DNS,” March 2010.) [I‑D.cheshire‑dnsext‑multicastdns] this might be regarded as heretical and it could be resisted with a vigour usually reserved for protecting a favourite kind of text editor.

5.7.  Alternatives

There is no strong reason for use of DNS (or what might try to pass for DNS) with this anycast option. Adaptation of any number of a range of discovery protocols is possible. Typically, these protocols rely upon link-local multicast as an initial step. Altering this phase to use an assigned anycast address instead of multicast is a possibility.

6.  IANA Considerations

[RFC Editor: please remove this section prior to publication.]

This document has no IANA actions.

7.  Security Considerations

To be completed.

8.  Acknowledgements

The solution in Section 4 (IP-based DNS Solution) can be attributed to Ray Bellis, who probably should be listed as an author, except that I haven't asked him yet. The solution in Section 5 (Anycast DNS Method) comes via Dean Willis, but the details are entirely concocted by the author and any shortcomings should be attributed accordingly.

9.  References

9.1. Normative References

9.2. Informative References

Author's Address