draft-ietf-geopriv-res-gw-lis-discovery-05.txt   draft-ietf-geopriv-res-gw-lis-discovery-06.txt 
GEOPRIV M. Thomson GEOPRIV M. Thomson
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Informational R. Bellis Intended status: Standards Track R. Bellis
Expires: October 7, 2013 Nominet UK Expires: March 10, 2014 Nominet UK
April 5, 2013 September 06, 2013
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-05 draft-ietf-geopriv-res-gw-lis-discovery-06
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.
This document describes a solution to this problem. The solution This document describes a solution to this problem. The solution
provides alternative domain names as input to the LIS discovery provides alternative domain names as input to the LIS discovery
process based on the network addresses assigned to a Device. process based on the network addresses assigned to a Device.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 7, 2013. This Internet-Draft will expire on March 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6 3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 5
3.2. Residential Gateway Security Features . . . . . . . . . . 7 3.2. Residential Gateway Security Features . . . . . . . . . . 6
4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 8 4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 6
4.1. Identification of IP Addresses . . . . . . . . . . . . . . 8 4.1. Identification of IP Addresses . . . . . . . . . . . . . 7
4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9 4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 8
4.3. When To Use The Reverse DNS Method . . . . . . . . . . . . 9 4.3. Shortened DNS Names . . . . . . . . . . . . . . . . . . . 8
4.4. Private Address Spaces . . . . . . . . . . . . . . . . . . 10 4.4. When To Use The Reverse DNS Method . . . . . . . . . . . 9
4.5. Necessary Assumptions and Restrictions . . . . . . . . . . 11 4.5. Private Address Spaces . . . . . . . . . . . . . . . . . 9
4.6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Necessary Assumptions and Restrictions . . . . . . . . . 10
4.7. Deployment Considerations . . . . . . . . . . . . . . . . 11 4.7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4.8. Deployment Considerations . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 15 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
A Location Information Server (LIS) is a service provided by an A Location Information Server (LIS) is a service provided by an
access network. The LIS uses knowledge of the access network access network. The LIS uses knowledge of the access network
topology and other information to generate location for Devices. topology and other information to generate location information for
Devices within an access network are able to acquire location Devices. Devices within an access network are able to acquire
information from a LIS. location information from a LIS.
The relationship between a Device and an access network might be The relationship between a Device and an access network might be
transient. Configuration of the correct LIS at the Device ensures transient. Configuration of the correct LIS at the Device ensures
that accurate location information is available. Without location that accurate location information is available. Without location
information, some network services are not available. information, some network services are not available.
The configuration of a LIS IP address on a Device requires some The configuration of a LIS IP address on a Device requires some
automated process. This is particularly relevant when it is automated process. This is particularly relevant when one considers
considered that Devices might move between different access networks that Devices might move between different access networks served by
served by different LISs. LIS Discovery [RFC5986] describes a method different LISs. LIS Discovery [RFC5986] describes a method that
that employs the Dynamic Host Configuration Protocol (DHCPv4 employs the Dynamic Host Configuration Protocol (DHCPv4 [RFC2131],
[RFC2131], DHCPv6 [RFC3315]) as input to U-NAPTR [RFC4848] discovery. DHCPv6 [RFC3315]) as input to U-NAPTR [RFC4848] discovery.
A residential gateway, or home router, provides a range of networking A residential gateway, or home router, provides a range of networking
functions for Devices within the network it serves. Unfortunately in functions for Devices within the network it serves. Unfortunately in
most cases these functions effectively prevent the successful use of most cases these functions effectively prevent the successful use of
DHCP for LIS discovery. DHCP for LIS discovery.
One drawback with DHCP is that universal deployment of a new option One drawback with DHCP is that universal deployment of a new option
takes a considerable amount of time. Often, networking equipment takes a considerable amount of time. Often, networking equipment
needs to be updated in order to support the new option. Of needs to be updated in order to support the new option. Of
particular concern are the millions of residential gateway devices particular concern are the millions of residential gateway devices
skipping to change at page 3, line 51 skipping to change at page 3, line 38
address when a residential gateway is interposed between the Device address when a residential gateway is interposed between the Device
and access network. Section 3 defines the problem and Section 4 and access network. Section 3 defines the problem and Section 4
describes a method for determining a domain name that can be used for describes a method for determining a domain name that can be used for
discovery of the LIS. discovery of the LIS.
In some cases, the solution described in this document is based on a In some cases, the solution described in this document is based on a
UNilateral Self-Address Fixing (UNSAF) [RFC3424] method. For those UNilateral Self-Address Fixing (UNSAF) [RFC3424] method. For those
cases, this solution is considered transitional until such time as cases, this solution is considered transitional until such time as
the recommendations for residential gateways in [RFC5986] are more the recommendations for residential gateways in [RFC5986] are more
widely deployed. Considerations relating to UNSAF applications are widely deployed. Considerations relating to UNSAF applications are
described in Section 7. described in Section 8.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses terminology established in [RFC3693] and This document uses terminology established in [RFC6280] and
[RFC5012]. [RFC5012]. The terms Device and LIS are capitalized throughout when
they are used to identify the roles defined in [RFC6280].
3. Problem Statement 3. Problem Statement
Figure 1 shows a simplified network topology for fixed wire-line Figure 1 shows a simplified network topology for fixed wire-line
Internet access. This arrangement is typical when wired Internet Internet access. This arrangement is typical when wired Internet
access is provided. The diagram shows two network segments: the access is provided. The diagram shows two network segments: the
access network provided by an internet service provider (ISP), and access network provided by an internet service provider (ISP), and
the residential network served by the residential gateway. the residential network served by the residential gateway.
There are a number of variations on this arrangement, as documented There are a number of variations on this arrangement, as documented
in Section 3.1 of [RFC5687]. In each of these variations the goal of in Section 3.1 of [RFC5687]. In each of these variations the goal of
LIS discovery is to identify the LIS in the access network. LIS discovery is to identify the LIS in the access network.
skipping to change at page 5, line 17 skipping to change at page 4, line 14
Figure 1 shows a simplified network topology for fixed wire-line Figure 1 shows a simplified network topology for fixed wire-line
Internet access. This arrangement is typical when wired Internet Internet access. This arrangement is typical when wired Internet
access is provided. The diagram shows two network segments: the access is provided. The diagram shows two network segments: the
access network provided by an internet service provider (ISP), and access network provided by an internet service provider (ISP), and
the residential network served by the residential gateway. the residential network served by the residential gateway.
There are a number of variations on this arrangement, as documented There are a number of variations on this arrangement, as documented
in Section 3.1 of [RFC5687]. In each of these variations the goal of in Section 3.1 of [RFC5687]. In each of these variations the goal of
LIS discovery is to identify the LIS in the access network. LIS discovery is to identify the LIS in the access network.
________ ________
(/ \) (/ \)
(( Internet )) (( Internet ))
(\________/) (\________/)
| |
| |
.- - -|- - - - - - - - - - - -. .- - -|- - - - - - - - - - - -.
( | ) ( | )
( +--------+ +-------+ ) ( +--------+ +-------+ )
Access ( | Access |. . . .| LIS | ) Access ( | Access |. . . .| LIS | )
Network ( | Node | | | ) Network ( | Node | | | )
(ISP) ( +--------+ +-------+ ) (ISP) ( +--------+ +-------+ )
( \ \ ) ( \ \ )
`- - - -\- - - - - - - -\- - -' `- - - -\- - - - - - - -\- - -'
\ \ \ \
\ | \ |
.- - - - -\- - - - - - - + -. .- - - - -\- - - - - - - + -.
( \ | ) ( \ | )
( +-------------+ : ) ( +-------------+ : )
( | Residential | | ) ( | Residential | | )
Residential ( | Gateway | : ) Residential ( | Gateway | : )
Network ( +-------------+ | ) Network ( +-------------+ | )
( / \ / ) ( / \ / )
( / \ / ) ( / \ / )
( +--------+ +--------+ ) ( +--------+ +--------+ )
( | Device | | Device | ) ( | Device | | Device | )
( +--------+ +--------+ ) ( +--------+ +--------+ )
( ) ( )
`- - - - - - - - - - - - - -' `- - - - - - - - - - - - - -'
Figure 1: Simplified Network Topology Figure 1: Simplified Network Topology
A particularly important characteristic of this arrangement is the A particularly important characteristic of this arrangement is the
relatively small geographical area served by the residential gateway. relatively small geographical area served by the residential gateway.
Given a small enough area, it is reasonable to delegate the Given a small enough area, it is reasonable to delegate the
responsibility for providing Devices within the residential network responsibility for providing Devices within the residential network
with location information to the ISP. The ISP is able to provide with location information to the ISP. The ISP is able to provide
location information that identifies the residence, which should be location information that identifies the residence, which should be
adequate for a wide range of purposes. adequate for a wide range of purposes.
skipping to change at page 6, line 48 skipping to change at page 6, line 4
ISP network. For instance, DNS configuration typically points to a ISP network. For instance, DNS configuration typically points to a
DNS relay on the gateway device. This approach ensures that the DNS relay on the gateway device. This approach ensures that the
local network served by the gateway is able to operate without a local network served by the gateway is able to operate without a
connection to the ISP, but it also means that Devices are effectively connection to the ISP, but it also means that Devices are effectively
ignorant of the ISP network. ignorant of the ISP network.
[RFC5986] describes several methods that can be applied by a [RFC5986] describes several methods that can be applied by a
residential gateway to assist Devices in acquiring location residential gateway to assist Devices in acquiring location
information. For instance, the residential gateway could forward LIS information. For instance, the residential gateway could forward LIS
address information to hosts within the network it serves. address information to hosts within the network it serves.
Unfortunately, such an active involvement in the discovery process Unfortunately, such an active involvement in the discovery process
only works for new residential gateway devices that implement those only works for new residential gateway devices that implement those
recommendations. recommendations.
Where residential gateways already exist, direct involvement of the Where residential gateways already exist, direct involvement of the
gateway in LIS discovery requires that the residential gateway be gateway in LIS discovery requires that the residential gateway be
updated or replaced. The cost of replacement is difficult to justify updated or replaced. The cost of replacement is difficult to justify
to the owner of the gateway, especially when it is considered that to the owner of the gateway, especially when it is considered that
the gateway still fills its primary function: Internet access. the gateway still fills its primary function: Internet access.
Furthermore, updating the software in such devices is not feasible in
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 of 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 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 that 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. Residential Gateway Security Features 3.2. Residential Gateway Security Features
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
LIS discovery [RFC5986] uses a DNS-based Dynamic Delegation Discovery LIS discovery [RFC5986] uses a DNS-based Dynamic Delegation Discovery
Service (DDDS) system as the basis of discovery. Input to this Service (DDDS) system as the basis of discovery. Input to this
process is a domain name. Use of DHCP for acquiring the domain name process is a domain name. Use of DHCP for acquiring the domain name
is specified, but alternative methods of acquisition are permitted. is specified, but alternative methods of acquisition are permitted.
This document specifies a means for a device to discover several This document specifies a means for a Device to discover several
alternative domain names that can be used as input to the DDDS alternative domain names that can be used as input to the DDDS
process. These domain names are based on the IP address of the process. These domain names are based on the IP address of the
Device. Specifically, the domain names are a portion of the reverse Device. Specifically, the domain names are a portion of the reverse
DNS trees - either the ".in-addr.arpa." or ".ip6.arpa." tree. DNS trees - either the ".in-addr.arpa." or ".ip6.arpa." tree.
The goal of this process is to make a small number of DDDS queries in
order to find a LIS. After LIS discovery using the DHCP-based
process in [RFC5986] has failed, a Device can:
1. Collect a set of IP addresses that refer to the Device
(Section 4.1).
2. Convert each IP address into DNS names in the "in-addr.arpa." or
"ip6.arpa." tree (Section 4.2).
3. Perform the DDDS process for LIS discovery on those DNS names
([RFC5986]).
4. Shorten the DNS names by some number of labels and repeat the
DDDS process (Section 4.3).
A Device might be reachable at one of a number of IP addresses. In A Device might be reachable at one of a number of IP addresses. In
the process described, a Device first identifies each IP address that the process described, a Device first identifies each IP address that
it is potentially reachable from. From each of these addresses, the it is potentially reachable from. From each of these addresses, the
Device then selects up to three domain names for use in discovery. Device then selects up to three domain names for use in discovery.
These domain names are then used as input to the DDDS process. These domain names are then used as input to the DDDS process.
4.1. Identification of IP Addresses 4.1. Identification of IP Addresses
A Device identifies a set of potential IP addresses that currently A Device identifies a set of potential IP addresses that currently
result in packets being routed to it. These are ordered by result in packets being routed to it. These are ordered by
skipping to change at page 8, line 46 skipping to change at page 7, line 42
resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the
response. response.
Alternative methods for determining other IP addresses MAY be used by Alternative methods for determining other IP addresses MAY be used by
the Device. Universal Plug and Play (UPnP) the Device. Universal Plug and Play (UPnP)
[UPnP-IGD-WANIPConnection1] and NAT Port Mapping Protocol (NAT-PMP) [UPnP-IGD-WANIPConnection1] and NAT Port Mapping Protocol (NAT-PMP)
[I-D.cheshire-nat-pmp] are both able to provide the external address [I-D.cheshire-nat-pmp] are both able to provide the external address
of a residential gateway device when enabled. These as well as of a residential gateway device when enabled. These as well as
proprietary methods for determining other addresses might also be proprietary methods for determining other addresses might also be
available. Because there is no assurance that these methods will be available. Because there is no assurance that these methods will be
supported by any access network these methods are not mandated. Note supported by any access network, these methods are not mandated.
also that in some cases, methods that rely on the view of the network Note also that in some cases, methods that rely on the view of the
from the residential gateway device could reveal an address in a network from the residential gateway device could reveal an address
private address range (see Section 4.5). in a private address range (see Section 4.6).
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 9, line 22 skipping to change at page 8, line 18
4.2. Domain Name Selection 4.2. Domain Name Selection
The domain name selected for each resulting IP address is the name The domain name selected for each resulting IP address is the name
that would be used for a reverse DNS lookup. The domain name derived that 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 from an IP version 4 address is in the ".in-addr.arpa." tree and
follows the construction rules in Section 3.5 of [RFC1035]. The follows the construction rules in Section 3.5 of [RFC1035]. The
domain name derived from an IP version 6 address is in 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 ".ip6.arpa." tree and follows the construction rules in Section 2.5
of [RFC3596]. of [RFC3596].
4.3. Shortened DNS Names
Additional domain names are added to allow for a single DNS record to Additional domain names are added to allow for a single DNS record to
cover a larger set of addresses. If the search on the domain derived cover a larger set of addresses. If the search on the domain derived
from the full IP address does not produce a NAPTR record with the 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 desired service tag (e.g., "LIS:HELD"), a similar search is repeated
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, 18, 20 and 24 labels and the query repeated. successively by 16, 18, 20 and 24 labels and the query repeated.
This corresponds to a search on a /64, /56, /48 or /32 network This corresponds to a search on a /64, /56, /48 or /32 network
prefix. prefix.
DNS queries on other prefixes than those listed above SHOULD NOT be For example, the IPv4 address "192.0.2.75" could result in queries
performed in order to limit the number of DNS queries performed by to:
Devices. If no LIS is discovered by this method, the result will be
that no more than four U-NAPTR resolutions are invoked for each IP
address.
4.3. When To Use The Reverse DNS Method o 75.2.0.192.in-addr.arpa.
The DHCP method described in [RFC5986] SHOULD be attempted on all o 2.0.192.in-addr.arpa.
local network interfaces before attempting this method. This method
is employed either because DHCP is unavailable, when the DHCP server o 0.192.in-addr.arpa.
Similarly, the IPv6 address "2001:DB8::28e4:3a93:4429:dfb5" could
result in queries to:
o 5.b.f.d.9.2.4.4.3.9.a.3.4.e.8.2.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2
.ip6.arpa.
o 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
o 0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
o 8.b.d.0.1.0.0.2.ip6.arpa.
The limited number of labels by which each name is shortened is
intended to limit the number of DNS queries performed by Devices. If
no LIS is discovered by this method, the result will be that no more
than five U-NAPTR resolutions are invoked for each IP address.
4.4. When To Use The Reverse DNS Method
The DHCP method described in [RFC5986] MUST 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 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.
4.4. Private Address Spaces 4.5. Private Address Spaces
Addresses from a private use address space can be used as input to Addresses from a private use address space can be used as input to
this method. In many cases, this applies to addresses defined in this method. In many cases, this applies to addresses defined in
[RFC1918], though other address ranges could have limited [RFC1918], though other address ranges could have limited
reachability where this advice also applies. This is only possible reachability where this advice also applies. This is only possible
if a DNS server with a view of the same address space is used. if a DNS server with a view of the same address space is used.
Public DNS servers cannot provide useful records for private Public DNS servers cannot provide useful records for private
addresses. addresses.
Using an address from a private space in discovery can provide a more Using an address from a private space in discovery can provide a more
specific answer if the DNS server has records for that space. specific answer if the DNS server has records for that space. Figure
Figure 2 shows a network configuration where addresses from an ISP 2 shows a network configuration where addresses from an ISP network
network could better indicate the correct LIS. Records in DNS B can could better indicate the correct LIS. Records in DNS B can be
be provided for the 10.0.0.0/8 range, potentially dividing that range provided for the 10.0.0.0/8 range, potentially dividing that range so
so that a more local LIS can be selected. that a more local LIS can be selected.
_____ ________ _____ ________
( DNS ).....(/ \) Public ( DNS ).....(/ \) Public
(__A__) (( Internet )) Address (__A__) (( Internet )) Address
(\________/) Space (\________/) Space
| |
[NAT] [NAT]
_____ _____|_____ _____ _____|_____
( DNS )....(/ \) Private ( DNS )....(/ \) Private
(__B__) (( ISP Network )) Address Space (__B__) (( ISP Network )) Address Space
(\___________/) (e.g. 10.0.0.0/8) (\___________/) (e.g. 10.0.0.0/8)
| |
[Gateway] [Gateway]
____|____ ____|____
(/ \) Private (/ \) Private
(( Residence )) Address Space (( Residence )) Address Space
(\_________/) (e.g. 192.168.0.0/16) (\_________/) (e.g. 192.168.0.0/16)
Figure 2: Address Space Example Figure 2: Address Space Example
The goal of automatic DNS configuration is usually to select a local The goal of automatic DNS configuration is usually to select a local
DNS, which suits configurations like the one shown. However, use of DNS, which suits configurations like the one shown. However, use of
public DNS or STUN servers means that a public IP address is likely public DNS or STUN servers means that a public IP address is likely
to be found. For STUN in particular, selecting a public server to be found. For STUN in particular, selecting a public server
minimizes the need for reconfiguration when a Device moves. Adding minimizes the need for reconfiguration when a Device moves. Adding
records for the public address space used by an access network records for the public address space used by an access network
ensures that the discovery process succeeds when a public address is ensures that the discovery process succeeds when a public address is
used. used.
4.5. Necessary Assumptions and Restrictions 4.6. 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 8.
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 7) might require that the address be verified
to limit the chance of falsification. to limit the chance of falsification.
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 the access network used by a Device is in some way controlled by the access network
provider, or some other related party. This implies that the provider, or some other related party. This implies that the
corresponding ".in-addr.arpa." or ".ip6.arpa." record can be updated corresponding ".in-addr.arpa." or ".ip6.arpa." record can be updated
by that entity to include a useful value for the LIS address. by that entity to include a useful value for the LIS address.
4.6. Failure Modes 4.7. Failure Modes
Successful use of private addresses relies on a DNS server that has Successful use of private addresses relies on a DNS server that has
records for the address space that is used. Using a public IP records for the address space that is used. Using a public IP
address increases the likelihood of this. 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 a STUN server is necessary to ensure that this is
successful. successful.
Alternative methods for discovering external IP addresses are
possible, including UPnP and NAT-PMP. These methods might not be
supported by the residential gateway and cannot be relied upon in all
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.7. Deployment Considerations 4.8. 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 server internal to
that NAT SHOULD also include records for the private address range. Any DNS server internal to a NAT SHOULD also include records for the
private address range. These records might only be provided to
clients making requests from the private address range. Doing so
allows clients within the private address range to discover a LIS
based on their IP address prior to any address translation. In
geographically distributed networks that use a private address range,
this enables the use of a different LIS for different locations,
based on the IP address range used at each location. Use of a
public, translated IP address for the network can still work, but it
might result in a suboptimal LIS selection.
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 higher nodes of the tree (corresponding to /24 and /16 for IPv4; /
IPv4; /64, /48 and /32 for IPv6). A record at a higher point in the 64, /56, /48 and /32 for IPv6). A record at a higher point in the
tree (those with a shorter prefix) applies to all addresses lower in tree (those with a shorter prefix) applies to all addresses lower in
the tree (those with a longer prefix); records at the lower point the tree (those with a longer prefix); records at the lower point
override those at higher points, thus allowing for exceptions to be override those at higher points, thus allowing for exceptions to be
specified. specified.
5. IANA Considerations 5. IANA Considerations
[RFC Editor: please remove this section prior to publication.] [RFC Editor: please remove this section prior to publication.]
This document has no IANA actions. This document has no IANA actions.
6. Security Considerations 6. Privacy Considerations
As with all uses of geolocation information, it is very important
that measures be taken to ensure that location information is not
provided to unauthorized parties. The mechanism defined in this
document is focused on the case where a device is learning its own
location, so that it can provide that location information to
applications. We assume that the device learning its own location is
not a privacy risk. There are then two remaining privacy risks: The
use of geolocation by applications, and abuse of the location
configuration protocol.
The privacy considerations around the use of geolocation by
applications vary considerably by application context. A framework
for location privacy in applications is provided in [RFC6280].
The mechanism specified in this document allows a device to discover
its local LIS, from which it then acquires its location using a
Location Configuration Protocol [RFC5687]. If an unauthorized third
party can spoof the LCP to obtain a target's location information,
then the mechanism in this document could allow them to discover the
proper server to attack for a given IP address. Thus, it is
important that a LIS meet the security requirements of the LCP it
implements. For HELD, these requirements are laid out in Section 9
of [RFC5985].
A Device that discovers a LIS using the methods in this document MUST
NOT provide that LIS with additional information that might reveal
its position, such as the location measurements described in
[I-D.ietf-geopriv-held-measurements], unless it has a secondary
method for determining the authenticity of the LIS, such as a white
list.
7. Security Considerations
The security considerations described in [RFC5986] apply to the The security considerations described in [RFC5986] apply to the
discovery process as a whole. The primary security concern is with discovery process as a whole. The primary security concern is with
the potential for an attacker to impersonate a LIS. the potential for an attacker to impersonate a LIS.
The added ability for a third party to discover the identity of a LIS The added ability for a third party to discover the identity of a LIS
does not add any concerns, since the identity of a LIS is considered does not add any concerns, since the identity of a LIS is considered
public information. public information.
In addition to existing considerations, this document introduces In addition to existing considerations, this document introduces
further security considerations relating to the identification of the further security considerations relating to the identification of the
IP address. It is possible that an attacker could attempt to provide IP address. It is possible that an attacker could attempt to provide
a falsified IP addresses in an attempt to subvert the rest of the a falsified IP address in an attempt to subvert the rest of the
process. process.
[RFC5389] describes attacks where an attacker is able to ensure that [RFC5389] describes attacks where an attacker is able to ensure that
a Device receives a falsified reflexive address. Even if the STUN a Device receives a falsified reflexive address. An on-path attacker
server is trusted, an attacker might be able to ensure that a might be able to ensure that a falsified address is provided to the
falsified address is provided to the Device. Device. Even though STUN messages are protected by a STUN MESSAGE-
INTEGRITY attribute, which is an HMAC that uses a shared secret, an
on-path attacker can capture and modify packets, altering source and
destination addresses to provide falsified addresses.
This attack could result in an effective means of denial of service, This attack could result in an effective means of denial of service,
or a means to provide a deliberately misleading service. Notably, or a means to provide a deliberately misleading service. Notably,
any LIS that is identified based on a falsified IP address could any LIS that is identified based on a falsified IP address could
still be a valid LIS for the given IP address, just not one that is still be a valid LIS for the given IP address, just not one that is
useful for providing the Device with location information. In this useful for providing the Device with location information. In this
case, the LIS provides a HELD "notLocatable" error, or an equivalent. case, the LIS provides a HELD "notLocatable" error, or an equivalent.
If the falsified IP address is under the control of the attacker, it If the falsified IP address is under the control of the attacker, it
is possible that misleading (but verifiable) DNS records could is possible that misleading (but verifiable) DNS records could
indicate a malicious LIS that provides false location information. indicate a malicious LIS that provides false location information.
In all cases of falsification, the best remedy is to perform some In all cases of falsification, the best remedy is to perform some
form of independent verification of the result. No specific form of independent verification of the result. No specific
mechanism is currently available to prevent attacks based on mechanism is currently available to prevent attacks based on
falsification of reflexive addresses; it is suggested that Devices falsification of reflexive addresses; it is suggested that Devices
attempt to independently verify that the reflexive transport address attempt to independently verify that the reflexive transport address
provided is accurate. provided is accurate. An independent, trusted source of location
information could aid in verification, even in the trusted source is
unable to provide information with the same accuracy as the
discovered LIS.
Use of private address space effectively prevents use of the usual Use of private address space effectively prevents use of the usual
set of trust anchors for DNSSEC. Only a DNS server that is able to set of trust anchors for DNSSEC. Only a DNS server that is able to
see the same private address space can provide useful records. A see the same private address space can provide useful records. A
Device that relies on DNS records in the private address space Device that relies on DNS records in the private address space
portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use
an alternative trust anchor for these records or rely on other means an alternative trust anchor for these records or rely on other means
of ensuring the veracity of the DNS records. of ensuring the veracity of the DNS records.
7. IAB Considerations 8. IAB Considerations
The IAB has studied the problem of Unilateral Self-Address Fixing The IAB has studied the problem of Unilateral Self-Address Fixing
(UNSAF) [RFC3424], which is the general process by which a client (UNSAF) [RFC3424], which is the general process by which a client
attempts to determine its address in another realm on the other side attempts to determine its address in another realm on the other side
of a NAT through a collaborative protocol reflection mechanism, such of a NAT through a collaborative protocol reflection mechanism, such
as STUN. as STUN.
This section only applies to the use of this method of LIS discovery This section only applies to the use of this method of LIS discovery
by Devices and does not apply to its use for third-party LIS by Devices and does not apply to its use for third-party LIS
discovery. discovery.
skipping to change at page 15, line 37 skipping to change at page 14, line 14
[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.5. this solution are included in Section 4.6.
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 17, line 5 skipping to change at page 14, line 43
5. Discussion of the impact of the noted practical issues with 5. Discussion of the impact of the noted practical issues with
existing deployed NATs and experience reports. existing deployed NATs and experience reports.
The UNSAF mechanism depends on the experience in deployment of The UNSAF mechanism depends on the experience in deployment of
STUN [RFC5389]. On the whole, existing residential gateway STUN [RFC5389]. On the whole, existing residential gateway
devices are able to provide access to STUN and DNS service devices are able to provide access to STUN and DNS service
reliably, although regard should be given to the size of the DNS reliably, although regard should be given to the size of the DNS
response (see [RFC5625]). response (see [RFC5625]).
8. References 9. Acknowledgements
8.1. Normative References Richard Barnes provided the text in Section 6.
10. References
10.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[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.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
October 2003. October 2003.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986, Location Information Server (LIS)", RFC 5986, September
September 2010. 2010.
8.2. Informative References [I-D.ietf-geopriv-held-measurements]
Thomson, M. and J. Winterbottom, "Using Device-provided
Location-Related Measurements in Location Configuration
Protocols", draft-ietf-geopriv-held-measurements-08 (work
in progress), June 2013.
10.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets", BCP
BCP 5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
RFC 2131, March 1997. 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3424] Daigle, L. IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[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.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies", Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008. RFC 5012, January 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"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.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, July 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. and M. Krochmal, "NAT Port Mapping Protocol Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol
(NAT-PMP)", draft-cheshire-nat-pmp-07 (work in progress), (NAT-PMP)", draft-cheshire-nat-pmp-07 (work in progress),
January 2013. January 2013.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP
BCP 152, RFC 5625, August 2009. 152, RFC 5625, August 2009.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC
RFC 5985, September 2010. 5985, September 2010.
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Microsoft Microsoft
3210 Porter Drive 3210 Porter Drive
Palo Alto, CA 94304 Palo Alto, CA 94304
US US
Phone: +1 650-353-1925 Phone: +1 650-353-1925
 End of changes. 52 change blocks. 
152 lines changed or deleted 249 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/