draft-ietf-geopriv-lis-discovery-00.txt   draft-ietf-geopriv-lis-discovery-01.txt 
GEOPRIV M. Thomson GEOPRIV M. Thomson
Internet-Draft J. Winterbottom Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew Intended status: Standards Track Andrew
Expires: June 13, 2008 December 11, 2007 Expires: December 15, 2008 June 13, 2008
Discovering the Local Location Information Server (LIS) Discovering the Local Location Information Server (LIS)
draft-ietf-geopriv-lis-discovery-00.txt draft-ietf-geopriv-lis-discovery-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 13, 2008. This Internet-Draft will expire on December 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
A method is described for the discovery of a Location Information A method is described for the discovery of a Location Information
Server. The method consists of attempting to use a Dynamic Host Server. The method consists of attempting to use a Dynamic Host
Configuration Protocol (DHCP) option, followed by a URI-enabled NAPTR Configuration Protocol (DHCP) option, followed by a URI-enabled NAPTR
(U-NAPTR). DHCP options are defined for both IPv4 and IPv6 DHCP. (U-NAPTR). DHCP options are defined for both IPv4 and IPv6 DHCP.
This document also defines a U-NAPTR Application Service for a LIS, This document also defines a U-NAPTR Application Service for a LIS,
with a specific Application Protocol for the HTTP Enabled Location with a specific Application Protocol for the HTTP Enabled Location
Delivery (HELD) protocol. Delivery (HELD) protocol.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
2. LIS Discovery Using DHCP . . . . . . . . . . . . . . . . . . . 5 2. LIS Discovery Using DHCP . . . . . . . . . . . . . . . . . . . 5
2.1. DHCPv4 Option for a LIS Address . . . . . . . . . . . . . 5 2.1. DHCPv4 Option for a LIS Address . . . . . . . . . . . . . 5
2.2. DHCPv6 Option for a LIS Address . . . . . . . . . . . . . 5 2.2. DHCPv6 Option for a LIS Address . . . . . . . . . . . . . 5
3. U-NAPTR for LIS Discovery . . . . . . . . . . . . . . . . . . 7 3. U-NAPTR for LIS Discovery . . . . . . . . . . . . . . . . . . 7
4. Determining the Access Network Domain Name . . . . . . . . . . 8 4. Determining the Access Network Domain Name . . . . . . . . . . 8
4.1. DHCP Domain Name Option . . . . . . . . . . . . . . . . . 8 4.1. DHCP Domain Name Option . . . . . . . . . . . . . . . . . 8
4.2. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Determining an External IP Address . . . . . . . . . . 9 4.2.1. Determining an External IP Address . . . . . . . . . . 9
5. Discovery Order . . . . . . . . . . . . . . . . . . . . . . . 11 5. Discovery Order . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 12 5.1. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Access Network Guidance . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Registration of DHCPv4 and DHCPv6 Option Codes . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.2. Registration of a Location Server Application Service 8.1. Registration of DHCPv4 and DHCPv6 Option Codes . . . . . . 15
Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Registration of a Location Server Application Service
7.3. Registration of a Location Server Application Protocol Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Tag for HELD . . . . . . . . . . . . . . . . . . . . . . . 14 8.3. Registration of a Location Server Application Protocol
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 Tag for HELD . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Residential Broadband LIS Discovery Example . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Residential Broadband LIS Discovery Example . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Introduction and Overview 1. Introduction and Overview
Discovering a Location Information Server (LIS) is an important part Discovering a Location Information Server (LIS) is an important part
of the location acquisition process. The LIS is an access network of the location acquisition process. The LIS is an access network
service that needs to be discovered before it can be used. This service that needs to be discovered before it can be used. This
document describes a method that a host can use to discover a URI for document describes a method that a host can use to discover a URI for
a LIS. a LIS.
The product of a discovery process, such as the one described in this The product of a discovery process, such as the one described in this
skipping to change at page 3, line 27 skipping to change at page 3, line 27
other supplementary information. other supplementary information.
The discovery process requires that the host first attempt LIS The discovery process requires that the host first attempt LIS
discovery using Dynamic Host Configuration protocol (DHCP). If DHCP discovery using Dynamic Host Configuration protocol (DHCP). If DHCP
is not available, or the option is not supported by the network, the is not available, or the option is not supported by the network, the
host attempts to discover the LIS using the DNS and URI-enabled host attempts to discover the LIS using the DNS and URI-enabled
Naming Authority Pointer (U-NAPTR). Finally, the host can rely on Naming Authority Pointer (U-NAPTR). Finally, the host can rely on
proprietary methods for determining the address of the LIS, including proprietary methods for determining the address of the LIS, including
static configuration. static configuration.
The URI result from the discovery process is suitable for location
configuration only; that is, the client MUST dereference the URI
using the process described in HELD
[I-D.ietf-geopriv-http-location-delivery]. URIs discovered in this
way are not "location by reference" URIs; dereferencing one of them
provides the location of the requester only. Clients MUST NOT embed
these URIs in fields in other protocols designed to carry the
location of the client.
1.1. DHCP Discovery 1.1. DHCP Discovery
DHCP ([RFC2131], [RFC3315]) is a commonly used mechanism for DHCP ([RFC2131], [RFC3315]) is a commonly used mechanism for
providing bootstrap configuration information allowing a host to providing bootstrap configuration information allowing a host to
operate in a specific network environment. The bulk of DHCP operate in a specific network environment. The bulk of DHCP
information is largely static; consisting of configuration information is largely static; consisting of configuration
information that does not change over the period that the host is information that does not change over the period that the host is
attached to the network. Physical location information might change attached to the network. Physical location information might change
over this time, however the address of the LIS does not. Thus, DHCP over this time, however the address of the LIS does not. Thus, DHCP
is suitable for configuring a host with the address of a LIS. is suitable for configuring a host with the address of a LIS.
skipping to change at page 7, line 13 skipping to change at page 7, line 13
URI: The address of the LIS. The URI MUST NOT be NULL terminated. URI: The address of the LIS. The URI MUST NOT be NULL terminated.
3. U-NAPTR for LIS Discovery 3. U-NAPTR for LIS Discovery
U-NAPTR resolution for a LIS takes a domain name as input and U-NAPTR resolution for a LIS takes a domain name as input and
produces a URI that identifies the LIS. This process also requires produces a URI that identifies the LIS. This process also requires
an Application Service tag and an Application Protocol tag, which an Application Service tag and an Application Protocol tag, which
differentiate LIS-related NAPTR records from other records for that differentiate LIS-related NAPTR records from other records for that
domain. domain.
Section 7.2 defines an Application Service tag of "LIS", which is Section 8.2 defines an Application Service tag of "LIS", which is
used to identify the location service for a particular domain. The used to identify the location service for a particular domain. The
Application Protocol tag "HELD", defined in Section 7.3, is used to Application Protocol tag "HELD", defined in Section 8.3, is used to
identify a LIS that understands the HELD protocol identify a LIS that understands the HELD protocol
[I-D.ietf-geopriv-http-location-delivery]. [I-D.ietf-geopriv-http-location-delivery].
The NAPTR records in the following example demonstrate the use of the The NAPTR records in the following example demonstrate the use of the
Application Service and Protocol tags. Iterative NAPTR resolution is Application Service and Protocol tags. Iterative NAPTR resolution is
used to delegate responsibility for the LIS service from used to delegate responsibility for the LIS service from
"zonea.example.com." and "zoneb.example.com." to "zonea.example.com." and "zoneb.example.com." to
"outsource.example.com.". "outsource.example.com.".
zonea.example.com. zonea.example.com.
skipping to change at page 7, line 47 skipping to change at page 7, line 47
outsource.example.com. outsource.example.com.
;; order pref flags ;; order pref flags
IN NAPTR 100 10 "u" "LIS:HELD" ( ; service IN NAPTR 100 10 "u" "LIS:HELD" ( ; service
"!*.!https://lis.outsource.example.com/!" ; regex "!*.!https://lis.outsource.example.com/!" ; regex
. ; replacement . ; replacement
) )
Figure 3: Sample LIS:HELD Service NAPTR Records Figure 3: Sample LIS:HELD Service NAPTR Records
Details for the "LIS" Application Service tag and the "HELD" Details for the "LIS" Application Service tag and the "HELD"
Application Protocol tag are included in Section 7. Application Protocol tag are included in Section 8.
4. Determining the Access Network Domain Name 4. Determining the Access Network Domain Name
The U-NAPTR discovery method described in Section 3 requires that the The U-NAPTR discovery method described in Section 3 requires that the
domain name applicable to the access network is known. An domain name applicable to the access network is known. An
unconfigured host might not have this information, therefore it must unconfigured host might not have this information, therefore it must
determine this value before the U-NAPTR method can be attempted. determine this value before the U-NAPTR method can be attempted.
This section describes several methods for discovering a domain name This section describes several methods for discovering a domain name
for the local access network. Each method is attempted where for the local access network. Each method is attempted where
skipping to change at page 8, line 28 skipping to change at page 8, line 28
particularly applicable when NAT is used, as is shown in particularly applicable when NAT is used, as is shown in
Section 4.2.1. Section 4.2.1.
4.1. DHCP Domain Name Option 4.1. DHCP Domain Name Option
For IP version 4, Dynamic Host Configuration Protocol (DHCP) option For IP version 4, Dynamic Host Configuration Protocol (DHCP) option
15 [RFC2131] includes the domain name suffix for the host. If DHCP 15 [RFC2131] includes the domain name suffix for the host. If DHCP
and option 15 are available, this value should be used as input the and option 15 are available, this value should be used as input the
U-NAPTR procedure. U-NAPTR procedure.
DHCP for IPv6 provides a single domain name suffix that can be used
in the same manner, as a described in
[I-D.ietf-dhc-dhcpv6-opt-dnsdomain].
Alternatively, a fully qualified domain name (FQDN) for the host Alternatively, a fully qualified domain name (FQDN) for the host
might be provided by the server ([RFC4702] for DHCPv4, [RFC4704] for might be provided by the server ([RFC4702] for DHCPv4, [RFC4704] for
DHCPv6). This domain name is used as input to the U-NAPTR resolution DHCPv6). This domain name is used as input to the U-NAPTR resolution
and is obtained from the FQDN by removing the first label. If the and is obtained from the FQDN by removing the first label. If the
host has provided a fully qualified domain name using this option, it host has provided a fully qualified domain name using this option, it
SHOULD NOT be used - the domain known to the host might not be the SHOULD NOT be used - the domain known to the host might not be the
same as that of the access network. same as that of the access network.
Either DHCP method SHOULD be attempted first if DHCP is available. Either DHCP method SHOULD be attempted first if DHCP is available.
Note that this method is only attempted if the LIS address option is Note that this method is only attempted if the LIS address option is
skipping to change at page 11, line 19 skipping to change at page 11, line 19
Some networks maintain a topology analogous to an onion and are Some networks maintain a topology analogous to an onion and are
comprised of layers, or segments, separating hosts from the Internet comprised of layers, or segments, separating hosts from the Internet
through intermediate networks. It is best therefore for a host to through intermediate networks. It is best therefore for a host to
discover the LIS logically closest to it, and this can best be done discover the LIS logically closest to it, and this can best be done
by applying the discovery techniques in the following order: by applying the discovery techniques in the following order:
1. DHCP LIS URI Option 1. DHCP LIS URI Option
2. DNS U-NAPTR Discovery, using the domain name from: 2. DNS U-NAPTR Discovery, using the domain name from:
1. DHCP Domain Name Option A. DHCP Domain Name Option
2. Reverse DNS, using the hosts IP address from: B. Reverse DNS, using the hosts IP address from:
1. the local network interface and immediate network segment 1. the local network interface and immediate network segment
2. the network segment adjacent to the immediate segment, as 2. the network segment adjacent to the immediate segment, as
revealed by UPnP revealed by UPnP
3. the public Internet, as revealed by STUN; or the network 3. the public Internet, as revealed by STUN; or the network
segment where the STUN server resides segment where the STUN server resides
(4.) any network segment, as revealed by other method (4.) any network segment, as revealed by other method
skipping to change at page 12, line 38 skipping to change at page 12, line 38
5.1. Virtual Private Networks (VPNs) 5.1. Virtual Private Networks (VPNs)
Where a host has multiple network interfaces the host MAY Where a host has multiple network interfaces the host MAY
independently discover the LIS corresponding to the access networks independently discover the LIS corresponding to the access networks
reached by each network interface. Resolving which LIS to contact reached by each network interface. Resolving which LIS to contact
for location information is a host application issue. for location information is a host application issue.
LIS discovery over a VPN network interface SHOULD NOT be performed LIS discovery over a VPN network interface SHOULD NOT be performed
since such a LIS does not have the physical presence generally since such a LIS does not have the physical presence generally
necessary to determine location. However, since not all VPN necessary to determine location. However, since not all VPN
interfaces can be detected by hosts, a LIS SHOULD NOT respond to interfaces can be detected by hosts, a LIS SHOULD NOT provide
requests originating from a VPN pool. This ensures that even if a location information in response to requests originating from a VPN
host discovers a LIS over the VPN, it does not rely on a LIS that is pool. This ensures that even if a host discovers a LIS over the VPN,
unable to provide accurate location information. The exception to it does not rely on a LIS that is unable to provide accurate location
this is where the LIS and host are able to determine a location information. The exception to this is where the LIS and host are
without access network support. able to determine a location without access network support.
TBD: Is there an advantage in providing a HELD error code that 6. Access Network Guidance
indicates that the host has reached the LIS over a VPN?
6. Security Considerations In order to successfully discover a LIS, a host relies on information
provided by the access network. DHCP and DNS servers need to be able
to provide the data that the device depends on. This section
provides guidance on what information needs to be made available to a
host for it to successfully discover a LIS.
Access networks that provide both a LIS and a DHCP server must
provide the DHCP option for the LIS address. Since DHCP must be
attempted first, if it can be guaranteed that DHCP can be used by all
hosts in the network, no further configuration is necessary.
Unless DHCP can be relied upon for all hosts in the network (see
[I-D.ietf-geopriv-l7-lcp-ps] for common scenarios), DNS discovery
methods must also be supported. To support the DNS discovery
methods, the access network must provide two sets of DNS records: the
(U-)NAPTR records that enable the discovery of a LIS URI from a
domain name; and the reverse DNS records that enable the discovery of
a domain name based on the IP address of the host.
Access networks that provide a LIS should also provide reverse DNS
records for all IP addresses they administer. For each domain that
is referenced in reverse DNS records, a NAPTR record in that domain
must be provided for the "LIS:HELD" service that can be used to
resolve the address of a LIS.
Note: The DHCP domain name option is notably absent from this
guidance. The domain name option provides a quicker and more
reliable means to discover the domain name in the case where a
DHCP server does not support the LIS URI option.
7. Security Considerations
The primary attack against the methods described in this document is The primary attack against the methods described in this document is
one that would lead to impersonation of a LIS. The LIS is one that would lead to impersonation of a LIS. The LIS is
responsible for providing location information and this information responsible for providing location information and this information
is critical to a number of network services; furthermore, a host does is critical to a number of network services; furthermore, a host does
not necessarily have a prior relationship with a LIS. Several not necessarily have a prior relationship with a LIS. Several
methods are described here that can limit the probablity of, or methods are described here that can limit the probablity of, or
provide some protection against, such an attack. provide some protection against, such an attack.
The address of a LIS is usually well-known within an access network; The address of a LIS is usually well-known within an access network;
skipping to change at page 14, line 5 skipping to change at page 15, line 5
to ensure that the reverse DNS record and the resulting domain are to ensure that the reverse DNS record and the resulting domain are
provided by the same entity before this method is used. Without this provided by the same entity before this method is used. Without this
assurance, the host cannot be certain that the access network assurance, the host cannot be certain that the access network
provider has provided the NAPTR record for the domain name that is provider has provided the NAPTR record for the domain name that is
provided. provided.
Hosts behind NAT devices are also subject to attacks when retrieving Hosts behind NAT devices are also subject to attacks when retrieving
their public IP address. [I-D.ietf-behave-rfc3489bis] describes some their public IP address. [I-D.ietf-behave-rfc3489bis] describes some
means of mitigating this attack for STUN. means of mitigating this attack for STUN.
7. IANA Considerations 8. IANA Considerations
7.1. Registration of DHCPv4 and DHCPv6 Option Codes 8.1. Registration of DHCPv4 and DHCPv6 Option Codes
The IANA is requested to assign an option code for the DHCPv4 option The IANA is requested to assign an option code for the DHCPv4 option
for a LIS address, as described in Section 2.1 of this document. for a LIS address, as described in Section 2.1 of this document.
The IANA is requested to assign an option code for the DHCPv6 option The IANA is requested to assign an option code for the DHCPv6 option
for a LIS address, as described in Section 2.2 of this document. for a LIS address, as described in Section 2.2 of this document.
7.2. Registration of a Location Server Application Service Tag 8.2. Registration of a Location Server Application Service Tag
This section registers a new S-NAPTR/U-NAPTR Application Service tag This section registers a new S-NAPTR/U-NAPTR Application Service tag
for a LIS, as mandated by [RFC3958]. for a LIS, as mandated by [RFC3958].
Application Service Tag: LIS Application Service Tag: LIS
Intended usage: Identifies a service that provides a host with its Intended usage: Identifies a service that provides a host with its
location information. location information.
Defining publication: RFCXXXX Defining publication: RFCXXXX
Related publications: HELD [I-D.ietf-geopriv-http-location-delivery] Related publications: HELD [I-D.ietf-geopriv-http-location-delivery]
Contact information: The authors of this document Contact information: The authors of this document
Author/Change controller: The IESG Author/Change controller: The IESG
7.3. Registration of a Location Server Application Protocol Tag for 8.3. Registration of a Location Server Application Protocol Tag for
HELD HELD
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
for the HELD [I-D.ietf-geopriv-http-location-delivery] protocol, as for the HELD [I-D.ietf-geopriv-http-location-delivery] protocol, as
mandated by [RFC3958]. mandated by [RFC3958].
Application Service Tag: HELD Application Service Tag: HELD
Intended Usage: Identifies the HELD protocol. Intended Usage: Identifies the HELD protocol.
skipping to change at page 16, line 5 skipping to change at page 17, line 5
Terminal NAPTR Record Type(s): U Terminal NAPTR Record Type(s): U
Defining Publication: RFCXXXX Defining Publication: RFCXXXX
Related Publications: HELD [I-D.ietf-geopriv-http-location-delivery] Related Publications: HELD [I-D.ietf-geopriv-http-location-delivery]
Contact Information: The authors of this document Contact Information: The authors of this document
Author/Change Controller: The IESG Author/Change Controller: The IESG
8. Acknowledgements 9. Acknowledgements
The authors would like to thank Leslie Daigle for her work on The authors would like to thank Leslie Daigle for her work on
U-NAPTR; Peter Koch for his feedback on the DNS aspects of this U-NAPTR; Peter Koch for his feedback on the DNS aspects of this
document; Andy Newton for constructive suggestions with regards to document; Andy Newton for constructive suggestions with regards to
document direction; Hannes Tschofenig for input and reviews. document direction; Hannes Tschofenig and Richard Barnes for input
and reviews.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
skipping to change at page 17, line 38 skipping to change at page 18, line 38
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006. Option", RFC 4704, October 2006.
[RFC4848] Daigle, L., "Domain-Based Application Service Location [RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007. (DDDS)", RFC 4848, April 2007.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-13 (work in progress), draft-ietf-behave-rfc3489bis-15 (work in progress),
November 2007. February 2008.
[I-D.ietf-dhc-dhcpv6-opt-dnsdomain]
Yan, R., "Domain Suffix Option for DHCPv6",
draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in progress),
June 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 10.2. Informative References
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
skipping to change at page 18, line 26 skipping to change at page 19, line 22
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4367] Rosenberg, J. and IAB, "What's in a Name: False [RFC4367] Rosenberg, J. and IAB, "What's in a Name: False
Assumptions about DNS Names", RFC 4367, February 2006. Assumptions about DNS Names", RFC 4367, February 2006.
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-06 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-07 (work in
progress), November 2007. progress), March 2008.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-03 (work in draft-ietf-geopriv-http-location-delivery-07 (work in
progress), November 2007. progress), April 2008.
[UPnP-IGD-WANIPConnection1] [UPnP-IGD-WANIPConnection1]
UPnP Forum, "Internet Gateway Device (IGD) Standardized UPnP Forum, "Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0: WANIPConnection:1 Service Device Control Protocol V 1.0: WANIPConnection:1 Service
Template Version 1.01 For UPnP Version 1.0", DCP 05-001, Template Version 1.01 For UPnP Version 1.0", DCP 05-001,
Nov 2001. Nov 2001.
Appendix A. Residential Broadband LIS Discovery Example Appendix A. Residential Broadband LIS Discovery Example
This example shows how LIS discovery using U-NAPTR and DNS might be This example shows how LIS discovery using U-NAPTR and DNS might be
skipping to change at page 23, line 7 skipping to change at page 24, line 7
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2938 Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/ URI: http://www.andrew.com/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 23, line 44 skipping to change at line 888
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 28 change blocks. 
60 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/