RFC 5986
Discovering the Local Location Information Server (LIS)
RFC 5986: Discovering the Local Location Information Server (LIS) ✨
Okay bestie, let's get the vibe check on this one first 💖. It's RFC 5986, titled Discovering the Local Location Information Server (LIS). The authors are M. Thomson and J. Winterbottom, both at Andrew Corporation. It's a Standards Track doc, ISSN 2070-1721, published September 2010. It doesn't list anything it obsoletes or updates, so it's standing on its own 🦋.
Abstract
Okay so the big idea is that a Device needs to find the right Location Information Server (LIS) in its local access network if it wants location info, and this doc explains how to do that 🗺️. It describes a method for discovering the LIS that serves a Device. It defines DHCP options for both IPv4 and IPv6 that give you a domain name, and then that domain name gets fed into a URI-enabled NAPTR (U-NAPTR) resolution process 🧚.
Status of This Memo
This is an Internet Standards Track document 🌸.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📚.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5986 🔗.
Copyright Notice
Copyright (c) 2010 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) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🫶. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️.
Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
1.1. Discovery Procedure Overview . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. LIS Discovery Procedure . . . . . . . . . . . . . . . . . . . 4
2.1. Residential Gateways . . . . . . . . . . . . . . . . . . . 6
2.2. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 7
3. Determining a Domain Name . . . . . . . . . . . . . . . . . . 7
3.1. Domain Name Encoding . . . . . . . . . . . . . . . . . . . 7
3.2. Access Network Domain Name DHCPv4 Option . . . . . . . . . 8
3.3. Access Network Domain Name DHCPv6 Option . . . . . . . . . 8
3.4. Alternative Domain Names . . . . . . . . . . . . . . . . . 9
4. U-NAPTR Resolution of a LIS URI . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.1. Registration of DHCPv4 and DHCPv6 Option Codes . . . . . . 13
6.2. Registration of a Location Server Application Service
Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Registration of a Location Server Application Protocol
Tag for HELD . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 151. Introduction and Overview 🌟
Knowing where a Device is physically located is super useful, and honestly sometimes necessary, for loads of services 🍓. A Location Information Server (LIS) is the one in charge of handing that location info out to Devices on access networks that give them Internet access. The LIS uses what it knows about the access network and its physical topology to create and serve up location information 🗺️.
Every access network needs its own specific topology knowledge 🧠. So it's really important to find the LIS that has exactly the knowledge needed to locate a Device, meaning the LIS that serves the current access network. Automatic discovery matters most when there's any chance the Device might roam outside a single access network. If you rely on static configuration, things can go sideways with unexpected errors when a Device moves between access networks 😭.
This document describes a process a Device can use to discover a LIS 💅. The process uses a DHCP option and the DNS. What comes out of it is an HTTP [RFC2616] or HTTPS [RFC2818] URI that identifies a LIS 🦋.
The URI from the discovery process is for location configuration only. In other words, the Device MUST dereference the URI using the process described in HTTP-Enabled Location Delivery (HELD) [RFC5985]. URIs found this way are not "location URIs" [RFC5808], so dereferencing one only gives you the location of the requestor 🙈. Devices MUST NOT embed these URIs in fields of other protocols that are designed to carry the location of the Device 🚫.
1.1. Discovery Procedure Overview ✨
Okay so DHCP ([RFC2131], [RFC3315]) is a super common way to hand out bootstrap configuration info, which lets a Device work in a specific network environment 🎀. The DHCP info is mostly static. It's configuration that doesn't change while the Device is attached to the network. Physical location info might change over that time, but the address of the LIS doesn't. So DHCP is a great fit for configuring a Device with the address of a LIS 💜.
This document defines a DHCP option that produces a domain name identifying the local access network. That's covered in Section 3 🌈.
Section 4 describes a method that uses URI-enabled NAPTR (U-NAPTR) [RFC4848], which is a Dynamic Delegation Discovery Service (DDDS) profile that produces a URI for the LIS. The input to this process comes from the DHCP option 🧚♀️.
For the LIS discovery DDDS application, an Application Service tag "LIS" and an Application Protocol tag "HELD" were created and registered with the IANA. Based on the domain name, this U-NAPTR application uses those two tags to figure out a URI for a LIS that supports the HELD protocol 🫶.
1.2. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥.
This document also uses the term "Device" to mean an end host or client, consistent with how HELD uses it. In HELD and RFC 3693 [RFC3693] lingo, the Device is also the Target 🎯.
"Access network" refers to the network a Device connects to for Internet access. The "access network provider" is the entity that operates the access network. This lines up with the definition in [RFC5687], which combines the Internet Access Provider (IAP) and Internet Service Provider (ISP) 👑. The access network provider is responsible for giving the Device a public IP address and for providing a LIS service, either directly or indirectly 💅.
2. LIS Discovery Procedure 🗝️
Picture a Device with multiple network interfaces. Each one could be served by a different access network, and each of those could have a different LIS 🌸. The Device SHOULD attempt to discover the LIS for each network interface, and it can stop once it successfully discovers a LIS on any interface ✨.
The LIS discovery procedure goes like this:
- Acquire the access network domain name (Section 3).
This might be repeated for each of the network interfaces on the Device. Domain names acquired from other sources might also get added 🍓.
- Apply U-NAPTR resolution (Section 4) to discover a LIS URI.
The U-NAPTR process runs with each of the domain names as input 🧚.
- Verify that the LIS is able to provide location information.
The first URI that gets a successful response from the LIS is the one that gets used 🏆.
A Device MUST support discovery using the access network domain name DHCP option (Section 3) as input to U-NAPTR resolution (Section 4). If that option isn't available, DHCPv4 option 15 [RFC2132] gets used instead. Other domain names MAY be used, as described in Section 3.4 🌈.
A Device that discovers a LIS URI MUST attempt to verify that the LIS is able to provide location information. For HELD, the Device verifies the URI by making a location request to the LIS. Any HTTP 200 response containing a HELD response means success. That includes HELD error responses, except for the "notLocatable" error 💀.
If, at any time, the LIS responds to a request with the "notLocatable" error code (see Section 4.3.2 of [RFC5985]), the Device MUST continue or restart the discovery process. A Device SHOULD NOT make further requests to a LIS that gave a "notLocatable" error until its network attachment changes, or until it discovers the LIS on an alternative network interface 🙅♀️.
Static configuration of a domain name or a LIS URI MAY be used. Heads up though: if a Device has moved from its usual location, static configuration might point to a LIS that can't provide accurate location information 🚨.
The product of the LIS discovery process for HELD is an HTTPS or HTTP URI. Nothing sets this URI apart from other URIs with the same scheme, except that it came out of this process. Only URIs produced by the discovery process can be used for location configuration with HELD 🔐.
The overall discovery process is summed up in Figure 1 👇.
-----------
( Start )
-----+-----
|<--------------------------------------+
| |
V |
------^------- ------^------ |
/ \ / 1. \ |
< Next interface >------->< Get domain >-----+
\ / Y ^ \ / N
------v------- | ------v------
| N | | Y
| | V
| | ------^------
| | / 2. \
| +----< Get URI ><----+
| N \ / |
| ------v------ |
| | Y |
| V |
| ------^------ |
| / 3. \ |
| < Check URI >-----+
| \ / N
| ------v------
| | Y
V V
----------- -----------
( Failure ) ( Success )
----------- -----------
Figure 1: LIS Discovery Flowchart2.1. Residential Gateways 🏠
okay so the options in residential gateways totally decide whether this algorithm slays in home networks 💅 The fixed wireline scenario gets the full breakdown in [RFC5687], Section 3.1. In that setup, there's a residential gateway sitting between the Device and the access network. If the gateway doesn't pass the right info down to the Devices it serves, those Devices literally can't find a LIS 💀
Gateway support for this spec is what makes sure the Devices behind it can actually get their location info 🫶 A lot of the time the residential gateway hands out config to its Devices with DHCP, so it can use DHCP to help them reach their location info ✨ It can do that by giving out an access network domain name DHCP option that works for LIS discovery, or by acting as a LIS itself. To actively help its Devices, a residential gateway can:
- acquire an access network domain name from the access network provider (possibly using DHCP) and pass the resulting value to Devices; or
- discover a LIS on its external interface, then provide Devices with the domain name that was used to successfully discover the LIS; or
- explicitly include configuration that refers to a particular LIS; or
- act as a LIS and directly provide location information to the Devices it serves, including providing a means to discover this service.
Same as with Devices, a specific domain name or location config is only accurate as long as the residential gateway doesn't move 🚚 If a residential gateway relies on config instead of automatic discovery and then gets moved, the Devices it serves could end up with wrong info 😭 They could be led to a LIS that can't give accurate location info, or, if the location is configured on the residential gateway, the gateway itself could hand out incorrect location info 🙈
2.2. Virtual Private Networks (VPNs) 🔐
A Device MUST NOT attempt LIS discovery over a VPN network interface until it has attempted and failed to perform discovery on all of its other non-VPN interfaces. A Device MAY perform discovery over a VPN network interface if it already tried discovery on its non-VPN interfaces, but a LIS found this way probably won't have the info needed to figure out an accurate location 🧐
Not every interface connected to a VPN can be detected by Devices or the software running on them 👀 So it's possible that a LIS on the far side of a VPN gets found by accident. A LIS gives back a "notLocatable" error code when it can't fulfill a request (see [RFC5985], Section 6.3), and that's the safety net 🦋 Even if a Device finds a LIS over the VPN, it won't rely on a LIS that can't give accurate location info. Iconic behavior, honestly 👑
3. Determining a Domain Name 🌸
DHCP is a direct way for the access network provider to configure a Device 🫶 The access network domain name option names a domain that's suitable for service discovery within the access network. That domain name then gets fed into the U-NAPTR resolution process for LIS discovery ✨
The domain name in this option is one owned by the access network operator. It's meant for discovering services within the access network and nothing else 💅
This document registers a DHCP option for the access network domain name for both IPv4 and IPv6 🎀
3.1. Domain Name Encoding 🧩
This section describes how the domain name gets encoded for the DHCPv4 option defined in Section 3.2 and the DHCPv6 option defined in Section 3.3, so it's giving consistency 🫶
The domain name is encoded according to Section 3.1 of [RFC1035]. Each label is written as a one-octet length field followed by that many octets. Every domain name ends with the null label of the root, so the whole domain name finishes with a length byte of zero 🍓 The high-order two bits of every length octet MUST be zero, and the remaining six bits of the length field limit each label to 63 octets or less. To keep implementations simple, the total length of a domain name (label octets and label length octets together) is capped at 255 octets or less 💖
For example, the domain "example.com." is encoded in 13 octets like this:
+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 | e | x | a | m | p | l | e | 3 | c | o | m | 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+Heads up, this part is a little tricky 🙈 The length field in either option represents the length of the entire domain name encoding, while the length fields inside the domain name encoding are the length of a single label. Different numbers, different jobs, bestie 💜
3.2. Access Network Domain Name DHCPv4 Option 🎀
This section defines a DHCP for IPv4 (DHCPv4) option for the domain name associated with the access network ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Access Network Domain Name .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Network Domain Name (cont.) .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Access Network Domain Name DHCPv4 OptionHere's the breakdown 🍰
option-code:OPTION_V4_ACCESS_DOMAIN(213).option-length: the length of the entire access network domain name option in octets.option-value: the domain name associated with the access network, encoded as described in Section 3.1.
A DHCPv4 client MAY request an access network domain name option in a Parameter Request List option, as described in [RFC2131] 🙌
This option holds a single domain name, so it MUST contain precisely one root label 💅
3.3. Access Network Domain Name DHCPv6 Option 🦋
This section defines a DHCP for IPv6 (DHCPv6) option for the domain name associated with the access network. It's formatted pretty much like the DHCPv4 option, so no new drama 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_ACCESS_DOMAIN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Network Domain Name .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DHCPv6 Access Network Domain Name Optionoption-code:OPTION_V6_ACCESS_DOMAIN(57).option-length: the length of the entire access network domain name option in octets.option-value: the domain name associated with the access network, encoded as described in Section 3.1.
A DHCPv6 client MAY request an access network domain name option in an Options Request Option (ORO), as described in [RFC3315] ✨
Same deal as v4: this option holds a single domain name, so it MUST contain precisely one root label 🫶
3.4. Alternative Domain Names 🗺️
The U-NAPTR resolution method needs a domain name as input, and the access network domain name DHCP options (Sections 3.2 and 3.3) are one place that name can come from 💖
If a Device knows one or more alternative domain names that might be used for discovery, it MAY repeat the U-NAPTR process with those domain names as input 🔁 For example, static configuration on a Device could be how it gets a domain name 🧚
DHCPv4 option 15 [RFC2132] shows which domain name a host uses when it resolves hostnames in DNS. This option only gets used when the DHCPv4 access domain name isn't available 🌸
DHCPv4 option 15 might not be a good fit for every network, though 🙈 Imagine a global enterprise with lots of sites where every Device uses the same value for option 15. In that kind of setup, you'd probably want to find a LIS that's local to each site. The access domain name option can have a different value at each site so that a LIS at that site can be discovered 📍
Alternative domain names MUST NOT be used unless the access network domain name option was unsuccessful, or unless external information says a particular domain name should be used 🚫
Other domain names might come from a DHCP server (for example, [RFC4702] for DHCPv4 and [RFC4704] for DHCPv6). But those names could be handed out without anyone thinking about LIS discovery, so these other domain names probably don't contain useful values 🤷♀️
4. U-NAPTR Resolution of a LIS URI 🔍
U-NAPTR [RFC4848] resolution for a LIS takes a domain name as input and produces a URI that identifies the LIS ✨ It also needs an Application Service tag and an Application Protocol tag, which tell LIS-related NAPTR records apart from other records for that same domain 🏷️
Section 6.2 defines an Application Service tag of "LIS", which identifies the location service for a given domain. The Application Protocol tag "HELD", defined in Section 6.3, identifies a LIS that understands the HELD protocol [RFC5985] 💜
The NAPTR records below show how the Application Service and Protocol tags are used. Iterative NAPTR resolution delegates responsibility for the LIS service from "zonea.example.net." and "zoneb.example.net." to "outsource.example.com." 🦋
zonea.example.net.
;; order pref flags
IN NAPTR 100 10 "" "LIS:HELD" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
zoneb.example.net.
;; order pref flags
IN NAPTR 100 10 "" "LIS:HELD" ( ; service
"" ; regex
outsource.example.com. ; replacement
)
outsource.example.com.
;; order pref flags
IN NAPTR 100 10 "u" "LIS:HELD" ( ; service
"!.*!https://lis.example.org:4802/?c=ex!" ; regex
. ; replacement
)
Figure 4: Sample LIS:HELD Service NAPTR RecordsThe details for the "LIS" Application Service tag and the "HELD" Application Protocol tag are in Section 6 📖
U-NAPTR resolution can produce multiple results from each iteration of the algorithm 🎲 The order and preference values in the NAPTR record decide which one gets picked. A Device MAY try alternative choices if the first choice doesn't work 🔄 But if a request to the resulting URI gets back a HELD "notLocatable" response (or something equivalent), the Device SHOULD NOT try any alternative choices from the same domain name 🛑
An HTTPS LIS URI that comes out of U-NAPTR MUST be authenticated using the domain name method described in Section 3.1 of RFC 2818 [RFC2818]. The domain name used for that authentication is the one pulled out of the URI, not the one that went into the U-NAPTR resolution process 🔐✨
5. Security Considerations 🔐
okay bestie, the address of a LIS is usually well-known inside an access network, so getting messages intercepted doesn't introduce any specific new worries 👀
The primary attack on the methods in this document is one that leads to impersonation of a LIS 😭 The LIS is responsible for providing location information, and that info is critical for a bunch of network services. A Device also doesn't necessarily have a prior relationship with a LIS, so it's giving high-stakes. Several methods are described here that can limit the probability of this attack, or provide some protection against it. These methods MUST be applied unless similar protections are already in place, or in cases (like an emergency) where location information of dubious origin is arguably better than none at all 🚨
An attacker could try to compromise LIS discovery at any of three stages:
- providing a falsified domain name to be used as input to U-NAPTR
- altering the DNS records used in U-NAPTR resolution
- impersonating the LIS
The domain name used to authenticate the LIS is the domain name input to the U-NAPTR process, not the output of that process [RFC3958], [RFC4848]. So, the results of DNS queries don't need integrity protection 🧠✨
An HTTPS URI is authenticated using the method described in Section 3.1 of [RFC2818]. HTTP client implementations frequently don't provide a way to authenticate based on a domain name other than the one in the request URI, which is the U-NAPTR output. To avoid having to authenticate the LIS with a domain name that's different from the one used to identify it, a client MAY choose to reject URIs that contain a domain name different from the U-NAPTR input. To support endpoints that enforce this restriction on URIs, network administrators SHOULD ensure that the domain name in the DHCP option is the same as the one contained in the resulting URI 💅
Authentication of a LIS relies on the integrity of the domain name acquired from DHCP. An attacker who can falsify a domain name gets around the protections provided, so that's a big no. To make sure the access network domain name DHCP option can be relied upon, preventing DHCP messages from being modified or spoofed by attackers is necessary. Physical- or link-layer security are commonly used to reduce the possibility of this attack within an access network. DHCP authentication [RFC3118] might also provide a degree of protection against modification or spoofing 🔒
A LIS that is identified by an HTTP URI cannot be authenticated. Unsecured HTTP also doesn't meet the requirements in HELD for confidentiality and integrity. So if an HTTP URI is the product of LIS discovery, Devices are left vulnerable to several attacks 😬 Lower-layer protections, such as Layer 2 traffic separation, might be used to provide some guarantees.
6. IANA Considerations 📋
6.1. Registration of DHCPv4 and DHCPv6 Option Codes
The IANA has assigned an option code of 213 for the DHCPv4 option for an access network domain name option, as described in Section 3.2 of this document 🎀
The IANA has assigned an option code of 57 for the DHCPv6 option for an access network domain name option, as described in Section 3.3 of this document 🎀
6.2. Registration of a Location Server Application Service Tag
This section registers a new S-NAPTR/U-NAPTR Application Service tag for LIS, as mandated by [RFC3958] 🦋
Application Service Tag: LIS
Intended usage: Identifies a service that provides a Device with its
location information.
Defining publication: RFC 5986
Related publications: HELD [RFC5985]
Contact information: The authors of this document
Author/Change controller: The IESG6.3. Registration of a Location Server Application Protocol Tag for HELD
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag for the HELD protocol [RFC5985], as mandated by [RFC3958] 🌸
Application Protocol Tag: HELD
Intended Usage: Identifies the HELD protocol.
Applicable Service Tag(s): LIS
Terminal NAPTR Record Type(s): U
Defining Publication: RFC 5986
Related Publications: HELD [RFC5985]
Contact Information: The authors of this document
Author/Change Controller: The IESG7. Acknowledgements 🫶
This document uses a mechanism that is largely identical to the one in [RFC5222] and [RFC5223]. The authors would like to thank Leslie Daigle for her work on U-NAPTR, Peter Koch for feedback on how not to use DNS for discovery, Andy Newton for constructive suggestions about document direction, Richard Barnes, Joe Salowey, Barbara Stark, and Hannes Tschofenig for input and reviews, and Dean Willis for constructive feedback. Iconic cast, no notes 👑
8. References 📚
8.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
Configuration Protocol (DHCP) Client Fully Qualified
Domain Name (FQDN) Option", RFC 4702, October 2006.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010.8.2. Informative References
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
August 2008.
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010.
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010.Authors' Addresses 🖊️
Martin Thomson
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
James Winterbottom
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com📦 where this page comes from
- ietf: rfc5986 2010-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms