--- 1/draft-ietf-geopriv-l7-lcp-ps-09.txt 2009-07-13 20:12:25.000000000 +0200 +++ 2/draft-ietf-geopriv-l7-lcp-ps-10.txt 2009-07-13 20:12:25.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group H. Tschofenig Internet-Draft Nokia Siemens Networks Intended status: Informational H. Schulzrinne -Expires: August 25, 2009 Columbia University - February 21, 2009 +Expires: January 14, 2010 Columbia University + July 13, 2009 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements - draft-ietf-geopriv-l7-lcp-ps-09.txt + draft-ietf-geopriv-l7-lcp-ps-10.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -23,126 +23,128 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 25, 2009. + This Internet-Draft will expire on January 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Abstract This document provides a problem statement, lists requirements and 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Fixed Wired Environment . . . . . . . . . . . . . . . . . 5 - 3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Moving Network . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Wireless Access . . . . . . . . . . . . . . . . . . . . . 9 4. Discovery of the Location Information Server . . . . . . . . . 11 5. Identifier for Location Determination . . . . . . . . . . . . 13 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction This document provides a problem statement, lists requirements and captures design aspects for a Geopriv Layer 7 Location Configuration Protocol L7 (LCP). The protocol has two purposes: o It is used to obtain location information (referred as "Location by Value" or LbyV) from a dedicated node, called the Location Information Server (LIS). o It enables the Target to obtain a reference to location information (referred as "Location by Reference" or LbyR). This reference can take the form of a subscription URI, such as a SIP - presence URI, a HTTP/HTTPS URI, or another URI. The requirements - related to the task of obtaining a LbyR are described in a - separate document, see [4]. + presence based Uniform Resource Identifier (URI), a HTTP/HTTPS + URI, or another URI. The requirements related to the task of + obtaining a LbyR are described in a separate document, see + [I-D.ietf-geopriv-lbyr-requirements]. The need for these two functions can be derived from the scenarios presented in Section 3. For this document we assume that the Geopriv Layer 7 LCP runs between - the end host (i.e., the Target in [1] terminology) and the LIS. + the end host (i.e., the Target in [RFC3693] terminology) and the LIS. This document is structured as follows. Section 4 discusses the challenge of discovering the LIS in the access network. Section 5 compares different types of identifiers that can be used to retrieve location information. A list of requirements for the L7 LCP can be found in Section 6. This document does not describe how the access network provider determines the location of the end host since this is largely a matter of the capabilities of specific link layer technologies or certain deployment environments. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" are to be interpreted as described in RFC 2119 [2], - with the qualification that unless otherwise stated these words apply - to the design of the Geopriv Layer 7 Location Configuration Protocol. + and "OPTIONAL" are to be interpreted as described in RFC 2119 + [RFC2119], with the qualification that unless otherwise stated these + words apply to the design of the Geopriv Layer 7 Location + Configuration Protocol. The term Location Information Server (LIS) refers to an entity capable of determining the location of a Target and of providing that location information, a reference to it, or both via the Location Configuration Protocol (LCP) to the requesting party. In most cases 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 [1] (such as Target) and [3] - (such as Internet Access Provider (IAP), Internet Service Provider - (ISP), and Application Service Provider (ASP)). + This document also uses terminology from [RFC3693] (such as Target) + and [I-D.ietf-ecrit-requirements] (such as Internet Access Provider + (IAP), Internet Service Provider (ISP), and Application Service + Provider (ASP)). With the term "Access Network Provider" we refer to the Internet Access Provider (IAP) and the Internet Service Provider (ISP) without further distinguishing these two entities as it is not relevant for the purpose of this document. An additional requirements document on - LIS-to-LIS [5] shows scenario where the separation between IAP and - ISP is important. + LIS-to-LIS [I-D.winterbottom-geopriv-lis2lis-req] shows scenario + where the separation between IAP and ISP is important. 3. Scenarios This section describes a few network scenarios where the L7 LCP may be used. Note that this section does not aim to exhaustively list all possible deployment environments. Instead we focus on the following environments: o DSL/Cable networks, WiMax-like fixed access @@ -150,24 +152,24 @@ 802.16e/Wimax o 3G networks o Enterprise networks We illustrate a few examples below. 3.1. Fixed Wired Environment - Figure 1 shows a DSL network scenario with the Access Network - Provider and the customer premises. The Access Network Provider - operates link and network layer devices (represented as Node) and the - LIS. + Figure 1 shows a Digital subscriber line (DSL) network scenario with + the Access Network Provider and the customer premises. The Access + Network Provider operates link and network layer devices (represented + as Node) and the LIS. +---------------------------+ | | | Access Network Provider | | | | +--------+ | | | Node | | | +--------+ +----------+ | | | | | LIS | | | | +---| | | @@ -217,25 +219,29 @@ 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 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. Current Customer Premises Network (CPN) deployments generally fall into one of the following classifications: 1. Single PC - 1. with Ethernet NIC (PPPoE or DHCP on PC); there may be a - bridged DSL or cable modem as NTE, or the Ethernet NIC might - be the NTE + 1. with Ethernet network interface card (NIC) with Point-to- + Point Protocol Over Ethernet (PPPoE) or Dynamic Host + Configuration Protocol (DHCP) on PC; there may be a bridged + DSL or cable modem as NTE, or the Ethernet NIC might be the + NTE - 2. with USB DSL or cable modem [PPPoA, PPPoE, or DHCP on PC] + 2. with Universal Serial Bus (USB) based DSL access or a cable + modem access using Point-to-Point Protocol over ATM (PPPoA), + PPPoE, or DHCP on PC Note that the device with NAPT and DHCP of Figure 1 is not present in such a scenario. 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 VoIP device, or Analog Terminal Adaptor (ATA) function embedded in router) 1. combined router and NTE @@ -339,107 +345,109 @@ | +------+ | End | | Host | +------+ Figure 3: Wireless Access Scenario 4. Discovery of the Location Information Server - Note that this section lists mechanisms that were discussed as - part of the work on the Geopriv Layer 7 Location Configuration - Protocol design team. They are included to show challenges in the - problem space and are listed for completeness reasons. They do - not in any way mean that their is consensus that any of these - approaches are good or bad or that the IETF is in any recommended - in this document that any of these be used. + Note that this section lists mechanisms that were discussed in the + Geopriv Layer 7 Location Configuration Protocol design team. They + are included to show challenges in the problem space and are + listed for completeness reasons. They do not in any way mean that + there is consensus about any of the mechanisms or that the IETF + recommends any of the procedures described in this section. When a Target wants to retrieve location information from the LIS it first needs to discover it. Based on the problem statement of determining the location of the Target, which is known best by entities close to the Target itself, we assume that the LIS is located in the local subnet or in access network. Several procedures have been investigated that aim to discover the LIS in such an access network. DHCP-based Discovery: In some environments the Dynamic Host Configuration Protocol - (DHCP) might be a good choice for discovering the FQDN or the IP - address of the LIS. In environments where DHCP can be used it is - also possible to use the already defined location extensions. In - environments with legacy devices, such as the one shown in - Section 3.1, a DHCP based discovery solution may not be possible. + (DHCP) might be a good choice for discovering the fully qualified + 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 + defined location extensions. In environments with legacy devices, + such as the one shown in Section 3.1, a DHCP based discovery + solution may not be possible. DNS-based Discovery: - Before a DNS lookup can be started it is necessary to learn the - domain name of the access network that runs a LIS. Several ways - to learn the domain name exist. For example, the end host obtains - its own public IP address, for example via STUN [6], and performs - a reverse DNS lookup (assuming the data is provisioned into the - DNS). Then, the SRV or NAPTR record for that domain is retrieved. - A more detailed description of this approach can be found in [7]. + Before a Domain Name System (DNS) lookup can be started it is + necessary to learn the domain name of the access network that runs + a LIS. Several ways to learn the domain name exist. For example, + the end host obtains its own public IP address, for example via + STUN [RFC3489], and performs a reverse DNS lookup (assuming the + data is provisioned into the DNS). Then, the DNS Service (SRV) + record or the DNS Naming Authority Pointer (NAPTR) record for that + domain is retrieved. A more detailed description of this approach + can be found in [I-D.thomson-geopriv-lis-discovery]. Redirect Rule: A redirect rule at a device in the access network could be used to redirect the L7 LCP signalling messages (destined to a specific port) to the LIS. The end host could then discover the LIS by sending a packet with a specific (registered) port number to almost any address (as long as the destination IP address does not target a device in the local network). The packet would be redirected to the respective LIS being configured. The same procedure is used by captive portals whereby any HTTP traffic is intercepted and redirected. To some extend this approach is similar to packets that are marked - with a Router Alert option [8] and intercepted by entities that - understand the specific marking. In the above-mentioned case, - however, the marking is provided via a registered port number - instead of relying on a Router Alert option. + with a Router Alert option [RFC2113] and intercepted by entities + that understand the specific marking. In the above-mentioned + case, however, the marking is provided via a registered port + number instead of relying on a Router Alert option. This solution approach would require a deep packet inspection capability at an entity in the access providers networks that scans for the occurrence of particular destination port numbers. Multicast Query: An end node could also discover a LIS by sending a DNS query to a well-known address. An example of such a mechanism is multicast - DNS (see [9] and [10]). Unfortunately, these mechanisms only work - on the local link. + DNS (see [RFC4795] and [I-D.cheshire-dnsext-multicastdns]). + Unfortunately, these mechanisms only work on the local link. Anycast: With this solution an anycast address is defined (for IPv4 and - IPv6) in the style of [11] that allows the endhost to route + IPv6) in the style of [RFC3068] that allows the endhost to route discovery packets to the nearest LIS. Note that this procedure would be used purely for discovery and thereby similar to local - Teredo server discovery approach outlined in Section 4.2 of [12]. + Teredo server discovery approach outlined in Section 4.2 of + [I-D.nward-v6ops-teredo-server-selection]. The LIS discovery procedure raises deployment and security issues. The access network needs to be designed to prevent man-in-the-middle adversaries from presenting themselves as a LIS to end hosts. When an end host discovers a LIS, it needs to ensure (and be able to ensure) that the discovered entity is indeed an authorized LIS. 5. Identifier for Location Determination - Note that this section lists mechanisms that were discussed as - part of the work in the Geopriv Layer 7 Location Configuration - Protocol design team. They are included to show challenges in the - problem space and are listed for completeness reasons. They do - not in any way mean that their is consensus that any of these - approaches are good or bad or that the IETF is in any recommended - in this document that any of these be used. + Note that this section lists mechanisms that were discussed in the + Geopriv Layer 7 Location Configuration Protocol design team. They + are included to show challenges in the problem space and are + listed for completeness reasons. They do not in any way mean that + there is consensus about any of the mechanisms or that the IETF + recommends any of the procedures described in this section. The LIS returns location information to the end host when it receives a request. Some form of identifier is therefore needed to allow the LIS to retrieve the Target's current location (or a good approximation of it) from a database. The chosen identifier needs to have the following properties: Ability for Target to learn or know the identifier: @@ -459,86 +467,90 @@ Security properties of the identifier: Misuse needs to be minimized whereby off-path adversary MUST NOT be able to obtain location information of other Targets. A on- path adversary in the same subnet SHOULD NOT be able to spoof the identifier of another Target in the same subnet. The following list discusses frequently mentioned identifiers and their properties: - Host MAC Address: + Media Access Control (MAC) Address: The Target's MAC address is known to the end host, but not carried over an IP hop and therefore not accessible to the LIS in most deployment environments (unless carried in the L7 LCP itself). - ATM VCI/VPI: + Asynchronous Transfer Mode (ATM) Virtual Path Identifier(VPI)/Virtual + Circuit Identifier(VCI): - The VPI/VCI is generally only seen by the DSL modem. Almost all - routers in the US use 1 of 2 VPI/VCI value pairs: 0/35 and 8/35. - This VC is terminated at the DSLAM, which uses a different VPI/VCI - (per end customer) to connect to the ATM switch. Only the network + 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 + and 8/35. This VC is terminated at the digital subscriber line + access multiplexer (DSLAM), which uses a different VPI/VCI (per + end customer) to connect to the ATM switch. Only the network provider is able to map VPI/VCI values through its network. With - the arrival of VDSL, ATM will slowly be phased out in favor of - Ethernet. + the arrival of Very high rate Digital Subscriber Line (VDSL), ATM + will slowly be phased out in favor of Ethernet. - Switch/Port Number: + Ethernet Switch (Bridge)/Port Number: This identifier is available only in certain networks, such as - enterprise networks, typically available via proprietary protocols - like CDP or, in the future, 802.1ab. + enterprise networks, typically available via the IEEE 802.1AB + protocol [802.1AB] or proprietary protocols like the Cisco + Discovery Protocol (CDP) [CDP]. Cell ID: This identifier is available in cellular data networks and the cell ID may not be visible to the end host. Host Identifier: - The Host Identifier introduced by the Host Identity Protocol [13] - allows identification of a particular host. Unfortunately, the - network can only use this identifier for location determination if - the operator already stores a mapping of host identities to - location information. Furthermore, there is a deployment problem - since the host identities are not used in todays networks. + The Host Identifier introduced by the Host Identity Protocol (HIP) + [I-D.ietf-hip-base] allows identification of a particular host. + Unfortunately, the network can only use this identifier for + location determination if the operator already stores a mapping of + host identities to location information. Furthermore, there is a + deployment problem since the host identities are not used in + todays networks. Cryptographically Generated Address (CGA): The concept of a Cryptographically Generated Address (CGA) was - introduced by [14]. The basic idea is to put the truncated hash - of a public key into the interface identifier part of an IPv6 + introduced by [RFC3972]. The basic idea is to put the truncated + 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 a proof of ownership. Hence, a return routability check can be omitted. It is only available for IPv6 addresses. Network Access Identifiers: - A Network Access Identifier [15] is used during the network access - authentication procedure, for example in RADIUS [16] and Diameter - [17]. In DSL networks the user credentials are, in many cases, - only known by the home router and not configured at the Target - itself. To the network, the authenticated user identity is only - available if a network access authentication procedure is - executed. In case of roaming the user's identity might not be - available to the access network since security protocols might - offer user identity confidentiality and thereby hiding the real - identity of the user allowing the access network to only see a - pseudonym or a randomized string. + A Network Access Identifier [RFC4282] is used during the network + access authentication procedure, for example in RADIUS [RFC2865] + and Diameter [RFC3588]. In DSL networks the user credentials are, + in many cases, only known by the home router and not configured at + the Target itself. To the network, the authenticated user + identity is only available if a network access authentication + procedure is executed. In case of roaming the user's identity + might not be available to the access network since security + protocols might offer user identity confidentiality and thereby + hiding the real identity of the user allowing the access network + to only see a pseudonym or a randomized string. Unique Client Identifier - The DSL Forum has defined that all devices that expect to be - managed by the TR-069 interface be able to generate an identifier - as described in Section 3.4.4 of the TR-069v2 DSL Forum document. - It also has a requirement that routers that use DHCP to the WAN - use RFC 4361 [18] to provide the DHCP server with a unique client + 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 + generate an identifier that uniquely identifies the device. It + 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 identifier. This identifier is, however, not visible to the Target when legacy NTE device are used. IP Address: The Target's IP address may be used for location determination. This IP address is not visible to the LIS if the end host is behind one or multiple NATs. This may not be a problem since the location of a host that is located behind a NAT cannot be determined by the access network. The LIS would in this case only @@ -604,75 +616,79 @@ for the same host are different entities, they cooperate for the purposes needed to determine end system locations. Requirement L7-5: Legacy Device Considerations The design of the L7 LCP MUST consider legacy devices, such as residential NAT devices and NTEs in a DSL environment, that cannot be upgraded to support additional protocols, for example, to pass additional information towards the Target. - Requirement L7-6: 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 VPN is aware of the VPN functionality. In an enterprise scenario, the enterprise side will provide the LIS used by the client and can thereby detect whether the LIS request was initiated through a VPN tunnel. Requirement L7-7: Network Access Authentication The design of the L7 LCP MUST NOT assume prior network access authentication. Requirement L7-8: Network Topology Unawareness The design of the L7 LCP MUST NOT assume end systems being aware of the access network topology. End systems are, however, able to - determine their public IP address(es) via mechanisms, such as STUN - [6] or NSIS NATFW NSLP [19] . + determine their public IP address(es) via mechanisms, such as + Simple Traversal of User Datagram Protocol (UDP) Through Network + Address Translators (NATs) (STUN) [RFC3489] or Next Steps in + Signaling (NSIS) NAT/Firewall NSIS Signaling Layer Protocol (NSLP) + [I-D.ietf-nsis-nslp-natfw] . Requirement L7-9: Discovery Mechanism The L7 LCP MUST define a mandatory-to-implement LIS discovery mechanism. Requirement L7-10: PIDF-LO Creation - When a LIS creates a PIDF-LO [20] then it MUST put the + When a LIS creates a Presence Information Data Format (PIDF) + Location Object (LO) [RFC4119] then it MUST put the element into the element of the presence document (see - [21]). This ensures that the resulting PIDF-LO document, which is - subsequently distributed to other entities, conforms to the rules - outlined in [22]. + [RFC4479]). This ensures that the resulting PIDF-LO document, + which is subsequently distributed to other entities, conforms to + the rules outlined in [I-D.ietf-geopriv-pdif-lo-profile]. 7. Security Considerations By using a Geolocation L7 Location Configuration Protocol, the client expose themselves to a privacy risk whereby an unauthorized entity receives location information. The provision of confidentiality protected location to the 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. - 4. The LIS must securely exchange messages without intermedaries + 4. The LIS MUST securely exchange messages without intermedaries eavesdropping or tampering them. This document contains various security related requirements throughout the document addressing the above-mentioned steps. For a broader security discussion of the overall geolocation privacy - architecture the reader is referred to [23]. + architecture the reader is referred to [I-D.barnes-geopriv-lo-sec]. 8. IANA Considerations This document does not require actions by IANA. 9. Contributors This contribution is a joint effort of the Geopriv Layer 7 Location Configuration Requirements Design Team of the IETF GEOPRIV Working Group. The contributors include Henning Schulzrinne, Barbara Stark, @@ -709,122 +725,152 @@ 10. Acknowledgements We would also like to thank Murugaraj Shanmugam, Ted Hardie, Martin Dawson, Richard Barnes, James Winterbottom, Tom Taylor, Otmar Lendl, Marc Linsner, Brian Rosen, Roger Marshall, Guy Caron, Doug Stuard, Eric Arolick, Dan Romascanu, Jerome Grenier, Martin Thomson, Barbara Stark, Michael Haberler, and Mary Barnes for their WGLC review comments. - The authors would like to thank NENA for their work on [24] as it + The authors would like to thank NENA for their work on [NENA] as it helped to provide some of the initial thinking. The authors would also like to thank Cullen Jennings for his feedback - as part of the IESG processing. + as part of the IESG processing. Additionally, we would like to thank + Alexey Melnikov, Dan Romascanu, 11. References 11.1. Normative References - [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. - Polk, "Geopriv Requirements", RFC 3693, February 2004. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, BCP 14, March 1997. - - [3] Schulzrinne, H. and R. Marshall, "Requirements for Emergency - Context Resolution with Internet Technologies", + [I-D.ietf-ecrit-requirements] + Schulzrinne, H. and R. Marshall, "Requirements for + Emergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-13 (work in progress), March 2007. -11.2. Informative References - - [4] Marshall, R., "Requirements for a Location-by-Reference - Mechanism", draft-ietf-geopriv-lbyr-requirements-05 (work in - progress), November 2008. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. - [5] Winterbottom, J. and S. Norreys, "LIS to LIS Protocol - Requirements", draft-winterbottom-geopriv-lis2lis-req-01 (work - in progress), November 2007. + [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and + J. Polk, "Geopriv Requirements", RFC 3693, February 2004. - [6] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - - Simple Traversal of User Datagram Protocol (UDP) Through - Network Address Translators (NATs)", RFC 3489, March 2003. +11.2. Informative References - [7] Thomson, M. and J. Winterbottom, "Discovering the Local - Location Information Server (LIS)", - draft-thomson-geopriv-lis-discovery-03 (work in progress), - September 2007. + [802.1AB] "IEEE 802.1AB-2005 IEEE Standard for Local and + Metropolitan Area Networks Station and Media Access + Control Connectivity Discovery", (PDF document), http:// + standards.ieee.org/getieee802/download/802.1AB-2005.pdf, + May 2005. - [8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. + [CDP] "Cisco Discovery Protocol (CDP)", (HTML page), http:// + en.wikipedia.org/wiki/Cisco_Discovery_Protocol, July 2009. - [9] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast - Name Resolution (LLMNR)", RFC 4795, January 2007. + [I-D.barnes-geopriv-lo-sec] + Barnes, R., Lepinski, M., Cooper, A., Morris, J., + Tschofenig, H., and H. Schulzrinne, "An Architecture for + Location and Location Privacy in Internet Applications", + draft-barnes-geopriv-lo-sec-05 (work in progress), + March 2009. - [10] Cheshire, S. and M. Krochmal, "Multicast DNS", + [I-D.cheshire-dnsext-multicastdns] + Cheshire, S. and M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-07 (work in progress), September 2008. - [11] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", - RFC 3068, June 2001. + [I-D.ietf-geopriv-lbyr-requirements] + Marshall, R., "Requirements for a Location-by-Reference + Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work + in progress), February 2009. - [12] Ward, N., "Teredo Server Selection", - draft-nward-v6ops-teredo-server-selection-00 (work in - progress), July 2007. + [I-D.ietf-geopriv-pdif-lo-profile] + Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV + PIDF-LO Usage Clarification, Considerations and + Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 + (work in progress), November 2008. - [13] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, + [I-D.ietf-hip-base] + Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", draft-ietf-hip-base-10 (work in progress), October 2007. - [14] Aura, T., "Cryptographically Generated Addresses (CGA)", - RFC 3972, March 2005. + [I-D.ietf-nsis-nslp-natfw] + Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, + "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", + draft-ietf-nsis-nslp-natfw-20 (work in progress), + November 2008. - [15] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network - Access Identifier", RFC 4282, December 2005. + [I-D.nward-v6ops-teredo-server-selection] + Ward, N., "Teredo Server Selection", + draft-nward-v6ops-teredo-server-selection-00 (work in + progress), July 2007. - [16] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote - Authentication Dial In User Service (RADIUS)", RFC 2865, - June 2000. + [I-D.thomson-geopriv-lis-discovery] + Thomson, M. and J. Winterbottom, "Discovering the Local + Location Information Server (LIS)", + draft-thomson-geopriv-lis-discovery-03 (work in progress), + September 2007. - [17] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, - "Diameter Base Protocol", RFC 3588, September 2003. + [I-D.winterbottom-geopriv-lis2lis-req] + Winterbottom, J. and S. Norreys, "LIS to LIS Protocol + Requirements", draft-winterbottom-geopriv-lis2lis-req-01 + (work in progress), November 2007. - [18] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers - for Dynamic Host Configuration Protocol Version Four (DHCPv4)", - RFC 4361, February 2006. + [NENA] "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA + Recommended Method(s) for Location Determination to + Support IP-Based Emergency Services - Technical + Information Document (TID)", (PDF document), NENA 08-505, + December 2006. - [19] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/ - Firewall NSIS Signaling Layer Protocol (NSLP)", - draft-ietf-nsis-nslp-natfw-20 (work in progress), - November 2008. + [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, + February 1997. - [20] Peterson, J., "A Presence-based GEOPRIV Location Object + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", + RFC 3068, June 2001. + + [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, + "STUN - Simple Traversal of User Datagram Protocol (UDP) + Through Network Address Translators (NATs)", RFC 3489, + March 2003. + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. + Arkko, "Diameter Base Protocol", RFC 3588, September 2003. + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, March 2005. + + [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. - [21] Rosenberg, J., "A Data Model for Presence", RFC 4479, - July 2006. + [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The + Network Access Identifier", RFC 4282, December 2005. - [22] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV - PIDF-LO Usage Clarification, Considerations and - Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 (work - in progress), November 2008. + [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client + Identifiers for Dynamic Host Configuration Protocol + Version Four (DHCPv4)", RFC 4361, February 2006. - [23] Barnes, R., Lepinski, M., Tschofenig, H., and H. Schulzrinne, - "Additional Location Privacy Considerations", - draft-barnes-geopriv-lo-sec-04 (work in progress), - January 2009. + [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, + July 2006. - [24] "NENA 08-505, Issue 1, 2006 (December 21, 2006), NENA - Recommended Method(s) for Location Determination to Support IP- - Based Emergency Services - Technical Information Document - (TID)", PDF NENA 08-505, December 2006. + [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local + Multicast Name Resolution (LLMNR)", RFC 4795, + January 2007. + + [TR069] "TR-069, CPE WAN Management Protocol v1.1, Version: Issue + 1 Amendment 2", (PDF document), http:// + www.broadband-forum.org/technical/download/ + TR-069Amendment2.pdf, December 2007. Authors' Addresses Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445