One document matched: draft-thomson-geopriv-res-gw-lis-discovery-00.txt
GEOPRIV M. Thomson
Internet-Draft Andrew Corporation
Intended status: Informational February 12, 2009
Expires: August 16, 2009
Location Information Server (LIS) Discovery From Behind Residential
Gateways
draft-thomson-geopriv-res-gw-lis-discovery-00
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 August 16, 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
The residential gateway is an ubiquitous device that has become an
Thomson Expires August 16, 2009 [Page 1]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
integral part 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 the problem of discovering a LIS in the
presence of a residential gateway. The current version includes two
proposed solutions to this problem, which will be evaluated.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 5
3.2. Use of Discovery for Third Party Queries . . . . . . . . . 6
3.3. Additional and Optional Constraints . . . . . . . . . . . 7
3.4. Solution Descriptions . . . . . . . . . . . . . . . . . . 7
4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 8
4.1. Identification of IP Addresses . . . . . . . . . . . . . . 8
4.2. DDDS Lookup . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. When To Use This Method . . . . . . . . . . . . . . . . . 9
4.4. Necessary Assumptions and Restrictions . . . . . . . . . . 9
4.5. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Deployment Considerations . . . . . . . . . . . . . . . . 10
5. Anycast DNS Method . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Overview of Operation . . . . . . . . . . . . . . . . . . 11
5.1.1. Choice of Domain Name . . . . . . . . . . . . . . . . 11
5.2. When To Use This Method . . . . . . . . . . . . . . . . . 12
5.3. Necessary Assumptions and Restrictions . . . . . . . . . . 12
5.4. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Deployment Considerations . . . . . . . . . . . . . . . . 12
5.6. Speculation On This Method . . . . . . . . . . . . . . . . 13
5.7. Alternatives . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Thomson Expires August 16, 2009 [Page 2]
Internet-Draft LIS Discovery w/ Res. Gateways February 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]) for Device configuration.
The drawback with DHCP is that universal deployment of a relatively
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.
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.
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 subsequent
sections explore alternative solutions to this problem.
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].
Thomson Expires August 16, 2009 [Page 3]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
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]. Irrespective of any
variations, the goal of LIS discovery in this scenario is to identify
the LIS in the access network.
________
(/ \)
(( 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
Thomson Expires August 16, 2009 [Page 4]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
for providing location information to Devices in the residential
network to the ISP. The ISP is able to provide location information
that identifies the residence, which is currently considered adequate
for a range of purposes. A network that covered a larger area might
require a dedicated LIS, a case that is outside the scope of this
document.
In the network topology described, the goal of LIS discovery at a
Device is to successfully identify the LIS in the access network.
The residential gateway is a major obstacle in achieving this goal.
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.
A residential gateway could forward LIS address information to hosts
within the network it serves. If the residential gateway were able
to acquire LIS address configuration from the access network, it
could distribute this information using DHCP to hosts within that
Thomson Expires August 16, 2009 [Page 5]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
network. Alternatively, a similar approach to that taken for DNS
could be used--a relay would ensure that Devices configured before
the gateway is able to acquire configuration from the ISP network.
This approach is recommended for new residential gateway devices.
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 intended function.
Existing residential gateways have proven to be quite reliable
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. In these circumstances
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.
Thomson Expires August 16, 2009 [Page 6]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
R3. The alternative LIS discovery method MAY provide a means for a
third party to discover a LIS.
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.
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.
3.4. Solution Descriptions
Any solution that addresses the problem of LIS discovery from a
residential network SHOULD provide:
o A thorough description of the procedure that a Device follows to
discover a LIS.
o A set of criteria used in selecting the procedure. E.g., are
there any indications to a Device that this procedure should or
should not be attempted?
o An exploration of the necessary assumptions associated with the
procedure.
o Any applicability restrictions. E.g., does this only apply to
networks that employ a particular access technology?
o A discussion of the failure modes and the consequences of
particular failures. E.g., how can each step in the process fail?
What happens? Be certain to consider use of the method in
scenarios that do not involve residential gateways, such as within
an corporate Ethernet network, or on a cellular network.
An appraisal of the benefits and shortcomings of the solution is not
necessary, but unobvious advantages or disadvantages can be
Thomson Expires August 16, 2009 [Page 7]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
highlighted.
4. IP-based DNS Solution
In this option, the Device first identifies its IP address or
addresses. For each address, it attempts up to three Dynamic
Delegation Discovery Service (DDDS) queries against the
".in-addr.arpa." or ".ip6.arpa." tree. The first resulting URI is
used as the address of the LIS.
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)
[I-D.ietf-behave-rfc3489bis] 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 routing device.
Proprietary methods for determining other addresses might also be
available. Because there is no assurance that these methods will be
supported by any access network these methods are not mandated.
4.2. DDDS Lookup
The U-NAPTR [RFC4848] application defined in
[I-D.ietf-geopriv-lis-discovery] is used based on an input domain
name derived from each IP address. The input domain name is the
exact same as 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].
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 part of the IP
Thomson Expires August 16, 2009 [Page 8]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
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 ISP controls an entire /24 or
/16 network.
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.
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 LIS address
option, or if a request the address identified 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.
4.4. Necessary Assumptions and Restrictions
Addresses for private address ranges (10.0.0.0/8, 192.168.0.0/16 or
similar) MAY be used as input to this method. However, if private
addresses are used, only a DNS server within that network is able to
provide the DNS mappings for the private address used; the public DNS
does not contain useful records for private address ranges.
Private addresses are never the final option for this method. Public
reflexive transport addresses acquired from a STUN server ensure that
the entity providing access to the public Internet is identified.
This solution assumes access to a STUN server that is able to view
addresses from the public Internet.
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 Expires August 16, 2009 [Page 9]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
to include a useful value for the LIS address.
4.5. Failure Modes
Configuration of STUN server is vital to the success of this method.
Alternative methods for discovering external IP addresses are
possible, including UPnP and NAT-PMP. These methods might not be
enabled on the residential gateway.
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).
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
applies to all addresses lower in the tree, records at the lower
point are only necessary in the case of exceptions.
5. Anycast DNS Method
Anycast is practice of making a particular Service Address available
in multiple, discrete, autonomous locations, such that datagrams sent
are routed to one of several available network locations [RFC4786].
One potential advantage of anycast is that datagrams can be routed to
the node that is nearest according to the network topology. This
discovery method relies on network routing configuration that directs
requests to a server within the access network.
This solution uses a specially allocated IP address for anycast to
contact the nearest host. Any access network MAY use this IP address
for the purpose described here. The advantage is that this avoids
any need for Device configuration; successful operation relies on
routing configuration alone. This solutions is unaffected by use of
network address translation (NAT) by intermediate network segmentss;
the first network segment that provides the anycast address is the
one that is contacted.
Thomson Expires August 16, 2009 [Page 10]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
The special IP address is constrained to an access network, and
routes to this address MUST NOT be advertised globally over Border
Gateway Protocol (BGP) [RFC4271]. This ensures that only Devices
within the access network are able to access the host using this
address.
Stateless transport is preferred for use with anycast unless routing
is known to be stable on the duration of a typical session.
Therefore, relying on anycast for use with HELD or any other protocol
that relies on stateful protocols would be inadvisable. The
discovery process need only rely on anycast for initial stages.
Use of anycast for DNS deployment is well established. This method
relies upon use of a specific IP address that is directed to the
nearest DNS server.
5.1. Overview of Operation
A Device sends a DNS request to the allocated IP address. The
request retrieves NAPTR records for the ".access." top level domain.
The U-NAPTR [RFC4848] DDDS application defined in
[I-D.ietf-geopriv-lis-discovery] is used to determine a LIS URI.
[Open question: From RFC 2181 and the anti-forgery work, it appears
that the source IP in the response datagram should be the anycast
address. However, other discussion on anycast seems to indicate that
an alternative (unicast) address could be used. If a unicast address
is provided in the response, then when truncation is indicated, the
Device could establish a TCP connection to the unicast address
directly. This has none of the negative ramifications normally
associated with use of TCP and anycast. Need to confirm, more for
completeness than anything else.]
5.1.1. Choice of Domain Name
The choice of a DNS name to use in the request is an important
consideration, perhaps the most important. It is unlikely that a
Device is able to select a name that has equal significance to the
access network unless that name is fixed by specification.
Several potential options for the domain name have been presented.
One option is to use the ".local." suffix established in
[I-D.cheshire-dnsext-multicastdns]. However, the semantics
associated with that method appear not to be consistent with this
usage. A new subdomain under the ".arpa." root is also possible,
although this implies allocation by the IANA, which is a small
misrepresentation.
Thomson Expires August 16, 2009 [Page 11]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
This document proposes that a new ".access." root suffix be
established for the purpose of identifying services associated with
the network access. Any server can claim to be authoritative for
this domain. All records associated with this domain and all sub-
domains are MUST NOT be propagated and recursing resolvers MUST NOT
recurse on queries to this domain. The root servers do not provide
NS records for this domain. Servers SHOULD NOT propagate this
information in zone transfers.
Because any server can be considered authoritative for ".access.",
DNSSEC [RFC4033] cannot be used to authenticate the RRs provided.
What surety this method provides lies solely in the use of anycast to
contact the DNS server.
5.2. 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 LIS address
option, or if a request the address identified results in a HELD
"notLocatable" error or equivalent.
5.3. Necessary Assumptions and Restrictions
This solution requires specific network configuration where the
allocated IP address is advertised within an access network. The
allocated IP address MUST NOT be advertised globally on BGP. This
method also assumes relative stability of the route between Device
and DNS server.
5.4. Failure Modes
This method is subject to any redirections that might happen to all
Internet traffic. For instance, some residential gateways redirect
all traffic through a virtual private network or other type of
tunnel. If such a blanket redirection is used, the DNS request will
traverse that tunnel and potentially reach the wrong server at the
other end. Successful recognition of this situation relies on that
LIS that is discovered using the HELD "notLocatable" error correctly.
5.5. Deployment Considerations
An access network provider MAY use split-view DNS to ensure that the
".access." tree doesn't appear to requesters outside the access
network. This ensures that this information does not result in
misleading information being accidentally propagated.
Thomson Expires August 16, 2009 [Page 12]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
5.6. Speculation On This Method
The use of a newly minted TLD and the special semantics associated
with that label is likely to be the biggest problem with this
solution. As happened with "Multicast DNS"
[I-D.cheshire-dnsext-multicastdns] this might be regarded as
heretical and it could be resisted with a vigour usually reserved for
protecting a favourite kind of text editor.
5.7. Alternatives
There is no strong reason for use of DNS (or what might try to pass
for DNS) with this anycast option. Adaptation of any number of a
range of discovery protocols is possible. Typically, these protocols
rely upon link-local multicast as an initial step. Altering this
phase to use an assigned anycast address instead of multicast is a
possibility.
6. IANA Considerations
[RFC Editor: please remove this section prior to publication.]
This document has no IANA actions.
7. Security Considerations
To be completed.
8. Acknowledgements
The solution in Section 4 can be attributed to Ray Bellis, who
probably should be listed as an author, except that I haven't asked
him yet. The solution in Section 5 comes via Dean Willis, but the
details are entirely concocted by the author and any shortcomings
should be attributed accordingly.
9. References
9.1. Normative References
[RFC1035] Mockapetris, P.,
"Domain names -
implementation
and
specification",
STD 13,
RFC 1035,
November 1987.
Thomson Expires August 16, 2009 [Page 13]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
[RFC2119] Bradner, S.,
"Key words for
use in RFCs to
Indicate
Requirement
Levels", BCP 14,
RFC 2119,
March 1997.
[RFC3596] Thomson, S.,
Huitema, C.,
Ksinant, V., and
M. Souissi, "DNS
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-12
(work in
progress),
January 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-07
(work in
progress),
February 2009.
Thomson Expires August 16, 2009 [Page 14]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
9.2. Informative References
[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.
[RFC4033] Arends, R.,
Austein, R.,
Larson, M.,
Massey, D., and
S. Rose, "DNS
Security
Introduction and
Requirements",
RFC 4033,
March 2005.
[RFC4271] Rekhter, Y., Li,
T., and S.
Hares, "A Border
Gateway Protocol
4 (BGP-4)",
RFC 4271,
Thomson Expires August 16, 2009 [Page 15]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
January 2006.
[RFC4848] Daigle, L.,
"Domain-Based
Application
Service Location
Using URIs and
the Dynamic
Delegation
Discovery
Service (DDDS)",
RFC 4848,
April 2007.
[RFC4786] Abley, J. and K.
Lindqvist,
"Operation of
Anycast
Services",
BCP 126,
RFC 4786,
December 2006.
[I-D.ietf-behave-rfc3489bis] Rosenberg, J.,
Mahy, R.,
Matthews, P.,
and D. Wing,
"Session
Traversal
Utilities for
(NAT) (STUN)", d
raft-ietf-
behave-
rfc3489bis-18
(work in
progress),
July 2008.
[I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H.
and H.
Schulzrinne,
"GEOPRIV Layer 7
Location
Configuration
Protocol;
Problem
Statement and
Requirements", d
Thomson Expires August 16, 2009 [Page 16]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
raft-ietf-
geopriv-l7-lcp-
ps-08 (work in
progress),
June 2008.
[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-12
(work in
progress),
November 2008.
[UPnP-IGD-WANIPConnection1] UPnP Forum,
"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.
Thomson Expires August 16, 2009 [Page 17]
Internet-Draft LIS Discovery w/ Res. Gateways February 2009
[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,
"HELD Identity
Extensions", dra
ft-winterbottom-
geopriv-held-
identity-
extensions-08
(work in
progress),
January 2009.
Author's Address
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/
Thomson Expires August 16, 2009 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 03:10:19 |