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