idnits 2.17.1 draft-ietf-geopriv-res-gw-lis-discovery-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 3 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 29, 2012) is 4410 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'NAT' is mentioned on line 379, but not defined == Missing Reference: 'Gateway' is mentioned on line 385, but not defined -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft Microsoft 4 Intended status: Informational R. Bellis 5 Expires: September 30, 2012 Nominet UK 6 March 29, 2012 8 Location Information Server (LIS) Discovery using IP address and Reverse 9 DNS 10 draft-ietf-geopriv-res-gw-lis-discovery-03 12 Abstract 14 The residential gateway is a device that has become an integral part 15 of home networking equipment. Discovering a Location Information 16 Server (LIS) is a necessary part of acquiring location information 17 for location-based services. However, discovering a LIS when a 18 residential gateway is present poses a configuration challenge, 19 requiring a method that is able to work around the obstacle presented 20 by the gateway. 22 This document describes a solution to this problem. The solution 23 provides alternative domain names as input to the LIS discovery 24 process based on the network addresses assigned to a Device. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 30, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions used in this document . . . . . . . . . . . . . . 4 62 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6 64 3.2. Residential Gateway Security Features . . . . . . . . . . 7 65 4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Identification of IP Addresses . . . . . . . . . . . . . . 8 67 4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9 68 4.3. When To Use This Method . . . . . . . . . . . . . . . . . 9 69 4.4. Private Address Spaces . . . . . . . . . . . . . . . . . . 10 70 4.5. Necessary Assumptions and Restrictions . . . . . . . . . . 11 71 4.6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 11 72 4.7. Deployment Considerations . . . . . . . . . . . . . . . . 11 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 15 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 A Location Information Server (LIS) is a service provided by an 84 access network. The LIS uses knowledge of the access network 85 topology and other information to generate location for Devices. 86 Devices within an access network are able to acquire location 87 information from a LIS. 89 The relationship between a Device and an access network might be 90 transient. Configuration of the correct LIS at the Device ensures 91 that accurate location information is available. Without location 92 information, some network services are not available. 94 The configuration of a LIS address on a Device requires some 95 automated configuration process. This is particularly relevant when 96 it is considered that Devices might move between different access 97 networks. LIS Discovery [RFC5986] describes a method that employs 98 the Dynamic Host Configuration Protocol (DHCPv4 [RFC2131], DHCPv6 99 [RFC3315]) as input to U-NAPTR [RFC4848] discovery. 101 A residential gateway, or home router, provides a range of networking 102 functions for Devices within the network it serves. In most cases, 103 these functions effectively prevent the successful use of DHCP for 104 LIS discovery. 106 The drawback with DHCP is that universal deployment of a new option 107 takes a considerable amount of time. Often, networking equipment 108 needs to be updated in order to support the new option. Of 109 particular concern are the millions of residential gateway devices 110 used to provide Internet access to homes and businesses. While 111 [RFC5986] describes functions that can be provided by residential 112 gateways to support LIS discovery, gateways built before the 113 publication of this specification do not (and cannot) provide these 114 functions. 116 This document explores the problem of configuring Devices with a LIS 117 address when a residential gateway is interposed between the Device 118 and access network. Section 3 defines the problem and Section 4 119 describes a method for determining a domain name that can be used for 120 discovery of the LIS. 122 In some cases, the solution described in this document is based on a 123 UNilateral Self-Address Fixing (UNSAF) [RFC3424] method. For those 124 cases, this solution is considered transitional until such time as 125 the recommendations for residential gateways in [RFC5986] are more 126 widely deployed. Considerations relating to UNSAF applications are 127 described in Section 7. 129 2. Conventions used in this document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 This document uses terminology established in [RFC3693] and 136 [RFC5012]. 138 3. Problem Statement 140 Figure 1 shows a simplified network topology for fixed wire-line 141 Internet access. This arrangement is typical when wired Internet 142 access is provided. The diagram shows two network segments: the 143 access network provided by an internet service provider (ISP), and 144 the residential network served by the residential gateway. 146 There are a number of variations on this arrangement, as documented 147 in Section 3.1 of [RFC5687]. In each of these variations the goal of 148 LIS discovery is to identify the LIS in the access network. 150 ________ 151 (/ \) 152 (( Internet )) 153 (\________/) 154 | 155 | 156 .- - -|- - - - - - - - - - - -. 157 ( | ) 158 ( +--------+ +-------+ ) 159 Access ( | Access |. . . .| LIS | ) 160 Network ( | Node | | | ) 161 (ISP) ( +--------+ +-------+ ) 162 ( \ \ ) 163 `- - - -\- - - - - - - -\- - -' 164 \ \ 165 \ | 166 .- - - - -\- - - - - - - + -. 167 ( \ | ) 168 ( +-------------+ : ) 169 ( | Residential | | ) 170 Residential ( | Gateway | : ) 171 Network ( +-------------+ | ) 172 ( / \ / ) 173 ( / \ / ) 174 ( +--------+ +--------+ ) 175 ( | Device | | Device | ) 176 ( +--------+ +--------+ ) 177 ( ) 178 `- - - - - - - - - - - - - -' 180 Figure 1: Simplified Network Topology 182 A particularly important characteristic of this arrangement is the 183 relatively small area served by the residential gateway. Given a 184 small enough area, it is reasonable to delegate the responsibility 185 for providing Devices within the residential network with location 186 information to the ISP. The ISP is able to provide location 187 information that identifies the residence, which should be adequate 188 for a wide range of purposes. 190 A residential network that covers a larger area might require a 191 dedicated LIS, a case that is outside the scope of this document. 193 The goal of LIS discovery is to identify a LIS that is able to 194 provide the Device with accurate location information. In the 195 network topology described, this means identifying the LIS in the 196 access network. The residential gateway is a major obstacle in 197 achieving this goal. 199 3.1. Residential Gateway 201 A residential gateway can encompass several different functions 202 including: modem, Ethernet switch, wireless access point, router, 203 network address translation (NAT), DHCP server, DNS relay and 204 firewall. Of the common functions provided, the NAT function of a 205 residential gateway has the greatest impact on LIS discovery. 207 An ISP is typically parsimonious about their IP address allocations; 208 each customer is allocated a limited number of IP addresses. 209 Therefore, NAT is an extremely common function of gateways. NAT 210 enables the use of multiple Devices within the residential network. 211 However NAT also means that Devices within the residence are not 212 configured by the ISP directly. 214 When it comes to discovering a LIS, the fact that Devices are not 215 configured by the ISP causes a significant problem. Configuration is 216 the ideal method of conveying the information necessary for 217 discovery. Devices attached to residential gateways are usually 218 given a generic configuration that includes no information about the 219 ISP network. For instance, DNS configuration typically points to a 220 DNS relay on the gateway device. This approach ensures that the 221 local network served by the gateway is able to operate without a 222 connection to the ISP, but it also means that Devices are effectively 223 ignorant of the ISP network. 225 [RFC5986] describes several methods that can be applied by a 226 residential gateway to assist Devices in acquiring location 227 information. For instance, the residential gateway could forward LIS 228 address information to hosts within the network it serves. Such an 229 active involvement in the discovery process only works for new 230 residential gateway devices that implement these recommendations. 232 Where residential gateways already exist, direct involvement of the 233 gateway in LIS discovery requires that the residential gateway be 234 updated or replaced. The cost of replacement is difficult to justify 235 to the owner of the gateway, especially when it is considered that 236 the gateway still fills its primary function: Internet access. 238 Existing residential gateways have proven to be quite reliable 239 devices, some operating continuously for many years without failure. 240 As a result, there are many operational gateways that are of a 241 considerable age, some well outside the period of manufacturer 242 support. Updating the software in such devices is not feasible in 243 many cases. Even if software updates were made available, many 244 residential gateways cannot be updated remotely, inevitably leading 245 to some proportion that is not updated. 247 This document therefore describes a method which can be used by 248 Devices to discover their LIS without any assistance from the 249 network. 251 3.2. Residential Gateway Security Features 253 A network firewall function is often provided by residential gateways 254 as a security measure. Security features like intrusion detection 255 systems help protect users from attacks. Amongst these protections 256 is a port filter that prevents both inbound and outbound traffic on 257 certain TCP and UDP ports. Therefore, any solution needs to consider 258 the likelihood of traffic being blocked. 260 4. IP-based DNS Solution 262 LIS discovery [RFC5986] uses a DNS-based Dynamic Delegation Discovery 263 Service (DDDS) system as the basis of discovery. Input to this 264 process is a domain name. Use of DHCP for acquiring the domain name 265 is specified, but alternative methods of acquisition are permitted. 267 This document specifies a means for a device to discover several 268 alternative domain names that can be used as input to the DDDS 269 process. These domain names are based on the IP address of the 270 Device. Specifically, the domain names are a portion of the reverse 271 DNS trees - either the ".in-addr.arpa." or ".ip6.arpa." tree. 273 A Device might be reachable at one of a number of IP addresses. In 274 the process described, a Device first identifies each IP address that 275 it is potentially reachable from. From each of these addresses, the 276 Device then selects up to three domain names for use in discovery. 277 These domain names are then used as input to the DDDS process. 279 4.1. Identification of IP Addresses 281 A Device identifies a set of potential IP addresses that currently 282 result in packets being routed to it. These are ordered by 283 proximity, with those addresses that are used in adjacent network 284 segments being favoured over those used in public or remote networks. 285 The first addresses in the set are those that are assigned to local 286 network interfaces. 288 A Device can use the Session Traversal Utilities for NAT (STUN) 289 [RFC5389] to determine its public reflexive transport address. The 290 host uses the "Binding Request" message and the resulting 291 "XOR-MAPPED-ADDRESS" parameter that is returned in the response. 293 Alternative methods for determining other IP addresses MAY be used by 294 the host. Universal Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1] 295 and NAT Port Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] are 296 both able to provide the external address of a residential gateway 297 device when enabled. These as well as proprietary methods for 298 determining other addresses might also be available. Because there 299 is no assurance that these methods will be supported by any access 300 network these methods are not mandated. Note also that in some 301 cases, methods that rely on the view of the network from the 302 residential gateway device could reveal an address in a private 303 address range (see Section 4.5). 305 In many instances, the IP address produced might be from a private 306 address range. For instance, the address on a local network 307 interface could be from a private range allocated by the residential 308 gateway. In other cases, methods that rely on the view of the 309 network (UPnP, NAT-PMP) from the residential gateway device could 310 reveal an address in a private address range if the access network 311 also uses NAT. For a private IP address, the derived domain name is 312 only usable where the DNS server used contains data for the 313 corresponding private IP address range. 315 4.2. Domain Name Selection 317 The domain name selected for each resulting IP address is the name 318 that would be used for a reverse DNS lookup. The domain name derived 319 from an IP version 4 address is in the ".in-addr.arpa." tree and 320 follows the construction rules in Section 3.5 of [RFC1035]. The 321 domain name derived from an IP version 6 address is in the 322 ".ip6.arpa." tree and follows the construction rules in Section 2.5 323 of [RFC3596]. 325 Additional domain names are added to allow for a single record to 326 cover a larger set of addresses. If the search on the domain derived 327 from the full IP address does not produce a NAPTR record with the 328 desired service tag (e.g., "LIS:HELD"), a similar search is repeated 329 based on a shorter domain name, using a part of the IP address: 331 o For IP version 4, the resulting domain name SHOULD be shortened 332 successively by one and two labels and the query repeated. This 333 corresponds to a search on a /24 or /16 network prefix. This 334 allows for fewer DNS records in the case where a single access 335 network covering an entire /24 or /16 network is served by the 336 same LIS. 338 o For IP version 6, the resulting domain SHOULD be shortened 339 sucessively by 16, 18, 20 and 24 labels and the query repeated. 340 This corresponds to a search on a /64, /56, /48 or /32 network 341 prefix. 343 DNS queries on other prefixes than those listed above SHOULD NOT be 344 performed to limit the number of DNS queries performed by Devices. 345 If no LIS is discovered by this method, no more than four U-NAPTR 346 resolutions are invoked for each IP address. 348 4.3. When To Use This Method 350 The DHCP method described in [RFC5986] SHOULD be attempted on all 351 local network interfaces before attempting this method. This method 352 is employed either because DHCP is unavailable, when the DHCP server 353 does not provide a value for the access network domain name option, 354 or if a request to the resulting LIS results in a HELD "notLocatable" 355 error or equivalent. 357 4.4. Private Address Spaces 359 Addresses from a private use address space can be used as input to 360 this method. In many cases, this applies to addresses defined in 361 [RFC1918], though other address ranges could have limited 362 reachability where this advice also applies. This is only possible 363 if a DNS server with a view of the same address space is used. 364 Public DNS servers cannot provide useful records for private 365 addresses. 367 Using an address from a private space in discovery can provide a more 368 specific answer if the DNS server has records for that space. 369 Figure 2 shows a network configuration where addresses from an ISP 370 network could better indicate the correct LIS. Records in DNS B can 371 be provided for the 10.0.0.0/8 range, potentially dividing that range 372 so that a more local LIS can be selected. 374 _____ ________ 375 ( DNS ).....(/ \) Public 376 (__A__) (( Internet )) Address 377 (\________/) Space 378 | 379 [NAT] 380 _____ _____|_____ 381 ( DNS )....(/ \) Private 382 (__B__) (( ISP Network )) Address Space 383 (\___________/) (e.g. 10.0.0.0/8) 384 | 385 [Gateway] 386 ____|____ 387 (/ \) Private 388 (( Residence )) Address Space 389 (\_________/) (e.g. 192.168.0.0/16) 391 Figure 2: Address Space Example 393 The goal of automatic DNS configuration is usually to select a local 394 DNS, which suits configurations like the one shown. However, use of 395 public DNS or STUN servers means that a public IP address is likely 396 to be found. For STUN in particular, selecting a public server 397 minimizes the need for reconfiguration when a Device moves. Adding 398 records for the public address space used by an access network 399 ensures that the discovery process succeeds when a public address is 400 used. 402 4.5. Necessary Assumptions and Restrictions 404 When used by a Device for LIS discovery this is an UNSAF application 405 and is subject to the limitations described in Section 7. 407 It is not necessary that the IP address used is unique to the Device, 408 only that the address can be somehow related to the Device or the 409 access network that serves the Device. This allows a degree of 410 flexibility in determining this value, although security 411 considerations (Section 6) might require that the address be verified 412 to limit the chance of falsification. 414 This solution assumes that the public reflexive transport address 415 used by a Device is in some way controlled by the access network 416 provider, or some other related party. This implies that the 417 corresponding ".in-addr.arpa." or ".ip6.arpa." record can be updated 418 by that entity to include a useful value for the LIS address. 420 4.6. Failure Modes 422 Successful use of private addresses relies on a DNS server that has 423 records for the address space that is used. Using a public IP 424 address increases the likelihood of this. This document relies on 425 STUN to provide the Device with a public reflexive transport address. 426 Configuration of STUN server is necessary to ensure that this is 427 successful. 429 Alternative methods for discovering external IP addresses are 430 possible, including UPnP and NAT-PMP. These methods might not be 431 supported by the residential gateway and cannot be relied upon in all 432 cases. 434 In cases where a virtual private network (VPN) or other tunnel is 435 used, the entity providing a public IP address might not be able to 436 provide the Device with location information. It is assumed that 437 this entity is able to identify this problem and indicate this to the 438 Device (using the "notLocatable" HELD error, or similar). This 439 problem is described in more detail in [RFC5985]. 441 4.7. Deployment Considerations 443 An access network provider SHOULD provide NAPTR records for each 444 public IP address that is used for Devices within the access network. 445 If the access network provider uses NAT, any DNS internal to that NAT 446 SHOULD also include records for the private address range. 448 NAPTR records can be provided for individual IP addresses. To limit 449 the proliferation of identical records, a single record can be placed 450 at a the higher nodes of the tree (corresponding to /24 and /16 for 451 IPv4; /64, /48 and /32 for IPv6). A record at a higher point in the 452 tree (those with a shorter prefix) applies to all addresses lower in 453 the tree (those with a longer prefix); records at the lower point 454 override those at higher points, allowing for exceptions to be 455 provided for at the lower point. 457 5. IANA Considerations 459 [RFC Editor: please remove this section prior to publication.] 461 This document has no IANA actions. 463 6. Security Considerations 465 The security considerations described in [RFC5986] apply to the 466 discovery process as a whole. The primary security concern is with 467 the potential for an attacker to impersonate a LIS. 469 The added ability for a third party to discover the identity of a LIS 470 does not add any concerns, since the identity of a LIS is considered 471 public information. 473 In addition to existing considerations, this document introduces 474 further security considerations relating to the identification of the 475 IP address. It is possible that an attacker could attempt to provide 476 a falsified IP addresses in an attempt to subvert the rest of the 477 process. 479 [RFC5389] describes attacks where an attacker is able to ensure that 480 a Device receives a falsified reflexive address. Even if the STUN 481 server is trusted, an attacker might be able to ensure that a 482 falsified address is provided to the Device. 484 This attack is an effective means of denial of service, or a means to 485 provide a deliberately misleading service. Notably, any LIS that is 486 identified based on a falsified IP address could still be a valid LIS 487 for the given IP address, just not one that is useful for providing 488 the Device with location information. In this case, the LIS provides 489 a HELD "notLocatable" error, or an equivalent. If the falsified IP 490 address is under the control of the attacker, it is possible that 491 misleading (but verifiable) DNS records could indicate a malicious 492 LIS that provides false location information. 494 In all cases of falsification, the best remedy is to perform some 495 form of independent verification of the result. No specific 496 mechanism is currently available to prevent attacks based on 497 falsification of reflexive addresses; it is suggested that Devices 498 attempt to independently verify that the reflexive transport address 499 provided is accurate. 501 Use of private address space effectively prevents use of the usual 502 set of trust anchors for DNSSEC. Only a DNS server that is able to 503 see the same private address space can provide useful records. A 504 Device that relies on DNS records in the private address space 505 portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use 506 an alternative trust anchor for these records or rely on other means 507 of ensuring the veracity of the DNS records. 509 7. IAB Considerations 511 The IAB has studied the problem of Unilateral Self-Address Fixing 512 (UNSAF) [RFC3424], which is the general process by which a client 513 attempts to determine its address in another realm on the other side 514 of a NAT through a collaborative protocol reflection mechanism, such 515 as STUN. 517 This section only applies to the use of this method of LIS discovery 518 by Devices and does not apply to its use for third-party LIS 519 discovery. 521 The IAB requires that protocol specifications that define UNSAF 522 mechanisms document a set of considerations. 524 1. Precise definition of a specific, limited-scope problem that is 525 to be solved with the UNSAF proposal. 527 Section 3 describes the limited scope of the problem addressed in 528 this document. 530 2. Description of an exit strategy/transition plan. 532 [RFC5986] describes behaviour that residential gateways require 533 in order for this short term solution to be rendered unnecessary. 534 When implementations of the recommendations in LIS discovery are 535 widely available, this UNSAF mechanism can be made obsolete. 537 3. Discussion of specific issues that may render systems more 538 "brittle". 540 A description of the necessary assumptions and limitations of 541 this solution are included in Section 4.5. 543 Use of STUN for discovery of a reflexive transport address is 544 inherently brittle in the presence of multiple NATs or address 545 realms. In particular, brittleness is added by the requirement 546 of using a DNS server that is able to view the address realm that 547 contains the IP address in question. If address realms use 548 overlapping addressing space, then there is a risk that the DNS 549 server provides information that is not useful to the Device. 551 4. Identify requirements for longer term, sound technical solutions; 552 contribute to the process of finding the right longer term 553 solution. 555 A longer term solution is already provided in [RFC5986]. 556 However, that solution relies on widespread deployment. The 557 UNSAF solution provided here is provided as an interim solution 558 that enables LIS access for Devices that are not able to benefit 559 from deployment of the recommendations in [RFC5986]. 561 5. Discussion of the impact of the noted practical issues with 562 existing deployed NATs and experience reports. 564 The UNSAF mechanism depends on the experience in deployment of 565 STUN [RFC5389]. On the whole, existing residential gateway 566 devices are able to provide access to STUN and DNS service 567 reliably, although regard should be given to the size of the DNS 568 response (see [RFC5625]). 570 8. References 572 8.1. Normative References 574 [RFC1035] Mockapetris, P., "Domain names - implementation and 575 specification", STD 13, RFC 1035, November 1987. 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, March 1997. 580 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 581 Self-Address Fixing (UNSAF) Across Network Address 582 Translation", RFC 3424, November 2002. 584 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 585 "DNS Extensions to Support IP Version 6", RFC 3596, 586 October 2003. 588 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 589 RFC 5985, September 2010. 591 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 592 Location Information Server (LIS)", RFC 5986, 593 September 2010. 595 8.2. Informative References 597 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 598 E. Lear, "Address Allocation for Private Internets", 599 BCP 5, RFC 1918, February 1996. 601 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 602 RFC 2131, March 1997. 604 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 605 and M. Carney, "Dynamic Host Configuration Protocol for 606 IPv6 (DHCPv6)", RFC 3315, July 2003. 608 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 609 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 611 [RFC4848] Daigle, L., "Domain-Based Application Service Location 612 Using URIs and the Dynamic Delegation Discovery Service 613 (DDDS)", RFC 4848, April 2007. 615 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 616 Emergency Context Resolution with Internet Technologies", 617 RFC 5012, January 2008. 619 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 620 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 621 October 2008. 623 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 624 Location Configuration Protocol: Problem Statement and 625 Requirements", RFC 5687, March 2010. 627 [UPnP-IGD-WANIPConnection1] 628 UPnP Forum, "Internet Gateway Device (IGD) Standardized 629 Device Control Protocol V 1.0: WANIPConnection:1 Service 630 Template Version 1.01 For UPnP Version 1.0", DCP 05-001, 631 Nov 2001. 633 [I-D.cheshire-nat-pmp] 634 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 635 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 637 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 638 BCP 152, RFC 5625, August 2009. 640 Authors' Addresses 642 Martin Thomson 643 Microsoft 644 3210 Porter Drive 645 Palo Alto, CA 94304 646 US 648 Phone: +1 650-353-1925 649 Email: martin.thomson@gmail.com 651 Ray Bellis 652 Nominet UK 653 Edmund Halley Road 654 Oxford OX4 4DQ 655 United Kingdom 657 Phone: +44 1865 332211 658 Email: ray.bellis@nominet.org.uk 659 URI: http://www.nominet.org.uk/