Mobile IP Working Group Alan O'Neill INTERNET-DRAFT Flarion Technologies Category: Standards Track July 2004 Decomposed Home Agent Architecture draft-oneill-mip-decomposedha-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires January 6, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract RFC 3344 [1] describes the current version of Mobile IP version 4 signaling and forwarding. The signaling and forwarding is conducted between a Mobile Node and a Home Agent, via an optional intermediate Foreign Agent, for a Home Address of the Mobile Node. The Home Agent acts as the Mobile IP signaling endpoint, as well as the forwarding endpoint for packet tunneling between the Home Agent and the MN Care of Address. This document describes an alternative architecture in which the Home Agent is the signaling endpoint whilst a new Tunnel Agent acts as the forwarding endpoint. A.W.OĆNeill Expires - January 12, 2005 [Page 1] Decomposed Home Agent Architecture July, 2004 Table of Contents Status of this Memo.................................................1 Abstract............................................................1 Table of Contents...................................................2 1. Problem Statement................................................2 2. Terminology......................................................3 3. Requirements and Scope...........................................4 4. The Decomposed Home Agent Architecture...........................4 4.1 Common Channel Tunnel Agent Control Protocol....................6 4.2 Channel Associated Tunnel Agent Control Protocol................6 4.3 Overview Comparison between TACP-CC and TACP-CA Models..........7 4.4 Potential Benefits of the DHA...................................8 4.5 DHA Redundancy Enhancements.....................................8 4.6 TA Redundancy Enhancements......................................9 4.7 Additional Deployment Considerations...........................11 5. MIP extensions for the Decomposed HA............................11 5.1 Tunnel Agent Address Request...................................11 5.2 Tunnel Agent Address Grant.....................................12 5.3 TAAR Protocol Rules............................................13 5.4 TAAG Protocol Rules............................................13 6. IANA Considerations.............................................13 6.1 Mobile IP Extension Type and Subtypes..........................13 6.2 Mobile IP Error codes..........................................14 7. Security Considerations.........................................14 8. Backward Compatibility Considerations...........................14 8.1 Legacy Home Agent..............................................14 8.2 Legacy Foreign Agent...........................................15 8.3 Legacy Mobile Node.............................................15 9. Notice Regarding Intellectual Property Rights...................15 References.........................................................15 AuthorsĆ Addresses.................................................16 Copyright Statement................................................16 Disclaimer of Validity.............................................16 Acknowledgement....................................................16 1. Problem Statement RFC 3344 describes the current version of Mobile IP version 4 signaling and forwarding. The signaling and forwarding is conducted between a Mobile Node and a Home Agent, via an optional intermediate Foreign Agent, for a Home Address of the Mobile Node. The Home Agent acts as the Mobile IP signaling endpoint, as well as the forwarding endpoint for packet tunneling between the Home Agent and the MN Care of Address. The general Internet Routing System considers that this Home Address (and hence the associated MN interface) is located at the Home Agent, whilst Mobile IP signaling and forwarding enables that home address to instead be located at a remote Access Router, which may optionally contain a Foreign Agent. A.W.OĆNeill Expires - January 12, 2005 [Page 2] Decomposed Home Agent Architecture July, 2004 This dual-mode Home Agent exhibits a number of characteristics; i) The Home Agent node implementation has to be optimized for both MIP signaling and forwarding operations. ii) The Home Agent location needs to be optimized both from a MIP signaling and forwarding perspective. iii) Failure of the Home Agent typically renders both MIP signaling and forwarding inoperable for each of the mobility bindings at that Home Agent. iv) The Home Agent optionally needs to support additional interfaces to AAA, Security, Address Management and other policy servers to provide a complete set of mobility features whilst scaling to support a very large number of MNs. The design and operational conflicts and compromises that arise when a single node attempts to undertake multiple large-scale, high availability tasks have been seen before in telecommunication and Internet systems (CAS v CCS, MGCP v SIP etc) and the IETF presently has a working group looking at a general protocol framework (FORCES) for decomposing network nodes into distinct control and forwarding elements that are synchronized by a control protocol. In addition, 2G and 3G cellular systems separate forwarding (MSC/GGSN) from control (HLR/VLR) as much as possible although the analogy is somewhat stretched here especially in the Packet Domain. This document therefore describes an alternative MIP architecture in which the Home Agent is decomposed and remains the MIP signaling endpoint, whilst a new Tunnel Agent acts as the MIP forwarding endpoint. This enables the Decomposed Home Agent to be optimized and located for MIP signaling purposes whilst the new Tunnel Agent can be independently optimized and located for forwarding purposes. The document first describes the minimal MIP extensions required to facilitate this decomposition, and then investigates a couple of implementation scenarios and the potential associated operational advantages of the architecture. The decomposition is equally applicable to MIPv6 but that is outside the scope of this document. 2. Terminology MN Mobile Node as defined in RFC 3344 HoA MNĆs Home Address HA Home Agent as defined in RFC 3344 FA Foreign Agent as defined in RFC 3344 CoA MNĆs Care of Address FACoA Shared CoA from the Foreign Agent CCoA Colocated Care of Address CN Correspondent Node as defined in RFC 3344 CNA IP address of the Correspondent Node DHA Decomposed Home Agent as outlined in this document TEN Tunnel Endpoint Node (the MN or FA) TA Tunnel Agent as outlined in this document A.W.OĆNeill Expires - January 12, 2005 [Page 3] Decomposed Home Agent Architecture July, 2004 TAA IP address of the Tunnel Agent TACP-CC Common Channel Tunnel Agent Control Protocol TACP-CA Channel Associated Tunnel Agent Control Protocol XX-CC A MIP agent that complies with the CC decomposition XX-CA A MIP Agent that complies with the CA decomposition RRQ Mobile IP Registration Request as defined in RFC 3344 RRP Mobile IP Registration Reply as defined in RFC 3344 RRQ(TAAR) A RRQ containing the TAAR extension. RRP(TAAG) A RRP containing the TAAG extension. 3. Requirements and Scope Following are the requirements that the proposed decomposed Home Agent architecture tries to satisfy. - Physical separation of the MIP signaling and forwarding endpoints in the core network. - The carriage of a claimed Tunnel Agent address in MIP signaling to the DHA. - The carriage of an assigned Tunnel Agent address in MIP signaling to the TEN. - Support for multiple DHAs and TAs per MN for high availability deployments. - Support for common channel and channel associated Tunnel Agent Control protocols (TACP) between the DHA and the TA for managing tunnel bindings. The following architecture components and analysis are not undertaken in this document. - Definition of the detailed requirements or mechanisms for either version of TACP. - Definition of the requirements or mechanisms for, the dynamic assignment of a Tunnel Agent address and HoA address at the DHA. - Detailed theoretical, financial or operational comparisons between the existing products and deployments based on RFC3344 architecture and the Decomposed Home Agent architecture. 4. The Decomposed Home Agent (DHA) Architecture The DHA has optional interfaces into external policy elements such as address management, security and AAA servers much as the RFC3344 HA. The Decomposed Home Agent acts as a ćMIP ControllerĆ for one or more Tunnel Agents under its control, on behalf of MNs. The DHA receives A.W.OĆNeill Expires - January 12, 2005 [Page 4] Decomposed Home Agent Architecture July, 2004 RRQ signals from the MN and returns RRP signals to that MN via any intermediate FAs. The DHA is aware of the mapping between Tunnel Agents and HoA prefixes, and may also be aware of preferred Tunnel Agents per MN, and/or for a specific aggregate of ARs. The DHA is able to provide a dynamic Tunnel Agent grant as well as dynamic Home Address assignment, but can alternatively verify a requested Tunnel Agent and/or HoA for a MN. The DHA also has means, compliant with RFC3344, to authenticate MIP signaling with the MN and with an optional FA on the signaling path. The Tunnel Agent is a new MIP element that supports MIP tunneling operations to/from the Tunnel Endpoint Node (TEN = MN or FA) at which the MN CoA is located (MN CCoA or FA CoA). Each TA undertakes tunneling operations for one or more MNs, and for one or more HoAs per MN. The general Internet Routing System considers that each MN HoA (and hence the associated MN interface) is located at the Tunnel Agent (and not the DHA, unlike the RFC3344 HA). MIP forwarding then enables that HoA to instead be dynamically located at a remote Access Router (AR), which may optionally contain a Foreign Agent. This specifically means that data packets between the CN and the MN do not visit the DHA as shown in figure 1. CN DHA TA FA MN Forward CNA------------------------TAA=====>FACoA--------->HoA RevTun CNA<-----------------------TAA<=====FACoA----------HoA Figure 1. TA based MIP Data forwarding The requested and/or granted Tunnel Agent address is carried in RRQ and RRP MIP messages, between the MN and the DHA, using new MIP extensions that are defined in section 5. The Tunnel Agent maintains tunnel bindings much like the forwarding part of the RFC3344 HA, and can support forward and reverse tunneling for IPinIP, GRE and IPSEC tunnels much like a traditional RFC3344 HA. Note that general purpose routers generally have support for low density tunneling operations such that TAs can potentially be located throughout a routed domain in a highly distributed and locally optimized way (from a forwarding perspective). Two alternative signaling models, for managing the tunnel agent bindings from the DHA, are overviewed in this document, within sections 4.1 and 4.2. Both models support multiple redundant TAs per MN HoA, or even alternative HoAs at redundant TAs. It is the support for a Tunnel Agent Control Protocol that primarily enables general purposes routers to become potential Tunnel Agents. The Decomposed HA Architecture also fully supports specialized highly centralized Tunnel Agent hardware/software (as does the forwarding part of an RFC3344 HA) and is ambivalent on the optimal configuration which is likely to be more closely tied to specific deployment scenarios. Mixed deployments of centralized and distributed TAs under a single DHA are intended to be supported. A.W.OĆNeill Expires - January 12, 2005 [Page 5] Decomposed Home Agent Architecture July, 2004 4.1 Common Channel Tunnel Agent Control Protocol (TACP-CC) The Decomposition of the HA follows the FORCES framework in which a distinct control protocol is used between the DHA and the TA to manage tunnel bindings. The FORCES protocol is a candidate TACP-CC but the requirements for, and design of, the TACP-CC is outside the scope of this document. This architecture is shown in figure 2 for the case of the TEN being the FA. An optional Tunnel Agent Address Request (TAAR) extension is added by the MN or the TEN into the RRQ, and verified by the DHA. The MN adds the TAAR to inform the DHA of an existing or preferred TA address, along with any associated allocated HoA at that TA. The FA adds the TAAR on behalf of the MN for the reasons above or to inform the DHA of a preferred TA in local AR state that was optionally returned from the AAA infrastructure. The TAAR can include an ALL-ZEROs TAA which indicates support for Tunnel Agents without indicating a preferred TA. The Tunnel Agent Address Grant (TAAG) extension is added by the DHA into the RRP and consumed by the TEN. It is optionally sent to the MN if the MN originated the TAAR in the RRQ. The DHA uses the TACP-CC protocol with the granted TA to install the required tunnel binding into the TA, for the tunnel between the TA and the FA CoA. This state is commensurate with the parameters in the associated MIP signals. The TACP-CC might employ peer to peer or client-server signaling models and the tunnel bindings designed as soft or hard state. Figure 2 implies that the RRP is not sent by the DHA until the TACP-CC REP is received back from the TA. However, the precise requirements in that regard, given the soft-state best effort nature of MIP signaling, are outside the scope of this overview document. CN DHA TA FA MN RRQ <************************<************** TACP-CC ############> TACP-CC <############ RRP *************************>*************> Figure 2. TACP-CC and MIP signaling model 4.2 Channel Associated Tunnel Agent Control Protocol (TACP-CA) The Decomposition of the HA is such that the TA is located between the AR and the DHA and is on the MIP signaling path. The TA tunnel bindings are then installed using MIP RRQ/RRP extension signals that traverse the TA as shown in figure 3. TACP-CA is therefore fully integrated within MIP signaling. This model avoids the need for the development of a new protocol between the DHA/TA but instead places MIP signaling load on the TA. The required MIP extensions to support an intermediate MIP agent will be similar to those developed for A.W.OĆNeill Expires - January 12, 2005 [Page 6] Decomposed Home Agent Architecture July, 2004 regionalized MIP signaling schemes but the detailed requirements for, and design of, these extensions are outside the scope of this document. Figure 3 shows that the FA needs to know the TA address for the routing of the RRQ, and hence must either obtain the TA address from a RRQ(TAAG) received from the MN, or from local state at the FA potentially returned from a AAA access_request. The FA can in the latter cases verify a RRQ(TAAR) received from the MN. CN DHA TA FA MN RRQ(TACP-CA) <#*#*#*#*#*#*<#*#*#*#*#*#<*#*#*#*#*#*#*# RRP(TACP-CA) *#*#*#*#*#*#*>#*#*#*#*#*#>*#*#*#*#*#*#*> Figure 3. MIP based TACP-CA protocol Figure 3 implies that the MN-FA signaling is aware of the DHA / TA architecture but again it should be made clear, that in the case of a FACoA, the presence of the DHA/TA combination can be completely hidden from the MN by the FA, and RFC3344 signaling employed between the FA and the MN. A further variant of the TACP-CA model is that the RRQ does not visit the TA whilst the RRP, following TA address grant at the DHA, does visit the granted TA. This avoids the need for the FA to determine the TA address but is a significant departure from the traditional MIP signaling model and therefore not further discussed here. 4.3 Overview Comparison between TACP-CC and TACP-CA Models The TA-CA avoids having to support the MN-HA Security Associations (SA) as well as the interfaces to the policy servers in the operations zone which are instead reached through the DHA. The TA-CA does however need an FA-TA SA which potentially could be shared across a number FAs. The TA-CA can be distributed across the routing domain and located optimally for forwarding purposes. The TA- CA does however still operate on per HoA MIP signaling and hence still has high density high availability design constraints for both the forwarding and signaling planes. The FA-CA needs to support some additional minor MIP extensions as well as an FA-TA SA which potentially could be shared with a number of TAs in the domain. The FA-CA also needs to be able to determine the TAA so that the RRQ can be routed via the selected TA to the DHA. The TA-CC avoids having to support the MN-HA SAs as well as the interfaces to the policy servers in the operations zone which are again reached through the DHA. The TA-CC does not need an FA-TA SA and can also be distributed across the routing domain and located optimally for forwarding purposes. The TA-CC does not operate on per HoA MIP signaling but instead has a TACP-CC signaling session per DHA. A.W.OĆNeill Expires - January 12, 2005 [Page 7] Decomposed Home Agent Architecture July, 2004 The FA-CC needs to support some additional minor MIP extensions but does not need either an FA-TA SA or a means to determine the preferred TA which is instead undertaken by the DHA. TA-CC and TA-CA have very different implications on signaling resilience, performance and cost, and subsequently on the ideal levels of distribution of the TA function for a given population of MNs and ARs. These are not addressed in this overview document. In the case of FA CoAs, the MN may be fully isolated from whether the core network is employing TACP-CC or TAP-CA decomposition signaling which therefore enables MN to move and employ either system during one or more MIP access sessions. 4.4 Potential Benefits of the DHA It is clear from figures 2 and 3 that the DHA is in either case absolved from packet forwarding yet retains its role as the MIP signaling controller and primary interface into policy systems such as the AAA and security infrastructure. The DHA continues to need a MN-HA SA and a FA-HA SA as well as security associations with the external policy systems. The DHA can now be co-located with those policy servers behind an operational firewall as its location is now not affected by forwarding constraints. The DHA can be implemented on a high-availability server platform, using off-the-shelf hardware and OS software, and its mobility and address management information stored in a high availability database where it can be made available to external application servers in support of general operations (fault, fraud, performance etc), location based services, presence servers and paging servers. The DHA function can specifically be fully integrated within the AAA database infrastructure. 4.5 DHA Redundancy Enhancements A single logical DHA, fronting a high-availability server and storage cluster, can clearly be used to support a very large number of mobility bindings at reasonably low cost. A pair of geographically dispersed logical DHAs can be used by Mobile Internet Service Providers (MISPs), much as AAA is architected for todayĆs ISPs. The MNs associated with that domain can be persistently configured with the primary and secondary DHA addresses, because irrespective of the MN location, mobility signaling is always sent to one of those DHAs. However, DHA failures will still of course occur and the DHA (and the RFC3344 HA) can be assumed to be able to recover after some reboot interval and retain some portion of ongoing binding information depending on the type and resolution of the binding state storage. The impact of a single or primary DHA failure, when compared to an single or redundant pair of RFC3344 HAs, is however somewhat different. i) The DHA failure only affects binding changes because the forwarding path is completely independent of the DHA, and A.W.OĆNeill Expires - January 12, 2005 [Page 8] Decomposed Home Agent Architecture July, 2004 the tunnel state at the TA remains in place for the duration of the DHA failure. ii) During the failure, the MN can continue to receive packets at its historical CoA stored in the TA, and can also move to a new AR if the historical AR is providing forwarding for the historical CoA towards the new CoA as a result of inter-AR MIP signaling. iii) If a MN does not get a RRP back from a DHA then existing MNs will retry and hence will be able to rebuild the mobility state following the reboot interval, but will not be able to alter its historical CoA during that interval. iv) If the DHA misses a binding deregistration during its reboot, and the MN disconnects from the historical CoA, then stale state can exist on the DHA and/or TA until the lifetime of the state at the TA expires. This however is no worse than the scenario of a MN disconnecting at its historical CoA without attempting to explicitly deregister that CoA at the DHA. v) If the primary DHA is deemed unavailable following some number of missed RRPs, or following some timer, the MN can instead contact the secondary DHA and include in that RRQ its existing TA and HoA allocation state, as well as the modifications to its MIP binding state. The secondary DHA can then independently control the MNs HoA tunnel state at that TA and hence continuity of the MNs communications is possible even with a sustained DHA failure. vi) If the current TA of a MN HoA fails then access to the DHA is maintained and so the MN can as a worst case request a new dynamic TA-HoA assignment and resume its communications using the new TA/HoA assignments. Therefore, it is possible that additional significant and cost effective resilience is provided by the decomposition of the HA into a DHA and a TA, and by the ability to employ two concurrent DHAs hosted on high availability server infrastructure. 4.6 TA Redundancy Enhancements The DHA architecture offers support for TA redundancy, which enables the IP routing system to reroute around TA failures. The MN may be granted multiple TAs for a specific MIP signaling session that are communicated to the MN TEN in multiple TAAGs. Each TA is located in a single routing domain and each TA injects a prefix which covers the HoA of the MN, in an anycast configuration. The metrics associated with that HoA prefix, at any particular router in the routing domain, produces a preferred TA for packets arriving from a specific CN at A.W.OĆNeill Expires - January 12, 2005 [Page 9] Decomposed Home Agent Architecture July, 2004 that router, that are destined for that MN HoA. Suitable selection of prefix metrics in the routing domain can result in the TAs load- sharing traffic, with each TA dealing with a sub-set of the CNs that are injecting packets towards that prefix. Alternatively, a primary TA is used for all active CNs until that primary TA fails, In either case, a TA failure results in the metric associated with the prefix from that TA degrading to the extent that the other TA becomes the sole forwarder for downstream packets towards that HoA prefix. The speed of routing convergence for the route to the secondary TA is a function of the type of routing protocols involved, the size of the routing domain, and the topological distance between the primary and secondary TAs. In a noteworthy configuration, somewhat reminiscent of synchronized RFC3344 HAs in a hot-standby pair, the primary and secondary TAs can be on the same subnet and ARP mechanisms (gratuitous, proxy etc) used to move HoA specific traffic between them. It should be pointed out however that the two TAs do not need to support a tunnel binding synchronization protocol between each other because each is independently slaved of the DHA. Upstream reverse tunneled traffic to the TAs may be delivered to either of the redundant TAs although clearly it is beneficial if the upstream traffic is sent to the TA that is the source of the downstream traffic for each CN. When routing causes traffic from a specific CN to be diverted to the alternative TA then this can act as a trigger for the upstream traffic to be reverse tunneled to that alternative TA. The support for multiple TAs in TACP-CC is at a fairly obvious as it simply requires the DHA to manage tunnel binding messages with multiple TAs in parallel. However, TACP-CA requires further description because a single MIP RRQ arriving at the FA needs to be copied and routed to the DHA via both the primary and secondary TAs. The MN and DHA (just as the RFC3344 HA) manage the Identification parameter (for replay protection), so that the parameter space is unaffected by the split. The FA therefore uses the Identification information in the received RRQ, along with local state on the chosen primary and secondary TA addresses, to create RRQs towards each TA containing the same Identification information so that the DHA can match the redundant RRQs and issue associated redundant RRPs back via the primary and secondary TAs to the common FA. The challenge- response protocol (RFC3012) information is similarly unaffected by the redundancy procedure and is again duplicated in the redundant RRQ and RRPs. However, it should be made clear that under various failure conditions, further analysis may indicate a need for additional MIP protocol mechanisms to ensure that message sequencing, matching and replay protection is maintained. A.W.OĆNeill Expires - January 12, 2005 [Page 10] Decomposed Home Agent Architecture July, 2004 4.7 Additional Deployment Considerations The ability to locate the DHA and the TA in different parts of the network leads to a number of capabilities covering specific deployment scenarios. The use of MIP for corporate remote access [2] leads to the need for firewall traversal of the MIP signaling and tunneling. Placing the HA in the DMZ causes internal traffic to be routed via the DMZ whilst placing the HA inside the corporate network causes external MIP signaling to be allowed into the corporate network. The ability to place the DHA in the DMZ, whilst placing the TAs either inside or outside of the corporate network based on MN location should be of particular benefit to that scenario. Inter-operator MIP roaming typically results in both inter-domain signaling and forward, or results in the assignment of a HA in the visited domain and hence a loss of visibility of mobility signaling in the home domain. The decomposed architecture enables the home domain DHA to continue to marshal the MIP signaling plane whilst using an inter-domain protocol to manage tunnel bindings at a TA in the visited domain and so avoid the need for inter-domain forwarding. Alternatively, a visited domain DHA could be assigned to produce a short MIP signaling path, yet ensure that the MN gets a home domain TA and HoA as part of a wholesale/retail solution. The DHA maintains a view of all binding activity from the signaling plane, and can receive packet forwarding metrics within TACP-CC (or possibly even TACP-CA) from the TA, and therefore is in an excellent position to manage load-sharing across a group of TAs. The DHA model avoids the need for HA Redirection and hence the MN can continue to use a well-known DHA across and within MIP access sessions whilst still preserving the load-sharing capabilities for the operator. An RFC3344 HA could additionally be extended to support decomposition for a set of TAs for load-sharing / off-loading purposes. The HA would act as the forwarder for some main set of HoA prefixes, and when consumed, the HA could off-load the forwarding for additional MNs to external TAs (with their own HoAs). This dual-mode HA/DHA also of course provides support for RFC3344-only MNs and FAs, and is therefore a nice option for incremental deployment. 5. MIP extensions for the Decomposed HA Architecture 5.1 Tunnel Agent Address Request Extension (TAAR) This extension may be included in the RRQ by a MN to request a specific Tunnel Agent address. If not inserted by the MN, then the optional FA may alternatively request a specific Tunnel Agent address to be assigned. This skippable extension follows the short extension format as defined in [2], where the subtype indicates the specific A.W.OĆNeill Expires - January 12, 2005 [Page 11] Decomposed Home Agent Architecture July, 2004 address management extension. 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 | Length | Sub-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Agent Address (TAA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Address Management Extension (skippable) [2] Sub-Type 1 Length 6 Reserved Reserved for future use. MUST be set to 0 on sending and MUST be ignored on reception. TAA 4 byte IPv4 address of the requested Tunnel Agent 5.2 Tunnel Agent Address Grant Extension (TAAG) The TAAG extension is included by the DHA in a RRP to inform the TEN of the address of the assigned Tunnel Agent. The RRP(TAAG) may be forwarded by the FA (TEN) to the MN when the MN has requested a specific Tunnel Agent using the TAAR extension. The TAAG is also included by a FA-CA in a RRQ(TAAG) to the assigned TA-CA, as the TA assignment in the TACP-CA model is at the FA. This skippable extension follows the short extension format as defined in [2], where the subtype indicates the specific address management extension. 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 | Length | Sub-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Agent Address (TAA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Address Management Extension (skippable) [2] Sub-Type 2 Length 6 Reserved Reserved for future use. MUST be set to 0 on sending and MUST be ignored on reception. TAA 4 byte IPv4 address of the granted Tunnel Agent A.W.OĆNeill Expires - January 12, 2005 [Page 12] Decomposed Home Agent Architecture July, 2004 5.3 TAAR Protocol Rules The MN sends the RRQ(TAAR) to either the HA or the FA to indicate compliance with this document. The TAA may be 0.0.0.0 to request a dynamic TAA assignment in which case a dynamic HoA MUST also be requested. The TAA may be a.b.c.d to indicate a request to use a specific TAA and the associated HoA field MAY be either 0.0.0.0 to indicate a request for dynamic assignment of a HoA, or w.x.y.z to indicate a preferred HoA at that TAA. Clearly, the DHA must ensure that the resulting HoA is routable via the assigned TAA. If the RRQ(TAAR) is received at an FA-CC, then that FA will forward a RRQ(TAAR) to the DHA-CC and the dynamic assignment of the TA and the HoA undertaken. 5.4 TAAG Protocol Rules An FA-CA sends a RRQ(TAAG) to the TA-CA, whether or not the MN issued a RRQ(TAAR). The DHA sends the RRP(TAAG) to either the MN or the FA in response to either a RRQ(TAAR) or RRQ(TAAG). The RRP(TAAG) indicates compliance with this document and confirms the address of the assigned TA (along with the associated HoA assignment information) to the TEN. The FA-CA or FA-CC that receives a RRP(TAAG) SHOULD forward a RRP(TAAG) to the MN if that FA received a RRQ(TAAR) from the MN. Otherwise, the FA MAY forward the RRQ(TAAR). 6. IANA Considerations 6.1 Mobile IP Extension Type and Subtypes This document introduces the following Mobile IP extension type. Name : Tunnel Agent Extensions Type Value : TBD Section : 6 This document also introduces two of the following subtypes for the above extension type. Sub-type Name Section -------- ---- ------- 1 Tunnel Agent Address Request 6.1 2 Tunnel Agent Address Grant 6.2 A.W.OĆNeill Expires - January 12, 2005 [Page 13] Decomposed Home Agent Architecture July, 2004 6.2 Mobile IP Error codes This document introduces no new error codes that can be returned by the FA or HA in a Mobile IP Registration Reply. However, such error codes will no doubt be required as part of the design of TACP-CA and are for further study. 7. Security Considerations The DHA in both decomposition schemes can be located in the operations zone behind a firewall and so should be better protected against DOS attacks. The TA-CC does not have a need to exchange signaling with MNs and should therefore be better protected against DOS attacks. The decomposition of the DHA and the TA offers no new vulnerabilities in the MIP signaling plane for TACP-CC, and any vulnerabilities for TACP-CA have been previously discussed and addressed in regional MIP signaling schemes where bindings are also installed in a node that is situated between the HA and the TEN. However, all such vulnerabilities will need to fully documented and protected against in the TACP-CA design. The TACP-CC decomposition clearly introduces a new signaling protocol with associated vulnerabilities that can only be examined as part of that protocol design. However, a clear need will exist to authenticate and integrity protect TACP-CC messages and parameters to avoid DHA-TA communications being corrupted. The above mentioned procedure for Tunnel Agent address agreement, that is common to both decomposition schemes, introduces the TAAR and TAAG extensions which MUST be protected by an authorization-enabling extension [2] between the MN and the HA. Thus, this procedure does not introduce any new security concerns that are not otherwise outlined above. 8. Backward Compatibility Considerations These comments assume all MIP nodes compliant with this document are able to revert to RFC3344 behavior. 8.1 Legacy Home Agent Upon receiving a RRQ(TAAR) from a MN following the procedure outlined in this document, the legacy HA SHOULD follow the behavior as per RFC 3344, ignoring the TAAR extension which has been defined in the skippable range of extensions. A compliant FA will note that the TAAG is missing and MAY revert to A.W.OĆNeill Expires - January 12, 2005 [Page 14] Decomposed Home Agent Architecture July, 2004 RFC3344 behavior. A complaint MN that sent a RRQ(TAAR) but did not receive a RRP(TAAG) will be informed that the core network does not support decomposition. 8.2 Legacy Foreign Agent For the cases where the RRQ(TAAR) is sent by a complaint MN with TAA field set to 0.0.0.0 or a.b.c.d, the behavior of the legacy FA will be the same as per RFC 3344, and the FA will not forward a RRQ(TAAR) towards the HA. A compliant HA will not receive RRQ(TAAR) and hence will not return a RRQ(TAAG). The HA will resort to RFC3344 behavior. 8.3 Legacy Mobile Node A legacy MN that is using a FACoA may be supported by a compliant FA, DHA, and TA combination in the core network whilst employing RFC3344 RRQ/RRPs. The RRQ behavior of a legacy MN that uses a CCoA will not be affected, since the new behavior will be applicable only for RRQs which include the TAAR so indicating compliance with this specification. The RRP behavior of a legacy MN that uses a CCoA is also not affected by the receipt of an unsolicited TAAG as it is only sent to a MN that has indicated compliance with this specification. It is also a skippable extension and behavior will progress as per RFC 3344 if incorrectly sent to a non-compliant MN as a result of a bug. 9. Notice Regarding Intellectual Property Rights Flarion's submissions will conform with RFC 3668. Flarion may seek patent protection on some or all of the technical information submitted by its employees in connection with the IETF's standards process. If part(s) of a submission by Flarion is (are) included in a standard and Flarion owns patent(s) and/or pending patent application(s) that are essential to implementation of such included part(s) in said standard, Flarion is prepared to grant a license on fair, reasonable, reciprocal (license back) and non-discriminatory terms on such included part(s). Informative References [1] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, August 2002. [2] F. Adrangi, Ed., H. Levkowetz, Ed. "Mobile IPv4 Traversal of VPN Gatewaysö, Internet-Draft, draft-ietf-mip4-vpn-problem- statement-00.txt, October 14, 2003. A.W.OĆNeill Expires - January 12, 2005 [Page 15] Decomposed Home Agent Architecture July, 2004 AuthorsĆ Addresses Alan O'Neill Flarion Technologies a.oneill@flarion.com Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. A.W.OĆNeill Expires ű January 12, 2005 [Page 16]