idnits 2.17.1 draft-oneill-mip-decomposedha-00.txt: -(207): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 805. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 795), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 596: '...d for future use. MUST be set to 0 on...' RFC 2119 keyword, line 597: '... sending and MUST be ignored on re...' RFC 2119 keyword, line 626: '...d for future use. MUST be set to 0 on...' RFC 2119 keyword, line 627: '... sending and MUST be ignored on re...' RFC 2119 keyword, line 637: '... which case a dynamic HoA MUST also be...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 406 has weird spacing: '...sonably low c...' -- 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 (July 2004) is 7218 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) -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '1') (Obsoleted by RFC 5944) == Outdated reference: A later version (-03) exists of draft-ietf-mip4-vpn-problem-statement-00 Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Alan O'Neill 3 INTERNET-DRAFT Flarion Technologies 4 Category: Standards Track 5 July 2004 7 Decomposed Home Agent Architecture 8 draft-oneill-mip-decomposedha-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet Draft expires January 6, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 RFC 3344 [1] describes the current version of Mobile IP version 4 42 signaling and forwarding. The signaling and forwarding is conducted 43 between a Mobile Node and a Home Agent, via an optional intermediate 44 Foreign Agent, for a Home Address of the Mobile Node. The Home Agent 45 acts as the Mobile IP signaling endpoint, as well as the forwarding 46 endpoint for packet tunneling between the Home Agent and the MN Care 47 of Address. This document describes an alternative architecture in 48 which the Home Agent is the signaling endpoint whilst a new Tunnel 49 Agent acts as the forwarding endpoint. 51 Decomposed Home Agent Architecture July, 2004 53 Table of Contents 55 Status of this Memo.................................................1 56 Abstract............................................................1 57 Table of Contents...................................................2 58 1. Problem Statement................................................2 59 2. Terminology......................................................3 60 3. Requirements and Scope...........................................4 61 4. The Decomposed Home Agent Architecture...........................4 62 4.1 Common Channel Tunnel Agent Control Protocol....................6 63 4.2 Channel Associated Tunnel Agent Control Protocol................6 64 4.3 Overview Comparison between TACP-CC and TACP-CA Models..........7 65 4.4 Potential Benefits of the DHA...................................8 66 4.5 DHA Redundancy Enhancements.....................................8 67 4.6 TA Redundancy Enhancements......................................9 68 4.7 Additional Deployment Considerations...........................11 69 5. MIP extensions for the Decomposed HA............................11 70 5.1 Tunnel Agent Address Request...................................11 71 5.2 Tunnel Agent Address Grant.....................................12 72 5.3 TAAR Protocol Rules............................................13 73 5.4 TAAG Protocol Rules............................................13 74 6. IANA Considerations.............................................13 75 6.1 Mobile IP Extension Type and Subtypes..........................13 76 6.2 Mobile IP Error codes..........................................14 77 7. Security Considerations.........................................14 78 8. Backward Compatibility Considerations...........................14 79 8.1 Legacy Home Agent..............................................14 80 8.2 Legacy Foreign Agent...........................................15 81 8.3 Legacy Mobile Node.............................................15 82 9. Notice Regarding Intellectual Property Rights...................15 83 References.........................................................15 84 Authors� Addresses.................................................16 85 Copyright Statement................................................16 86 Disclaimer of Validity.............................................16 87 Acknowledgement....................................................16 89 1. Problem Statement 91 RFC 3344 describes the current version of Mobile IP version 4 92 signaling and forwarding. The signaling and forwarding is conducted 93 between a Mobile Node and a Home Agent, via an optional intermediate 94 Foreign Agent, for a Home Address of the Mobile Node. The Home Agent 95 acts as the Mobile IP signaling endpoint, as well as the forwarding 96 endpoint for packet tunneling between the Home Agent and the MN Care 97 of Address. The general Internet Routing System considers that this 98 Home Address (and hence the associated MN interface) is located at 99 the Home Agent, whilst Mobile IP signaling and forwarding enables 100 that home address to instead be located at a remote Access Router, 101 which may optionally contain a Foreign Agent. 103 Decomposed Home Agent Architecture July, 2004 105 This dual-mode Home Agent exhibits a number of characteristics; 107 i) The Home Agent node implementation has to be optimized for both MIP 108 signaling and forwarding operations. 109 ii) The Home Agent location needs to be optimized both from a MIP 110 signaling and forwarding perspective. 111 iii) Failure of the Home Agent typically renders both MIP signaling and 112 forwarding inoperable for each of the mobility bindings at that 113 Home Agent. 114 iv) The Home Agent optionally needs to support additional interfaces to 115 AAA, Security, Address Management and other policy servers to 116 provide a complete set of mobility features whilst scaling to 117 support a very large number of MNs. 119 The design and operational conflicts and compromises that arise when 120 a single node attempts to undertake multiple large-scale, high 121 availability tasks have been seen before in telecommunication and 122 Internet systems (CAS v CCS, MGCP v SIP etc) and the IETF presently 123 has a working group looking at a general protocol framework (FORCES) 124 for decomposing network nodes into distinct control and forwarding 125 elements that are synchronized by a control protocol. In addition, 2G 126 and 3G cellular systems separate forwarding (MSC/GGSN) from control 127 (HLR/VLR) as much as possible although the analogy is somewhat 128 stretched here especially in the Packet Domain. 130 This document therefore describes an alternative MIP architecture in 131 which the Home Agent is decomposed and remains the MIP signaling 132 endpoint, whilst a new Tunnel Agent acts as the MIP forwarding 133 endpoint. This enables the Decomposed Home Agent to be optimized and 134 located for MIP signaling purposes whilst the new Tunnel Agent can be 135 independently optimized and located for forwarding purposes. The 136 document first describes the minimal MIP extensions required to 137 facilitate this decomposition, and then investigates a couple of 138 implementation scenarios and the potential associated operational 139 advantages of the architecture. The decomposition is equally 140 applicable to MIPv6 but that is outside the scope of this document. 142 2. Terminology 144 MN Mobile Node as defined in RFC 3344 145 HoA MN�s Home Address 146 HA Home Agent as defined in RFC 3344 147 FA Foreign Agent as defined in RFC 3344 148 CoA MN�s Care of Address 149 FACoA Shared CoA from the Foreign Agent 150 CCoA Colocated Care of Address 151 CN Correspondent Node as defined in RFC 3344 152 CNA IP address of the Correspondent Node 153 DHA Decomposed Home Agent as outlined in this document 154 TEN Tunnel Endpoint Node (the MN or FA) 155 TA Tunnel Agent as outlined in this document 157 Decomposed Home Agent Architecture July, 2004 159 TAA IP address of the Tunnel Agent 160 TACP-CC Common Channel Tunnel Agent Control Protocol 161 TACP-CA Channel Associated Tunnel Agent Control Protocol 162 XX-CC A MIP agent that complies with the CC decomposition 163 XX-CA A MIP Agent that complies with the CA decomposition 164 RRQ Mobile IP Registration Request as defined in RFC 3344 165 RRP Mobile IP Registration Reply as defined in RFC 3344 166 RRQ(TAAR) A RRQ containing the TAAR extension. 167 RRP(TAAG) A RRP containing the TAAG extension. 169 3. Requirements and Scope 171 Following are the requirements that the proposed decomposed Home 172 Agent architecture tries to satisfy. 174 - Physical separation of the MIP signaling and forwarding 175 endpoints in the core network. 177 - The carriage of a claimed Tunnel Agent address in MIP signaling to 178 the DHA. 180 - The carriage of an assigned Tunnel Agent address in MIP signaling 181 to the TEN. 183 - Support for multiple DHAs and TAs per MN for high availability 184 deployments. 186 - Support for common channel and channel associated Tunnel Agent 187 Control protocols (TACP) between the DHA and the TA for managing 188 tunnel bindings. 190 The following architecture components and analysis are not undertaken 191 in this document. 193 - Definition of the detailed requirements or mechanisms for either 194 version of TACP. 196 - Definition of the requirements or mechanisms for, the dynamic 197 assignment of a Tunnel Agent address and HoA address at the DHA. 199 - Detailed theoretical, financial or operational comparisons between 200 the existing products and deployments based on RFC3344 201 architecture and the Decomposed Home Agent architecture. 203 4. The Decomposed Home Agent (DHA) Architecture 205 The DHA has optional interfaces into external policy elements such as 206 address management, security and AAA servers much as the RFC3344 HA. 207 The Decomposed Home Agent acts as a �MIP Controller� for one or more 208 Tunnel Agents under its control, on behalf of MNs. The DHA receives 210 Decomposed Home Agent Architecture July, 2004 212 RRQ signals from the MN and returns RRP signals to that MN via any 213 intermediate FAs. The DHA is aware of the mapping between Tunnel 214 Agents and HoA prefixes, and may also be aware of preferred Tunnel 215 Agents per MN, and/or for a specific aggregate of ARs. The DHA is 216 able to provide a dynamic Tunnel Agent grant as well as dynamic Home 217 Address assignment, but can alternatively verify a requested Tunnel 218 Agent and/or HoA for a MN. The DHA also has means, compliant with 219 RFC3344, to authenticate MIP signaling with the MN and with an 220 optional FA on the signaling path. 222 The Tunnel Agent is a new MIP element that supports MIP tunneling 223 operations to/from the Tunnel Endpoint Node (TEN = MN or FA) at which 224 the MN CoA is located (MN CCoA or FA CoA). Each TA undertakes 225 tunneling operations for one or more MNs, and for one or more HoAs 226 per MN. The general Internet Routing System considers that each MN 227 HoA (and hence the associated MN interface) is located at the Tunnel 228 Agent (and not the DHA, unlike the RFC3344 HA). MIP forwarding 229 then enables that HoA to instead be dynamically located at a remote 230 Access Router (AR), which may optionally contain a Foreign Agent. 231 This specifically means that data packets between the CN and the MN 232 do not visit the DHA as shown in figure 1. 234 CN DHA TA FA MN 236 Forward CNA------------------------TAA=====>FACoA--------->HoA 238 RevTun CNA<-----------------------TAA<=====FACoA----------HoA 240 Figure 1. TA based MIP Data forwarding 242 The requested and/or granted Tunnel Agent address is carried in RRQ 243 and RRP MIP messages, between the MN and the DHA, using new MIP 244 extensions that are defined in section 5. The Tunnel Agent maintains 245 tunnel bindings much like the forwarding part of the RFC3344 HA, and 246 can support forward and reverse tunneling for IPinIP, GRE and IPSEC 247 tunnels much like a traditional RFC3344 HA. Note that general purpose 248 routers generally have support for low density tunneling operations 249 such that TAs can potentially be located throughout a routed domain 250 in a highly distributed and locally optimized way (from a forwarding 251 perspective). Two alternative signaling models, for managing the 252 tunnel agent bindings from the DHA, are overviewed in this document, 253 within sections 4.1 and 4.2. Both models support multiple redundant 254 TAs per MN HoA, or even alternative HoAs at redundant TAs. It is the 255 support for a Tunnel Agent Control Protocol that primarily enables 256 general purposes routers to become potential Tunnel Agents. The 257 Decomposed HA Architecture also fully supports specialized highly 258 centralized Tunnel Agent hardware/software (as does the forwarding 259 part of an RFC3344 HA) and is ambivalent on the optimal configuration 260 which is likely to be more closely tied to specific deployment 261 scenarios. Mixed deployments of centralized and distributed TAs under 262 a single DHA are intended to be supported. 264 Decomposed Home Agent Architecture July, 2004 266 4.1 Common Channel Tunnel Agent Control Protocol (TACP-CC) 268 The Decomposition of the HA follows the FORCES framework in which a 269 distinct control protocol is used between the DHA and the TA to 270 manage tunnel bindings. The FORCES protocol is a candidate TACP-CC 271 but the requirements for, and design of, the TACP-CC is outside the 272 scope of this document. This architecture is shown in figure 2 for 273 the case of the TEN being the FA. An optional Tunnel Agent Address 274 Request (TAAR) extension is added by the MN or the TEN into the RRQ, 275 and verified by the DHA. The MN adds the TAAR to inform the DHA of an 276 existing or preferred TA address, along with any associated allocated 277 HoA at that TA. The FA adds the TAAR on behalf of the MN for the 278 reasons above or to inform the DHA of a preferred TA in local AR 279 state that was optionally returned from the AAA infrastructure. The 280 TAAR can include an ALL-ZEROs TAA which indicates support for Tunnel 281 Agents without indicating a preferred TA. 283 The Tunnel Agent Address Grant (TAAG) extension is added by the DHA 284 into the RRP and consumed by the TEN. It is optionally sent to the MN 285 if the MN originated the TAAR in the RRQ. The DHA uses the TACP-CC 286 protocol with the granted TA to install the required tunnel binding 287 into the TA, for the tunnel between the TA and the FA CoA. This state 288 is commensurate with the parameters in the associated MIP signals. The 289 TACP-CC might employ peer to peer or client-server signaling models 290 and the tunnel bindings designed as soft or hard state. Figure 2 291 implies that the RRP is not sent by the DHA until the TACP-CC REP is 292 received back from the TA. However, the precise requirements in that 293 regard, given the soft-state best effort nature of MIP signaling, are 294 outside the scope of this overview document. 296 CN DHA TA FA MN 298 RRQ <************************<************** 299 TACP-CC ############> 300 TACP-CC <############ 302 RRP *************************>*************> 304 Figure 2. TACP-CC and MIP signaling model 306 4.2 Channel Associated Tunnel Agent Control Protocol (TACP-CA) 308 The Decomposition of the HA is such that the TA is located between 309 the AR and the DHA and is on the MIP signaling path. The TA tunnel 310 bindings are then installed using MIP RRQ/RRP extension signals that 311 traverse the TA as shown in figure 3. TACP-CA is therefore fully 312 integrated within MIP signaling. This model avoids the need for the 313 development of a new protocol between the DHA/TA but instead places 314 MIP signaling load on the TA. The required MIP extensions to support 315 an intermediate MIP agent will be similar to those developed for 317 Decomposed Home Agent Architecture July, 2004 319 regionalized MIP signaling schemes but the detailed requirements for, 320 and design of, these extensions are outside the scope of this 321 document. Figure 3 shows that the FA needs to know the TA address for 322 the routing of the RRQ, and hence must either obtain the TA address 323 from a RRQ(TAAG) received from the MN, or from local state at the FA 324 potentially returned from a AAA access_request. The FA can in the 325 latter cases verify a RRQ(TAAR) received from the MN. 327 CN DHA TA FA MN 329 RRQ(TACP-CA) <#*#*#*#*#*#*<#*#*#*#*#*#<*#*#*#*#*#*#*# 330 RRP(TACP-CA) *#*#*#*#*#*#*>#*#*#*#*#*#>*#*#*#*#*#*#*> 332 Figure 3. MIP based TACP-CA protocol 334 Figure 3 implies that the MN-FA signaling is aware of the DHA / TA 335 architecture but again it should be made clear, that in the case of a 336 FACoA, the presence of the DHA/TA combination can be completely 337 hidden from the MN by the FA, and RFC3344 signaling employed between 338 the FA and the MN. 340 A further variant of the TACP-CA model is that the RRQ does not visit 341 the TA whilst the RRP, following TA address grant at the DHA, does 342 visit the granted TA. This avoids the need for the FA to determine 343 the TA address but is a significant departure from the traditional 344 MIP signaling model and therefore not further discussed here. 346 4.3 Overview Comparison between TACP-CC and TACP-CA Models 348 The TA-CA avoids having to support the MN-HA Security Associations 349 (SA) as well as the interfaces to the policy servers in the 350 operations zone which are instead reached through the DHA. The TA-CA 351 does however need an FA-TA SA which potentially could be shared 352 across a number FAs. The TA-CA can be distributed across the 353 routing domain and located optimally for forwarding purposes. The TA- 354 CA does however still operate on per HoA MIP signaling and hence 355 still has high density high availability design constraints for both 356 the forwarding and signaling planes. The FA-CA needs to support some 357 additional minor MIP extensions as well as an FA-TA SA which 358 potentially could be shared with a number of TAs in the domain. The 359 FA-CA also needs to be able to determine the TAA so that the RRQ can 360 be routed via the selected TA to the DHA. 362 The TA-CC avoids having to support the MN-HA SAs as well as the 363 interfaces to the policy servers in the operations zone which are 364 again reached through the DHA. The TA-CC does not need an FA-TA SA 365 and can also be distributed across the routing domain and located 366 optimally for forwarding purposes. The TA-CC does not operate on per 367 HoA MIP signaling but instead has a TACP-CC signaling session per DHA. 369 Decomposed Home Agent Architecture July, 2004 371 The FA-CC needs to support some additional minor MIP extensions but 372 does not need either an FA-TA SA or a means to determine the 373 preferred TA which is instead undertaken by the DHA. 374 TA-CC and TA-CA have very different implications on signaling 375 resilience, performance and cost, and subsequently on the ideal 376 levels of distribution of the TA function for a given population of 377 MNs and ARs. These are not addressed in this overview document. 379 In the case of FA CoAs, the MN may be fully isolated from whether the 380 core network is employing TACP-CC or TAP-CA decomposition signaling 381 which therefore enables MN to move and employ either system during one 382 or more MIP access sessions. 384 4.4 Potential Benefits of the DHA 386 It is clear from figures 2 and 3 that the DHA is in either case 387 absolved from packet forwarding yet retains its role as the MIP 388 signaling controller and primary interface into policy systems such 389 as the AAA and security infrastructure. The DHA continues to need a 390 MN-HA SA and a FA-HA SA as well as security associations with the 391 external policy systems. The DHA can now be co-located with those 392 policy servers behind an operational firewall as its location is now 393 not affected by forwarding constraints. The DHA can be implemented on 394 a high-availability server platform, using off-the-shelf hardware and 395 OS software, and its mobility and address management information 396 stored in a high availability database where it can be made available 397 to external application servers in support of general operations 398 (fault, fraud, performance etc), location based services, presence 399 servers and paging servers. The DHA function can specifically be 400 fully integrated within the AAA database infrastructure. 402 4.5 DHA Redundancy Enhancements 404 A single logical DHA, fronting a high-availability server and storage 405 cluster, can clearly be used to support a very large number of 406 mobility bindings at reasonably low cost. A pair of geographically 407 dispersed logical DHAs can be used by Mobile Internet Service 408 Providers (MISPs), much as AAA is architected for today�s ISPs. The 409 MNs associated with that domain can be persistently configured with 410 the primary and secondary DHA addresses, because irrespective of the 411 MN location, mobility signaling is always sent to one of those DHAs. 412 However, DHA failures will still of course occur and the DHA (and the 413 RFC3344 HA) can be assumed to be able to recover after some reboot 414 interval and retain some portion of ongoing binding information 415 depending on the type and resolution of the binding state storage. 416 The impact of a single or primary DHA failure, when compared to an 417 single or redundant pair of RFC3344 HAs, is however somewhat different. 419 i) The DHA failure only affects binding changes because the 420 forwarding path is completely independent of the DHA, and 422 Decomposed Home Agent Architecture July, 2004 424 the tunnel state at the TA remains in place for the duration 425 of the DHA failure. 427 ii) During the failure, the MN can continue to receive packets at 428 its historical CoA stored in the TA, and can also move to a new 429 AR if the historical AR is providing forwarding for the 430 historical CoA towards the new CoA as a result of inter-AR MIP 431 signaling. 433 iii) If a MN does not get a RRP back from a DHA then existing MNs 434 will retry and hence will be able to rebuild the mobility state 435 following the reboot interval, but will not be able to alter 436 its historical CoA during that interval. 438 iv) If the DHA misses a binding deregistration during its reboot, 439 and the MN disconnects from the historical CoA, then stale 440 state can exist on the DHA and/or TA until the lifetime of the 441 state at the TA expires. This however is no worse than the 442 scenario of a MN disconnecting at its historical CoA without 443 attempting to explicitly deregister that CoA at the DHA. 445 v) If the primary DHA is deemed unavailable following some number 446 of missed RRPs, or following some timer, the MN can instead 447 contact the secondary DHA and include in that RRQ its existing 448 TA and HoA allocation state, as well as the modifications to 449 its MIP binding state. The secondary DHA can then independently 450 control the MNs HoA tunnel state at that TA and hence 451 continuity of the MNs communications is possible even with a 452 sustained DHA failure. 454 vi) If the current TA of a MN HoA fails then access to the DHA is 455 maintained and so the MN can as a worst case request a new 456 dynamic TA-HoA assignment and resume its communications using 457 the new TA/HoA assignments. 459 Therefore, it is possible that additional significant and cost 460 effective resilience is provided by the decomposition of the HA into 461 a DHA and a TA, and by the ability to employ two concurrent DHAs 462 hosted on high availability server infrastructure. 464 4.6 TA Redundancy Enhancements 466 The DHA architecture offers support for TA redundancy, which enables 467 the IP routing system to reroute around TA failures. The MN may be 468 granted multiple TAs for a specific MIP signaling session that are 469 communicated to the MN TEN in multiple TAAGs. Each TA is located in a 470 single routing domain and each TA injects a prefix which covers the 471 HoA of the MN, in an anycast configuration. The metrics associated 472 with that HoA prefix, at any particular router in the routing domain, 473 produces a preferred TA for packets arriving from a specific CN at 475 Decomposed Home Agent Architecture July, 2004 477 that router, that are destined for that MN HoA. Suitable selection of 478 prefix metrics in the routing domain can result in the TAs load- 479 sharing traffic, with each TA dealing with a sub-set of the CNs that 480 are injecting packets towards that prefix. Alternatively, a primary 481 TA is used for all active CNs until that primary TA fails, In either 482 case, a TA failure results in the metric associated with the prefix 483 from that TA degrading to the extent that the other TA becomes the 484 sole forwarder for downstream packets towards that HoA prefix. The 485 speed of routing convergence for the route to the secondary TA is a 486 function of the type of routing protocols involved, the size of 487 the routing domain, and the topological distance between the primary 488 and secondary TAs. In a noteworthy configuration, somewhat 489 reminiscent of synchronized RFC3344 HAs in a hot-standby pair, the 490 primary and secondary TAs can be on the same subnet and ARP 491 mechanisms (gratuitous, proxy etc) used to move HoA specific traffic 492 between them. It should be pointed out however that the two TAs do 493 not need to support a tunnel binding synchronization protocol between 494 each other because each is independently slaved of the DHA. 496 Upstream reverse tunneled traffic to the TAs may be delivered to 497 either of the redundant TAs although clearly it is beneficial if the 498 upstream traffic is sent to the TA that is the source of the 499 downstream traffic for each CN. When routing causes traffic from a 500 specific CN to be diverted to the alternative TA then this can act as 501 a trigger for the upstream traffic to be reverse tunneled to that 502 alternative TA. 504 The support for multiple TAs in TACP-CC is at a fairly obvious as it 505 simply requires the DHA to manage tunnel binding messages with 506 multiple TAs in parallel. However, TACP-CA requires further 507 description because a single MIP RRQ arriving at the FA needs to be 508 copied and routed to the DHA via both the primary and secondary TAs. 509 The MN and DHA (just as the RFC3344 HA) manage the Identification 510 parameter (for replay protection), so that the parameter space is 511 unaffected by the split. The FA therefore uses the Identification 512 information in the received RRQ, along with local state on the chosen 513 primary and secondary TA addresses, to create RRQs towards each TA 514 containing the same Identification information so that the DHA can 515 match the redundant RRQs and issue associated redundant RRPs back via 516 the primary and secondary TAs to the common FA. The challenge- 517 response protocol (RFC3012) information is similarly unaffected by 518 the redundancy procedure and is again duplicated in the redundant RRQ 519 and RRPs. However, it should be made clear that under various failure 520 conditions, further analysis may indicate a need for additional MIP 521 protocol mechanisms to ensure that message sequencing, matching and 522 replay protection is maintained. 524 Decomposed Home Agent Architecture July, 2004 526 4.7 Additional Deployment Considerations 528 The ability to locate the DHA and the TA in different parts of the 529 network leads to a number of capabilities covering specific 530 deployment scenarios. 532 The use of MIP for corporate remote access [2] leads to the need for 533 firewall traversal of the MIP signaling and tunneling. Placing the HA 534 in the DMZ causes internal traffic to be routed via the DMZ whilst 535 placing the HA inside the corporate network causes external MIP 536 signaling to be allowed into the corporate network. The ability to 537 place the DHA in the DMZ, whilst placing the TAs either inside or 538 outside of the corporate network based on MN location should be of 539 particular benefit to that scenario. 541 Inter-operator MIP roaming typically results in both inter-domain 542 signaling and forward, or results in the assignment of a HA in the 543 visited domain and hence a loss of visibility of mobility signaling 544 in the home domain. The decomposed architecture enables the home 545 domain DHA to continue to marshal the MIP signaling plane whilst 546 using an inter-domain protocol to manage tunnel bindings at a TA in 547 the visited domain and so avoid the need for inter-domain forwarding. 548 Alternatively, a visited domain DHA could be assigned to produce a 549 short MIP signaling path, yet ensure that the MN gets a home domain 550 TA and HoA as part of a wholesale/retail solution. 552 The DHA maintains a view of all binding activity from the signaling 553 plane, and can receive packet forwarding metrics within TACP-CC (or 554 possibly even TACP-CA) from the TA, and therefore is in an excellent 555 position to manage load-sharing across a group of TAs. The DHA model 556 avoids the need for HA Redirection and hence the MN can continue to 557 use a well-known DHA across and within MIP access sessions whilst 558 still preserving the load-sharing capabilities for the operator. 560 An RFC3344 HA could additionally be extended to support 561 decomposition for a set of TAs for load-sharing / off-loading 562 purposes. The HA would act as the forwarder for some main set of HoA 563 prefixes, and when consumed, the HA could off-load the forwarding for 564 additional MNs to external TAs (with their own HoAs). This dual-mode 565 HA/DHA also of course provides support for RFC3344-only MNs and FAs, 566 and is therefore a nice option for incremental deployment. 568 5. MIP extensions for the Decomposed HA Architecture 570 5.1 Tunnel Agent Address Request Extension (TAAR) 572 This extension may be included in the RRQ by a MN to request a 573 specific Tunnel Agent address. If not inserted by the MN, then the 574 optional FA may alternatively request a specific Tunnel Agent address 575 to be assigned. This skippable extension follows the short extension 576 format as defined in [2], where the subtype indicates the specific 578 Decomposed Home Agent Architecture July, 2004 580 address management extension. 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type | Length | Sub-Type | Reserved | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Tunnel Agent Address (TAA) | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 Type Address Management Extension (skippable) [2] 592 Sub-Type 1 594 Length 6 596 Reserved Reserved for future use. MUST be set to 0 on 597 sending and MUST be ignored on reception. 599 TAA 4 byte IPv4 address of the requested Tunnel Agent 601 5.2 Tunnel Agent Address Grant Extension (TAAG) 603 The TAAG extension is included by the DHA in a RRP to inform the TEN 604 of the address of the assigned Tunnel Agent. The RRP(TAAG) may be 605 forwarded by the FA (TEN) to the MN when the MN has requested a 606 specific Tunnel Agent using the TAAR extension. The TAAG is also 607 included by a FA-CA in a RRQ(TAAG) to the assigned TA-CA, as the TA 608 assignment in the TACP-CA model is at the FA. This skippable 609 extension follows the short extension format as defined in [2], where 610 the subtype indicates the specific address management extension. 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Type | Length | Sub-Type | Reserved | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Tunnel Agent Address (TAA) | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Type Address Management Extension (skippable) [2] 622 Sub-Type 2 624 Length 6 626 Reserved Reserved for future use. MUST be set to 0 on 627 sending and MUST be ignored on reception. 629 TAA 4 byte IPv4 address of the granted Tunnel Agent 631 Decomposed Home Agent Architecture July, 2004 633 5.3 TAAR Protocol Rules 635 The MN sends the RRQ(TAAR) to either the HA or the FA to indicate 636 compliance with this document. The TAA may be 0.0.0.0 to request a 637 dynamic TAA assignment in which case a dynamic HoA MUST also be 638 requested. The TAA may be a.b.c.d to indicate a request to use a 639 specific TAA and the associated HoA field MAY be either 0.0.0.0 to 640 indicate a request for dynamic assignment of a HoA, or w.x.y.z to 641 indicate a preferred HoA at that TAA. Clearly, the DHA must ensure 642 that the resulting HoA is routable via the assigned TAA. 644 If the RRQ(TAAR) is received at an FA-CC, then that FA will forward a 645 RRQ(TAAR) to the DHA-CC and the dynamic assignment of the TA and the 646 HoA undertaken. 648 5.4 TAAG Protocol Rules 650 An FA-CA sends a RRQ(TAAG) to the TA-CA, whether or not the MN issued 651 a RRQ(TAAR). 653 The DHA sends the RRP(TAAG) to either the MN or the FA in response to 654 either a RRQ(TAAR) or RRQ(TAAG). The RRP(TAAG) indicates compliance 655 with this document and confirms the address of the assigned TA (along 656 with the associated HoA assignment information) to the TEN. 658 The FA-CA or FA-CC that receives a RRP(TAAG) SHOULD forward a 659 RRP(TAAG) to the MN if that FA received a RRQ(TAAR) from the MN. 660 Otherwise, the FA MAY forward the RRQ(TAAR). 662 6. IANA Considerations 664 6.1 Mobile IP Extension Type and Subtypes 666 This document introduces the following Mobile IP extension type. 668 Name : Tunnel Agent Extensions 669 Type Value : TBD 670 Section : 6 672 This document also introduces two of the following subtypes for the 673 above extension type. 675 Sub-type Name Section 676 -------- ---- ------- 677 1 Tunnel Agent Address Request 6.1 678 2 Tunnel Agent Address Grant 6.2 680 Decomposed Home Agent Architecture July, 2004 682 6.2 Mobile IP Error codes 684 This document introduces no new error codes that can be returned by 685 the FA or HA in a Mobile IP Registration Reply. However, such error 686 codes will no doubt be required as part of the design of TACP-CA and 687 are for further study. 689 7. Security Considerations 691 The DHA in both decomposition schemes can be located in the 692 operations zone behind a firewall and so should be better 693 protected against DOS attacks. 695 The TA-CC does not have a need to exchange signaling with MNs and 696 should therefore be better protected against DOS attacks. 698 The decomposition of the DHA and the TA offers no new vulnerabilities 699 in the MIP signaling plane for TACP-CC, and any vulnerabilities for 700 TACP-CA have been previously discussed and addressed in regional MIP 701 signaling schemes where bindings are also installed in a node that is 702 situated between the HA and the TEN. However, all such 703 vulnerabilities will need to fully documented and protected against 704 in the TACP-CA design. 706 The TACP-CC decomposition clearly introduces a new signaling protocol 707 with associated vulnerabilities that can only be examined as part of 708 that protocol design. However, a clear need will exist to 709 authenticate and integrity protect TACP-CC messages and parameters to 710 avoid DHA-TA communications being corrupted. 712 The above mentioned procedure for Tunnel Agent address agreement, 713 that is common to both decomposition schemes, introduces the TAAR and 714 TAAG extensions which MUST be protected by an authorization-enabling 715 extension [2] between the MN and the HA. Thus, this procedure does 716 not introduce any new security concerns that are not otherwise 717 outlined above. 719 8. Backward Compatibility Considerations 721 These comments assume all MIP nodes compliant with this document are 722 able to revert to RFC3344 behavior. 724 8.1 Legacy Home Agent 726 Upon receiving a RRQ(TAAR) from a MN following the procedure 727 outlined in this document, the legacy HA SHOULD follow the behavior 728 as per RFC 3344, ignoring the TAAR extension which has been defined 729 in the skippable range of extensions. 731 A compliant FA will note that the TAAG is missing and MAY revert to 733 Decomposed Home Agent Architecture July, 2004 735 RFC3344 behavior. A complaint MN that sent a RRQ(TAAR) but did not 736 receive a RRP(TAAG) will be informed that the core network does not 737 support decomposition. 739 8.2 Legacy Foreign Agent 741 For the cases where the RRQ(TAAR) is sent by a complaint MN with TAA 742 field set to 0.0.0.0 or a.b.c.d, the behavior of the legacy FA will 743 be the same as per RFC 3344, and the FA will not forward a RRQ(TAAR) 744 towards the HA. A compliant HA will not receive RRQ(TAAR) and hence 745 will not return a RRQ(TAAG). The HA will resort to RFC3344 behavior. 747 8.3 Legacy Mobile Node 749 A legacy MN that is using a FACoA may be supported by a compliant FA, 750 DHA, and TA combination in the core network whilst employing RFC3344 751 RRQ/RRPs. 753 The RRQ behavior of a legacy MN that uses a CCoA will not be affected, 754 since the new behavior will be applicable only for RRQs which include 755 the TAAR so indicating compliance with this specification. 757 The RRP behavior of a legacy MN that uses a CCoA is also not affected 758 by the receipt of an unsolicited TAAG as it is only sent to a MN that 759 has indicated compliance with this specification. It is also a 760 skippable extension and behavior will progress as per RFC 3344 if 761 incorrectly sent to a non-compliant MN as a result of a bug. 763 9. Notice Regarding Intellectual Property Rights 765 Flarion's submissions will conform with RFC 3668. Flarion may seek 766 patent protection on some or all of the technical information 767 submitted by its employees in connection with the IETF's standards 768 process. If part(s) of a submission by Flarion is (are) included in 769 a standard and Flarion owns patent(s) and/or pending patent 770 application(s) that are essential to implementation of such included 771 part(s) in said standard, Flarion is prepared to grant a license on 772 fair, reasonable, reciprocal (license back) and non-discriminatory 773 terms on such included part(s). 775 Informative References 777 [1] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, August 778 2002. 779 [2] F. Adrangi, Ed., H. Levkowetz, Ed. "Mobile IPv4 Traversal of 780 VPN Gateways�, Internet-Draft, draft-ietf-mip4-vpn-problem- 781 statement-00.txt, October 14, 2003. 783 Decomposed Home Agent Architecture July, 2004 785 Authors� Addresses 787 Alan O'Neill 788 Flarion Technologies 789 a.oneill@flarion.com 791 Copyright Statement 793 Copyright (C) The Internet Society (2004). This document is subject 794 to the rights, licenses and restrictions contained in BCP 78, and 795 except as set forth therein, the authors retain all their rights. 797 Disclaimer of Validity 799 This document and the information contained herein are provided on an 800 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 801 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 802 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 803 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 804 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 805 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 807 Acknowledgment 809 Funding for the RFC Editor function is currently provided by the 810 Internet Society.