Internet DRAFT - draft-ewu-mobopts-directsig
draft-ewu-mobopts-directsig
Network Working Group E. Wu
Internet-Draft G. Daley
Expires: April 27, 2006 A. Sekercioglu
Monash University CTIE
S. Narayanan
Panasonic
October 24, 2005
Direct Signaling for Mobile IPv6 Return Routability Procedure
draft-ewu-mobopts-directsig-01.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 April 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In Mobile IPv6, mobile nodes must complete Return Routability
Procedure and binding process before route optimization for data
packet transmission is performed. This requires signaling exchange
between the mobile and correspondent node. For the current
specification, signaling is restricted to be routed to the mobile's
Wu, et al. Expires April 27, 2006 [Page 1]
Internet-Draft Mobile IPv6 Direct Signaling October 2005
and correspondent node's home addresses.
This document describes a mechanism to enable mobile and
correspondent nodes to send the signaling packets directly to their
care-of addresses.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 MN to MN Signaling . . . . . . . . . . . . . . . . . . . . 3
2. MN-to-MN Communications via Indirect Signaling Route . . . . . 4
3. Direct MN-to-MN Signaling Route . . . . . . . . . . . . . . . 6
4. Recovery from Failure . . . . . . . . . . . . . . . . . . . . 7
5. Changes to Mobile Nodes . . . . . . . . . . . . . . . . . . . 8
5.1 Binding Update Format . . . . . . . . . . . . . . . . . . 8
6. Changes to Correspondent Nodes . . . . . . . . . . . . . . . . 9
6.1 Binding Acknowledgement Format . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Wu, et al. Expires April 27, 2006 [Page 2]
Internet-Draft Mobile IPv6 Direct Signaling October 2005
1. Introduction
Mobile IPv6 Route Optimization is a flexible mechanism which allows
Mobile Nodes (MNs) to negotiate with their peer Correspondent Nodes
(CNs) as to whether the peer sends data to its visited or its home
location.
Route Optimization in Mobile IPv6 requires some proof of ownership
test before sending a Binding Update message, which changes the CN's
knowledge of where the MN is, by providing a visited network Care-of-
Address for packet delivery [1].
Below is a diagram showing the logical path taken by signaling
messages used in binding signaling, and the basic authorization
scheme for mobility: Return Routability.
+----+
| HA |
| MN |
+----+
/ |
/ |
/ |
/ |
HoTI/HoT |
/ HoTI/HoT
/ |
/ |
/ |
/ |
/ |
+----+ / +----+
| |/ | |
| CN |-------------| MN |
+----+ CoTI/CoT/BU +----+
Figure 1: Return Routability and Binding Update Signaling paths
1.1 MN to MN Signaling
When two Mobile IPv6 Mobile Nodes each decide to perform route
optimization to each other, the MNs can send data on the data path
between each other's Care-of-Addresses on their visited networks.
When they transmit binding signaling to each other though, they are
not allowed to transmit mobility signaling messages to the peer's
CoA, and must send messages to Home Addresses (HoAs) on the Home
Wu, et al. Expires April 27, 2006 [Page 3]
Internet-Draft Mobile IPv6 Direct Signaling October 2005
Network, without reference to the Binding Cache[1].
This is a result of an oversight in earlier Mobile IPv6
specifications, discovered through testing. Two mobile nodes would
successfully update each other at the CoA with Return Routability and
Binding messages, unless one wasn't able to complete mobility
signaling before the other moved. In this case MNs would retry
binding messages to the incorrect care-of-address.
Subsequent versions of the Mobile IPv6 draft specifications removed
this anomaly, making Binding Update, CoTI and HoTI messages get sent
to Home Address messages in order to provide robust signaling [1].
This document describes a possible route optimization to the return
routability procedure and binding process between two communicating
nodes while attaching to foreign links.
It describes the differences between signaling to Home Addresses, and
signaling to care-of-addresses, and provides some motivation for
sending signaling messages directly.
It presents a robust and efficient method for solving the
simultaneous movement issue, which prevented Mobile IPv6 sending
directly to a mobile Correspondent Node's (CN's) Care of Address.
2. MN-to-MN Communications via Indirect Signaling Route
Mobile Node to Mobile Node Signaling in Mobile IPv6 may not use the
binding cache entry [1]. This means that when an MN moves and
signals to its CN, the signaling messages traverse a longer path than
the data messages.
Additional cost of indirect signaling is associated with i) round
trip delays for packets traveled to the Correspondent Node's home
network ii) additional transmission delays for the use of additional
IPv6 headers for packets sending via the home agent (i.e. tunneling).
As can be seen in Figure 2, the additional duration is related to how
far the CN is from its home network. All signaling messages are
diverted to the Home Agent before traveling to the CN's location.
Where there are time constraints or loss bounds for data traffic,
this may affect the function of applications by increasing the
service restoration time after movement.
In some cases, binding signaling messages may arrive after data
messages. For an address which is not already bound, this results in
packet loss.
Wu, et al. Expires April 27, 2006 [Page 4]
Internet-Draft Mobile IPv6 Direct Signaling October 2005
Also, no signaling message ever tests the data path (between the
CoAs) before application data traverses it.
+----+ HoTI/HoT +----+
| HA |----------| HA |
| CN | | MN |
+----+\ +----+
| \ |
| \ |
| \ |
| CoTI/CoT/BU |
| \ |
HoTI/HoT/CoTI/CoT/BU \ HoTI/HoT
| \ |
| \ |
| \ |
+----+ +----+
| | | |
| CN | | MN |
+----+ +----+
Figure 2: Indirect signaling route
On the positive side, when signaling to the CN's home address,
messages will only go missing due to movement in the interval between
when the CN moves, and the time it takes to update its own Home
Agent.
The following equation defines delays for indirect signaling
exchange, D:
D = max( RTT MN-HAMN + RTT HAMN-HACN + RTT HACN-CN, RTT MN-HACN +
RTTHACN-CN) + T MN-HACN + T HACN-CN
where,
RTT is the round trip time delay between two intermediate nodes
A and B, expressed as "RTT A-B"
T is the transmission (one way trip) delay from node A to node
B, expressed as "T A-B"
MN is the mobile node
CN is the Correspondent Node
Wu, et al. Expires April 27, 2006 [Page 5]
Internet-Draft Mobile IPv6 Direct Signaling October 2005
HAMN is the Mobile Node's Home Agent
HACN is the Correspondent Node's Home Agent
3. Direct MN-to-MN Signaling Route
When Mobile Nodes use direct signaling, they consult their binding
cache before transmitting mobility signaling to their peers. If the
peer CN is mobile, the MN may attempt to send signaling directly to
the CN's Care-of-Address.
All operations which regard the MN's own Care-of-Address still
operate as in Mobile IPv6, including the source address for CoTI and
HoTI messages [1].
The signaling paths used for direct signaling are described in
Figure 3. Binding Update messages, CoTI and HoTI messages are
transmitted to the CN's CoA, and their responses from the CN are sent
from the same addresses, transmitted back to the origin of the
packet.
It is notable that in order to provide interoperability with Mobile
IPv6 Nodes, that mobility signaling does not take on any additional
Routing Headers or Home Address options through adopting the direct
signaling path. This means that the overheads for signaling messages
are actually lower for successful signaling exchanges on the direct
path, because they do not incur tunnel overheads.
Wu, et al. Expires April 27, 2006 [Page 6]
Internet-Draft Mobile IPv6 Direct Signaling October 2005
+----+ +----+
| HA | | HA |
| CN | | MN |
+----+ +----+
/ |
/ |
/ |
HoTI/HoT |
/ |
/ HoTI/HoT
/ |
/ |
/ |
/ |
/ |
/ |
+----+/ +----+
| | | |
| CN |-------------| MN |
+----+ CoTI/CoT/BU +----+
Figure 3: Direct signaling route
Therefore, the delay incurred by signaling exchange on the direct
path is:
Ddirect = max(RTT MN-HAMN + RTT HAMN-CN, RTT MN-CN) + T MN-CN)
The largest delay component is likely to be the the home test return
routability operation. Where this can be done off the critical path,
the return routability and binding signaling delays becomes up to
three messages on the route optimized data path between the MN and
CN.
When signaling directly to the CN's Care-of-Address, packets may be
lost if the CN moves away from that visited network before binding
signaling completes. Robustness mechanisms which handle this case
are described in Section 4.
4. Recovery from Failure
When signaling to the CN's Care-of-Address there is a chance that the
CN will move before the BU is received. Where Binding signaling is
being Acknowledged (or responded to with HoT or CoT), it is possible
to determine if the CN received a particular message. If the MN
receives an acknowledging message to its directly transmitted
signaling message, it knows that binding signaling has completed, and
that both the MN and CN have each other's CoA bindings correct.
Wu, et al. Expires April 27, 2006 [Page 7]
Internet-Draft Mobile IPv6 Direct Signaling October 2005
Where timeout occurs waiting for a response, it is possible that the
peer CN may have moved, and the MN's own Binding Cache state is
therefore suspect (even though the lack of response may be due to
packet loss). In this case, the MN sends mobility signaling to the
CN through its Home Address without reference to the binding cache
entry's stored Care-of-Address.
This allows robust fallback to Mobile IPv6's procedures, and avoids
the failed retries which would occur otherwise on simultaneous
movement.
When binding cache entries are succeeding, the binding signaling
occurs on the direct (fast) transmission path.
5. Changes to Mobile Nodes
In order to support direct signaling, both the CN and and MN function
within a mobile node require modification.
When acting as an MN, the Binding Update List needs to identify if
the peer CN is capable of receiving signaling messages at CoAs, and
be able to identify if the Binding Update or Return Routability
operation is the first transmission, or occurs on a retransmission.
5.1 Binding Update Format
In Figure 4 a modified binding update format is presented, which
incorporates the new direct signaling request flag:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|D| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Update Message
(D) Direct signaling: This flag indicates that the MN is able to
perform direct signaling.
When requesting that a CN accept direct signaling the MN sends a BU
to the CN's HoA indicating that it is capable of performing direct
Wu, et al. Expires April 27, 2006 [Page 8]
Internet-Draft Mobile IPv6 Direct Signaling October 2005
signaling (D=on). The MN also sets the 'A' flag, to force an Binding
Acknowledgement to be sent. Recipients of the Direct Signaling flag
acknowledge the BU with a BAck [1]. Those recipients capable (and
willing) to receive binding signaling at their CoA respond with a
specially modified Binding Ack, as described in the next section.
All binding updates using the optimization, sent to the CoA MUST
contain the Direct Signaling flag set. These packets MAY leave the
BU's Ack flag unset.
6. Changes to Correspondent Nodes
A correspondent node which is also mobile needs to be able to
understand direct signaling Binding updates, which are addressed to
its CoA. Existing Binding Cache principles segregate binding
signaling directed to different addresses deliberately in order not
to confuse bindings where multiple HoAs are in use. Therefore,
binding signaling to a CoA of an existing Mobile IPv6 host would be
placed in a logically separate binding cache to that directed to a
HoA [1].
With direct signaling however, the CoAs are already advertised to
remote HA, and it is easy to pre-determine if ambiguity may exist.
Therefore it is possible to use a unified binding cache, where
packets addressed to any of the CN's addresses are treated as the
same BCE.
6.1 Binding Acknowledgement Format
Received Binding Update packets containing the Direct Signaling flag
set indicate that the sender is able to provide direct signaling. A
receiver of this flag is required to send Binding Acknowledgement if
the BU contained tha Ack Flag set.
A CN which both understands the BU's Direct Signaling Flag, and
wishes to receive signaling at its CoA sends back an Acknowledgement
to the MN containing a responding Direct Signaling Ack Flag, if the
CN is required to send a BAck.
If the MN receives a response from the CN with the Direct Signaling
Ack flag unset, it MUST NOT send a BU to the CN's CoA, but should
send binding signaling messages to the CN's HoA.
Wu, et al. Expires April 27, 2006 [Page 9]
Internet-Draft Mobile IPv6 Direct Signaling October 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Binding Acknowledgement Message
(D) Direct Signaling Ack: When set, allows the MN to sent a BU to
either the CN's CoA or Home Address.
CN's which are not configured for direct signaling will ignore the
BU's Direct Signaling Flag, and will leave the Direct Signaling Ack
flag unset. This ensures that the MN will fallback to the procedures
defined in Mobile IPv6 [1].
7. IANA Considerations
If this draft is adopeted, it will be necessary to allocate the
Direct Signaling Flag from Section 5.1, and the Direct Signaling Ack
Flag from Section 6.1 for the respsective binding messages.
8. Security Considerations
When a host signals directly to the MN, it is able to bypass the CN's
home network, but not its own. Therefore each of the Return
Routability tests provided by Mobile IPv6 is still valid, and the MNs
each prove they are on the path to the Care-of and Home Addresses.
Since the signaling path to a mobile CN for HoTI/Hot and CoTI/CoT are
now less diverse with direct signaling, it may be slightly easier for
attackers to intercept or spoof signaling to steal or redirect
packets. In the worst case, this becomes the same as for a fixed CN.
9. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
Wu, et al. Expires April 27, 2006 [Page 10]
Internet-Draft Mobile IPv6 Direct Signaling October 2005
Authors' Addresses
Eric Wu
Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering
Monash University
Clayton, Victoria 3800
Australia
Phone: +61 3 9905 4996
Email: eric.wu@@eng.monash.edu.au
Greg Daley
Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering
Monash University
Clayton, Victoria 3800
Australia
Phone: +61 3 9905 4655
Email: greg.daley@@eng.monash.edu.au
Ahmet Sekercioglu
Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering
Monash University
Clayton, Victoria 3800
Australia
Phone: +61 3 9905 3503
Email: ahmet.sekercioglu@@eng.monash.edu.au
Sathya Narayanan
Panasonic Digital Networking Lab
2 Research Way
Princeton, NJ 08540
U.S.A.
Phone: (609) 734 7599
Email: sathya@Research.Panasonic.COM
Wu, et al. Expires April 27, 2006 [Page 11]
Internet-Draft Mobile IPv6 Direct Signaling October 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wu, et al. Expires April 27, 2006 [Page 12]
