Internet Engineering Task Force Bjorn Chambless
INTERNET DRAFT Portland State University
Jim Binkley
Oregon Graduate Institute
October 27, 1997
HARP - "Home Agent Redundancy Protocol"
<draft-chambless-mobileip-harp-00.txt>
Status of This Memo
Distribution of this memo is unlimited.
This document is an Internet-Draft. 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 made obsolete by other
documents at any time. It is not appropriate to use Internet
Drafts as reference material, or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This document presents a protocol called the Home Agent Redundancy
Protocol or HARP. HARP is an optional extension to Mobile-IP [RFC-
2002]. Mobile-IP includes the notion of a Home Agent which is
a host located on the home IP subnet for Mobile Nodes. Home Agents
forward packets to Mobile Nodes that are away from home. Since Mobile
Nodes are dependent on the Home Agent for connectivity when away from
home, the Home Agent represents a possible single source of failure for
the Mobile IP system.
HARP is a protocol which allows a pair (or set) of Home Agents
to cooperate and share Mobile-IP Mobile Node registration
information. If one of the HARP peers should fail, the Mobile-IP
system will not necessarily fail, hence HARP introduces Home
Agent redundancy into the Mobile-IP system. Mobile Nodes are
not aware that HARP exists, so HARP requires no changes to
Mobile-IP as a protocol. In this document, we present the HARP
architecture and protocol.
Chambless & Binkley Expires March 25 1998 [Page 1]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
Table of Contents
1. Introduction
1.1. Design Goals
1.2. Terminology
2. Protocol Overview
2.1 Assumptions
2.2 Protocol Overview
2.3 Redundancy Considerations
3. Mobile-IP Home Link Considerations
3.1 Non-partitioned Home Subnet
3.2 Partitioned Home Subnet
4. HARP Protocol
4.1. Message Types and Functions
4.2. Message Formats
4.2.1. HARP Registration Forward (HARP_FORWARD)
4.2.2. HARP Ping (HARP_PING)
4.2.3. HARP Ping Acknowledge (HARP_ACK)
4.2.4. HARP Registration Dump Request (HARP_DUMP_REQ)
4.2.5. HARP Registration Dump (HARP_REG_DUMP)
5. Security Considerations
References.........................................................
Contacts...........................................................
Chambless & Binkley Expires March 25 1998 [Page 2]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
1. Introduction
Mobile-IP is designed to allow a Mobile Node (MN) to change its
point of IP subnet attachment in the Internet at the network or
IP layer. The MN is always identified by it home IP address
regardless of its current network location. Its mobility is
not limited by conventional IP network boundaries.
The Mobile-IP system consists of Mobile Nodes, and two kinds of
agents, known as Home Agents (HA), and Foreign Agents (FA).
Home Agents remain "home" and when the Mobile Node is not home,
forward packets sent to the conventional IP subnet of the Mobile
Node to a possibly distant point of attachment. The remote
address is called a Care Of Address (COA), and may be at a Foreign
Agent or a co-located Mobile Node. As a Mobile Node travels from one
IP link to another, it determines possible COAs and uses the
Mobile-IP registration protocol to inform the Home Agent of its
current location. The Home Agent then forwards packets addressed to
the Mobile Node at its home network to the its current location.
In Mobile-IP, as currently specified, a single HA services an
MN. The MN is reliant on this Home Agent for its connectivity.
Thus the HA represents the possibility of a single point of
failure for Mobile-IP. A Home Agent may be responsible for
multiple Mobile Nodes on multiple home subnets. The failure of
a single HA may then result in the loss of connectivity for
numerous Mobile-IP Mobile Nodes located throughout the Internet.
Thus the Home Agent and Mobile Node taken together have a shared
fate. A Mobile Node cannot afford the loss of its Home Agent.
This vulnerability is inconsistent with the fault tolerant nature
of the Internet. Additionally redundancy is needed. We have
developed the Home Agent Redundancy Protocol (HARP) as an optional
extension to Mobile-IP to address this problem.
HARP is a simple protocol based on the notion of one or more
HARP peers that act as a single shared Home Agent. Each HARP
peer is configured with information about its HARP peers and
forwards any Mobile-IP registration messages it receives to its
peers. HARP peers act in parallel to create or delete tunnels
[RFC 2003] to the Mobile Node's remote COA according to the last
registration message received. Although we speak of HARP peers
as a set, in general, there will probably be only two cooperating
systems in the HARP sub-system.
There are three major types of messages, 1. HARP TCP DUMP, 2.
HARP UDP FORWARD., and 3. HARP UDP PING. At boot, a TCP connection
may optionally be made to a remote HARP peer to exchange mobile
routing information. At runtime, HARP UDP PING messages are
exchanged to determine if remote HARP peers are up. At runtime,
HARP UDP FORWARD messages are used to forward Mobile-IP registration
messages from the receiving HARP agent to its HARP peers.
Chambless & Binkley Expires March 25 1998 [Page 3]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
HARP assumes no changes to Mobile-IP proper; i.e., the existence
of one or more HARP peers is kept hidden from Mobile Nodes.
Therefore HARP will interoperate with existing Mobile-IP
implementations. In routing terms, one may think of the HARP
peers as advertising the existence of a common IP subnet into
an interior routing domain. Externally, a MN's Mobile-IP
authentication message is routed to the nearest ( according to local
routing metrics ) HARP peer which, in turn, informs other HARP peers
about the MN's location via a HARP FORWARD message. Packets are routed
to HARP peer Home Agents via conventional routing, and since each HARP
peer maintains Mobile Node COA information, packets are forwarded to
the MN.
1.1 Design Goals
The Home Agent Redundancy Protocol (HARP) aims to remove the
Home Agent as a single point of failure for Mobile-IP.
The protocol is implemented entirely through the enhancement of
Home Agent functionality. There are no additional responsibilities
or modifications required of either Mobile Nodes or Foreign
Agents. Mobile Nodes and Foreign Agents have no knowledge of
HARP and Mobile-IP will interoperate with HARP capable Home
Agents.
The Home Agent Redundancy Protocol will be made secure, minimally
with authentication, and optionally with authentication and
privacy mechanisms.
Home Agent Redundancy makes no assumptions about the physical
media utilized by the Mobile-IP environment. Therefore HARP
does not limit the physical implementation of Mobile-IP.
The number of Mobile Nodes is not limited by HARP.
1.2 Terminology
Home Agent Redundancy Protocol terminology uses and expands on
the Mobile-IP terminology presented in RFC 2002. The following
terms are specific to the Home Agent Redundancy protocol:
HARP peers -
co-HAs -
co-Home Agents - A set of Home Agents acting in concert
to provide connectivity to one or more Mobile Nodes.
These hosts share an IP address on the Home Subnet but
each has a uniquely identified interface outside of the
Home Network. Co-HAs, a priori, know about a small set
of cooperating Home Agents and exchange registration
information regarding Mobile Nodes and periodically test
peer co-HA reachability. One may assume that there are
only two Home Agents in a set of co-HAs, but there is no
inherent limit to the number of peers in a Co-HA set.
Chambless & Binkley Expires March 25 1998 [Page 4]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
Primary-HA, Primary - The Home Agent of a co-HA set which
is currently receiving registration information directly
from a MN. The Primary Home Agent shares this information
with its co-HAs (Secondaries) by forwarding registration
packets to the peers. A HA is primary because the IP
routing infrastructure is currently routing the Mobile-IP
registration packet to it.
Secondary-HA, Secondary - A Home Agent of a HARP set which
is receiving registration information about a given MN
indirectly through its co-Home Agent which is acting as
the Primary.
HARP - Home Agent Redundancy Protocol.
HARP PORT - The HARP port number which is the same for both
the TCP and UDP ports. This port has not yet been allocated
yet.
Home Network - Home Subnet - The subnet containing both
Home Agents and the home addresses of the Mobile Nodes they
are serving. This subnet may be partitioned in terms of the
co-HAs or the co-HAs may be physically present on the same
link.
Partitioned Subnet - A physically divided Home Subnet.
Home Agents in a co-HA pair may be thought of as existing
on a virtual subnet. Physically divided means that the
co-HAs cannot use that link to communicate directly.
Note that this is not a requirement of HARP, but an
aspect of network design. We will discuss the network
design aspects of HARP below.
AWAY(Mobile-IP state) - The state of a Mobile Node, with
respect to its Home Agent(s), in which datagrams addressed
to the MN arrive at its Home-Subnet and are tunneled to
the MN's Care Of Address by one of the Mobile Node's
Home Agents.
AT HOME (Mobile-IP state) - The state of a Mobile Node with
respect to a Home Agent in which the MN's current point
of attachment in the Internet is consistent with its IP
address. In this state, the Mobile Node will receive
packets directly.
At CoHA(Mobile-IP state) - The state of of Mobile Node,
with respect to a Home Agent, in which the MN's home
subnet is partitioned and a packet arrives for the MN
at another link of the partitioned network. In this
case, packets addressed to the home subnet may arrive
on a portion of the home subnet to which the Mobile Node
has no link layer attachment. These packets must then
be forwarded (tunneled) by one HARP peer to another.
Chambless & Binkley Expires March 25 1998 [Page 5]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
2. Protocol Overview
This section provides a protocol overview of HARP. We discuss
HARP from a routing topological point of view, and provide a
short discussion of redundancy issues.
2.1 Assumptions
The following are fundamental assumptions about the design of
a HARP redundant agent network:
1. So that Mobile-IP and Mobile Nodes need not know about the
HARP sub-system, we assume that the HARP peers share a single
IP subnet and a single IP network address.
2. Due to assumption 1, and because the HARP agents must
communicate amongst themselves, we assume they are multi-homed
in the sense that there exist on one node at least two IP
addresses. We will call them the "Mobile-IP subnet" address,
and the "HARP peer" address. The former is shared. The latter
is not shared. The HARP peer address is unique and is used by
HARP systems to communicate amongst themselves. Note that this
does not rule out an agent with only one physical interface.
3. We assume that the HARP peers exist within an interior
routing domain that runs a IP interior routing protocol such as
RIPv2 [RFC-1721], or OSPF [RFC-2178]. Thus packets addressed to the
Mobile-IP subnet, including Mobile-IP authentication packets, are
routed to the HARP peers according to the local metrics of the
interior routing protocols. At any given time, any packet bound for
a Mobile Host at HOME, will go to exactly one HARP peer. Ideally,
if an interior link fails, an interior routing protocol will
switch Mobile-IP packets to the other HARP system. This does
not rule out the possibility of HARP being used with static
routes in interior routers. External routes to the Mobile-IP
subnet may always be changed by hand in the event of HARP agent
failure.
Finally, it is NOT assumed that the HARP Mobile-IP subnet is
partitioned. Partitioning may add useful redundancy attributes.
But the subnet need not be partitioned. How this is handled
is implementation and site specific and will be discussed more
in the next section.
Chambless & Binkley Expires March 25 1998 [Page 6]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
2.2 Protocol Overview
Diagram 1:
MN or CH
|
| MN/CH path
|
Internet
|
|
|
------------------------
R1 interior path R2
| |
H1 H2
| |
----- Mobile-IP subnet ------
Please refer to diagram 1 for the following discussion.
Assume we have a Mobile Node that is away from home. Assume
that at home we have two routers R1, and R2, which are using a
local interior routing protocol (for example, OSPF, or static
routes). Behind them are two HARP peers which advertise a
Mobile-IP subnet to the routers and to the network. Along with
the Mobile Node on the exterior Internet, there exists a
Correspondent Host (CH). The latter is any host interested
in sending packets to the Mobile Node.
The Mobile Node is unaware of Home Agent redundancy and sends
registration information only once to the shared HA address
located on the Home Subnet. Due to the nature of unicast routing,
this information may be received by either Home Agent, but is
likely to be received by only one. Packets sent from the CH to
the Mobile Node will likewise be routed to one or the other Home
Agent (whichever is "closer", according to the metrics of the
interior routing system). Note that any of these datagrams
(Mobile-IP authentication or ordinary datagrams) may at any time
go to either Home Agent.
When a Mobile-IP registration packet is received by a co-HA, it
will encapsulate that registration packet and forward it to
another co-HA via the HARP UDP port. Thus the peer co-HA will
know that the other HA directly received the registration, and
will also know the current MN Care Of Address; i.e., the
forwarding address for CH packets.
Chambless & Binkley Expires March 25 1998 [Page 7]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
Each HARP peer takes the same internal action whether it receives
a Mobile-IP registration packet directly from a MN or whether
it receives it from a HARP peer. For example, in parallel, the
Mobile-IP vlist entry is created or refreshed, and tunnels are
setup (if needed) from the Home Agent to the Care Of Address.
In Mobile-IP terms, the Home Agents act in parallel.
Mobile-IP authentication (MN to HA, FA to HA, etc.) is performed
once at the primary co-HA system. The secondary is expected to
perform a separate HARP protocol authentication (HA to HA) on
packets forwarded to it by the primary via the HARP UDP (or TCP in the
case of table exchanges) ports.
If one Home Agent should fail, the interior routing structure
should notice that it has failed as a router, and normal routing
convergence will remove that path to the Mobile-IP subnet.
Convergence may take manual route manipulation in some cases
where static routes are used. As a result, the Mobile-IP system
should be able to survive the loss of a Home Agent as packets
will be routed to a surviving Home Agent.
HARP consists of three major packets type sent from one HARP
peer to other HARP peers. (Note that some of the types have
acknowledgements). We have already mentioned the HARP UDP FORWARD,
which is a simple repackaging of the Mobile-IP registration
packet itself. In addition there are two other kinds of messages
used in the HARP system. There is a HARP PING and a HARP boottime
table exchange. The former uses UDP and the later uses TCP.
The UDP HARP PING is used to determine if other HARP peers are
up. If a PING fails (say 3 out of 5), a HARP agent knows that
either its peer has failed or the path to it has been partitioned.
It may then take implementation-specific actions which should
include ways to attempt to notify local administrators that
critical interior links or systems have failed. Other implementation
actions may be taken as well if needed. For example, a dormant
local link interface might be enabled.
HARP provides an optional boot protocol which uses TCP to
exchange all HARP information in one connection. Thus if one
HARP system reboots after failure, it can acquire Mobile-IP
state information from another HARP peer. At boot, a HARP Home
Agent will attempt to establish a TCP connections with its co-HAs at
their respective TCP HARP PORTs. If successful, these connections
are used to pass all current Mobile Node registration information from
a running HA to a booting co-HA. When all relevant information
has been passed, and the booting Home Agent is synchronized with
respect to MN Registrations, the TCP connections are closed. If
the peer system is not available, the sending system will
timeout and proceed as the peer may be unavailable or rebooting.
Chambless & Binkley Expires March 25 1998 [Page 8]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
2.3 Redundancy Considerations
There are a number of redundancy considerations regarding HARP
that have driven its design which we will present in this
section.
The failure of one HARP agent, or a network interface on that
agent, or possibly a path to that agent should not necessarily
cause the Mobile-IP network to fail. This is, of course, the
goal of the protocol itself. In addition to simple node
redundancy, redundancy may be possible if a path from the
MN (CH) in question exists to another HARP agent even when an
interior (or exterior) router (or associated interface) fails.
Thus HARP may sometimes be able to take advantage of dynamic
interior routing.
On the other hand, the interior path between the HARP agents
should not be allowed to fail. If it does, it is possible that
the Mobile-IP registration packets might go one way and datagram
packets from a given CH might go another, thus leading to a
(bizarre) partition. This is one of the reasons for the HARP
PING protocol. Lack of connectivity between the agents should
lead to a local management alert. Of course, fundamentally, an
interior path failure might cut the Mobile Node off from important
local services and should be taken seriously in any case.
As part of the overview, we should justify why we have chosen
UDP for internal HARP forwarding as opposed to say TCP connections
between HARP agents. We felt that the HARP protocol should
internally match the design of Mobile-IP. Registration for
Mobile Nodes while away from home is driven by Mobile-IP/UDP
based packets. Since the Mobile Node drives the registration,
we felt that forwarding these packets internally over presumably
shorter channels (with higher bandwidth) was reasonable. As a
result, Mobile-IP registration also drives the HARP sub-system.
We also felt that given the goal of producing a reliable server
with reliable software it made more sense to use a simple protocol
without the enhanced complexity of a TCP state machine to deal
with possible protocol errors. Thus agent-side implementation
should be simpler. As a final point, even though the number of
HARP peers in a HARP set is likely to be very small, at some
future time, one might consider experimentally replacing the
unicast UDP HARP (re)registration with reliable multicast
registration. Of course, TCP lacks multicast capability.
Redundancy considerations for the Mobile-IP home link itself
are discussed in the next section.
Chambless & Binkley Expires March 25 1998 [Page 9]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
3. Mobile-IP Home Link Considerations
One might claim that the impact of HARP on the actual Mobile-IP
home subnet link could be regarded as implementation dependent.
This is because Mobile-IP itself is aimed not so much at dealing
with how mobile nodes interact at the home subnet, but how they
can take a home subnet IP address, move to other subnets, and
retain connectivity. Thus HARP primarily seeks to address the
problem of what might happen if the home forwarding agent is
lost. Still, the issue of redundancy on the Mobile-IP home link
exists and there is a small amount of protocol impact on HARP.
In a very simple sense, having two possible "home" links can
aid redundancy as well. If one home fails, a second home might
be available. In this section, we will discuss this issue and
make implementation suggestions.
In the end local network management must decide what they want,
according to available local resources and local tradeoffs.
Therefore we suggest that implementations remain flexible
where home subnet design is concerned.
The Home Mobile-IP subnet may be either:
1. not partitioned; i.e., the HARP Home Agents could reside
on the same link and would be able to reach each other on that
link.
2. partitioned; i.e., the HARP Agents might reside on
different links, and would NOT be able to reach each other on
that link.
3.1 Non-Partitioned Home Subnet
If the link is not-partitioned, the HARP Home Agents can reach
each other directly. It is not advisable to have both HARP IP
interfaces (which by definition share the same IP interface)
active as confusion with nodes on the shared subnet might result.
If the systems act as routers only (and not as end systems), one might
claim that it would not matter, but there is no point in having both
systems race to answer ARP [RFC-826] requests. Worse, any node that
attempted to directly connect to the shared HARP subnet IP address with
a transport protocol may experience failure due to ARP cache
overwrites.
Thus it is reasonable to assume an implementation might provide
a way to shut down one HARP interior IP interface and dynamically
bring another up if failure of the other HARP node is detected.
This can be done by the normal method of designated router
election. A set of HARP peers exchanging HARP PING messages
Chambless & Binkley Expires March 25 1998 [Page 10]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
may choose the HARP peer with the highest IP address to be the
only active peer on the interface. We assume that the PINGS
are done over the non-Mobile-IP (and non-shared) IP address.
If PINGS fail from that interface, (say after N failures,
where N is configured in), the remaining HARP peers would again
elect a designated router which will take over the "live" ARP
function.
3.2 Partitioned Home Subnet
If HARP peers exist on the same link, it is possible that the
failure of an interior router or router interface could lead to
the loss of all HARP agents. Thus one may have replaced the
Mobile-IP single point of failure mode with a more elaborate
single failure mode. We suggest that if practicable (and this
ultimately depends on per site network resources), it may be
better to partition the home mobile link. In other words, the
internal path to the HARP agents would still be an interior
routing path, but the agents themselves might best be in widely
dispersed locations. For example, HARP peers would be placed
behind different interior routers, possibly in different buildings.
Such a partitioned network is not ideal for non-Mobile nodes,
as IP subnet reachability problems would result if non-Mobile
nodes were placed on the Mobile subnet. As a result, one might
choose to only place Mobile-IP nodes on such partitioned links.
Where a partitioned scheme is used, it is necessary for the Home
Agents to install tunnels between themselves. This mechanism is
directly analogous to the Mobile-IP tunnel from the Home Agent to
the Foreign Agent. A packet sent to a co-HA where the MN is not
resident, would be forwarded to the other co-HA. Note that HA
tunneling is not strictly necessary when the Mobile subnet is
not partitioned, unless the Home Agents are only speaking one
at a time to the home link.
A simple and less elegant solution would be to disable
Mobile-IP router advertisements for Home Agents where actual
physical residence is not desired. A dynamic scheme for election
here could be used, or this function could be done manually.
For example, one might choose to have only one Mobile-IP
home subnet from the interior point of view. The other home
might reside on a virtual interface that is not directly accessible
except in the exterior routing sense. Mobile Nodes in such a
system might never be able to directly visit the second home.
In summary, where interior router resources exist, partitioning
may provide greater surviveablity.
Chambless & Binkley Expires March 25 1998 [Page 11]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
4.1 Message Types and Functions
The Home Agent Redundancy Protocol has five messages:
HARP_FORWARD - This message consists of an encapsulated
Mobile Node registration message which is tunneled from
the receiving Home Agent to its co-HA. This
information is used to update the co-HA's registration
tables. This message type uses UDP and is sent to
the HARP UDP PORT.
HARP_PING - This message is sent at configurable intervals
from one co-HA to another to confirm connectivity.
If the Home Agent receives no response from its
co-HA peer, the co-HA is assumed to be unreachable.
This message type uses UDP and is sent to the HARP
UDP PORT.
HARP_ACK - Sent in response to a HARP_PING to acknowledge
that the PING message has been received. This
message type uses UDP and is sent to the HARP UDP
PORT.
HARP_REG_REQ - A message requesting all Mobile Node
registration information. This is the first message
sent upon establishment of an inter-co-HA TCP
connection. This message type utilizes TCP.
HARP_REG_DUMP - TCP message which contains Mobile Node
registration information maintained by a Home Agent.
This message is sent in response to a HARP_REG_REQ.
Note that more than one DUMP message may be sent,
but each DUMP message may contain more
than one Mobile-IP node registration.
4.2. Message Formats
All HARP messages are structured in a Tag, Length, Value format.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type and Length occupy one unsigned short and are 16-bit values.
They are assumed to be in network byte order. Messages are sent
to either the HARP UDP or TCP PORT.
Chambless & Binkley Expires March 25 1998 [Page 12]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
4.2.1. HARP Registration Forward (HARP_FORWARD)
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=HARP_FORWARD | size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile-IP registration packet ... |
| |
type: HARP_FORWARD = 1
size: in bytes of the value field.
value: Mobile-IP registration packet.
HARP Registration Forward messages are used to encapsulate and
forward registration updates received from a Mobile Node. They
are sent between co-HAs. The message consists of two bytes of
type followed by two bytes indicating the length in bytes of a
Mobile-IP registration packet. The Data field is a Mobile-IP
registration packet of the size indicated by the size field.
The registration packet has the same format as used with Mobile-IP.
Optional (TLV) elements may be present and should be processed.
However it is expected that the receiving Home Agent deals with
all MN/HA and MN/FA authentication and may remove those elements
from the registration packet.
4.2.2 HARP Ping (HARP_PING)
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=HARP_PING | size=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HARP peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
type: HARP_PING = 2
size: 4
value: (reachable) IP address of HARP sender
HARP_PING messages are sent between all the members of a HARP
co-HA set. They are sent with a configured periodicity and are sent
within a configured mechanism for determining the loss of an interior
routing path. For example, one might send one message a minute, and
retry N times. If the sending agent determines that another
agent is down, it may initiate implementation-dependent mechanisms
including SNMP alerts, paging a network administrator, and/or
taking up or down a local interface. We include the HARP peer
IP address in order to limit possible problems caused by
multi-homing.
Chambless & Binkley Expires March 25 1998 [Page 13]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
4.2.3. HARP Ping Acknowledge (HARP_ACK)
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=HARP_ACK | size=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HARP peer IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
type: HARP_ACK = 3
size: 4
value: HARP peer IP address
A HARP Ping Acknowledge message is sent in response to a HARP
Ping. The peer IP address belongs to the sender of the
acknowledgement.
4.2.4 HARP Dump Request (HARP_DUMP_REQ)
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=HARP_DUMP_REQ | size=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
type: HARP_DUMP_REQ = 4
size: 0
The HARP Dump Request message consists of two bytes of type
followed by two bytes giving the size of the data field, which
is always zero.
A HARP_DUMP_REQ is passed from a Home Agent in Initializing State
to its co-HA through the inter-co-HA TCP connection. If the receiving
co-HA does not receive this message, it should shut down the connection
and log an error. If the client's connection fails or no DUMP appears
within a configured timeout interval, the client should disconnect and
log an error.
Chambless & Binkley Expires March 25 1998 [Page 14]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
4.2.5 HARP Registration Dump (HARP_REG_DUMP)
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=HARP_REG_DUMP | size=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Registrations |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of Registrations |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile-IP registration field ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile-IP registration field ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| etc. | |
type: HARP_REG_DUMP = 5
size: 8
value:
Number of Registrations: a 32-bit unsigned integer in network
byte order
Size of Registrations: a 32-bit unsigned integer in
network byte order. This field contains the size of all
the Mobile-IP registration sections which must all have
the same size.
Some number of Mobile-IP registration requests.
A HARP Registration Dump message is sent in response to a TCP
connect and HARP Dump Request. It contains current registration
information for all Mobile Nodes serviced by a given Home Agent. "The
number of registrations" field tells the receiver how many registration
messages are being sent. The size of the registration message gives
the size of each Mobile-IP registration message which as before, is
assumed to be the same format as is used with Mobile-IP. Note
we assume that all message sub-fields are of the same length.
Also note that a Home Agent need not write all of the information
with the same TCP write. Nor does the responding peer need to
send all Mobile-IP registration messages in one DUMP message.
Multiple DUMP messages may be sent over the same connection.
The channel must be closed by the receiver when it has written
all of the messages.
Chambless & Binkley Expires March 25 1998 [Page 15]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
5. Security Considerations
In this section, we briefly consider the security of the HARP
protocol itself. Security might also be taken to mean
"survivability" and we will discuss that notion first, and then
return to HARP protocol network security.
In terms of survivability, HARP primarily addresses the problem
that a Mobile-IP system, serving a given number of Mobile Nodes
may fail due to the loss of a single Home Agent. Home Agent
redundancy reduces the odds of a total Mobile-IP system
outage due to failure of a Home Agent node, a network
adapter on that node, or possibly an internal routing path to
that node. Given that we may have multiple Home Agents that
cooperate to emulate a single home agent there may also be
additional security benefits. For example, a denial of service
attack against one Home Agent may not apply to the other (perhaps
if they are not on the same link). Hence the Mobile-IP network
might continue to function.
For protocol security of HARP itself, we require the use of IP
layer security [RFC 1825] between any given HARP pair in a set
of HARP peers. The HARP pair may use a TCP connection
between them at boot for route synchronization, and will use
UDP to forward Mobile-IP registration packets. It is required
that all of these end to end TCP and UDP channels be protected
by at least IPSEC authentication [RFC 1826], and optionally by
authentication and encryption [RFC 1827]. Authentication is a
requirement. Thus security will be end to end for the HARP
protocol between HARP peers.
Chambless & Binkley Expires March 25 1998 [Page 16]
INTERNET DRAFT Home Agent Redundancy Protocol October 1997
References
[RFC-826] Plummer, D., "An Ethernet Address Resolution Protocol:
Or Converting Network Protocol Addresses to 48.bit Ethernet
Addresses for Transmission on Ethernet Hardware", STD 37,
November 1982.
[RFC-1721] Malkin, G., "RIP Version 2 Protocol Analysis",
November 1994.
[RFC-1825] Atkinson, R., "Security Architecture for the Internet
Protocol", Naval Research Laboratory, July 1995.
[RFC-1826] Atkinson, R., "IP Authentication Header", August 1995.
[RFC-1827] Atkinson, R., "IP Encapsulated Security Payload",
August 1995.
[RFC-2002] Perkins, C., "IP Mobility Support", October 1996.
[RFC-2003] Perkins, C., "IP Encapsulation within IP",
October 1996.
[RFC-2178] Moy, J., "OSPF Version 2", July 1997.
Chambless & Binkley Expires March 25 1998 [Page 17]
^L
INTERNET DRAFT October 27, 1997 Expires April 1997
Contacts
Bjorn Chambless
Computer Science Department
Portland State University
Email: bjorn@cs.px.edu
Jim Binkley
Computer Science and Engineering Department
Oregon Graduate Institute
Email: jrb@cse.ogi.edu
Chambless & Binkley Expires March 25 1998 [Page 18]