Network-Based Mobility Extensions J. Korhonen
(Netext) Renesas Mobile
Internet-Draft T. Savolainen
Intended status: Standards Track Nokia
Expires: January 30, 2014 S. Gundavelli
Cisco
July 29, 2013
Local Prefix Lifetime Management for Proxy Mobile IPv6
draft-korhonen-dmm-local-prefix-01.txt
Abstract
This specification defines a protocol extension to Proxy Mobile IPv6
that enables prefix lifetime management for locally assigned prefixes
within a Proxy Mobile IPv6 domain. A locally assigned prefix is
managed by a Mobile Access Gateway and is always topologically
anchored to the Mobile Access Gateway within the Proxy Mobile IPv6
domain.
Requirements Language
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 RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 30, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Korhonen, et al. Expires January 30, 2014 [Page 1]
Internet-Draft Local Prefix Management July 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
3. Mobility Options . . . . . . . . . . . . . . . . . . . . . . . 5
4. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 6
4.1. Extensions to Binding Update List Entry Data Structure . . 6
4.2. Local Prefix/Address Assignment . . . . . . . . . . . . . 7
4.3. Local Use of Prefixes/Addresses . . . . . . . . . . . . . 7
4.4. Local Prefixes/Addresses Management . . . . . . . . . . . 7
4.4.1. Deprecating Prefixes/Addresses . . . . . . . . . . . . 7
4.4.2. Temporary Tunneling Between Mobile Access Gateways . . 8
4.4.3. Informing a Mobile Node of an Inoperable
Prefix/Address . . . . . . . . . . . . . . . . . . . . 8
5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 8
5.1. Extensions to Binding Cache Entry Data Structure . . . . . 8
5.2. Local Prefix/Address Context Transfer . . . . . . . . . . 8
5.3. Local Prefixes/Addresses Management . . . . . . . . . . . 9
6. Signaling Flow Examples . . . . . . . . . . . . . . . . . . . 9
6.1. Stateless Address AutoConfiguration Example . . . . . . . 9
6.2. Stateful Address Configuration Example . . . . . . . . . . 11
7. Configuration Objects . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Korhonen, et al. Expires January 30, 2014 [Page 2]
Internet-Draft Local Prefix Management July 2013
1. Introduction
This specification defines a protocol extension to Proxy Mobile IPv6
(PMIPv6) [RFC5213] that enables prefix/address lifetime management
for locally assigned prefixes/addresses within a PMIPv6 domain. A
prefix/address locally assigned to the mobile node (MN) is managed by
a specific Mobile Access Gateway (MAG) and is always topologically
anchored to that MAG within the PMIPv6 domain. The protocol
extension essentially defines a context transfer mechanism that
allows for a source MAG to inform a target MAG about locally assigned
prefixes/addresses during the handover.
After a handover, the prefixes/addresses from the source MAG are
topologically in an incorrect location when the mobile node (MN) is
attached to the target MAG. The context transfer mechanism defined
in this specification can implicitly serve as a trigger to create a
temporary tunneling (read, localized routing) between MAGs for the
period prefixes/addresses from the source MAG are used under the
target MAG.
Additionally, using the context transfer information the target MAG
can take required actions to deprecate those prefixes/addresses that
belong to the source MAG. The specified mechanism is a complementary
for Simple Procedures for Detecting Network Attachment in IPv6 (DNA)
[RFC6059]. Explicit network side prefix/address deprecation is
useful in situations, for instance, when the MN does not implement
DNA or there is a need to trigger DHCPv6 Reconfigure procedure
[RFC3315] when the MN attaches to the target MAG.
[Discussion: it is to be verified whether the existing PMIPv6
Localized Routing protocol [RFC6705] with small enhancements is
appropriate for the temporary tunneling between MAGs for the
purpose this specification has.]
Locally assigned prefixes/addresses that are topologically anchored
to the MAG allow for optimized access to local resources near the
MAG. This, of course, assumes the MAG is able to route certain
traffic locally bypassing the PMIPv6 tunnel, and the MN is able to
detect which prefixes/addresses are local or have mobility
[I-D.korhonen-6man-prefix-properties][I-D.bhandari-dhc-class-based-pr
efix].
2. Solution Overview
The protocol solution in this specification is targeted to the
following use case and illustrated in Figure 1. Additional use cases
outside the IP mobility domain are discussed extensively in
Korhonen, et al. Expires January 30, 2014 [Page 3]
Internet-Draft Local Prefix Management July 2013
[I-D.lepape-6man-prefix-metadata].
o A MN is assigned with multiple prefixes that it uses to configure
multiple IPv6 addresses.
o Some of the prefixes/addresses assigned to the MN are anchored at
the Local Mobility Anchor (LMA) and provide mobility within the
PMIPv6 domain.
o Some of the prefixes/addresses assigned to the MN are local to the
MAG the MN is currently attached to. These prefixes/addresses
provide mobility only in a limited area, for example, within the
layer-2 domain under the MAG control.
o When the MN moves from a MAG (i.e., a source MAG) to another MAG
(i.e., a target MAG), the prefixes/addresses anchored to the LMA
remain but the prefixes/addresses anchored to a MAG will change.
The prefixes/addresses are topologically only valid under the MAG
they are anchored to.
o If DHCPv6 is used for configuring addresses to the MN, then the
DHCPv6 server is collocated in the LMA.
+----------------------> Internet
| ^
| : mobility
| | (Prefix_z)
| +-----+
| | LMA |
| +-----+
+---+ +---+ | +---+
|rtr| |CNx| | |CNy|
+---+ +---+ | +---+
| | | |
---+---------+------+ +--------+--------+ +-----+-----
local | | | | local
network | | | | network
(Prefix_x) +---+ +---+ (Prefix_y)
|src| temporary |tgt|
|MAG|===============|MAG|
+---+ tunnel +---+
: :
+--+ +--+
|MN|--------------->|MN|
+--+ handover +--+
Figure 1: Local services provided topologically close to a MAG
Korhonen, et al. Expires January 30, 2014 [Page 4]
Internet-Draft Local Prefix Management July 2013
In order to provide a mechanism for a source MAG to inform the target
MAG about prefixes the MN might have configured and that are
topologically valid only under the source MAG, there is a need for a
context transfer of locally assigned prefix/address information
between MAGs. This specification extends both the PMIPv6 signaling
and the Binding Cache in the LMA with a local prefix/address
information.
During the Proxy Binding Update (PBU) and the Proxy Binding
Acknowledgement (PBA) exchange, MAGs and the LMA inform each other
about locally assigned prefixes/addresses. Using that information, a
target MAG can do the following two things:
o Make sure the prefixes/addresses from the source MAG get
deprecated and eventually invalidated using some mechanism (that
essentially does not require end host stack changes).
o Optionally create of a temporary tunnel between the source and the
target MAG, and setting up the required host routes for routing
addresses belonging to the source MAG back and forth until the
addresses become invalid.
3. Mobility Options
A MAG uses the Local Prefix mobility option (LPO) to inform the LMA
of the IPv6 prefix/address and its valid lifetime (see [RFC4861] and
[RFC3315]) that shall be locally assigned to a MN. After a handover
an LMA uses the option to inform a target MAG of the IPv6 prefix/
address that was assigned to a MN by the previous MAG. The Local
Prefix option has an alignment of 4n. There can be zero or more LPOs
in a PUB and in a PBA.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD1 | Length=22 | Prefix Length |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Local Prefix/address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Local Prefix Mobility Option
Korhonen, et al. Expires January 30, 2014 [Page 5]
Internet-Draft Local Prefix Management July 2013
Type:
Set to TBD1.
Length:
The length of the Local Prefix mobility option in octets,
excluding the Option Type and Length fields. The length is set to
22.
Prefix Length:
The prefix length of the local IPv6 prefix. Valid prefix lengths
are between 1 and 128. In case of an IPv6 address the prefix
length is 128.
'R':
Set to 1 if the sender of the LPO wants the receiver to deprecate/
invalidate/remove the prefix/address. Otherwise set to 0.
Reserved:
This field is reserved for future use. MUST be set to zero by the
sender and ignored by the receiver.
Valid Lifetime:
The valid lifetime of the IPv6 prefix/address. The value follows
the valid lifetime semantics of Prefix Information Option
[RFC4861] and OPTION_IAADDR option [RFC3315].
Local Prefix/address:
The locally assigned IPv6 prefix/address.
4. Mobile Access Gateway Operation
4.1. Extensions to Binding Update List Entry Data Structure
The Binding Update List Entry (BULE) data structure for each MN's
mobility binding with its LMA is extended with zero or more locally
assigned IPv6 prefix/address, and its lifetime information.
Korhonen, et al. Expires January 30, 2014 [Page 6]
Internet-Draft Local Prefix Management July 2013
4.2. Local Prefix/Address Assignment
A MAG maintains a pool of locally usable prefixes/addresses. If the
'EnableLocalPrefixManagement' configuration object is set to TRUE,
then the MAG assigns one or more local prefixes/addresses to the MN
during the initial attach. Essentially the MAG adds new Local Prefix
Mobility Options into the Proxy Binding Update (PBU) message, and
eventually advertises those prefixes to the MN when using Stateless
Address AutoConfiguration (SLAAC).
4.3. Local Use of Prefixes/Addresses
The local prefixes/addresses are topologically anchored to the MAG,
and do not really provide mobility in a same level as PMIPv6 provides
for Home Network Prefixes (HNP) anchored to the LMA. This
specification also requires the MAG is provided with a functionality
that certain traffic can bypass the PMIPv6 tunnel in the MAG. Such
functionality is already hinted in [RFC5213] Section 6.10.3.
However, this specification further assumes the local corresponded
nodes do not need to be directly on the access link connected to the
MAG. They can be any number of IP hops away.
There is no restriction on the scope of the local prefixes/addresses.
A MN could use local addresses to the MAG as its source address to
access the Internet, assuming local addresses have a global scope.
Similarly, the MN could use the home address anchored to the LMA to
reach local destinations around the MAG.
4.4. Local Prefixes/Addresses Management
After a MN has moved from a source MAG to a target MAG as a result of
a handover, the MN might be configured with prefixes/addresses that
topologically belong to the source MAG. In this case, the target MAG
may purposely need to deprecate and invalidate or otherwise handle
prefixes/addresses that are topologically in a wrong place (i.e., are
anchored to the source MAG). We could assume that the DNA [RFC6059]
handles this but explicit actions by the target MAG make sure that
MNs without DNA support are also covered.
4.4.1. Deprecating Prefixes/Addresses
A target MAG receives information of prefixes/addresses that are not
valid under the target MAG in LPOs included in a PBA from a LMA. If
SLAAC is used to configure addresses to a MN, then the target MAG
SHOULD deprecate prefixes from the source MAG by sending a Router
Advertisement with a Prefix Information Option (PIO) and set at least
the preferred lifetime to zero (0). The valid lifetime is set to
value received in the corresponding LPO. If e.g. SeND [RFC3971] is
Korhonen, et al. Expires January 30, 2014 [Page 7]
Internet-Draft Local Prefix Management July 2013
used, then the valid lifetime can also be set to zero (0).
4.4.2. Temporary Tunneling Between Mobile Access Gateways
During the handover from a source MAG to a target MAG, it might not
be possible to make the MN to discard all addresses in use that
belong to the source MAG. This is the case, for example, when the MN
does not implement the DNA functionality and the valid lifetime of
the prefixes is still greater than zero. In this case, it would be
beneficial to establish a temporary tunnel for the local addresses
from the source MAG to the target MAG for the period the valid
lifetime of the prefixes expires. The temporary tunnel would be
removed immediately when valid lifetime of the local prefix from the
source MAG expires. Whether the target MAG initiates the creation of
the temporary tunnel between MAGs is controlled by the
'EnableTemporaryLocalizedRouting' configuration object.
[Discussion: it is to be verified whether [RFC6705] is usable for
this purpose and whether it has to be extended to cover the above use
case or do we need to develop a new one.]
4.4.3. Informing a Mobile Node of an Inoperable Prefix/Address
If tunneling between MAGs as described in Section 4.4.2 is not an
option, then the target MAG SHOULD respond to all IP packets a MN
originates with an address belonging to the source MAG with an ICMPv6
error Destination Unreachable Message and set the Code to 5 (Source
address failed ingress/egress policy) [RFC4443]. The configuration
SHOULD remain active until the valid lifetime received from the
corresponding LPO expires.
5. Local Mobility Anchor Operation
5.1. Extensions to Binding Cache Entry Data Structure
The Binding Cache Entry (BCE) data structure for each currently
registered MN is extended with zero or more locally assigned IPv6
prefix/address and its valid lifetime pairs. The prefix/address in
the Local Prefix mobility option MUST NOT be used as a BCE look up
key.
5.2. Local Prefix/Address Context Transfer
The operation of the LMA is fairly simple. When the LMA received a
PBU and the BCE for the MN has no prior knowledge of a local prefix/
address information learned from the received LPO option, then the
LMA:
Korhonen, et al. Expires January 30, 2014 [Page 8]
Internet-Draft Local Prefix Management July 2013
o Records the prefix/address into the BCE.
o Records the valid lifetime of the prefix/address into the BCE.
o Echoes the prefix/address, the valid lifetime and 'R' set to 0
information back to the MAG in the LPO option included in the PBA.
If the BCE for the MN has existing local prefix/address information
learned from the received LPO option, then the LMA:
o Records the new prefix/address into the BCE.
o Records the new valid lifetime of the prefix/address into the BCE.
o Returns the old prefix/address, the valid lifetime and 'R' set to
1 information back to the MAG in the LPO option included in the
PBA.
5.3. Local Prefixes/Addresses Management
After a MN has moved from a source MAG to a target MAG as a result of
a handover, the MN might be configured with prefixes/addresses that
topologically belong to the source MAG. If DHCPv6 was used to
configure addresses to the MN, then the LMA SHOULD initiate the
DHCPv6 Reconfigure procedure towards the MN immediately after sending
the PBA to the target MAG. If SLAAC was used to configure addresses
to the MN, then the LMA does not need to do anything beyond what has
already been done in Section 5.2.
6. Signaling Flow Examples
6.1. Stateless Address AutoConfiguration Example
Figure 3 shows example PMIPv6 signaling for the initial attachment to
the PMIPv6 domain and a handover with locally assigned prefixes and
when the stateless autoconfiguration (SLAAC) [RFC4862] is used for
configuring addresses.
In the following figure 'PIO' stands for Prefix Information Option
[RFC4861] in a Router Advertisement, 'p' means the preferred lifetime
in a PIO, and 'v' means the valid lifetime in a PIO. 'lp1' stands for
local prefix 1 and 'lt1' for its valid lifetime. Similarly 'lp2'
stands for local prefix 2 and 'lt2" for its valid lifetime. 'lp1' is
different from 'lp2'.
Korhonen, et al. Expires January 30, 2014 [Page 9]
Internet-Draft Local Prefix Management July 2013
[MN] [MAG_1] [MAG_2] [LMA]
| | | |
|--- Rtr Sol --->| | |
| | | |
| MAG_1 assigns local | |
| IPv6 prefix lp1 | |
| | | |
| |--- PBU ------------------------>|
| | LPO=lp1/lt1/R=0, |
| | HNP=0, | LMA records
| | HI=1, ... | lp1/lt1, assigns
| | | HNP pref
| | | |
| |<-- PBA -------------------------|
| | LPO=lp1/lt1/R=0, |
|<-- Rtr Adv ----| HNP=pref, ... |
| PIO=pref, | | |
| PIO=lp1/p=lt1/v=lt1 (new) | |
| | | |
.... handover takes place ....
| | | |
|--- Rtr Sol -------------------->| |
| | | |
| | MAG_2 assigns local |
| | IPv6 prefix lp2 |
| | | |
| | |--- PBU ------->|
| | | LPO=lp2/lt2/R=0,
| | | HNP=0, HI=3,|
| | | ... |
| | | lp2 != lp1, thus
| | | LMA records
| | | lp2/lt2, returns
| | | previous lp1/lt1
| | | |
| | |<-- PBA --------|
|<-- Rtr Adv ---------------------| LPO=lp1/lt1/R=1,
| PIO=pref, | | HNP=pref, ...
| PIO=lp2/p=lt2/v=lt2, (new) | |
| PIO=lp1/p=0/v=lt1 (old) | |
| | | |
Figure 3: Local prefix assignment and lifetime management example
using SLAAC
Korhonen, et al. Expires January 30, 2014 [Page 10]
Internet-Draft Local Prefix Management July 2013
6.2. Stateful Address Configuration Example
Figure 4 shows example PMIPv6 signaling for the initial attachment to
the PMIPv6 domain with locally assigned prefixes and when the
stateful address configuration (DHCPv6) is used for configuring
addresses.
In the following figures 'p' means the preferred lifetime in an IA_TA
or IA_NA, and 'v' means the valid lifetime in an IA_TA or IA_NA
respectively. Also, 'la1' stands for local address 1 and 'lt1' for
its valid lifetime. Similarly 'la2' stands for local address 2 and
'lt2" for its valid lifetime. 'la1' is different from 'la2'. The
'IA_xA' stands for either IA_TA or IA_NA.
[MN] [MAG_1/Relay] [DHCPv6-S ~ ~ ~ ~ ~ LMA]
| | | |
|--- Rtr Sol --->| | |
| | | |
| MAG_1 assigns local | |
| IPv6 address la1 | |
| | | |
| |--- PBU ------------------------>|
| | LPO=la1/R=0,| |
| | HNP=0, | LMA records
| | HI=1, ... | la1, assigns
| | | HNP pref
| | | |
| |<-- PBA -------------------------|
|<-- Rtr Adv ----| LPO=la1/lt1/R=0, |
| M=1, ... | HNP=pref, | |
| | ... | |
| | | |
|--- Solicit --->| Relay adds | |
| | link-addr=pref | |
| | | |
| |--- Relay-f --->| DHCPv6 server |
| | | adds IA_xA with|
| | | la1/p=lt1/v=lt1,
| | | HoA based on pref,
| | | Reconfigure Accept,
| | | ... |
| |<-- Relay-r ----| |
|<--- Advert or -| | |
| Reply | | |
| | | |
| ... DHCPv6 negotiation may continue...
| | | |
Korhonen, et al. Expires January 30, 2014 [Page 11]
Internet-Draft Local Prefix Management July 2013
Figure 4: Local prefix assignment example using stateful DHCPv6
Figure 5 shows example PMIPv6 signaling for a handover with locally
assigned prefixes and when the stateful address configuration
(DHCPv6) is used for configuring addresses.
[MN] [MAG_2/Relay] [DHCPv6-S ~ ~ ~ ~ ~ LMA]
| | | |
.... handover takes place ....
| | | |
[ |--- Rtr Sol --->| ] | |
| | | |
| MAG_2 assigns local | |
| IPv6 address la2 | |
| | | |
| |--- PBU ------------------------>|
| | LPO=la2/lt2/R=0, |
| | HNP=0, | la2 != la1, thus
| | HI=3, ... | LMA records
| | | la2/lt2, returns
| | | previous la1/lt1/R=1
| | | |
| |<-- PBA -------------------------|
[ |<-- Rtr Adv ----| ] LPO=la1/lt1/R=1, |
| M=1, ... | HNP=pref, | |
| | ... | |
| | | |
|<-- Reconfigure ----------------------------------|
| IA_xA, | | |
| ... | | |
| | | |
|--- Renew --------------------------------------->|
| IA_xA with | | |
| HoA, | | DHCPv6 server
| la1, | | adds IA_xA with
| ... | | la1/p=0/v=0,
| | | la2/p=lt2/v=lt2,
| | | HoA, |
| | | ... |
| | | |
|<-- Reply ----------------------------------------|
| ... | | |
| | | |
Figure 5: Local prefix change example using stateful DHCPv6 during a
handover
Korhonen, et al. Expires January 30, 2014 [Page 12]
Internet-Draft Local Prefix Management July 2013
7. Configuration Objects
This specification defines two configuration objects.
EnableLocalPrefixManagement
This configuration object is available in both a MAG and in a LMA.
When set to TRUE (i.e., enabled), the PMIPv6 node enables the
local IPv6 prefix/address lifetime management functionality. The
default value is FALSE (i.e., disabled).
EnableTemporaryLocalizedRouting
This configuration object is available in both a MAG and in a LMA.
When set to TRUE (i.e., enabled), the MAG or the LMA MAY initiate
the localized routing (tunnel) [RFC6705] for the period locally
meaningful prefixes from the previous MAG are still valid. The
default value is FALSE (i.e., disabled).
8. Security Considerations
The security considerationf for the Proxy Mobile IPv6 [RFC5213]
apply. Furthermore, generic security threats regarding the address/
prefix ownership also apply [RFC3971]. An attacker can make use of
unprotected Router Advertisements to interfere the address selection
the MN does and in that way hijact traffic. This requires that the
attacker is albe to gain access to the same link the victim host is.
[Editor's Note: security considerations to be imporved.]
9. IANA Considerations
One new mobility options for the use with PMIPv6 is defined in the
[RFC6275] "Mobility Options" registry. The mobility option is
defined in Section 3:
Local Prefix Mobility Option is set to TBD1
10. Acknowledgements
We ack.
11. References
Korhonen, et al. Expires January 30, 2014 [Page 13]
Internet-Draft Local Prefix Management July 2013
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
11.2. Informative References
[I-D.bhandari-dhc-class-based-prefix]
Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
based prefix", draft-bhandari-dhc-class-based-prefix-05
(work in progress), July 2013.
[I-D.korhonen-6man-prefix-properties]
Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
Liu, "IPv6 Prefix Properties",
draft-korhonen-6man-prefix-properties-02 (work in
progress), July 2013.
[I-D.lepape-6man-prefix-metadata]
Pape, M., Systems, C., and I. Farrer, "IPv6 Prefix Meta-
data and Usage", draft-lepape-6man-prefix-metadata-00
(work in progress), July 2013.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Korhonen, et al. Expires January 30, 2014 [Page 14]
Internet-Draft Local Prefix Management July 2013
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059,
November 2010.
[RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
Dutta, "Localized Routing for Proxy Mobile IPv6",
RFC 6705, September 2012.
Authors' Addresses
Jouni Korhonen
Renesas Mobile
Porkkalankatu 24
FIN-00180 Helsinki
Finland
Email: jouni.nospam@gmail.com
Teemu Savolainen
Nokia
Hermiankatu 12 D
FI-33720 Tampere
FINLAND
Email: teemu.savolainen@nokia.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Korhonen, et al. Expires January 30, 2014 [Page 15]