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]