Network Working Group D. Damic Internet-Draft D. Premec Intended status: Standards Track B. Patil Expires: December 9, 2007 M. Sahasrabudhe Nokia Siemens Networks June 7, 2007 Proxy Mobile IPv6 indication and discovery draft-damic-netlmm-pmip6-ind-discover-00.txt 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 December 9, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Proxy Mobile IPv6 is a network-based mobility protocol and is able to manage the mobility of an IP host as it moves across different points of attachment within the mobility domain. The IP host whose mobility is being managed by the network is unaware of the existence of Proxy Mobile IPv6 in the network or mobility being managed on its behalf. This draft proposes mechanisms by which the host is informed of proxy Damic, et al. Expires December 9, 2007 [Page 1] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 mobile IPv6 support in a network that it attaches to as well as the ability for the host to discover such capability in the attached network. The ability of the host to discover or be aware of proxy mobile IPv6 support in the network enables better decision making in terms of the type of mobility protocol used for IP mobility. Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Router Advertisment extension . . . . . . . . . . . . . . 5 4.2. Router Solicitation extension . . . . . . . . . . . . . . 7 4.3. DHCPv6 extensions . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Home Network Identifier Option . . . . . . . . . . . . 9 4.3.2. Home Network Information Option . . . . . . . . . . . 10 4.3.3. Note on DHCPv4 . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Damic, et al. Expires December 9, 2007 [Page 2] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 1. Introduction and Scope Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is a network-based mobility management protocol in which the host is not involved in any signaling to enable IP mobility as it moves and changes its point of attachment. This feature complements the mobility protocols such as Mobile IPv6 [RFC3775] in which the host is involved in mobility management. On the other hand, nodes that are capable for mobility management themselves (i.e., implement the MIP6 functionality in the IP stack) might not require such kind of service. PMIP6 protocol as specified in [I-D.ietf-netlmm-proxymip6] is applicable within the scope of a single PMIP6 domain. However deployment scenarios may include a broader scope than a single domain. Scenarios where mobility is managed by the network are usually referred as running in Proxy MIP (PMIP) mode. Analogously, when mobile nodes manage mobility themselves we are talking about host- based mobility. There are several scenarios in which host-based Mobile IP and proxy MIP support co-exist in the same network. For example: o Different mobility modes within a single PMIP6 domain: In case of nomadic users, the network needs to provide mobility services simultaneously for nodes with and those without the built-in mobility support. Each mobility mode, either PMIP6 or host-based MIP6, needs to be individually recognized and appropriately handled by the network. o Session continuation accros different domains: Mobile node roaming in/out of the PMIP6 domain needs 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 should either continue with the host-based mobility, or the network would take over the mobility management and begin handling the MN in the PMIP6 mode. Existing IPv6 mechanisms, such as Neighbor Discovery protocol (NDP) or DHCPv6, are currently insufficient for the purpose of mobility mode detection or capability negotiation. This document proposes means by which the network can indicate its PMIP6 capabilities and provide specific configuration parameters to mobile nodes. The proposal also provides a method by which the MN can proactively choose the mobility management scheme. Damic, et al. Expires December 9, 2007 [Page 3] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 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]. 3. Problem Statement In the PMIP6 domain MN may use stateless address autoconfiguration (SLAAC) or DHCPv6 to configure its addresses. The address configuration parameters provided to the MN MAY be different in cases when supporting PMIP6 or host-based MIP6. In case PMIP is used as a mechanism for global mobility or for emulating the home link to the MN, the network obtains the home 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 MN will use to configure the care-of address (CoA) on its interface. The AR or MAG in an access network should be able to interpret the mobility preference and capability of the host via either the router solicitation (RS) or DHCP request received from the MN. NDP and DHCP messages cannot be used as specific mobility triggers. The Profile associated with a user in AAA for example cannot really be used as an indication about the mobility protocol to be used for a host as the device and capability may change. For example: information that subscriber is allowed PMIP6 does not provide indication on what kind of terminal subscriber is actually using (does it implement MIP6), or is it aiming to utilize host-based mobility. Explicit mechanisms and protocol extensions are needed to: o enable the access network to advertise the PMIP6 feature or function to hosts o provide the host with more reliable parameters allowing it to choose the mobility protocol based on its capabilities or other criteria o allow MNs to signal their mobility mode preferences 4. Proposed Solutions This document proposes extensions to the NDP and DHCP protocols that may serve as triggers for PMIP6 mobility selection. These extensions Damic, et al. Expires December 9, 2007 [Page 4] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 include: a new flag in the RA Prefix Information Option, a new option for the Router Solicitation message, and new options for the DHCP messages. 4.1. Router Advertisment extension The AR can include multiple on-link prefixes in one RA message, where each individual prefix is contained in the Prefix Information Option. In case the access network does support PMIP6, the AR could advertise this capability in the RA messages it sends. Within its domain, the AR may advertise PMIP6 prefixes as default. In some occasions along with the specific PMIP6 prefix, the advertised prefix list should include local scope IPv6 prefix(es) as well. In order to specifically indicate a PMIP6 local prefix, the AR should set a specific "P" flag in the Prefix Information Option header. When this flag is set, it indicates network supporting PMIP6 is providing additional prefix with a local scope validity. Mobile nodes which are capable of processing the extended Prefix Information option can configure their care-of address using this prefix, and thereby continue with host-based mobility management while roaming through the PMIP6 domain. 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|P|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Prefix Information Option containing PMIP6 flag Fields: Damic, et al. Expires December 9, 2007 [Page 5] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 Type 3 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. When set, indicates that 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. For instance, the prefix might be used for address configuration with some of the addresses belonging to the prefix being on-link and others being off-link A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for autonomous address configuration as specified in [RFC2462]. P 1-bit PMIP6 local-prefix flag. When set indicates the option contains a PMIP6 local prefix, valid for configuration of a local IPv6 address or a MIP6 CoA. Reserved1 6-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 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 [RFC2462]. 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 Damic, et al. Expires December 9, 2007 [Page 6] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 [RFC2462]. A value of all one bits (0xffffffff) represents infinity. See [RFC2462]. Reserved2 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Prefix An IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. A router SHOULD NOT send a prefix option for the link- local prefix and a host SHOULD ignore such a prefix option. In case "P" flag has been set, the Prefix field contains the PMIP6 HNP. Description: The Prefix Information option provide hosts with on-link prefixes and prefixes for Address Autoconfiguration. In case "P" flag is set, the option provides the HNP for PMIP6 MN-HoA Address Autoconfiguration. The Prefix Information option appears in Router Advertisement packets and MUST be silently ignored for other messages. 4.2. Router Solicitation extension Mobile node aware of different mobility modes may explicitly request a specific mobility service using a new Mobility Mode option in the RS message. Routers in the network not supporting PMIP6 or unable to process this option must ignore it. Otherwise the AR will acquire the PMIP6 HNP for the mobile node, and provide it in the responding RA using the extended Prefix Information 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 |P| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Pad ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Damic, et al. Expires December 9, 2007 [Page 7] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 Figure 2. Mobility Mode option for RS Type 8-bit identifier for the Mobility Mode option (to be assigned by IANA) Length 8-bit unsigned integer. The length of the option in octets (including the type and length fields) Flags 8-bit field containing flags set by MN to negotiate on the mobility service type. The most significant bit in this field is labled as PMIP6 "P" flag. It is set by MN when explicitly requesting PMIP6 mobility from the network. Reserved 8-bit field reserved for future use. Pad Variable-length field. This field is used to align the option into units of 8 octets. 4.3. DHCPv6 extensions This section describes how a mobile node can use DHCP [RFC3315] to detect that it is located in the PMIP domain and to inform the AR of its preference to use PMIP6 or host-based MIP6 as a mobility management protocol. By using DHCP, mobile node and the AR are able to exchange following information: o AR can let the mobile node know that the access network supports the PMIP protocol o AR can inform the mobile node of the PMIP prefix o mobile node can inform the AR wheather it should provide a PMIP service to it or if the MN prefers to run MIP by itself Draft [I-D.ietf-mip6-hiopt] defines new DHCPv6 options used to facilitate bootstraping of a MIP6 based mobility service. One of the options introduced by the draft is a Home Network Identifier option Damic, et al. Expires December 9, 2007 [Page 8] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 (OPTION_MIP6-HNID) by which the mobile node can request information about the home network and indicate its preference for the location of the HA: in the visited network or in the target network. 4.3.1. Home Network Identifier Option The Home Network Identifier option is extended with an additional code to allow the mobile node to explicitely request information about the availability of the PMIP service at its current point of attachment. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_MIP6-HNID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id-type | reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Home Network Identifier . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Home Network Identifier option format option-code OPTION_MIP6-HNID (TBD) option-len Total length of the option in octets id-type The type of Home Network Identifier: 0 Visited domain (local ASP) 1 The target network 2 No preference 3 PMIP domain When the mobile node wants to learn if the access network supports PMIP service, it SHALL include Home Network Option setting the id- type field to 3. When the id-type is set to 3, the Home Network Identifier field MAY be set to 0 if the mobile node wants to learn about the PMIP support in the local domain. Alternatively, if the mobile node wants to inquire about the support for PMIP service in a Damic, et al. Expires December 9, 2007 [Page 9] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 particular network, the mobile node MAY set the Home Network Identifier field to the network realm as FQDN. The mobile node can learn information about a particular network type by sending separate Information Request messages with different id- types. If the mobile node wants to acquire the information about the visited network, target network and the PMIP domain in a single message exchange, it MAY include several Home Network Identifier options in the reguest message. There may be several Home Network Identifier options with the id-type 1 and/or 3 in a single message. 4.3.2. Home Network Information Option Draft [I-D.ietf-mip6-hiopt] defines a new DHCPv6 option Home Network Information option. This option is used by the DHCP server to convey to the mobile node information about inquired network(s). The information provided could be a home subnet prefix (one or more), home agent address(es) and home agent FQDN(s). There is a separate suboption for each type of information provided (prefix, home agent address and home agent FQDN). If the id-type field of the Home Network Identifier option indicates the network which is not supported by this access network or if the mobile node is not authorized for the requested network, the DHCP server's reponse SHALL include the Home Network Information option with the option-len set to zero. If the mobile node inquiered information about the PMIP domain, the relevant information about the PMIP domain will be provided in the Home Network Information option. In this case the only relevant information is prefix. Since in PMIP mode the mobile node does not interact with the home agent directly, home agent's address and FQDN SHALL not be provided to the mobile node. If the access network wants to force the PMIP mode for the mobile node, it MAY respond to both visited domain and target domain(s) inquieris with a Home Network Information option containing the 0-length data. 4.3.2.1. Avoiding the premature prefix advertisment When the netlmm domain supports the DHCP extensions specified here, the AR may want to defer advertisment of the prefix until both the mobile node and network have exchanged their capabilites and preferences for a mobility management mode. This can be achived by setting the 'M' or 'O' flag in Router Advertisment message forcing the mobile node to use DHCP. In this way the AR can delay the prefix advertisment until the DHCP exchange is completed. Damic, et al. Expires December 9, 2007 [Page 10] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 4.3.2.2. Choosing the PMIP mode If the client decides that it would use PMIP service offered by the access network, it SHALL send the (additional) Information Request message containing Home Network Information sub-option with the Home Network Information field containing the PMIP network prefix. 4.3.3. Note on DHCPv4 Home Network Identifier option and Home Network Information option defined for DHCPv6 could be adopted, with some modifications, for DHCPv4. This would enable the single stack IPv4 host to become aware of the PMIP service support by the access network. Wheather the approach of adopting the DHCPv6 options for DHCPv4 is feasible in this particular case is for futher study. The IPv4 host would include the Home Network Identifier option, indicating its preferences, in the DHCPDISCOVER message. DHCPOFFER message would include Home Network Information option indicating the network type(s) supported by the access network and authorized for the mobile node. The mobile node would indicate its choice in the DHCPREQUEST message by including the Home Network Information option with the id-type field set to the selected network type. 5. Security Considerations TBD. 6. IANA Considerations The following Extension Types MUST be assigned by IANA: TBD. 7. Acknowledgements TBD. 8. Normative References [I-D.ietf-mip6-hiopt] Jang, H., "DHCP Option for Home Information Discovery in MIPv6", draft-ietf-mip6-hiopt-03 (work in progress), May 2007. [I-D.ietf-netlmm-proxymip6] Damic, et al. Expires December 9, 2007 [Page 11] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 S. Gundavelli et al., "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-00 (work in progress), April 2007. [RFC2023] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2023, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [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. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Authors' Addresses Damjan Damic Nokia Siemens Networks Zagrebacka 145a Zagreb 10000 Croatia Phone: +385 1-6331-337 Email: damjan.damic@siemens.com Damic, et al. Expires December 9, 2007 [Page 12] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 2007 Domagoj Premec Nokia Siemens Networks Zagrebacka 145a Zagreb 10000 Croatia Phone: +385 1-6105-923 Email: domagoj.premec@siemens.com Basavaraj Patil Nokia Siemens Networks 6000 Connection Drive Irving, TX 75039 US Phone: Email: basavaraj.patil@nsn.com Meghana Sahasrabudhe Nokia Siemens Networks 313 Fairchild Drive Mountain View, CA 94043 US Phone: Email: meghana.sahasrabudhe@nsn.com Damic, et al. Expires December 9, 2007 [Page 13] Internet-Draft draft-damic-netlmm-pmip6-ind-discover June 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). Damic, et al. Expires December 9, 2007 [Page 14]