draft-ietf-geopriv-lis-discovery-12.txt   draft-ietf-geopriv-lis-discovery-13.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: May 12, 2010 November 8, 2009 Expires: June 11, 2010 December 8, 2009
Discovering the Local Location Information Server (LIS) Discovering the Local Location Information Server (LIS)
draft-ietf-geopriv-lis-discovery-12 draft-ietf-geopriv-lis-discovery-13
Abstract Abstract
Discovery of the correct Location Information Server (LIS) in the Discovery of the correct Location Information Server (LIS) in the
local access network is necessary for devices that wish to acquire local access network is necessary for devices that wish to acquire
location information from the network. A method is described for the location information from the network. A method is described for the
discovery of a LIS in the access network serving a device. Dynamic discovery of a LIS in the access network serving a device. Dynamic
Host Configuration Protocol (DHCP) options for IP versions 4 and 6 Host Configuration Protocol (DHCP) options for IP versions 4 and 6
are defined that specify a domain name. This domain name is then are defined that specify a domain name. This domain name is then
used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 May 12, 2010. This Internet-Draft will expire on June 11, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
1.1. Discovery Procedure Overview . . . . . . . . . . . . . . . 3 1.1. Discovery Procedure Overview . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. LIS Discovery Procedure . . . . . . . . . . . . . . . . . . . 4 2. LIS Discovery Procedure . . . . . . . . . . . . . . . . . . . 4
2.1. Residential Gateways . . . . . . . . . . . . . . . . . . . 5 2.1. Residential Gateways . . . . . . . . . . . . . . . . . . . 6
2.2. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 6 2.2. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 7
3. Access Network Domain Name DHCP Option . . . . . . . . . . . . 7 3. Determining a Domain Name . . . . . . . . . . . . . . . . . . 8
3.1. Domain Name Encoding . . . . . . . . . . . . . . . . . . . 7 3.1. Domain Name Encoding . . . . . . . . . . . . . . . . . . . 8
3.2. Access Network Domain Name DHCPv4 Option . . . . . . . . . 7 3.2. Access Network Domain Name DHCPv4 Option . . . . . . . . . 8
3.3. Access Network Domain Name DHCPv6 Option . . . . . . . . . 8 3.3. Access Network Domain Name DHCPv6 Option . . . . . . . . . 9
4. U-NAPTR Resolution of a LIS URI . . . . . . . . . . . . . . . 9 3.4. Alternative Domain Names . . . . . . . . . . . . . . . . . 10
4.1. Determining a Domain Name . . . . . . . . . . . . . . . . 10 4. U-NAPTR Resolution of a LIS URI . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.1. Registration of DHCPv4 and DHCPv6 Option Codes . . . . . . 11 6.1. Registration of DHCPv4 and DHCPv6 Option Codes . . . . . . 13
6.2. Registration of a Location Server Application Service 6.2. Registration of a Location Server Application Service
Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Registration of a Location Server Application Protocol 6.3. Registration of a Location Server Application Protocol
Tag for HELD . . . . . . . . . . . . . . . . . . . . . . . 12 Tag for HELD . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
1. Introduction and Overview 1. Introduction and Overview
The location of a device is a useful and sometimes necessary part of The location of a device is a useful and sometimes necessary part of
many services. A Location Information Server (LIS) is responsible many services. A Location Information Server (LIS) is responsible
for providing that location information to devices with an access for providing that location information to devices with an access
network. The LIS uses knowledge of the access network and its network. The LIS uses knowledge of the access network and its
physical topology to generate and serve location information to physical topology to generate and serve location information to
devices. devices.
skipping to change at page 4, line 39 skipping to change at page 4, line 39
service. service.
2. LIS Discovery Procedure 2. LIS Discovery Procedure
A device that has multiple network interfaces could potentially be A device that has multiple network interfaces could potentially be
served by a different access network on each interface, each with a served by a different access network on each interface, each with a
different LIS. The device SHOULD attempt to discover the LIS different LIS. The device SHOULD attempt to discover the LIS
applicable to each network interface, stopping when a LIS is applicable to each network interface, stopping when a LIS is
successfully discovered on any interface. successfully discovered on any interface.
The LIS discovery procedure follows the following process: The LIS discovery procedure follows this process:
1. Acquire the access network domain name DHCP option (Section 3). 1. Acquire the access network domain name (Section 3).
This process might be repeated for each of the network interfaces This process might be repeated for each of the network interfaces
on the device. Domain names acquired from other sources might on the device. Domain names acquired from other sources might
also be added. also be added.
2. Apply U-NAPTR resolution (Section 4) to discover a LIS URI. 2. Apply U-NAPTR resolution (Section 4) to discover a LIS URI.
The U-NAPTR process is applied using each of the domain names as The U-NAPTR process is applied using each of the domain names as
input. input.
3. Verify that the LIS is able to provide location information. 3. Verify that the LIS is able to provide location information.
The first URI that results in a successful response from the LIS The first URI that results in a successful response from the LIS
is used. is used.
A device MUST support discovery using the access network domain name A device MUST support discovery using the access network domain name
DHCP option (Section 3) as input to U-NAPTR resolution (Section 4). DHCP option (Section 3) as input to U-NAPTR resolution (Section 4).
Other domain names MAY be used, as described in Section 4.1. If this option is not available, DHCPv4 option 15 [RFC2132] is used.
Other domain names MAY be used, as described in Section 3.4.
A device that discovers a LIS URI MUST attempt to verify that the LIS A device that discovers a LIS URI MUST attempt to verify that the LIS
is able to provide location information. For the HELD protocol, the is able to provide location information. For the HELD protocol, the
device verifies the URI by making a location request to the LIS. If device verifies the URI by making a location request to the LIS. If
- at any time - the LIS responds to a request with the "notLocatable" - at any time - the LIS responds to a request with the "notLocatable"
error code (see Section 4.3.2 of error code (see Section 4.3.2 of
[I-D.ietf-geopriv-http-location-delivery]), the device MUST continue [I-D.ietf-geopriv-http-location-delivery]), the device MUST continue
or restart the discovery process. A device SHOULD NOT make further or restart the discovery process. A device SHOULD NOT make further
requests to a LIS that provides a "notLocatable" error until its requests to a LIS that provides a "notLocatable" error until its
network attachment changes, or it discovers the LIS on an alternative network attachment changes, or it discovers the LIS on an alternative
network interface. network interface.
Static configuration of a domain name or a LIS URI MAY be used if all Static configuration of a domain name or a LIS URI MAY be used. Note
other discovery methods fail. Note that if a device has moved from that if a device has moved from its customary location, static
its customary location, static configuration might indicate a LIS configuration might indicate a LIS that is unable to provide accurate
that is unable to provide accurate location information. location information.
The product of the LIS discovery process for HELD is an "https:" or The product of the LIS discovery process for HELD is an "https:" or
"http:" URI. Nothing distinguishes this URI from other URIs with the "http:" URI. Nothing distinguishes this URI from other URIs with the
same scheme, aside from the fact that it is the product of this same scheme, aside from the fact that it is the product of this
process. Only URIs produced by the discovery process can be used for process. Only URIs produced by the discovery process can be used for
location configuration using HELD. location configuration using HELD.
The overall discovery process is summarized in Figure 1.
-----------
( Start )
-----+-----
|<--------------------------------------+
| |
V |
------^------- ------^------ |
/ \ / 1. \ |
< Next interface >------->< Get domain >-----+
\ / Y ^ \ / N
------v------- | ------v------
| N | | Y
| | V
| | ------^------
| | / 2. \
| +----< Get URI >
| | N \ /
| | ------v------
| | | Y
| | V
| | ------^------
| | / 3. \
| +----< Check URI >
| N \ /
| ------v------
| | Y
V V
----------- -----------
( Failure ) ( Success )
----------- -----------
Figure 1: LIS Discovery Flowchart
2.1. Residential Gateways 2.1. Residential Gateways
The process described in this document is known to not work in a very The process described in this document is likely to fail in many
common deployment scenario. A fixed wireline scenario is described residential network scenarios. A fixed wireline scenario is
in more detail in Section 3.1 of [I-D.ietf-geopriv-l7-lcp-ps]. In described in more detail in Section 3.1 of
this fixed wireline environment an intervening residential gateway [I-D.ietf-geopriv-l7-lcp-ps]. In this fixed wireline environment an
exists between the device and the access network. If the residential intervening residential gateway exists between the device and the
gateway does not provide this option to the devices it serves, those access network. If the residential gateway does not provide this
devices are unable to discover a LIS. option to the devices it serves, those devices are unable to discover
a LIS.
Support of this specification by residential gateways ensures that Support of this specification by residential gateways ensures that
the devices they serve are able to acquire location information. In the devices they serve are able to acquire location information. In
many cases the residential gateway configures the devices it serves many cases the residential gateway configures the devices it serves
using DHCP. A residential gateway is able to use DHCP to assist using DHCP. A residential gateway is able to use DHCP to assist
devices in gaining access to their location information. This can be devices in gaining access to their location information. This can be
accomplished by providing an access network domain name DHCP option accomplished by providing an access network domain name DHCP option
suitable for LIS discovery, or by acting as a LIS directly. To suitable for LIS discovery, or by acting as a LIS directly. To
actively assist devices, a residential gateway can either: actively assist devices, a residential gateway can either:
skipping to change at page 7, line 8 skipping to change at page 8, line 11
the software running on them. In these cases, it might be that a LIS the software running on them. In these cases, it might be that a LIS
on the remote side of a VPN is inadvertently discovered. A LIS MUST on the remote side of a VPN is inadvertently discovered. A LIS MUST
NOT provide location information in response to requests that it can NOT provide location information in response to requests that it can
identify as originating from a device on the remote end of a VPN identify as originating from a device on the remote end of a VPN
tunnel, unless it is able to accurately determine location. The tunnel, unless it is able to accurately determine location. The
"notLocatable" HELD error code can be used to indicate to a device "notLocatable" HELD error code can be used to indicate to a device
that discovery has revealed an unsuitable LIS. This ensures that that discovery has revealed an unsuitable LIS. This ensures that
even if a device discovers a LIS over the VPN, it does not rely on a even if a device discovers a LIS over the VPN, it does not rely on a
LIS that is unable to provide accurate location information. LIS that is unable to provide accurate location information.
3. Access Network Domain Name DHCP Option 3. Determining a Domain Name
DHCP provides a direct means for the access network provider to DHCP provides a direct means for the access network provider to
configure a device. The access network domain name option identifies configure a device. The access network domain name option identifies
a domain name that is suitable for service discovery within the a domain name that is suitable for service discovery within the
access network. This domain name is used as input to the U-NAPTR access network. This domain name is used as input to the U-NAPTR
resolution process for LIS discovery. resolution process for LIS discovery.
The domain name provided in this option is one owned by the access The domain name provided in this option is one owned by the access
network operator. This domain name is intended for use in network operator. This domain name is intended for use in
discovering services within the access network. discovering services within the access network.
skipping to change at page 7, line 48 skipping to change at page 9, line 4
3.2. Access Network Domain Name DHCPv4 Option 3.2. Access Network Domain Name DHCPv4 Option
This section defines a DHCP for IPv4 (DHCPv4) option for the domain This section defines a DHCP for IPv4 (DHCPv4) option for the domain
name associated with the access network. name associated with the access network.
Code Len Access Network Domain Name Code Len Access Network Domain Name
+-----+-----+-----+-----+-----+-----+-----+---- +-----+-----+-----+-----+-----+-----+-----+----
| TBD | n | s1 | s2 | s3 | s4 | s5 | ... | TBD | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+---- +-----+-----+-----+-----+-----+-----+-----+----
Figure 2: Access Network Domain Name DHCPv4 Option
Figure 1: Access Network Domain Name DHCPv4 Option
The values s1, s2, s3, etc. represent the domain name labels in the The values s1, s2, s3, etc. represent the domain name labels in the
domain name encoding. Note that the length field in the DHCPv4 domain name encoding. Note that the length field in the DHCPv4
option represents the length of the entire domain name encoding, option represents the length of the entire domain name encoding,
whereas the length fields in the domain name encoding (see Section 3) whereas the length fields in the domain name encoding (see Section 3)
is the length of a single domain name label. is the length of a single domain name label.
Code: OPTION_V4_ACCESS_DOMAIN (TBD). [[IANA/RFC-Editor Note: Please Code: OPTION_V4_ACCESS_DOMAIN (TBD). [[IANA/RFC-Editor Note: Please
replace TBD with the assigned DHCPv4 option code, both here and in replace TBD with the assigned DHCPv4 option code, both here and in
Figure 1.]] Figure 2.]]
Length: The length of the entire access network domain name option Length: The length of the entire access network domain name option
in octets. in octets.
Access Network Domain Name: The domain name associated with the Access Network Domain Name: The domain name associated with the
access network, encoded as described in Section 3.1. access network, encoded as described in Section 3.1.
A DHCPv4 client MAY request a access network domain name option in a A DHCPv4 client MAY request a access network domain name option in a
Parameter Request List option, as described in [RFC2131]. Parameter Request List option, as described in [RFC2131].
skipping to change at page 8, line 40 skipping to change at page 9, line 43
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_ACCESS_DOMAIN | Length | | OPTION_V6_ACCESS_DOMAIN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Network Domain Name . . Access Network Domain Name .
. ... . . ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DHCPv6 Access Network Domain Name Option Figure 3: DHCPv6 Access Network Domain Name Option
option-code: OPTION_V6_ACCESS_DOMAIN (TBD). [[IANA/RFC-Editor Note: option-code: OPTION_V6_ACCESS_DOMAIN (TBD). [[IANA/RFC-Editor Note:
Please replace TBD with the assigned DHCPv6 option code.]] Please replace TBD with the assigned DHCPv6 option code.]]
option-length: The length of the entire access network domain name option-length: The length of the entire access network domain name
option in octets. option in octets.
option-value: The access network domain name, encoded as described option-value: The access network domain name, encoded as described
in Section 3.1. in Section 3.1.
A DHCPv6 client MAY request a access network domain name option in a A DHCPv6 client MAY request a access network domain name option in a
Options Request Option (ORO), as described in [RFC3315]. Options Request Option (ORO), as described in [RFC3315].
This option contains a single domain name and, as such, MUST contain This option contains a single domain name and, as such, MUST contain
precisely one root label. precisely one root label.
3.4. Alternative Domain Names
The U-NAPTR resolution method described requires a domain name as
input. The access network domain name DHCP options (Section 3.2 and
Section 3.3) is one source of this domain name.
If a device knows one or more alternative domain names that might be
used for discovery, it MAY repeat the U-NAPTR process using those
domain names as input. For instance, static configuration of a
device might be used to provide a device with a domain name.
DHCPv4 option 15 [RFC2132] provides an indication of the domain name
that a host uses when resolving hostnames in DNS. This option is
used when the DHCPv4 access domain name is not available.
Alternative domain names MUST NOT be used unless the access network
domain name option is unsuccessful or where external information
indicates that a particular domain name is to be used.
Other domain names might be provided by a DHCP server (for example,
[RFC4702] for DHCPv4, [RFC4704] for DHCPv6). However, these domain
names could be provided without considering their use for LIS
discovery; therefore, it is not likely that these options contain
useful values.
4. U-NAPTR Resolution of a LIS URI 4. U-NAPTR Resolution of a LIS URI
U-NAPTR [RFC4848] resolution for a LIS takes a domain name as input U-NAPTR [RFC4848] resolution for a LIS takes a domain name as input
and produces a URI that identifies the LIS. This process also and produces a URI that identifies the LIS. This process also
requires an Application Service tag and an Application Protocol tag, requires an Application Service tag and an Application Protocol tag,
which differentiate LIS-related NAPTR records from other records for which differentiate LIS-related NAPTR records from other records for
that domain. that domain.
Section 6.2 defines an Application Service tag of "LIS", which is Section 6.2 defines an Application Service tag of "LIS", which is
used to identify the location service for a given domain. The used to identify the location service for a given domain. The
skipping to change at page 9, line 48 skipping to change at page 11, line 30
"" ; regex "" ; regex
outsource.example.com. ; replacement outsource.example.com. ; replacement
) )
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.example.org:4802/?c=ex!" ; regex "!*.!https://lis.example.org:4802/?c=ex!" ; regex
. ; replacement . ; replacement
) )
Figure 3: Sample LIS:HELD Service NAPTR Records Figure 4: 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 6. Application Protocol tag are included in Section 6.
An "https:" LIS URI that is a product of U-NAPTR MUST be An "https:" LIS URI that is a product of U-NAPTR MUST be
authenticated using the domain name method described in Section 3.1 authenticated using the domain name method described in Section 3.1
of RFC 2818 [RFC2818]. The domain name that is used in this of RFC 2818 [RFC2818]. The domain name that is used in this
authentication is the one extracted from the URI, not the input to authentication is the one extracted from the URI, not the input to
the U-NAPTR resolution process. the U-NAPTR resolution process.
4.1. Determining a Domain Name
The U-NAPTR resolution method described requires a domain name as
input. The access network domain name DHCP option (Section 3)
describes one source of this domain name.
If a device knows one or more alternative domain names that might be
used for discovery, it MAY repeat the U-NAPTR process using those
domain names as input. For instance, static configuration of a
device might be used to provide a device with a domain name.
Alternative domain names MUST NOT be used unless the access network
domain name option is unsuccessful or where external information
indicates that a particular domain name is to be used. For instance,
domain names for the device might be provided by a DHCP server
([RFC4702] for DHCPv4, [RFC4704] for DHCPv6); DHCPv4 option 15
[RFC2131] could also be used as a source of a domain name suffix for
the device. However, these domain names could be provided without
considering their use for LIS discovery; therefore, many DHCP servers
do not provide a sensible value for these options.
5. Security Considerations 5. Security Considerations
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;
therefore, interception of messages does not introduce any specific therefore, interception of messages does not introduce any specific
concerns. concerns.
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 device is critical to a number of network services; furthermore, a device
skipping to change at page 13, line 28 skipping to change at page 14, line 35
[RFC1035] Mockapetris, P., "Domain [RFC1035] Mockapetris, P., "Domain
names - implementation and names - implementation and
specification", STD 13, specification", STD 13,
RFC 1035, November 1987. RFC 1035, November 1987.
[RFC2131] Droms, R., "Dynamic Host [RFC2131] Droms, R., "Dynamic Host
Configuration Protocol", Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2132] Alexander, S. and R.
Droms, "DHCP Options and
BOOTP Vendor Extensions",
RFC 2132, March 1997.
[RFC2818] Rescorla, E., "HTTP Over [RFC2818] Rescorla, E., "HTTP Over
TLS", RFC 2818, May 2000. TLS", RFC 2818, May 2000.
[RFC3315] Droms, R., Bound, J., [RFC3315] Droms, R., Bound, J.,
Volz, B., Lemon, T., Volz, B., Lemon, T.,
Perkins, C., and M. Perkins, C., and M.
Carney, "Dynamic Host Carney, "Dynamic Host
Configuration Protocol for Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, IPv6 (DHCPv6)", RFC 3315,
July 2003. July 2003.
skipping to change at page 15, line 43 skipping to change at page 17, line 10
Problem Statement and Problem Statement and
Requirements", draft-ietf- Requirements", draft-ietf-
geopriv-l7-lcp-ps-10 (work geopriv-l7-lcp-ps-10 (work
in progress), July 2009. in progress), July 2009.
[I-D.ietf-geopriv-lbyr-requirements] Marshall, R., [I-D.ietf-geopriv-lbyr-requirements] Marshall, R.,
"Requirements for a "Requirements for a
Location-by-Reference Location-by-Reference
Mechanism", draft-ietf- Mechanism", draft-ietf-
geopriv-lbyr-requirements- geopriv-lbyr-requirements-
08 (work in progress), 09 (work in progress),
September 2009. November 2009.
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Andrew Andrew
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2915 Phone: +61 2 4221 2915
 End of changes. 21 change blocks. 
63 lines changed or deleted 108 lines changed or added

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