Personal A. O'Neill Internet Draft Flarion Technologies Document: draft-oneill-mip-proxyccoa-00.txt 8 May 2002 Expires: Oct 2002 Proxy CCoA Tunneling for Mobile IP <draft-oneill-mip-proxyccoa-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 In MIPv4, when a Mobile Node (MN) registers with the 'D' bit, in the MIP Registration to a Home Agent (HA), then the MN wishes to use a Co-located Care-of address (CCoA) with a specific Home Address (HoA). Packets sent to the MN Home Address (HoA) will then be encapsulated in the CCoA by the HA and forwarded directly to the MN. Alternatively, a MN can obtain from the local Foreign Agent(FA) a shared FA CoA for inclusion in its MIP Registration to the FA/HA. In this case, the HA encapsulates to the FA CoA, and the Foreign Agent then decapsulates and delivers the HoA addressed packet unencapsulated to the MN. This draft adds to MIPv4 the ability for the MN to acquire a MN specific FA CoA that provides the MN with a topologically correct local address and whose tunnel encaps/decaps is provided by the FA. This address is called a proxy CCoA (PCCoA) and the associated processing in the MN and FA is called Proxy CCoA tunneling. This capability is applicable to any access technology but is especially useful for wir A.W. O'Neill Expires Sept 2002 [Page 1]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002 INDEX Abstract 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . . . . 3 3. Terminology used in this document . . . . . . . . . . . . . . . . . 3 4. MIPv4 Proxy CCoA Tunneling. . . . . . . . . . . . . . . . . . . . . 3 4.1. Proxy CCoA Negotiation . . . . . . . . . . . . . . . . . . . . 3 4.2. Downlink forwarding. . . . . . . . . . . . . . . . . . . . . . 5 4.3. Uplink forwarding and reverse tunneling . . . . . . . . . . . 5 4.4. PCCoAs and smooth hand-off . . . . . . . . . . . . . . . . . . 5 4.5. PCCoA Advantages . . . . . . . . . . . . . . . . . . . . . . . 7 5. New Packet Formats 5.1. Mobility Agent Advertisement Extension . . . . . . . . . . . . 7 5.2. Proxy CCoA Extension . . . . . . . . . . . . . . . . . . . . . 7 5.3. New Registration Reply Codes . . . . . . . . . . . . . . . . . 8 5.4. Binding Update Message . . . . . . . . . . . . . . . . . . . . 8 5.5. Binding Acknowledgement Message. . . . . . . . . . . . . . . . 9 6. MIPv6 Considerations. . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8. Notice Regarding Intellectual Property Rights . . . . . . . . . . . 9 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In MIPv4, when a MN registers with the 'D' bit, in the MIP Registration to a Home Agent through a Foreign Agent, then the MN wishes to use a Co-located Care-of address (CCoA) with a specific Home Address (HoA). Packets sent to the MN Home Address (HoA) will then be encapsulated in the CCoA by the HA and forwarded direct to the MN via the best route from any FA advertising the subnet of that address. In addition, the MN can use that CCoA as a topologically correct source/destination address for local access on the visited subnet. In CCoA based reverse tunneling, the MN can encapsulate the HoA itself into its Co-located Care of Address (CCoA) to cause the packet to be reverse tunneled to the HA. The MN can in addition leave the HoA unencapsulated so that the FA delivers the packet natively and unencapsulated to the destination address. This is known as selective reverse tunneling and is possible whether or not the MN registers via the local FA. Alternatively, a MN can use a shared FA CoA advertised to it by the FA in an Agent Advertisement. In this case, the HA encapsulates to the FA CoA who then decapsulates and delivers the HoA addressed packet natively unencapsulated to the MN. When reverse tunneling, the MN can select during MIP registration between the default Direct Delivery Style and the optional Encapsulating Delivery Style. In Direct Delivery Style, the MN sends packets unencapsulated via the FA using the HoA as a source address, and the FA undertakes the encapsulation of those packets towards the HA using the FA CoA as the source address of the tunnel. A.W. O'Neill Expires Sept 2002 [Page 2]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002 In Encapsulating Delivery Style, the MN instead encapsulates packets with the HoA as a source address towards the FA, which after decapsulating, inspects the visitor list and then re-encapsulates into a tunnel with the FA CoA as the source address. In addition, once Encapsulating Delivery Style has been negotiated with the FA, then the MN can selectively bypass reverse tunneling by sending packets unencapsulated from the HoA. The MN and the FA in existing MIP specs are therefore able to selectively send and receive packets, either unencapsulated, or encapsulated using the HoA as an inner source/destination address and a CoA as the outer address. When sending unencapsulated between each other, the MN and the FA avoid the additional bandwidth incurred by a tunnel header. By using a FA CoA, the MN is however deprived of a local topologically correct address (so preserving address space) but is able to selectively avoid tunneling over the access link, which is beneficial in cellular and other access systems. By using a CCoA, the MN gets a topologically correct address (where addresses are available) but then incurs the overhead of the additional tunnel header for incoming traffic and during any reverse tunneling operations. The use of a MN specific MIP tunnel address can also be useful for QoS support. What is missing in MIPv4 is the ability for the MN to acquire a MN specific FA CoA as a CCoA, that provides the MN with a topologically correct local address and whose tunnel encaps/decaps is provided by the FA. This address is here called a proxy CCoA (PCCoA) and the associated processing in the MN and FA is called Proxy CCoA tunneling. This draft also describes reverse tunneling and smooth hand-off extensions based on the PCCoA. 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/v6. The following introduces additional terminology. PCCoA - Proxy Co-located Care of Address PCCoA tunnelling - tunnel processing carried out by the FA 4. MIPv4 Proxy CCoA Capability 4.1 Proxy CCoA Negotiation The negotiation of a PCCoA is a local matter between the MN and the FA and there is no known reason why the HA should in any way be informed of the optional configuration of the PCCoA capability by the MN on the local FA. The HA simply detects a MIP request, via the FA, for CCoA tunneling. According to Mobile IPv4 [MIPv4] and Reverse tunneling [RevTun], the HA will expect the following tunneling to occur. A.W. O'Neill Expires Sept 2002 [Page 3]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002 The HA will encapsulate all permitted unicast, multicast and broadcast packets, intended for the MN HoA, in the CCoA included within the associated MIP Registrations. The HA then sends the packets to this CCoA from the source address of the HA. If reverse tunneling is enabled then the HA will decapsulate all permitted unicast, multicast and broadcast packets that are tunneled from the CCoA to the HA address, with the inner source address matching the HoA of the MN. From the perspective of the HA, the CCoA is located at the MN and so requires the MIP signaling to have the 'D' bit set. However, as far as the FA is concerned the CoA is actually a PCCoA, which as far as Internet routing is concerned can be considered to be a MN specific FA CoA. The MN allocated this address is on a link-layer directly attached to the FA and so the FA can also enable the MN to make use of this MN specific FA CoA as a source/destination address for local communications. Therefore, the HA sees the PCCoA as a CCoA, the FA sees the PCCoA as a special MN specific FA CoA and the MN treats the PCCoA as an ordinary interface address. A specific implementation of the PCCoA process would be to simply move the tunnel/detunneling process for a CCoA to the other end of the link (from the MN to the FA) but in all other ways treat the address as a CCoA. This is then a link specific change in much the same way that header compression is a link specific function. Proxy CCoA tunneling is therefore possible in MIP if the MN obtains a CCoA from the FA subnet, the MN then registers for PCCoA service via the FA, and that FA is able to support PCCoA processing for that CCoA. The HA forwarding and tunnel processing is unaffected by the changes in this draft. The availability of the PCCoA capability is advertised by the FA in a FAA, by setting the new 'P' bit, or could be triggered via an MIP extension, configuration, PPP, DHCP or other signalling. To request PCCoA service, the MN MUST register via the FA, whether or not this is mandated by the FAA 'R' bit, so that the FA can undertake correct PCCoA processing. The MN can be allocated a PCCoA either by a unicasted MIP FAA that includes a MN specific FA CoA, through a DHCP server with a FA specific prefix, or by any other means that can ensure the address is uniquely bound to a MN on that FA. Proxy CCoA tunneling is negotiated by the MN by including the Proxy CCoA extension in the MIP Registration as well as setting the 'D' flag used to signal the use of a CCoA. This structure is required so that the FA can remove the PCCoA extension whilst leaving the 'D' bit so that the HA will continue to treat the MN as if it had a CCoA. In the future, if HAs require knowledge of the PCCoA mechanism, and sufficient deployment has / will occur, then the extension mechanism could be replaced by instead assigning and setting a new 'P' flag bit (proxy CCoA) in the MIP Registration, as well as setting the 'D' bit (CCoA). The MIP CCoA Registration, when acknowledged by both the HA and the FA in the MIP Reply, causes the FA to store both the HoA and the PCCoA in the visitor list for that MN. Both the HoA and the PCCoA can be used as source / destination addresses to/from the MN. The HoA is used for remote access to/from the HA whilst the PCCoA can be used for topologically correct local access whilst the MN remains at that FA. A.W. O'Neill Expires Sept 2002 [Page 4]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002 4.2 Downlink Forwarding Downlink packets addressed to the HoA, arrive at the FA via the HA, encapsulated in the PCCoA of the MN. Downlink packets (local traffic using the PCCoA as a source/dest address) otherwise arrive directly, and unencapsulated, at the FA. The FA inspects the PCCoA and searches for it in the visitor list. If the packet is unencapsulated then it is simply forwarded to the owning MN. If the packet is encapsulated then it is first decapsulated and the inner unicast destination header inspected to ensure it matches the HoA state for that MN. If the decapsulated packet is broadcast/multicast, and the MIP flags for that MN have requested broadcast traffic and/or the MN is a member of that multicast group, then the packet is forwarded unencapsulated to the MN over a point-to-point access medium but must be sent in its encapsulated form over a broadcast medium. 4.3 Uplink forwarding and reverse tunneling Uplink unicast packets from the HoA are sent unencapsulated via the FA and injected into the routing fabric unencapsulated. In the case of reverse tunneling, the FA encapsulates the permitted unicast, broadcast and multicast packets with the PCCoA of the MN as the tunnel source address, and HA as the tunnel destination address. This is so that the packets will match the registered binding in the HA. Broadcast/multicast packets sent over a broadcast access medium must be encapsulated in the HoA and sent to the shared FA CoA where they are decapsulated, the visitor list and group membership for that MN inspected, and permitted packets re-encapsulated to the HA, as before, within the PCCoA. Note that with proxy CCoA tunneling the option for selective reverse tunneling from the MN is lost. However, this ability can be re-instated if the MN provides the FA with a classifier that specifically defines which of the MNs uplink traffic SHOULD NOT be reverse tunneled. This is achieved by first selecting Reverse tunneling for a specific HoA by setting the 'T' bit as normal in the MIP Registration, and then including a set of excluded classifiers in the form of quintuples describing the uplink unicast header. 4.4 PCCoAs and smooth Hand-offs Smooth hand-offs [RoutOp] enable a MN that was previously registered at the old Foreign Agent (oFA) with an oFA CoA, to request the forwarding of packets, sent to the MN HoA and decapsulated from the oFA HoA, to the MNs new CoA. This means however, that smooth hand-offs are not supported for a MN with a CCoA that is either registered or unregistered at the oFA. This is because a FA is not allowed to decapsulate from the oCCoA and forward to the new CoA at the new point of attachment. Smooth forwarding could be supported by instead having the oFA additionally encapsulate the oCCoA to the nCoA but this clearly adds overhead and requires the nFA to have knowledge of the oCCoA to correctly forward in the case of the MN acquiring a nFA CoA. A.W. O'Neill Expires Sept 2002 [Page 5]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002 The PCCoA capability in contrast brings the required functionality to the FA to support the smooth forwarding of CCoAs, if the MN registered via the oFA, irrespective of whether or not the MN is using a CCoA or a PCCoA. In the case of a normal CCoA, the FA can still transiently support the PCCoA capability and automatically transition the CCoA to a PCCoA when the BU is received from the nFA or directly from the MN. This is only possible if the CCoA is uniquely advertised by that FA. The incoming BU that includes the nCoA will then create a binding between the HoA (and indirectly the oCCoA) and the nCCoA, such that the oFA can decapsulate everything from the oCCoA and re- encapsulate into the nCoA before forwarding. Broadcast / multicast traffic is handled by checking the MIP flags and the HoA group membership and re- encapsulating all permitted packets. The oFA will also encapsulate into the nCoA all packets that are received unencapsulated with a destination address equal to the oCCoA (local traffic using the oCCoA as a network address) during the shorter of the lifetime of the smooth hand-off or the delay until the oCCoA is re-allocated. The request to trigger transient PCCoA support is implicit at the oFA on the reception of a BU. In the case of a MN that was using a PCCoA at the oFA, the meaning of the BU is again implicit and the oFA simply proceeds as for the oCCoA after the PCCoA transition. If the BU is from the MN then it is for a CCoA at a MN that is not registering via the nFA. This however does not affect this hand-off but will affect subsequent hand-offs because the PCCoA transient forwarding is only possible if a MN registers via a FA. If the BU is originated by the nFA then the nCoA in the BU is either a nFA CoA or a nPCCoA, which affects the processing at the oFA. This is because the sending of a nFA CoA implies that the nFA does not support PCCoAs and therefore the oFA (which does support PCCoAs) should undertake all processing required to convert the oCCoA or the oPCCoA received traffic into a format that will be correctly received and forwarded by the nFA. This means that any broadcast/multicast traffic must be first encapsulated into the HoA of the MN before encapsulating into the nFA CoA. It also means that the BU must specifically indicate whether it is for a FA CoA or a CCoA/PCCoA by setting the new 'D' bit. The 'D' bit is set in the BU if the MIP Registration via the nFA had either the 'D' or the 'P' bit set, or is set by the MN that is using a CCoA. The difference at the nFA between a CCoA and a PCCoA is kept within the nFA, and between the nFA and the MN that requested a PCCoA by including the PCCoA extension in its registration. The BU is otherwise unchanged. In addition, the mandatory BUack and its status codes do not need to be extended because the failure of the BU for technical reasons at the oFA, for a CCoA, directly implies a PCCoA processing failure. When considering reverse smooth tunneling, as described in <draft-oneill-mip- revtun-ho-00.txt>, the mechanisms are unchanged for PCCoAs other than that the reverse smooth tunneling is now between MN specific and shared FA CoAs, rather than just between shared FA CoAs. The smooth BU will contain both 'T' and 'D' bits set and the reverse tunneling will be from the nCCoA to the oFA CoA and then from the oCCoA/PCCoA to the GFA/HA. Broadcast/multicast must be reverse tunneled according to the required processing at the receiver for the CoA type. Clearly however, the PCCoA capability is only available when the FA is both able (eg IPSEC) and trusted to perform the tunnel management for the MN. A.W. O'Neill Expires Sept 2002 [Page 6]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002 4.5 PCCoA Advantages These procedures avoid the CCoA encapsulation for remote access traffic over the access link. In addition, the FA is now in a position to police traffic addressed to a specific HoA from a specific gateway, via the PCCoA, before it is sent to the MN, and can also effectively support smooth hand-offs for all CCoAs. In the case of broadcast/multicast the FA is now in a position to avoid the additional encapsulation over the air in both directions when the access medium supports point to point link layer connectivity to/from the MN. Finally, the MN specific (PCCoA) MIP encapsulation simplifies address-based QoS support in the network between the HA and the MN. 5. New Packet Formats 5.1. Mobility Agent Advertisement 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 | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |R|B|H|F|M|G|r|T|S|I|P| reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | | ... | The only change to the Mobility Agent Advertisement Extension [1] is the additional 'P' bit: P Agent offers proxy CCoA tunneling. A foreign agent that sets the 'P' bit MUST support the proxy CCoA tunneling for any CCoAs that are uniquely advertised into the routing system by that FA. Using this information, a mobile node is able to choose a foreign agent that supports proxy CCoA tunneling. Notice that if a mobile node does not understand this bit, it simply ignores it as per [MIPv4] and reverts to normal CCoA behaviour. The ordering of addresses in FAAs is according to the relevant MIP specs and is not altered by this draft. 5.2. Proxy CCoA Extension The Proxy CCoA Extension MAY ONLY be included if the 'D' bit is set and the MN is registering via the FA . If this extension is absent, and the 'D' bit is set, then normal CCoA behaviour from Mobile IP [MIPv4] and RevTun[2] is undertaken. The Encapsulating Delivery Style extension and the Proxy CCoA extension MUST NOT be in the same registration. Mobile Nodes and Foreign agents SHOULD support the Proxy CCoA Extension. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Type: TBA, Length 0. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.W. O'Neill Expires Sept 2002 [Page 7]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002 5.3. New Registration Reply Codes Foreign agent registration replies MUST convey if the PCCoA request failed. These new reply codes are defined: Service denied by the foreign agent: X1 PCCoA capability is mandatory X2 PCCoA capability is administratively barred X3 submitted PCCoA is not routable at the FA X4 submitted PCCoA unavailable In response to a Registration Request with the 'D' bit set, and accompanied by the PCCoA extension, mobile nodes may receive (and MUST accept) code 70 (poorly formed request) from foreign agents. However, foreign agents that support PCCoA capability MUST use the appropriate new code. If the MN registers via the FA with the 'D' bit set, and does not include the PCCoA extension, then code X1 should be returned to the MN to cause the MN to include the extension in any new request. If the MN does include the PCCoA extension and it is either administratively barred from using this capability (through either foreign or home AAA policy state), then code X2 should be returned to cause the MN to modify the Registration. Code X3 should be used if the MN attempts to use as a CCoA an address that is not routable at the FA, and code X4 should be used if the included address is already being used by another MN. In either case, the MN should attempt to get a new PCCoA for the local FA, either from the FA or via some other method. 5.4. Binding Update Message The binding Update message is modified as described below. A new BU flag, the 'D' flag, is added to indicate a request for smooth forwarding of the oCoA to the nCCoA/nPCCoA. The BU 'D' flag is only set if the MIP Registration to the nFA, that generated the BU also has the 'D' bit set. 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 |A|I|M|G|D| Rsv | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- A.W. O'Neill Expires Sept 2002 [Page 8]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002 It is mandatory that a BU with the 'D' bit set must also have the 'A' bit set so that the BU sender has confirmation that the forwarding will occur. The absence of this flag indicates that the CoA in the BU is a nFA CoA. If the oCoA is either a CCoA or a PCCoA, then the absence of this flag causes the oFA to try to convert any arriving flows so that they are compatible with the destination nFA CoA. This specifically means that any permitted broadcast/multicast traffic, and any packets with the oCCoA/PCCoA as an unencapsulated destination address (local traffic), must first be encapsulated into the HoA before being additionally encapsulated into the nFA CoA in the BU. 5.5. Binding Acknowledge Message The format of the Binding Acknowledge message is unchanged, apart from extending the allowed values of the status field to cover the same cases as identified for the MIP Reg. The processing is such that if a BU is sent with the 'D' bit set that does not also have the 'A' bit set, then the oFA should still accept the request, if in all other ways correct, and return an acknowledgement. Up-to-date values of the Code field are specified in the most recent "Assigned Numbers" [13]. 6. IPv6 Considerations IPv6 has the use of a CCoA by the MN as the normal method of tunneling due to the better address availability and allocation mechanisms compared to IPv4. IPv6 does not have the notion of a Foreign Agent though, but an access router or a Local Mobility Agent could instead be modified to undertake the PCCoA functionality defined in this draft, with the obvious required changes. In the case of hand-off, the option of receiving a BU containing a nFA CoA is not possible and so the 'D' bit is not required to distinguish between the two CoA types (nFA CoA or a CCoA/PCCoA). 7. Security Considerations No new security issues are raised by this draft than are already considered in the design of Mobile IPv4 [MIPv4], MIPv4 reverse tunneling [RevTun], MIP Route Optimization [RoutOpt] and Mobile IPv6 [MIPv6]. 8. 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). A.W. O'Neill Expires Sept 2002 [Page 9]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002 9. 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 [RevTun] G. Montenegro, Ed., "Reverse Tunneling for Mobile IP, revised," Internet RFC 3024, January 2001. [RoutOp] C. Perkins, D. Johnson, "Route Optimization in Mobile IP", Internet- Draft, draft-ietf-mobileip-optim-11.txt (work in progress), 6 September 2001. [MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6", Internet-Draft, draft-ietf-mobileip-ipv6-16.txt (work in progress), 22 March 2002. [NestMIP] A.W. O'Neill, ``Nested MIP for mobility management," Internet- draft, draft-ietf-oneill-mip-nested-00.txt, May 2002. [ConcatMIP] A.W. O'Neill, ``Concatenated MIP for mobility management," Internet-draft, draft-ietf-oneill-mip-nested-00.txt, May 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 10]