idnits 2.17.1 draft-ietf-geopriv-lis-discovery-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1006. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1013. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1019. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2008) is 5768 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-16 -- Obsolete informational reference (is this intentional?): RFC 3025 (Obsoleted by RFC 3115) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-08 == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-08 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft J. Winterbottom 4 Intended status: Standards Track Andrew 5 Expires: January 12, 2009 July 11, 2008 7 Discovering the Local Location Information Server (LIS) 8 draft-ietf-geopriv-lis-discovery-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 12, 2009. 35 Abstract 37 A method is described for the discovery of a Location Information 38 Server. The method uses a Dynamic Host Configuration Protocol (DHCP) 39 option. DHCP options are defined for both IPv4 and IPv6 DHCP. A 40 URI-enabled NAPTR (U-NAPTR) method is described for use where the 41 DHCP option is unsuccessful. This document defines a U-NAPTR 42 Application Service for a LIS, with a specific Application Protocol 43 for the HTTP Enabled Location Delivery (HELD) protocol. The held: 44 URI scheme, the product of the discovery process, is defined by this 45 document. 47 Table of Contents 49 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 50 1.1. DHCP Discovery . . . . . . . . . . . . . . . . . . . . . . 3 51 1.2. U-NAPTR Discovery . . . . . . . . . . . . . . . . . . . . 3 52 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. The held: URI . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. LIS Discovery Using DHCP . . . . . . . . . . . . . . . . . . . 6 55 3.1. DHCPv4 Option for a LIS Address . . . . . . . . . . . . . 6 56 3.2. DHCPv6 Option for a LIS Address . . . . . . . . . . . . . 6 57 4. U-NAPTR for LIS Discovery . . . . . . . . . . . . . . . . . . 8 58 5. Determining the Access Network Domain Name . . . . . . . . . . 9 59 5.1. DHCP Domain Name Option . . . . . . . . . . . . . . . . . 9 60 5.2. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.2.1. Determining an External IP Address . . . . . . . . . . 10 62 6. Discovery Order . . . . . . . . . . . . . . . . . . . . . . . 13 63 6.1. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 14 64 7. Access Network Guidance . . . . . . . . . . . . . . . . . . . 15 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 67 9.1. Registration of DHCPv4 and DHCPv6 Option Codes . . . . . . 18 68 9.2. Registration of a Location Server Application Service 69 Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 9.3. Registration of a Location Server Application Protocol 71 Tag for HELD . . . . . . . . . . . . . . . . . . . . . . . 18 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 76 Appendix A. Residential Broadband LIS Discovery Example . . . . . 23 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 78 Intellectual Property and Copyright Statements . . . . . . . . . . 27 80 1. Introduction and Overview 82 Discovering a Location Information Server (LIS) is an important part 83 of the location acquisition process. The LIS is an access network 84 service that needs to be discovered before it can be used. This 85 document describes a method that a host can use to discover a URI for 86 a LIS. 88 The product of a discovery process, such as the one described in this 89 document, is the address of the service. In this document, the 90 result is a URI, which identifies a LIS. The held: URI scheme, which 91 identifies a LIS that supports HELD, is defined in Section 2. 93 The discovery process requires that the host first attempt LIS 94 discovery using Dynamic Host Configuration protocol (DHCP). If DHCP 95 is not available, or the option is not supported by the network, the 96 host attempts to discover the LIS using the DNS and URI-enabled 97 Naming Authority Pointer (U-NAPTR). Finally, the host can rely on 98 proprietary methods for determining the address of the LIS, including 99 static configuration. 101 The URI result from the discovery process is suitable for location 102 configuration only; that is, the client MUST dereference the URI 103 using the process described in HELD 104 [I-D.ietf-geopriv-http-location-delivery]. URIs discovered in this 105 way are not "location by reference" URIs; dereferencing one of them 106 provides the location of the requester only. Clients MUST NOT embed 107 these URIs in fields in other protocols designed to carry the 108 location of the client. 110 1.1. DHCP Discovery 112 DHCP ([RFC2131], [RFC3315]) is a commonly used mechanism for 113 providing bootstrap configuration information allowing a host to 114 operate in a specific network environment. The bulk of DHCP 115 information is largely static; consisting of configuration 116 information that does not change over the period that the host is 117 attached to the network. Physical location information might change 118 over this time, however the address of the LIS does not. Thus, DHCP 119 is suitable for configuring a host with the address of a LIS. 121 1.2. U-NAPTR Discovery 123 Where DHCP is not available, the DNS might be able to provide a URI. 124 This document describes a method that uses URI-enabled NAPTR 125 (U-NAPTR) [RFC4848], a Dynamic Delegation Discovery Service (DDDS) 126 profile that supports URI results. 128 For the LIS discovery DDDS application, an Application Service tag 129 "LIS" and an Application Protocol tag "HELD" are created and 130 registered with the IANA. Taking a domain name, this U-NAPTR 131 application uses the two tags to determine the LIS URI. 133 Determining the domain name to be used is a critical part of the 134 resolution process. The second part of this document describes how a 135 domain name can be derived. Several methods are described that 136 address different scenarios. 138 1.3. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 This document also uses the term "host" to refer to an end host, 145 consistent with its use in DHCP documents. In RFC3693 [RFC3693] 146 parlance, the host is the Device, which might also be the Target. 148 The terms "access network" refers to the network that a host connects 149 to for Internet access. The "access network provider" is the entity 150 that operates the access network. This is consistent with the 151 definition in [I-D.ietf-geopriv-l7-lcp-ps] which combines the 152 Internet Access Provider (IAP) and Internet Service Provider (ISP). 153 The access network provider is responsible for allocating the host an 154 IP address and for directly or indirectly providing a LIS service. 156 2. The held: URI 158 This section defines the held: URI scheme. A host acquires a held: 159 URI as the output of the discovery process in this document. It is 160 able to use this URI to retrieve its own location from a LIS, using 161 the HELD protocol [I-D.ietf-geopriv-http-location-delivery]. Other 162 uses for this URI scheme are not precluded, but are out of scope for 163 this document. 165 The held: URI scheme is defined based on a restricted subset of the 166 syntax defined in [RFC3986]. This definition follows the guildelines 167 from [RFC4395] with the qualifier that the syntax is designed to be 168 largely compatible with that used by http: URIs to limit the impact 169 on HELD implementations. 171 Using the ABNF [RFC5234] definitions from [RFC3986], the following 172 ABNF defines the format of a held: URI: 174 HELD-URI = "held://" host ":" port [ path-absolute ] [ "?" query ] 176 There is no default port for HELD. Nor is there a different scheme 177 for a "secure" variant using an additional 's' character (see Section 178 4 of [RFC3025]). HELD requires that TLS be implemented; private 179 agreements on the use of unsecured TCP, or the 180 TLS_NULL_NULL_WITH_NULL cipher suite are possible, but are not the 181 concern of this document. 183 The held: URI is not intended to be human-readable text, therefore it 184 is encoded entirely in US-ASCII. The following are examples of held: 185 URIs: 187 held://lis.example.com:49152/thisLocation?token=xyz987 188 held://lis.example.com:5432/THISLOCATION?foobar=abc123 189 held://lis.example.com:5432/THISlocation?foobar=ABC123 190 held://lis.example.com:9876/civic 192 Other than the scheme and the "host" portion, URIs are case sensitive 193 and exact equivalency is required for HELD-URI comparisons. For 194 example, in the above examples, although similar in information, the 195 2nd and 3rd URIs are not considered equivalent. 197 3. LIS Discovery Using DHCP 199 DHCP allows the access network provider to specify the address of a 200 LIS as part of network configuration. If the host is able to acquire 201 a LIS URI using DHCP then this URI is used directly; the U-NAPTR 202 process is not necessary if this option is provided. 204 This document registers DHCP options for a LIS address for both IPv4 205 and IPv6. 207 3.1. DHCPv4 Option for a LIS Address 209 This section defines a DHCP for IPv4 (DHCPv4) option for the address 210 of a LIS. 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | LIS_URI | Length | URI ... . 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | URI ... 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 1: DHCPv4 LIS URI Option 222 LIS_URI: The IANA assigned option number (TBD). 224 Length: The length of the URI in octets. 226 URI: The address of the LIS. This URI SHOULD NOT be more than 253 227 bytes in length, but MAY be extended by concatenating multiple 228 option values, as described in [RFC3396]. The URI MUST NOT be 229 NULL terminated. 231 3.2. DHCPv6 Option for a LIS Address 233 This section defines a DHCP for IPv6 (DHCPv6) option for the address 234 of a LIS. The DHCPv6 option for this parameter is similarly 235 formatted to the DHCPv4 option. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | OPTION_LIS_URI | Length | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | URI ... 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2: DHCPv6 LIS URI Option 246 OPTION_LIS_URI: The IANA assigned option number (TBD). 248 Length: The length of the URI in octets. 250 URI: The address of the LIS. The URI MUST NOT be NULL terminated. 252 4. U-NAPTR for LIS Discovery 254 U-NAPTR resolution for a LIS takes a domain name as input and 255 produces a URI that identifies the LIS. This process also requires 256 an Application Service tag and an Application Protocol tag, which 257 differentiate LIS-related NAPTR records from other records for that 258 domain. 260 Section 9.2 defines an Application Service tag of "LIS", which is 261 used to identify the location service for a particular domain. The 262 Application Protocol tag "HELD", defined in Section 9.3, is used to 263 identify a LIS that understands the HELD protocol 264 [I-D.ietf-geopriv-http-location-delivery]. 266 The NAPTR records in the following example demonstrate the use of the 267 Application Service and Protocol tags. Iterative NAPTR resolution is 268 used to delegate responsibility for the LIS service from 269 "zonea.example.com." and "zoneb.example.com." to 270 "outsource.example.com.". 272 zonea.example.com. 273 ;; order pref flags 274 IN NAPTR 100 10 "" "LIS:HELD" ( ; service 275 "" ; regex 276 outsource.example.com. ; replacement 277 ) 278 zoneb.example.com. 279 ;; order pref flags 280 IN NAPTR 100 10 "" "LIS:HELD" ( ; service 281 "" ; regex 282 outsource.example.com. ; replacement 283 ) 284 outsource.example.com. 285 ;; order pref flags 286 IN NAPTR 100 10 "u" "LIS:HELD" ( ; service 287 "!*.!held://lis.outsource.example.com/!" ; regex 288 . ; replacement 289 ) 291 Figure 3: Sample LIS:HELD Service NAPTR Records 293 Details for the "LIS" Application Service tag and the "HELD" 294 Application Protocol tag are included in Section 9. 296 5. Determining the Access Network Domain Name 298 The U-NAPTR discovery method described in Section 4 requires that the 299 domain name applicable to the access network is known. An 300 unconfigured host might not have this information, therefore it must 301 determine this value before the U-NAPTR method can be attempted. 303 This section describes several methods for discovering a domain name 304 for the local access network. Each method is attempted where 305 applicable until a domain name is derived. If a domain name is 306 successfully derived but that domain name does not produce any 307 U-NAPTR records, alternative methods can be attempted to determine 308 additional domain names. Reattempting with different methods is 309 particularly applicable when NAT is used, as is shown in 310 Section 5.2.1. 312 5.1. DHCP Domain Name Option 314 For IP version 4, Dynamic Host Configuration Protocol (DHCP) option 315 15 [RFC2131] includes the domain name suffix for the host. If DHCP 316 and option 15 are available, this value should be used as input the 317 U-NAPTR procedure. 319 Alternatively, a fully qualified domain name (FQDN) for the host 320 might be provided by the server ([RFC4702] for DHCPv4, [RFC4704] for 321 DHCPv6). The domain part of the FQDN can be used as input to the 322 U-NAPTR resolution and is obtained by removing the first label. If 323 the host has provided a fully qualified domain name using this 324 option, it SHOULD NOT be used - the domain known to the host might 325 not be the same as that of the access network. 327 Note that this method is only attempted if the LIS address option is 328 not available, but it SHOULD be attempted if DHCP is available. 330 5.2. Reverse DNS 332 DNS "PTR" records in the "in-addr.arpa." domain can be used to 333 determine the domain name of a host, and therefore, the name of the 334 domain for that host. The use of the "in-addr.arpa." domain is 335 described in [RFC1034] and results in the domain name of the host. 336 Likewise, IPv6 hosts use the "ip6.arpa." domain. In the majority of 337 cases, the domain part of this name (everything excluding the first 338 label) is also the domain name for the access network. Assuming that 339 this is true, this domain name can be used as input to the U-NAPTR 340 process. 342 For example, if the for "10.1.2.3" address, if the "PTR" record at 343 "3.2.1.10.in-addr.arpa." refers to "h3-2-1-10.example.com", this 344 results in a U-NAPTR search for "example.com". 346 The DNS hierarchy does not necessarily directly map onto a network 347 topology (see [RFC4367]); therefore, this method MUST only be used 348 for the domain name determined by removing the first label only. 349 This method assumes that the access network provider also provides 350 the reverse DNS record and they control the domain that is indicated 351 in the "PTR" record. 353 Furthermore, this method might not apply where a host is given a 354 domain name that is different from the domain name of the access 355 network. This might occur in some hosting configurations, such as 356 where a number of web server hosts, with widely varying domain names, 357 are co-located. From the above example, the access network provider 358 allocated "10.1.2.3" to the host; therefore, they also need to 359 control the DNS domain "example.com" and the associated NAPTR 360 records. DNS Security Extensions (DNSSEC) [RFC4033] provides a 361 cryptographic means of validating this association, through data 362 origin authentication. 364 5.2.1. Determining an External IP Address 366 Reverse DNS relies on knowing the IP address of a host within the 367 access domain. Initially, this SHOULD be attempted using the IP 368 address that is assigned to a local interface on the host. However, 369 when a NAT device is used, the IP address of the NAT device is 370 substituted for the source IP address. If a NAT device exists 371 between the host and the access network, the host does not have any 372 direct way to determine the IP address that it is effectively using 373 within the access network. The IP address of the NAT device and the 374 corresponding domain name can be used to discover the LIS. 376 In order to use reverse DNS in this configuration, the hosts need to 377 know the IP address that the NAT device uses. The following sections 378 describe some possible methods. 380 These methods are particularly useful in residential broadband 381 configurations. A large proportion of residential broadband services 382 employ a NAT device so that several hosts can share the same Internet 383 access. Since the network behind the NAT device are generally very 384 small, both in numbers and geographical area, it isn't necessary for 385 a LIS to operate within that network; the hosts are able to access a 386 LIS in the access network outside of the NAT device. 388 5.2.1.1. UPnP 390 If a NAT device complies with the Universal Plug and Play (UPnP) 391 specification [UPnP-IGD-WANIPConnection1], the WANIPConnection part 392 can be used to query the device for its public IP address. The 393 "GetExternalIPAddress" function provides the external address for a 394 particular network connection. 396 UPnP defines a method for discovering UPnP-enabled hosts in a 397 network; the host does not need any prior configuration to employ 398 this method. 400 The following figure demonstrates a deployment scenario where this 401 type of discovery is useful. 403 +-----+ 404 | LIS | 405 +--+--+ 406 / ________ 407 +------+ +------------+ / +-----+ (/ \) 408 | Host |-----| Router/NAT |----+----| NAT |----(( Internet )) 409 +------+ ^ +------------+ ^ +-----+ (\________/) 410 | | 411 Private (Home) Private Network 412 Network (Access Network) 414 If the LIS is discoverable based on the private address range used by 415 the Access Network, the address provided by the UPnP internet gateway 416 device (the Router/NAT device) can be used as an input to the 417 discovery process. This requires that the Access Network Provider 418 DNS server be used by the host. Reverse DNS (PTR) records need to be 419 provided for the private address range used in the access network. 421 5.2.1.2. STUN 423 A host can use the Session Traversal Utilities for NAT (STUN) 424 [I-D.ietf-behave-rfc3489bis] to determine a public IP address. The 425 host uses the "Binding Request" message and the resulting 426 "XOR-MAPPED-ADDRESS" parameter that is returned in the response. 428 Using STUN requires cooperation from a publicly accessible STUN 429 server. The host also requires configuration information that 430 identifies the STUN server, or a domain name that can be used for 431 STUN server discovery. 433 Given that a STUN service is typically operated in conjunction with 434 some other service and it is only ever intended for use with that 435 service, STUN potentially has further limitations. If the service is 436 operated behind a NAT, the address provided by the STUN server could 437 be in the private address range used by the provider of that server. 439 +-----+ 440 | LIS | 441 +--+--+ +------+ 442 \ ________ ,--| STUN | 443 +------+ +-----+ \ (/ \) +-----+ / +------+ 444 | Host |-----| NAT |--+-(( Internet ))---| NAT |----< 445 +------+ ^ +-----+ (\________/) +-----+ ^ \ +---------+ 446 | | `-| (Other) | 447 Private Private +---------+ 448 Network Network 450 STUN servers used for discovery need to be able to see and provide 451 the public reflexive transport address of the host. 453 5.2.1.3. Other Options 455 The source IP address in any IP packet can be used to determine the 456 public IP address of a host. While the STUN method uses a small part 457 of a more sophisticated protocol, this principle can be applied using 458 any other protocol. Like STUN, this method requires prior knowledge 459 of the publicly accessible server and the method that it supports. 461 For instance, a publicly accessible host could be configured to 462 respond to a UDP packet on a predefined port; the data of the 463 response could contain the source IP address that was in the request. 464 Alternatively, a HTTP server at a particular URL could be configured 465 to respond to a GET request with a "text/plain" body containing the 466 IP address of the requester. HTTP proxies render this method 467 unusable; in particular, transparent HTTP proxies might affect the 468 results of this method without the knowledge of the host. Such 469 services already exist on the public Internet. 471 6. Discovery Order 473 The previous sections described a set of procedures that allow a 474 device to determine the LIS associated with the local access network. 475 Some networks maintain a topology analogous to an onion and are 476 comprised of layers, or segments, separating hosts from the Internet 477 through intermediate networks. It is best therefore for a host to 478 discover the LIS logically closest to it, and this can best be done 479 by applying the discovery techniques in the following order: 481 1. DHCP LIS URI Option 483 2. DNS U-NAPTR Discovery, using the domain name from: 485 A. DHCP Domain Name Option 487 B. Reverse DNS, using the hosts IP address from: 489 1. the local network interface and immediate network segment 491 2. the network segment adjacent to the immediate segment, as 492 revealed by UPnP 494 3. the public Internet, as revealed by STUN; or the network 495 segment where the STUN server resides 497 (4.) any network segment, as revealed by other method 499 3. Static configuration 501 A host that discovers a LIS URI MUST attempt to verify that the LIS 502 is able to provide location information. For the HELD protocol, the 503 host MUST make a location request to the LIS. If the LIS responds to 504 this request with the "notLocatable" error code (see Section 4.3.2 of 505 [I-D.ietf-geopriv-http-location-delivery]), the host MUST mark that 506 LIS as bad and continue the discovery process. 508 DHCP discovery MUST be attempted before DNS discovery. This allows 509 the network access provider a direct and explicit means of 510 configuring a LIS address. DNS discovery is used as a failsafe, 511 providing a means to discover a LIS where the DHCP infrastructure 512 does not support the LIS URI option. 514 Static host configuration MAY be used to provide a LIS address if 515 both DHCP and DNS methods fail. Note however, that if a host has 516 moved from its customary location, static configuration might 517 indicate a LIS that is unable to provide a location. User 518 interaction is NOT RECOMMENDED; the discovery process is not easily 519 diagnosed by a user. 521 LIS discovery through DNS requires the host to determine the domain 522 name of the local access network. Where DHCP is available, the DHCP 523 domain name option (Section 5.1) can be used to provide this 524 information. If the domain name cannot be determined from DHCP, or 525 the resulting domain name fails to yield a valid LIS address then 526 reverse DNS is used. 528 The discovery procedure assumes that the correct LIS is in a network 529 segment that is closer to the host. Each network segment between the 530 host and LIS decreases the chance that the LIS is able to correctly 531 determine a location for the host. 533 Discovery methods follow an order of precedence. The exception is 534 for alternative methods of determining the hosts IP address in each 535 network segment; precedence is given to addresses in the network 536 segments closer to the host. Therefore, the host MUST attempt to use 537 the IP address assigned to its local network interface before 538 attempting to determine its IP address. Precedence is given to 539 methods, like UPnP that provide an IP address in adjacent network 540 segments. Methods for determining addresses on the public Internet 541 are given lower precedence. 543 To claim compliance with this document, a host MUST support both DHCP 544 discovery and U-NAPTR discovery. Further, the host MUST support 545 retrieval of domain name from DHCP and reverse DNS, using a local 546 interface address, UPnP and STUN. Additional methods for determining 547 the IP address of the host in different network segments are 548 optional. 550 6.1. Virtual Private Networks (VPNs) 552 Where a host has multiple network interfaces the host MAY 553 independently discover the LIS corresponding to the access networks 554 reached by each network interface. Resolving which LIS to contact 555 for location information is a host application issue. 557 LIS discovery over a VPN network interface SHOULD NOT be performed 558 since such a LIS does not have the physical presence generally 559 necessary to determine location. However, since not all VPN 560 interfaces can be detected by hosts, a LIS SHOULD NOT provide 561 location information in response to requests originating from a VPN 562 pool. This ensures that even if a host discovers a LIS over the VPN, 563 it does not rely on a LIS that is unable to provide accurate location 564 information. The exception to this is where the LIS and host are 565 able to determine a location without access network support. 567 7. Access Network Guidance 569 In order to successfully discover a LIS, a host relies on information 570 provided by the access network. DHCP and DNS servers need to be able 571 to provide the data that the device depends on. This section 572 provides guidance on what information needs to be made available to a 573 host for it to successfully discover a LIS. 575 Access networks that provide both a LIS and a DHCP server must 576 provide the DHCP option for the LIS address. Since DHCP must be 577 attempted first, if it can be guaranteed that DHCP can be used by all 578 hosts in the network, no further configuration is necessary. 580 Unless DHCP can be relied upon for all hosts in the network (see 581 [I-D.ietf-geopriv-l7-lcp-ps] for common scenarios where this isn't 582 the case), DNS discovery methods must also be supported. To support 583 the DNS discovery methods, the access network must provide two sets 584 of DNS records: the (U-)NAPTR records that enable the discovery of a 585 LIS URI from a domain name; and the reverse DNS records that enable 586 the discovery of a domain name based on the IP address of the host. 588 Access networks that provide a LIS should also provide reverse DNS 589 records for all IP addresses they administer. For each domain that 590 is referenced in reverse DNS records, a NAPTR record in that domain 591 must be provided for the "LIS:HELD" service that can be used to 592 resolve the address of a LIS. 594 The requirement for PTR and NAPTR records extends to both public and 595 private addresses used by access networks. A host that uses UPnP to 596 discover the external address of a router must be able to use the 597 resulting private address as input to a reverse DNS lookup and 598 U-NAPTR discovery. Similarly, a host that discovers a public 599 reflexive transport address using STUN should be able to use the 600 public address. 602 The following figure shows the addresses provided by UPnP (the 603 private address marked with '{U}') and STUN (the public address 604 marked with '{S}'). The access network provider should provide the 605 necessary DNS records for both of these addresses. 607 +-----+ +------+ 608 | LIS | | STUN | 609 +--+--+ +---+--+ 610 {U} / {S} _____/__ 611 +------+ +------------+ / / +-----+ / (/ \) 612 | Host |-----| Router/NAT |----+----| NAT |----(( Internet )) 613 +------+ ^ +------------+ ^ +-----+ (\________/) 614 | | 615 Private (Home) Private Network 616 Network (Access Network) 618 For the LIS to be discoverable using the public address provided by 619 STUN, the LIS requires a public IP address. An access network 620 provider cannot assume that hosts are able to reliably route packets 621 to an addresses in the private address space. 623 Note: The DHCP domain name option is notably absent from this 624 guidance. The domain name option provides a quicker and more 625 reliable means to discover the domain name in the case where a 626 DHCP server does not support the LIS URI option. If DHCP is 627 available, it is expected that access network providers use the 628 LIS URI option. 630 8. Security Considerations 632 The primary attack against the methods described in this document is 633 one that would lead to impersonation of a LIS. The LIS is 634 responsible for providing location information and this information 635 is critical to a number of network services; furthermore, a host does 636 not necessarily have a prior relationship with a LIS. Several 637 methods are described here that can limit the probablity of, or 638 provide some protection against, such an attack. 640 The address of a LIS is usually well-known within an access network; 641 therefore, interception of messages does not introduce any specific 642 concerns. 644 If DHCP is used, the integrity of DHCP options is limited by the 645 security of the channel over which they are provided. Physical 646 security and separation of DHCP messages from other packets are 647 commonplace methods that can reduce the possibility of attack within 648 an access network; alternatively, DHCP authentication [RFC3118] can 649 provide a degree of protection against modification. 651 An attacker could attempt to compromise the U-NAPTR resolution. A 652 description of the security considerations for U-NAPTR applications 653 is included in [RFC4848]. 655 In addition to considerations related to U-NAPTR, it is important to 656 recognize that the output of this is entirely dependent on its input. 657 An attacker who can control the domain name can also control the 658 final URI. Because a number of methods are provided for determining 659 the domain name, a host implementation needs to consider attacks 660 against each of the methods that are used. 662 Reverse DNS is subject to the maintenance of the "in-addr.arpa." or 663 "ip6.arpa." domain and the integrity of the results that it provides. 664 DNSSEC [RFC4033] provides some measures that can improve the 665 reliability of DNS results. In particular, DNSSEC SHOULD be applied 666 to ensure that the reverse DNS record and the resulting domain are 667 provided by the same entity before this method is used. Without this 668 assurance, the host cannot be certain that the access network 669 provider has provided the NAPTR record for the domain name that is 670 provided. 672 Hosts behind NAT devices are also subject to attacks when retrieving 673 their public IP address. [I-D.ietf-behave-rfc3489bis] describes some 674 means of mitigating this attack for STUN. 676 9. IANA Considerations 678 9.1. Registration of DHCPv4 and DHCPv6 Option Codes 680 The IANA is requested to assign an option code for the DHCPv4 option 681 for a LIS address, as described in Section 3.1 of this document. 683 The IANA is requested to assign an option code for the DHCPv6 option 684 for a LIS address, as described in Section 3.2 of this document. 686 9.2. Registration of a Location Server Application Service Tag 688 This section registers a new S-NAPTR/U-NAPTR Application Service tag 689 for a LIS, as mandated by [RFC3958]. 691 Application Service Tag: LIS 693 Intended usage: Identifies a service that provides a host with its 694 location information. 696 Defining publication: RFCXXXX 698 Related publications: HELD [I-D.ietf-geopriv-http-location-delivery] 700 Contact information: The authors of this document 702 Author/Change controller: The IESG 704 9.3. Registration of a Location Server Application Protocol Tag for 705 HELD 707 This section registers a new S-NAPTR/U-NAPTR Application Protocol tag 708 for the HELD [I-D.ietf-geopriv-http-location-delivery] protocol, as 709 mandated by [RFC3958]. 711 Application Service Tag: HELD 713 Intended Usage: Identifies the HELD protocol. 715 Applicable Service Tag(s): LIS 717 Terminal NAPTR Record Type(s): U 719 Defining Publication: RFCXXXX 720 Related Publications: HELD [I-D.ietf-geopriv-http-location-delivery] 722 Contact Information: The authors of this document 724 Author/Change Controller: The IESG 726 10. Acknowledgements 728 The authors would like to thank Leslie Daigle for her work on 729 U-NAPTR; Peter Koch for his feedback on the DNS aspects of this 730 document; Andy Newton for constructive suggestions with regards to 731 document direction; Hannes Tschofenig and Richard Barnes for input 732 and reviews; Dean Willis for constructive feedback. 734 11. References 736 11.1. Normative References 738 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 739 STD 13, RFC 1034, November 1987. 741 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 742 RFC 2131, March 1997. 744 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 745 and M. Carney, "Dynamic Host Configuration Protocol for 746 IPv6 (DHCPv6)", RFC 3315, July 2003. 748 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 749 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 750 November 2002. 752 [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 753 Configuration Protocol (DHCP) Client Fully Qualified 754 Domain Name (FQDN) Option", RFC 4702, October 2006. 756 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 757 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 758 Option", RFC 4704, October 2006. 760 [RFC4848] Daigle, L., "Domain-Based Application Service Location 761 Using URIs and the Dynamic Delegation Discovery Service 762 (DDDS)", RFC 4848, April 2007. 764 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 765 Resource Identifier (URI): Generic Syntax", STD 66, 766 RFC 3986, January 2005. 768 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 769 Specifications: ABNF", STD 68, RFC 5234, January 2008. 771 [I-D.ietf-behave-rfc3489bis] 772 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 773 "Session Traversal Utilities for (NAT) (STUN)", 774 draft-ietf-behave-rfc3489bis-16 (work in progress), 775 July 2008. 777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 778 Requirement Levels", BCP 14, RFC 2119, March 1997. 780 11.2. Informative References 782 [RFC3025] Dommety, G. and K. Leung, "Mobile IP Vendor/ 783 Organization-Specific Extensions", RFC 3025, 784 February 2001. 786 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 787 Messages", RFC 3118, June 2001. 789 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 790 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 792 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 793 Service Location Using SRV RRs and the Dynamic Delegation 794 Discovery Service (DDDS)", RFC 3958, January 2005. 796 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 797 Rose, "DNS Security Introduction and Requirements", 798 RFC 4033, March 2005. 800 [RFC4367] Rosenberg, J. and IAB, "What's in a Name: False 801 Assumptions about DNS Names", RFC 4367, February 2006. 803 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 804 Registration Procedures for New URI Schemes", BCP 115, 805 RFC 4395, February 2006. 807 [I-D.ietf-geopriv-l7-lcp-ps] 808 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 809 Location Configuration Protocol; Problem Statement and 810 Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in 811 progress), June 2008. 813 [I-D.ietf-geopriv-http-location-delivery] 814 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 815 "HTTP Enabled Location Delivery (HELD)", 816 draft-ietf-geopriv-http-location-delivery-08 (work in 817 progress), July 2008. 819 [UPnP-IGD-WANIPConnection1] 820 UPnP Forum, "Internet Gateway Device (IGD) Standardized 821 Device Control Protocol V 1.0: WANIPConnection:1 Service 822 Template Version 1.01 For UPnP Version 1.0", DCP 05-001, 823 Nov 2001. 825 Appendix A. Residential Broadband LIS Discovery Example 827 This example shows how LIS discovery using U-NAPTR and DNS might be 828 performed in a residential broadband scenario. The assumed network 829 topology for this network is shown in Figure 4. 831 __________ __________ 832 +----------------+ ( ) ( ) 833 | NAT | ( ACCESS ) ( ) 834 | (Home Router) |-------( NETWORK )-------( INTERNET ) 835 | 192.0.2.75 | ( my.isp.net ) ( ) 836 +----------------+ ( ) ( ) 837 | ---------- ---------- 838 | : 839 | : 840 +----------------+ +-----------------+ 841 | DEVICE | | VOICE SERVICE | 842 | | | PROVIDER (VSP) | 843 | 192.168.0.55 | | STUN SERVER | 844 +----------------+ +-----------------+ 846 Figure 4: Example Network Topology 848 In this example, the host sits behind a home router that includes a 849 NAT function. The host is assigned an address from the private 850 192.168.x.x address range, in this case 192.168.0.55. The outbound 851 IP address provided to the home router is public and and belongs to 852 the my.isp.net domain; in this example the home router is assigned 853 192.0.2.75, which is also given the domain name 192-0-2- 854 75.my.isp.net. 856 In this example, several methods are not possible due to the 857 configuration of the devices and network. The DHCP server on the 858 home router does not support the LIS URI option, and a domain name is 859 not configured on the router. In addition to this, the UPnP service 860 on home router is disabled. Therefore, the host attempts these 861 methods and is unsuccessful. 863 The example first covers the unsuccessful attempts to discover the 864 LIS, followed by a successful application of DNS discovery based on 865 an address provided by a STUN server. In this situation, the STUN 866 server is provided by a Voice Service Provider (VSP) that the owner 867 of the host purchases a voice service from. The address of the STUN 868 server is configured on the host. The VSP is a separate entity on 869 the public Internet with no relation to the access network provider. 871 The sequence diagram below shows each of the failed attempts to 872 discover the LIS, followed by the successful discovery using the STUN 873 server, reverse DNS and the DNS discovery method. 875 +-------+ +--------+ +-----+ +-----+ +--------+ 876 | HOST | | HOME | | DNS | | LIS | | STUN | 877 | | | ROUTER | | | | | | SERVER | 878 +---+---+ +----+---+ +--+--+ +--+--+ +---+----+ 879 | | | | | 880 1 +--- DHCPINFORM -->| | | | 881 | | | | | 882 2 |<---- DHCPACK ----+ | | | 883 | | | | | 884 3 +------- DNS: PTR ------------->| | | 885 | 55.0.168.192.in-addr.arpa. | | | 886 | | | | | 887 4 |<------ DNS: no domain --------+ | | 888 | | | | | 889 5 +----- UPnP: ----->| | | | 890 | ssdp:discover | | | | 891 | | | | | 892 6 | (no response) | | | | 893 | | | | | 894 7 +---------------- STUN: Binding Request --------------->| 895 | | | | | 896 8 |<------- STUN: XOR-MAPPED-ADDRESS = (192.0.2.75) ------+ 897 | | | | | 898 9 +------- DNS: PTR ------------->| | | 899 | 75.2.0.192.in-addr.arpa. | | | 900 | | | | | 901 10 |<--- 192-0-2-205.my.isp.net ---+ | | 902 | | | | | 903 11 +--- DNS: NAPTR my.isp.net ---->| | | 904 | | | | | 905 12 |<--- https://lis.my.isp.net/ --+ | | 906 | | | | | 907 13 +-------- HELD: locationRequest ----------->| | 908 | | | | | 909 . . . . . 911 Figure 5: LIS Discovery Sequence 913 1. The host makes a DHCP request for the LIS URI option. To reduce 914 the overall time required in case the LIS URI is unknown, the 915 host also requests the domain name option. 917 2. The DHCP server (in the home router) responds but does not have 918 either datum. Therefore, the host is unable to use the DHCP 919 method, or use the domain name to perform U-NAPTR discovery. 921 3. The host then attempts reverse DNS based on its IP address 922 (192.168.0.55). The host makes a DNS PTR request for 923 "55.0.168.192.in-addr.arpa." 925 4. The DNS server has no knowledge of the private network segment 926 and so indicates that there is no such domain. 928 5. The host then must determine its address in a different network 929 segment. It first attempts to discover this using UPnP. The 930 host broadcasts a UPnP discovery message, attempting to locate a 931 UPnP capable device that supports the WANIPConnection profile. 933 6. There are no UPnP devices on the network and the UPnP discovery 934 message is unanswered. 936 7. The host contacts a STUN server, which is configured on the 937 host. It sends a Binding Request to the STUN server. 939 8. The STUN server responds to the Binding Request, including the 940 XOR-MAPPED-ADDRESS parameter. The host decodes this parameter, 941 which reveals the IP address of the home router: 192.0.2.75. 943 9. The host requests the domain name assigned to 192.0.2.75. It 944 makes a DNS PTR request to "75.2.0.192.in-addr.arpa." 946 10. The DNS server indicates that 192.0.2.75 is assigned the name 947 "192-0-2-75.my.isp.net." 949 11. The host removes the host part of the domain name and makes a 950 DNS NAPTR request for the domain "my.isp.net." 952 12. The DNS server provides all NAPTR records for the "my.isp.net." 953 domain. The host finds the record with a service tag of 954 "LIS:HELD" and retrieves the URI from the regexp field. The URI 955 of the LIS is found to be "https://lis.my.isp.net/". 957 13. The host sends a HELD "locationRequest" to the LIS. 959 Authors' Addresses 961 Martin Thomson 962 Andrew 963 PO Box U40 964 Wollongong University Campus, NSW 2500 965 AU 967 Phone: +61 2 4221 2915 968 Email: martin.thomson@andrew.com 969 URI: http://www.andrew.com/ 971 James Winterbottom 972 Andrew 973 PO Box U40 974 Wollongong University Campus, NSW 2500 975 AU 977 Phone: +61 2 4221 2938 978 Email: james.winterbottom@andrew.com 979 URI: http://www.andrew.com/ 981 Full Copyright Statement 983 Copyright (C) The IETF Trust (2008). 985 This document is subject to the rights, licenses and restrictions 986 contained in BCP 78, and except as set forth therein, the authors 987 retain all their rights. 989 This document and the information contained herein are provided on an 990 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 991 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 992 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 993 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 994 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 995 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 997 Intellectual Property 999 The IETF takes no position regarding the validity or scope of any 1000 Intellectual Property Rights or other rights that might be claimed to 1001 pertain to the implementation or use of the technology described in 1002 this document or the extent to which any license under such rights 1003 might or might not be available; nor does it represent that it has 1004 made any independent effort to identify any such rights. Information 1005 on the procedures with respect to rights in RFC documents can be 1006 found in BCP 78 and BCP 79. 1008 Copies of IPR disclosures made to the IETF Secretariat and any 1009 assurances of licenses to be made available, or the result of an 1010 attempt made to obtain a general license or permission for the use of 1011 such proprietary rights by implementers or users of this 1012 specification can be obtained from the IETF on-line IPR repository at 1013 http://www.ietf.org/ipr. 1015 The IETF invites any interested party to bring to its attention any 1016 copyrights, patents or patent applications, or other proprietary 1017 rights that may cover technology that may be required to implement 1018 this standard. Please address the information to the IETF at 1019 ietf-ipr@ietf.org.