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]