idnits 2.17.1 draft-ietf-geopriv-res-gw-lis-discovery-05.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 (April 5, 2013) is 4031 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'NAT' is mentioned on line 383, but not defined == Missing Reference: 'Gateway' is mentioned on line 389, 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) Summary: 0 errors (**), 0 flaws (~~), 4 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: October 7, 2013 Nominet UK 6 April 5, 2013 8 Location Information Server (LIS) Discovery using IP address and Reverse 9 DNS 10 draft-ietf-geopriv-res-gw-lis-discovery-05 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 October 7, 2013. 43 Copyright Notice 45 Copyright (c) 2013 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 The Reverse DNS 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 IP address on a Device requires some 95 automated process. This is particularly relevant when it is 96 considered that Devices might move between different access networks 97 served by different LISs. LIS Discovery [RFC5986] describes a method 98 that employs the Dynamic Host Configuration Protocol (DHCPv4 99 [RFC2131], DHCPv6 [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. Unfortunately in 103 most cases these functions effectively prevent the successful use of 104 DHCP for LIS discovery. 106 One 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 are not expected (and are likely 114 not able) to provide these 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 geographical area served by the residential gateway. 184 Given a small enough area, it is reasonable to delegate the 185 responsibility for providing Devices within the residential network 186 with location information to the ISP. The ISP is able to provide 187 location information that identifies the residence, which should be 188 adequate for a wide range of purposes. 190 A residential network that covers a larger geographical area might 191 require a dedicated LIS, a case that is outside the scope of this 192 document. 194 The goal of LIS discovery is to identify a LIS that is able to 195 provide the Device with accurate location information. In the 196 network topology described, this means identifying the LIS in the 197 access network. The residential gateway is a major obstacle in 198 achieving this goal. 200 3.1. Residential Gateway 202 A residential gateway can encompass several different functions 203 including: modem, Ethernet switch, wireless access point, router, 204 network address translation (NAT), DHCP server, DNS relay and 205 firewall. Of the common functions provided, the NAT function of a 206 residential gateway has the greatest impact on LIS discovery. 208 An ISP is typically parsimonious about their IP address allocations; 209 each customer is allocated a limited number of IP addresses. 210 Therefore, NAT is an extremely common function of gateways. NAT 211 enables the use of multiple Devices within the residential network. 212 However NAT also means that Devices within the residence are not 213 configured by the ISP directly. 215 When it comes to discovering a LIS, the fact that Devices are not 216 configured by the ISP causes a significant problem. Configuration is 217 the ideal method of conveying the information necessary for 218 discovery. Devices attached to residential gateways are usually 219 given a generic configuration that includes no information about the 220 ISP network. For instance, DNS configuration typically points to a 221 DNS relay on the gateway device. This approach ensures that the 222 local network served by the gateway is able to operate without a 223 connection to the ISP, but it also means that Devices are effectively 224 ignorant of the ISP network. 226 [RFC5986] describes several methods that can be applied by a 227 residential gateway to assist Devices in acquiring location 228 information. For instance, the residential gateway could forward LIS 229 address information to hosts within the network it serves. 230 Unfortunately, such an active involvement in the discovery process 231 only works for new residential gateway devices that implement those 232 recommendations. 234 Where residential gateways already exist, direct involvement of the 235 gateway in LIS discovery requires that the residential gateway be 236 updated or replaced. The cost of replacement is difficult to justify 237 to the owner of the gateway, especially when it is considered that 238 the gateway still fills its primary function: Internet access. 240 Existing residential gateways have proven to be quite reliable 241 devices, some operating continuously for many years without failure. 242 As a result, there are many operational gateways that are of a 243 considerable age, some well outside the period of manufacturer 244 support. Updating the software in such devices is not feasible in 245 many cases. Even if software updates were made available, many 246 residential gateways cannot be updated remotely, inevitably leading 247 to some proportion that is not updated. 249 This document therefore describes a method which can be used by 250 Devices to discover their LIS without any assistance from the 251 network. 253 3.2. Residential Gateway Security Features 255 A network firewall function is often provided by residential gateways 256 as a security measure. Security features like intrusion detection 257 systems help protect users from attacks. Amongst these protections 258 is a port filter that prevents both inbound and outbound traffic on 259 certain TCP and UDP ports. Therefore, any solution needs to consider 260 the likelihood of traffic being blocked. 262 4. IP-based DNS Solution 264 LIS discovery [RFC5986] uses a DNS-based Dynamic Delegation Discovery 265 Service (DDDS) system as the basis of discovery. Input to this 266 process is a domain name. Use of DHCP for acquiring the domain name 267 is specified, but alternative methods of acquisition are permitted. 269 This document specifies a means for a device to discover several 270 alternative domain names that can be used as input to the DDDS 271 process. These domain names are based on the IP address of the 272 Device. Specifically, the domain names are a portion of the reverse 273 DNS trees - either the ".in-addr.arpa." or ".ip6.arpa." tree. 275 A Device might be reachable at one of a number of IP addresses. In 276 the process described, a Device first identifies each IP address that 277 it is potentially reachable from. From each of these addresses, the 278 Device then selects up to three domain names for use in discovery. 279 These domain names are then used as input to the DDDS process. 281 4.1. Identification of IP Addresses 283 A Device identifies a set of potential IP addresses that currently 284 result in packets being routed to it. These are ordered by 285 proximity, with those addresses that are used in adjacent network 286 segments being favoured over those used in public or remote networks. 287 The first addresses in the set are those that are assigned to local 288 network interfaces. 290 A Device can use the Session Traversal Utilities for NAT (STUN) 291 [RFC5389] mechanism to determine its public reflexive transport 292 address. The host uses the "Binding Request" message and the 293 resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the 294 response. 296 Alternative methods for determining other IP addresses MAY be used by 297 the Device. Universal Plug and Play (UPnP) 298 [UPnP-IGD-WANIPConnection1] and NAT Port Mapping Protocol (NAT-PMP) 299 [I-D.cheshire-nat-pmp] are both able to provide the external address 300 of a residential gateway device when enabled. These as well as 301 proprietary methods for determining other addresses might also be 302 available. Because there is no assurance that these methods will be 303 supported by any access network these methods are not mandated. Note 304 also that in some cases, methods that rely on the view of the network 305 from the residential gateway device could reveal an address in a 306 private address range (see Section 4.5). 308 In many instances, the IP address produced might be from a private 309 address range. For instance, the address on a local network 310 interface could be from a private range allocated by the residential 311 gateway. In other cases, methods that rely on the view of the 312 network (UPnP, NAT-PMP) from the residential gateway device could 313 reveal an address in a private address range if the access network 314 also uses NAT. For a private IP address, the derived domain name is 315 only usable where the DNS server used contains data for the 316 corresponding private IP address range. 318 4.2. Domain Name Selection 320 The domain name selected for each resulting IP address is the name 321 that would be used for a reverse DNS lookup. The domain name derived 322 from an IP version 4 address is in the ".in-addr.arpa." tree and 323 follows the construction rules in Section 3.5 of [RFC1035]. The 324 domain name derived from an IP version 6 address is in the 325 ".ip6.arpa." tree and follows the construction rules in Section 2.5 326 of [RFC3596]. 328 Additional domain names are added to allow for a single DNS record to 329 cover a larger set of addresses. If the search on the domain derived 330 from the full IP address does not produce a NAPTR record with the 331 desired service tag (e.g., "LIS:HELD"), a similar search is repeated 332 based on a shorter domain name, using a part of the IP address: 334 o For IP version 4, the resulting domain name SHOULD be shortened 335 successively by one and two labels and the query repeated. This 336 corresponds to a search on a /24 or /16 network prefix. This 337 allows for fewer DNS records in the case where a single access 338 network covering an entire /24 or /16 network is served by the 339 same LIS. 341 o For IP version 6, the resulting domain SHOULD be shortened 342 sucessively by 16, 18, 20 and 24 labels and the query repeated. 343 This corresponds to a search on a /64, /56, /48 or /32 network 344 prefix. 346 DNS queries on other prefixes than those listed above SHOULD NOT be 347 performed in order to limit the number of DNS queries performed by 348 Devices. If no LIS is discovered by this method, the result will be 349 that no more than four U-NAPTR resolutions are invoked for each IP 350 address. 352 4.3. When To Use The Reverse DNS Method 354 The DHCP method described in [RFC5986] SHOULD be attempted on all 355 local network interfaces before attempting this method. This method 356 is employed either because DHCP is unavailable, when the DHCP server 357 does not provide a value for the access network domain name option, 358 or if a request to the resulting LIS results in a HELD "notLocatable" 359 error or equivalent. 361 4.4. Private Address Spaces 363 Addresses from a private use address space can be used as input to 364 this method. In many cases, this applies to addresses defined in 365 [RFC1918], though other address ranges could have limited 366 reachability where this advice also applies. This is only possible 367 if a DNS server with a view of the same address space is used. 368 Public DNS servers cannot provide useful records for private 369 addresses. 371 Using an address from a private space in discovery can provide a more 372 specific answer if the DNS server has records for that space. 373 Figure 2 shows a network configuration where addresses from an ISP 374 network could better indicate the correct LIS. Records in DNS B can 375 be provided for the 10.0.0.0/8 range, potentially dividing that range 376 so that a more local LIS can be selected. 378 _____ ________ 379 ( DNS ).....(/ \) Public 380 (__A__) (( Internet )) Address 381 (\________/) Space 382 | 383 [NAT] 384 _____ _____|_____ 385 ( DNS )....(/ \) Private 386 (__B__) (( ISP Network )) Address Space 387 (\___________/) (e.g. 10.0.0.0/8) 388 | 389 [Gateway] 390 ____|____ 391 (/ \) Private 392 (( Residence )) Address Space 393 (\_________/) (e.g. 192.168.0.0/16) 395 Figure 2: Address Space Example 397 The goal of automatic DNS configuration is usually to select a local 398 DNS, which suits configurations like the one shown. However, use of 399 public DNS or STUN servers means that a public IP address is likely 400 to be found. For STUN in particular, selecting a public server 401 minimizes the need for reconfiguration when a Device moves. Adding 402 records for the public address space used by an access network 403 ensures that the discovery process succeeds when a public address is 404 used. 406 4.5. Necessary Assumptions and Restrictions 408 When used by a Device for LIS discovery this is an UNSAF application 409 and is subject to the limitations described in Section 7. 411 It is not necessary that the IP address used is unique to the Device, 412 only that the address can be somehow related to the Device or the 413 access network that serves the Device. This allows a degree of 414 flexibility in determining this value, although security 415 considerations (Section 6) might require that the address be verified 416 to limit the chance of falsification. 418 This solution assumes that the public reflexive transport address 419 used by a Device is in some way controlled by the access network 420 provider, or some other related party. This implies that the 421 corresponding ".in-addr.arpa." or ".ip6.arpa." record can be updated 422 by that entity to include a useful value for the LIS address. 424 4.6. Failure Modes 426 Successful use of private addresses relies on a DNS server that has 427 records for the address space that is used. Using a public IP 428 address increases the likelihood of this. This document relies on 429 STUN to provide the Device with a public reflexive transport address. 430 Configuration of STUN server is necessary to ensure that this is 431 successful. 433 Alternative methods for discovering external IP addresses are 434 possible, including UPnP and NAT-PMP. These methods might not be 435 supported by the residential gateway and cannot be relied upon in all 436 cases. 438 In cases where a virtual private network (VPN) or other tunnel is 439 used, the entity providing a public IP address might not be able to 440 provide the Device with location information. It is assumed that 441 this entity is able to identify this problem and indicate this to the 442 Device (using the "notLocatable" HELD error, or similar). This 443 problem is described in more detail in [RFC5985]. 445 4.7. Deployment Considerations 447 An access network provider SHOULD provide NAPTR records for each 448 public IP address that is used for Devices within the access network. 449 If the access network provider uses NAT, any DNS server internal to 450 that NAT SHOULD also include records for the private address range. 452 NAPTR records can be provided for individual IP addresses. To limit 453 the proliferation of identical records, a single record can be placed 454 at a the higher nodes of the tree (corresponding to /24 and /16 for 455 IPv4; /64, /48 and /32 for IPv6). A record at a higher point in the 456 tree (those with a shorter prefix) applies to all addresses lower in 457 the tree (those with a longer prefix); records at the lower point 458 override those at higher points, thus allowing for exceptions to be 459 specified. 461 5. IANA Considerations 463 [RFC Editor: please remove this section prior to publication.] 465 This document has no IANA actions. 467 6. Security Considerations 469 The security considerations described in [RFC5986] apply to the 470 discovery process as a whole. The primary security concern is with 471 the potential for an attacker to impersonate a LIS. 473 The added ability for a third party to discover the identity of a LIS 474 does not add any concerns, since the identity of a LIS is considered 475 public information. 477 In addition to existing considerations, this document introduces 478 further security considerations relating to the identification of the 479 IP address. It is possible that an attacker could attempt to provide 480 a falsified IP addresses in an attempt to subvert the rest of the 481 process. 483 [RFC5389] describes attacks where an attacker is able to ensure that 484 a Device receives a falsified reflexive address. Even if the STUN 485 server is trusted, an attacker might be able to ensure that a 486 falsified address is provided to the Device. 488 This attack could result in an effective means of denial of service, 489 or a means to provide a deliberately misleading service. Notably, 490 any LIS that is identified based on a falsified IP address could 491 still be a valid LIS for the given IP address, just not one that is 492 useful for providing the Device with location information. In this 493 case, the LIS provides a HELD "notLocatable" error, or an equivalent. 494 If the falsified IP address is under the control of the attacker, it 495 is possible that misleading (but verifiable) DNS records could 496 indicate a malicious LIS that provides false location information. 498 In all cases of falsification, the best remedy is to perform some 499 form of independent verification of the result. No specific 500 mechanism is currently available to prevent attacks based on 501 falsification of reflexive addresses; it is suggested that Devices 502 attempt to independently verify that the reflexive transport address 503 provided is accurate. 505 Use of private address space effectively prevents use of the usual 506 set of trust anchors for DNSSEC. Only a DNS server that is able to 507 see the same private address space can provide useful records. A 508 Device that relies on DNS records in the private address space 509 portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use 510 an alternative trust anchor for these records or rely on other means 511 of ensuring the veracity of the DNS records. 513 7. IAB Considerations 515 The IAB has studied the problem of Unilateral Self-Address Fixing 516 (UNSAF) [RFC3424], which is the general process by which a client 517 attempts to determine its address in another realm on the other side 518 of a NAT through a collaborative protocol reflection mechanism, such 519 as STUN. 521 This section only applies to the use of this method of LIS discovery 522 by Devices and does not apply to its use for third-party LIS 523 discovery. 525 The IAB requires that protocol specifications that define UNSAF 526 mechanisms document a set of considerations. 528 1. Precise definition of a specific, limited-scope problem that is 529 to be solved with the UNSAF proposal. 531 Section 3 describes the limited scope of the problem addressed in 532 this document. 534 2. Description of an exit strategy/transition plan. 536 [RFC5986] describes behaviour that residential gateways require 537 in order for this short term solution to be rendered unnecessary. 538 When implementations of the recommendations in LIS discovery are 539 widely available, this UNSAF mechanism can be made obsolete. 541 3. Discussion of specific issues that may render systems more 542 "brittle". 544 A description of the necessary assumptions and limitations of 545 this solution are included in Section 4.5. 547 Use of STUN for discovery of a reflexive transport address is 548 inherently brittle in the presence of multiple NATs or address 549 realms. In particular, brittleness is added by the requirement 550 of using a DNS server that is able to view the address realm that 551 contains the IP address in question. If address realms use 552 overlapping addressing space, then there is a risk that the DNS 553 server provides information that is not useful to the Device. 555 4. Identify requirements for longer term, sound technical solutions; 556 contribute to the process of finding the right longer term 557 solution. 559 A longer term solution is already provided in [RFC5986]. 560 However, that solution relies on widespread deployment. The 561 UNSAF solution provided here is provided as an interim solution 562 that enables LIS access for Devices that are not able to benefit 563 from deployment of the recommendations in [RFC5986]. 565 5. Discussion of the impact of the noted practical issues with 566 existing deployed NATs and experience reports. 568 The UNSAF mechanism depends on the experience in deployment of 569 STUN [RFC5389]. On the whole, existing residential gateway 570 devices are able to provide access to STUN and DNS service 571 reliably, although regard should be given to the size of the DNS 572 response (see [RFC5625]). 574 8. References 576 8.1. Normative References 578 [RFC1035] Mockapetris, P., "Domain names - implementation and 579 specification", STD 13, RFC 1035, November 1987. 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, March 1997. 584 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 585 Self-Address Fixing (UNSAF) Across Network Address 586 Translation", RFC 3424, November 2002. 588 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 589 "DNS Extensions to Support IP Version 6", RFC 3596, 590 October 2003. 592 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 593 Location Information Server (LIS)", RFC 5986, 594 September 2010. 596 8.2. Informative References 598 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 599 E. Lear, "Address Allocation for Private Internets", 600 BCP 5, RFC 1918, February 1996. 602 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 603 RFC 2131, March 1997. 605 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 606 and M. Carney, "Dynamic Host Configuration Protocol for 607 IPv6 (DHCPv6)", RFC 3315, July 2003. 609 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 610 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 612 [RFC4848] Daigle, L., "Domain-Based Application Service Location 613 Using URIs and the Dynamic Delegation Discovery Service 614 (DDDS)", RFC 4848, April 2007. 616 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 617 Emergency Context Resolution with Internet Technologies", 618 RFC 5012, January 2008. 620 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 621 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 622 October 2008. 624 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 625 Location Configuration Protocol: Problem Statement and 626 Requirements", RFC 5687, March 2010. 628 [UPnP-IGD-WANIPConnection1] 629 UPnP Forum, "Internet Gateway Device (IGD) Standardized 630 Device Control Protocol V 1.0: WANIPConnection:1 Service 631 Template Version 1.01 For UPnP Version 1.0", DCP 05-001, 632 Nov 2001. 634 [I-D.cheshire-nat-pmp] 635 Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol 636 (NAT-PMP)", draft-cheshire-nat-pmp-07 (work in progress), 637 January 2013. 639 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 640 BCP 152, RFC 5625, August 2009. 642 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 643 RFC 5985, September 2010. 645 Authors' Addresses 647 Martin Thomson 648 Microsoft 649 3210 Porter Drive 650 Palo Alto, CA 94304 651 US 653 Phone: +1 650-353-1925 654 Email: martin.thomson@gmail.com 656 Ray Bellis 657 Nominet UK 658 Edmund Halley Road 659 Oxford OX4 4DQ 660 United Kingdom 662 Phone: +44 1865 332211 663 Email: ray.bellis@nominet.org.uk 664 URI: http://www.nominet.org.uk/