One document matched: draft-thomson-geopriv-res-gw-lis-discovery-01.txt
Differences from draft-thomson-geopriv-res-gw-lis-discovery-00.txt
GEOPRIV M. Thomson
Internet-Draft Andrew Corporation
Intended status: Informational R. Bellis
Expires: December 5, 2009 Nominet UK
June 3, 2009
Location Information Server (LIS) Discovery From Behind Residential
Gateways
draft-thomson-geopriv-res-gw-lis-discovery-01
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 5, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The residential gateway is an device that has become an integral part
Thomson & Bellis Expires December 5, 2009 [Page 1]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
of home networking equipment. Discovering a Location Information
Server (LIS) is a necessary part of aquiring location information for
location-based services. However, discovering a LIS when a
residential gateway is present poses a configuration challenge,
requiring a method that is able to work around the obstacle presented
by the gateway.
This document describes an interim UNilateral Self-Address Fixing
(UNSAF) solution to this problem. The solution provides alternative
domain names as input to the LIS discovery process based on the IP
addresses assigned to a Device.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6
3.2. Use of Discovery for Third Party Queries . . . . . . . . . 7
3.3. Additional and Optional Constraints . . . . . . . . . . . 7
4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 8
4.1. Identification of IP Addresses . . . . . . . . . . . . . . 8
4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9
4.3. When To Use This Method . . . . . . . . . . . . . . . . . 10
4.4. Necessary Assumptions and Restrictions . . . . . . . . . . 10
4.5. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Deployment Considerations . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Thomson & Bellis Expires December 5, 2009 [Page 2]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
1. Introduction
A Location Information Server (LIS) is a service provided by an
access network. The LIS uses knowledge of the access network
topology and other information to generate location for Devices.
Devices within an access network are able to acquire location
information from a LIS.
The relationship between a Device and an access network might be
transient. Configuration of the correct LIS at the Device ensures
that accurate location information is available. Without location
information, some network services are not available.
The configuration of a LIS address on a Device requires some
automated configuration process. This is particularly relevant when
it is considered that Devices might move between different access
networks. LIS Discovery [I-D.ietf-geopriv-lis-discovery] describes a
method that employs the Dynamic Host Configuration Protocol (DHCPv4
[RFC2131], DHCPv6 [RFC3315]) as input to U-NAPTR ([RFC4848])
discovery.
A residential gateway, or home router, provides a range of networking
functions for Devices within the network it serves. In most cases,
these functions effectively prevent the successful use of DHCP for
LIS discovery.
The drawback with DHCP is that universal deployment of a new option
takes a considerable amount of time. Often, networking equipment
needs to be updated in order to support the new option. Of
particular concern are the millions of residential gateway devices
used to provide Internet access to homes and businesses. While
[I-D.ietf-geopriv-lis-discovery] describes functions that can be
provided by residential gateways to support LIS discovery, gateways
built before the publication of this specification do not (and
cannot) provide these functions.
This document explores the problem of configuring Devices with a LIS
address when a residential gateway is interposed between the Device
and access network. Section 3 defines the problem and Section 4
describes a method for determining a domain name that can be used for
discovery of the LIS.
The solution described in this document is based on an UNilateral
Self-Address Fixing (UNSAF) [RFC3424] method. As such, this solution
is considered transitional until such time as the recommendations for
residential gateways in [I-D.ietf-geopriv-lis-discovery] are more
widely deployed. Considerations relating to UNSAF applications are
described in Section 7.
Thomson & Bellis Expires December 5, 2009 [Page 3]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses terminology established in [RFC3693] and
[I-D.ietf-ecrit-requirements].
3. Problem Statement
Figure 1 shows a simplified network topology for fixed wireline
Internet access. This arrangement is typical when wired Internet
access is provided. The diagram shows two network segments: the
access network provided by an internet service provider (ISP), and
the residential network served by the residential gateway.
There are a number of variations on this arrangement, as documented
in Section 3.1 of [I-D.ietf-geopriv-l7-lcp-ps]. In each of these
variations, the consequences are the same: the goal of LIS discovery
in this scenario is to identify the LIS in the access network.
Thomson & Bellis Expires December 5, 2009 [Page 4]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
________
(/ \)
(( Internet ))
(\________/)
|
|
.- - -|- - - - - - - - - - - -.
( | )
( +--------+ +-------+ )
Access ( | Access |. . . .| LIS | )
Network ( | Node | | | )
(ISP) ( +--------+ +-------+ )
( \ \ )
`- - - -\- - - - - - - -\- - -'
\ \
\ |
.- - - - -\- - - - - - - + -.
( \ | )
( +-------------+ : )
( | Residential | | )
Residential ( | Gateway | : )
Network ( +-------------+ | )
( / \ / )
( / \ / )
( +--------+ +--------+ )
( | Device | | Device | )
( +--------+ +--------+ )
( )
`- - - - - - - - - - - - - -'
Figure 1: Simplified Network Topology
A particularly important characteristic of this arrangement is the
relatively small area served by the residential gateway. Given a
small enough area, it is reasonable to delegate the responsibility
for providing Devices within the residential network with location
information to the ISP. The ISP is able to provide location
information that identifies the residence, which could be adequate
for a range of purposes.
A residential network that covers a larger area might require a
dedicated LIS, a case that is outside the scope of this document.
The goal of LIS discovery is to identify a LIS that is able to
provide the Device with accurate location information. In the
network topology described, this means identifying the LIS in the
access network. The residential gateway is a major obstacle in
achieving this goal.
Thomson & Bellis Expires December 5, 2009 [Page 5]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
R1. An alternative method for LIS discovery MUST be provided such
that a Device is able to successfully discover a LIS when a
residential gateway exists between the Device and the access
network providing the LIS.
3.1. Residential Gateway
A residential gateway can encompass several different functions
including: modem, Ethernet switch, wireless access point, router,
network address translation (NAT), DHCP server, DNS relay and
firewall. Of the common functions provided, the NAT function of a
residential gateway has the greatest impact on LIS discovery.
An ISP is typically parsimonious about their IP address allocations;
each customer is allocated a limited number of IP addresses.
Therefore, NAT is an extremely common function of gateways. NAT
enables the use of multiple Devices within the residential network
and it could be argued that such widespread use of NAT has delayed
the inevitable exhaustion of the IPv4 address pool. However, NAT
also means that Devices within the residence are not configured by
the ISP directly.
When it comes to discovering a LIS, the fact that Devices are not
configured by the ISP causes a significant problem. Configuration is
the ideal method of conveying the information necessary for
discovery. Devices attached to residential gateways are usually
given a generic configuration that includes no information about the
ISP network. For instance, DNS configuration typically points to a
DNS relay on the gateway device. This approach ensures that the
local network served by the gateway is able to operate without a
connectionto the ISP, but it also means that Devices are effectively
ignorant of the ISP network.
[I-D.ietf-geopriv-lis-discovery] describes several methods that can
be applied by a residential gateway to assist Devices in acquiring
location information. For instance, the residential gateway could
forward LIS address information to hosts within the network it
serves. Such an active involvement in the discovery process only
works for new residential gateway devices that implement these
recommendations.
Where residential gateways already exist, direct involvement of the
gateway in LIS discovery requires that the residential gateway be
updated or replaced. The cost of replacement is difficult to justify
to the owner of the gateway. Especially when it is considered that
the gateway still fills its primary function: Internet access.
Existing residential gateways have proven to be quite reliable
Thomson & Bellis Expires December 5, 2009 [Page 6]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
devices, some operating continuously for many years without failure.
As a result, there are many operational gateways that are a
considerable age, some well outside the period of manufacturer
support. Updating the software in such devices is not feasible in
many cases. Even if software updates were made available, many
residential gateways cannot be updated remotely, inevitably leading
to some proportion that is not updated.
R2. The alternative LIS discovery method MUST be able to
successfully discover a LIS without any assistance from a
residential gateway.
3.2. Use of Discovery for Third Party Queries
It is desirable that any discovery mechanism is able to be used by
hosts outside of the access network. This facilitates third party
queries (see [I-D.winterbottom-geopriv-held-identity-extensions]) by
enabling identification of the correct LIS to ask.
In some jurisdictions, interim solutions for emergency services
require that a voice service provider (VSP) or public safety
answering point (PSAP) be able to request location information from
the access network provider. These architectures mandate third party
queries to accomodate calling devices that are unable to acquire
location information and convey ([I-D.ietf-sip-location-conveyance])
that information with call signalling.
Additional methods for third parties to determine the correct LIS to
query are possible. Within the confines of a particular
jurisdiction, it is more feasible to coordinate such things as
national ISP databases, which are one potential solution to this
problem. However, if a discovery solution also enabled third party
discovery, that would be a distinct advantage of that solution.
R3. The alternative LIS discovery method MAY provide a means for a
third party to discover a LIS based on the identity of a
particular device.
A network that is able to guarantee availability of DHCP does not
need to provide a secondary discovery capability for the benefit of
the Devices within the network. However, if third party requests are
desired, the supplementary discovery method could still be provided
for the benefit of those third parties.
3.3. Additional and Optional Constraints
Certain other properties of residential gateways constrain the
potential solutions to this problem.
Thomson & Bellis Expires December 5, 2009 [Page 7]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
Operation of a network firewall function is often provided by
residential gateways as a security measure. Security features like
intrusion detection systems help protect users from attacks.
Amoungst these protections is a port filter that prevents both
inbound and outbound traffic on certain TCP and UDP ports.
Therefore, any solution needs to consider the likelihood of traffic
being blocked.
4. IP-based DNS Solution
LIS discovery [I-D.ietf-geopriv-lis-discovery] uses a DNS-based
Dynamic Delegation Discovery Service (DDDS) system as the basis of
discovery. Input to this process is a domain name. Use of DHCP for
acquiring the domain name is specified, but alternative methods of
acquisition are permitted.
This document specifies a means for a device to discover several
alternative domain names that can be used as input to the DDDS
process. These domain names are based on the IP address of the
Device. Specifically, the domain names are a portion of the reverse
DNS trees - either the ".in-addr.arpa." or ".ip6.arpa." tree.
A Device might be reachable at one of a number of IP addresses. In
the process described, a Device first identifies each IP address that
it is potentially reachable from. From each of these addresses, the
Device then selects up to three domain names for use in discovery.
These domain names are then used as input to the DDDS process.
4.1. Identification of IP Addresses
A Device identifies a set of potential IP addresses that currently
result in packets being routed to it. These are ordered by
proximity, with those addresses that are used in adjacent network
segments being favoured over those used in public or remote networks.
The first addresses in the set are those that are assigned to local
network interfaces.
A Device can use the Session Traversal Utilities for NAT (STUN)
[RFC5389] to determine its public reflexive transport address. The
host uses the "Binding Request" message and the resulting
"XOR-MAPPED-ADDRESS" parameter that is returned in the response.
Alternative methods for determining other IP addresses MAY be used by
the host. Universal Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1]
and NAT Port Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp] are
both able to provide the external address of a residential gateway
device when enabled. These as well as proprietary methods for
determining other addresses might also be available. Because there
Thomson & Bellis Expires December 5, 2009 [Page 8]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
is no assurance that these methods will be supported by any access
network these methods are not mandated. Note also that in some
cases, methods that rely on the view of the network from the
residential gateway device could reveal an address in a private
address range (see Section 4.4).
In many instances, the IP address produced might be from a private
address range. For instance, the address on a local network
interface could be from a private range allocated by the residential
gateway. In other cases, methods that rely on the view of the
network (UPnP, NAT-PMP) from the residential gateway device could
reveal an address in a private address range if the access network
also uses NAT. For a private IP address, the derived domain name is
only usable where the DNS server used contains data for the
corresponding private IP address range.
4.2. Domain Name Selection
The domain name selected for each resulting IP address is the name
that would be used for a reverse DNS lookup. The domain name derived
from an IP version 4 address is in the ".in-addr.arpa." tree and
follows the construction rules in Section 3.5 of [RFC1035]. The
domain name derived from an IP version 6 address is in the
".ip6.arpa." tree and follows the construction rules in Section 2.5
of [RFC3596].
Additional domain names are added to allow for a single record to
cover a larger set of addresses. If the search on the domain derived
from the full IP address does not produce a NAPTR record with the
desired service tag (e.g., "LIS:HELD"), a similar search is repeated
based on a shorter domain name, using a part of the IP address:
o For IP version 4, the resulting domain name SHOULD be shortened by
one or two labels and the query repeated. This corresponds to a
search on a /24 or /16 network prefix. This allows for fewer DNS
records in the case where a single access network covering an
entire /24 or /16 network is served by the same LIS.
o For IP version 6, the resulting domain SHOULD be shortened by
either 16 or 20 labels and the query repeated. This corresponds
to a search on a /64 or /48 network prefix.
DNS queries on other prefixes than those listed above SHOULD NOT be
performed to limit the number of DNS queries performed by Devices.
If no LIS is discovered by this method, three U-NAPTR resolutions are
invoked for each IP address.
Thomson & Bellis Expires December 5, 2009 [Page 9]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
4.3. When To Use This Method
The DHCP method described in [I-D.ietf-geopriv-lis-discovery] SHOULD
be attempted on all local network interfaces before attempting this
method. This method is employed either because DHCP is unavailable,
when the DHCP server does not provide a value for the access network
domain name option, or if a request to the resulting LIS results in a
HELD "notLocatable" error or equivalent.
This method can also be used to facilitate third party queries, as
described in Section 3.2. Based on a known IP address, the LIS that
serves that address can be identified as long as the corresponding
NAPTR records are provided.
4.4. Necessary Assumptions and Restrictions
This is an UNSAF application and is subject to the limitations
described in [RFC3424].
It is not necessary that the IP address used is unique to the Device,
only that the address can be somehow related to the Device or the
access network that serves the Device. This allows a degree of
flexibility in determining this value, although security
considerations (Section 6) might require that the address be verified
to prevent falsification.
Addresses from private address space [RFC1918] MAY be used as input
to this method. However, it is assumed that a DNS server with a view
of the same address realm is used in order to provide the
corresponding DNS mappings; the public DNS does not contain useful
records for all possible address realms.
This does not preclude the use of private address spaces; use of a
private address space in discovery can provide an access network
operator more granular control over discovery. This assumes that the
DNS server used in the U-NAPTR resolution is able to view the address
realm. Addresses from the public address space are more likely to be
able to be resolved by any DNS server. Thus, use of the public
reflexive transport addresses acquired from a STUN server provide
better chance of the DNS server being able to produce a usable
result. Ideally, the address realm Therefore, access to a STUN
server that is able to view addresses from the public Internet is
necessary.
This solution assumes that the public reflexive transport address
used by a Device is in some way controlled by their ISP, or some
other related party. This imples that the corresponding
".in-addr.arpa." or ".ip6.arpa." record can be updated by that entity
Thomson & Bellis Expires December 5, 2009 [Page 10]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
to include a useful value for the LIS address.
4.5. Failure Modes
Successful use of private addresses relies on a DNS server that is
able to see the private address space; therefore, a means to
determine a public IP address is necessary. This document relies on
STUN to provide the Device with a public reflexive transport address.
Configuration of STUN server is necessary to ensure that this is
successful.
Alternative methods for discovering external IP addresses are
possible, including UPnP and NAT-PMP. However, these methods might
not be enabled on the residential gateway; thus, these methods cannot
be relied upon.
In cases where a virtual private network (VPN) or other tunnel is
used, the entity providing a public IP address might not be able to
provide the Device with location information. It is assumed that
this entity is able to identify this problem and indicate this to the
Device (using the "notLocatable" HELD error, or similar). This
problem is described in more detail in
[I-D.ietf-geopriv-http-location-delivery].
4.6. Deployment Considerations
An access network provider SHOULD provide NAPTR records for each
public IP address that is used for Devices within the access network.
If the access network provider uses NAT, any DNS internal to that NAT
SHOULD also include records for the private address range.
NAPTR records can be provided for individual IP addresses. To limit
the proliferation of identical records, a single record can be placed
at a the higher nodes of the tree (corresponding to /24 and /16 for
IPv4, /64 abnd /48 for IPv6). A record at a higher point in the tree
(those with a shorter prefix) applies to all addresses lower in the
tree (those with a longer prefix); records at the lower point
override those at higher points, allowing for exceptions to be
provided for at the lower point.
5. IANA Considerations
[RFC Editor: please remove this section prior to publication.]
This document has no IANA actions.
Thomson & Bellis Expires December 5, 2009 [Page 11]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
6. Security Considerations
The security considerations described in
[I-D.ietf-geopriv-lis-discovery] apply to the discovery process as a
whole. In addition to those considerations, this document introduces
further security considerations relating to the identification of the
IP address. It is possible that an attacker could attempt to mislead
a Device about its IP addresses in an attempt to subvert the rest of
the process.
[RFC5389] describes attacks where an attacker is able to ensure that
a Device receives a falsified reflexive address. Even if the STUN
server is trusted, an attacker might be able to ensure that a
falsified address is provided to the Device.
This attack is an effective means of denial of service, or a means to
provide a deliberately misleading service. Notably, any LIS that is
identified based on a falsified IP address could still be a valid LIS
for the given IP address, just not one that is useful for providing
the Device with location information. In this case, the LIS provides
a HELD "notLocatable" error, or an equivalent. If the falsified IP
address is under the control of the attacker, it is possible that
misleading (but verifiable) DNS records could indicate a malicious
LIS that provides false location information.
In all cases of falsification, the best remedy is to perform some
form of independent verification of the result. No specific
mechanism is currently available to prevent attacks based on
falsification of reflexive addresses; it is suggested that Devices
attempt to independently verify that the reflexive transport address
provided is accurate. [[TBD - it's clear why this is called UNSAF.
What, if any, mechanism is required here.]]
Use of private address space effectively prevents use of the usual
set of trust anchors for DNSSEC. Only a DNS server that is able to
see the same private address space can provide useful records. A
Device that relies on DNS records in the private address space
portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use
an alternative trust anchor for these records or rely on other means
of ensuring the veracity of the DNS records.
7. IAB Considerations
The IAB has studied the problem of Unilateral Self-Address Fixing
(UNSAF) [RFC3424], which is the general process by which a client
attempts to determine its address in another realm on the other side
of a NAT through a collaborative protocol reflection mechanism, such
as STUN.
Thomson & Bellis Expires December 5, 2009 [Page 12]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
The IAB requires that protocol specifications that define UNSAF
mechanisms document a set of considerations.
1. Precise definition of a specific, limited-scope problem that is
to be solved with the UNSAF proposal.
Section 3 describes the limited scope of the problem addressed in
this document.
2. Description of an exit strategy/transition plan.
[I-D.ietf-geopriv-lis-discovery] describes behaviour that
residential gateways require in order for this short term
solution to be rendered unnecessary. When widespread
implementation of the recommendations in LIS discovery, this
UNSAF mechanism can be made obsolete. Alternatively, this
mechanism can be made obsolete by widespread use of
[I-D.ietf-dhc-container-opt].
3. Discussion of specific issues that may render systems more
"brittle".
A description of the necessary assumptions and limitations of
this solution are included in Section 4.4.
Use of STUN for discovery of a reflexive transport address is
inherently brittle in the presence of multiple NATs or address
realms. In particular, brittleness is added by the requirement
of using a DNS server that is able to view the address realm that
contains the IP address in question. If address realms use
overlapping addressing space, then there is a risk that the DNS
server provides information that is not useful to the Device.
4. Identify requirements for longer term, sound technical solutions;
contribute to the process of finding the right longer term
solution.
A longer term solution is already provided in
[I-D.ietf-geopriv-lis-discovery]. However, that solution relies
on widespread deployment. The UNSAF solution provided here is
provided as an interim solution that enables LIS access for
Devices that are not able to benefit from deployment of the
recommendations in [I-D.ietf-geopriv-lis-discovery].
5. Discussion of the impact of the noted practical issues with
existing deployed NATs and experience reports.
The UNSAF mechanism depends on the experience in deployment of
Thomson & Bellis Expires December 5, 2009 [Page 13]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
STUN [RFC5389]. On the whole, existing residential gateway
devices are able to provide access to STUN and DNS service
reliably, although support of DNSSEC is largely quite poor
([I-D.ietf-dnsext-dnsproxy]).
8. Acknowledgements
The solution in Section 4 can be largely attributed to Ray Bellis,
who should be listed as an author.
9. References
9.1. Normative References
[RFC1035] Mockapetris, P.,
"Domain names -
implementation
and
specification",
STD 13,
RFC 1035,
November 1987.
[RFC2119] Bradner, S.,
"Key words for
use in RFCs to
Indicate
Requirement
Levels", BCP 14,
RFC 2119,
March 1997.
[RFC3424] Daigle, L. and
IAB, "IAB
Considerations
for UNilateral
Self-Address
Fixing (UNSAF)
Across Network
Address
Translation",
RFC 3424,
November 2002.
[RFC3596] Thomson, S.,
Huitema, C.,
Ksinant, V., and
M. Souissi, "DNS
Thomson & Bellis Expires December 5, 2009 [Page 14]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
Extensions to
Support IP
Version 6",
RFC 3596,
October 2003.
[I-D.ietf-geopriv-http-location-delivery] Barnes, M.,
Winterbottom,
J., Thomson, M.,
and B. Stark,
"HTTP Enabled
Location
Delivery
(HELD)", draft-
ietf-geopriv-
http-location-
delivery-14
(work in
progress),
May 2009.
[I-D.ietf-geopriv-lis-discovery] Thomson, M. and
J. Winterbottom,
"Discovering the
Local Location
Information
Server (LIS)", d
raft-ietf-
geopriv-lis-
discovery-11
(work in
progress),
May 2009.
9.2. Informative References
[RFC1918] Rekhter, Y.,
Moskowitz, R.,
Karrenberg, D.,
Groot, G., and
E. Lear,
"Address
Allocation for
Private
Internets",
BCP 5, RFC 1918,
February 1996.
Thomson & Bellis Expires December 5, 2009 [Page 15]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
[RFC2131] Droms, R.,
"Dynamic Host
Configuration
Protocol",
RFC 2131,
March 1997.
[RFC3315] Droms, R.,
Bound, J., Volz,
B., Lemon, T.,
Perkins, C., and
M. Carney,
"Dynamic Host
Configuration
Protocol for
IPv6 (DHCPv6)",
RFC 3315,
July 2003.
[RFC3693] Cuellar, J.,
Morris, J.,
Mulligan, D.,
Peterson, J.,
and J. Polk,
"Geopriv
Requirements",
RFC 3693,
February 2004.
[RFC4848] Daigle, L.,
"Domain-Based
Application
Service Location
Using URIs and
the Dynamic
Delegation
Discovery
Service (DDDS)",
RFC 4848,
April 2007.
[RFC5389] Rosenberg, J.,
Mahy, R.,
Matthews, P.,
and D. Wing,
"Session
Traversal
Utilities for
Thomson & Bellis Expires December 5, 2009 [Page 16]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
NAT (STUN)",
RFC 5389,
October 2008.
[I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H.
and H.
Schulzrinne,
"GEOPRIV Layer 7
Location
Configuration
Protocol;
Problem
Statement and
Requirements", d
raft-ietf-
geopriv-l7-lcp-
ps-09 (work in
progress),
February 2009.
[I-D.ietf-ecrit-requirements] Schulzrinne, H.
and R. Marshall,
"Requirements
for Emergency
Context
Resolution with
Internet
Technologies", d
raft-ietf-ecrit-
requirements-13
(work in
progress),
March 2007.
[I-D.ietf-sip-location-conveyance] Polk, J. and B.
Rosen, "Location
Conveyance for
the Session
Initiation
Protocol", draft
-ietf-sip-
location-
conveyance-13
(work in
progress),
March 2009.
[UPnP-IGD-WANIPConnection1] UPnP Forum,
Thomson & Bellis Expires December 5, 2009 [Page 17]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
"Internet
Gateway Device
(IGD)
Standardized
Device Control
Protocol V 1.0:
WANIPConnection:
1 Service
Template Version
1.01 For UPnP
Version 1.0",
DCP 05-001,
Nov 2001.
[I-D.cheshire-nat-pmp] Cheshire, S.,
"NAT Port
Mapping Protocol
(NAT-PMP)", draf
t-cheshire-nat-
pmp-03 (work in
progress),
April 2008.
[I-D.cheshire-dnsext-multicastdns] Cheshire, S. and
M. Krochmal,
"Multicast DNS",
draft-cheshire-
dnsext-
multicastdns-07
(work in
progress),
September 2008.
[I-D.winterbottom-geopriv-held-identity-extensions] Thomson, M.,
Tschofenig, H.,
Barnes, R., and
J. Winterbottom,
"Use of Target
Identity in
HTTP-Enabled
Location
Delivery
(HELD)", draft-
winterbottom-
geopriv-held-
identity-
extensions-09
(work in
Thomson & Bellis Expires December 5, 2009 [Page 18]
Internet-Draft LIS Discovery w/ Res. Gateways June 2009
progress),
February 2009.
[I-D.ietf-dnsext-dnsproxy] Bellis, R., "DNS
Proxy
Implementation
Guidelines", dra
ft-ietf-dnsext-
dnsproxy-05
(work in
progress),
April 2009.
[I-D.ietf-dhc-container-opt] Droms, R.,
"Container
Option for
Server
Configuration",
draft-ietf-dhc-
container-opt-05
(work in
progress),
March 2009.
Authors' Addresses
Martin Thomson
Andrew Corporation
PO Box U40
Wollongong University Campus, NSW 2500
AU
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
URI: http://www.andrew.com/
Ray Bellis
Nominet UK
Edmund Halley Road
Oxford OX4 4DQ
United Kingdom
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/
Thomson & Bellis Expires December 5, 2009 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 03:10:27 |