One document matched: draft-laganier-mext-lone-home-binding-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
<!ENTITY rfc5555 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5555.xml'>
<!ENTITY rfc5648 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5648.xml'>
<!ENTITY I-D.ietf-mext-flow-binding PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mext-flow-binding.xml'>
<!ENTITY I-D.devarapalli-mext-mipv6-home-link PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.devarapalli-mext-mipv6-home-link.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" updates="5648" ipr="trust200902">
<!--rfc category="std" ipr="pre5378Trust200902"-->
<front>
<title abbrev="Mobile IPv6 Lone Home Binding">
Mobile IPv6 Lone Home Binding
</title>
<author initials="J." surname="Laganier" fullname="Julien Laganier">
<organization abbrev="Qualcomm Inc.">
Qualcomm Incorporated
</organization>
<address> <postal>
<street>5775 Morehouse Drive
</street>
<city>San Diego</city>
<region>CA</region>
<code>92121</code>
<country>USA</country>
</postal>
<phone>+1 858 658 3538</phone>
<email>julienl@qualcomm.com</email>
</address>
</author>
<author initials="G." surname="Giaretta" fullname="Gerardo Giaretta">
<organization abbrev="Qualcomm Inc.">
Qualcomm Incorporated
</organization>
<address> <postal>
<street>5775 Morehouse Drive
</street>
<city>San Diego</city>
<region>CA</region>
<code>92121</code>
<country>USA</country>
</postal>
<phone>+1 858 658 5844</phone>
<email>gerardog@qualcomm.com</email>
</address>
</author>
<date year="2010"/>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Mobile IPv6 (MIPv6) <xref target="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 <xref target="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.
</t>
<t>
<xref target="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).
</t>
<t>
The Home Binding is described in a subsection of Section 5.6 of <xref
target="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.
</t>
<t>
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.
</t>
</section>
<section title="Requirement Levels Key Words">
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
<section title="Terminology">
<t>
Lone Home Binding: A Home Binding as per <xref target="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).
</t>
<t>
Other terms used throughout this document are defined in the documents
specifying the Mobile IPv6 protocol suite: <xref target="RFC3775"/>,
<xref target="RFC5555"/>, <xref target="RFC5648"/>, and <xref
target="I-D.ietf-mext-flow-binding"/>.
</t>
</section>
<section title="Usage Scenario">
<t>
<xref target="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.
</t>
<t>
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:
<list style="symbols">
<t>
<xref target="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."
</t>
<t>
<xref target="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."
</t>
</list>
</t>
<t>
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 <xref target="RFC5648"/> and <xref
target="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 <xref target="RFC5648"/>, or to send and receive
traffic in the case of <xref target="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 <xref target="I-D.ietf-mext-flow-binding"/> and/or a BID option
<xref target="RFC5648"/> depending on the capability to be detected.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Mobile Node Operation">
<t>
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 <xref target="I-D.ietf-mext-flow-binding"/>
and/or Section 5.6.3 of <xref target="RFC5648"/>.
</t>
</section>
<section title="Home Agent and Correspondent Node Operation">
<t>
A Home Agent or a Correspondent Node that supports <xref
target="I-D.ietf-mext-flow-binding"/> and/or <xref
target="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.
</t>
<t>
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 <xref target="I-D.ietf-mext-flow-binding"/>
and/or Section 6.3 of <xref target="RFC5648"/>.
</t>
</section>
<section title="IANA Considerations">
<t>
There are no IANA considerations for this specification.
</t>
</section>
<section title="Security Considerations">
<t>
The security considerations of <xref target="RFC5648"/> and
<xref target="I-D.ietf-mext-flow-binding"/> are not modified by
this specification.
</t>
</section>
<section title="Acknowledgment">
<t>
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 <xref target="I-D.devarapalli-mext-mipv6-home-link"/>.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3775;
&rfc5555;
&rfc5648;
&I-D.ietf-mext-flow-binding;
</references>
<references title="Informative References">
&I-D.devarapalli-mext-mipv6-home-link;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:00:08 |