Network Working Group K. Weniger
Internet-Draft Panasonic
Expires: April 13, 2008 October 11, 2007
MIPv6 Correspondent Node-Targeted Location Privacy and Optimized Routing
draft-irtf-mobopts-mip6-cnlocpriv-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of 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 April 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Weniger Expires April 13, 2008 [Page 1]
Internet-Draft CNLocPriv October 2007
Abstract
Mobile IPv6 does not allow a mobile node to hide its location from a
correspondent node without compromising optimized routing. Hence, a
mobile node has the choice: it can either get location privacy
support or short packet delay, but not both at the same time. This
document discusses the problem of achieving both simultaneously and
specifies a solution. The solution utilizes the Mobile IPv6
bootstrapping mechanisms and does neither introduce new network
entities nor changes to home agent or correspondent node
implementations.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and Problem Definition . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
4. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Changes to Mobile Node Operation . . . . . . . . . . . . . . . 8
5.1. Route Optimization for New Sessions . . . . . . . . . . . 8
5.2. Route Optimization for Ongoing Sessions . . . . . . . . . 9
5.3. Route Optimization Mode Selection . . . . . . . . . . . . 11
5.4. Source Address Selection . . . . . . . . . . . . . . . . . 11
6. Location-dependent Home Agent Discovery . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Weniger Expires April 13, 2008 [Page 2]
Internet-Draft CNLocPriv October 2007
1. Terminology
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 [1].
General mobility terminology can be found in [5]. Terminology
specific to Mobile IPv6 and Mobile IPv6 bootstrapping can be found in
[2] and [6]. Additionally, the following terms are introduced:
Correspondent node-targeted location privacy: Hiding the mobile
node's location from the correspondent node
Eavesdropper-targeted location privacy: Hiding the mobile node's
location from nodes eavesdropping on the path between mobile node
and correspondent node
IP Reachability Home Agent (IRHA): A Mobile IPv6 home agent as
specified in [2] that provides IP reachability and global session
continuity for the mobile node.
Home Address for IP Reachability (HoA_IR): A Mobile IPv6 home
address used for IP reachability and session continuity and that
is anchored at the IRHA. This home address is independent of the
location of the mobile node and is disclosed to potential
correspondent nodes (e.g., by publishing the address in DNS).
Optimized path: A path between mobile node and correspondent node
that is shorter than the path between mobile node and
correspondent node when the mobile node uses bi-directional
tunneling mode to the IRHA. Note that the optimized path may be
longer than the path between mobile node and correspondent node
when the mobile node uses route optimization mode.
Optimized routing: Routing data packets over the optimized path
Optimized Routing Home Agent (ORHA): A Mobile IPv6 home agent as
specified in [2] that is used for providing optimized routing and
correspondent node-targeted location privacy. It must support the
bootstrapping mechanisms specified in [3] and should be located
close to the correspondent node.
Home Address for Optimized Routing (HoA_OR): A Mobile IPv6 home
address used for optimized routing and session continuity that is
anchored at the ORHA. This home address is typically not public
(i.e., not published in DNS).
Weniger Expires April 13, 2008 [Page 3]
Internet-Draft CNLocPriv October 2007
2. Introduction and Problem Definition
Location privacy is the ability to hide a user's location from other
users. This is considered to be an important feature, since
disclosure of the location can have serious impacts on the user's
life. In general, location privacy can be achieved by hiding the
relation between identity and location of a user. In Mobile IPv6
[2], the care-of address and the home address typically represent
topological location and identity of a mobile node, respectively.
Even though a dynamically assigned home address may not represent a
permanent identity itself, a mapping to a mobile node's permanent
identifiers is typically published for IP reachability reasons (e.g.,
in DNS). Consequently, in Mobile IPv6 at least either the care-of
address or the home address must be hidden from anyone that is not
authorized to obtain the location of the mobile node. Two rather
orthogonal sub-problems of location privacy for Mobile IPv6 can be
identified: hiding the location from eavesdroppers on the path and
hiding the location from the correspondent node [7], which we
henceforth call eavesdropper-targeted and correspondent node-targeted
location privacy, respectively. This document is concerned with
correspondent node-targeted location privacy only, especially with
the problem of providing optimized routing at the same time.
Eavesdropper-targeted location privacy is out of scope of this
document. However, it is expected that the mechanisms defined in
this document can be combined with solutions for eavesdropper-
targeted location privacy such as the pseudo home address mechanisms
specified in [11]. Any location privacy issues not related to Mobile
IPv6 are out of the scope of this document.
An example scenario illustrating the problem addressed by this
document is the following: A mobile node wants to hide its location
from correspondent nodes and uses Mobile IPv6 with a public home
address to be reachable. The public home address is anchored at a
home agent, which we henceforth call IRHA. The mobile node requires
strong location privacy, i.e., hiding only the mobility within an
access network and revealing the access network prefix to the
correspondent node is not acceptable. An application on the
correspondent node initiates a delay-sensitive session with the
mobile node such as a VoIP call by sending packets to the mobile
node's public home address (HoA_IR). This requires that the
correspondent node has obtained the mobile node's home address
beforehand, e.g., from DNS. The mobile node receives the packets in
bi-directional tunneling mode from its home agent (IRHA) and then may
decide to switch to route optimization mode for the session. Let's
assume the mobile node is located in the United States and the
correspondent node is located in Canada, whereas the mobile node's
home agent is located in Europe. Since the mobile node is far away
from home, the packet delay and hence the user experience is far from
Weniger Expires April 13, 2008 [Page 4]
Internet-Draft CNLocPriv October 2007
what could be achieved. However, if the mobile node uses route
optimization mode, it reveals its CoA and hence its location to the
correspondent node (note that the correspondent node can also be an
attacker that just initiates a session to find out the mobile node's
location). Consequently, the mobile node has the choice: it can
either have good VoIP call quality without location privacy or
location privacy with bad VoIP call quality. Currently, there is no
way to achieve both simultaneously with Mobile IPv6.
This document proposes a mechanism that can provide both
simultaneously, i.e., strong correspondent node-targeted location
privacy and optimized routing. Home agents and correspondent node
are unchanged and no new entities or messages are introduced. The
basic idea is that the mobile node bootstraps with a home agent
located topologically close to the correspondent node and which is
used for optimized communication with this correspondent node. Such
home agent is henceforth called ORHA. A home agent location close to
the correspondent node ensures that the route in bi-directional
tunneling mode is short and that no location information is contained
in the home address, as opposed to a home address anchored at a local
home agent. For mobile node-initiated sessions, the mobile node uses
the ORHA in bi-directional tunneling mode and HoA_OR on higher
layers. For correspondent node-initiated sessions, the public home
address HoA_IR is used on higher layers and the mobile node registers
the HoA_OR as care-of address at the correspondent node.
Weniger Expires April 13, 2008 [Page 5]
Internet-Draft CNLocPriv October 2007
3. Applicability Statement
The solution described in this document relies on the assignment or
discovery of an home agent in the vicinity of the correspondent node
or at an appropriate location that is uncorrelated with the location
of the point of attachment of the mobile node. In deployment
scenarios where such a home agent does not exist or if the
establishment of security associations with such home agent is not
feasible (e.g., because the mobile node's Mobility Service Authorizer
does not have any relationship with the provider Mobility Service
Provider of the home agent), this solution is not applicable.
Furthermore, the mechanisms defined in this document should only be
used in scenarios where the number of concurrent sessions that a
mobile node runs and that require simultaneous optimized routing and
correspondent node-targeted location privacy is low.
The application of the HA discovery mechanisms as specified in the
MIP6 bootstrapping documents [3] [8] to ORHA discovery may pose
special requirements on deployment. If the DNS-based HA discovery
scheme shall be used for ORHA discovery, MSAs or MSPs should maintain
DNS entries that allow the MN to discover a home agent at a specific
location or in a specific domain. There are different ways to
achieve that. For instance, the mobile node's MSA may maintain DNS
entries per CN domain according to the scheme
"_mip6._ipv6.CNdomain.MSAdomain.com" and the mobile node may be
configured to construct the FQDN for ORHA discovery by appending the
string "_mip6._ipv6.", CN's domain name, and MSA's domain name. If
the DHCP-based HA discovery scheme [9] shall be used for ORHA
discovery, the mobile node should be able to request a home agent
using DHCP once a session with a new CN begins, i.e., potentially
long after completion of the network authentication. Therefore, the
ASP should support either storing the HA information received from
the mobile node's MSA for as long as the mobile node is attached to
the ASP or requesting HA information from the MSA for a specific
target domain during the mobile node session (see section 4.2 of
[9]).
Weniger Expires April 13, 2008 [Page 6]
Internet-Draft CNLocPriv October 2007
4. Related work
Qui et. al. [11] propose a solution to the correspondent node-
targeted location privacy problem. The basic idea is to hide the
home address from the correspondent node in route optimization mode
by using a pseudo home address instead of the real home address.
Although the care-of address is revealed to the correspondent node,
location privacy is protected by hiding the identity (i.e., real home
address) of the mobile node from the correspondent node. This
approach has also been proposed in [10]. However, if the
correspondent node initiates the communication location privacy is
compromised, since the public home address and hence the identity of
the mobile node is typically already known by the correspondent node.
And even if the real home address can be hidden from the
correspondent node, location privacy is compromised if the
correspondent node is able to figure out the mobile node's identity
by any other means (e.g., during the conversation of a voice call or
by higher layer identifiers).
[3] and [8] specify the mechanisms for Mobile IPv6 bootstrapping in
the split and the integrated scenario, respectively. They allow a
mobile node to bootstrap with any home agent, for which the necessary
trust relationships are in place. When bootstrapping with a local
home agent, optimized routing can be achieved in bi-directional
tunneling mode by using the home address pertaining to the local home
agent for the session with the correspondent node. However, since
the home address obtained from a local home agent belongs to the
network the mobile node is currently visiting, it contains location
information. Consequently, location privacy is compromised, if the
correspondent node knows that the home agent is local to the mobile
node (see security considerations of [3]). Although in many cases
the correspondent node will not know, there are cases where the
correspondent node can find out whether the mobile node's home agent
is local or remote. For instance, a correspondent node may know that
a mobile node's home agent is local because the mobile node's
Mobility Service Provider (MSP) is known to always assign local home
agents for routing efficiency reasons.
Weniger Expires April 13, 2008 [Page 7]
Internet-Draft CNLocPriv October 2007
5. Changes to Mobile Node Operation
This section describes a mechanism that allows a Mobile IPv6 mobile
node to achieve both correspondent node-targeted location privacy and
optimized routing simultaneously. The mobile node operation is split
in two cases: route optimization for new sessions (i.e.,
communication sessions that have not yet started) and route
optimization for ongoing sessions. The first case applies, e.g., if
the mobile nodes wants to initiate a session with a correspondent
node and decides to optimized the route before sending the first data
packets. The second case applies, e.g., if the correspondent node
initiates a session with the mobile node or if the mobile node
decides to optimize the route of an ongoing session. A session is
defined by an application or transport layer context bound to the IP
addresses of the two endpoints, with one of the addresses being the
mobile node's home address to achieve session continuity.
5.1. Route Optimization for New Sessions
The mobile node first tries to discover an ORHA as described in
Section 6. If the discovery is successful, the mobile node
bootstraps with the ORHA, obtains a home address HoA_OR, and uses the
ORHA in bi-directional tunneling mode for communication with the
correspondent node. Existing registrations with other home agents
can be kept for communication with other correspondent nodes. Since
the mobile node can continue to use the public home address HoA_IR
for IP reachability, the HoA_OR does not need to be published, i.e.,
no DNS update needs to be triggered for this home address. An
exemplary signaling flow is shown in Figure 1.
+--+ +-------+ +--+
|MN| | ORHA | |CN|
+--+ +-------+ +--+
<ORHA discovery> | |
| | |
| MIPv6 bootstrapping | |
|<----------------------------------------->| |
| BU/BA (HoA_OR,CoA) | |
|<----------------------------------------->| |
| MIPv6 tunnel (ORHA) | data packets |
|===========================================|<------------------->|
Figure 1: Signaling flow for optimizing the route for a session that
has not yet started
Since HoA_OR is independent of the mobile node's location and since
Weniger Expires April 13, 2008 [Page 8]
Internet-Draft CNLocPriv October 2007
HoA_OR is the only address that is revealed to the correspondent
node, strong correspondent node-targeted location privacy is ensured.
5.2. Route Optimization for Ongoing Sessions
After the mobile node has decided to optimize the route of a session
(e.g., after receiving the first data packets from the correspondent
node tunneled through the IRHA), the mobile node tries to discover an
ORHA as described in Section 6. If this is successful, it bootstraps
with this ORHA and obtains HoA_OR. Since the ongoing communication
session is bound to HoA_IR, packets sent by the correspondent node
are still routed through the IRHA. To optimize the route without
compromising location privacy, the mobile node moves the session to
the ORHA. Therefore, the mobile node switches to route optimization
mode and sends care-of test messages, binding update messages, and
later data packets destined for the correspondent node over the
reverse tunnel to the ORHA. The mobile node uses HoA_IR as home
address and HoA_OR as care-of address in the context of this route
optimization mode, i.e., headers of care-of test messages, binding
update messages, and data packets are as follows (IPsec for signaling
protection to ORHA assumed):
Care-of Test Init:
IPv6 header (source = care-of address,
destination = ORHA)
ESP header in tunnel mode
IPv6 header (source = HoA_OR,
destination = correspondent node address)
Any protocol
Data packets and binding updates:
IPv6 header (source = care-of address,
destination = ORHA)
ESP header in tunnel mode
IPv6 header (source = HoA_OR,
destination = correspondent node address)
Destination Options header
Home Address option (HoA_IR)
Any protocol
Weniger Expires April 13, 2008 [Page 9]
Internet-Draft CNLocPriv October 2007
Since HoA_OR is the mobile node's care-of address and the HoA_IR is
the mobile node's home address from the correspondent node's point of
view, data packets sent by the correspondent node contain the HoA_IR
in the routing header and the HoA_OR in the destination address field
of the IP header. Consequently, data packets sent by the
correspondent node are routed to the ORHA and tunneled to the mobile
node. An exemplary signaling flow is shown in Figure 2.
+--+ +-------+ +-------+ +--+
|MN| | IRHA | | ORHA | |CN|
+--+ +-------+ +-------+ +--+
| BU/BA (HoA_IR,CoA) | | |
|<------------------->| | |
~ ~ ~ ~
| MIPv6 tunnel (IRHA) | data packets |
|=====================|<----------------------------------------->|
| | | |
<ORHA discovery> | | |
| | | |
| MIPv6 bootstrapping | |
|<----------------------------------------->| |
| BU/BA (HoA_OR,CoA) | |
|<----------------------------------------->| |
| MIPv6 tunnel (IRHA) | HoTi |
|=====================|------------------------------------------>|
| MIPv6 tunnel (ORHA) | CoTi |
|===========================================|-------------------->|
| MIPv6 tunnel (IRHA) | HoT |
|=====================|<------------------------------------------|
| MIPv6 tunnel (ORHA) | CoT |
|===========================================|<--------------------|
| MIPv6 tunnel (ORHA) |BU/BA (HoA_IR,HoA_OR)|
|===========================================|<------------------->|
| MIPv6 tunnel (ORHA) | data packets |
|===========================================|<------------------->|
Figure 2: Signaling flow for optimization of the route for an ongoing
session
Location privacy is provided, since the correspondent node only
learns HoA_OR and HoA_IR, which both do not contain any information
about the mobile node's location. Optimized routing is provided as
well, since all data packets exchanged between mobile node and
correspondent node are routed over the ORHA, which is located close
to the correspondent node.
Weniger Expires April 13, 2008 [Page 10]
Internet-Draft CNLocPriv October 2007
Note that upon changing the care-of address, the mobile node does not
need to send a binding update message to the correspondent node over
the reverse tunnel to the ORHA, because the mobile node's care-of
address in this context is the HoA_OR.
5.3. Route Optimization Mode Selection
The mobile node has to decide for every correspondent node, whether
it wants to use bi-directional tunneling mode, route optimization
mode or the mechanisms described in this document. How this decision
is made and when route optimization according to this document is
triggered is implementation specific and hence out of scope of this
document. Generally, bi-directional tunneling to the home agent
achieves strong correspondent node-targeted location privacy and is
sufficient for non-delay-sensitive services such as simple web
browsing. If no location privacy is required, Mobile IPv6 route
optimization mode can be used.
Since the number of simultaneous registrations at different home
agents has impacts on the overall signaling overhead and resource
consumption on the mobile node, the mobile node should try to
minimize the number of simultaneously used ORHAs and only apply the
mechanisms specified in this document for sessions that really
require simultaneous optimized routing and correspondent node-
targeted location privacy.
5.4. Source Address Selection
The mobile node may use different home addresses for communication
with different correspondent nodes when using the route optimization
mechanisms defined in this document. Hence, the mobile node must be
able to select the right home address as source address for packets
to be sent to a specific destination address. This can be achieved
with the source address selection mechanisms defined in [4]. If the
ORHA is located in the correspondent node's domain, the prefix of the
home address anchored at the ORHA is similar to the prefix of the
correspondent node and rule 9 (Use longest matching prefix) of the
default source address selection [4] applies. For other cases,
dynamically adding entries for HoA_OR and correspondent node address
with matching labels in the policy table [4] when route optimization
according to this document is triggered would prefer a home address
as source address for communication with a specific correspondent
node. However, since this is implementation specific, the details of
the source address selection are out of the scope of this document.
Weniger Expires April 13, 2008 [Page 11]
Internet-Draft CNLocPriv October 2007
6. Location-dependent Home Agent Discovery
The mechanisms defined in Section 5.1 and Section 5.2 require the
discovery or assignment of a home agent (ORHA) located close to a
correspondent node. One option to achieve that is to pre-configure a
list of home agent FQDNs and distances to various prefixes on the
mobile node. However, since the list of available home agents and
the distances may change, a dynamic discovery of ORHAs is preferable.
There are various ways for achieving this, some of them are described
in the following.
One option is to re-use the DNS-based home agent discovery specified
in [3]. The mobile node would construct the FQDN based on the
correspondent node's address, prefix or host name. Some operator
(e.g., MSA, ASP or MSP) should maintain DNS entries that allow the MN
to discover a home agent at a specific location or in a specific
domain. For instance, the mobile node's MSA may maintain DNS entries
per CN domain according to the scheme
"_mip6._ipv6.CNdomain.MSAdomain.com" and the mobile node may be
configured to construct the FQDN for ORHA discovery by appending the
string "_mip6._ipv6.", CN's domain name, and MSA's domain name.
Another option is to re-using DHCP-based HA assignment as defined in
[8] and [9]. For instance, the MSA would send the home agent
information for all the MSPs which the mobile node is authorized to
use to the Network Access Server (NAS) during network authentication.
Once the mobile node intends to initiate route optimization according
to this document, it sends a DHCP Information Request and appends a
Home Network Identifier Option [9] containing the correspondent
node's domain as target domain. The id-type can be set to 2 or to a
new value specifically defined for ORHA discovery. The NAS would
then select a home agent from the set of authorized home agents that
is close to the target domain. How this selection is done is out of
scope of this document. Finally, the NAS would assign the selected
home agent to the mobile node in the Home Network Information Option
of the DHCP reply message.
Anycast-based home agent discovery using IKEv2 [12] or DHAAD [2] is
another possible solution. The mobile node would construct the
anycast destination address based on the correspondent node's prefix.
A drawback of this method is that it cannot discover ORHAs located
close to, but outside the correspondent node's network.
Finally, the mobile node could query a dedicated server using some
application-layer protocol like http. The server would maintain the
list of ORHAs and would reply with the name of an ORHA upon receiving
a request with a correspondent node's prefix. This server can, e.g.,
be provided by the MSA or a third party in the public Internet.
Weniger Expires April 13, 2008 [Page 12]
Internet-Draft CNLocPriv October 2007
7. Security Considerations
The solution specified in this document ensures that a correspondent
node at most learns the home addresses HoA_OR and HoA_IR of the
mobile node. HoA_IR is used for IP reachability and is independent
of the mobile node's movement. Hence, it doesn't contain any
information about the mobile node's current location. HoA_OR is
anchored at a home agent located close to the correspondent node and
thus there is no relation between HoA_OR and the mobile node's
current location. Consequently, the correspondent node has no way to
infer the mobile node's location or movement, i.e., correspondent
node-targeted location privacy is guaranteed. However, the
correspondent node may wrongly believe that mobile node has moved
close to himself once the mobile node bootstraps with an ORHA and
moves the session from IRHA to ORHA as described in Section 5.2.
However, since the decision to optimize an ongoing session is
independent of the mobile node's movement, the correspondent node
cannot infer anything about the mobile node's real movement patterns
from this.
An attacker could initiate many faked communication sessions with
spoofed source addresses in order to trigger the mobile node to
discover and bootstrap with many different ORHAs. This could consume
significant resources on the mobile node and in the network and may
cause a DoS. As a countermeasure, the mobile node should not start
bootstrapping with a new ORHA just because it receives packets from a
new correspondent node or it should limit the number of
simultaneously used ORHAs. Faked sessions should be identified as
such as quickly as possible and the mobile node should de-register
immediately from ORHAs once a session is identified as a fake
session.
The ORHA knows the location of the mobile node and could distribute
it to third parties without authorization from the mobile node.
Hence, the mobile node must be sure that the ORHA is trusted before
the mobile node reveals its location to the ORHA. How the trust
verification is done depends on the ORHA discovery mechanism in use.
One option is that the MSA knows which home agents are trusted with
respect to location privacy and only assigns such home agents to the
mobile node. The MSA could also deny the authorization request if
the MN tries to bootstrap with an untrusted home agent. Another
option is that the mobile node verifies the trust by itself, e.g., by
pre-configuring a list of trusted home agent addresses on the mobile
node or by using certificates. Note that the fact that the ORHA and
the correspondent node may be in the same administrative domain
doesn't imply that the ORHA reveals the mobile node's location to the
correspondent node. This is also true in today's cellular networks,
where it is ensured that users of a service provided by a particular
Weniger Expires April 13, 2008 [Page 13]
Internet-Draft CNLocPriv October 2007
mobile operator don't know the location of other users using a
service provided by the same operator.
The return routability procedure over the reverse tunnel to the ORHA
is not considered less secure than the standard return routability
procedure as long as the ORHA is trusted and the ORHA link is not
vulnerable to eavesdropping.
Weniger Expires April 13, 2008 [Page 14]
Internet-Draft CNLocPriv October 2007
8. Acknowledgements
Thanks to Kuntal Chowdhury, Vijay Devarapalli, Rajeev Koodli, and
Ahmad Muhanna for their valuable comments and suggestions to improve
this document.
Weniger Expires April 13, 2008 [Page 15]
Internet-Draft CNLocPriv October 2007
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-07 (work in progress),
July 2007.
9.2. Informative References
[4] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[5] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[6] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[7] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", RFC 4882, May 2007.
[8] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in
progress), July 2007.
[9] Jang, H., "DHCP Option for Home Information Discovery in
MIPv6", draft-ietf-mip6-hiopt-07 (work in progress),
September 2007.
[10] Dupont, F., "A Simple Privacy Extension for Mobile IPv6",
draft-dupont-mip6-privacyext-04 (work in progress), July 2006.
[11] Qiu, Y., "Mobile IPv6 Location Privacy Solutions",
draft-irtf-mobopts-location-privacy-solutions-05 (work in
progress), May 2007.
[12] Weniger, K. and F. Dupont, "IKEv2-based Home Agent Assignment
in Mobile IPv6/NEMO Bootstrapping",
draft-dupont-ikev2-haassign-02 (work in progress),
January 2007.
Weniger Expires April 13, 2008 [Page 16]
Internet-Draft CNLocPriv October 2007
Author's Address
Kilian A. Weniger
Panasonic R&D Center Germany
Monzastr. 4c
Langen 63225
Germany
Email: kilian.weniger@eu.panasonic.com
Weniger Expires April 13, 2008 [Page 17]
Internet-Draft CNLocPriv October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Weniger Expires April 13, 2008 [Page 18]