Personal A. O'Neill
Internet Draft Flarion Technologies
Document: draft-oneill-mip-regtun-mods-00.txt 9 April 2002
Expires: August 2002
Modifications to Regional Tunneling
<draft-oneill-mip-regtun-mods-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 modifies the normal MIP Registration signalling
back to the HA so that the signalling can traverse an intermediate
Gateway Foreign Agent (GFA). The registered binding is between the Home
Address (HoA) and the GFA Care-of Address (GFA-CoA) in the Home Agent
(HA), and between the GFA-CoA and the Foreign Agent (FA-CoA) in the GFA.
Two extensions are defined to support this new Registration processing
these being the Hierarchical Foreign Agent extension (HFAext) and the GFA
IP address extension (GFAIPext). The former is used to carry the FA CoA
to the GFA and the latter is used by the FA to allocate a GFA to the MN,
and by the FA, GFA, HA to securely return the GFA IP address to the MN.
The present processing rules for the HA registration enable the FA to
advertise the GFA to the MN in a Foreign Agent Advertisement (FAA) and
for the MN to include that GFA address into the CoA field of the MIP home
Registration. This however assumes a number of things about the GFA
address in the FAA and the addressing realms between the FA-GFA and GFA-
HA.. Specifically, the GFA CoA and the GFA IP address must potentially be
from two different addressing plans and hence cannot be in the same FAA.
This draft describes the issues and suggests a solution that requires
slight modifications to the required extensions, that generalises the
Home Registration signalling for arbitrary intermediate MIP nodes, and
only slightly modifies the processing rules for the MIP Home
Registration. This draft also describes a way to support dynamic HA
allocation along-side Regional Registrations.
A.W. O'Neill Expires Sept 2002 [Page 1]
INTERNET-DRAFT Modifications to Regional Tunneling 09 Apr 2002
INDEX
Abstract
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . . . . 4
3. Terminology used in this document . . . . . . . . . . . . . . . . . 4
4. Home Registration Modifications . . . . . . . . . . . . . . . . . . 4
4.1. GFA address. . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. HA address . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. GFA CoA. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Reverse Tunneling Implications . . . . . . . . . . . . . . . . 5
4.5. Naming Modifications . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Notice Regarding Intellectual Property Rights . . . . . . . . . . . 6
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The present processing rules for the HA registration in [RegTun] enable
the FA to advertise the GFA to the MN in a Foreign Agent Advertisement
(FAA) and for the MN to include that GFA address into the CoA field of
the MIP home Registration. In the case of a dynamically allocated GFA,
the MN instead leaves the CoA field blank so that the FA can dynamically
allocate a GFA and place the address into the GFAIPext extension. These
procedures however assume a number of things about the addressing plans,
the type of CoA used in the GFA, and the design of the GFA forwarding.
Specifically, the GFA address advertised in the FAA must be the GFA CoA
if that address is to be put into the CoA field by the MN. The GFA CoA
must be routable between the HA and the GFA. At the same time, the GFA
address known to the FA must be the address towards which the FA sends
MIP Registrations. This obviously requires the GFA address to be routable
between the FA and the GFA. If the two addressing and routing plans
either side of the GFA are different then it is impossible for the GFA
address advertised by the FAA to be both the GFA CoA and the GFA address
as defined above. The advertised GFA address cannot therefore safely be
placed into the MIP Reg CoA field.
HA1 ------Realm 1------------+
|
(CoA1)
HA2 ------Realm 2-----(CoA2)GFA-------Realm 2--------FA
A.W. O'Neill Expires Sept 2002 [Page 2]
INTERNET-DRAFT Modifications to Regional Tunneling 09 Apr 2002
One way to solve the problem would be to advertise independent addresses,
one as the GFA address reachable from the HA, and one as the GFA CoA
address reachable from the FA. The FA, however, must advertise the GFA
address in the FAA as this is required for GFA change detection (to
trigger a new home registration) and so there is no place for the GFA CoA
at present. Even if both addresses could be advertised, there are many
cases in which the FA could not know in advance of a GFA CoA that is
routable between the GFA and the HA. This is especially true if the GFA
uses a different addressing realm to communicate with different HAs, in
which case the FA will need to know the MN's HoA/NAI before it can
advertise the correct GFA CoA and even then it is not clear that the FA
can make the distinction successfully. Given that it is unlikely that the
MN could differentiate between these cases it is safer if the MN never
inserts the advertised address into the MIP Reg CoA field. As an example,
it is quite normal to use private address space for communication between
routers within the operator domain, whilst using public addresses for
user flows. This would imply that the GFA address required for the MIP
Registration signals between the FA and the GFA would likely be a private
address whilst the GFA CoA would likely to be a public address. Even
worse, if different interfaces on the GFA point to both public and/or
private networks and associated HAs, then the FA would need to have a
different GFA CoA for each different addressing/routing plan. It would
then have the impossible task of having to advertise the correct GFA CoA
to a MN in advance of seeing the associated Registration that would
define the required GFA interface.
Essentially, the FA is generally not in a position to advertise a valid
GFA CoA to the MN and therefore neither should it advertise such an
address nor should the MN insert that address into the MIP Reg CoA. This
also enables the GFA to always be in a position to dynamically allocate
the GFA CoA based on the MIP Registration information. This could be
because of different routings requiring different numbering plans, or
could alternatively be due to the GFA handing out different CoAs for
different traffic aggregates (VPN traffic, different QoS levels etc).
Further, the FA in [RegTun] already cannot advertise the GFA CoA to the
MN if the GFA is to be dynamically assigned at the time of the MIP Home
Registration. There is therefore already a reason for the MN to send a
blank CoA in the MIP home Reg, and a method, the GFAIPext, to communicate
the dynamically allocated GFA address to the other MIP elements to be
used as a GFA CoA. Once again, we have the GFA address or GFA CoA overlap
to resolve, the solution to which can at the same time enable the FA to
still dynamically allocate the GFA, the GFA to dynamically allocate the
GFA CoA, and both to communicate the right addresses to the other MIP
nodes.
Finally, there is no existing way for a dynamically allocated HA,
delivered to the FA by the AAA system, to be supported in [RegTun]. This
is because the FA does not presently have a way to inform the GFA of the
dynamically assigned HA address so that the GFA can onward forward to
that HA. This provides additional motivation for defining a general MIP
extension that can carry forward the address of a dynamically assigned
MIP element.
This draft suggests solutions to these problems that require minimal
changes to the required extensions, and that generalize the processing
rules for the MIP Home Registration.
A.W. O'Neill Expires Sept 2002 [Page 3]
INTERNET-DRAFT Modifications to Regional Tunneling 09 Apr 2002
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], Regional Tunneling [RegTun] and MIP Reverse Tunneling [RevTun].
The following introduces additional terminology.
GFA address - the address of the GFA as seen by the assigning FA or AAA
GFA CoA - the address of the GFA as seen by the Home Agent for the
Data path forwarding.
HAIPext - the address of the dynamically allocated Home Agent
HFAIPext - the HFA IP address extension for exchanging dynamically
allocated MIP element addresses.
4. Home Registration Modifications
4.1. GFA Address
The GFA address in the FA Advertisement to the MN must not be inserted by
the MN into the CoA field of an MIP Reg. This address can however still
be used to detect GFA changes and can also be used as the destination
address for an MIP CCoA Registration that is sent direct to the GFA.
The FA should not use the GFAIPext to communicate the GFA CoA of a
dynamically allocated GFA. This is so that the GFA has the freedom to
dynamically allocate the GFA CoA. The GFAIPext can be used by the FA to
carry the address of the dynamically allocated GFA to that GFA, to the HA
and back to the MN. However, the FA only needs to do this if the
allocated GFA address is different to the one advertised to the MN in the
FAA. The GFA can tell if the MN already knows the GFA address by the
absence of the GFAIPext. The GFAIPext is used also between the GFA and
the HA so that the dynamic GFA address can be returned, as in [RegTun],
to the MN to trigger appropriate Registration behaviour. The GFA IP
address is returned to the MN by the HA including the GFAIPext in the MIP
Registration Reply, secured by the HA-MN authentication extension.
4.2 HA Address
If the MN does not have a statically configured HA address then the FA
needs to obtain a dynamic HA for the MN, via the AAA system and based on
the MN-NAI, as described in RFC 2794. Now when the HA is delivered to the
FA it is necessary for the FA to communicate the HA address to the GFA so
that the GFA can send the registration on to that HA. The FA can do so by
sending a HAIPext to the GFA, formatted similarly to that of the
GFAIPext, and secured by the FA-FA auth extension. The HFAext does not
need to be forwarded to the HA and returned to the MN because the HA will
already be included in the Registration Reply along with the dynamically
allocated HoA.
A.W. O'Neill Expires Sept 2002 [Page 4]
INTERNET-DRAFT Modifications to Regional Tunneling 09 Apr 2002
4.3. GFA CoA
The HFAext in [RegTun] is presently employed by the FA to inform the GFA
of the FA CoA to be used when forwarding for a specific HoA. The HFAext
is protected by the FA-FA authentication extension in [RegTun].
Similarly, the HFAext, rather than the GFAIPext, should be used by the
GFA to communicate the GFA CoA to the HA. It does this by including the
HFAext in the MIP Registration to the HA, secured by the GFA-HA
authentication extension. The GFA consumes the HFAext from the FA that
contains the FA CoA, and replaces it with a HFAext with the assigned GFA
CoA. This enables the GFA to dynamically generate the CoA, it avoids the
FA needing to be aware of the addressing plan between the HA and the GFA,
and finally it enables the address in the GFAIPext and the HFAext to be
different.
The HA consumes the received HFAext, extracting the GFA CoA and inserting
it into the binding for the HoA. The MIP Reply is then returned with the
HFAext carrying the GFA CoA to the MN, protected by the MN-HA
authentication extension. The HFAext is required by the MN to enable it
to include the GFA CoA in MIP Registrations to the HA. The use of the
HFAext in this way provides a general signaling method for one MIP
element to inform another MIP element of the CoA to be used when
encapsulating and forwarding between those elements. The pair of elements
affected by the HFAext is identified by the inner most authentication
extension used to authenticate the HFAext.
4.4. Reverse Tunneling Implications
Reverse tunneling requires the source CoA in the encapsulating header to
match the binding in the receiving node. This means that the downstream
MIP element must encapsulate using the CoA that it sent to the upstream
node in the HFAext, at any point in the reverse tunneling hierarchy.
4.5. Naming Modifications
The HFAext, according to this draft, specifically carries a Care of
Address for the data plane. The HFAext is sufficiently general to enable
it to be used at any point within a MIP hierarchy. However the GFAIPext,
which is now suggested by this draft as carrying the GFA address rather
than the GFA CoA, has a name that binds it closely to a GFA intermediate
node, and the carriage of a GFA address. It cannot therefore be used to
carry the HA address to the GFA for example. A HFAIPext might
alternatively be a better name instead of GFAIPext which would enable
arbitrary nodes to exchange control plane IP addresses. The HFAIPext
would then provide a general method for a MIP node to inform another MIP
node of a dynamically allocated MIP node address. In the case of
[RegTun], the MIP node address is that of the GFA which is communicated
to the MN via the FA, GFA and HA. In the case of the HA address, it is
the FA that communicates it to the GFA. In the cases of both the HFAext
and the HFAIPext the nature of the enclosed address can be determined
from the authentication extension used to protect it, although a more
general model would be to state the address type and associated
processing in the extension itself through an address code.
A.W. O'Neill Expires Sept 2002 [Page 5]
INTERNET-DRAFT Modifications to Regional Tunneling 09 Apr 2002
This then leads to the use of a single type value for hierarchical CoAs
and hierarchical IP address carriage formatted as follows, where the
address code field then distinguishes address types such as GFA CoA, GFA
IP address, HA address etc...
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 | Address code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address .... | IP Address ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The home MIP Registration process then becomes general enough to be
applicable to registrations via arbitrary intermediate static/dynamically
allocated MIP nodes. The GFA specific signaling and naming is then more
appropriately limited to the Regional Registration messages between MN,
FA and the GFA, for the localization of the MIP hand-off and registration
refresh.
5. Security Considerations
No new security issues are raised by this draft than are already
considered in the design of [MIPv4], [RegTun] and [RevTun].
6. 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).
7. 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
[RevTun] G. Montenegro, Ed., "Reverse Tunneling for Mobile IP, revised,"
Internet RFC 3024, January 2001.
A.W. O'Neill Expires Sept 2002 [Page 6]
INTERNET-DRAFT Modifications to Regional Tunneling 09 Apr 2002
Author's Addresses
Alan O'Neill
Flarion Technologies
Phone: +1 908 947 7033
Email: oneill@flarion.com
A.W. O'Neill Expires Sept 2002 [Page 7]