RFC 5687

GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements

📅 published March 2010, from ietf

RFC 5687: GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements 💖

Okay bestie, this one is the problem statement and requirements doc for a GEOPRIV Layer 7 (L7) Location Configuration Protocol (LCP). It was written by H. Tschofenig from Nokia Siemens Networks and H. Schulzrinne from Columbia University, and it was published in March 2010 as an Informational document (ISSN 2070-1721) 🎀. The header doesn't list anything it obsoletes or updates.

Abstract ✨

Okay so this doc does three things: it lays out the problem, lists the requirements, and captures the design aspects for a GEOPRIV Layer 7 (L7) Location Configuration Protocol (LCP) 🧚. The big idea is that an end host can grab location info, either by value or by reference, from a Location Information Server (LIS) sitting in the access network 📍. Then that location can be reused everywhere. You can feed it into the Location-to-Service Translation (LoST) Protocol, or send it around inside the Session Initiation Protocol (SIP) so other entities know where you are 🦋.

Status of This Memo 🌸

Not a Standards Track spec, just published for info purposes 💅. It's still a real IETF product that has consensus from the IETF community, got public review, and was approved by the Internet Engineering Steering Group (IESG). But being approved doesn't automatically make a doc a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🙈.

For the current status, errata, or how to send feedback, head to http://www.rfc-editor.org/info/rfc5687 🌈.

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Read them carefully, because they spell out your rights and restrictions for this doc 📜. Code Components pulled out of this doc must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🫶.

Table of Contents 🍓

1. Introduction ....................................................3
2. Terminology .....................................................3
3. Scenarios .......................................................4
   3.1. Fixed-Wired Environment ....................................4
   3.2. Mobile Network .............................................7
   3.3. Wireless Access ............................................8
4. Discovery of the Location Information Server ....................9
5. Identifier for Location Determination ..........................11
6. Requirements ...................................................14
7. Security Considerations ........................................16
8. Contributors ...................................................17
9. Acknowledgements ...............................................18
10. References ....................................................18
   10.1. Normative References .....................................18
   10.2. Informative References ...................................18

1. Introduction 🎀

Okay so the whole point of this doc is to give a problem statement, list requirements, and capture design aspects for a GEOPRIV Layer 7 (L7) Location Configuration Protocol (LCP) 🦋. The protocol has two purposes:

  • It's how a device gets its own location (the "Location by Value", or LbyV) from a dedicated node called the Location Information Server (LIS) 📍.
  • It also lets the device get a reference to location information (the "Location by Reference", or LbyR) ✨. That reference can look like a subscription URI, such as a SIP presence-based Uniform Resource Identifier (URI), an HTTP/HTTPS URI, or some other URI 🌸. The requirements for getting an LbyR live in a separate doc, see [LBYR-REQS] 💅.

You can tell these two functions are needed from the scenarios in Section 3 🧚.

For this doc, we're assuming the GEOPRIV Layer 7 LCP runs between the device and the LIS 🫶.

Here's the roadmap 🗺️. Section 4 covers the challenge of finding the LIS in the access network 🔍. Section 5 compares the different kinds of identifiers you could use to retrieve location info 🪪. And the list of requirements for the L7 LCP is in Section 6 💖.

One more thing: this doc does not explain how the access network provider works out where the device is 🙈. That's mostly up to the capabilities of specific link-layer technologies or certain deployment environments, so it's not the focus here 💀.

2. Terminology 💜

In this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in RFC 2119 [RFC2119] 🔥. The one twist is that, unless stated otherwise, these words apply to the design of the GEOPRIV Layer 7 Location Configuration Protocol 🎀.

The term Location Information Server (LIS) means an entity that can work out where a device is, and then hand over that location info, a reference to it, or both, to the Target through the Location Configuration Protocol (LCP) 📍.

This doc also borrows terminology from [RFC5012], like Internet Access Provider (IAP), Internet Service Provider (ISP), and Application Service Provider (ASP) 🦋.

"Access Network Provider" is what we call the IAP and the ISP when we don't need to tell them apart, because that distinction doesn't matter for this doc 🌈. If you're curious about a case where the IAP/ISP split does matter, the LIS-to-LIS protocol requirements doc [LIS2LIS] has a scenario for it 👑.

3. Scenarios 🧚

This section walks through a few network scenarios where the L7 LCP might get used ✨. Heads up, it isn't trying to list every possible deployment environment 💅. We're just focusing on these:

  • DSL/Cable networks, and WiMAX-like (Worldwide Interoperability for Microwave Access) fixed access 🔌
  • Airport, city, and campus wireless networks, like 802.11a/b/g and 802.16e/WiMAX 📶
  • 3G networks 📱
  • Enterprise networks 🏢

Also, we use the word 'host' instead of device, just for readability 🌸.

3.1. Fixed-Wired Environment 🌈

Okay, Figure 1 shows a Digital Subscriber Line (DSL) network scenario with the Access Network Provider and the customer premises 🏠. The Access Network Provider runs the link- and network-layer devices (drawn as a node) and also runs the LIS 💜.

   +---------------------------+
   |                           |
   |  Access Network Provider  |
   |                           |
   |   +--------+              |
   |   | Node   |              |
   |   +--------+ +----------+ |
   |       |  |   | LIS      | |
   |       |  +---|          | |
   |       |      +----------+ |
   |       |                   |
   +-------+-------------------+
           | Wired Network
   <----------------> Access Network Provider demarc
           |
   +-------+-------------------+
   |       |                   |
   |   +-------------+         |
   |   | NTE         |         |
   |   +-------------+         |
   |       |                   |
   |       |                   |
   |   +--------------+        |
   |   | Device with  | Home   |
   |   | NAPT and     | Router |
   |   | DHCP server  |        |
   |   +--------------+        |
   |       |                   |
   |       |                   |
   |    +------+               |
   |    | Host |               |
   |    +------+               |
   |                           |
   |Customer Premises Network  |
   |                           |
   +---------------------------+

Figure 1: Fixed-Wired Scenario 🎀

So the customer premises network is basically a router running a Network Address Translator with Port Address Translation (NAPT) plus a DHCP server, which is what most Customer Premises Networks (CPNs) look like 🦋. There's also the Network Termination Equipment (NTE), where Layer 1 and sometimes Layer 2 protocols get terminated 🔧. The router in the home network (broadband router, cable or DSL router, whatever) usually runs a NAPT and a DHCP server 💖. The NTE is a legacy device, and in a lot of cases you can't modify it to deliver location info to the host 😭. Same deal for the device with the NAPT and DHCP server 🙈.

The NTE and home router can be the same physical box, or there might be no home router at all, or the NTE and host can be in the same physical box with no home router 🧚. An example of that last one is when Ethernet service gets delivered to people's homes and the Ethernet network interface card (NIC) in their PC acts as the NTE 💻.

Current CPN deployments generally fall into one of these classifications 👑:

  1. Single PC
    1. with Ethernet network interface card (NIC), with Point-to-Point Protocol Over Ethernet (PPPoE), or Dynamic Host Configuration Protocol (DHCP) on the PC. There may be a bridged DSL or cable modem as the NTE, or the Ethernet NIC might be the NTE 🌸.
    2. with USB-based DSL access, or cable modem access using Point-to-Point Protocol over ATM (PPPoA), PPPoE, or DHCP on the PC 🔌.

Note that the device with NAPT and DHCP from Figure 1 is not present in this kind of scenario 🙅.

  1. One or more hosts with at least one router (DHCP client or PPPoE, and a DHCP server in the router). Voice over IP (VoIP) can be a soft client on a PC, a stand-alone VoIP device, or an Analog Terminal Adaptor (ATA) function built into a router 📞:
    1. combined router and NTE 💜.
    2. separate router with NTE in bridged mode 🌈.
    3. separate router with NTE (the NTE/router does PPPoE or DHCP to the WAN, and the router provides a DHCP server for hosts in the LAN, which makes it double NAT) 🔥.

The majority of fixed-access broadband customers use a router 🏆. The VoIP client placement is mentioned to show what kinds of hosts might need to request location info 🫶. Soft clients on PCs often don't launch until long after bootstrapping is complete. They also can't control any options that were specified during bootstrapping 😬. And they can't control whether a VPN client is running on the end host either 🙈.

3.2. Mobile Network 🚌

okay so one example of a moving network is a WiMAX-fixed wireless scenario 🛜. This also applies to "pre-WiMAX" and "WiMAX-like" fixed wireless networks 💅. In setups meant to give broadband to a home or other stationary spot, the customer-side antenna/NTE is usually pretty small and portable 🎀. Its LAN-side output is an Ethernet jack, which you can plug a PC or a router into 🔌. The PC or router then uses DHCP or PPPoE to connect to the access network, same as wired access networks, no drama 🫶. Access providers who roll this out might reuse the same core network (including the network elements that terminate PPPoE and provide IP addresses) for DSL, fiber to the premises (FTTP), and fixed wireless customers 🌈.

Given that the customer antenna is portable and can be battery-powered, a user can connect a laptop to it and move around inside the coverage area of a single base antenna 🚶‍♀️. That coverage area can be many square kilometers, bestie 😭. In this case the laptop (and any SIP client running on it) would be completely unaware of its mobility 🙈. Only the user and the network are aware of the laptop's mobility ✨.

Further examples of moving networks (where end devices may not be aware that they are moving) can be found in busses, trains, and airplanes 🚆✈️.

Figure 2 shows an example topology for a moving network 👀.

   +--------------------------+
   | Wireless                 |
   | Access Network Provider  |
   |                          |
   |              +----------+|
   |      +-------+ LIS      ||
   |      |       |          ||
   |  +---+----+  +----------+|
   |  | Node   |              |
   |  |        |              |
   |  +---+----+              |
   |      |                   |
   +------+-------------------+
          | Wireless Interface
          |
   +------+-------------------+
   |      |    Moving Network |
   |  +---+----+              |
   |  | NTE    |   +--------+ |
   |  |        +---+ Host   | |
   |  +-+-----++   |  B     | |
   |    |     \    +--------+ |
   |    |      \              |
   |+---+----+  \  +---+----+ |
   || Host   |   \ | Host   | |
   ||  A     |    \+  B     | |
   |+--------+     +--------+ |
   +--------------------------+

Figure 2: Moving Network

3.3. Wireless Access 📶

Figure 3 shows a wireless access network where a moving host gets location information, or references to location information, from the LIS 📍. The access equipment uses, in many cases, link-layer devices 🔗. Figure 3 represents a hotspot network like the ones found in hotels, airports, and coffee shops ☕. For editorial reasons we only describe a single access point and do not depict how the LIS obtains location information, since this is very deployment specific 🙃.

   +--------------------------+
   | Access Network Provider  |
   |                          |
   |              +----------+|
   |      +-------| LIS      ||
   |      |       |          ||
   |  +--------+  +----------+|
   |  | Access |              |
   |  | Point  |              |
   |  +--------+              |
   |      |                   |
   +------+-------------------+
          |
      +------+
      | Host |
      +------+

Figure 3: Wireless Access Scenario

4. Discovery of the Location Information Server ✨

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 device 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 device, which is known best by entities close to the device itself, we assume that the LIS is located in the local subnet or in the 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 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 Domain Name System (DNS) lookup can be started, it is necessary to learn the domain name of the access network that runs an LIS 🗺️. There are several ways to learn the domain name. For example, the end host obtains its own public IP address via Simple Traversal of the UDP Protocol through NAT (STUN) [RFC5389], 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 [LIS-DISC] 📖.

Redirect Rule

A redirect rule at an entity in the access network could be used to redirect the L7 LCP signaling messages (destined to a specific port) to the LIS 🪄. The device 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 an entity 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 extent, this approach is similar to packets that are marked 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 provider's networks that scans for the occurrence of particular destination port numbers. That's a lot of peeking, so keep it in mind 👀💜

Multicast Query

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 DNS (see [RFC4795] and [mDNS]). 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 [RFC3068] that allows the device to route discovery packets to the nearest LIS 🎯. Note that this procedure would be used purely for discovery, and is therefore similar to the local Teredo server discovery approach outlined in Section 4.2 of [TEREDO-SEL] 🦋.

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 an LIS to devices 😱. When a device discovers an LIS, it needs to ensure (and be able to ensure) that the discovered entity is indeed an authorized LIS 🔐💅

5. Identifier for Location Determination ✨

🚨 Disclaimer bestie: this section lists mechanisms that got discussed in the GEOPRIV Layer 7 Location Configuration Protocol design team. They're included to show the challenges in the problem space and listed for completeness reasons. They do not mean there's consensus on any of them, and the IETF does not recommend any of the procedures in here. 🙈

Okay so the LIS hands location info back to the device when it gets a request 📍. That means it needs some kind of identifier so it can grab the device's current location (or a good approximation of it) from a database. 🗺️

The chosen identifier needs to have these properties:

Ability for Device to learn or know 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. 💌 "Implicitly" is the situation where a device along the path between the device and the LIS modifies the identifier, like a NAT does when an IP address based identifier is in use. 🧚

Ability to use the identifier for location determination

The LIS MUST be able to use the identifier (directly or indirectly) for location determination. 🎯 "Indirectly" means the LIS uses other identifiers internally for location determination, on top of the one the device provided. 🫶

Security properties of the identifier

Misuse needs to be minimized, so an off-path adversary MUST NOT be able to obtain location information of other devices. 🙅‍♀️ An on-path adversary in the same subnet SHOULD NOT be able to spoof the identifier of another device in that same subnet. 👀

The following list discusses frequently mentioned identifiers and their properties. Let's go! 💅

Media Access Control (MAC) Address

The MAC address is known to the device itself, but it isn't carried beyond a single IP hop. 🚧 So in most deployment environments the LIS can't access it (unless it's carried in the L7 LCP itself). 🤷‍♀️

Asynchronous Transfer Mode (ATM) Virtual Path Identifier / Virtual Circuit Identifier (VPI/VCI)

The VCI/VPI is generally only seen by the DSL modem. 📡 Almost all routers in the United States use one of 2 VPI/VCI value pairs: 0/35 and 8/35. 🇺🇸 This VC gets 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 can map VPI/VCI values through its network. 🏢 With the arrival of Very high rate Digital Subscriber Line (VDSL), ATM is slowly getting phased out in favor of Ethernet. 🌸 Bye bye ATM! 👋

Ethernet Switch (Bridge)/Port Number

This identifier is only available in certain networks, like enterprise networks. 🏬 It's 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 device. 📶 Lowkey mysterious 🕵️‍♀️

Host Identifier

The Host Identifier introduced by the Host Identity Protocol (HIP) [RFC5201] lets you identify 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. 🥲 Also there's a deployment problem, since host identities aren't used in today's networks. 😭

Cryptographically Generated Address (CGA)

The concept of a Cryptographically Generated Address (CGA) was 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. 🪄 On top of the properties of an IP address, it allows a proof of ownership. ✅ That means a return routability check can be omitted. 🙌 It's only available for IPv6 addresses. 💜

Network Access Identifiers

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 device itself. 🏠 To the network, the authenticated user identity is only available if a network access authentication procedure is executed. 🫣 When roaming, the user's identity might not be available to the access network, because security protocols might offer user identity confidentiality and hide the real identity. 🎭 The access network then only sees a pseudonym or a randomized string. 🌈

Unique Client Identifier

The Broadband Forum has defined that all devices expected 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 using DHCP to the WAN use RFC 4361 [RFC4361] to give the DHCP server a unique client identifier. 🎀 This identifier is, however, not visible to the device when legacy NTE devices are used. 🙃

IP Address

The device's IP address may be used for location determination. 📬 This IP address isn't visible to the LIS if the device is behind one or multiple NATs. 🧱 That may not be a problem, since the location of a device behind a NAT can't be determined by the access network. 🤔 The LIS would only see the public IP address of the NAT binding allocated by the NAT, which is the expected behavior. ✨ The IP address's property for a return routability check is attractive, because it returns location information only to the address that submitted the request. 🔁 If an adversary wants to learn the location of a device (as identified by a particular IP address), it doesn't see the response message (unless it's on the subnetwork or at a router along the path towards the LIS). 🕶️

On a shared medium, though, an adversary could ask for location information of another device. 😱 The adversary would be able to see the response message, since it's sniffing on the shared medium, unless security mechanisms like link-layer encryption are in place. 🔓 With a network deployment as shown in Section 3.1, where multiple devices in the Customer Premises are behind a NAT, the LIS is unable to tell the individual devices apart. 🫠 For WLAN deployments like the ones in hotels, as shown in Section 3.3, it's possible for an adversary to eavesdrop on data traffic and then spoof the IP address in a query to the LIS to learn more detailed location information (e.g., specific room numbers). 🏨😬 Such an attack might, for example, compromise the privacy of hotel guests. 🚨 This is giving serious privacy danger, bestie. 💀

6. Requirements 📋

The following requirements and assumptions have been identified:

Requirement L7-1: Identifier Choice

The L7 LCP MUST be able to carry different identifiers or MUST define an identifier that is mandatory to implement. 🪪 That second option is only appropriate if the identifier is from the same realm as the one the location information service uses for its identifier-to-location mapping. 🗝️

Requirement L7-2: Mobility Support

The L7 LCP MUST support a broad range of mobility. 🏃‍♀️ That covers devices that can only move between reboots, devices that can change attachment points with the impact that their IP address changes, devices that don't change their IP address while roaming, and devices that continuously move by staying attached to the same network attachment point. 🌍

Requirement L7-3: ASP and Access Network Provider Relationship

The design of the L7 LCP MUST NOT assume that there's a business or trust relationship between the Application Service Provider (ASP) and the Access Network Provider. 🙅‍♀️ Requirements for resolving a reference to location information aren't discussed in this document. 📭

Requirement L7-4: Layer 2 and Layer 3 Provider Relationship

The design of the L7 LCP MUST assume that there's a trust and business relationship between the L2 and the L3 provider. 🤝 The L3 provider operates the LIS that the device queries. 🖥️ It needs to get location information from the L2 provider, since that one is closest to the device. 📍 If the L2 and L3 providers for the same device are different entities, they cooperate for the purposes needed to determine locations. 💞

Requirement L7-5: Legacy Device Considerations

The design of the L7 LCP MUST consider legacy devices, like residential NAT devices and NTEs in a DSL environment, that can't be upgraded to support additional protocols (for example, to pass additional information towards the device). 🦕 We don't leave the oldies behind! 🫶

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 provides the LIS used by the device, so it can 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 that prior network access authentication. 🚫 (Yes, that's the exact wording from the spec, so we're keeping it as is. 🙈)

Requirement L7-8: Network Topology Unawareness

The design of the L7 LCP MUST NOT assume that devices are aware of the access network topology. 🗺️🙅‍♀️ Devices are, however, able to determine their public IP address(es) via mechanisms like Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) [RFC5389] or the Next Steps in Signaling (NSIS) NAT/Firewall NSIS Signaling Layer Protocol (NSLP) [NSLP]. 🔍

Requirement L7-9: Discovery Mechanism

The L7 LCP MUST define a mandatory-to-implement LIS discovery mechanism. 🔎 Every device needs to be able to find the LIS, no exceptions! 🫡

Requirement L7-10: PIDF-LO Creation

When an LIS creates a Presence Information Data Format (PIDF) Location Object (LO) [RFC4119], it MUST put the <geopriv> element into the <device> element of the presence document (see [RFC4479]). 📄 This makes sure that the resulting PIDF-LO document, which gets distributed to other entities afterwards, conforms to the rules outlined in [RFC5491]. 💅✨

7. Security Considerations 🔐

⚠️ Serious talk time, bestie. Using a Geolocation L7 Location Configuration Protocol means the device (and a human user of that device, if there is one) exposes themselves to a privacy risk, where an unauthorized entity receives location information. 😰 Giving confidentiality-protected location to the requestor depends on the success of four steps:
  1. The client MUST have a means to discover a LIS. 🧭
  2. The client MUST authenticate the discovered LIS. 🪪
  3. The LIS MUST be able to determine location and return it to the authorized entity. 📍
  4. The LIS MUST securely exchange messages without intermediaries eavesdropping on or tampering with them. 🛡️

This document contains various security-related requirements throughout, addressing the steps above. 🫶 For a broader security discussion of the overall geolocation privacy architecture, the reader is referred to [GEOPRIV-ARCH]. 📚🌸

8. Contributors 🎀

Okay so this one was a whole team effort 🫶 It came from the GEOPRIV Layer 7 Location Configuration Requirements Design Team in the IETF GEOPRIV Working Group. The contributors are Henning Schulzrinne, Barbara Stark, Marc Linsner, Andrew Newton, James Winterbottom, Martin Thomson, Rohan Mahy, Brian Rosen, Jon Peterson, and Hannes Tschofenig. Iconic squad 👑

Big thanks to the GEOPRIV Working Group Chairs, Andy Newton, Randy Gellens, and Allison Mankin, for creating the design team 💖 Extra love to Andy Newton for supporting the design team mailing list, setting up Jabber chat conferences, and showing up to the phone conference discussions 📞

The design team members can be reached at:

Marc Linsner:  mlinsner@cisco.com

Rohan Mahy:  rohan@ekabal.com

Andrew Newton:  andy@hxr.us

Jon Peterson:  jon.peterson@neustar.biz

Brian Rosen:  br@brianrosen.net

Henning Schulzrinne:  hgs@cs.columbia.edu

Barbara Stark:  Barbara.Stark@bellsouth.com

Martin Thomson:  Martin.Thomson@andrew.com

Hannes Tschofenig:  Hannes.Tschofenig@nsn.com

James Winterbottom:  James.Winterbottom@andrew.com

9. Acknowledgements 🌸

Next up, the people who helped out during the WGLC review 🥰 They are 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. They all left review comments, and that's literally how the spec got better ✨

The authors also want to thank NENA for their work on [NENA]. It helped give us some of the initial thinking 🧚

Thanks as well to Cullen Jennings for his feedback during IESG processing. We also want to thank Alexey Melnikov, Dan Romascanu, and Robert Sparks 💜

10. References 🦋

10.1. Normative References

[RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5012]       Schulzrinne, H. and R. Marshall, "Requirements for
                Emergency Context Resolution with Internet
                Technologies", RFC 5012, January 2008.

10.2. Informative References

[802.1AB]       "IEEE 802.1AB-2005 IEEE Standard for Local and
                Metropolitan Area Networks Station and Media Access
                Control Connectivity Discovery", May 2005, <http://
                standards.ieee.org/getieee802/download/
                802.1AB-2005.pdf>.

[CDP]           Wikipedia, "Cisco Discovery Protocol (CDP)", <http://
                en.wikipedia.org/wiki/Cisco_Discovery_Protocol>.

[GEOPRIV-ARCH]  Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
                Tschofenig, H., and H. Schulzrinne, "An Architecture
                for Location and Location Privacy in Internet
                Applications", Work in Progress, October 2009.

[LBYR-REQS]     Marshall, R., Ed., "Requirements for a Location-by-
                Reference Mechanism", Work in Progress,
                November 2009.

[LIS-DISC]      Thomson, M. and J. Winterbottom, "Discovering the
                Local Location Information Server (LIS)", Work
                in Progress, February 2010.

[LIS2LIS]       Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
                Requirements", Work in Progress, November 2007.

[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)", December 2006, <http://
                www.nena.org/sites/default/files/
                08-505_20061221.pdf>.

[NSLP]          Stiemerling, M., Tschofenig, H., Aoun, C., and E.
                Davies, "NAT/Firewall NSIS Signaling Layer Protocol
                (NSLP)", Work in Progress, February 2010.

[RFC2113]       Katz, D., "IP Router Alert Option", RFC 2113,
                February 1997.

[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.

[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.

[RFC4282]       Aboba, B., Beadles, M., Arkko, J., and P. Eronen,
                "The Network Access Identifier", RFC 4282,
                December 2005.

[RFC4361]       Lemon, T. and B. Sommerfeld, "Node-specific Client
                Identifiers for Dynamic Host Configuration Protocol
                Version Four (DHCPv4)", RFC 4361, February 2006.

[RFC4479]       Rosenberg, J., "A Data Model for Presence", RFC 4479,
                July 2006.

[RFC4795]       Aboba, B., Thaler, D., and L. Esibov, "Link-local
                Multicast Name Resolution (LLMNR)", RFC 4795,
                January 2007.

[RFC5201]       Moskowitz, R., Nikander, P., Jokela, P., and T.
                Henderson, "Host Identity Protocol", RFC 5201,
                April 2008.

[RFC5389]       Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
                "Session Traversal Utilities for NAT (STUN)",
                RFC 5389, October 2008.

[RFC5491]       Winterbottom, J., Thomson, M., and H. Tschofenig,
                "GEOPRIV Presence Information Data Format Location
                Object (PIDF-LO) Usage Clarification, Considerations,
                and Recommendations", RFC 5491, March 2009.

[TEREDO-SEL]    Ward, N., "Teredo Server Selection", Work
                in Progress, July 2007.

[TR069]         "TR-069, CPE WAN Management Protocol v1.1, Version:
                Issue 1 Amendment 2", December 2007, <http://
                www.broadband-forum.org/technical/download/
                TR-069_Amendment-2.pdf>.

[mDNS]          Cheshire, S. and M. Krochmal, "Multicast DNS", Work
                in Progress, September 2009.

Authors' Addresses 💅

Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo  02600
Finland

Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI:   http://www.tschofenig.priv.at


Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY  10027
US

Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI:   http://www.cs.columbia.edu
📦 where this page comes from