Personal A. O'Neill Internet Draft Flarion Technologies Document: draft-oneill-mip-nested-00.txt 8 May 2002 Expires: Oct 2002 Nested MIP for IP Mobility Management <draft-oneill-mip-nested-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 Regional Registration provides a mechanism for MIPv4 to localise registrations. The Mobile Node (MN) initially registers to the HA via the Gateway Foreign Agent (GFA) so that the HA can learn the GFA Care of Address (CoA). The MN can then subsequently use a Regional Registration to maintain the binding in the GFA as the MN moves and changes its Foreign Agent (FA) CoA or Collocated CoA (CCoA). It can continue to do so whilst a MN remains under the GFA through which the MN sent the Home Registration. The GFA performs CoA switching between the GFA CoA and that used by the MN (CCoA or FA CoA). Whilst the regional registration provides localisation, it does not at the same time provide registration aggregation for MNs employing multiple HoAs. The ability to concurrently support multiple MN addresses from arbitrary addressing domains is a 3GPP commercial and technical requirement and therefore of interest to operators seeking to move to an all-IP solution based on MIP. In addition, the GFA is a very stateful element in the core of the Internet that cannot be bypassed on failure through routing updates. This draft describes a complementary, less stateful model for localisation that in addition supports aggregation both for regional-like registration and hand-offs. The model re-uses as much as possible from the home registration signalling model of [RegTun] but requires a new form of aggregated regional registration. A.W. O'Neill Expires Oct 2002 [Page 1]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 INDEX Abstract 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . . . . 2 3. Terminology used in this document . . . . . . . . . . . . . . . . . 2 4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Basic IPv4 Nested MIP Design . . . . . . . . . . . . . . . . . . . 6 5.1. Regional Tunnelling Implications. . . . . . . . . . . . . . . . . 8 5.2. Reverse Tunnelling Implications . . . . . . . . . . . . . . . . . 9 5.3. Private addressing. . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Security Associations . . . . . . . . . . . . . . . . . . . . . . 11 6. Basic Nested MIPv4 Signalling Description . . . . . . . . . . . . . 11 6.1. Local Access Only Signalling. . . . . . . . . . . . . . . . . . . 12 6.2. Remote Access Only Signalling . . . . . . . . . . . . . . . . . . 12 6.3. Local and Remote Access Signalling. . . . . . . . . . . . . . . . 13 7. Enhanced RA Registration. . . . . . . . . . . . . . . . . . . . . . 13 7.1 RA MIP Registration via the FA. . . . . . . . . . . . . . . . . 13 7.2 RA MIP Registration via the FA and RMA. . . . . . . . . . . . . 14 7.3 Efficient Remote Only Signalling. . . . . . . . . . . . . . . . 15 8. AAA Support for Nested MIP. . . . . . . . . . . . . . . . . . . . . 15 8.1. FA AAA Requests. . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. RA AAA Requests. . . . . . . . . . . . . . . . . . . . . . . . 17 9. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations. . . . . . . . . . . . . . . . . . . . . . 18 11. Notice Regarding Intellectual Property Rights. . . . . . . . . . . 18 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Regional Registration provides a mechanism for MIPv4 to localise registrations. The MN initially registers to the HA via the GFA so that the HA can learn the GFA CoA. The MN can then subsequently use a Regional Registration to maintain the binding in the GFA as the MN moves and changes its FA CoA or CCoA. It can continue to do so whilst a MN remains under the GFA through which the MN sent the Home Registration. The GFA performs CoA switching between that of the GFA CoA and that used by the MN. Whilst the regional registration provides localisation, it does not at the same time provide registration aggregation for MNs employing multiple HoAs. The ability to concurrently support multiple MN addresses from arbitrary addressing domains is a 3GPP commercial and technical requirement and therefore of interest to operators seeking to move to an all-IP solution based on MIP. A.W. O'Neill Expires Oct 2002 [Page 2]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 This draft describes a complementary model less stateful model for localization that in addition supports aggregation both for regional-like registration and hand-offs. The model re-uses as much as possible from the home registration signalling model of [RegTun] but requires a new form of regional registration. The required modifications to [RegTun] are described in [RegTunMods] and focus on generalising the GFAIPext and the HFAext in the home registration so that it can used across multiple addressing domains and for non-GFA intermediate MIP nodes. The modifications also ensure that the MN can be dynamically allocated an intermediate CoA by the intermediate MIP node as well as being allocated a dynamic HA by the AAA system. These modifications are then exploited in this draft to enable the MN to be assigned a local HA that also then acts as a regional MIP node. The local HA works in unison with any global HAs to provide local and or remote internet access services for the MN. The remote access MIP layer is nested within the local access MIP layer by using the local RoA as a CCoA for the global HoAs, as well as a source / destination address for local access traffic. The nesting results in a second layer of encapsulation between the local HA and the FA, in addition to the remote access encapsulation between the global HA and the MN. The benefit though is that as the local HoA visitor list for the RoA is updated with each new FA CoA, an arbitrary number of remote access HoA specific flows, encapsulated within the RoA, are automatically redirected to the new FA without requiring additional MIP signalling or visitor list changes. Other benefits include the localisation of regional signalling, and clean separation between local and global concerns wrt security, addressing plans, MIP forwarding models, privacy and AAA. Similarly, during hand-off, a BU to the old FA for the RoA can enable aggregated inter-FA forwarding for a multitude of HoA flows using that RoA. Whilst the allocation of both a local and remote MIP home address places additional burden on the IPv4 address space, this can be mitigated through the use of private addresses in either or both the local and remote access layers due to the clean separation of the layers that the model provides. The model also supports the use of MIPv4 and MIPv6 in the two layers and so provides a useful migration tool as well as operator independence in terms of transition. 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 and uses the following additional terminology. A.W. O'Neill Expires Oct 2002 [Page 3]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 Local Access service - Internet access using a topologically local address Remote Access service - Internet access using a topologically remote address Regional Mobility Agent (RMA) - regional node supporting at least local HA Regional Address (RoA) - A HoA-like address from the RMA based local HA function RMA Region - the set of FAs able to allocate that RMA to a MN LA/RA MIP - Local/Remote Access MIP functionality between the MN and the RMA/HA LA visitor list - the MIP visitor list for the RoA / RMA RA visitor list - the MIP visitor list for the CCoA / HA 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 signalling layer LA/RA MIP Reg - An MIP Reg in the LA/RA layer to the RMA/HA. Inter-FA Hand-off - a HO between two FAs that updates the FA CoA in the RMA. Inter-RMA Hand-off - a HO between two RMAs that results in a RoA change HFAIPext - the HFA IP address extension (generalization of GFAIPext) 4. Motivation Traditional Internet Local Access (LA) assigns to a host a topologically correct local address for the duration of a Local Access session. The movement of the host across different access technologies or optionally for different sessions on the same access technology, results in the Mobile Host acquiring different addresses for each Local Access session. MIP has historically provided a Remote Access (RA) service whereby a MN can roam with a remote address from a home subnet onto a foreign subnet, by hiding that address within an encapsulation using a local Care of Address from the Local Access provider. If a Co-located Care of Address (CCoA) is assigned by the local access provider, then the MN can use that address for MIP Remote Access, or alternatively use that address for PPTP and/or IPSec remote access (IPSRA) tunnelling. MIP has more recently been targeted at wireless deployment scenarios where MIP is used to provide remote access from a wireless provider to a service domain such as a corporate, content or application provider or ISP. For this model, MIP has been extended to support hand-off between FAs as the MN moves during an access session. Herein lies a conflict though because the hand-off is primarily local mobility management but is coupled to a remote access MIP Registration/Reply exchange. If the remote access provider is the same as the wireless provider then the remote access HA, and the intermediate networking via the FA, can be designed and dimensioned to provide the required levels of availability and reliability for the hand-off. If this is not done then local mobility management can be compromised, through the slow response or unavailability of the HA, generating the potential for chaining of inter-FA forwarding tunnels. If the remote access and wireless providers are different, then the performance of the wireless operators local mobility management is dependent on a third party, which represents unacceptable commercial coupling. This provides the motivation for regional registration and tunnelling in [RegTun] and is also one motivation for our own complimentary solution to localization. If we then look further into commercial requirements, the design of 3GPP systems mandates the concurrent support in the handset and network for multiple addresses from third party domains, from which services are consumed. A.W. O'Neill Expires Oct 2002 [Page 4]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 Examples of such domains are corporate networks, content and application stub networks, as well as full ISPs that may be aligned with, or commercially distinct from, the wireless operator. The concurrent address support allows a user for example to have connectivity with its local ISP for Internet Local Access, with a remote corporate network for business e-mail (Remote Access 1) whilst in addition receiving a news feed from a subscription based financial information provider network (Remote Access 2). These are also requirements common to other broadband Internet systems. A MIP based system should therefore be able to efficiently deal with multiple concurrent HoAs. In 3G networks, the hand-off of the radio bearers for each MN uses a single aggregated signalling phase for all the packet data protocol sessions (PDPcontexts) up to the RAN Controller. However, hand-off between GPRS Support Nodes (eg SGSNs where the MN potentially has Generic Tunnelling Protocol (GTP) tunnels with multiple GGSNs), leads to multiple parallel signalling phases, although each GTP tunnel can still itself move multiple PDPcontexts within that tunnel. Returning to the situation with an all-IP based solution based on MIP, each concurrent address (each HoA) implies a distinct Remote Access MIP session (cf GTP), back to each independent addressing domain. The movement of the MN then requires the update of each distinct HA/HoA with the new CoA of the MN. This translates into multiple MIP Registrations from the MN to/from each HA, along with multiple inter-FA hand- off exchanges. Even when Regional Tunnelling [RegTun] is deployed, each regional registration is HoA specific and therefore multiple parallel MIP signalling phases are still required both to the GFA and to the previous FA. Just as in the case of 3G, there is a need in an MIP local mobility management system for aggregated hand-off as well as localized hand-off to a regional MIP element. In addition, there is also a need, following sufficient MN movement, for the regional hand-off of each remote access session between regional MIP elements that can be considered to be equivalent in some ways to the SGSN. Whilst [RegTun] does support GFA hand-off it does not do so (new home registration) in a way which preserves in-flight traffic between the HA and the old GFA, by failing to reroute traffic already present at the old GFA to the new GFA. [ParallelMIP] describes a backwards compatible approach to extend inter-FA and GFA signalling to support aggregation whilst [RMAsig] describes an architecture for supporting hand-off between regional elements whilst preserving in-flight traffic. Finally, another key commercial requirement is to be able to support Local Access in conjunction with Remote Access, each with distinct policy controls. This is because Local Access is a commodity service and many service providers would not wish to incur the expense of routing all customer traffic (ie local and remote access) via their remote third party value-adding service networks. They are only interested primarily in value-added traffic flows. This is also true in corporate networks where only Intranet traffic may wish to be routed to the corporate stub network whilst external Internet access may be provided in the local vicinity of the access connection. In addition, wireless operators would not wish to lose the ability to offer ISPs services whilst at the same time wishing to support third party value-added content and applications on their networks. This is not a universal situation and so the local operator MIP solution needs to be able to flexibly handle various combinations of local and remote access service and associated MN specific traffic privileges. A.W. O'Neill Expires Oct 2002 [Page 5]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 Local Access is possible within the existing Remote Access MIP model in three main ways. Firstly the MN can acquire a CCoA at the FA and use this as a source address for local traffic whilst using the CCoA as the binding for the remote access layer. The problem here though is that if the MN then moves from the FA then the local access address and the HA binding immediately becomes invalid, and associated address allocation delays is the reason that the use of the CCoA as a source address is constrained in MIPv4. The second alternative is to use the HoA as a source address (not reverse tunnelling) but this requires the foreign FA and domain to not undertake ingress filtering, and still results in dog-leg routing for the return traffic via the remote access HA. The third option is to use a second parallel MIP 'remote' access session with a local HA to generate local access in parallel with a truly remote access session to a global HA. However, this once again leads to additional MIP signalling and processing load further demonstrating the need for aggregated hand-off. Clearly, none of these are in any way optimal and a better solution needs to be found for supporting local access in MIPv4 that can survive hand-off and ingress filtering checks. These limitations in existing technology have motivated the design of two additional regional mechanisms, each of which can co-exist if necessary with [RegTun] in the Internet, each of which is optimal for a subset of the all-IP mobility requirements. This draft deals with Nested MIP whilst a subsequent draft [ConcatMIP] deals with Concatenated MIP. 5. Basic Nested MIPv4 Design The above limitations can be avoided through the use of two distinct MIP access layers, where potentially multiple Remote Access sessions are supported in the Remote Access layer, all running over the single Local Access MIP session in the Local Access layer. The forwarding is shown in figure 1. The LA layer runs between the MN and a Regional Mobility Agent (RMA) that provides the MN with a Regional Address (RoA- a la HoA). The RMA in this case acts like a regional HA and the RoA like a regional HoA. The FA allocates a topologically close RMA to the MN by selecting one RMA from a configured or discovered set of available RMAs. Availability can simplistically for example be determined from previous successful and failed MIP Reg/Reps from MNs to RMAs. A choice of RMAs is useful to enable load-sharing and to improve availability. The FA can then use dynamic MIP address allocation to acquire the RoA from the assigned RMA. The RoA can satisfy ingress filtering at least within the region of that RMA, and certainly within the domain, and the RoA will obviously survive hand-off between FAs beneath the same RMA because the LA MIP Registrations will update the evolving FA CoA. The topological closeness of the RMA means that the dog-leg routing for that RoA address is of little concern from a latency, QoS or reachability perspective. As the MN moves, then the binding between the RoA and the MNs current LA CoA is updated using standard MIP Registrations with hand-off extensions as detailed in [RoutOpt] and/or [LowLat]. LA MIP enables a MN to use either a CCoA or FA CoA for this Registration, but in the basic MIPv4 design this is a FA CoA. The MN can, in addition, continue to use an RMA after it moves into legacy regions that lack their own RMA. It does this by continuing to send LA MIP Registrations, from the external FA to the RMA, although there are known additional constraints with what is likely to be an inter-domain hand-off. A.W. O'Neill Expires Oct 2002 [Page 6]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 Regional inter-RMA hand-off is however preferred, as is described in [RMAsig], because continuing to use a non-local RMA comes at the cost of increasing dog-leg routing which compromises much of the motivation for the deployment of an RMA. This localised MIP capability is known as the Local Access MIP layer (LA MIP), which effectively provides localised mobility management as well as optionally providing Local Access services. For Local Access service, the MN simply uses the RoA from the RMA as an interface address and hence as a source and destination address for packets. Downlink (forward) packets are routed to the RMA where they are encapsulated into the present FA CoA for the MN. The RoA is therefore valid within the region of the RMA as it can survive a number of inter-FA hand-offs through the LA MIP hand-off signalling. If the MN wishes to also/alternatively invoke Remote Access, then the RoA can be used as a global CCoA by the Remote Access MIP layer (RA MIP). The RoA is included in the RA MIP Registrations to each global HA, as the CCoA for each of the HoAs. The Remote Access sessions are effectively nested within the LA MIP layer. Forwarding between each CN and the MN is first to the global HA which encapsulates into the CCoA=RoA. This is then forwarded to the RMA from whose subnet the RoA was obtained. The RMA then encapsulates these packets into the present FA CoA for the RoA that is being maintained by the local access MIP Registrations. The FA then decapsulates from the FA CoA and forwards the CCoA addressed packets to the MN. This generates one tunnel from HA to MN/RoA and one from RMA to FA/CoA). The impact of the tunnel over the air-interface can be minimised using header compression or alternatively through the use of Proxy Co-located Care of Addresses [PCCoA]. This overhead is however never more than that already accepted for MIPv6. CN HA RMA FA MN Forward LA CN------------------------------------------------>RoA RMA=====>FACoA Reverse LA CN<------------------------------------------------RoA RevTun 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 traffic in Nested MIP A.W. O'Neill Expires Oct 2002 [Page 7]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 The Local Access session uses the RoA for forwarding. The Remote Access sessions also use the RoA, but as a global CCoA. This ensures that the LA MIP registration updates for the RoA, as the MN moves in the local routed topology, can affect and correctly redirect all ongoing access (local and Remote) sessions, using a single hand-off message sequence. The LA MIP layer therefore provides both localization of hand-off signalling to the RMA, and aggregation of hand-off for an arbitrary number of Remote Access sessions using HoAs from arbitrarily located global HAs. Specifically, in the case of a smooth hand-off [RoutOpt], a single LA MIP Registration to the RMA, and a single triggered BU from the new FA to the old FA is all that is required to provide mobility management for an arbitrary number of MIP access sessions on the RoA. LA MIP hand-off will in addition automatically support PPTP and IPSEC based (IPSRA) remote access tunnels that use the RoA as a tunnel end- point. The basic model is clearly deployable with little impact on MIP standards. The Remote Access service, whether based on MIP, PPTP, IPSRA or any other VPN technique, is effectively invisible to the local mobility management system (LA MIP) and the host simply needs to observe the allocation of the RoA as an interface address, and then use that address as it sees fit. This is because neither IPSRA nor PPTP interact with the MIP elements, and the RA MIP registration in the basic design is direct between the MN and the Remote Access global HA. However, the host must also be able react to interface address (RoA) reconfigurations that it would observe during an RMA change. Clearly, the larger the RMA region, then the lower the likelihood that an RMA change would interfere with ongoing PPTP and/or IPSRA sessions whilst irrespective of region size the RA MIP layer would simply issue an updated Home Registration back to the HA. 5.1. Regional Tunnelling Implications The GFA in [RegTun] is a gateway element at the top of a visited domain, beneath which can reside an arbitrary number of Regional Foreign Agents. CoA switching is then used between the elements to support both forward and reverse tunnelling, with the reverse tunnel source CoA having to match the forward tunnel destination CoA. The basic RMA is also a regional element but its functionality is equivalent neither to that of a GFA or an RFA. For example, the RMA forwards like a HA by encapsulating incoming packets to the RoA with the FA CoA registered by the local access layer. The RMA is traversed in the forward path as a result of routing towards the RoA rather than as a direct result of CoA switching. In the reverse direction, the RMA does not need to be traversed whilst the RFAs and GFA must be. Given that the Nested forwarding is based on routing rather than on tunnel switching, the Nested RMA is less stateful and more ameniable to fall-over recovery. Routing prefix from RMAs for the same RMA prefixes can be weighted so that the RoA traffic can be served by alternate RMAs, on an RMA failure, without requiring a change in the HA binding. The local RMAs can then duplicate registration information so that fast recovery is possible. Ingress filtering is performed by the FA and the FA may know the regional prefixes supported by the RMA which includes the assigned RoA. Specifically though, the FA discovers the RoA at the LA layer and uses this to update the ingress filtering to prevent unassigned RoAs being employed by an attacker. A.W. O'Neill Expires Oct 2002 [Page 8]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 This is reasonable because the FA and RMA are owned by the same operator and are mutually trusted. It is perfectly possible, whilst not necessarily advisable, that a GFA and a RMA could be used together in a domain, with the GFA sitting in the RA layer between the global HA and the RMA. The GFA would use the RoA as a CCoA in its visitor list for the HoA, whilst the HA would use the GFA CoA. Alternatively, a closer integration is preferred with the RMA supporting alternative forwarding functionality for different groups of MNs consuming a range of services, and specifically providing GFA support for backwards compatibility with any deployed MNs requiring that service. As an example, for MNs that are only able to use a single RA MIP session and do not require local access, CoA switching might be a better solution than Nested as there is clearly no need for aggregated hand-off or the RoA. This is dealt with in more detail in [ConcatMIP] and some of the required generalisations in the Regional Tunnelling signalling are described in [RegTunMods]. 5.2. Reverse Tunnelling Implications Reverse tunnelling (upstream) requires the source address in the encapsulating header to match the registered CoA in the receiving nodes visitor list that is used to tunnel forward packets (downstream) for the HoA as a source address. This means that the downstream MIP element must encapsulate using the CoA that it sent to the upstream node in the MIP Registration, at any point in the reverse tunnelling hierarchy. The implications of this restriction on local hand-off, is described in [RevTunMods], which suggests modifications to HAs, GFAs, RFAs and FAs in [MIPv4] and [RegTun] to better support reverse tunnels during inter-FA hand- off. Nested MIP greatly reduces the problem for RA reverse tunnelling because the MN encapsulates from the RoA to the HA which is valid across multiple inter- FA hand-offs under the same RMA. Therefore, the [RevTunMods] are only required when the RoA changes which is a much less frequent event. In addition, the localization provided by [RegTun] requires [RevTunMods] to be supported in the GFA but are not required in the basic RMA because the MN tunnels directly to the HA and not via the RMA. Nested MIP therefore greatly simplifies and improves reverse tunnel support for Remote Access services. Nested MIP in the reverse direction only requires a tunnel between the MN and the HA so the improved reverse tunnel support does not come at the expense of reduced bandwidth efficiency in this case. Reverse tunnelling is also optionally supported in the LA layer between the FA and the RMA. This can be used to route Local Access and Remote Access packets, from the RoA back to the RMA, using a second local encapsulation. This can be used to ensure traversal through an RMA based NAT or firewall. It can also be used to expose the outbound packets to an RMA based policing, accounting or QoS capability, or any other RoA specific processing. This capability can also be undertaken selectively for Local Access or Remote Access traffic by modifying the FA visitor list such that reverse tunnelling happens in the LA layer only, RA layer only, or both LA and RA layer. This can then reverse tunnel unencapsulated packets (Local Access only), encapsulated packets (all Remote Access), or encapsulated packets from a specific Remote Access session (HA/HoA specific). A.W. O'Neill Expires Oct 2002 [Page 9]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 5.3. Private addressing Implications 5.3.1 LA Private Addresses The RMA and FA are by definition within the same domain and are closely linked by configuration and topology. The RMA and FA can therefore communicate using private addresses. The RMA and the associated RoA are both dynamically allocated and therefore the RoA could be either a public or private address. The MIP Registration must therefore carry sufficient information to enable the RMA to dynamically allocate private and public addresses in a controlled manner which would typically be either an MIP flag or an extension type. If Local Access only is requested by, or provided to, the MN then it is fully acceptable for the RoA to be a private address and for a NAT to be deployed in the domain to translate this address into public address space. This capability is equivalent to NAT usage by existing fixed access ISPs and because the NAT is not between the RMA and the FA, then MIP NAT traversal is not required [MIPNAT]. If the MN tries to use a private RoA address as a CCoA in any RA MIP Registrations then these registrations will pass through a NAT in the foreign domain but will clearly fail. This provides a simple method for an operator to prevent a MN from undertaking Remote Access services to external networks, whether based on MIP, PPTP or IPSRA. If Remote Access only, or Local and Remote Access is provided to the MN then the RoA provided to the MN can still be a private address if MIP NAT traversal [MIPNAT] is supported for this MN. This requires the global HA, the NAT and the MN to support an additional UDP and MIP header in the CCoA based tunnel. Note that the packets do not need to traverse the RMA in the uplink direction. If the MN is dynamically allocated a public RoA address, then Internet Local Access can pass-through or bypass the NATs in the domain. In addition, the public RoA can now be included in RA MIP Registrations and they will succeed without requiring [MIPNAT] capabilities. In all cases, the private or public RoA forwarding in the RMA and FA is unambiguous because by definition these addresses are always unique in the RMA and FA provided that the RMA does not accept LA MIP Registrations from FAs using private addresses from outside its private addressing domain (typically inter-domain LA MIP Registrations). 5.3.2 RA Private Addresses The standard MIP RA layer acts to hide the HoA destination address at the home network, from the Internet routing fabric, using a tunnel from the HA to the FA CoA. The HoA can therefore be either a public or a private address in principle. There are significant complications however with overlapping address spaces in the FA if the visitor list is indexed on a private HoA. This is because the HoA is not guaranteed to be unique because MNs from two different but overlapping private addressing domains can visit the same FA with the same HoA. A.W. O'Neill Expires Oct 2002 [Page 10]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 The nested model resolves this ambiguity because the basic forwarding in the RMA and FA is based on the RoA which is guaranteed to be unique, and not the potentially ambiguous HoA. HoA specific processing in the RMA and FA elements can still be supported however because the visitor list entry can still be assured to be unique through concatenation of the RoA and HoA. Therefore private HoAs can now be fully supported in the RA layer of the Nested MIP model. This is true whether the RoA is itself public or private. The use of a private address for the HA is limited by the addressing plan between the RMA and the HA. RA MIP Registrations/Replies must be routable to and from the HA, forward tunnels must be routable from the HA address to the RoA, and reverse tunnels must be routable from the RoA to the RMA (LA reverse tunnel) or from the RoA to the HA (RA reverse tunnel. The existence of a NAT between a private RoA and a public HA address can still support Remote Access through deployment of [MIPNAT]. The HA itself can also use a private address in conjunction with a private RoA as long as they are both from coordinated and routable private address spaces. 5.4 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. 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. Basic Nested MIPv4 Signalling Description The two MIP layers in the Nested model are clearly separable in the basic model because one layer is between the MN and the HA whilst the other is between the MN, the FA and the RMA. There are therefore essential no changes required to existing MIP standards to support Nested MIP, provided that the LA MIP layer is hidden from the MN host stack and exposed to that MN simply as an RoA interface address. The RA layer does not need to see a FA nor use Agent Solicitations or Advertisements. The RA layer simply needs to respond to interface address changes, on RMA hand-off (RoA change) by refreshing its bindings with the new (RoA) interface address. The LA MIP layer can then operate between a network driver and/or PCMCIA card on the host and the FA/RMA nodes, with the FAA seen by the network driver to detect and control FA CoA based access, with hand-off extensions to deal with FA changes. The FAA must indicate to the network driver the current FA address, RMA address and/or region NAI so that the network driver knows when to undertake an inter-FA and inter-RMA hand-off using LA MIP signalling. This model ensures that local mobility management is not dependent on the vagaries of host implementations but are instead under tight operator control. A.W. O'Neill Expires Oct 2002 [Page 11]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 The LA MIP signalling for inter-RMA hand-off requires similar extensions to those required for [RegTun] home registration which are discussed in [RMAsig]. Note also that it is possible for the LA layer to run between a hub and the RMA, to support multiple RA sessions for MNs sharing the RoA and the wireless link on the hub. This is again discussed in [RMAsig]. The clean separation between the layers is lost is lost if the LA layer is exposed to the host resulting in the need for host RA layer MIP changes. It is also lost if the RA MIP layer, due to alternative implementation decisions requires FAA support, and/or the RA MIP signalling is processed by the FA or the RMA. These changes are described in section 7 and [RMAsig]. 6.1 Local Access Only Signalling The FA advertises its capabilities to the MN using the FA advertisement (FAA) that contains a FA CoA as per [MIPv4]. The MN sends a LA MIP Registration via the FA with the CoA set to the advertised FA CoA, and including the MN-NAI as per RFC 2794 to download MN privileges, and security state as in [MIPAAA] from the home operator via the foreign operator. The LA MIP Reg HA/HoA fields are left empty by the MN to enable dynamic allocation of an RMA in the FA, and the subsequent dynamic allocation of a RoA by that RMA. Note that LA layer and RA layer Registrations need to be distinguished in the FA by using different type values, flags or extensions which is discussed further in [RMAsig]. The FA forwards the LA MIP Reg to the allocated RMA, which then acts like a local HA by dynamically allocating an RoA to the MN. The RMA then sends an LA MIP Reply to the MN via the FA, with the HA and HoA fields now populated, and containing any RMA derived security state, so that the FA and MN can be correctly initialized. The MN then has Internet local access enabled and uses the RoA as a topologically correct source / destination address. The relative role of the AAA system, the FA and the RMA in securing the LA layer can be achieved a number of ways including mechanisms defined in [MIPAAA] and referenced by [RegTun]. Remote access can potentially be prevented, by the FA blocking MIP Registrations not addressed to the allocated RMA or by appropriate blocking of data packets in an FA or RMA 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. 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 unencapsulated packets to/from the RoA, other than those necessary for LA/RA MIP signalling. The MN then sends an RA MIP Reg directly to the statically allocated HA and HoA stored in the MN, using the RoA as the CoA and setting the 'D' bit to indicate that the CoA is a CCoA. The MN can include its MN-NAI that it used in the local access registration if it wishes but this will only be observed by the HA. If successful, remote access is then enabled and the remote access service survives inter-FA hand-off through the local access mobility management. The MN receives packets from the HA encapsulated in the RoA. The MN can send RA packets using either the HoA as a source address and risk ingress filtering, or more likely by reverse tunnelling to the HA if it set the 'T' bit (reverse tunnelling) in the RA MIP registration. A.W. O'Neill Expires Oct 2002 [Page 12]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 Reverse tunnelling just to the RMA is also possible, if the RA Reg is sent via the RMA, so that HoA state can be stored and ingress checks can be reasonably undertaken without compromising hand-off aggregation. The MN privileges might also indicate that only a specific remote access registration is allowed based on specific HA and/or HoA state. The FA and/or RMA could then block encapsulated packets sent from/to addresses other than the permitted HA/HoA parameters. However, this form of remote access control is better supported if the RA MIP Registration is directed through and policed by the FA and / or RMA, rather than blocking traffic flow, as discussed in section 7. 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. Once again local access can be provided in addition to a specific remote access service as indicated by the MN privileges. 7. Enhanced Remote Access Registration The Remote access signalling as described in the basic model is between the MN and the HA. This means that neither the FA nor the RMA are directly able to determine or affect the HoA or HA being used for the remote access session(s). The RA MIP signalling can alternatively be routed via the FA or RMA, which results in modifications/extensions to the FA and RMA (HA) visitor lists. This is because the clean separation between the LA and RA layers is now lost. These issues are examined below. 7.1 RA MIP Registration via the FA The RA MIP Registration can be routed via the FA by the FA setting the 'R' bit in the FAA, and exposing the FAA directly to the RA MIP layer. Alternatively, the RA MIP host stack can be made aware of the FA address by the LA MIP layer acting as either a virtual FA or by relaying a modified FAA. Most importantly, for correct movement and hand-off processing, it is critical that the RA MIP layer is only exposed to RMA changes. MNs then wishing to continue to bypass the FA will do so at the risk of having their RA MIP Reg, or the resulting remote access traffic dropped by the FA. The FA can police such RA MIP Regs using firewall rules, and a remote access HoA aware visitor list can police the resulting traffic. If instead, the MN sends its RA MIP Registrations to the FA, then the FA will extend the FA RoA specific visitor list with the RA MIP state for the RA MIP layer. The RA MIP Reg will then forward the Reg to the HA as normal. The message routing is already covered by existing MIP standards and is not further discussed here, but the convergence of the LA MIP and RA MIP visitor lists is an obvious change. Also provided in existing standards, but an addition compared to section 5, is that the MN can now potentially exploit the AAA system to obtain a dynamically allocated HA. This is discussed in section 8. A.W. O'Neill Expires Oct 2002 [Page 13]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 The additions to standard MIP are that these remote access requests should be checked against the LA visitor list and the MN privileges delivered to the FA by the AAA system. The FA must only accept RA MIP Regs for RoAs that are in the LA visitor list, for HAs and RA MIP flags that are permitted by the MN privileges. In addition, the FA can supplement the local access visitor list with a HA/HoA specific RA visitor list to support HA/HoA specific processing for both remote access registrations and the resulting traffic. HoA specific processing however requires the HoA state to be context transferred in an aggregated manner between FAs during FA hand-off, triggered by a single inter-FA hand-off message such as the BU. Each LA MIP visitor list can have multiple RA MIP visitor lists, and the combination of the RoA and the HoA can be used to identify a specific RA visitor list to correctly support private addresses. Other than this, both RA and LA visitor lists are fully compliant standard MIP entities with there own lifetimes, identification fields and MIP flags. A more fully integrated implementation of the multiple visitor lists is possible. 7.2 RA MIP Registration via the FA and RMA. The RA MIP Registration can also be onward directed to the RMA by re-using the MIP Registration extensions from [RegTun] and from [RegTunMods]. This enables HA/HoA specific processing to also be added to the RMA such as policing, accounting and QoS support. This is useful because it enables out of profile packets to be removed before traversing expensive backhaul bandwidth to the basestation, it enables appropriate accounting state to be more centrally located in high-availability platforms that are shielded from the highest hand-off dynamics and finally enables the RMA to undertake HoA specific QoS mechanisms. This is all possible because the FA is aware of the RMA address from the local access layer. The FA directs remote access requests onto the allocated RMA so that the RMA can discover any configured or allocated HA/HoA addresses and the associated MIP flags. The RMA can then build and maintain an RA visitor list for that HA/HoA, in addition to the LA visitor list for the RoA. The RMA can then support HA/HoA specific processing The RA MIP includes the RoA as the CCoA for the HoA, as it already knows the RoA allocated to the MN by the RMA, from the LA MIP signalling. If the MN has a pre-configured HA and /or HoA then these can also be included otherwise they are set to zero and the HA obtained from the MN privileges. The FA adds the FA CoA into the HFAext and sends this to the RMA, secured by the FA- HA(RMA) authentication extension. The FA can also add the HFAIPext to communicate any dynamically allocated HA to the RMA as described in [RegTunMods]. The RMA then forwards the RA Registration to the HA address contained in the HFAIPext received from the FA. This can be secured by an RMA-HA auth extension to protect any RMA-HA extensions, with the security state to support this being delivered to the FA by the AAAH-AAAF path and relayed to the RMA, or delivered directly to the RMA by the AAAF either as a result of an RMA request or pushed (Diameter) from the AAA system. The RMA uses the HFAext from the FA, and the CCoA=RoA to index and refresh the LA visitor list, and the HA/HoA information is used to install an RA visitor list bound to the LA list, awaiting if necessary the return of any dynamically allocated HoA information. The RMA then forwards the RA Registration to the HA address contained in the HFAIPext received from the FA. The HA then allocates the HoA and the MIP Reply contains both the HA and the HoA to update all visitor lists on the Reply path. A.W. O'Neill Expires Oct 2002 [Page 14]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 7.3 Efficient Remote Access Only Signalling The signalling examples in section 6.2 and 6.3 can now be undertaken more efficiently in cases that the RA MIP Registration visits both the FA and the RMA. This is achieved by integrating the LA update into each RA MIP signalling phase, and only otherwise using LA only signalling for inter-FA hand-off. As before, the FAA advertises the FA CoA and the MN sends an RA MIP Reg to the FA containing the MN-NAI. The HA is set to either zero or to the static HA of the MN and the HoA is set to either zero or to the static HoA of the MN. The CoA is also set to zero because the RoA has not yet been allocated. The 'I' bit in the FAA should indicate support for a zero CoA. The MN-NAI is used to obtain the MN privileges and to dynamically allocate a HA if required from the home AAA system. The FA allocates an RMA as before and forwards this registration to that RMA along with the HFAext containing the FA CoA, and the HFAIPext containing the address of a dynamically allocated HA. The RMA consumes both of these extensions and then creates a new HFAext containing the RMA CoA=RoA for the HA. These are then both added to the original Registration Request and sent to the HA. The Registration Reply is then returned via the RMA containing the HA and the dynamically allocated HoA. It is then sent to the FA which adds any dynamically allocated RMA IP address in a HFAIPext, and finally onto the MN, The HA does not need to include the HFAIPext back to the MN because the MN is registering via the FA. The RMA must however add the HFAext to the Reply to carry the RoA back to the FA, which forwards it to the MN. This results in all nodes discovering all the state normally built by the combination of the LA and RA MIP layers. This state is then maintained by the LA MIP layer undertaking mobility management, and the RA MIP layer refreshing the HoA visitor lists in the RMA and HA. 8. AAA Support for Nested MIP The following sections detail some additional optional mechanisms within, and hence requirements for, AAA systems supporting the Basic Nested MIP model. 8.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 LA MIP 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. The LA-NAI effectively uses the AAA system to support MN access into a wireless network. When that wireless network belongs to a foreign wireless operator then the MN is undertaking wireless roaming whether from a home wireless operator or a home fixed operator. In the context of Nested MIP, the MN privileges obtained via the LA-NAI can include configuration for local access, for remote access back to the home network, and additional remote access configurations for services either provided by the home operator or by third parties who outsource wireless roaming support to the home operator. A.W. O'Neill Expires Oct 2002 [Page 15]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 The FA AAA request can enable the global HA to be dynamically allocated through the AAA system, and the RoA either dynamically allocated through MIP signalling or by the AAA system. The AAA system can similarly support the delivery of the RMA and RoA. In either case, the AAA system needs to be able to control whether the MN gets a public or private HoA/RoA address and also means that MIP must also be able to request either type of address on behalf of AAA delivered MN privileges. The AAA system can also be used to deliver and refresh the MN-FA, MN-RMA, MN-HA, FA-RMA, FA-HA and RMA-HA SAs to/for the FA and the other elements in the system, in conjunction with complementary deliveries to the RMA and HA. Following completion of the initial LA MIP AAA exchanges, the MN is then in a position to additionally initiate RA MIP Regs. If a RA MIP Reg is routed via the FA and includes either no LA-NAI, or the same LA-NAI as that included in the LA MIP Registration, then the RA MIP Reg should be checked against the LA MN privileges already delivered by the AAA system to the FA, as agreed for roaming between the home and foreign operators. However, there is then an additional AAA requirement for a MN to be able to initiate RA MIP to third party services whose operators either have no commercial relationship with the home network operator of the MN, or do not wish to share customer configuration information with that home network operator for such services. In this case the RA MIP Registration could include a service specific RA-NAI which would cause the FA to trigger a second AAA request via the foreign operator AAA server to the AAA server of the third party service provider, effectively bypassing the MN home operator AAA system. This enables the FA (and foreign operator) to acquire the RA MN privileges from that RA service provider, which then supplements or supplants the LA MN privileges. This enables service specific policing, routing and QoS features to be provided to specific remote access flows, as well as ensuring that the accounting records are delivered to the service provider rather than to the home network operator. This therefore provides additional motivation for enabling HoA independent forwarding for remote access flows in general, whilst being able to add HoA specific features as required by more complex commercial models. This model also provides clean separation between the MN-NAI specific MN privileges provided by a specific AAA provider, from the remote access services that are accounted for under that authorization. Essentially, the MN can dynamically bind any of its MN-NAIs to a specific RA MIP session by including that MN-NAI in the RA MIP Reg. If the FA does not recognize the MN- NAI then the FA uses the AAA system to authenticate the user with the service provider, acquire the associated MN privileges, and commence accounting. If the associated MN privileges have already previously been fetched during a previous LA/RA MIP Reg, then a AAA request is not required. This flexibility can be constrained by the authenticator installing service specific state (HA address, application bounds etc) into the MN privileges. For each such MN- NAI, the MN and the foreign AAA server needs to have a unique security association with the service provider AAA system so that the MN can be authenticated, the MN privileges securely delivered, and the service accounting records protected. In summary, the MN can have multiple NAIs from a range of LA and RA providers. The MN can use one MN-NAI to configure the LA MIP payer of the foreign wireless network using AAA roaming from its home network operator. A.W. O'Neill Expires Oct 2002 [Page 16]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 That MN-NAI will have MN privileges for local access and potentially for remote access, and the home network operator is the authenticator for the MN, authorizes its access onto the foreign network, and is the ultimate recipient for the accounting records generated under that NAI. This LA-NAI is called the 'connectivityNAI'. Each RA MIP Reg can then also include a 'serviceNAI' to AAA each remote access session, and that NAI can be either the LA-NAI invoked to gain connectivity, or any other MN-NAI whose associated MN privileges support the remote access service requirements. MN privileges can be service independent or can include service state which limits them to specific types of remote access sessions. This layered approach flexibly provides home network and home service provider control over services invoked by the MN within a wide range of commercial models. Note that during LA hand-off it is necessary to transfer at least the active AAA configuration to the new FA. 8.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. This can be achieved three different ways, some of which depend on the RA MIP Regs being routed via the FA and / or RMA. Firstly, the preferred approach is for the foreign network AAA server to deliver the MN privileges in parallel to both the FA and the RMA(local HA) along with accounting configuration information. This requires the FA to include the RMA address or NAI in the AAA request, or for the AAA system to allocate that address. This model is similar to that envisaged for MIP AAA security associations and key distribution [MIPAAA] for FA, HA state distribution, although Diameter would most likely be a prerequisite. Alternatively, and especially when RA MIP Registrations are processed by the RMA, the RMA can undertake an additional AAA request to obtain the AAA state from the local AAA server. This only occurs after the FA has completed its AAA request and obtained the AAA state from the home AAA server but has the disadvantage of the AAA requests running sequentially although the second one can probably make use of cached state in the local AAA server. The third approach is to have the FA route the AAA request to the foreign AAA server via an RMA AAA proxy so that the RMA is on the path for the delivered AAA state. This also enables the RMA to decide which subset of the AAA state is delivered to the FA and puts in place a chain of command via the RMA so that it can undertake authentication and accounting processing for the MN and FA. The FA can then limit its AAA functions to those that must be placed in the edge device. This is beneficial because all AAA state in the FA must be context transferred on every FA hand-off, using expensive access backhaul bandwidth, whilst AAA state located in the RMA need only be context transfer on each RMA hand-off, and each transfer then consumes cheaper core bandwidth. The downside here though is that the RMA AAA proxy then needs to potentially process all AAA requests, many of which will not be MIP related. A.W. O'Neill Expires Oct 2002 [Page 17]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 9. IPv6 Considerations The Nested 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. 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. This is to ensure that each new MN CCoA does not need to be communicated to the HA. The RA 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. Nested MIP also provides clean separation between address spaces at the RA and LA layers which means that IPv6, IPv4, MIPv6 and MIPv4 can be variously combined to support evolution and incremental heterogeneous deployment. 10. 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. 11. 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). 12. Acknowledgements Michaela Vanderveen and Vincent Park of Flarion Technologies conducted reviews of this draft. A.W. O'Neill Expires Oct 2002 [Page 18]
INTERNET-DRAFT Nested MIP for IP Mobility Management May 2002 12. 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 [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. [PCCoA] A. O'Neill, "Proxy CCoA Tunnelling for Mobile IP", Internet-draft, draft-oneill-mip-proxyCCoA-00.txt, May 2002. [ParallelMIP] A. O'Neill, "Parallel MIP for Aggregated Mobility Management", Internet-draft, draft-oneill-mip-parallel-00.txt, May 2002. [ConcatMIP] A. O'Neill, "Concatenated MIP for Mobility Management", Internet- draft, draft-oneill-mip-concat-00.txt, May 2002. [RMAsig] A. O'Neill, "Regional Mobility Agent Signalling", Internet-draft, draft-oneill-mip-rmasig-00.txt, May 2002. [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 19]