We would like to add a proposal to MEXT that permits the
mobile to engage into route-optimization in *absence* of a home agent.
Such a feature adds robustness to route optimization in case
the HA is temporarily unavailable. Under some circumstances, route optimization
*without* HA may be beneficial for performance reasons. Our proposal requires
“enhanced route optimization for Mobile IPv6” (RFC 4866) as pre-requisite.
We would like to obtain some feedback from the MEXT
community via this mailing list before we submit the proposal as a draft to the
workgroup. For this purpose, we have enclosed a high-level outline below. Thanks.
Networking & Networks Domain
Proposal: Support of Route-Optimization in Absence of Home
The proposal allows the mobile to engage into route
optimization (R/O) in *absence* of a HA. This feature increases robustness when
the HA becomes temporarily unavailable. Under some circumstances, R/O *without*
HA may be beneficial for performance reasons. This proposal requires “enhanced
route optimization for Mobile IPv6” (RFC 4866) as pre-requisite.
In route optimization (R/O), traffic packets are directly
exchanged between hosts without passing the HA. The mobile, however, still has
to interact with the HA. The HA provides (1) location service, (2) a fallback
path in case the direct path breaks, (3) a fallback in case the correspondent
does not support the protocol and (4) security support for R/O-related
signaling (i.e. home test). These functions come at the following cost:
· Handovers may
fail when the link to the HA or the HA itself are down or congested. Mobility is
not supported, when the mobile does not have a HA.
· When the
mobile starts a session outside of its home network, it must use a HoA pertaining
to its home network even if it engages into R/O. This requirement adds
air-interface overhead due to mobility headers and processing overhead on the
mobile. This upfront cost incurs even if the mobile does not move during the
· Signaling handshakes
have to be conducted between mobile and HA at every mobility event.
Currently, the Mobile IPv6 standard family forces the mobile
to bear these disadvantages in R/O even if the HA functions are not needed. This
specifically applies to scenarios where:
· Traffic is
based on mobile-initiated requests to public servers (majority of present
mobile internet traffic). The HA’s location service is not needed for
such traffic. Location service may also be provided by other means such as
Dynamic DNS or on application layer (e.g. SIP registrar).
· The fallback
path through the HA has little value when it shares the weakest link with the
direct path. Since the weakest link is typically the wireless link, this situation
applies to all scenarios where only one air interface is available (this is the
typical case rather than the exception).
· The mobile
may know about the correspondent’s Mobile-IPv6 support from prior
sessions or through means external to the standard.
· The mobile
applies the CGA-based procedure of RFC 4866, which makes the HA’s
security support for R/O unnecessary. This applies to all cases where stateless
addressing is permitted.
To increase the flexibility and robustness of
route-optimized Mobile IPv6, we propose to make the HA an *optional* rather
than a *mandatory* feature, i.e. to permit operation without HA. This proposal
requires some additional extensions to the present standard.
The extensions build on Enhanced Route Optimization for
Mobile IPv6 (RFC 4866) to guarantee sufficient signaling security. With the
absence of a HA, mobility support in R/O can be provided in the following
· The mobile starts
the traffic session from any of its currently supported IP addresses. The
selected IP address automatically takes the function of the HoA for this
session. This has the advantage that conventional transport is used as long as
the mobile does not move, i.e. mobility headers and CoA-vs-HoA mapping is not
needed. The HoA must have been generated via CGA in compliance with RFC 4866.
· The mobile
must conduct a “home-test” from this HoA in compliance with RFC
4866. It may conduct the home-test prior to session establishment, e.g. to find
out if the correspondent supports the standard.
· All binding
update handshakes are conducted on the direct path according to RFC 4866.
sessions are always started from a currently supported IP address, temporally overlapping
sessions may use different HoAs. A multi-homed mobile may also decide to start
sessions from different simultaneously supported IP addresses. There is no
principle problem here.
· Opposed to
RFC 4866, the mobile need not perform the CoA registration with the HA.
· The mobile must
be able to deregister the HoA at the correspondent in case the HoA is not
supported anymore. This ensures that the correspondent does not send packets to
the HoA. After deregistration of the HoA, the HoA is still used by higher
protocol layers of ongoing sessions. It must still be included in the mobility
headers for these sessions.
· When the
mobile has HA support and the HA becomes temporarily unavailable, the mobile
simply continues R/O without HA as outlined in the prior points.
· The mobile can
publish its IP address in any location service. This allows other hosts to initiate
sessions with the mobile. These sessions enjoy route-optimized mobility support
only if the published IP address was generated via CGA in compliance with RFC
These extensions have to be made compliant with RFC 5648
(multiple CoA registration), RFC 3963 (NEMO) and others. More discussions are