MIP6/NEMO Working Group Ryuji Wakikawa
INTERNET DRAFT Keio University/WIDE
Category: Standards Track Vijay Devarapalli
16 Feb 2004 Nokia
Pascal Thubert
Cisco Systems
Inter Home Agents Protocol (HAHA)
draft-wakikawa-mip6-nemo-haha-01.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document describes an inter Home Agents (HAHA) protocol to
provide multiple Home Agents support for both Mobile IPv6 and the
Nemo Basic Support protocol. The HAHA protocol provides Home Agent
redundancy and load-balancing for both protocols. The HAHA protocol
allows multiple Home Agents to be placed at different links. It also
allows a Mobile Node to utilize multiple Home Agents simultaneously.
The protocol consists of 3 mechanisms, Home Agent List management,
Binding Synchronization, and Home Agent Switching. A Mobile Node
picks one Home Agent as its primary Home Agent and registers with it.
The primary Home Agent synchronizes the binding cache information
with other Home Agents. Any of Home Agents can intercept a packet
meant for the Mobile Node and tunnel the packet directly to its
current Care-of address. Alternatively, the Home Agent can tunnel
the packet to the primary Home Agent.
Wakikawa, et al. Expires 16 Aug 2004 [Page 1]
Internet Draft HAHA protocol 16 Feb 2004
Contents
Status of This Memo 1
Abstract 1
1. Introduction 4
2. Terminology 6
3. Overview of Inter Home Agents Protocol 7
4. Message Formats 10
4.1. New Mobility Header Messages . . . . . . . . . . . . . . 10
4.1.1. Home Agent HELLO Message . . . . . . . . . . . . 10
4.1.2. Binding Information Request Message . . . . . . . 11
4.1.3. Binding Information Update Message . . . . . . . 13
4.1.4. Binding Information Acknowledgment Message . . . 13
4.1.5. Home Agent Switch Request Message . . . . . . . . 14
4.2. New Mobility Options . . . . . . . . . . . . . . . . . . 15
4.2.1. Home Address . . . . . . . . . . . . . . . . . . 15
4.2.2. Mobile Network Prefix Option . . . . . . . . . . 15
4.2.3. Binding Cache Entry Information Option . . . . . 16
5. Home Agent Lists Management 17
6. Home Agent Failure Detection 18
7. Binding Synchronization among Home Agents 19
7.1. Requesting Binding . . . . . . . . . . . . . . . . . . . 19
7.2. Notifying Binding . . . . . . . . . . . . . . . . . . . . 19
8. Primary Home Agent Switching 21
8.1. Home Agent initiated Switching . . . . . . . . . . . . . 21
8.2. Mobile Node initiated Switching . . . . . . . . . . . . . 21
9. Scenarios 23
9.1. Single Home Agent Activation . . . . . . . . . . . . . . 23
9.2. Multiple Home Agent Activation . . . . . . . . . . . . . 24
10. Modifications to Mobile IPv6 and the Nemo Basic Support Protocol 27
11. IANA Considerations 29
12. Security Considerations 30
A. Changes from -00 32
Wakikawa, et al. Expires 16 Aug 2004 [Page 2]
Internet Draft HAHA protocol 16 Feb 2004
B. Distributed Home Network 33
Addresses 38
Wakikawa, et al. Expires 16 Aug 2004 [Page 3]
Internet Draft HAHA protocol 16 Feb 2004
1. Introduction
In Mobile IPv6 [2], a Mobile Host could be tunneling and receiving
all its traffic through a bi-directional tunnel with its Home Agent,
unless it uses Route Optimization with its Correspondent Nodes. In
Nemo Basic Support protocol [7], the default mode of operation is
to tunnel all traffic meant for the Mobile Network through the Home
Agent serving the Mobile Router. Consequently, Home Agents could
become a considerable bottleneck in the performance of Mobile IPv6
and Nemo protocols. This becomes more significant when the Home
Agent serves thousands of Mobile Hosts and Mobile Routers. Sometimes
the Mobile Network could be closer to the Correspondent Node than
the Home Agent. If the Mobile Router could pick another Home Agent
closer to its current location, the tunneling overhead on every
packet could be reduced to a much shorter path in the Internet.
This draft specifies the inter Home Agents protocol (HAHA protocol)
to provide reliability, redundancy and load balancing of Home Agents.
Problem statements of Home Agent Reliability is summarized in [1].
For the HAHA protocol, the definition of Home Agent is extended to
place multiple Home Agents at different links. Multiple Home Agents
could be located on different links and still serve the same home
prefix. Mobile IPv6 uses a IPv6 Neighbor Discovery based mechanism
for maintaining the list of Home Agents serving the same prefix, at
each Home Agent. If the Home Agents are not present on the same
physical link, Neighbor Discovery based mechanisms don't work. The
HAHA protocol defines a mechanism for Home Agents List management
using new MH messages for Home Agents located on different links.
Network configurations such as Home Network Prefix Assignments and
route distributions among Home Agents are described in [8]. In
appendix B, a distributed home network scenarios are described.
The HAHA protocol makes it possible to have two new scenarios which
would not have possible with Mobile IPv6 and the Nemo Basic Support
Protocol. These scenarios are Single Home Agent Activation and
Multiple Home Agent Activation and are explained in the following
paragraphs.
In the scenario of Single Home Agent Activation, a Mobile Node always
selects the best Home Agent to register its binding depending on
Mobile Node's current location or Home Agent status. The Mobile
Node's binding is always maintained by the single Home Agent. For
example, when a Mobile Node registers its binding to the nearest Home
Agent, the path between the Mobile Node and the Home Agent can be the
shortest possible path. This is particularly useful for a Mobile
Node which moves over geographically wide areas such as a Mobile
Router on an airplane.
Wakikawa, et al. Expires 16 Aug 2004 [Page 4]
Internet Draft HAHA protocol 16 Feb 2004
In the scenario of Multiple Home Agent Activation, a Mobile Nodes
registers its binding to multiple Home Agents at the same time.
The Mobile Node sends a binding update to its primary home agent.
After the home registration, the primary Home Agent exchanges the
binding information with the other Home Agents. The Mobile Node's
binding is maintained by multiple Home Agent. Thereafter, the Mobile
Node can use any of these Home Agents which have the binding. The
Mobile Node can accept packets which are tunneled by any of the Home
Agents. Alternatively, a Home Agent who intercepts packets can
tunnel packets to the primary Home Agent. In this case, the Mobile
Node receives packets through the primary Home Agent. If many Home
Agents are scattered on the Internet, the Home Agent nearest to the
correspondent node intercepts packets meant for the Mobile Node or
the Mobile Network and tunnels them to the Mobile Node. The route
path between the correspondent node and the Home Agent can be kept
short.
Wakikawa, et al. Expires 16 Aug 2004 [Page 5]
Internet Draft HAHA protocol 16 Feb 2004
2. Terminology
There is a separate Nemo terminology document [3], which defines the
terms related to Network Mobility used in the document.
The keywords ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and
``OPTIONAL'' in this document are to be interpreted as described in
RFC 2119.
Home Agent
A Home Agent is originally defined in [2]. Traditional
Home Agents, if they all serve the same home prefix are
configured on a single link. This document extends the
definition of Home Agents such that the Home Agents need
not be on the same link. There could be multiple Home
Agents attached to different links serving the same home
prefix.
Primary Home Agent
A Home Agent who receives Binding Update from a Mobile
Router. The Mobile Router is always associated with a
primary Home Agent to register its binding.
Mobile Node, Mobile Host, and Mobile Router
In this document,three terms are used to express mobile
entities as defined at [10]. A Mobile Host is an end
host capable of Mobile IPv6. A Mobile Router is a router
of a mobile network supporting the Basic NEMO protocol. A
Mobile Node is entity moving on the Internet. A Mobile
Node implies either a Mobile Host, Mobile Router, or both.
Wakikawa, et al. Expires 16 Aug 2004 [Page 6]
Internet Draft HAHA protocol 16 Feb 2004
3. Overview of Inter Home Agents Protocol
The HAHA protocol addresses the issues of home agent reliability
described in [1]. The HAHA protocol prevents Home Agent failure and
Home Link failure from Mobile IPv6. It provides mechanism of failure
detection and its recovery by binding synchronization.
Local HAs Distribtuion Global Home Distribution
Home Link1
----+----
+--------+ |
|Internet| +--------+ |
+--------+ |Internet|---+ Home Link2
| +--------+ |
--+---+---+--Home Link |
| | | ----+------
HA HA HA Home Link3
The Combination
Home Link1
HA HA HA
| | |
+---+---+
| +- HA
+--------+ |
|Internet|----+- HA Home Link2
+--------+ |
| +- HA
+----+----+
| | | Home Link3
HA HA HA
Local Home Agent distribution is the configuration when multiple
home agents are placed locally in same routing domain. Multiple
home agents are configured at the same home link for a particular
mobile nodes. When one of home agents goes down, another home agent
takes over the inactive home agent and serves same mobile nodes
continuously. It is possible to balance load locally among home
agents. Local multiplexing is effective for load balancing and home
agent redundancy.
Global Home Agent distribution is used to avoid home link failure.
Multiple home agents are placed globally despite routing domains.
Multiple home agents serving a same home network are distributed
Wakikawa, et al. Expires 16 Aug 2004 [Page 7]
Internet Draft HAHA protocol 16 Feb 2004
to different routing domains. Therefore, the routes for the home
network are advertised from multiple routing domains. Each mobile
node can pick the best home agent among distributed home agents
according to network environments and topological position.
When multiple Home Agents are configured at different links, each
Home Agent is expected to know the other Home Agents beforehand and
establishes Security Association with them for a secure path towards
the other Home Agents.
Each Home Agent maintains a list of all other Home Agents that serve
the same Home Network. The Mobile IPv6 mechanism of using router
advertisements for maintaining the Home Agent list cannot be used
if the Home Agents are placed on geographically different links,
because router advertisements can not be sent over link-local scope.
Therefore, each Home Agents periodically unicasts a Home Agent HELLO
message instead of Router Advertisement to the other Home Agents
configured at different links. Whenever a Home Agent receives a Home
Agent HELLO message, it updates its Home Agent List according to the
information in the received HELLO message. The Home Agent manages
the Home Agent List as same as the Mobile IPv6 specification. If
the lifetime of an entry is expired in the Home Agent List, the Home
Agent should delete the the entry from the Home Agent List and MAY
assume the Home Agent which entry is deleted becomes unreachable
(i.e. system down).
Synchronizing Binding of a particular Mobile Node allow to activate
multiple Home Agents simultaneously. When a primary Home Agent
receives a Binding Update and creates a Binding, it notifies the
Binding to the other Home Agents by unicasting Binding Information
Update messages. Home Agents receiving the Binding Information
Update message records Binding information and the address of the
primary Home Agent into their Binding Cache. Home Agents MUST
return Binding Information Acknowledgment messages with appropriate
status code to the sender Home Agent. A Home Agent sends a Binding
Information Request message to solicit a Binding Information Update
message to the primary Home Agent if needed.
When a Home Agent wants a Mobile Node to change the primary Home
Agent, it sends a Home Agent Switch Request message to trigger
the Dynamic Home Agent Address Discovery to a Mobile Node. After
receiving an ICMP Home Agent Address Discovery Request, the Home
Agent should reply an ICMP Home Agent Address Discovery Reply with
addresses of appropriate Home Agent addresses. If the Home Agent
has already had the desired new primary Home Agent, it contains
the address of the new Home Agent in the Home Agent Switch Request
message. The Mobile Node switches its primary Home Agent to the new
Home Agent. When the Mobile Node changes the primary Home Agent
proactively, it selects a new Home Agent from its home agent list.
Wakikawa, et al. Expires 16 Aug 2004 [Page 8]
Internet Draft HAHA protocol 16 Feb 2004
After determination of the new Home Agent, it simply registers its
binding to the new Home Agent. The Mobile Node should de-register
its binding from the old Home Agent before the home registration to
the new Home Agent.
The scenarios for the HAHA protocol are described in Section 9. In
the Single Home Agent Activation scenario, only a primary Home Agent
manages a binding for a Mobile Node and takes responsibility for
tunneling packets from and to a Mobile Node. The Mobile Node can
switch its primary Home Agent to a Home Agent located in different
link by the HAHA protocol.
In the Multiple Home Agents Activation scenario, a primary Home Agent
shares the registered binding for a Mobile Node with all other Home
Agents. Each Home Agent intercepts packets and take responsibility
for delivering intercepted packets to either the Mobile Node or
the primary Home Agent. The Mobile Node accepts tunneled packets
directly from the Home Agent. Otherwise, when the primary Home Agent
receives tunneled packets from other Home Agents, it delivers packets
to the Mobile Node. The Mobile Node always tunnels outgoing packets
to the primary Home Agent. The Mobile Node can switch its primary
Home Agent to a Home Agent located in different link by the HAHA
protocol.
Wakikawa, et al. Expires 16 Aug 2004 [Page 9]
Internet Draft HAHA protocol 16 Feb 2004
4. Message Formats
4.1. New Mobility Header Messages
The Mobility Header format is defined in section 6 of [2]. This
document defines five new mobility messages.
4.1.1. Home Agent HELLO Message
The Home Agent HELLO message is pulsed to other Home Agents in order
to inform activeness of the sender home agent. The format of the
Home Agent HELLO message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HELLO Interval | Reserved | Prefix length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Home Agent Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence
16-bit unsigned integer. The Sequence number of the HELLO
message can be used to verify whether this HELLO message is the
latest one or not. This value does not need to be recorded in
Home Agent List.
Home Agent Preference
16-bit unsigned integer. The preference for the home agent
sending this hello. This preference is same as the home agent
preference value of home agent information option defined in
Mobile IPv6.
Wakikawa, et al. Expires 16 Aug 2004 [Page 10]
Internet Draft HAHA protocol 16 Feb 2004
Home Agent Lifetime
16-bit unsigned integer. The lifetime for the home agent
sending this HELLO. This lifetime is same as the home agent
Lifetime value of home agent information option defined in
Mobile IPv6.
HELLO Interval
16-bit unsigned integer. The interval for the home agent
sending this HELLO.
Reserved
8-bit unsigned integer. It must be initialized to zero by the
sender and must be ignored by the receiver.
Prefix Length
8-bit unsigned integer. The prefix length of the home prefix
that HA is serving. The home prefix is retrieved from the
Prefix Length field and following Home Agent Address field.
Home Agent Address
A 16 byte field contains an IPv6 global address of the home
agent sending this hello.
This message MUST include the Mobile Network Prefix Option defined in
section 4.2.2 that is served by the Home Agent if available.
Home Agent HELLO message MUST be authenticated and encrypted by IPsec
ESP.
4.1.2. Binding Information Request Message
The Binding Information Request Message is used to request Binding
Cache Information corresponding to a particular Mobile Node. It is
Wakikawa, et al. Expires 16 Aug 2004 [Page 11]
Internet Draft HAHA protocol 16 Feb 2004
sent only between Home Agents. The format of the Binding Information
Request message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifier
The 16-bit identifier to aid in matching Home Agent Information
Update message. The identifier should never be set to 0. It
should always be more than 1.
This message MUST include either the Home Address mobility option
defined in section 4.2.1 or the Mobile Network Prefix Option
defined in section 4.2.2. If a Home Agents want the Binding Cache
Information for a particular Mobile Node it includes a Home Address
mobility option. If a Home Agent wants to know the forwarding state
setting up for a particular Mobile Network Prefix, it includes the
Mobile Network Prefix Option.
This message is optional if Home Agents send out unsolicited Binding
Information Update messages.
Binding Information Request message MUST be authenticated and
encrypted by IPsec ESP.
Wakikawa, et al. Expires 16 Aug 2004 [Page 12]
Internet Draft HAHA protocol 16 Feb 2004
4.1.3. Binding Information Update Message
The Binding Information Update message is used by the Home Agents
to exchange Binding Cache Information. The message format is as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifier
The 16-bit identifier to aid in matching Home Agent Information
Request and Home Agent Information Acknowledge message. The
identifier should never be set to 0. It should always be
more than 1. The identifier should be set random number for
unsolicited Binding Information Update messages. Otherwise,
the identifier should be set to the identifier in a Binding
Information Request message if this is a solicited Binding
Information Update message.
This message MUST include Binding Cache Entry Information option.
Binding Information Update message MUST be authenticated and
encrypted by IPsec ESP.
4.1.4. Binding Information Acknowledgment Message
The Binding Information Acknowledgment message is used by the Home
Agents to confirm recipient of a Binding Information Update message.
The message format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wakikawa, et al. Expires 16 Aug 2004 [Page 13]
Internet Draft HAHA protocol 16 Feb 2004
Identifier
The 16-bit identifier should be copied from the identifier
field of the received Home Agent Information Update message.
Status
16-bit Status value. Values of Status field greater than or
equal to 128 indicate that the Binding Infroamtion Update was
rejected by the receiving node. The following Status values
are currently defined:
0 Binding is successfully synchronized
Reserved
16-bit field reserved for future use. The value SHOULD be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Binding Information Acknowledgment message MUST be authenticated and
encrypted by IPsec ESP.
4.1.5. Home Agent Switch Request Message
This message is sent by a Home Agent to a Mobile Node to trigger
Dynamic Home Agent Discovery. The message format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Agent Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. The value SHOULD be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Wakikawa, et al. Expires 16 Aug 2004 [Page 14]
Internet Draft HAHA protocol 16 Feb 2004
Home Agent Address
A 16 byte field contains the new primary Home Agent Address.
The Home Agent address MUST be recorded in the Home Agent list
of the Mobile Router. If this field does not contain the
valid global IPv6 address or the unknown Home Agent address,
the Mobile Router sends dynamic Home Agent address discovery
request message. Otherwise, the Mobile Router switches to this
Home Agent immediately as its primary Home Agent.
Home Agent Switch Request message MUST be authenticated and encrypted
by the use of IPsec ESP mode.
4.2. New Mobility Options
4.2.1. Home Address
The Home Address option has an alignment requirement of 8n+6. Its
format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x8 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Home Address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This option is used when the Home Agent needs to figure out the
Binding Cache information for a particular Mobile Node or Mobile
Router. not useful when each Home Agent sends an unsolicited binding
cache information for each BU it receives.
4.2.2. Mobile Network Prefix Option
This option is already defined in the Nemo basic support [7]. This
option is included in the Binding Information Request message only if
a Home Agent is requesting information regarding a particular Mobile
Network Prefix.
Wakikawa, et al. Expires 16 Aug 2004 [Page 15]
Internet Draft HAHA protocol 16 Feb 2004
4.2.3. Binding Cache Entry Information Option
The Binding Cache Entry Information option has an alignment
requirement of 8n+2. Its format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x9 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Home Address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved | # of MNPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Mobile Network Prefixes .
. .
Binding Cache Entry Information option is valid in the Binding
Information Update.
The fields of Home Address, Care-of Address, Flags, Sequence Number,
and Lifetime are copied from the registered binding of a particular
Mobile Node or Mobile Router. 8-bit Reserved field MUST be set to
zero.
The field ``Number of MNPs'' tells the receiving Home Agent which
Mobile Network Prefixes are owned by a Mobile Router. The receiving
Home Agent can then setup forwarding for each Mobile Network Prefix.
for Mobile IPv6, the ``Number of MNPs'' field is set to 0.
Wakikawa, et al. Expires 16 Aug 2004 [Page 16]
Internet Draft HAHA protocol 16 Feb 2004
5. Home Agent Lists Management
Mobile IPv6 uses Router Advertisement messages to manage Home Agent
lists on each Home Agents. When Home Agents are placed at different
links, Router Solicitation and Advertisement messages can not be used
due to link-local limitation. Therefore, a new MH message is defined
to notify similar information of Router Advertisement among Home
Agents over the home link.
A Home Agent MUST know other Home Agents which configured in
different links beforehand. This is manually configured on each
Home Agent. This mechanism MUST be used only between Home Agents on
different links serving the same home prefix. It SHOULD not be used
between Home Agents on the same link.
A Home Agent MUST periodically send a Home Agent HELLO message. The
Home Agent SHOULD also send a Home Agent HELLO message when its local
information such as preference, lifetime, and registration status,
etc. changes.
A Home Agent HELLO message MUST be constructed with same information
of a Router Advertisement message described in section 7 of [2] and
MUST be sent by a unicast to the destination (other Home Agents).
The receiver of a Home Agent HELLO message MUST verify the Source
address field of the IPv6 header. If a Home Agent HELLO message
is received from unknown Home Agent, the message MUST be silently
dropped. If the source address is not in the list of known Home
Agents, the message MUST be silently dropped. Otherwise, the
receiver processes the Home Agent HELLO message to update its Home
Agent list. The Sequence field should be checked to ensure the
freshness of the received HELLO message.
Any Home Agent HELLO message satisfying all of these tests MUST be
processed to update its Home Agent list. The receiver Home Agent
copy each field of the Home Agent HELLO message to its local Home
Agent List. If the Lifetime field is set to zero, the receiver MUST
delete the sender Home Agent from the Home Agent List.
When a new Home Agent boots up, it SHOULD wait particular time to
listen Home Agent HELLO messages of all configured Home Agents.
Wakikawa, et al. Expires 16 Aug 2004 [Page 17]
Internet Draft HAHA protocol 16 Feb 2004
6. Home Agent Failure Detection
Each Home Agent detects Home Agent failure by monitoring lifetime of
each Home Agent List entry.
When an entry is deleted because of lack of either Router
Advertisements or Home Agent HELLO messages, the Home Agent is
treated as invalid.
When Home Agent Lifetime is notified with zero by Router
Advertisements or Home Agent HELLO messages, the receiver MUST mark
the sender Home Agent as invalid, too.
Wakikawa, et al. Expires 16 Aug 2004 [Page 18]
Internet Draft HAHA protocol 16 Feb 2004
7. Binding Synchronization among Home Agents
A binding for a particular Mobile Node is shared among Home Agents.
Therefore, each Home Agents can always know the binding for a
particular Mobile Node and the primary Home Agent which is currently
serving the Mobile Node. This makes it possible for Mobile Nodes to
utilize multiple Home Agents simultaneously.
Binding synchronization messages can be sent with either unicast
or multicast routing. If unicast routing is used, full mesh
flooding is required. Full mesh flooding incurs high overhead for
synchronizing information among multiple entities. But there are
existing mechanisms like CARP and BGP reflector mechanism to reduce
the overhead. Therefore this document does not discuss any optimized
synchronization schemes. This document assumes full mesh flooding,
however, it can be replaced by any other mechanism which achieves
full mesh flooding.
7.1. Requesting Binding
When a Home Agent wants a binding for a particular Mobile Node, it
can solicit Binding Information Update message. The Home Agent sends
a Binding Information Request message to the primary Home Agent of
the Mobile Node. The Home Agent MUST set a random value to the
Identifier field in the Binding Information Request message and MUST
include either a Home Address mobility option or a Mobile Network
Prefix mobility option.
7.2. Notifying Binding
The primary Home Agent sends Binding Information Update messages when
it is solicited by Binding Information Request message or when it
creates or updates binding for a particular Mobile Node.
When the primary Home Agent receives a Binding Information Request
message, it MUST verifies the Source address field of the IPv6
header. If the source address is not among the known Home Agents,
the message MUST be silently discarded.
If a Home Agent who receives a Binding Information Request message
is not the primary Home Agent for the requested Mobile Node, it
MUST ignore the message. Otherwise, it SHOULD reply to the Binding
Information Request message.
The binding information of the requested Mobile Node are stored in
the Binding Information Update message. The primary Home Agent
MUST copy the binding information of the requested Mobile Node to
Wakikawa, et al. Expires 16 Aug 2004 [Page 19]
Internet Draft HAHA protocol 16 Feb 2004
each fields of a Binding Cache Entry Information option. If the
Binding Information Update message is sent in response to the Binding
Information Request message, the primary Home Agent MUST copy the
Identifier field of the Request message to the same filed in the
Update message. Otherwise, it MUST set zero to the Identifier field.
When a Home Agent receives a Binding Information Update message, it
MUST verify the Source address field of the IPv6 header. If the
source address is not among the known Home Agents, the message MUST
be silently discarded. If the Binding Information Update message
is sent from the primary Home Agent, the Home Agent SHOULD record
the binding information and the primary Home Agent address into its
Binding Cache. After registering the binding, the Home Agent MUST
return a Binding Information Acknowledgement message to the sender
Home Agent of the Binding Information Update message.
If the sender Home Agent of the Binding Information Update message
does not receive a Binding Information Acknowledgement message, it
MUST retry to send a Binding Information Update message.
Both a Binding Information Update message, a Binding Information
Request message and a Binding Infromation Acknowledgement message
MUST be authenticated and encrypted by IPsec ESP. If a message does
not have IPsec ESP header, the message MUST be ignored.
Wakikawa, et al. Expires 16 Aug 2004 [Page 20]
Internet Draft HAHA protocol 16 Feb 2004
8. Primary Home Agent Switching
A Mobile Node always associates with the best Home Agent from Home
Agents configured for the Mobile Node. The Mobile Node initiates
dynamic Home Agent discovery to get the most appropriate Home Agents.
The Mobile Node can ensure the best Home Agent by issuing a Dynamic
Home Agent Address Discovery Request message at each visiting foreign
links. Alternatively, Home Agent can send Home Agent Switch Request
message as a trigger of a Dynamic Home Agent Address Discovery
Request message to the Mobile Node.
The Home Agent initiated switching is useful for load-sharing of each
Home Agents. A Home Agent can control the load average by moving
some of Mobile Nodes to other Home Agents compulsory.
The Mobile Node initiated switching guarantees a Mobile Node to
register its binding to the best Home Agent all the time. For
example, the best Home Agent is the nearest one.
8.1. Home Agent initiated Switching
A Mobile Node can change its primary Home Agent when it is requested
by a Home Agent. When a Mobile Node receives a Home Agent Switch
Request, it checks the Home Address field in the request. If the
address in the Home Address field is global scope address and is
already recorded in the Home Agent list of the Mobile Node, the
Mobile Node MUST immediately switch to the requested Home Agent by
the Home Agent Switch Request.
On the other hand, if the requested address in the Home Agent Switch
Request message is either unknown or empty, the Mobile Node MUST send
a Dynamic Home Agent Discovery Request message to the Mobile IPv6
Home-Agents anycast address. After receiving a Dynamic Home Agent
Discovery Reply, the Mobile Node selects the most appropriate home
agent and changes its primary Home Agent to the selected Home Agent.
The primary Home Agent switching is completed when the Mobile Node
registers its binding to the new Home Agent.
8.2. Mobile Node initiated Switching
When a Mobile Node decides to change its primary Home Agent, it
selects the new Home Agent from its Home Agent list. The Mobile Node
can start Dynamic Home Agent Address Discovery mechanism to update
Home Agents information such as a preference value of each Home
Agents.
Wakikawa, et al. Expires 16 Aug 2004 [Page 21]
Internet Draft HAHA protocol 16 Feb 2004
After selection of a new Home Agent, it registers its binding to the
new Home Agent.
Wakikawa, et al. Expires 16 Aug 2004 [Page 22]
Internet Draft HAHA protocol 16 Feb 2004
9. Scenarios
This section describes assumed scenarios of the HAHA protocol.
Network configurations such as Home Prefix assignments and route
managements are described in [8].
Two scenario are introduced such as the Single Home Agent Activation
and the Multiple Home Agents Activation. Both can be applied to both
Mobile IPv6 and the Nemo basic support protocol.
In each figures descrbied below, the operation of Binding Information
Acknowledgement message is omitted. The binding notification is
assumed to be success all the time in this Section.
9.1. Single Home Agent Activation
MN PHA HA2 HA3 CN
| | | | |
|------>| | | | 1. Home Registration
| | | | |
|======>|---------------------->| 2. Sending Packet to CN
| | | | | via Primary HA"(PHA)
|<======|<----------------------| 3. Sending Packet to MN
| | | | | via PHA
|<------|(HA1) | | | 4. Trigger primary HA switching
| | | | |
|-------------->|(PHA) | | 5. Sending Binding Update
| | | | |
| |<------|------>| | 6. Soliciting the binding
| | | | | to other HAs. (no reply)
|<--------------| | | 7. Sending Binding Acknowledgement
| | | | |
|==============>|-------------->| 8. Sending Packet to CN
| | | | |
|<==============|<--------------| 9. Sending Packet to CN
| | | | |
Figure 1: Local Home Agent Distribution
All packets meant for a Mobile Node are routed to the primary Home
Agent and are intercepted by the primary Home Agent as well as both
Mobile IPv6 and Nemo basic support. Then, the primary Home Agent
tunnels packets to the Mobile Node according to either the registered
binding cache or the forwarding states established by a Binding
Update (Seq2 and Seq3).
Wakikawa, et al. Expires 16 Aug 2004 [Page 23]
Internet Draft HAHA protocol 16 Feb 2004
When the Mobile Node switches its primary Home Agent, it sends a
Binding Update to the new primary Home Agent (Seq5). The new primary
Home Agent receiving the Binding Update verifies whether the other
Home Agents still hold the binding for the Mobile Node. It sends
Binding Information Request messages to all the other Home Agents
(Seq6). If it receives any Binding Information Update message in
response to the Binding Information Request messages, it sends a
Binding Acknowledge to the Mobile Node with the status value set to
144 (another Home Agent is still active). Otherwise, the Home Agent
accepts the Binding Update and becomes the primary Home Agent for the
Mobile Node (Seq7).
If the Mobile Node receives the Binding Acknowledge with a negative
status code, it de-registers its binding from the old primary Home
Agent and retries to send a Binding Update to the new primary Home
Agent. Before trying home registration to the new Home Agent, the
Mobile Node should de-register its binding from the current primary
Home Agent.
When the Mobile Node receives a Home Agent Switch Request from the
current primary Home Agent, it MUST switch its primary Home Agent
to the new Home Agent specified in the Home Agent Switch Request.
The Mobile Node can also switch the primary Home Agent proactively
without the Home Agent Switch Request.
9.2. Multiple Home Agent Activation
Each Home Agent synchronizes a binding for a particular Mobile Node
by the HAHA protocol. If all the Home Agents who have the binding
for the Mobile Node can setup forwarding for the Home Address and the
mobile network prefixes owned by the Mobile Node if any, it tunnels
intercepted packets directly to the Mobile Node (Fig 3). On the
other hand, if the Home Agent does not enable forwarding for the
Home Address and the mobile network prefixes, it tunnels intercepted
packets to the primary Home Agent (Fig 2) first. Then the primary
Home Agent re-tunnels packets to the Mobile Node. It is a matter of
operations whether forwarding setting is enable on all the Home Agent
or not.
In the figure 2, a Mobile Node first registers its binding to the
primary Home Agent (Seq1). Once the primary Home Agent creates
a binding for the Home Address of the Mobile Node and sets up
forwarding for the Mobile Network Prefixes, it sends Binding
Information Update messages to other Home Agents to synchronize the
binding information (Seq2 and Seq3). When a Home Agent receives the
Binding Information Update message, it records the binding and the
primary Home Agent address (which can be retrieved from the source
Wakikawa, et al. Expires 16 Aug 2004 [Page 24]
Internet Draft HAHA protocol 16 Feb 2004
MN PHA HA2 CN1 HA3 CN2
| | | | | |
|------>| | | | | 1. Home Registration
| | | | | |
| |------>| | | | 2. Sending binding to HA2
| | | | | |
| |---------------------->| | 3. Sending binding to HA3
| | | | | |
|======>|-------------->| | | 4. Sending Packet to CN1
| | | | | | via PHA
|<======|<------|<------| | | 5. Sending Packet to MN
| | | | | | via HA2 and PHA
|======>|------------------------------>| 6. Sending Packet to CN2
| | | | | | via PHA
|<======|<----------------------|<------| 7. Sending Packet to MN
| | | | | | via HA3 and PHA
|-------------->|(PHA) | | | 8. Home Registration
| | | | | |
| (HA1)|<------|-------------->| | 9. Sending binding to
| | | | | | HA1 and HA3
|==============>|---------------------->| 10. Sending Packet to CN2
| | | | | | via PHA
|<==============|<--------------|<------| 11. Sending Packet to MN
| | | | | | via HA3 and PHA
Figure 2: Multiple Home Agents with single bi-directional tunnel
address of the Binding Information Update messages) in the binding
cache entry.
After the completion of the binding synchronization, all Home
Agents start to distribute the network routes for the Mobile Network
Prefixes to the Internet in the basic NEMO case. Therefore, when the
Mobile Network Node communicates with a Correspondent Node, outgoing
packets from the Mobile Network are tunneled to the closer primary
Home Agent (Seq4) and incoming packets to the Mobile Network are
intercepted by the Home Agent which is close to the Correspondent
Node (Seq5). Then, the intercepted packets are forwarded/tunneled to
the primary Home Agent. The primary Home Agent delivers the packets
to the Mobile Router through the bi-directional tunnel (Seq5). In
Mobile IPv6, the operation is same except for lack of Mobile Network
Prefixes.
If the Mobile Node decides to switch its primary Home Agent due to
its movement, it sends a Binding Update to the new primary home
agent. Then, the new primary Home Agent starts to synchronize the
Wakikawa, et al. Expires 16 Aug 2004 [Page 25]
Internet Draft HAHA protocol 16 Feb 2004
binding information with other Home Agents (Seq9). All Home Agent
updates the binding and the primary Home Agent address according to
the received Binding Information Update message.
MN HA1 HA2 CN1 HA3 CN2
| | | | | |
|------>| | | | | 1. Home Registration
| | | | | |
| |------>| | | | 2. Sending the binding
| | | | | | to HA2
| |---------------------->| | 3. Sending the binding
| | | | | | to HA3
|======>|-------------->| | | 4. Sending Packet to CN1
| | | | | | via HA1
|<==============|<------| | | 5. Replying to MN
| | | | | | via HA2
|======>|------------------------------>| 6. Sending Packet to CN2
| | | | | | via HA1
|<==============================|<------| 7. Replying to MN
| | | | | | via HA3
Figure 3: Multiple Home Agents with multiple
bi-directional tunnels
In the figure 3, a Mobile Node first sends a Binding Update to its
primary Home Agent (Seq1). The primary Home Agent also notifies the
binding information to other Home Agents by using Binding Information
Update messages (Seq2 and Seq3). When a Home Agent receives the
Binding Information Update message, it records the binding and the
primary home agent address as a binding cache entry for the Mobile
Node and sets up forwarding for mobile network prefixes if any.
After creating the binding cache entry and setting up forwarding,
each Home Agent starts to distribute network routes for the mobile
network prefixes to the Internet. When the Mobile Network Node
communicates with a Correspondent Node, outgoing packets from
the mobile network are tunneled to the primary Home Agent (Seq4).
Incoming packets to the mobile network are intercepted by the Home
Agent which is close to the Correspondent Node (Seq5). Then, the
intercepted packets are tunneled directly to the current Care-of
Address according to binding and forwarding (Seq5).
The procedure of primary Home Agent switching is same as the
procedure described in Fig 2.
Wakikawa, et al. Expires 16 Aug 2004 [Page 26]
Internet Draft HAHA protocol 16 Feb 2004
10. Modifications to Mobile IPv6 and the Nemo Basic Support Protocol
The HAHA protocol modifies the below items of Mobile IPv6 [2] and the
Nemo Basic Support protocol [7].
- The new status values for the Binding Acknowledgment.
When a Mobile Node receives this status for its home
registration, it MUST de-register its binding from the old
primary Home Agent and SHOULD re-try home registration. A Home
Agent SHOULD use this status value only in the Single Home
Agent Activation scenario. The primary Home Agent can not be
duplicated in the scenario and can only have a binding for a
particular Mobile Node all the time.
Status
144 Another primary Home Agent is still active.
- Binding Cache Registration
The conceptual fields of each Binding Cache entry are defined
in [2]. The HAHA protocol introduces an additional field to
record the primary Home Agent address for a Mobile Node.
When a Home Agent receives a Binding Information Update message,
it creates or updates the binding cache entry. The Home Agent
MUST record the primary Home Agent address in the binding cache
entry. The address can be derived from the Source address field
of IPv6 header in the Binding Information Update message.
When a primary Home Agent receives a Binding Update from a Mobile
Node, it MUST records its own address as the primary Home Agent
address in the binding cache entry.
- Tunneling packets to Mobile Node Home Agents
Home Agents who registers a binding by the HAHA protocol can
tunnel packets meant for the Mobile Node or Mobile Network to
the current Care-of Address as well as the primary Home Agent.
The Mobile Node can accept the tunneled packets. The Mobile
Node MUST know all the Home Agents who has its binding in the
home agent list so as to verify the Source address of outer IPv6
header.
- Tunneling packets to primary Home Agent from Home Agents
When one of Home Agents who has a binding intercepts packets
meant for a particular Mobile Node, the Home Agent can tunnel
packets to the primary Home Agent recorded in the binding cache.
Wakikawa, et al. Expires 16 Aug 2004 [Page 27]
Internet Draft HAHA protocol 16 Feb 2004
The primary Home Agent tunnels packets to the current Care-of
Address of the Mobile Node.
Wakikawa, et al. Expires 16 Aug 2004 [Page 28]
Internet Draft HAHA protocol 16 Feb 2004
11. IANA Considerations
This document defines three new Mobility Header messages
- Home Agent HELLO Message
- Binding Information Request Message
- Binding Information Update Message
- Binding Information Acknowledgment Message
- Home Agent Switch Request Message
This document defines two new Mobility Options.
- Home Address
- Binding Cache Entry Information
Wakikawa, et al. Expires 16 Aug 2004 [Page 29]
Internet Draft HAHA protocol 16 Feb 2004
12. Security Considerations
Multiple Home Agents advertise routes for either same Home Prefix and
possibly Mobile Network Prefix in the HAHA protocol, these routes
MUST be correctly advertised. System Administrators MUST prevent
malicious (blackhole) routes for these prefixes.
A Home Agent MUST know the other Home Agent serving a same Mobile
Node and MUST establish a secure association with each Home Agent.
All signaling messages between the Mobile Node and the Home Agent
MUST be authenticated and encrypted by IPsec ESP [5].
The Mobile Node MUST verify that packets are tunneled through the
known Home Agent. In Multiple Home Agent Activation scenario, the
Mobile Node may receives packets tunneled by multiple Home Agents.
The Mobile Node MUST know all Home Agents who has its binding by the
HAHA protocol in its Home Agent List by using Home Agent Address
Discovery. It is necessary for a Mobile Node to know all other Home
Agents in order to protect attacks launched by malicious Home Agents.
Please refer to the Mobile IPv6 specification [2] and the Nemo Basic
Support protocol specification [7] for security considerations.
Wakikawa, et al. Expires 16 Aug 2004 [Page 30]
Internet Draft HAHA protocol 16 Feb 2004
References
[1] J. Faizan, H. El-Rewini, M. Khalil, Problem Statement: Home
Agent Reliability (work in progress). Internet Draft, IETF.
draft-jfaizan-mipv6-ha-reliability-01.txt Februry 2004.
[2] D. Johnson, C. Perkins and J. Arkko. Mobility Support
in IPv6 (work in progress). Internet Draft, IETF.
draft-ietf-mobileip-ipv6-22.txt. May 2003.
[3] T. Ernst and H. Lach. Network Mobility Support Terminology (work
in progress). Internet Draft, IETF. draft-ietf-nemo-terminology
-00.txt May 2003.
[4] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and
Home Agents (work in progress). Internet Draft, IETF.
draft-ietf-mobileip-mipv6-ha-ipsec-05.txt May 2003
[5] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP).
RFC 2402, IETF. November 1998.
[6] A. Conta and S. Deering. Generic Packet Tunneling in IPv6
Specification. RFC 2473, IETF. December 1998.
[7] V. Devarapalli and R. Wakikawa and A. Petrescu and P. Thubert.
Nemo Basic Support Protocol (work in progress). Internet Draft,
IETF. draft-ietf-nemo-basic-support-01.txt September 2003
[8] P. Thubert and R. Wakikawa and V. Devarapalli. Examples of
basic Nemo usage (work in progress). Internet Draft, IETF.
draft-ietf-nemo-basic-usage-00.txt October 14 2003.
[9] T. Narten and E. Nordmark and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). RFC 2461, IETF. December 1998.
[10] J. Manner and M. Kojo. Mobility Related Terminology.
draft-ietf-seamoby-mobility-terminology-05.txt November 2003
Wakikawa, et al. Expires 16 Aug 2004 [Page 31]
Internet Draft HAHA protocol 16 Feb 2004
A. Changes from -00
- Obsolete two ICMP messages (Home Agent Solicitation and
Advertisement Message)
- Add a new MH message called Home Agent HELLO message
- Change the name of Binding Information Reply Message to Binding
Information Update Message
- Add a new MH message called Binding Information Acknowledgment
Message
- Add a section for a detailed example in Appendix B
Wakikawa, et al. Expires 16 Aug 2004 [Page 32]
Internet Draft HAHA protocol 16 Feb 2004
B. Distributed Home Network
This section describes a detailed example how multiple Home Agents
are configured in different routing domains. The HAHA protocol does
not completely cover all operations for this example at this time.
Readers are expected to read [8] before reading this section.
In distributed home network, a global Home is advertised by several
sites that are geographically distributed and meshed using tunnels
in a VPN fashion. Mobile Nodes locate the closest site using
DHAAD against the global Home Network and bind there. Some form of
inter-site synchronization (e.g. a routing protocol), which Mobile
IPv6 and Nemo Basic Support do not provide, must take place in order
to allow packets to be routed between the incoming site to the Mobile
Node. The HAHA (Home Agent to Home Agent) protocol is being designed
for that purpose.
In one model, each site is responsible for a subnet of Home. When a
Mobile Node roams far from its natural (default) site, it registers
to a Home Agent on a remote site, that takes the registration and
notifies at least the natural site of the foreign registration.
There are at least 3 approaches in order to locate the Home Agent
that has a registration for a given Mobile Node, Router or Mobile
Network:
- reactive
This method is also referred to as 'on-demand'. In case
of a binding cache miss, a Home Agent floods a Binding
Information Request message to all the other Home Agents with
the (destination of the packet) home address that is sought
for. Every Home Agent that has a registration for that home
address or for a Mobile Network that encompasses that home
address responds. This approach is traditionally used in fast
changing configurations, for instance if Mobile Nodes register
and de-register very often.
- proactive
An information is pushed to all Home Agents with the Home
Address and the Mobile Network Prefixes each time by Binding
Information Update message This approach is preferred for stable
configurations, for instance if Mobile IP is used as a tool to
simplify the configuration and reconfiguration of mostly stable
networks.
- predictive
Ranges of Home Addresses and prefixes are assigned to the Home
Agents, following a rule that is commonly computed by all Home
Agents. Dynamic Home Agent Address Discovery (DHAAD) returns
Wakikawa, et al. Expires 16 Aug 2004 [Page 33]
Internet Draft HAHA protocol 16 Feb 2004
only the address of one Home Agent, the one that is pre-allocated
for that Mobile Node. When the wrong Home Agent intercepts
packets, it can compute which is the right Home Agent and forward
packets to it at L2 if they are directly connected, or via a HAHA
tunnel which is established between Home Agents. This is what we
call 'Z' routing.
CN --------> closest HA CN ----------> closest HA
/ |
/ |
/ |
/ |
/ |
Assigned / |
HA v V
----------> Mobile Node Mobile Node
The Predictive Mode minimizes the control traffic, which may be
required for a large configuration. Some additional controls would
be necessary for the HAHA protocol to allow the negotiation and the
distribution of the shares of Home to be attributed to each Home
Agent.
One specific advantage of not relying on a Home Link for HAHA
communication is that for a large configuration, the Home Agents can
be organized hierarchically and distributed geographically, as a set
of local clusters linked together to form a global Home Network.
For instance, it is possible for a large ISP to partition the Home
Network for a given worldwide service, and assign a partition to a
cluster of Home Agents in each of the geographies. In predictive
mode, each Home Agent in the world would be able to compute the
best suited Home Agent in its local cluster (call this a Acting
Wakikawa, et al. Expires 16 Aug 2004 [Page 34]
Internet Draft HAHA protocol 16 Feb 2004
Home Agent) and the best suited Home Agent worldwide (call this the
Assigned Home Agent) for each and any Home Address.
HA HA
| ______ |
--+-----+--+- . -+- . -+-- TUNNEL --+-----+--+- . -+- .. -+--
| | | | ______ | | | |
MR1 MR2 MRi MRN MR1 MR2 MRi MRN
------ ------ ------ ------ ------ ------ ---- - ----
/64 A:B:1:i::/64 /64 A:B:n:i::/64
Distributed Home Network /48
<------------------------------------------------------------------>
extended HN Aggregated HN Virtual HN
<----------------------><---------------------->...<--------------->
Home Mob Mob Mob Mob Mob Mob Mob
<-----><----->...<-----><-----><----->...<----->...<----->...<----->
Any Home Agent processing an anycast DHAAD can predict the Assigned
Home Agent and local Acting Home Agents for a Home Address if that
information is added to the DHAAD request. In the case of Mobile
Routers, the service must be arranged in such ways that, for a given
registration, all the Mobile Networks are assigned to a same Home
Agent.
Possible flows: In order to register, a Mobile Node uses DHAAD which
returns one Home Agent in the closest cluster. This can be a Acting
Home Agent if the Mobile Node is roaming far from Home, but hopefully
it is in general the Assigned Home Agent for that Mobile Node. When
this is a Acting Home Agent, it needs to register to the Assigned
Home Agent as proxy binding.
When a packet destined to a given Home Address arrives at a Home
Agent from a Correspondent Node:
If the Home Agent is Assigned Home Agent for that Home Address and it
has a direct registration (it is primary), the Home Agent forwards
the packet over its bi-directional tunnel established with the Mobile
Node (the MNHA tunnel). If it has a proxy registration (it is
secondary), it forwards the packet to the primary Acting Home Agent -
or directly to the Mobile Node if that is practical for tunnel setup
and security reasons. Else it drops the packet.
Wakikawa, et al. Expires 16 Aug 2004 [Page 35]
Internet Draft HAHA protocol 16 Feb 2004
Else If the Home Agent is Acting Home Agent for that Home Address and
it has a direct registration (it is primary), the Home Agent forwards
the packet over its MNHA tunnel. If it has a proxy registration (it
is secondary), it forwards the packet to the primary Acting Home
Agent - or directly to the Mobile Node if that is practical for
tunnel setup and security reasons. Else, it forwards the packet to
the Assigned Home Agent.
CN ----------> Acting HA
/ closest to CN
/
/
/
Assigned /
HA V
"
"
"
"
"
" Acting HA primary
MN <----------- for that registration
(closest to MN)
CN ----------> closest HA
| to CN
|
|
|
|
v Acting HA, primary
MN <--------- for that registration
(closest to MN)
Else (if the Home Agent is the 'wrong Home Agent') the Home Agent
tunnels the packet to the best suited of the local Home Agents, be it
the Assigned Home Agent, or a local Acting Home Agent.
In the worst case, the packet may bounce from the receiving
Home Agent to the local Acting Home Agent, then to the Assigned
Home Agent, and finally to the Acting Home Agent that has the
registration. It is up to the Assigned Home Agent to forward the
proxy binding states to the Acting Home Agent on the receiving side
in order to allow Acting Home Agent to Acting Home Agent 'Z' routing.
Wakikawa, et al. Expires 16 Aug 2004 [Page 36]
Internet Draft HAHA protocol 16 Feb 2004
If the Home Agents are distributed geographically, it is expected
that, in general, the angles of the Z (the Home Agents) are close to
the Mobile Node and Correspondent Node respectively, relatively to
the distance between the Home Agents, which makes the cost of the
bouncing acceptable in terms of distance and hops.
When a packet from a registered Mobile Node arrives over the MNHA
tunnel to a Home Agent (one that it is registered to), the Home Agent
forwards the packet directly to the Correspondent Node. That Home
Agent is supposed to be close to the Mobile Node, making the MN-HA-CN
triangle as flat as possible and limiting the cost of the dogleg.
Wakikawa, et al. Expires 16 Aug 2004 [Page 37]
Internet Draft HAHA protocol 16 Feb 2004
Authors Addresses
Ryuji Wakikawa
Keio University and WIDE
5322 Endo Fujisawa Kanagawa
252-8520
Japan
Email: ryuji@sfc.wide.ad.jp
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: vijay.devarapalli@nokia.com
Pascal Thubert
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
France
Email: pthubert@cisco.com
Wakikawa, et al. Expires 16 Aug 2004 [Page 38]
Internet Draft HAHA protocol 16 Feb 2004
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However,
this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wakikawa, et al. Expires 16 Aug 2004 [Page 39]