idnits 2.17.1 draft-chambless-mobileip-harp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 4) being 59 lines == It seems as if not all pages are separated by form feeds - found 16 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 31 characters in excess of 72. ** There are 94 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC-2002]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 178 has weird spacing: '...- A set of Ho...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 1997) is 9672 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2003' is mentioned on line 122, but not defined == Missing Reference: 'RFC 1825' is mentioned on line 737, but not defined ** Obsolete undefined reference: RFC 1825 (Obsoleted by RFC 2401) == Missing Reference: 'RFC 1826' is mentioned on line 742, but not defined ** Obsolete undefined reference: RFC 1826 (Obsoleted by RFC 2402) == Missing Reference: 'RFC 1827' is mentioned on line 743, but not defined ** Obsolete undefined reference: RFC 1827 (Obsoleted by RFC 2406) == Unused Reference: 'RFC-1825' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'RFC-1826' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'RFC-1827' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'RFC-2003' is defined on line 767, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1721 ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2178 (Obsoleted by RFC 2328) Summary: 21 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Bjorn Chambless 2 INTERNET DRAFT Portland State University 3 Jim Binkley 4 Oregon Graduate Institute 5 October 27, 1997 7 HARP - "Home Agent Redundancy Protocol" 8 10 Status of This Memo 12 Distribution of this memo is unlimited. 14 This document is an Internet-Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 Areas, and its Working Groups. Note that other groups may also 17 distribute working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months, and may be updated, replaced, or made obsolete by other 21 documents at any time. It is not appropriate to use Internet 22 Drafts as reference material, or to cite them other than as a 23 ``working draft'' or ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 28 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 29 Coast), or ftp.isi.edu (US West Coast). 31 Distribution of this memo is unlimited. 33 Abstract 35 This document presents a protocol called the Home Agent Redundancy 36 Protocol or HARP. HARP is an optional extension to Mobile-IP [RFC- 37 2002]. Mobile-IP includes the notion of a Home Agent which is 38 a host located on the home IP subnet for Mobile Nodes. Home Agents 39 forward packets to Mobile Nodes that are away from home. Since Mobile 40 Nodes are dependent on the Home Agent for connectivity when away from 41 home, the Home Agent represents a possible single source of failure for 42 the Mobile IP system. 44 HARP is a protocol which allows a pair (or set) of Home Agents 45 to cooperate and share Mobile-IP Mobile Node registration 46 information. If one of the HARP peers should fail, the Mobile-IP 47 system will not necessarily fail, hence HARP introduces Home 48 Agent redundancy into the Mobile-IP system. Mobile Nodes are 49 not aware that HARP exists, so HARP requires no changes to 50 Mobile-IP as a protocol. In this document, we present the HARP 51 architecture and protocol. 53 Table of Contents 55 1. Introduction 56 1.1. Design Goals 57 1.2. Terminology 59 2. Protocol Overview 60 2.1 Assumptions 61 2.2 Protocol Overview 62 2.3 Redundancy Considerations 64 3. Mobile-IP Home Link Considerations 65 3.1 Non-partitioned Home Subnet 66 3.2 Partitioned Home Subnet 68 4. HARP Protocol 69 4.1. Message Types and Functions 70 4.2. Message Formats 71 4.2.1. HARP Registration Forward (HARP_FORWARD) 72 4.2.2. HARP Ping (HARP_PING) 73 4.2.3. HARP Ping Acknowledge (HARP_ACK) 74 4.2.4. HARP Registration Dump Request (HARP_DUMP_REQ) 75 4.2.5. HARP Registration Dump (HARP_REG_DUMP) 77 5. Security Considerations 79 References......................................................... 80 Contacts........................................................... 82 1. Introduction 84 Mobile-IP is designed to allow a Mobile Node (MN) to change its 85 point of IP subnet attachment in the Internet at the network or 86 IP layer. The MN is always identified by it home IP address 87 regardless of its current network location. Its mobility is 88 not limited by conventional IP network boundaries. 90 The Mobile-IP system consists of Mobile Nodes, and two kinds of 91 agents, known as Home Agents (HA), and Foreign Agents (FA). 92 Home Agents remain "home" and when the Mobile Node is not home, 93 forward packets sent to the conventional IP subnet of the Mobile 94 Node to a possibly distant point of attachment. The remote 95 address is called a Care Of Address (COA), and may be at a Foreign 96 Agent or a co-located Mobile Node. As a Mobile Node travels from one 97 IP link to another, it determines possible COAs and uses the 98 Mobile-IP registration protocol to inform the Home Agent of its 99 current location. The Home Agent then forwards packets addressed to 100 the Mobile Node at its home network to the its current location. 102 In Mobile-IP, as currently specified, a single HA services an 103 MN. The MN is reliant on this Home Agent for its connectivity. 104 Thus the HA represents the possibility of a single point of 105 failure for Mobile-IP. A Home Agent may be responsible for 106 multiple Mobile Nodes on multiple home subnets. The failure of 107 a single HA may then result in the loss of connectivity for 108 numerous Mobile-IP Mobile Nodes located throughout the Internet. 109 Thus the Home Agent and Mobile Node taken together have a shared 110 fate. A Mobile Node cannot afford the loss of its Home Agent. 112 This vulnerability is inconsistent with the fault tolerant nature 113 of the Internet. Additionally redundancy is needed. We have 114 developed the Home Agent Redundancy Protocol (HARP) as an optional 115 extension to Mobile-IP to address this problem. 117 HARP is a simple protocol based on the notion of one or more 118 HARP peers that act as a single shared Home Agent. Each HARP 119 peer is configured with information about its HARP peers and 120 forwards any Mobile-IP registration messages it receives to its 121 peers. HARP peers act in parallel to create or delete tunnels 122 [RFC 2003] to the Mobile Node's remote COA according to the last 123 registration message received. Although we speak of HARP peers 124 as a set, in general, there will probably be only two cooperating 125 systems in the HARP sub-system. 127 There are three major types of messages, 1. HARP TCP DUMP, 2. 128 HARP UDP FORWARD., and 3. HARP UDP PING. At boot, a TCP connection 129 may optionally be made to a remote HARP peer to exchange mobile 130 routing information. At runtime, HARP UDP PING messages are 131 exchanged to determine if remote HARP peers are up. At runtime, 132 HARP UDP FORWARD messages are used to forward Mobile-IP registration 133 messages from the receiving HARP agent to its HARP peers. 135 HARP assumes no changes to Mobile-IP proper; i.e., the existence 136 of one or more HARP peers is kept hidden from Mobile Nodes. 137 Therefore HARP will interoperate with existing Mobile-IP 138 implementations. In routing terms, one may think of the HARP 139 peers as advertising the existence of a common IP subnet into 140 an interior routing domain. Externally, a MN's Mobile-IP 141 authentication message is routed to the nearest ( according to local 142 routing metrics ) HARP peer which, in turn, informs other HARP peers 143 about the MN's location via a HARP FORWARD message. Packets are routed 144 to HARP peer Home Agents via conventional routing, and since each HARP 145 peer maintains Mobile Node COA information, packets are forwarded to 146 the MN. 148 1.1 Design Goals 150 The Home Agent Redundancy Protocol (HARP) aims to remove the 151 Home Agent as a single point of failure for Mobile-IP. 153 The protocol is implemented entirely through the enhancement of 154 Home Agent functionality. There are no additional responsibilities 155 or modifications required of either Mobile Nodes or Foreign 156 Agents. Mobile Nodes and Foreign Agents have no knowledge of 157 HARP and Mobile-IP will interoperate with HARP capable Home 158 Agents. 160 The Home Agent Redundancy Protocol will be made secure, minimally 161 with authentication, and optionally with authentication and 162 privacy mechanisms. 164 Home Agent Redundancy makes no assumptions about the physical 165 media utilized by the Mobile-IP environment. Therefore HARP 166 does not limit the physical implementation of Mobile-IP. 168 The number of Mobile Nodes is not limited by HARP. 170 1.2 Terminology 172 Home Agent Redundancy Protocol terminology uses and expands on 173 the Mobile-IP terminology presented in RFC 2002. The following 174 terms are specific to the Home Agent Redundancy protocol: 176 HARP peers - 177 co-HAs - 178 co-Home Agents - A set of Home Agents acting in concert 179 to provide connectivity to one or more Mobile Nodes. 180 These hosts share an IP address on the Home Subnet but 181 each has a uniquely identified interface outside of the 182 Home Network. Co-HAs, a priori, know about a small set 183 of cooperating Home Agents and exchange registration 184 information regarding Mobile Nodes and periodically test 185 peer co-HA reachability. One may assume that there are 186 only two Home Agents in a set of co-HAs, but there is no 187 inherent limit to the number of peers in a Co-HA set. 189 Primary-HA, Primary - The Home Agent of a co-HA set which 190 is currently receiving registration information directly 191 from a MN. The Primary Home Agent shares this information 192 with its co-HAs (Secondaries) by forwarding registration 193 packets to the peers. A HA is primary because the IP 194 routing infrastructure is currently routing the Mobile-IP 195 registration packet to it. 197 Secondary-HA, Secondary - A Home Agent of a HARP set which 198 is receiving registration information about a given MN 199 indirectly through its co-Home Agent which is acting as 200 the Primary. 202 HARP - Home Agent Redundancy Protocol. 204 HARP PORT - The HARP port number which is the same for both 205 the TCP and UDP ports. This port has not yet been allocated 206 yet. 208 Home Network - Home Subnet - The subnet containing both 209 Home Agents and the home addresses of the Mobile Nodes they 210 are serving. This subnet may be partitioned in terms of the 211 co-HAs or the co-HAs may be physically present on the same 212 link. 214 Partitioned Subnet - A physically divided Home Subnet. 215 Home Agents in a co-HA pair may be thought of as existing 216 on a virtual subnet. Physically divided means that the 217 co-HAs cannot use that link to communicate directly. 218 Note that this is not a requirement of HARP, but an 219 aspect of network design. We will discuss the network 220 design aspects of HARP below. 222 AWAY(Mobile-IP state) - The state of a Mobile Node, with 223 respect to its Home Agent(s), in which datagrams addressed 224 to the MN arrive at its Home-Subnet and are tunneled to 225 the MN's Care Of Address by one of the Mobile Node's 226 Home Agents. 228 AT HOME (Mobile-IP state) - The state of a Mobile Node with 229 respect to a Home Agent in which the MN's current point 230 of attachment in the Internet is consistent with its IP 231 address. In this state, the Mobile Node will receive 232 packets directly. 234 At CoHA(Mobile-IP state) - The state of of Mobile Node, 235 with respect to a Home Agent, in which the MN's home 236 subnet is partitioned and a packet arrives for the MN 237 at another link of the partitioned network. In this 238 case, packets addressed to the home subnet may arrive 239 on a portion of the home subnet to which the Mobile Node 240 has no link layer attachment. These packets must then 241 be forwarded (tunneled) by one HARP peer to another. 243 2. Protocol Overview 245 This section provides a protocol overview of HARP. We discuss 246 HARP from a routing topological point of view, and provide a 247 short discussion of redundancy issues. 249 2.1 Assumptions 251 The following are fundamental assumptions about the design of 252 a HARP redundant agent network: 254 1. So that Mobile-IP and Mobile Nodes need not know about the 255 HARP sub-system, we assume that the HARP peers share a single 256 IP subnet and a single IP network address. 258 2. Due to assumption 1, and because the HARP agents must 259 communicate amongst themselves, we assume they are multi-homed 260 in the sense that there exist on one node at least two IP 261 addresses. We will call them the "Mobile-IP subnet" address, 262 and the "HARP peer" address. The former is shared. The latter 263 is not shared. The HARP peer address is unique and is used by 264 HARP systems to communicate amongst themselves. Note that this 265 does not rule out an agent with only one physical interface. 267 3. We assume that the HARP peers exist within an interior 268 routing domain that runs a IP interior routing protocol such as 269 RIPv2 [RFC-1721], or OSPF [RFC-2178]. Thus packets addressed to the 270 Mobile-IP subnet, including Mobile-IP authentication packets, are 271 routed to the HARP peers according to the local metrics of the 272 interior routing protocols. At any given time, any packet bound for 273 a Mobile Host at HOME, will go to exactly one HARP peer. Ideally, 274 if an interior link fails, an interior routing protocol will 275 switch Mobile-IP packets to the other HARP system. This does 276 not rule out the possibility of HARP being used with static 277 routes in interior routers. External routes to the Mobile-IP 278 subnet may always be changed by hand in the event of HARP agent 279 failure. 281 Finally, it is NOT assumed that the HARP Mobile-IP subnet is 282 partitioned. Partitioning may add useful redundancy attributes. 283 But the subnet need not be partitioned. How this is handled 284 is implementation and site specific and will be discussed more 285 in the next section. 287 2.2 Protocol Overview 289 Diagram 1: 291 MN or CH 293 | 294 | MN/CH path 295 | 297 Internet 299 | 300 | 301 | 302 ------------------------ 303 R1 interior path R2 304 | | 305 H1 H2 306 | | 307 ----- Mobile-IP subnet ------ 309 Please refer to diagram 1 for the following discussion. 311 Assume we have a Mobile Node that is away from home. Assume 312 that at home we have two routers R1, and R2, which are using a 313 local interior routing protocol (for example, OSPF, or static 314 routes). Behind them are two HARP peers which advertise a 315 Mobile-IP subnet to the routers and to the network. Along with 316 the Mobile Node on the exterior Internet, there exists a 317 Correspondent Host (CH). The latter is any host interested 318 in sending packets to the Mobile Node. 320 The Mobile Node is unaware of Home Agent redundancy and sends 321 registration information only once to the shared HA address 322 located on the Home Subnet. Due to the nature of unicast routing, 323 this information may be received by either Home Agent, but is 324 likely to be received by only one. Packets sent from the CH to 325 the Mobile Node will likewise be routed to one or the other Home 326 Agent (whichever is "closer", according to the metrics of the 327 interior routing system). Note that any of these datagrams 328 (Mobile-IP authentication or ordinary datagrams) may at any time 329 go to either Home Agent. 331 When a Mobile-IP registration packet is received by a co-HA, it 332 will encapsulate that registration packet and forward it to 333 another co-HA via the HARP UDP port. Thus the peer co-HA will 334 know that the other HA directly received the registration, and 335 will also know the current MN Care Of Address; i.e., the 336 forwarding address for CH packets. 338 Each HARP peer takes the same internal action whether it receives 339 a Mobile-IP registration packet directly from a MN or whether 340 it receives it from a HARP peer. For example, in parallel, the 341 Mobile-IP vlist entry is created or refreshed, and tunnels are 342 setup (if needed) from the Home Agent to the Care Of Address. 343 In Mobile-IP terms, the Home Agents act in parallel. 345 Mobile-IP authentication (MN to HA, FA to HA, etc.) is performed 346 once at the primary co-HA system. The secondary is expected to 347 perform a separate HARP protocol authentication (HA to HA) on 348 packets forwarded to it by the primary via the HARP UDP (or TCP in the 349 case of table exchanges) ports. 351 If one Home Agent should fail, the interior routing structure 352 should notice that it has failed as a router, and normal routing 353 convergence will remove that path to the Mobile-IP subnet. 354 Convergence may take manual route manipulation in some cases 355 where static routes are used. As a result, the Mobile-IP system 356 should be able to survive the loss of a Home Agent as packets 357 will be routed to a surviving Home Agent. 359 HARP consists of three major packets type sent from one HARP 360 peer to other HARP peers. (Note that some of the types have 361 acknowledgements). We have already mentioned the HARP UDP FORWARD, 362 which is a simple repackaging of the Mobile-IP registration 363 packet itself. In addition there are two other kinds of messages 364 used in the HARP system. There is a HARP PING and a HARP boottime 365 table exchange. The former uses UDP and the later uses TCP. 367 The UDP HARP PING is used to determine if other HARP peers are 368 up. If a PING fails (say 3 out of 5), a HARP agent knows that 369 either its peer has failed or the path to it has been partitioned. 370 It may then take implementation-specific actions which should 371 include ways to attempt to notify local administrators that 372 critical interior links or systems have failed. Other implementation 373 actions may be taken as well if needed. For example, a dormant 374 local link interface might be enabled. 376 HARP provides an optional boot protocol which uses TCP to 377 exchange all HARP information in one connection. Thus if one 378 HARP system reboots after failure, it can acquire Mobile-IP 379 state information from another HARP peer. At boot, a HARP Home 380 Agent will attempt to establish a TCP connections with its co-HAs at 381 their respective TCP HARP PORTs. If successful, these connections 382 are used to pass all current Mobile Node registration information from 383 a running HA to a booting co-HA. When all relevant information 384 has been passed, and the booting Home Agent is synchronized with 385 respect to MN Registrations, the TCP connections are closed. If 386 the peer system is not available, the sending system will 387 timeout and proceed as the peer may be unavailable or rebooting. 389 2.3 Redundancy Considerations 391 There are a number of redundancy considerations regarding HARP 392 that have driven its design which we will present in this 393 section. 395 The failure of one HARP agent, or a network interface on that 396 agent, or possibly a path to that agent should not necessarily 397 cause the Mobile-IP network to fail. This is, of course, the 398 goal of the protocol itself. In addition to simple node 399 redundancy, redundancy may be possible if a path from the 400 MN (CH) in question exists to another HARP agent even when an 401 interior (or exterior) router (or associated interface) fails. 402 Thus HARP may sometimes be able to take advantage of dynamic 403 interior routing. 405 On the other hand, the interior path between the HARP agents 406 should not be allowed to fail. If it does, it is possible that 407 the Mobile-IP registration packets might go one way and datagram 408 packets from a given CH might go another, thus leading to a 409 (bizarre) partition. This is one of the reasons for the HARP 410 PING protocol. Lack of connectivity between the agents should 411 lead to a local management alert. Of course, fundamentally, an 412 interior path failure might cut the Mobile Node off from important 413 local services and should be taken seriously in any case. 415 As part of the overview, we should justify why we have chosen 416 UDP for internal HARP forwarding as opposed to say TCP connections 417 between HARP agents. We felt that the HARP protocol should 418 internally match the design of Mobile-IP. Registration for 419 Mobile Nodes while away from home is driven by Mobile-IP/UDP 420 based packets. Since the Mobile Node drives the registration, 421 we felt that forwarding these packets internally over presumably 422 shorter channels (with higher bandwidth) was reasonable. As a 423 result, Mobile-IP registration also drives the HARP sub-system. 424 We also felt that given the goal of producing a reliable server 425 with reliable software it made more sense to use a simple protocol 426 without the enhanced complexity of a TCP state machine to deal 427 with possible protocol errors. Thus agent-side implementation 428 should be simpler. As a final point, even though the number of 429 HARP peers in a HARP set is likely to be very small, at some 430 future time, one might consider experimentally replacing the 431 unicast UDP HARP (re)registration with reliable multicast 432 registration. Of course, TCP lacks multicast capability. 434 Redundancy considerations for the Mobile-IP home link itself 435 are discussed in the next section. 437 3. Mobile-IP Home Link Considerations 439 One might claim that the impact of HARP on the actual Mobile-IP 440 home subnet link could be regarded as implementation dependent. 441 This is because Mobile-IP itself is aimed not so much at dealing 442 with how mobile nodes interact at the home subnet, but how they 443 can take a home subnet IP address, move to other subnets, and 444 retain connectivity. Thus HARP primarily seeks to address the 445 problem of what might happen if the home forwarding agent is 446 lost. Still, the issue of redundancy on the Mobile-IP home link 447 exists and there is a small amount of protocol impact on HARP. 448 In a very simple sense, having two possible "home" links can 449 aid redundancy as well. If one home fails, a second home might 450 be available. In this section, we will discuss this issue and 451 make implementation suggestions. 453 In the end local network management must decide what they want, 454 according to available local resources and local tradeoffs. 455 Therefore we suggest that implementations remain flexible 456 where home subnet design is concerned. 458 The Home Mobile-IP subnet may be either: 460 1. not partitioned; i.e., the HARP Home Agents could reside 461 on the same link and would be able to reach each other on that 462 link. 464 2. partitioned; i.e., the HARP Agents might reside on 465 different links, and would NOT be able to reach each other on 466 that link. 468 3.1 Non-Partitioned Home Subnet 470 If the link is not-partitioned, the HARP Home Agents can reach 471 each other directly. It is not advisable to have both HARP IP 472 interfaces (which by definition share the same IP interface) 473 active as confusion with nodes on the shared subnet might result. 474 If the systems act as routers only (and not as end systems), one might 475 claim that it would not matter, but there is no point in having both 476 systems race to answer ARP [RFC-826] requests. Worse, any node that 477 attempted to directly connect to the shared HARP subnet IP address with 478 a transport protocol may experience failure due to ARP cache 479 overwrites. 481 Thus it is reasonable to assume an implementation might provide 482 a way to shut down one HARP interior IP interface and dynamically 483 bring another up if failure of the other HARP node is detected. 484 This can be done by the normal method of designated router 485 election. A set of HARP peers exchanging HARP PING messages 486 may choose the HARP peer with the highest IP address to be the 487 only active peer on the interface. We assume that the PINGS 488 are done over the non-Mobile-IP (and non-shared) IP address. 489 If PINGS fail from that interface, (say after N failures, 490 where N is configured in), the remaining HARP peers would again 491 elect a designated router which will take over the "live" ARP 492 function. 494 3.2 Partitioned Home Subnet 496 If HARP peers exist on the same link, it is possible that the 497 failure of an interior router or router interface could lead to 498 the loss of all HARP agents. Thus one may have replaced the 499 Mobile-IP single point of failure mode with a more elaborate 500 single failure mode. We suggest that if practicable (and this 501 ultimately depends on per site network resources), it may be 502 better to partition the home mobile link. In other words, the 503 internal path to the HARP agents would still be an interior 504 routing path, but the agents themselves might best be in widely 505 dispersed locations. For example, HARP peers would be placed 506 behind different interior routers, possibly in different buildings. 508 Such a partitioned network is not ideal for non-Mobile nodes, 509 as IP subnet reachability problems would result if non-Mobile 510 nodes were placed on the Mobile subnet. As a result, one might 511 choose to only place Mobile-IP nodes on such partitioned links. 513 Where a partitioned scheme is used, it is necessary for the Home 514 Agents to install tunnels between themselves. This mechanism is 515 directly analogous to the Mobile-IP tunnel from the Home Agent to 516 the Foreign Agent. A packet sent to a co-HA where the MN is not 517 resident, would be forwarded to the other co-HA. Note that HA 518 tunneling is not strictly necessary when the Mobile subnet is 519 not partitioned, unless the Home Agents are only speaking one 520 at a time to the home link. 522 A simple and less elegant solution would be to disable 523 Mobile-IP router advertisements for Home Agents where actual 524 physical residence is not desired. A dynamic scheme for election 525 here could be used, or this function could be done manually. 526 For example, one might choose to have only one Mobile-IP 527 home subnet from the interior point of view. The other home 528 might reside on a virtual interface that is not directly accessible 529 except in the exterior routing sense. Mobile Nodes in such a 530 system might never be able to directly visit the second home. 532 In summary, where interior router resources exist, partitioning 533 may provide greater surviveablity. 535 4.1 Message Types and Functions 537 The Home Agent Redundancy Protocol has five messages: 539 HARP_FORWARD - This message consists of an encapsulated 540 Mobile Node registration message which is tunneled from 541 the receiving Home Agent to its co-HA. This 542 information is used to update the co-HA's registration 543 tables. This message type uses UDP and is sent to 544 the HARP UDP PORT. 546 HARP_PING - This message is sent at configurable intervals 547 from one co-HA to another to confirm connectivity. 548 If the Home Agent receives no response from its 549 co-HA peer, the co-HA is assumed to be unreachable. 550 This message type uses UDP and is sent to the HARP 551 UDP PORT. 553 HARP_ACK - Sent in response to a HARP_PING to acknowledge 554 that the PING message has been received. This 555 message type uses UDP and is sent to the HARP UDP 556 PORT. 558 HARP_REG_REQ - A message requesting all Mobile Node 559 registration information. This is the first message 560 sent upon establishment of an inter-co-HA TCP 561 connection. This message type utilizes TCP. 563 HARP_REG_DUMP - TCP message which contains Mobile Node 564 registration information maintained by a Home Agent. 565 This message is sent in response to a HARP_REG_REQ. 566 Note that more than one DUMP message may be sent, 567 but each DUMP message may contain more 568 than one Mobile-IP node registration. 570 4.2. Message Formats 572 All HARP messages are structured in a Tag, Length, Value format. 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 575 | Type | Length | Value ... 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 578 Type and Length occupy one unsigned short and are 16-bit values. 579 They are assumed to be in network byte order. Messages are sent 580 to either the HARP UDP or TCP PORT. 582 4.2.1. HARP Registration Forward (HARP_FORWARD) 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | type=HARP_FORWARD | size | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Mobile-IP registration packet ... | 590 | | 592 type: HARP_FORWARD = 1 593 size: in bytes of the value field. 594 value: Mobile-IP registration packet. 596 HARP Registration Forward messages are used to encapsulate and 597 forward registration updates received from a Mobile Node. They 598 are sent between co-HAs. The message consists of two bytes of 599 type followed by two bytes indicating the length in bytes of a 600 Mobile-IP registration packet. The Data field is a Mobile-IP 601 registration packet of the size indicated by the size field. 602 The registration packet has the same format as used with Mobile-IP. 603 Optional (TLV) elements may be present and should be processed. 604 However it is expected that the receiving Home Agent deals with 605 all MN/HA and MN/FA authentication and may remove those elements 606 from the registration packet. 608 4.2.2 HARP Ping (HARP_PING) 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | type=HARP_PING | size=4 | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | HARP peer IP address | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 type: HARP_PING = 2 619 size: 4 620 value: (reachable) IP address of HARP sender 622 HARP_PING messages are sent between all the members of a HARP 623 co-HA set. They are sent with a configured periodicity and are sent 624 within a configured mechanism for determining the loss of an interior 625 routing path. For example, one might send one message a minute, and 626 retry N times. If the sending agent determines that another 627 agent is down, it may initiate implementation-dependent mechanisms 628 including SNMP alerts, paging a network administrator, and/or 629 taking up or down a local interface. We include the HARP peer 630 IP address in order to limit possible problems caused by 631 multi-homing. 633 4.2.3. HARP Ping Acknowledge (HARP_ACK) 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | type=HARP_ACK | size=4 | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | HARP peer IP address | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 type: HARP_ACK = 3 644 size: 4 645 value: HARP peer IP address 647 A HARP Ping Acknowledge message is sent in response to a HARP 648 Ping. The peer IP address belongs to the sender of the 649 acknowledgement. 651 4.2.4 HARP Dump Request (HARP_DUMP_REQ) 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | type=HARP_DUMP_REQ | size=0 | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 type: HARP_DUMP_REQ = 4 660 size: 0 662 The HARP Dump Request message consists of two bytes of type 663 followed by two bytes giving the size of the data field, which 664 is always zero. 666 A HARP_DUMP_REQ is passed from a Home Agent in Initializing State 667 to its co-HA through the inter-co-HA TCP connection. If the receiving 668 co-HA does not receive this message, it should shut down the connection 669 and log an error. If the client's connection fails or no DUMP appears 670 within a configured timeout interval, the client should disconnect and 671 log an error. 673 4.2.5 HARP Registration Dump (HARP_REG_DUMP) 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | type=HARP_REG_DUMP | size=8 | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Number of Registrations | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Size of Registrations | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Mobile-IP registration field ... | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Mobile-IP registration field ... | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | etc. | | 689 type: HARP_REG_DUMP = 5 690 size: 8 691 value: 692 Number of Registrations: a 32-bit unsigned integer in network 693 byte order 694 Size of Registrations: a 32-bit unsigned integer in 695 network byte order. This field contains the size of all 696 the Mobile-IP registration sections which must all have 697 the same size. 698 Some number of Mobile-IP registration requests. 700 A HARP Registration Dump message is sent in response to a TCP 701 connect and HARP Dump Request. It contains current registration 702 information for all Mobile Nodes serviced by a given Home Agent. "The 703 number of registrations" field tells the receiver how many registration 704 messages are being sent. The size of the registration message gives 705 the size of each Mobile-IP registration message which as before, is 706 assumed to be the same format as is used with Mobile-IP. Note 707 we assume that all message sub-fields are of the same length. 708 Also note that a Home Agent need not write all of the information 709 with the same TCP write. Nor does the responding peer need to 710 send all Mobile-IP registration messages in one DUMP message. 711 Multiple DUMP messages may be sent over the same connection. 713 The channel must be closed by the receiver when it has written 714 all of the messages. 716 5. Security Considerations 718 In this section, we briefly consider the security of the HARP 719 protocol itself. Security might also be taken to mean 720 "survivability" and we will discuss that notion first, and then 721 return to HARP protocol network security. 723 In terms of survivability, HARP primarily addresses the problem 724 that a Mobile-IP system, serving a given number of Mobile Nodes 725 may fail due to the loss of a single Home Agent. Home Agent 726 redundancy reduces the odds of a total Mobile-IP system 727 outage due to failure of a Home Agent node, a network 728 adapter on that node, or possibly an internal routing path to 729 that node. Given that we may have multiple Home Agents that 730 cooperate to emulate a single home agent there may also be 731 additional security benefits. For example, a denial of service 732 attack against one Home Agent may not apply to the other (perhaps 733 if they are not on the same link). Hence the Mobile-IP network 734 might continue to function. 736 For protocol security of HARP itself, we require the use of IP 737 layer security [RFC 1825] between any given HARP pair in a set 738 of HARP peers. The HARP pair may use a TCP connection 739 between them at boot for route synchronization, and will use 740 UDP to forward Mobile-IP registration packets. It is required 741 that all of these end to end TCP and UDP channels be protected 742 by at least IPSEC authentication [RFC 1826], and optionally by 743 authentication and encryption [RFC 1827]. Authentication is a 744 requirement. Thus security will be end to end for the HARP 745 protocol between HARP peers. 747 References 749 [RFC-826] Plummer, D., "An Ethernet Address Resolution Protocol: 750 Or Converting Network Protocol Addresses to 48.bit Ethernet 751 Addresses for Transmission on Ethernet Hardware", STD 37, 752 November 1982. 754 [RFC-1721] Malkin, G., "RIP Version 2 Protocol Analysis", 755 November 1994. 757 [RFC-1825] Atkinson, R., "Security Architecture for the Internet 758 Protocol", Naval Research Laboratory, July 1995. 760 [RFC-1826] Atkinson, R., "IP Authentication Header", August 1995. 762 [RFC-1827] Atkinson, R., "IP Encapsulated Security Payload", 763 August 1995. 765 [RFC-2002] Perkins, C., "IP Mobility Support", October 1996. 767 [RFC-2003] Perkins, C., "IP Encapsulation within IP", 768 October 1996. 770 [RFC-2178] Moy, J., "OSPF Version 2", July 1997. 772 ^L 774 Contacts 776 Bjorn Chambless 777 Computer Science Department 778 Portland State University 779 Email: bjorn@cs.px.edu 781 Jim Binkley 782 Computer Science and Engineering Department 783 Oregon Graduate Institute 784 Email: jrb@cse.ogi.edu