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.”

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.

Table of Contents

1.  Introduction
2.  Requirement Levels Key Words
3.  Terminology
4.  Usage Scenario
5.  Mobile Node Operation
6.  Home Agent and Correspondent Node Operation
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgment
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses

1.  Introduction

Mobile IPv6 (MIPv6) [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) 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] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.). 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] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) 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] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) 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.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Terminology

Lone Home Binding: A Home Binding as per [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.), 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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.), [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.), and [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,” March 2010.).

4.  Usage Scenario

[RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) 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:

• [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) 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."
• [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,” March 2010.) 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] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) and [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,” March 2010.). Suppose that a Mobile Node implementing these extensions wants to use the Home Link to send traffic in the case of [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.), or to send and receive traffic in the case of [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,” March 2010.). 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 [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,” March 2010.) and/or a BID option [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) 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.

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] (Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, “Flow Bindings in Mobile IPv6 and NEMO Basic Support,” March 2010.) and/or Section 5.6.3 of [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.).

6.  Home Agent and Correspondent Node Operation

A Home Agent or a Correspondent Node that supports [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,” March 2010.) and/or [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) 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] (Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, “Flow Bindings in Mobile IPv6 and NEMO Basic Support,” March 2010.) and/or Section 6.3 of [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.).

7.  IANA Considerations

There are no IANA considerations for this specification.

8.  Security Considerations

The security considerations of [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) and [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,” March 2010.) are not modified by this specification.

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] (Devarapalli, V., Kant, N., and H. Lim, “Mobile IPv6 Home Link Operation over SDO point-to-point links,” February 2008.).

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses