Network Working Group J. Laganier Internet-Draft G. Giaretta Updates: 5648 (if approved) Qualcomm Inc. Intended status: Standards Track July 3, 2010 Expires: January 4, 2011 Mobile IPv6 Lone Home Binding draft-laganier-mext-lone-home-binding-00 Abstract RFC5648 extends MIPv6 with the ability for a Mobile Node to register Multiple Care-of Addresses with its Home Agent and Correspondent Node(s). RFC 5648 also introduces the notion of a Home Binding that is essentially a binding on the Home Link, where the Care-of Address is set to the Home Address of the Mobile Node. A Mobile Node uses such a Home Binding together with one or more Multiple Care-of Address binding(s) to be able to use simultaneously both the Home Link and one or more visited link(s). The description of the Home Binding in a section of RFC 5846 entitled "Returning Home: Simultaneous Home and Visited Link Operation" seems to imply that a Home Binding can only be legitimately created while returning home and maintaining simultaneous bindings on one or more visited link(s). There is however no specific reason to prevent creation of such a Home Binding when the Mobile Node is only attached to the Home Link and does not have any interface attached to a visited link. Moreover, there is a specific use case for the creation of such a Lone Home Binding. This specification explicits the use case for creation of a Lone Home Binding, and clarifies the protocol behavior of Mobile IPv6 nodes (Mobile Node, Home Agent, Correspondent Node) involved with its creation. 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." Laganier & Giaretta Expires January 4, 2011 [Page 1] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 This Internet-Draft will expire on January 4, 2011. Copyright Notice Copyright (c) 2010 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 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. Laganier & Giaretta Expires January 4, 2011 [Page 2] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirement Levels Key Words . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 9 6. Home Agent and Correspondent Node Operation . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Laganier & Giaretta Expires January 4, 2011 [Page 3] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 1. Introduction Mobile IPv6 (MIPv6) [RFC3775] specifies a protocol which allows nodes to remain reachable while moving to different location of the IPv6 Internet, and of the IPv4 Internet when extended with Dual Stack support [RFC5555]. Each mobile node is identified by a so-called Home Address that is independent from its current point of attachment. A mobile node also has a so-called Care-of Address at which it is reachable and which reflects its current point of attachment. MIPv6 allows a mobile node to register with its Home Agent and correspondent nodes the binding between its Home Address and Care-of Address so that they are able to route appropriately packet they wish to send to its Home Address. [RFC5648] extends MIPv6 with the ability for a Mobile Node to register Multiple Care-of Addresses with its Home Agent and Correspondent Node(s). RFC 5648 also introduces the notion of a Home Binding that is essentially a binding on the Home Link, where the Care-of Address is set to the Home Address of the Mobile Node. A Mobile Node uses such a Home Binding together with one or more Multiple Care-of Address binding(s) to be able to use simultaneously both the Home Link and one or more visited link(s). The Home Binding is described in a subsection of Section 5.6 of [RFC5648] entitled "Returning Home: Simultaneous Home and Visited Link Operation", which seems to imply that a Home Binding can only be legitimately created while returning home and maintaining simultaneous bindings on one or more visited link(s). There is however no specific reason to prevent creation of such a Home Binding when the Mobile Node is only attached to the Home Link and does not have any interface attached to a visited link. Moreover, there is a specific use case for the creation of such a Lone Home Binding. This specification explicits the use case for creation of a Lone Home Binding, and clarifies the protocol behavior of Mobile IPv6 nodes (Mobile Node, Home Agent, Correspondent Node) involved with its creation. Laganier & Giaretta Expires January 4, 2011 [Page 4] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 2. Requirement Levels Key Words 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 [RFC2119]. Laganier & Giaretta Expires January 4, 2011 [Page 5] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 3. Terminology Lone Home Binding: A Home Binding as per [RFC5648], i.e., where the Care-of Address for the binding is set to the Home Address of the Mobile Node, where there exists no other bindings to Care-of Addresses configured by the Mobile Node on one or more visited link(s). Other terms used throughout this document are defined in the documents specifying the Mobile IPv6 protocol suite: [RFC3775], [RFC5555], [RFC5648], and [I-D.ietf-mext-flow-binding]. Laganier & Giaretta Expires January 4, 2011 [Page 6] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 4. Usage Scenario [RFC3775] specifies that a node receiving a Mobility Header "MUST ignore and skip any options which it does not understand." This makes it possible for a Mobile Node supporting and using new option(s) and sending messages to a Home Agent or a Correspond Node that does not support them to detect that fact and respond accordingly. As such, inclusion of the options defined in these extension in a Binding Update constitute an implicit capability detection for a Home Agent or a Correspondent Node. Absence of the options in a Binding Acknowledgment with a Status code indicating success indicates that the Home Agent or Correspondent Node does not support the extension making use of the option. Following that, two extensions to the basic MIPv6 protocol that introduces new Mobility Options require that a conformant node receiving a Binding Update including such an option includes a copy of that option in the Binding Acknowledgment confirming successful creation of a binding: o [RFC5648] states that "Whenever a Binding Acknowledgement is sent, all the Binding Identifier mobility options stored in the Binding Update MUST be copied to the Binding Acknowledgement except the Status field." o [I-D.ietf-mext-flow-binding] states that "a mobile node receiving a Binding Acknowledgement in response to the transmission of a Binding Update MUST determine if the Binding Acknowledgement contains a copy of every flow identification mobility options included in the Binding Update. A Binding Acknowledgement without flow identification option(s), in response to a Binding Update with flow identification mobility option, would indicate inability (or unwillingness) on behalf of the source node to support the extensions presented in this document." While this mechanism seems to be sufficient for capability detection, if a Mobile Node cannot create a Lone Home Binding the capability detection will incur side effects that are undesirable when the Home Agent or Correspondent node does not support the extensions specified in [RFC5648] and [I-D.ietf-mext-flow-binding]. Suppose that a Mobile Node implementing these extensions wants to use the Home Link to send traffic in the case of [RFC5648], or to send and receive traffic in the case of [I-D.ietf-mext-flow-binding]. Suppose further that the Mobile Node does not know yet that the Home Agent it has chosen, or the Correspondent Nodes it would like to creating binding do not support said extensions. In such a situation the Mobile Node has to perform capability detection by sending to the Home Agent or the Correspondent Node a Binding Update including a FID option Laganier & Giaretta Expires January 4, 2011 [Page 7] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 [I-D.ietf-mext-flow-binding] and/or a BID option [RFC5648] depending on the capability to be detected. If the Mobile Node is not allowed to create a Lone Home Binding, it will send this Binding Update from a Care-of Address on a visited link. The receiver will ignore the BID and FID options it does not understand, and as a result will create a single binding towards the Care-of Address. This will disrupt the Mobile Node transmission and/or reception of traffic on the Home Link. Were the Mobile Node allowed to create a Lone Home Binding, it could perform capability detection by creating a Lone Home Binding, which would not disrupt the Mobile Node Transmission and/or reception of traffic at the Home Link. Therefore, this document specifies how to create a Lone Home Binding. Laganier & Giaretta Expires January 4, 2011 [Page 8] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 5. Mobile Node Operation A Mobile Node MAY create a Lone Home Binding while not having any other binding on visited links in the same fashion that it would create a Home Binding while maintaining simultaneous attachment to one or more visited link(s), as specified in Section 5.2.5 of [I-D.ietf-mext-flow-binding] and/or Section 5.6.3 of [RFC5648]. Laganier & Giaretta Expires January 4, 2011 [Page 9] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 6. Home Agent and Correspondent Node Operation A Home Agent or a Correspondent Node that supports [I-D.ietf-mext-flow-binding] and/or [RFC5648] MUST be prepared to receive a Binding Update from a Mobile Node requesting creation of a Lone Home Binding while no other binding exists towards Care-of Address(es) configured by the Mobile Node on visited links. Such a Home Agent or Correspondent Node MUST process a Binding Update requesting the creation of a Lone Home Binding in the same fashion that it would process a Binding Update requesting creation of a Home Binding while maintaining simultaneous attachment to one or more visited link(s), as specified in Section 5.3 of [I-D.ietf-mext-flow-binding] and/or Section 6.3 of [RFC5648]. Laganier & Giaretta Expires January 4, 2011 [Page 10] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 7. IANA Considerations There are no IANA considerations for this specification. Laganier & Giaretta Expires January 4, 2011 [Page 11] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 8. Security Considerations The security considerations of [RFC5648] and [I-D.ietf-mext-flow-binding] are not modified by this specification. Laganier & Giaretta Expires January 4, 2011 [Page 12] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 9. Acknowledgment The authors would like to thanks Patrick Stupar for interesting discussion regarding the Lone Home Binding. Creation of a Lone Home Binding was first proposed in [I-D.devarapalli-mext-mipv6-home-link]. Laganier & Giaretta Expires January 4, 2011 [Page 13] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 10. References 10.1. Normative References [I-D.ietf-mext-flow-binding] Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO Basic Support", draft-ietf-mext-flow-binding-06 (work in progress), March 2010. [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. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. 10.2. Informative References [I-D.devarapalli-mext-mipv6-home-link] Devarapalli, V., Kant, N., and H. Lim, "Mobile IPv6 Home Link Operation over SDO point-to-point links", draft-devarapalli-mext-mipv6-home-link-01 (work in progress), February 2008. Laganier & Giaretta Expires January 4, 2011 [Page 14] Internet-Draft Mobile IPv6 Lone Home Binding July 2010 Authors' Addresses Julien Laganier Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA Phone: +1 858 658 3538 Email: julienl@qualcomm.com Gerardo Giaretta Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA Phone: +1 858 658 5844 Email: gerardog@qualcomm.com Laganier & Giaretta Expires January 4, 2011 [Page 15]