Personal A. O'Neill Internet Draft Flarion Technologies Document: draft-oneill-mip-concat-00.txt 8 May 2002 Expires: Oct 2002 Concatenated MIP for Mobility Management <draft-oneill-mip-concat-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Nested MIP [NestMIP] provides a means to support both localization and aggregation of MIP signalling. It achieves this by providing two distinct layers of MIP signalling and forwarding; a local access layer that provides local mobility management and local access services, and a remote access layer that provides remote access back to a home subnet. The local access layer provides a regional address from a Regional Mobility Agent (a regional HA) that is then used as a CCoA for the remote access layer. Inter-FA movement and MIP signalling at the local access layer then automatically produces the hand-off of potentially multiple parallel remote access sessions. The consequences of this model are however reductions in bandwidth efficiency due to the additional layers of temporary and permanent encapsulation. This draft describes a complementary model for MIP forwarding, called Concatenated MIP that re-uses, and extends the localised and aggregated MIP signalling model from [NestMIP]. The enhanced forwarding model is intended to co-exist both with [NestMIP] and [RegTunMods] so that the appropriate trade- offs can be made on a per session basis between bandwidth efficiency and other features. Inter-RMA hand-offs between Nesting and Concatenating Regional Mobility Agents is also supported. A.W. O'Neill Expires Oct 2002 [Page 1]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002 INDEX Abstract 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . . . . 3 3. Terminology used in this document . . . . . . . . . . . . . . . . . 3 4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Forwarding Models . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Nested MIP Forwarding. . . . . . . . . . . . . . . . . . . . . 4 5.2. Regional Tunnel Forwarding . . . . . . . . . . . . . . . . . . 4 5.3. HoA Independent Switching. . . . . . . . . . . . . . . . . . . 5 5.4. Concatenated MIP Forwarding. . . . . . . . . . . . . . . . . . 5 5.5. Private addressing . . . . . . . . . . . . . . . . . . . . . . 7 5.6. Security Associations. . . . . . . . . . . . . . . . . . . . . 7 6. Basic Concatenated MIPv4 Signalling Description . . . . . . . . . . 8 6.1. Local Access Only Signalling . . . . . . . . . . . . . . . . . 9 6.2. Remote Access Only Signalling. . . . . . . . . . . . . . . . . 9 6.3. Local and Remote Access Signalling . . . . . . . . . . . . . . 9 6.4. Combined LA/RA Signalling. . . . . . . . . . . . . . . . . . . 10 6.5. Style Extension. . . . . . . . . . . . . . . . . . . . . . . . 10 7. AAA Support for Concatenated MIP. . . . . . . . . . . . . . . . . . 10 7.1. FA AAA Requests. . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. RA AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 11 10. Notice Regarding Intellectual Property Rights. . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Nested MIP [NestMIP] provides a means to support both localization and aggregation of MIP signalling. It achieves this by providing two distinct layers of MIP signalling and forwarding; a local access layer that provides local mobility management and local access services, and a remote access layer that provides remote access back to a home subnet. The local access layer provides a regional address from a Regional Mobility Agent (a regional HA) that is then used as a CCoA for the remote access layer. Inter-FA movement and MIP signalling at the local access layer then automatically produces the hand-off of potentially multiple parallel remote access sessions. The consequences of this model are however reductions in bandwidth efficiency due to the additional layers of temporary and permanent encapsulation. A.W. O'Neill Expires Oct 2002 [Page 2]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002 The additional encapsulations can be avoided by adding support for CoA switching to the Regional Mobility Agents and Foreign Agents. The CoA switching techniques described here are broader than those presently supported by Foreign Agents (for smooth forwarding) and by Gateway/Regional Foreign Agents for Regional Tunnelling, to preserve the aggregation capabilities. This draft therefore describes a complementary model for MIP forwarding, called Concatenated MIP that re-uses, and extends the localised and aggregated MIP signalling model from [NestMIP]. The enhanced forwarding model is intended to co-exist both with [NestMIP] and [RegTun] so that the appropriate trade-offs can be made on a per session basis between bandwidth efficiency of other features. Inter-RMA hand-offs between Nesting and Concatenating Regional Mobility Agents is also supported. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3. Terminology used in this document Much of the terminology used in this document borrows from Mobile IPv4 [MIPv4], MIP Regional Tunnelling [RegTun], MIP Reverse Tunnelling [RevTun] and MIP Route Optimisation [RoutOpt]. This draft introduces the following additional terminology. Local access service - Internet access using a topologically local address Remote access service - Internet access using a topologically remote address Regional Mobility Agent (RMA)- a regional node capable of HA/FA type behaviour Regional Address (RoA) - A HoA from the RMA HA function RMA Region - the set of FAs able to allocate that RMA to a MN LA/RA MIP - Local access MIP functionality between the MN and the RMA/HA LA visitor list - the MIP visitor list for the RoA / FA CoA binding RA visitor list - the MIP visitor list for the HoA / CCoA=RoA binding LA/RA-NAI - the MN-NAI included in the LA/RA MIP Registration for AAA LA/RA Hand-off - a hand-off effected using the LA/RA MIP layer LA/RA MIP Reg - An MIP Reg in the LA/RA layer direct to the present RMA/HA. Inter-FA Hand-off - a hand-off between two FAs that updates the FA CoA. Inter-RMA Hand-off - a MIP hand-off between two RMAs that results in RoA change HFAIPext - the HFA IP address extension (generalization of GFAIPext) 4. Motivation The motivation for this work is described fully in [NestMIP] but can be summarized here as extending MIP signalling (Registration and Hand-off) to support efficient local Internet access in conjunction with potentially multiple parallel remote access sessions. In the case of this draft, the MIP forwarding is enhanced with two forms of CoA switching to reduce the number of layers of transient and persistent encapsulation both during and after hand-off. In addition, the work seeks to co-exist with the [RegTun] model. A.W. O'Neill Expires Oct 2002 [Page 3]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002 5. Forwarding Models 5.1. Nested MIP Forwarding Nested MIP incurs a remote access encapsulation between the HA and the MN CCoA, with an additional encapsulation between the Regional Mobility Agent (RMA) and the Foreign Agent (FA) CoA. The MN is allocated a Regional Address (RoA) from the RMA which is used by the MN both as an interface address for Local Access (LA) traffic and as the CCoA for Remote Access (RA) traffic. Reverse tunneled LA traffic can be sent using either direct (from RoA to CN) or encapsulating delivery style (RoA to CN, within RoA to FA address) and then the FA encapsulates from FA CoA to the RMA address. Reverse tunneled RA traffic is encapsulated from the CCoA to the HA address and bypasses the RMA. Reverse RA plus reverse LA results in the reverse RA traffic visiting the RMA. These options are shown graphically in figure 1. CN HA RMA FA MN Forward LA CN----------------------------------------------->RoA RMA=====>FACoA Reverse LA CN<-----------------------------------------------RoA RMA<=====FACoA Forward RA CN------------------------------------------------>HoA HA==================================>RoA RMA=====>FACoA Reverse RA CN<------------------------------------------------HoA RevTun RA CN<------------------------------------------------HoA (RMA bypass) HA<==================================RoA RevTun LA/RA CN<------------------------------------------------HoA HA<==================================RoA RMA<=====FACoA Figure 1. Forward and reverse tunnelling in Nested MIP 5.2. Regional Tunnel Forwarding Regional Tunnelling uses a GFA that undertakes CoA switching. The remote access traffic is encapsulated by the HA from the HA address to the shared GFA CoA (SHCoA). The GFA decapsulates and inspects the visitor list based on the HoA, before re-encapsulating from the GFA address to the shared FA CoA (SHCoA). The FA then decapsulates, again inspects the visitor list based on the HoA, and then forwards to the MN. In the case of a MN CCoA, the GFA sends to that CCoA directly, bypassing the FA. Reverse tunneled traffic uses the visitor list bindings in the reverse direction as shown in figure 2. Note that this architecture does not support multiple HoAs efficiently, does not offer support for aggregated hand-offs, cannot easily support concurrent local access or mixed public and private addressing, and the GFA must always be visited in both directions. A.W. O'Neill Expires Oct 2002 [Page 4]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002 CN HA GFA FA MN Forward RA CN<------------------------------------------------HoA HA=====>SHCoA X GFA=====>SHCoA Reverse RA CN<------------------------------------------------HoA HA<=====SHCoA X GFA<=====SHCoA Figure 2 Forwarding and reverse tunnelling with the GFA 5.3 HoA independent switching The limitation with HoA based forwarding is two fold. Firstly, the MIP registration and hand-off signalling to update the HoA state is clearly HoA specific. This is counter to the desire to support multiple concurrent HoAs because each hand-off then requires multiple parallel MIP signalling phases. HoA based forwarding also naturally requires that the HoAs from multiple independent home subnets (corporates, home nets etc) must be globally unique. This means that the HoAs must be addressed from either the global Internet space or mapped into a single private address space resulting in obvious deployment complexity and/or constraints. The nested model avoids both of these problems by basing forwarding on the Roaming address (RoA) used to hide the potentially multiple MN HoAs, rather than on each HoA. This however leads to additional tunnelling overhead that is next addressed by Concatenated MIP. The other limitation is that the GFA does not provide an address for local service that is coordinated with the remote access state. Specifically, the GFA is forwarding based on HoA, and detunnels/tunnels based on CoAs. 5.4. Concatenated MIP Forwarding Concatenated MIP seeks to keep the benefits of the Nested MIP model in terms of private address support, multiple HoAs and concurrent local and remote access, whilst eliminating the additional encapsulation between the RMA and the FA, when compared to Nested forwarding as shown in figures 1 and 2. This is achieved by the MN continuing to acquire an RoA from the RMA, and then registering this RoA as the CCoA in each global HA for each remote access session. The HA behaviour is therefore identical with Nested MIP in that it encapsulates arriving HoA packets into the RoA, which causes them to be routed to the RMA. In the Nested MIP model, the RMA acts like a HA and adds the additional encapsulation to the FA CoA maintained by the LA MIP signalling. In the Concatenated MIP, the RMA instead acts as a CoA switch but in a very different manner to that of the GFA. Firstly, to maintain support for private addressing, the RMA must switch on RoA rather than HoA specific state. The RoA is contained in the LA MIP Reg in the HoA field whilst the new FA CoA is in the CoA field. Therefore any hand- off at the LA layer will cause the RMA to update the next hop to be the new FA CoA for all traffic arriving for that RoA. This state is used to ensure that any packets (from any HoA) arriving encapsulated to the RoA, are switched (not encapsulated) into a tunnel from the RMA address to the FA CoA. With the RA MIP Reg being forwarded via the RMA, that RMA can limit this switching to those packets arriving from the HAs registered for that RoA address. A.W. O'Neill Expires Oct 2002 [Page 5]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002 Secondly, the FA must also switch on globally unique and MN specific state so that the MN can be reached and to enable clean support for private addressing. However, in this case the arriving packets from the RMA do not now contain the RoA address and so HoA specific forwarding is potentially required. This is fine for globally unique addresses but clearly prevents private HoAs due to the problem of ensuring their uniqueness. In addition, using HoA state in the FA means that it must be maintained during inter-FA hand-off using Context transfer because we wish to avoid non-aggregated HoA specific Registrations to the RMA. A further refinement can however avoid this problem through the additional step of making the FA CoA MN specific. A MN Specific FA CoA (FA MSCoA) can be allocated to the MN by the FA, when the MN wishes to avoid HoA specific state. The FA either advertises the MSCoA to the MN on arrival using a unicast FAA (based on AAA state), or adds the dynamically allocated MN specific FA CoA into the HFAext sent to the RMA (as in [RegTun]). The LA MIP Reply carries the RoA and the MSCoA back to the FA and MN. The RA MIP Reg in contrast registers the RoA into the HA for the HoA. Then, when packets arrive at the RMA encapsulated to the RoA (for any HA/HoA pair), the RMA looks in a switching table and replaces the HA:RoA encapsulation with the RMA: MSCoA encapsulation. This reaches the FA where the FA decapsulates from the RMA:MSCoA and determines the RoA from the incoming tunnel destination address (the MSCoA). The FA then encapsulates into that RoA if the destination address is not already that RoA (ie is a HoA) and then forwards based on that RoA instead of the HoA address that was encapsulated. Clearly, for LA layer traffic the destination will already be the RoA and so additional encapsualtion is not required. This therefore produces HoA independent RA forwarding by virtue of the incoming tunnel addresses in the RMA and FA being MN specific (the RoA and the MSCoA respectively). The resulting forward and reverse forwarding and tunnelling is shown in figure 3. Note that the MSCoA can be a private address and that the tunnel between the FA and the MN can be avoided using proxy Care of Addresses [PCCoA]. CN HA RMA FA MN Forward LA CN------------------------------------------------>RoA RMA=====>MSCoA Reverse LA CN<------------------------------------------------RoA RMA<=====MSCoA Forward RA CN------------------------------------------------>HoA HA=======>RoA X RMA=====>MSCoA=======>RoA Reverse RA CN<------------------------------------------------HoA RevTun RA CN<------------------------------------------------HoA HA<===================================RoA RevTun RA/LA CN<------------------------------------------------HoA HA<=======RoA X RMA<=====MSCoA<=======RoA Figure 3. Forwarding and reverse concatenated tunnelling A.W. O'Neill Expires Oct 2002 [Page 6]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002 Meanwhile LA traffic towards the RoA arrives at the RMA and is not matched on any RA layer HA:RoA pair, but matches simply on the LA layer RoA entry. This results in the packet simply being encapsulated into the FA MSCoA and forwarded to the FA as per Nested MIP. The FA decapsulates and forwards according to the MSCoA/RoA/MN state. Concatenated MIP can co-exist with GFA type forwarding, and the RMA can therefore offer CoA switching with specific constraints. Firstly, the HoA must be globally unique, RMA and FA must be able to store HoA state, and the MN should only employ a single RA session such that a single non-aggregated LA MIP Reg can hand-off the session state between FAs. The GFA mode is useful because it enables backwards compatibility with RegTun, offers more efficient support for HoA specific processing, does not require MN specific FA CoAs and avoids the need for RoA assignment when a local access is not required. Finally, it should be noted that in IPv6 the MN can instantly acquire a CCoA from each FA and can therefore use that CCoA instead of an FA based MSCoA to register into the RMA. In this case there is still a tunnel over the air interface as is the case with all CCoA based MIP forwarding. CN HA RMA LMA MN Forward RA CN-------------------------------------------->HoA HA====>RoA X RMA===============>CCoA Reverse RA CN<--------------------------------------------HoA HA<==============================RoA Reverse RA/LA CN-------------------------------------------->HoA HA<====RoA X RMA<===============CCoA Figure 4. Concat forwarding in IPv6 5.5. Private addressing Implications The HoA is now forwarded natively between the CN and the HA and at all other times is protected by an encapsulation. The HoA address type therefore only needs to match the routing in the HA - CN domain which can be public or private. The RoA must be routable between the HA and the MN, including both sides of the RMA. The RoA can be a public address or a NAT can be used to map a private RoA address into the public address space. The MSCoA is only known by the RMA and FA, and therefore can be public or private. It is guaranteed to be unique to each MN because of the RMA managing its address block. In IPv6, the CCoA can be public or private but the necessity for private addresses is clearly significantly removed. 5.6. Security Associations The two MIP layers would continue to use the family of authentication extensions (and associated SAs) that are required in MIP standards docs [MIPv4, RegTun, RevTun, RoutOpt etc]. These include the MN-FA, FA-HA and MN- HA auth extensions, with the RMA being treated as a HA in the LA MIP Layer. A.W. O'Neill Expires Oct 2002 [Page 7]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002 The only significant differences though are that each FA can now practically employ a pre-configured security association (SA) with each RMA, and the RMA and FA can potentially dynamically allocate to the MN an SA with the RMA. The system can of course also rely on [MIPAAA] by the FA informing AAA of the allocated RMA address and the foreign AAA returning the key material for the FA/MN to use with that RMA. In either case, the MN-FA and the FA-RMA can be shared across both LA and RA MIP traffic. Finally, LA hand-off continues to make use of the authentication mechanisms associated with the particular MIP hand-off solution (inter-FA SAs, PFANE etc). Minor extensions to the existing security mechanisms are required for supporting inter-RMA hand-off and these are described in [RMAsig]. 6. Concatenated MIPv4 Signalling Description This re-uses the same signalling plane as that designed for Nested MIP with the restriction that Concatenated MIP features are only available if the signalling is directed through the FA and the RMA. The RMA must be visited to enable the RMA to learn the switching state. Re-using the same signalling plane ensures that Nested, Concatenated and GFA MIP can to some extent co- exist both from an evolution and efficiency perspective. The LA Reg message is used to update the RMA with the evolving FA MSCoA. It is also used to undertake combined RMA and FA hand-off, to obtain the new RoA at the new RMA and to put in place inter-FA, inter-RMA and/or old RMA new FA temporary forwarding. Specifically, hand-off between Nested, Concatenated and GFA capable RMAs is supported. This is described in detail in [RMAsig]. The RA MIP Reg message is used to update the HA with the new RoA and to refresh the LA FA CoA in the RMA. In all cases, the information fields in the standard MIP Reg/Reply message fields are consistent with Nested MIP, and only the way in which that information is used in the RMA and FA changes. The decision about whether the MN forwards to the FA is again dictated by the setting of the 'R' bit whilst the FA configuration and the AAA state returned to the FA dictates whether the RA registration is sent via the RMA. This is because the routing via the RMA is to install awareness into the RMA of HA/HoA state for value-added processing that is optional both for the operator to support and for the MN to require via its AAA profile. The processing in the HA is the same for the Nested and Concatenated models and similar for the GFA model. However, it is essential that the FA and RMA can distinguish between Nested, Concatenated and GFA Reg requests and this can be achieved either through an MIP flag and/or a Style extension (Stylext). The MIP flag option is to use a one bit flag to indicate a request for Concatenated or Nested MIP processing for this registration. The absence of the flag, and hence the backwards compatible option, is Nested MIP as this can be achieved today with existing MIP standards. GFA is a subset of Concatenated and is selected by the nature of the allocated FA CoA. The flag space is however exhausted but use could be made of the 'I' bit which could be used to indicate support for generic regional signalling. A.W. O'Neill Expires Oct 2002 [Page 8]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002 The extension option would be for the MN to include a Stylext that includes additional flags to supplement the MIP header flags. This flag space can then be used to provide Nested/Concat/GFA service specific signalling options to the MN without consuming the more generic MIP Reg flag space. This then enables the MN to dynamically control invoked features rather than relying on the more static AAA profile option. The Stylext could contain flags for public/private address allocation control, NAT control, RMA routing, service level as well selecting between a shared or MN specific CoA. Other Stylext flags can be used to control how broadcast and multicast is forwarded in the LA and RA layers, and to select between local access, remote access and remote+local access service. The combined approach, whereby the MIP Reg flag space is used to differentiate between the Nested and Concat signalling from the MN (maybe by expanding the scope of the 'I' bit), and the Stylext flag space is used by the MN and operator to over-rule or enhance that request, is probably the best approach going forward. This ensures the basic functionality can be supported with zero overhead, but at the cost of the Stylext overhead comes the added opportunity for controlling additional optional service features. 6.1 Local Access Only Signalling Local Access signalling is unchanged from Nested MIP as a shared FA CoA is only required and local access traffic is always encapsulated (Nested) in the FA CoA. Clearly though, if a FA MSCoA is assigned then it can be used instead of a FA SHCoA. Remote access is prevented by the FA blocking MIP Registrations not addressed to the allocated RMA and/or by appropriate blocking of data packets in an FA located firewall. A private RoA can also be used in conjunction with a NAT to prevent remote access MIP signalling to destinations outside of the local operator private addressing domain (intra-domain RA only) 6.2 Remote Access Only Signalling The MN first undertakes LA MIP signalling to obtain an RMA and an RoA, and to bring the MN privileges into the FA. These privileges will indicate that the MN is not allowed to use the local access service but is permitted to undertake remote access. This results in the FA blocking any packets to/from the RoA, other than those necessary for LA/RA MIP signalling. The MN privileges might also indicate that only a specific remote access registration is allowed based on specific HA and/or HoA. The FA and/or RMA can then easily block encapsulated packets sent from/to addresses other than the permitted HA/RoA/MSCoA parameters because the FA (and the RMA) are on the path of the Registrations. HoA specific controls can also be added. 6.3 Local and Remote Access Signalling This is the same as section 6.2 except that the MN privileges enable local access service as well as remote access service. The RMA and FA will therefore allow both encapsulated and unencapsulated packets using the RoA/MSCoA state. Once again local access can be provided in addition to only a specific remote access service as indicated by the MN privileges. A.W. O'Neill Expires Oct 2002 [Page 9]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002 6.4 Combined RA/LA Signalling Given that Concatenated MIP requires the RA MIP Reg to visit both the FA and the RMA, it is always possible to combine LA updates into the RA MIP messaging to the HA, and only use LA messaging to otherwise refresh LA state as described in [NestedMIP] and [RMAsig]. 6.5 Style Extension (Stylext) The following basic information needs to be explicitly signalled in MIP messages to distinguish between Nested, Concatenated and GFA MIP features. In addition, LA and RA MIP messages must be distinguishable which is discussed further in [RMAsig] along with other stylext requirements. Request for LA service Request for Public or Private RoA Request for RA service Request for Public or Private HoA Nested, Concat or GFA mode in RMA for all dependent RA sessions RA service in nested mode with public or private HoA results in a FA SHCoA. RA service in concat mode with a public or private HoA results in a FA MSCoA. RA service in GFA mode is suitable for a single RA session with no local access and results in a SHCoA. 7. AAA Support for Concatenated MIP The following sections detail some additional optional mechanisms within, and hence requirements for, AAA systems supporting the Basic Nested MIP model. 7.1. FA AAA Requests LA MIP is provided to MNs following a AAA check which is triggered at the FA, based on the NAI in the LAMIP Registration as per RFC 2794. This "LA-NAI" is used to route the AAA request to the home AAA server for the MN via any foreign AAA server as per AAA Roaming. This triggers appropriate authentication and authorization results in the MN privileges being returned to the FA. This indicates the authorized service allowances in the foreign wireless network as well as controlling the accounting requirements for the session. Concatenated MIP requires special processing in the FA/RMA and so the AAA response needs to inform the FA as to whether Nested or Concatenated MIP is to be supported for all the MN RA sessions, and should do so in a way that causes Nested to be supported by default. Concatenated uses a MN specific FA CoA to ensure HoA independence and forwarding to the correct MN from the FA. Nested, Concatenated and GFA also potentially require [MIPAAA] assistance to secure the signalling plane and so the Stylext must make the security requirements explicit in the FA/AAA system. A.W. O'Neill Expires Oct 2002 [Page 10]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002 7.2. RMA AAA Behaviour There are also benefits in being able to deliver the MN privileges to the RMA so that policing, accounting and QoS functions can be appropriately distributed between the FA and the RMA. The way in which this processing is conducted is different between Nested and Concatenated Models but the appropriate processing is signalled via MIP and not as a result of RA AAA state. RA AAA Behaviour is therefore unchanged between Nested and Concatenated MIP. 8. IPv6 Considerations The Concatenated model is equally applicable to IPv6 with the major changes being that the MN in IPv6 is able to rapidly acquire a local interface address from each FA. This address can then be used as a MN CCoA for the LA MIP layer to the RMA and is clearly already MN specific. The RMA would still allocate the RoA to the MN, and the MN would once again use this RoA as a MN CCoA for the RA layer HoA in the HA. This is to ensure that each new MN CCoA does not need to be communicated to the HA. The model was shown in figure 4. The remote access layer is therefore unchanged conceptually from the MIPv4 model but is nested within a CCoA rather than a FA CoA at the LA layer. This is necessary because the FA is missing in IPv6. If this is replaced by a Local Mobility Agent(LMA) with similar capabilities, then the LMA and RMA could once again cooperate to control and manage local and remote access services in sympathy with the MN privileges and the operator policies. This may also enable something similar to a FA CoA to be supported. 9. Security Considerations No new security issues are raised by this draft than are already considered in the design of MIPv4, regional tunnelling [RegTun], [RoutOpt] and reverse tunnelling [RevTun]. At all times all information elements are authenticated to the same level as that demanded by MIP and AAA exchanges. New authentication extensions are required but are generated and distributed using established techniques. 10. Notice Regarding Intellectual Property Rights Flarion's submissions will conform with RFC 2026. 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). A.W. O'Neill Expires Oct 2002 [Page 11]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002 11. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [NestMIP] A.W. O'Neill, ``Nested MIP," Internet-draft, draft-ietf-oneill-mip- nested-00.txt, April 2002. [PCCoA] A.W. O'Neill, ``Proxy CCoA Tunnelling for Mobile IP," Internet-draft, draft-oneill-mip-proxyCCoA-00.txt, May 2002. [MIPv4] C.E. Perkins, Ed., ``IP Mobility Support for IPv4," RFC3220, January 2002. [RegTun] E. Gustafsson. Ed., " Mobile IPv4 Regional Registration, Internet-draft, draft-ietf-mobileip-reg-tunnel-06.txt, 1March 2002 [RegTunMods] A. O'Neill, "Modifications to Regional Tunnelling", Internet- draft, draft-oneill-mip-regtun-mods-00.txt, 9 April 2002. [RevTun] G. Montenegro, Ed., "Reverse Tunnelling for Mobile IP, revised," Internet RFC 3024, January 2001. [RevTunMods] A. O'Neill, "Hand-off Extensions for Reverse Tunnelling", Internet-draft, draft-oneill-mip-revtun-ho-00.txt, 22 Feb 2002. [NestMIP] A. O'Neill, "Nested MIP for IP Mobility Management", Internet Draft , draft-oneill-mip-nested-00.txt, May 2002. [RMAsig] A. O'Neill, "Regional Mobility Agent Signalling", Internet-draft, draft-oneill-mip-rmasig-00.txt, May. [MIPAAA] Charles E. Perkins, Pat R. Calhoun, "AAA Registration Keys for Mobile IP", draft-ietf-mobileip-aaa-key-09.txt (work in progress), 26 February 2002 [RoutOpt] C. Perkins, D. Johnson, "Route Optimization in Mobile IP", Internet-Draft, draft-ietf-mobileip-optim-11.txt (work in progress), 6 September 2001. [LowLat] K.E. Malki, Ed., "Low Latency Handoffs in Mobile IPv4", Internet- Draft, draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt, November 2001. [MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6", Internet-Draft, draft-ietf-mobileip-ipv6-16.txt (work in progress), 22 March 2002. Author's Addresses Alan O'Neill Flarion Technologies Phone: +1 908 947 7033 Email: oneill@flarion.com A.W. O'Neill Expires Oct 2002 [Page 12]