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 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]