draft-ietf-geopriv-l7-lcp-ps-10.txt   rfc5687.txt 
Network Working Group H. Tschofenig Internet Engineering Task Force (IETF) H. Tschofenig
Internet-Draft Nokia Siemens Networks Request for Comments: 5687 Nokia Siemens Networks
Intended status: Informational H. Schulzrinne Category: Informational H. Schulzrinne
Expires: January 14, 2010 Columbia University ISSN: 2070-1721 Columbia University
July 13, 2009 March 2010
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and
Requirements
draft-ietf-geopriv-l7-lcp-ps-10.txt
Status of this Memo GEOPRIV Layer 7 Location Configuration Protocol:
Problem Statement and Requirements
This Internet-Draft is submitted to IETF in full conformance with the Abstract
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document provides a problem statement, lists requirements, and
Task Force (IETF), its areas, and its working groups. Note that captures design aspects for a GEOPRIV Layer 7 (L7) Location
other groups may also distribute working documents as Internet- Configuration Protocol (LCP). This protocol aims to allow an end
Drafts. host to obtain location information, by value or by reference, from a
Location Information Server (LIS) that is located in the access
network. The obtained location information can then be used for a
variety of different protocols and purposes. For example, it can be
used as input to the Location-to-Service Translation (LoST) Protocol
or to convey location within the Session Initiation Protocol (SIP) to
other entities.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on January 14, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5687.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document provides a problem statement, lists requirements and described in the Simplified BSD License.
captures design aspects for a Geopriv Layer 7 Location Configuration
Protocol L7 (LCP). This protocol aims to allow an end host to obtain
location information, by value or by reference, from a Location
Information Server (LIS) that is located in the access network. The
obtained location information can then be used for a variety of
different protocols and purposes. For example, it can be used as
input to the Location-to-Service Translation Protocol (LoST) or to
convey location within SIP to other entities.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................3
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scenarios .......................................................4
3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5 3.1. Fixed-Wired Environment ....................................4
3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Mobile Network .............................................7
3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9 3.3. Wireless Access ............................................8
4. Discovery of the Location Information Server . . . . . . . . . 11 4. Discovery of the Location Information Server ....................9
5. Identifier for Location Determination . . . . . . . . . . . . 13 5. Identifier for Location Determination ..........................11
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Requirements ...................................................14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations ........................................16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Contributors ...................................................17
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgements ...............................................18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 10. References ....................................................18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References .....................................18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References ...................................18
11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document provides a problem statement, lists requirements and This document provides a problem statement, lists requirements, and
captures design aspects for a Geopriv Layer 7 Location Configuration captures design aspects for a GEOPRIV Layer 7 (L7) Location
Protocol L7 (LCP). The protocol has two purposes: Configuration Protocol (LCP). The protocol has two purposes:
o It is used to obtain location information (referred as "Location o It is used by a device to obtain its own location (referred as
by Value" or LbyV) from a dedicated node, called the Location "Location by Value" or LbyV) from a dedicated node, called the
Information Server (LIS). Location Information Server (LIS).
o It enables the Target to obtain a reference to location o It enables the device to obtain a reference to location
information (referred as "Location by Reference" or LbyR). This information (referred as "Location by Reference" or LbyR). This
reference can take the form of a subscription URI, such as a SIP reference can take the form of a subscription URI, such as a SIP
presence based Uniform Resource Identifier (URI), a HTTP/HTTPS presence-based Uniform Resource Identifier (URI), an HTTP/HTTPS
URI, or another URI. The requirements related to the task of URI, or another URI. The requirements related to the task of
obtaining a LbyR are described in a separate document, see obtaining an LbyR are described in a separate document, see
[I-D.ietf-geopriv-lbyr-requirements]. [LBYR-REQS].
The need for these two functions can be derived from the scenarios The need for these two functions can be derived from the scenarios
presented in Section 3. presented in Section 3.
For this document we assume that the Geopriv Layer 7 LCP runs between For this document, we assume that the GEOPRIV Layer 7 LCP runs
the end host (i.e., the Target in [RFC3693] terminology) and the LIS. between the device and the LIS.
This document is structured as follows. Section 4 discusses the This document is structured as follows. Section 4 discusses the
challenge of discovering the LIS in the access network. Section 5 challenge of discovering the LIS in the access network. Section 5
compares different types of identifiers that can be used to retrieve compares different types of identifiers that can be used to retrieve
location information. A list of requirements for the L7 LCP can be location information. A list of requirements for the L7 LCP can be
found in Section 6. found in Section 6.
This document does not describe how the access network provider This document does not describe how the access network provider
determines the location of the end host since this is largely a determines the location of the device since this is largely a matter
matter of the capabilities of specific link layer technologies or of the capabilities of specific link-layer technologies or certain
certain deployment environments. deployment environments.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 and "OPTIONAL" are to be interpreted as described in RFC 2119
[RFC2119], with the qualification that unless otherwise stated these [RFC2119], with the qualification that unless otherwise stated these
words apply to the design of the Geopriv Layer 7 Location words apply to the design of the GEOPRIV Layer 7 Location
Configuration Protocol. Configuration Protocol.
The term Location Information Server (LIS) refers to an entity The term Location Information Server (LIS) refers to an entity
capable of determining the location of a Target and of providing that capable of determining the location of a device and of providing that
location information, a reference to it, or both via the Location location information, a reference to it, or both via the Location
Configuration Protocol (LCP) to the requesting party. In most cases Configuration Protocol (LCP) to the Target.
the requesting party is the Target itself but it may also be an
authorized entity that acts on behalf of it, such as a SIP proxy or
another LIS.
This document also uses terminology from [RFC3693] (such as Target) This document also uses terminology from [RFC5012] (such as Internet
and [I-D.ietf-ecrit-requirements] (such as Internet Access Provider Access Provider (IAP), Internet Service Provider (ISP), and
(IAP), Internet Service Provider (ISP), and Application Service Application Service Provider (ASP)).
Provider (ASP)).
With the term "Access Network Provider" we refer to the Internet With the term "Access Network Provider" we refer to the IAP and the
Access Provider (IAP) and the Internet Service Provider (ISP) without ISP) without further distinguishing these two entities, as it is not
further distinguishing these two entities as it is not relevant for relevant for the purpose of this document. An additional
the purpose of this document. An additional requirements document on requirements document on LIS-to-LIS protocol [LIS2LIS] shows a
LIS-to-LIS [I-D.winterbottom-geopriv-lis2lis-req] shows scenario scenario where the separation between IAP and ISP is important.
where the separation between IAP and ISP is important.
3. Scenarios 3. Scenarios
This section describes a few network scenarios where the L7 LCP may This section describes a few network scenarios where the L7 LCP may
be used. Note that this section does not aim to exhaustively list be used. Note that this section does not aim to exhaustively list
all possible deployment environments. Instead we focus on the all possible deployment environments. Instead, we focus on the
following environments: following environments:
o DSL/Cable networks, WiMax-like fixed access o DSL/Cable networks, WiMAX-like (Worldwide Interoperability for
Microwave Access) fixed access
o Airport, City, Campus Wireless Networks, such as 802.11a/b/g, o Airport, city, campus wireless networks, such as 802.11a/b/g,
802.16e/Wimax 802.16e/WiMAX
o 3G networks o 3G networks
o Enterprise networks o Enterprise networks
We illustrate a few examples below. Note that we use the term 'host' instead of device for better
readability.
3.1. Fixed Wired Environment 3.1. Fixed-Wired Environment
Figure 1 shows a Digital subscriber line (DSL) network scenario with Figure 1 shows a Digital Subscriber Line (DSL) network scenario with
the Access Network Provider and the customer premises. The Access the Access Network Provider and the customer premises. The Access
Network Provider operates link and network layer devices (represented Network Provider operates link- and network-layer devices
as Node) and the LIS. (represented as a node) and the LIS.
+---------------------------+ +---------------------------+
| | | |
| Access Network Provider | | Access Network Provider |
| | | |
| +--------+ | | +--------+ |
| | Node | | | | Node | |
| +--------+ +----------+ | | +--------+ +----------+ |
| | | | LIS | | | | | | LIS | |
| | +---| | | | | +---| | |
skipping to change at page 6, line 35 skipping to change at page 5, line 35
| | | | | |
| | | | | |
| +--------------+ | | +--------------+ |
| | Device with | Home | | | Device with | Home |
| | NAPT and | Router | | | NAPT and | Router |
| | DHCP server | | | | DHCP server | |
| +--------------+ | | +--------------+ |
| | | | | |
| | | | | |
| +------+ | | +------+ |
| | End | |
| | Host | | | | Host | |
| +------+ | | +------+ |
| | | |
|Customer Premises Network | |Customer Premises Network |
| | | |
+---------------------------+ +---------------------------+
Figure 1: Fixed-wired Scenario Figure 1: Fixed-Wired Scenario
The customer premises consists of a router with a Network Address The customer premises network consists of a router with a Network
Translator with Port Address Translation (NAPT) and a DHCP server as Address Translator with Port Address Translation (NAPT) and a DHCP
used in most Customer Premises Networks (CPN) and the Network server as used in most Customer Premises Networks (CPNs) and the
Termination Equipment (NTE) where Layer 1 and sometimes Layer 2 Network Termination Equipment (NTE) where Layer 1 and sometimes Layer
protocols are terminated. The router in the home network (e.g., 2 protocols are terminated. The router in the home network (e.g.,
broadband router, cable or DSL router) typically runs a NAPT and a broadband router, cable or DSL router) typically runs a NAPT and a
DHCP server. The NTE is a legacy device and in many cases cannot be DHCP server. The NTE is a legacy device and in many cases cannot be
modified for the purpose of delivering location information to the modified for the purpose of delivering location information to the
end host. The same is true of the device with the NAPT and DHCP host. The same is true of the device with the NAPT and DHCP server.
server.
It is possible for the NTE and the home router to physically be in It is possible for the NTE and the home router to physically be in
the same box, or for there to be no home router, or for the NTE and the same box, or for there to be no home router, or for the NTE and
end host to be in the same physical box (with no home router). An host to be in the same physical box (with no home router). An
example of this last case is where Ethernet service is delivered to example of this last case is where Ethernet service is delivered to
customers' homes, and the Ethernet NIC in their PC serves as the NTE. customers' homes, and the Ethernet network interface card (NIC) in
their PC serves as the NTE.
Current Customer Premises Network (CPN) deployments generally fall Current CPN deployments generally fall into one of the following
into one of the following classifications: classifications:
1. Single PC 1. Single PC
1. with Ethernet network interface card (NIC) with Point-to- 1. with Ethernet network interface card (NIC), with Point-to-
Point Protocol Over Ethernet (PPPoE) or Dynamic Host Point Protocol Over Ethernet (PPPoE), or Dynamic Host
Configuration Protocol (DHCP) on PC; there may be a bridged Configuration Protocol (DHCP) on PC; there may be a bridged
DSL or cable modem as NTE, or the Ethernet NIC might be the DSL or cable modem as the NTE, or the Ethernet NIC might be
NTE the NTE.
2. with Universal Serial Bus (USB) based DSL access or a cable 2. with USB-based DSL access or a cable modem access using
modem access using Point-to-Point Protocol over ATM (PPPoA), Point-to-Point Protocol over ATM (PPPoA), PPPoE, or DHCP on
PPPoE, or DHCP on PC PC.
Note that the device with NAPT and DHCP of Figure 1 is not Note that the device with NAPT and DHCP of Figure 1 is not
present in such a scenario. present in such a scenario.
2. One or more hosts with at least one router (DHCP Client or PPPoE, 2. One or more hosts with at least one router (DHCP client or PPPoE,
DHCP server in router; VoIP can be soft client on PC, stand-alone DHCP server in router; Voice over IP (VoIP) can be a soft client
VoIP device, or Analog Terminal Adaptor (ATA) function embedded on a PC, a stand-alone VoIP device, or an Analog Terminal Adaptor
in router) (ATA) function embedded in a router):
1. combined router and NTE 1. combined router and NTE.
2. separate router with NTE in bridged mode 2. separate router with NTE in bridged mode.
3. separate router with NTE (NTE/router does PPPoE or DHCP to 3. separate router with NTE (NTE/router does PPPoE or DHCP to
WAN, router provides DHCP server for hosts in LAN; double WAN, router provides DHCP server for hosts in LAN; double
NAT) NAT).
The majority of fixed access broadband customers use a router. The The majority of fixed-access broadband customers use a router. The
placement of the VoIP client is mentioned to describe what sorts of placement of the VoIP client is mentioned to describe what sorts of
hosts may need to be able to request location information. Soft hosts may need to be able to request location information. Soft
clients on PCs are frequently not launched until long after bootstrap clients on PCs are frequently not launched until long after
is complete, and are not able to control any options that may be bootstrapping is complete, and are not able to control any options
specified during bootstrap. They also cannot control whether a VPN that may be specified during bootstrapping. They also cannot control
client is running on the end host. whether a VPN client is running on the end host.
3.2. Moving Network 3.2. Mobile Network
One example of a moving network is a WiMAX fixed wireless scenario. One example of a moving network is a WiMAX-fixed wireless scenario.
This also applies to "pre-WiMAX" and "WiMAX-like" fixed wireless This also applies to "pre-WiMAX" and "WiMAX-like" fixed wireless
networks. In implementations intended to provide broadband service networks. In implementations intended to provide broadband service
to a home or other stationary location, the customer-side antenna / to a home or other stationary location, the customer-side antenna/NTE
NTE tends to be rather small and portable. The LAN-side output of tends to be rather small and portable. The LAN-side output of this
this device is an Ethernet jack, which can be used to feed a PC or a device is an Ethernet jack, which can be used to feed a PC or a
router. The PC or router then uses DHCP or PPPoE to connect to the router. The PC or router then uses DHCP or PPPoE to connect to the
access network, the same as for wired access networks. Access access network, the same as for wired access networks. Access
providers who deploy this technology may use the same core network providers who deploy this technology may use the same core network
(including network elements that terminate PPPoE and provide IP (including network elements that terminate PPPoE and provide IP
addresses) for DSL, fiber to the premises (FTTP), and fixed wireless addresses) for DSL, fiber to the premises (FTTP), and fixed wireless
customers. customers.
Given that the customer antenna is portable and can be battery- Given that the customer antenna is portable and can be battery-
powered, it is possible for a user to connect a laptop to it and move powered, it is possible for a user to connect a laptop to it and move
within the coverage area of a single base antenna. This coverage within the coverage area of a single base antenna. This coverage
skipping to change at page 9, line 34 skipping to change at page 8, line 34
| | +---+ Host | | | | +---+ Host | |
| +-+-----++ | B | | | +-+-----++ | B | |
| | \ +--------+ | | | \ +--------+ |
| | \ | | | \ |
|+---+----+ \ +---+----+ | |+---+----+ \ +---+----+ |
|| Host | \ | Host | | || Host | \ | Host | |
|| A | \+ B | | || A | \+ B | |
|+--------+ +--------+ | |+--------+ +--------+ |
+--------------------------+ +--------------------------+
Figure 2: Moving Network Figure 2: Moving Network
3.3. Wireless Access 3.3. Wireless Access
Figure 3 shows a wireless access network where a moving end host Figure 3 shows a wireless access network where a moving host obtains
obtains location information or references to location information location information or references to location information from the
from the LIS. The access equipment uses, in many cases, link layer LIS. The access equipment uses, in many cases, link-layer devices.
devices. Figure 3 represents a hotspot network found, for example, Figure 3 represents a hotspot network found, for example, in hotels,
in hotels, airports, and coffee shops. For editorial reasons we only airports, and coffee shops. For editorial reasons we only describe a
describe a single access point and do not depict how the LIS obtains single access point and do not depict how the LIS obtains location
location information since this is very deployment specific. information since this is very deployment specific.
+--------------------------+ +--------------------------+
| Access Network Provider | | Access Network Provider |
| | | |
| +----------+| | +----------+|
| +-------| LIS || | +-------| LIS ||
| | | || | | | ||
| +--------+ +----------+| | +--------+ +----------+|
| | Access | | | | Access | |
| | Point | | | | Point | |
| +--------+ | | +--------+ |
| | | | | |
+------+-------------------+ +------+-------------------+
| |
+------+ +------+
| End | | Host |
| Host | +------+
+------+
Figure 3: Wireless Access Scenario Figure 3: Wireless Access Scenario
4. Discovery of the Location Information Server 4. Discovery of the Location Information Server
Note that this section lists mechanisms that were discussed in the Note that this section lists mechanisms that were discussed in the
Geopriv Layer 7 Location Configuration Protocol design team. They GEOPRIV Layer 7 Location Configuration Protocol design team. They
are included to show challenges in the problem space and are are included to show challenges in the problem space and are
listed for completeness reasons. They do not in any way mean that listed for completeness reasons. They do not in any way mean that
there is consensus about any of the mechanisms or that the IETF there is consensus about any of the mechanisms or that the IETF
recommends any of the procedures described in this section. recommends any of the procedures described in this section.
When a Target wants to retrieve location information from the LIS it When a device wants to retrieve location information from the LIS, it
first needs to discover it. Based on the problem statement of first needs to discover it. Based on the problem statement of
determining the location of the Target, which is known best by determining the location of the device, which is known best by
entities close to the Target itself, we assume that the LIS is entities close to the device itself, we assume that the LIS is
located in the local subnet or in access network. Several procedures located in the local subnet or in the access network. Several
have been investigated that aim to discover the LIS in such an access procedures have been investigated that aim to discover the LIS in
network. such an access network.
DHCP-based Discovery: DHCP-based Discovery:
In some environments the Dynamic Host Configuration Protocol In some environments, the Dynamic Host Configuration Protocol
(DHCP) might be a good choice for discovering the fully qualified (DHCP) might be a good choice for discovering the fully-qualified
domain name (FQDN) or the IP address of the LIS. In environments domain name (FQDN) or the IP address of the LIS. In environments
where DHCP can be used it is also possible to use the already where DHCP can be used, it is also possible to use the already
defined location extensions. In environments with legacy devices, defined location extensions. In environments with legacy devices,
such as the one shown in Section 3.1, a DHCP based discovery such as the one shown in Section 3.1, a DHCP-based discovery
solution may not be possible. solution may not be possible.
DNS-based Discovery: DNS-based Discovery:
Before a Domain Name System (DNS) lookup can be started it is Before a Domain Name System (DNS) lookup can be started, it is
necessary to learn the domain name of the access network that runs necessary to learn the domain name of the access network that runs
a LIS. Several ways to learn the domain name exist. For example, an LIS. Several ways to learn the domain name exist. For
the end host obtains its own public IP address, for example via example, the end host obtains its own public IP address via Simple
STUN [RFC3489], and performs a reverse DNS lookup (assuming the Traversal of the UDP Protocol through NAT (STUN) [RFC5389], and
data is provisioned into the DNS). Then, the DNS Service (SRV) performs a reverse DNS lookup (assuming the data is provisioned
record or the DNS Naming Authority Pointer (NAPTR) record for that into the DNS). Then, the DNS Service (SRV) record or the DNS
domain is retrieved. A more detailed description of this approach Naming Authority Pointer (NAPTR) record for that domain is
can be found in [I-D.thomson-geopriv-lis-discovery]. retrieved. A more detailed description of this approach can be
found in [LIS-DISC].
Redirect Rule: Redirect Rule:
A redirect rule at a device in the access network could be used to A redirect rule at an entity in the access network could be used
redirect the L7 LCP signalling messages (destined to a specific to redirect the L7 LCP signaling messages (destined to a specific
port) to the LIS. The end host could then discover the LIS by port) to the LIS. The device could then discover the LIS by
sending a packet with a specific (registered) port number to sending a packet with a specific (registered) port number to
almost any address (as long as the destination IP address does not almost any address as long as the destination IP address does not
target a device in the local network). The packet would be target an entity in the local network. The packet would be
redirected to the respective LIS being configured. The same redirected to the respective LIS being configured. The same
procedure is used by captive portals whereby any HTTP traffic is procedure is used by captive portals whereby any HTTP traffic is
intercepted and redirected. intercepted and redirected.
To some extend this approach is similar to packets that are marked To some extent, this approach is similar to packets that are
with a Router Alert option [RFC2113] and intercepted by entities marked with a Router Alert option [RFC2113] and intercepted by
that understand the specific marking. In the above-mentioned entities that understand the specific marking. In the above-
case, however, the marking is provided via a registered port mentioned case, however, the marking is provided via a registered
number instead of relying on a Router Alert option. port number instead of relying on a Router Alert option.
This solution approach would require a deep packet inspection This solution approach would require a deep packet inspection
capability at an entity in the access providers networks that capability at an entity in the access provider's networks that
scans for the occurrence of particular destination port numbers. scans for the occurrence of particular destination port numbers.
Multicast Query: Multicast Query:
An end node could also discover a LIS by sending a DNS query to a A device could also discover an LIS by sending a DNS query to a
well-known address. An example of such a mechanism is multicast well-known address. An example of such a mechanism is multicast
DNS (see [RFC4795] and [I-D.cheshire-dnsext-multicastdns]). DNS (see [RFC4795] and [mDNS]). Unfortunately, these mechanisms
Unfortunately, these mechanisms only work on the local link. only work on the local link.
Anycast: Anycast:
With this solution an anycast address is defined (for IPv4 and With this solution, an anycast address is defined (for IPv4 and
IPv6) in the style of [RFC3068] that allows the endhost to route IPv6) in the style of [RFC3068] that allows the device to route
discovery packets to the nearest LIS. Note that this procedure discovery packets to the nearest LIS. Note that this procedure
would be used purely for discovery and thereby similar to local would be used purely for discovery and is therefore similar to the
Teredo server discovery approach outlined in Section 4.2 of local Teredo server discovery approach outlined in Section 4.2 of
[I-D.nward-v6ops-teredo-server-selection]. [TEREDO-SEL].
The LIS discovery procedure raises deployment and security issues. The LIS discovery procedure raises deployment and security issues.
The access network needs to be designed to prevent man-in-the-middle The access network needs to be designed to prevent man-in-the-middle
adversaries from presenting themselves as a LIS to end hosts. When adversaries from presenting themselves as an LIS to devices. When a
an end host discovers a LIS, it needs to ensure (and be able to device discovers an LIS, it needs to ensure (and be able to ensure)
ensure) that the discovered entity is indeed an authorized LIS. that the discovered entity is indeed an authorized LIS.
5. Identifier for Location Determination 5. Identifier for Location Determination
Note that this section lists mechanisms that were discussed in the Note that this section lists mechanisms that were discussed in the
Geopriv Layer 7 Location Configuration Protocol design team. They GEOPRIV Layer 7 Location Configuration Protocol design team. They
are included to show challenges in the problem space and are are included to show challenges in the problem space and are
listed for completeness reasons. They do not in any way mean that listed for completeness reasons. They do not in any way mean that
there is consensus about any of the mechanisms or that the IETF there is consensus about any of the mechanisms or that the IETF
recommends any of the procedures described in this section. recommends any of the procedures described in this section.
The LIS returns location information to the end host when it receives The LIS returns location information to the device when it receives a
a request. Some form of identifier is therefore needed to allow the request. Some form of identifier is therefore needed to allow the
LIS to retrieve the Target's current location (or a good LIS to retrieve the device's current location, or a good
approximation of it) from a database. approximation, from a database.
The chosen identifier needs to have the following properties: The chosen identifier needs to have the following properties:
Ability for Target to learn or know the identifier: Ability for Device to learn or know the identifier:
The Target MUST know or MUST be able to learn the identifier The device MUST know or MUST be able to learn of the identifier
(explicitly or implicitly) in order to send it to the LIS. (explicitly or implicitly) in order to send it to the LIS.
Implicitly refers to the situation where a device along the path Implicitly refers to the situation where a device along the path
between the end host and the LIS modifies the identifier, as it is between the device and the LIS modifies the identifier, as it is
done by a NAT when an IP address based identifier is used. done by a NAT when an IP address based identifier is used.
Ability to use the identifier for location determination: Ability to use the identifier for location determination:
The LIS MUST be able to use the identifier (directly or The LIS MUST be able to use the identifier (directly or
indirectly) for location determination. Indirectly refers to the indirectly) for location determination. Indirectly refers to the
case where the LIS uses other identifiers internally for location case where the LIS uses other identifiers internally for location
determination, in addition to the one provided by the Target. determination, in addition to the one provided by the device.
Security properties of the identifier: Security properties of the identifier:
Misuse needs to be minimized whereby off-path adversary MUST NOT Misuse needs to be minimized whereby an off-path adversary MUST
be able to obtain location information of other Targets. A on- NOT be able to obtain location information of other devices. An
path adversary in the same subnet SHOULD NOT be able to spoof the on-path adversary in the same subnet SHOULD NOT be able to spoof
identifier of another Target in the same subnet. the identifier of another device in the same subnet.
The following list discusses frequently mentioned identifiers and The following list discusses frequently mentioned identifiers and
their properties: their properties:
Media Access Control (MAC) Address: Media Access Control (MAC) Address:
The Target's MAC address is known to the end host, but not carried The MAC address is known to the device itself, but not carried
over an IP hop and therefore not accessible to the LIS in most beyond a single IP hop and therefore not accessible to the LIS in
deployment environments (unless carried in the L7 LCP itself). most deployment environments (unless carried in the L7 LCP
itself).
Asynchronous Transfer Mode (ATM) Virtual Path Identifier(VPI)/Virtual Asynchronous Transfer Mode (ATM) Virtual Path Identifier / Virtual
Circuit Identifier(VCI): Circuit Identifier (VPI/VCI):
The VCI/VPI is generally only seen by the DSL modem. Almost all The VCI/VPI is generally only seen by the DSL modem. Almost all
routers in the United States use 1 of 2 VPI/VCI value pairs: 0/35 routers in the United States use 1 of 2 VPI/VCI value pairs: 0/35
and 8/35. This VC is terminated at the digital subscriber line and 8/35. This VC is terminated at the digital subscriber line
access multiplexer (DSLAM), which uses a different VPI/VCI (per access multiplexer (DSLAM), which uses a different VPI/VCI (per
end customer) to connect to the ATM switch. Only the network end customer) to connect to the ATM switch. Only the network
provider is able to map VPI/VCI values through its network. With provider is able to map VPI/VCI values through its network. With
the arrival of Very high rate Digital Subscriber Line (VDSL), ATM the arrival of Very high rate Digital Subscriber Line (VDSL), ATM
will slowly be phased out in favor of Ethernet. will slowly be phased out in favor of Ethernet.
Ethernet Switch (Bridge)/Port Number: Ethernet Switch (Bridge)/Port Number:
This identifier is available only in certain networks, such as This identifier is available only in certain networks, such as
enterprise networks, typically available via the IEEE 802.1AB enterprise networks, typically available via the IEEE 802.1AB
protocol [802.1AB] or proprietary protocols like the Cisco protocol [802.1AB] or proprietary protocols like the Cisco
Discovery Protocol (CDP) [CDP]. Discovery Protocol (CDP) [CDP].
Cell ID: Cell ID:
This identifier is available in cellular data networks and the This identifier is available in cellular data networks and the
cell ID may not be visible to the end host. cell ID may not be visible to the device.
Host Identifier: Host Identifier:
The Host Identifier introduced by the Host Identity Protocol (HIP) The Host Identifier introduced by the Host Identity Protocol (HIP)
[I-D.ietf-hip-base] allows identification of a particular host. [RFC5201] allows identification of a particular host.
Unfortunately, the network can only use this identifier for Unfortunately, the network can only use this identifier for
location determination if the operator already stores a mapping of location determination if the operator already stores a mapping of
host identities to location information. Furthermore, there is a host identities to location information. Furthermore, there is a
deployment problem since the host identities are not used in deployment problem since the host identities are not used in
todays networks. today's networks.
Cryptographically Generated Address (CGA): Cryptographically Generated Address (CGA):
The concept of a Cryptographically Generated Address (CGA) was The concept of a Cryptographically Generated Address (CGA) was
introduced by [RFC3972]. The basic idea is to put the truncated introduced by [RFC3972]. The basic idea is to put the truncated
hash of a public key into the interface identifier part of an IPv6 hash of a public key into the interface identifier part of an IPv6
address. In addition to the properties of an IP address it allows address. In addition to the properties of an IP address, it
a proof of ownership. Hence, a return routability check can be allows a proof of ownership. Hence, a return routability check
omitted. It is only available for IPv6 addresses. can be omitted. It is only available for IPv6 addresses.
Network Access Identifiers: Network Access Identifiers:
A Network Access Identifier [RFC4282] is used during the network A Network Access Identifier [RFC4282] is used during the network
access authentication procedure, for example in RADIUS [RFC2865] access authentication procedure, for example, in RADIUS [RFC2865]
and Diameter [RFC3588]. In DSL networks the user credentials are, and Diameter [RFC3588]. In DSL networks, the user credentials
in many cases, only known by the home router and not configured at are, in many cases, only known by the home router and not
the Target itself. To the network, the authenticated user configured at the device itself. To the network, the
identity is only available if a network access authentication authenticated user identity is only available if a network access
procedure is executed. In case of roaming the user's identity authentication procedure is executed. In case of roaming, the
might not be available to the access network since security user's identity might not be available to the access network since
protocols might offer user identity confidentiality and thereby security protocols might offer user identity confidentiality and
hiding the real identity of the user allowing the access network thereby hide the real identity of the user allowing the access
to only see a pseudonym or a randomized string. network to only see a pseudonym or a randomized string.
Unique Client Identifier Unique Client Identifier
The Broadband Forum has defined that all devices that expect to be The Broadband Forum has defined that all devices that expect to be
managed by the TR-069 interface, see [TR069], have to be able to managed by the TR-069 interface, see [TR069], have to be able to
generate an identifier that uniquely identifies the device. It generate an identifier that uniquely identifies the device. It
also has a requirement that routers that use DHCP to the WAN use also has a requirement that routers that use DHCP to the WAN use
RFC 4361 [RFC4361] to provide the DHCP server with a unique client RFC 4361 [RFC4361] to provide the DHCP server with a unique client
identifier. This identifier is, however, not visible to the identifier. This identifier is, however, not visible to the
Target when legacy NTE device are used. device when legacy NTE devices are used.
IP Address: IP Address:
The Target's IP address may be used for location determination. The device's IP address may be used for location determination.
This IP address is not visible to the LIS if the end host is This IP address is not visible to the LIS if the device is behind
behind one or multiple NATs. This may not be a problem since the one or multiple NATs. This may not be a problem since the
location of a host that is located behind a NAT cannot be location of a device that is located behind a NAT cannot be
determined by the access network. The LIS would in this case only determined by the access network. The LIS would in this case only
see the public IP address of the NAT binding allocated by the NAT, see the public IP address of the NAT binding allocated by the NAT,
which is the expected behavior. The property of the IP address which is the expected behavior. The property of the IP address
for a return routability check is attractive to return location for a return routability check is attractive to return location
information only to the address that submitted the request. If an information only to the address that submitted the request. If an
adversary wants to learn the location of a Target (as identified adversary wants to learn the location of a device (as identified
by a particular IP address) then it does not see the response by a particular IP address), then it does not see the response
message (unless he is on the subnetwork or at a router along the message (unless it is on the subnetwork or at a router along the
path towards the LIS). path towards the LIS).
On a shared medium an adversary could ask for location information On a shared medium, an adversary could ask for location
of another Target. The adversary would be able to see the information of another device. The adversary would be able to see
response message since it is sniffing on the shared medium unless the response message since it is sniffing on the shared medium
security mechanisms, such as link layer encryption, are in place. unless security mechanisms, such as link-layer encryption, are in
With a network deployment as shown in Section 3.1 with multiple place. With a network deployment as shown in Section 3.1 with
hosts in the Customer Premises being behind a NAT the LIS is multiple devices in the Customer Premises being behind a NAT, the
unable to differentiate the individual end points. For WLAN LIS is unable to differentiate the individual devices. For WLAN
deployments as found in hotels, as shown in Section 3.3, it is deployments as found in hotels, as shown in Section 3.3, it is
possible for an adversary to eavesdrop data traffic and possible for an adversary to eavesdrop data traffic and
subsequently to spoof the IP address in a query to the LIS to subsequently to spoof the IP address in a query to the LIS to
learn more detailed location information (e.g., specific room learn more detailed location information (e.g., specific room
numbers). Such an attack might, for example, compromise the numbers). Such an attack might, for example, compromise the
privacy of hotel guests. privacy of hotel guests.
6. Requirements 6. Requirements
The following requirements and assumptions have been identified: The following requirements and assumptions have been identified:
Requirement L7-1: Identifier Choice Requirement L7-1: Identifier Choice
The L7 LCP MUST be able to carry different identifiers or MUST The L7 LCP MUST be able to carry different identifiers or MUST
define an identifier that is mandatory to implement. Regarding define an identifier that is mandatory to implement. Regarding
the latter aspect, such an identifier is only appropriate if it is the latter aspect, such an identifier is only appropriate if it is
from the same realm as the one for which the location information from the same realm as the one for which the location information
service maintains identifier to location mapping. service maintains identifier-to-location mapping.
Requirement L7-2: Mobility Support Requirement L7-2: Mobility Support
The L7 LCP MUST support a broad range of mobility from devices The L7 LCP MUST support a broad range of mobility from devices
that can only move between reboots, to devices that can change that can only move between reboots, to devices that can change
attachment points with the impact that their IP address is attachment points with the impact that their IP address is
changed, to devices that do not change their IP address while changed, to devices that do not change their IP address while
roaming, to devices that continuously move by being attached to roaming, to devices that continuously move by being attached to
the same network attachment point. the same network attachment point.
Requirement L7-3: ASP and Access Network Provider Relationship Requirement L7-3: ASP and Access Network Provider Relationship
The design of the L7 LCP MUST NOT assume a business or trust The design of the L7 LCP MUST NOT assume that a business or trust
relationship between the Application Service Provider (ASP) and relationship between the Application Service Provider (ASP) and
the Access Network Provider. Requirements for resolving a the Access Network Provider. Requirements for resolving a
reference to location information are not discussed in this reference to location information are not discussed in this
document. document.
Requirement L7-4: Layer 2 and Layer 3 Provider Relationship Requirement L7-4: Layer 2 and Layer 3 Provider Relationship
The design of the L7 LCP MUST assume that there is a trust and The design of the L7 LCP MUST assume that there is a trust and
business relationship between the L2 and the L3 provider. The L3 business relationship between the L2 and the L3 provider. The L3
provider operates the LIS that the Target queries. It, in turn, provider operates the LIS that the device queries. It, in turn,
needs to obtain location information from the L2 provider since needs to obtain location information from the L2 provider since
this one is closest to the end host. If the L2 and L3 provider this one is closest to the device. If the L2 and L3 provider for
for the same host are different entities, they cooperate for the the same device are different entities, they cooperate for the
purposes needed to determine end system locations. purposes needed to determine locations.
Requirement L7-5: Legacy Device Considerations Requirement L7-5: Legacy Device Considerations
The design of the L7 LCP MUST consider legacy devices, such as The design of the L7 LCP MUST consider legacy devices, such as
residential NAT devices and NTEs in a DSL environment, that cannot residential NAT devices and NTEs in a DSL environment, that cannot
be upgraded to support additional protocols, for example, to pass be upgraded to support additional protocols, for example, to pass
additional information towards the Target. additional information towards the device.
Requirement L7-6: Virtual Private Network (VPN) Awareness Requirement L7-6: Virtual Private Network (VPN) Awareness
The design of the L7 LCP MUST assume that at least one end of a The design of the L7 LCP MUST assume that at least one end of a
VPN is aware of the VPN functionality. In an enterprise scenario, VPN is aware of the VPN functionality. In an enterprise scenario,
the enterprise side will provide the LIS used by the client and the enterprise side will provide the LIS used by the device and
can thereby detect whether the LIS request was initiated through a can thereby detect whether the LIS request was initiated through a
VPN tunnel. VPN tunnel.
Requirement L7-7: Network Access Authentication Requirement L7-7: Network Access Authentication
The design of the L7 LCP MUST NOT assume prior network access The design of the L7 LCP MUST NOT assume that prior network access
authentication. authentication.
Requirement L7-8: Network Topology Unawareness Requirement L7-8: Network Topology Unawareness
The design of the L7 LCP MUST NOT assume end systems being aware The design of the L7 LCP MUST NOT assume that devices are aware of
of the access network topology. End systems are, however, able to the access network topology. Devices are, however, able to
determine their public IP address(es) via mechanisms, such as determine their public IP address(es) via mechanisms, such as
Simple Traversal of User Datagram Protocol (UDP) Through Network Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs) (STUN) [RFC3489] or Next Steps in Address Translators (NATs) (STUN) [RFC5389] or Next Steps in
Signaling (NSIS) NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Signaling (NSIS) NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
[I-D.ietf-nsis-nslp-natfw] . [NSLP].
Requirement L7-9: Discovery Mechanism Requirement L7-9: Discovery Mechanism
The L7 LCP MUST define a mandatory-to-implement LIS discovery The L7 LCP MUST define a mandatory-to-implement LIS discovery
mechanism. mechanism.
Requirement L7-10: PIDF-LO Creation Requirement L7-10: PIDF-LO Creation
When a LIS creates a Presence Information Data Format (PIDF) When an LIS creates a Presence Information Data Format (PIDF)
Location Object (LO) [RFC4119] then it MUST put the <geopriv> Location Object (LO) [RFC4119], then it MUST put the <geopriv>
element into the <device> element of the presence document (see element into the <device> element of the presence document (see
[RFC4479]). This ensures that the resulting PIDF-LO document, [RFC4479]). This ensures that the resulting PIDF-LO document,
which is subsequently distributed to other entities, conforms to which is subsequently distributed to other entities, conforms to
the rules outlined in [I-D.ietf-geopriv-pdif-lo-profile]. the rules outlined in [RFC5491].
7. Security Considerations 7. Security Considerations
By using a Geolocation L7 Location Configuration Protocol, the client By using a Geolocation L7 Location Configuration Protocol, the device
expose themselves to a privacy risk whereby an unauthorized entity (and a human user of such a device, if applicable) exposes themselves
receives location information. The provision of confidentiality to a privacy risk whereby an unauthorized entity receives location
protected location to the requestor depends on the success of four information. Providing confidentiality protected location to the
steps: requestor depends on the success of four steps:
1. The client MUST have a means to discover a LIS. 1. The client MUST have a means to discover a LIS.
2. The client MUST authenticate the discovered LIS. 2. The client MUST authenticate the discovered LIS.
3. The LIS MUST be able to determine location and return it to the 3. The LIS MUST be able to determine location and return it to the
authorized entity. authorized entity.
4. The LIS MUST securely exchange messages without intermedaries 4. The LIS MUST securely exchange messages without intermediaries
eavesdropping or tampering them. eavesdropping or tampering with them.
This document contains various security related requirements This document contains various security-related requirements
throughout the document addressing the above-mentioned steps. For a throughout the document addressing the above-mentioned steps. For a
broader security discussion of the overall geolocation privacy broader security discussion of the overall geolocation privacy
architecture the reader is referred to [I-D.barnes-geopriv-lo-sec]. architecture, the reader is referred to [GEOPRIV-ARCH].
8. IANA Considerations
This document does not require actions by IANA.
9. Contributors 8. Contributors
This contribution is a joint effort of the Geopriv Layer 7 Location This contribution is a joint effort of the GEOPRIV Layer 7 Location
Configuration Requirements Design Team of the IETF GEOPRIV Working Configuration Requirements Design Team of the IETF GEOPRIV Working
Group. The contributors include Henning Schulzrinne, Barbara Stark, Group. The contributors include Henning Schulzrinne, Barbara Stark,
Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson,
Rohan Mahy, Brian Rosen, Jon Peterson and Hannes Tschofenig. Rohan Mahy, Brian Rosen, Jon Peterson, and Hannes Tschofenig.
We would like to thank the GEOPRIV working group chairs, Andy Newton, We would like to thank the GEOPRIV Working Group Chairs, Andy Newton,
Randy Gellens and Allison Mankin, for creating the design team. Randy Gellens, and Allison Mankin, for creating the design team.
Furthermore, we would like thank Andy Newton for his support during Furthermore, we would like thank Andy Newton for his support during
the design team mailing list, for setting up Jabber chat conferences the design team mailing list, for setting up Jabber chat conferences,
and for participating in the phone conference discussions. and for participating in the phone conference discussions.
The design team members can be reached at: The design team members can be reached at:
Marc Linsner: mlinsner@cisco.com Marc Linsner: mlinsner@cisco.com
Rohan Mahy: rohan@ekabal.com Rohan Mahy: rohan@ekabal.com
Andrew Newton: andy@hxr.us Andrew Newton: andy@hxr.us
skipping to change at page 22, line 5 skipping to change at page 18, line 5
Henning Schulzrinne: hgs@cs.columbia.edu Henning Schulzrinne: hgs@cs.columbia.edu
Barbara Stark: Barbara.Stark@bellsouth.com Barbara Stark: Barbara.Stark@bellsouth.com
Martin Thomson: Martin.Thomson@andrew.com Martin Thomson: Martin.Thomson@andrew.com
Hannes Tschofenig: Hannes.Tschofenig@nsn.com Hannes Tschofenig: Hannes.Tschofenig@nsn.com
James Winterbottom: James.Winterbottom@andrew.com James Winterbottom: James.Winterbottom@andrew.com
10. Acknowledgements 9. Acknowledgements
We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin
Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl,
Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard,
Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara
Stark, Michael Haberler, and Mary Barnes for their WGLC review Stark, Michael Haberler, and Mary Barnes for their WGLC review
comments. comments.
The authors would like to thank NENA for their work on [NENA] as it The authors would like to thank NENA for their work on [NENA] as it
helped to provide some of the initial thinking. helped to provide some of the initial thinking.
The authors would also like to thank Cullen Jennings for his feedback The authors would also like to thank Cullen Jennings for his feedback
as part of the IESG processing. Additionally, we would like to thank as part of the IESG processing. Additionally, we would like to thank
Alexey Melnikov, Dan Romascanu, Alexey Melnikov, Dan Romascanu, and Robert Sparks.
11. References
11.1. Normative References 10. References
[I-D.ietf-ecrit-requirements] 10.1. Normative References
Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress),
March 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. Emergency Context Resolution with Internet
Technologies", RFC 5012, January 2008.
11.2. Informative References 10.2. Informative References
[802.1AB] "IEEE 802.1AB-2005 IEEE Standard for Local and [802.1AB] "IEEE 802.1AB-2005 IEEE Standard for Local and
Metropolitan Area Networks Station and Media Access Metropolitan Area Networks Station and Media Access
Control Connectivity Discovery", (PDF document), http:// Control Connectivity Discovery", May 2005, <http://
standards.ieee.org/getieee802/download/802.1AB-2005.pdf, standards.ieee.org/getieee802/download/
May 2005. 802.1AB-2005.pdf>.
[CDP] "Cisco Discovery Protocol (CDP)", (HTML page), http:// [CDP] Wikipedia, "Cisco Discovery Protocol (CDP)", <http://
en.wikipedia.org/wiki/Cisco_Discovery_Protocol, July 2009. en.wikipedia.org/wiki/Cisco_Discovery_Protocol>.
[I-D.barnes-geopriv-lo-sec] [GEOPRIV-ARCH] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture
Tschofenig, H., and H. Schulzrinne, "An Architecture for for Location and Location Privacy in Internet
Location and Location Privacy in Internet Applications", Applications", Work in Progress, October 2009.
draft-barnes-geopriv-lo-sec-05 (work in progress),
March 2009.
[I-D.cheshire-dnsext-multicastdns] [LBYR-REQS] Marshall, R., Ed., "Requirements for a Location-by-
Cheshire, S. and M. Krochmal, "Multicast DNS", Reference Mechanism", Work in Progress,
draft-cheshire-dnsext-multicastdns-07 (work in progress), November 2009.
September 2008.
[I-D.ietf-geopriv-lbyr-requirements] [LIS-DISC] Thomson, M. and J. Winterbottom, "Discovering the
Marshall, R., "Requirements for a Location-by-Reference Local Location Information Server (LIS)", Work
Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work in Progress, February 2010.
in progress), February 2009.
[I-D.ietf-geopriv-pdif-lo-profile] [LIS2LIS] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Requirements", Work in Progress, November 2007.
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), November 2008.
[I-D.ietf-hip-base] [NENA] "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA
Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, Recommended Method(s) for Location Determination to
"Host Identity Protocol", draft-ietf-hip-base-10 (work in Support IP-Based Emergency Services - Technical
progress), October 2007. Information Document (TID)", December 2006, <http://
www.nena.org/sites/default/files/
08-505_20061221.pdf>.
[I-D.ietf-nsis-nslp-natfw] [NSLP] Stiemerling, M., Tschofenig, H., Aoun, C., and E.
Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, Davies, "NAT/Firewall NSIS Signaling Layer Protocol
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", (NSLP)", Work in Progress, February 2010.
draft-ietf-nsis-nslp-natfw-20 (work in progress),
November 2008.
[I-D.nward-v6ops-teredo-server-selection] [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
Ward, N., "Teredo Server Selection", February 1997.
draft-nward-v6ops-teredo-server-selection-00 (work in
progress), July 2007.
[I-D.thomson-geopriv-lis-discovery] [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
Thomson, M. and J. Winterbottom, "Discovering the Local "Remote Authentication Dial In User Service
Location Information Server (LIS)", (RADIUS)", RFC 2865, June 2000.
draft-thomson-geopriv-lis-discovery-03 (work in progress),
September 2007.
[I-D.winterbottom-geopriv-lis2lis-req] [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay
Winterbottom, J. and S. Norreys, "LIS to LIS Protocol Routers", RFC 3068, June 2001.
Requirements", draft-winterbottom-geopriv-lis2lis-req-01
(work in progress), November 2007.
[NENA] "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
Recommended Method(s) for Location Determination to J. Arkko, "Diameter Base Protocol", RFC 3588,
Support IP-Based Emergency Services - Technical September 2003.
Information Document (TID)", (PDF document), NENA 08-505,
December 2006.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, [RFC3972] Aura, T., "Cryptographically Generated Addresses
February 1997. (CGA)", RFC 3972, March 2005.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location
"Remote Authentication Dial In User Service (RADIUS)", Object Format", RFC 4119, December 2005.
RFC 2865, June 2000.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen,
RFC 3068, June 2001. "The Network Access Identifier", RFC 4282,
December 2005.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
"STUN - Simple Traversal of User Datagram Protocol (UDP) Identifiers for Dynamic Host Configuration Protocol
Through Network Address Translators (NATs)", RFC 3489, Version Four (DHCPv4)", RFC 4361, February 2006.
March 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. July 2006.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
RFC 3972, March 2005. Multicast Name Resolution (LLMNR)", RFC 4795,
January 2007.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T.
Format", RFC 4119, December 2005. Henderson, "Host Identity Protocol", RFC 5201,
April 2008.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
Network Access Identifier", RFC 4282, December 2005. "Session Traversal Utilities for NAT (STUN)",
RFC 5389, October 2008.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig,
Identifiers for Dynamic Host Configuration Protocol "GEOPRIV Presence Information Data Format Location
Version Four (DHCPv4)", RFC 4361, February 2006. Object (PIDF-LO) Usage Clarification, Considerations,
and Recommendations", RFC 5491, March 2009.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, [TEREDO-SEL] Ward, N., "Teredo Server Selection", Work
July 2006. in Progress, July 2007.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local [TR069] "TR-069, CPE WAN Management Protocol v1.1, Version:
Multicast Name Resolution (LLMNR)", RFC 4795, Issue 1 Amendment 2", December 2007, <http://
January 2007. www.broadband-forum.org/technical/download/
TR-069_Amendment-2.pdf>.
[TR069] "TR-069, CPE WAN Management Protocol v1.1, Version: Issue [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work
1 Amendment 2", (PDF document), http:// in Progress, September 2009.
www.broadband-forum.org/technical/download/
TR-069Amendment2.pdf, December 2007.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
 End of changes. 143 change blocks. 
377 lines changed or deleted 347 lines changed or added

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