idnits 2.17.1 draft-ietf-geopriv-res-gw-lis-discovery-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 1, 2011) is 4832 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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 (-09) exists of draft-ietf-sipcore-location-conveyance-04 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft Andrew Corporation 4 Intended status: Informational R. Bellis 5 Expires: August 5, 2011 Nominet UK 6 February 1, 2011 8 Location Information Server (LIS) Discovery using IP address and Reverse 9 DNS 10 draft-ietf-geopriv-res-gw-lis-discovery-00 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 August 5, 2011. 43 Copyright Notice 45 Copyright (c) 2011 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. Use of Discovery for Third Party Queries . . . . . . . . . 7 65 3.3. Additional and Optional Constraints . . . . . . . . . . . 7 66 4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 9 67 4.1. Identification of IP Addresses . . . . . . . . . . . . . . 9 68 4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 10 69 4.3. When To Use This Method . . . . . . . . . . . . . . . . . 10 70 4.4. Necessary Assumptions and Restrictions . . . . . . . . . . 11 71 4.5. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 11 72 4.6. Deployment Considerations . . . . . . . . . . . . . . . . 12 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. Use of Discovery for Third Party Queries 253 It is desirable that any discovery mechanism is capable of being used 254 by hosts outside of the access network. This facilitates third party 255 queries (see [I-D.ietf-geopriv-held-identity-extensions]) by enabling 256 identification of the appropriate LIS. 258 For example, in some jurisdictions, interim solutions for emergency 259 services require that a voice service provider (VSP) or public safety 260 answering point (PSAP) be able to request location information from 261 the access network provider. These architectures mandate third party 262 queries to accommodate calling devices that are unable to acquire 263 their own location information and subsequently convey 264 [I-D.ietf-sipcore-location-conveyance] that information within call 265 signalling. 267 This document therefore describes a method which may also be used by 268 third parties to discover the appropriate LIS based on the network 269 address of the Device. 271 Note that an access network that fully supports DHCP-based LIS 272 discovery [RFC5986] might not need to provide a secondary discovery 273 mechanism. However this method SHOULD be provided for the benefit of 274 third parties and for Devices that are unable to use DHCP-based LIS 275 discovery. 277 3.3. Additional and Optional Constraints 279 Certain other properties of residential gateways constrain the 280 potential solutions to this problem. 282 A network firewall function is often provided by residential gateways 283 as a security measure. Security features like intrusion detection 284 systems help protect users from attacks. Amongst these protections 285 is a port filter that prevents both inbound and outbound traffic on 286 certain TCP and UDP ports. Therefore, any solution needs to consider 287 the likelihood of traffic being blocked. 289 4. IP-based DNS Solution 291 LIS discovery [RFC5986] uses a DNS-based Dynamic Delegation Discovery 292 Service (DDDS) system as the basis of discovery. Input to this 293 process is a domain name. Use of DHCP for acquiring the domain name 294 is specified, but alternative methods of acquisition are permitted. 296 This document specifies a means for a device to discover several 297 alternative domain names that can be used as input to the DDDS 298 process. These domain names are based on the IP address of the 299 Device. Specifically, the domain names are a portion of the reverse 300 DNS trees - either the ".in-addr.arpa." or ".ip6.arpa." tree. 302 A Device might be reachable at one of a number of IP addresses. In 303 the process described, a Device first identifies each IP address that 304 it is potentially reachable from. From each of these addresses, the 305 Device then selects up to three domain names for use in discovery. 306 These domain names are then used as input to the DDDS process. 308 4.1. Identification of IP Addresses 310 A Device identifies a set of potential IP addresses that currently 311 result in packets being routed to it. These are ordered by 312 proximity, with those addresses that are used in adjacent network 313 segments being favoured over those used in public or remote networks. 314 The first addresses in the set are those that are assigned to local 315 network interfaces. 317 A Device can use the Session Traversal Utilities for NAT (STUN) 318 [RFC5389] to determine its public reflexive transport address. The 319 host uses the "Binding Request" message and the resulting 320 "XOR-MAPPED-ADDRESS" parameter that is returned in the response. 322 Alternative methods for determining other IP addresses MAY be used by 323 the host. Universal Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1] 324 and NAT Port Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] are 325 both able to provide the external address of a residential gateway 326 device when enabled. These as well as proprietary methods for 327 determining other addresses might also be available. Because there 328 is no assurance that these methods will be supported by any access 329 network these methods are not mandated. Note also that in some 330 cases, methods that rely on the view of the network from the 331 residential gateway device could reveal an address in a private 332 address range (see Section 4.4). 334 In many instances, the IP address produced might be from a private 335 address range. For instance, the address on a local network 336 interface could be from a private range allocated by the residential 337 gateway. In other cases, methods that rely on the view of the 338 network (UPnP, NAT-PMP) from the residential gateway device could 339 reveal an address in a private address range if the access network 340 also uses NAT. For a private IP address, the derived domain name is 341 only usable where the DNS server used contains data for the 342 corresponding private IP address range. 344 4.2. Domain Name Selection 346 The domain name selected for each resulting IP address is the name 347 that would be used for a reverse DNS lookup. The domain name derived 348 from an IP version 4 address is in the ".in-addr.arpa." tree and 349 follows the construction rules in Section 3.5 of [RFC1035]. The 350 domain name derived from an IP version 6 address is in the 351 ".ip6.arpa." tree and follows the construction rules in Section 2.5 352 of [RFC3596]. 354 Additional domain names are added to allow for a single record to 355 cover a larger set of addresses. If the search on the domain derived 356 from the full IP address does not produce a NAPTR record with the 357 desired service tag (e.g., "LIS:HELD"), a similar search is repeated 358 based on a shorter domain name, using a part of the IP address: 360 o For IP version 4, the resulting domain name SHOULD be shortened 361 successively by one and two labels and the query repeated. This 362 corresponds to a search on a /24 or /16 network prefix. This 363 allows for fewer DNS records in the case where a single access 364 network covering an entire /24 or /16 network is served by the 365 same LIS. 367 o For IP version 6, the resulting domain SHOULD be shortened 368 sucessively by 16, 20 and 24 labels and the query repeated. This 369 corresponds to a search on a /64, /48 or /32 network prefix. 371 DNS queries on other prefixes than those listed above SHOULD NOT be 372 performed to limit the number of DNS queries performed by Devices. 373 If no LIS is discovered by this method, no more than four U-NAPTR 374 resolutions are invoked for each IP address. 376 4.3. When To Use This Method 378 The DHCP method described in [RFC5986] SHOULD be attempted on all 379 local network interfaces before attempting this method. This method 380 is employed either because DHCP is unavailable, when the DHCP server 381 does not provide a value for the access network domain name option, 382 or if a request to the resulting LIS results in a HELD "notLocatable" 383 error or equivalent. 385 This method can also be used to facilitate third party queries, as 386 described in Section 3.2. Based on a known IP address, the LIS that 387 serves that address can be identified as long as the corresponding 388 NAPTR records are provided. 390 4.4. Necessary Assumptions and Restrictions 392 When used by a Device for LIS discovery this is an UNSAF application 393 and is subject to the limitations described in Section 7. 395 It is not necessary that the IP address used is unique to the Device, 396 only that the address can be somehow related to the Device or the 397 access network that serves the Device. This allows a degree of 398 flexibility in determining this value, although security 399 considerations (Section 6) might require that the address be verified 400 to prevent falsification. 402 Addresses from private address space [RFC1918] MAY be used as input 403 to this method. However, it is assumed that a DNS server with a view 404 of the same address space is used in order to provide the 405 corresponding DNS mappings; the public DNS does not contain useful 406 records for all possible address spaces. 408 This does not preclude the use of private address spaces; use of a 409 private address space in discovery can provide an access network 410 operator more granular control over discovery. This assumes that the 411 DNS server used in the U-NAPTR resolution is able to view the address 412 realm. Addresses from the public address space are more likely to be 413 able to be resolved by any DNS server. Thus, use of the public 414 reflexive transport addresses acquired from a STUN server provide 415 better chance of the DNS server being able to produce a usable 416 result. Therefore, access to a STUN server that is able to view 417 addresses from the public Internet is necessary. 419 This solution assumes that the public reflexive transport address 420 used by a Device is in some way controlled by their ISP, or some 421 other related party. This implies that the corresponding 422 ".in-addr.arpa." or ".ip6.arpa." record can be updated by that entity 423 to include a useful value for the LIS address. 425 4.5. Failure Modes 427 Successful use of private addresses relies on a DNS server that is 428 able to see the private address space; therefore, a means to 429 determine a public IP address is necessary. This document relies on 430 STUN to provide the Device with a public reflexive transport address. 431 Configuration of STUN server is necessary to ensure that this is 432 successful. 434 Alternative methods for discovering external IP addresses are 435 possible, including UPnP and NAT-PMP. However, these methods might 436 not be enabled on the residential gateway; thus, these methods cannot 437 be relied upon. 439 In cases where a virtual private network (VPN) or other tunnel is 440 used, the entity providing a public IP address might not be able to 441 provide the Device with location information. It is assumed that 442 this entity is able to identify this problem and indicate this to the 443 Device (using the "notLocatable" HELD error, or similar). This 444 problem is described in more detail in [RFC5985]. 446 4.6. Deployment Considerations 448 An access network provider SHOULD provide NAPTR records for each 449 public IP address that is used for Devices within the access network. 450 If the access network provider uses NAT, any DNS internal to that NAT 451 SHOULD also include records for the private address range. 453 NAPTR records can be provided for individual IP addresses. To limit 454 the proliferation of identical records, a single record can be placed 455 at a the higher nodes of the tree (corresponding to /24 and /16 for 456 IPv4; /64, /48 and /32 for IPv6). A record at a higher point in the 457 tree (those with a shorter prefix) applies to all addresses lower in 458 the tree (those with a longer prefix); records at the lower point 459 override those at higher points, allowing for exceptions to be 460 provided for at the lower point. 462 5. IANA Considerations 464 [RFC Editor: please remove this section prior to publication.] 466 This document has no IANA actions. 468 6. Security Considerations 470 The security considerations described in [RFC5986] apply to the 471 discovery process as a whole. The primary security concern is with 472 the potential for an attacker to impersonate a LIS. 474 The added ability for a third party to discover the identity of a LIS 475 does not add any concerns, since the identity of a LIS is considered 476 public information. 478 In addition to existing considerations, this document introduces 479 further security considerations relating to the identification of the 480 IP address. It is possible that an attacker could attempt to provide 481 a falsified IP addresses in an attempt to subvert the rest of the 482 process. 484 [RFC5389] describes attacks where an attacker is able to ensure that 485 a Device receives a falsified reflexive address. Even if the STUN 486 server is trusted, an attacker might be able to ensure that a 487 falsified address is provided to the Device. 489 This attack is an effective means of denial of service, or a means to 490 provide a deliberately misleading service. Notably, any LIS that is 491 identified based on a falsified IP address could still be a valid LIS 492 for the given IP address, just not one that is useful for providing 493 the Device with location information. In this case, the LIS provides 494 a HELD "notLocatable" error, or an equivalent. If the falsified IP 495 address is under the control of the attacker, it is possible that 496 misleading (but verifiable) DNS records could indicate a malicious 497 LIS that provides false location information. 499 In all cases of falsification, the best remedy is to perform some 500 form of independent verification of the result. No specific 501 mechanism is currently available to prevent attacks based on 502 falsification of reflexive addresses; it is suggested that Devices 503 attempt to independently verify that the reflexive transport address 504 provided is accurate. 506 Use of private address space effectively prevents use of the usual 507 set of trust anchors for DNSSEC. Only a DNS server that is able to 508 see the same private address space can provide useful records. A 509 Device that relies on DNS records in the private address space 510 portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use 511 an alternative trust anchor for these records or rely on other means 512 of ensuring the veracity of the DNS records. 514 7. IAB Considerations 516 The IAB has studied the problem of Unilateral Self-Address Fixing 517 (UNSAF) [RFC3424], which is the general process by which a client 518 attempts to determine its address in another realm on the other side 519 of a NAT through a collaborative protocol reflection mechanism, such 520 as STUN. 522 This section only applies to the use of this method of LIS discovery 523 by Devices and does not apply to its use for third-party LIS 524 discovery. 526 The IAB requires that protocol specifications that define UNSAF 527 mechanisms document a set of considerations. 529 1. Precise definition of a specific, limited-scope problem that is 530 to be solved with the UNSAF proposal. 532 Section 3 describes the limited scope of the problem addressed in 533 this document. 535 2. Description of an exit strategy/transition plan. 537 [RFC5986] describes behaviour that residential gateways require 538 in order for this short term solution to be rendered unnecessary. 539 When implementations of the recommendations in LIS discovery are 540 widely available, this UNSAF mechanism can be made obsolete. 542 3. Discussion of specific issues that may render systems more 543 "brittle". 545 A description of the necessary assumptions and limitations of 546 this solution are included in Section 4.4. 548 Use of STUN for discovery of a reflexive transport address is 549 inherently brittle in the presence of multiple NATs or address 550 realms. In particular, brittleness is added by the requirement 551 of using a DNS server that is able to view the address realm that 552 contains the IP address in question. If address realms use 553 overlapping addressing space, then there is a risk that the DNS 554 server provides information that is not useful to the Device. 556 4. Identify requirements for longer term, sound technical solutions; 557 contribute to the process of finding the right longer term 558 solution. 560 A longer term solution is already provided in [RFC5986]. 561 However, that solution relies on widespread deployment. The 562 UNSAF solution provided here is provided as an interim solution 563 that enables LIS access for Devices that are not able to benefit 564 from deployment of the recommendations in [RFC5986]. 566 5. Discussion of the impact of the noted practical issues with 567 existing deployed NATs and experience reports. 569 The UNSAF mechanism depends on the experience in deployment of 570 STUN [RFC5389]. On the whole, existing residential gateway 571 devices are able to provide access to STUN and DNS service 572 reliably, although regard should be given to the size of the DNS 573 response (see [RFC5625]). 575 8. References 577 8.1. Normative References 579 [RFC1035] Mockapetris, P., "Domain names - implementation and 580 specification", STD 13, RFC 1035, November 1987. 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, March 1997. 585 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 586 Self-Address Fixing (UNSAF) Across Network Address 587 Translation", RFC 3424, November 2002. 589 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 590 "DNS Extensions to Support IP Version 6", RFC 3596, 591 October 2003. 593 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 594 RFC 5985, September 2010. 596 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 597 Location Information Server (LIS)", RFC 5986, 598 September 2010. 600 8.2. Informative References 602 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 603 E. Lear, "Address Allocation for Private Internets", 604 BCP 5, RFC 1918, February 1996. 606 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 607 RFC 2131, March 1997. 609 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 610 and M. Carney, "Dynamic Host Configuration Protocol for 611 IPv6 (DHCPv6)", RFC 3315, July 2003. 613 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 614 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 616 [RFC4848] Daigle, L., "Domain-Based Application Service Location 617 Using URIs and the Dynamic Delegation Discovery Service 618 (DDDS)", RFC 4848, April 2007. 620 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 621 Emergency Context Resolution with Internet Technologies", 622 RFC 5012, January 2008. 624 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 625 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 626 October 2008. 628 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 629 Location Configuration Protocol: Problem Statement and 630 Requirements", RFC 5687, March 2010. 632 [I-D.ietf-sipcore-location-conveyance] 633 Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 634 for the Session Initiation Protocol", 635 draft-ietf-sipcore-location-conveyance-04 (work in 636 progress), October 2010. 638 [UPnP-IGD-WANIPConnection1] 639 UPnP Forum, "Internet Gateway Device (IGD) Standardized 640 Device Control Protocol V 1.0: WANIPConnection:1 Service 641 Template Version 1.01 For UPnP Version 1.0", DCP 05-001, 642 Nov 2001. 644 [I-D.cheshire-nat-pmp] 645 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 646 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 648 [I-D.ietf-geopriv-held-identity-extensions] 649 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 650 Barnes, "Use of Device Identity in HTTP-Enabled Location 651 Delivery (HELD)", 652 draft-ietf-geopriv-held-identity-extensions-06 (work in 653 progress), November 2010. 655 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 656 BCP 152, RFC 5625, August 2009. 658 Authors' Addresses 660 Martin Thomson 661 Andrew Corporation 662 PO Box U40 663 Wollongong University Campus, NSW 2500 664 AU 666 Phone: +61 2 4221 2915 667 Email: martin.thomson@andrew.com 668 URI: http://www.andrew.com/ 670 Ray Bellis 671 Nominet UK 672 Edmund Halley Road 673 Oxford OX4 4DQ 674 United Kingdom 676 Phone: +44 1865 332211 677 Email: ray.bellis@nominet.org.uk 678 URI: http://www.nominet.org.uk/