Network Working Group D. Damic [Ed.] Internet-Draft Nokia Siemens Networks Intended status: Standards Track March 02, 2009 Expires: September 3, 2009 Proxy Mobile IPv6 indication and discovery draft-damic-6man-pmip6-ind-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 September 3, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Damic [Ed.] Expires September 3, 2009 [Page 1] Internet-Draft draft-damic-6man-pmip6-ind March 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Proxy Mobile IPv6 (PMIPv6) is a network-based mobility protocol that enables mobility management for an IP host as it moves across different points of attachment within the mobility domain. An IP host whose mobility is being managed by the network is unaware of the access networks capability providing PMIPv6 mobility management on its behalf. This draft proposes mechanisms by which the host is informed of PMIPv6, as well as means to actively discover such capability in the network the host is attaching to. The ability of the host to discover or be aware of PMIPv6 support in the access network enables better decision making in terms of the network selection, attach procedure, choice of mobility management, as well as the service/session and even application configuration abilities. Damic [Ed.] Expires September 3, 2009 [Page 2] Internet-Draft draft-damic-6man-pmip6-ind March 2009 Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 6 4.1. PMIP6 indication in the Router Advertisment . . . . . . . 6 4.2. Alternate Prefix Information Option . . . . . . . . . . . 7 4.3. Router Solicitation Client-based Mobility Flag . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Damic [Ed.] Expires September 3, 2009 [Page 3] Internet-Draft draft-damic-6man-pmip6-ind March 2009 1. Introduction and Scope Proxy Mobile IPv6 [RFC5213] is a network-based mobility management protocol which does not require any signaling from the mobile node to enable IP mobility as the node moves and changes its point of attachment. PMIP6 is based on Mobile IPv6 [RFC3775] principles albeit the fact that the host is not involved in the mobility management. The network-based mobility management concept rapidly established itself as the prevailing, and for PMIPv6, most widespread IPv6 mobility solution in all emerging next-generation wireless networks. Alongside acknowledged benfits of network-based IP mobility, issues arise with respect to coexistence of multiple and concurrent IP mobility schemes within the same network or domain. This memo provides reasoning and mechanisms that allow an IPv6 mobile node become aware of PMIPv6 support presence in the network as means to enhance network selection and IP session management processes. The proposed principle of network-based IP mobility indication does not require active participation from the mobile, it simply aims to provide information of the specific network capability that may come valuable to the mobile host, regardless if the host itself is Mobile IP capable or not. Such information may help the mobile host choose the right target network, furthermore select and configure mobility scheme and overlaying IP service or application, potentially optimize use of host & network resources, etc. When the mobile host is a Mobile IPv6 capable device, the host may choose not to have the network perform mobility management on its behalf, via Proxy Mobile IPv6. Or other way around, host can delegate IP mobility management to the network on purpose. There are several scenarios in which host-based Mobile IP and Proxy MIP support co-exist in the same network. Deployment scenarios may include a broader scope than a single domain, in particular considering inter- technology IP handovers and interworking between different access techonologies. Two cases are described below, and a more exhaustive interactions analysis can be found in [I-D.ietf-netlmm-mip-interactions]: o Simultaneous support for different mobility modes: The operator may wish to support mobility services for hosts which do not include MIP client functionality, as well as those implementing Mobile IP within a single network domain. Discovery of the capabilities of the host and the network enables appropriate services to be correctly triggered for all types of hosts attaching to the domain. Damic [Ed.] Expires September 3, 2009 [Page 4] Internet-Draft draft-damic-6man-pmip6-ind March 2009 o Session continuation accros different domains: Mobile node roaming in/out of the PMIP6 domain aims to continue the ongoing session either retaining or substituting the assigned mobility mode. For example, MN running a MIP6 session in the network moves to a PMIP6-enabled domain. Depending on the privileges and policies, the session may either continue by using host-based mobility, or the network would take over the mobility management and begin/continue handling the MN in the PMIP6 mode. Existing IPv6 mechanism in form of the Neighbor Discovery protocol (NDP) is currently insufficient for the purpose of mobility mode detection or capability negotiation. This document proposes means by which the network can advertise PMIP6 capability and service being provided in the network, and provide specific configuration parameters to the IPv6 mobile nodes. The proposal also provides a method by which the MN can proactively participate in mobility mode selection by sending the explicit mode indication. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. PMIP6 prefix Prefix assigned to the MN while residing within the PMIP6 domain. The prefix is topologically anchored at the LMA, thus providing IP session continuity all throughout that LMA domain. Depending on the mobility scope, this prefix can be assigned by the LMA or some other mechanism. Local (on-link) prefix Topologically correct IPv6 prefix available for address autoconfiguration within the local domain, for example valid within a scope of a single AR/MAG. 3. Problem Statement A host which attaches to the network which is a part of a PMIP6 domain may use stateless address autoconfiguration (SLAAC) to configure its addresses. The type of prefix advertised to the host or configuration parameters returned to it may vary depending on variables such as policy, host preference, host capability etc. In case PMIP6 is used as a mechanism for managing mobility or for emulating the home link to the MN, the network obtains the home Damic [Ed.] Expires September 3, 2009 [Page 5] Internet-Draft draft-damic-6man-pmip6-ind March 2009 prefix for the MN and provides the same to the MN. Prefix is assigned to the MN for the entire session, and must be consistently advertised throughout the entire PMIP6 domain. For MIP6 capable nodes it is sufficient to supply any globallly routable local prefix/ address that the MN will use to configure the care-of address (CoA) on its interface. At the point when network allocates the address/prefix for the given mobile, or the Access Router begins advertising the specific IPv6 prefix information the network is unaware of the capability of the MN which is attempting to attach to the AR: NDP messages as defined today can not serve as specific PMIP6 mobility triggers. Furthermore, the profile associated with a user in AAA in not sufficient for deciding about the mobility protocol for that MN as the device and terminal capabilities may change. For example: Profile or policy parameters associated with a subscriber authorizing PMIP6 service cannot be used in triggering network mobility since the capability of the host or preference cannot be determined. The AR or MAG in the access network should anticipate different types of IPv6 mobility services and terminals, and make sure the correct service is assigned to the mobile node. The network should take into account mobility preference of the mobile, in case such information is provided beforehand, in the router solicitation (RS). Explicit mechanisms and protocol extensions are needed to: o enable the access network to advertise the PMIP6 support to the MN o provide the MN with more reliable parameters allowing it to choose the mobility protocol based on its capabilities or other criteria o allow MNs to indicate their mobility mode preferences 4. Proposed Solutions This document proposes extensions to the NDP protocol that may serve as triggers for PMIP6 mobility selection. The proposed extensions include: a new indication flag in the RA, new prefix information option for the Router Advertisement, and the flag extention to the Router Solicitation messages. 4.1. PMIP6 indication in the Router Advertisment As per [RFC5075] the AR should use the Flags Expansion option to further extend the flags field of the Router Advertisement message. This memo proposes the AR SHOULD use this RA expansion option to explicitly indicate mobility managemenet capabilities of the access nework. By setting the "N" flag in the Flags Expansion option, AR Damic [Ed.] Expires September 3, 2009 [Page 6] Internet-Draft draft-damic-6man-pmip6-ind March 2009 advertises its capability for network-based mobility management (i.e., PMIP6 support). 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 | Length |N| Bit fields available .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... for assignment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. RA Flags Expansion option with the PMIP6 indication Type Type - 8-bit identifier of the option type To be assigned by IANA, as indicated in [RFC5075] Length Length = 1; The length MUST be checked when processing the option in order to allow for future expansion of this option if the need arises. Bits Router Advertisement bit 8 - the "N" flag (To be assigned by IANA.) This bit is set by the AR to indicate the access network supports network-based mobility management, i.e., PMIP6. Other bits are available for further assignment. 4.2. Alternate Prefix Information Option The AR is allowed to include multiple IPv6 prefixes in the single RA message where each prefix is contained in an own Prefix Information Option [RFC4861]. In case the access network supports PMIP6, the AR MAY chose to simultaneoulsy advertise local on-link IPv6 prefixes, as well as the individual PMIP6 prefix for that MN. For this specific case, the two different types of prefixes SHOULD be cleary differentiated. The Alternate Prefix Information Option shall provide host with additional prefix information for the purpose of stateless IPv6 address autoconfiguration. In case the network supports multiple mobility service types, the AR may provide alternative option to the mobile node leaving the choice of the mobility service to the Damic [Ed.] Expires September 3, 2009 [Page 7] Internet-Draft draft-damic-6man-pmip6-ind March 2009 terminal. In order to make use of the service indication and selection, the MN has to be enhanced for processing of the new Alternate Prefix Information option. Mobile nodes that are capable of processing the Alternate Prefix Information option should use the obtained information according to internal configuration and policy to decide whether to configure PMIP6 MN-HoA or MIP6 CoA on its network interface. Node incapable of understanding the Alternate Prefix option SHALL ignore it. The format of the option supports regular operation and backwards compatibility for all legacy terminals by allowing flexibility in prefix assignment. Depending on the network policy and capabilities, the AR can advertise on-link prefixes, or the PMIP6 prefix as default information within the Prefix Information Option. By specifying the Prefix Type, the alternative prefix information can then be provided in the new option. 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 | Length | Prefix Length |L|A| |Pr.Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Alternate Prefix Information Option Fields: Type 8-bit identifier for the Alternate Prefix Information option (to be assigned by IANA). Damic [Ed.] Expires September 3, 2009 [Page 8] Internet-Draft draft-damic-6man-pmip6-ind March 2009 Length 4 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. L 1-bit on-link flag. Use of the flag as defined in [RFC4861]: When set, indicates this prefix can be used for on-link determination, when not set the advertisement makes no statement about on-link or off-link properties of the prefix. . A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for stateless address configuration as specified in [RFC4862]. Prefix Type 4-bit unsigned field. The field indicates the type of the prefix provided in the payload. Allowed values: 0 On-link IPv6 prefix bound to the first hop AR 1 PMIPv6 prefix anchored at the associated LMA Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity. The Valid Lifetime is also used by [RFC4862]. Preferred Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred. A value of all one bits (0xffffffff) represents infinity. See [RFC4862]. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Damic [Ed.] Expires September 3, 2009 [Page 9] Internet-Draft draft-damic-6man-pmip6-ind March 2009 IPv6 Prefix An IPv6 address or a prefix of an IPv6 address. The length of the prefix is given by the Prefix Length field, and the purpose of the prefix is defined by the Prefix Type field. A router SHOULD NOT send a prefix option for the link-local prefix and a host SHOULD ignore such a prefix option. Description: The Alternate Prefix Information option provides host with an additional prefix information for stateless address autoconfiguration. Respective of the prefix already provided in the regular Prefix, this option may contain either the topologically correct on-link prefix (type set to 0), or the PMIPv6 prefix (type 1) for the purpose of establishing network-based mobility management. The option appears in Router Advertisement packets only and MUST be silently ignored for other messages. 4.3. Router Solicitation Client-based Mobility Flag If a mobile node that chooses or prefers to do its own mobility signaling enters a PMIPv6 network it cannot do so since the PMIP domain makes the MN believe that it is in fact in its home network. This section describes a mechanism by which a mobile node in a PMIPv6 network can signal to the PMIPv6 network whether it would like to make use of the Proxy Mobility service or not. This document modifies the format of the Router Solicitation Message specified in [RFC4861] to include a new client-based mobility flag. As a result of this the router solicitation message format will look like the following figure: 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 3. Client-based mobility flag in the Router Solicitation ICMP Fields: Damic [Ed.] Expires September 3, 2009 [Page 10] Internet-Draft draft-damic-6man-pmip6-ind March 2009 Type 133 Code 0 Checksum The ICMP checksum. See [RFC4443] C If this bit is set, it means that the sending MN would like to perform its own signaling. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. A mobile node that utilises this mechanism and wants to perform its own signaling, MUST set the C bit to one. The MAG that receives it SHOULD respond with a Router Advertisement containing a topologically correct prefix for the link (i.e., Not the emulated PMIPv6 prefix). MNs which are not aware of this specification will not set the C bit and hence the MAG would provide them with proxy mobility service. MAGs not aware of this bit when a client sets the C bit to 1 will ignore it as specified in [RFC4861]. Hence there are no backward compatibility issues 5. Security Considerations The mechanisms described in this document use neighbor discovery messages to communicate mobility preferences and indications between the MN and the network. An on-link attacker can send spoofed router advertisements and spoofed router solicitation in order to deny mobility service to the node. The usage of SEND [RFC3971] could prevent this from happening. 6. IANA Considerations The following Extension Types MUST be assigned by IANA: o PMIP6 "N" indication flag in RA flags expansion option o Alternate Prefix Information Option type Damic [Ed.] Expires September 3, 2009 [Page 11] Internet-Draft draft-damic-6man-pmip6-ind March 2009 o Client-based mobility flag for RS message 7. Contributors Domagoj Premec Nokia Siemens Networks Heinzelova 70a 10000 Zagreb, Croatia +385 1 6105 923 domagoj.premec.ext@nsn.com Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039, US basavaraj.patil@nokia.com Meghana Sahasrabudhe Nokia Siemens Networks 313 Fairchild Drive Mountain View, CA 94043, US meghana.sahasrabudhe@nsn.com Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC, Canada +1 514 345 7900 x42871 suresh.krishnan@ericsson.com 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [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, Damic [Ed.] Expires September 3, 2009 [Page 12] Internet-Draft draft-damic-6man-pmip6-ind March 2009 September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5075] Haberman, B. and R. Hinden, "IPv6 Router Advertisement Flags Option", RFC 5075, November 2007. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 8.2. Informative References [I-D.ietf-netlmm-mip-interactions] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-ietf-netlmm-mip-interactions-02 (work in progress), February 2009. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Author's Address Damjan Damic Nokia Siemens Networks Heinzelova 70a Zagreb 10000 Croatia Phone: +385 1 6331 337 Email: damjan.damic.ext@nsn.com Damic [Ed.] Expires September 3, 2009 [Page 13]