One document matched: draft-laganier-mext-lone-home-binding-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:31:35 |