Personal A. O'Neill Flarion Technologies Internet Draft 22 Feb 2002 Document: draft-oneill-mip-revtun-ho-00.txt Expires: 22 Aug 2002 Hand-off Extensions for Reverse 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 Reverse tunneling in RFC3024 [RevTun] introduces new packet loss scenarios at the HA and also incurs similar packet routing issues as RFC3220 [MIPv4] between Foreign Agents, during a handoff. Whether a Co- located Care-of-Address or a Foreign Agent Care-of-Address is used during Mobile IP registration, any packets from the new Foreign that are received at the Home Agent before the visitor list has been updated will be dropped. In addition, any in-flight packets from the old Foreign agent will be dropped once the visitor list has been updated. This is because in either case the packet source address no longer matches the current Care of Address binding. In addition, whilst smooth handoff for MIPv4 can be achieved by using the PFANE extension [RoutOp], a corresponding solution does not exist for reverse tunneled during handoffs. Therefore, the base processing in [RevTun] (RFC 3024) needs to be amended to better support reverse tunneling through FA hand-offs. Specifically, this entails the support of multiple (fan-in) reverse bindings at an MIP agent. This enables the agent to receive reverse packets from both the oCoA and the nCoA during the hand-off. The draft also adds support, in the case of a FA CoA, for a reverse smooth hand-off via the old FA and the existing oCoA reverse forwarding state. This is used whilst the nFA waits for the MIP Reply that confirms the installation of the nFA CoA in the upstream MIP agent. A.W. O'Neill Expires Sept 2002 [Page 1] INTERNET-DRAFT Hand-off Extensions for Reverse Tunneling 22 Feb 2002 INDEX Abstract 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . . . . 3 3. Terminology used in this document . . . . . . . . . . . . . . . . . 4 4. Reverse Tunneling Hand-off Extensions . . . . . . . . . . . . . . . 4 4.1. Fan-in Bindings. . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Reverse smooth hand-off. . . . . . . . . . . . . . . . . . . . 5 4.3. Packet ordering. . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Signaling Requirements . . . . . . . . . . . . . . . . . . . . 7 4.5. Low Latency Hand-off . . . . . . . . . . . . . . . . . . . . . 8 5. New Packet Formats 5.1. Binding Update . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Binding Acknowledge Message. . . . . . . . . . . . . . . . . . 8 5.3. Mobility Agent Advertisement Extension . . . . . . . . . . . . 9 5.4. Fan-in Lifetime Extension. . . . . . . . . . . . . . . . . . . 10 5.5. New Registration Reply Codes . . . . . . . . . . . . . . . . . 10 6. MIPv6 Considerations. . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 11 8. Notice Regarding Intellectual Property Rights . . . . . . . . . . . 11 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction When reverse tunneling with a FA CoA [RevTun], 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. 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. In either case, according to [RevTun] the HA and any intermediate GFA, is only willing to receive packets from the FA CoA currently registered for that Home Address (HoA). This simple requirement does however cause significant problems for the support of A.W. O'Neill Expires Sept 2002 [Page 2] INTERNET-DRAFT Hand-off Extensions for Reverse Tunneling 22 Feb 2002 Reverse tunneled flows during a MIP hand-off. In subsequent text references to the GFA will be dropped but all references to a HA imply HA and/or GFA/RFA. When the MN moves from an old Foreign Agent (oFA) to a new Foreign Agent (nFA), the MN sends a MIP Registration via the nFA destined for the HA. The new Registration binds the new CoA (nCoA) instead of the old CoA (oCoA) to the HoA, where oCoA and nCoAs can be CCoAs or FA CoAs. In either the CCoA or FA CoA case, the installation of the new binding for the HoA will cause in-flight packets from the oFA to be dropped at the HA, as they no longer match the current binding because the source address is the oCoA. The packets will be dropped as soon as the HA successfully processes the MIP Reply for the nCoA. Therefore the MN needs to delay sending the MIP Reg via the nFA until all in-flight packets have been received at the HA. However, the MN does not know when this event happens and so must be cautious and wait a worse case length of time. The MN can then send the MIP Reg for the nCoA but still cannot reverse tunnel packets using this nCoA until the successful MIP Reply is actually received back at the MN. This is because the MN has no idea of when the HA actually installs the new binding nor whether the MIP Registration succeeded or failed. Once again, the MN must wait an unknown length of time to ensure that reverse tunneled packets will not be dropped in the network due to a binding mismatch. Therefore, the base processing in [RevTun] (RFC 3024) needs to be amended to better support reverse tunneling through FA hand-offs. Specifically, this draft adds support for reverse smooth hand-offs to enable reverse tunneling via the oFA and the existing mobility bindings as well as the support of fan-in bindings so that reverse packets from both the oCoA and the nCoA are accepted. 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], Mobile IPv6 [MIPv6], MIP Reverse Tunneling [RevTun] and MIP Route Optimization [RoutOp]. The following introduces additional terminology. Reverse smooth - inter-FA forwarding from the nFA to the oFA for a smooth hand-off Fan-in binding - supporting reverse tunneled packets from multiple source CoAs A.W. O'Neill Expires Sept 2002 [Page 3] INTERNET-DRAFT Hand-off Extensions for Reverse Tunneling 22 Feb 2002 4. Reverse Tunneling Hand-off Extensions 4.1. Fan-in Bindings The nFA cannot presently reverse tunnel directly to the HA until the MIP Reply is received because this confirms that all MIP elements have reverse forwarding state for the nCoA. Sending in advance of this MIP Reply runs the risk of the reverse packets being dropped in the network due to a missing reverse forwarding binding between the HoA and the nCoA. Reception of the MIP Reply also means however that the state for the oCoA must have been eliminated in the HA because the nCoA will have replaced the oCoA in the HoA binding. This oCoA state will have potentially been overwritten whilst packets were in-flight from the oCoA. This can occur due to a Make Before Break hand-off, reverse smooth hand-off tunneling (section 4.2), or relatively slow links between the oFA and the HA compared to the MIP Reg/Reply delays via the nFA. In the present MIP reverse tunneling spec [RevTun], the result will be that packets arriving with the wrong (stale/late) source address of the oCoA or wrong (new/early) source address of the nCoA will then be dropped according to RFC3024. This is clearly unfortunate and can be avoided by supporting fan-in bindings in the HA. A fan-in binding is similar to simultaneous bindings but for the reverse direction (ie from the CoA to the HA). The simultaneous bindings flag is unsuitable for extending to cover reverse tunneling though because this comes with it the cost of bi-casting of data to both FAs. The zero cost of the fan-in binding in the HA, and its universal benefit, makes it appropriate that it should be a mandatory feature of all reverse tunnel hand-offs. An MIP Registration with the 'T' flag set (indicating reverse tunneling) should therefore not cause the existing binding to be overwritten for reverse traffic only, but instead should cause both oFA and nFA CoA bindings to be valid during the reverse hand-off. The lifetime of this fan-in binding (effectively the remaining lifetime of the stale oCoA entry) can be determined in a number of ways. Firstly, it can be set through configuration in the HA for all hand- offs with that HA. This clearly leads to non-optimal fan-in binding lifetimes because the configuration needs to be as short as possible from a HA state maintenance perspective but needs to be long enough to avoid packet loss. If it is configured to high then an opportunity exists for a third party node to illegally inject reverse tunneled packets via that fan-in binding. The configuration therefore needs to take account of a wide range of hand-off topologies and provide some happy medium that will clearly often be non-optimal. A second alternative is to set fan-in lifetime to the remaining lifetime of the oCoA entry from the previous MIP Reg. This requires no additional configuration but does require the HA to maintain two Registration entries. This increases the state load but does so with little gain compared to the configuration option. This is because the remaining lifetime is clearly uncontrolled and could range from a huge value (increasing the risk of injection) through to zero (hand-off occurred at previous lifetime timeout). This is therefore the least preferred option. A.W. O'Neill Expires Sept 2002 [Page 4] INTERNET-DRAFT Hand-off Extensions for Reverse Tunneling 22 Feb 2002 Thirdly, the lifetime could optionally be dictated by a fan-in lifetime extension that is added by the MN or nFA, which in the latter case is derived from the smooth lifetime in the PFANE, and policed (and potentially reduced) by the HA when compared to the configured value described previously. In effect, we are creating the equivalent of a reverse smooth hand-off within the HA where the nFA CoA would otherwise overwrite the oCoA immediately. This does not however require a PFANE like extension (and a subsequent BU) because the HA is by definition unchanged, and the nCoA is already fully described by the MIP Registration state. Therefore this draft recommends that the fan-in lifetime be controlled based on a short configured default lifetime that can be extended by the HA if so requested by a lifetime in the MIP Reg. The nFA likely has sufficient information from configuration, the PFANE and historical experience about its RTTs to the oFA and the HA, to be able to select an appropriate fan-in lifetime to send to the HA in the MIP Reg. 4.2. Reverse smooth hand-off The second optional modification required is to enable a MN to immediately be able to reverse tunnel packets back to the HA when arriving at the nFA. This is to avoid the MN or the nFA having to wait for the MIP Reply from a very distant HA before reverse tunneling traffic to that HA. The HA already has a binding for the MN pointing to the oFA. Therefore to reuse this existing binding the nFA can first reverse tunnel packets to the oFA, using the nFA CoA as the source address and the oFA CoA as the destination address of the encapsulation. The oFA can then change the source address to its own address and set the destination address to that of the HA. The reverse tunneled packets will then arrive correctly at the HA with the correct source CoA in the existing installed bindings. The forward smooth hand-off in [RouteOpt] uses the PFANE extension to cause a BU to be forwarded to the oFA, by the nFA (or the HA), to set up inter-FA forwarding between the oCoA to the nCoA. The oFA is meanwhile required to buffer packets destined to the HoA of the MN until the BU is received, and then forwarding to the nCoA learnt from the BU. Similarly, the BU needs to also trigger reverse smooth forwarding if the MN MIP Registration at the nFA has the 'T' bit set, and reverse tunneling was also previously installed at the oFA. This is appropriate because the reverse smooth forwarding is only required / useful if existing reverse tunneling state is already installed in the oFA and HA. Essentially, the existing 'T' bit in the MIP Registration (for reverse tunneling in [RoutOpt]) also needs to be added as a flag bit into the BU. Note that smooth forwarding in either direction only works if the MN was previously registered at the oFA and was using an oFA CoA. However, reverse smooth forwarding makes sense if the MN is registering via the nFA with either a nFA CoA or a CCoA. A.W. O'Neill Expires Sept 2002 [Page 5] INTERNET-DRAFT Hand-off Extensions for Reverse Tunneling 22 Feb 2002 The oFA sends the BU with the 'T' bit to the oFA to trigger both forward and reverse inter-FA forwarding. If the nFA is buffering the reverse tunneled packets then it should only start reverse tunneling to the oFA once the mandatory BUack is received. If the MN is buffering the reverse packets then the MN will use the BUack as a trigger to start forwarding. Note that the BUack in [RoutOpt] is addressed to the MN and not the FA and so nFA must snoop the BUack. It would be preferable if the BUack was instead routed via the nFA and any such change in [RoutOpt] will be exploited by this draft. The BUack is mandatory for reverse smooth hand-off because the nFA needs to be sure that the oFA has the necessary state for onward forwarding of the reverse tunneled packets. Whilst waiting for the BUack, the nFA/MN will in addition be waiting for the MIP Reply. The nFA/MN should forward to the oFA only if the BUack is received in advance of a successful MIP Reply, and only whilst that MIP Reply is outstanding. If the MIP Reply is received before the BUack then the nFA should send directly to the HA where reverse tunneling state will have been correctly installed based on the nCoA. In this case the reverse smooth forwarding state in the oFA will not be used and will naturally time out with the forward smooth state. Finally, the buffering element (MN or nFA) needs to have a timer to ensure that it does not wait an excessive amount of time for the reception of either the BUack or the MIP Reply. This is required to ensure that the lossless objective does not affect the competing timeliness objectives. These reverse forwarding rules ensure that the fastest available yet reliable route is always used by the reverse tunneled packets. If the HA are closer than the oFA then the dog-leg inter-FA reverse forwarding will be naturally avoided. If the oFA is significantly closer than the HA then the buffering in the nFA/MN can be minimized by exploiting the existing reverse state. If the MN does not wish to buffer and hence to balance the lossless v timeliness objectives itself then the nFA will naturally undertake this function itself. In the case of the reverse smooth hand-off, and also during a make before break hand-off, the fan-in binding is needed in the oFA to enable packets to be reverse tunneled both from the HoA source address (via the visitor list) as well as from the nCoA source address in the binding cache. This is necessary because the oFA may not have reverse tunneled all packets to the HA before the reception of the BU from the nFA. The oFA fan-in binding is set-up by the BU, has the maximum lifetime of the forward smooth tunneling and is automatically terminated when all outstanding packets from the old link have been encapsulated in the oCoA and sent towards the HA. The associated state is lost when the old link is lost or the MIP Reg lifetime for the oCoA at the oFA times-out. 4.3. Packet ordering The reverse smooth hand-off and the fan-in binding can combine to cause re-ordering of packets. This can be minimized by using the following logic but the optimal solution for any deployment will depend on the L2/L3 control model. A.W. O'Neill Expires Sept 2002 [Page 6] INTERNET-DRAFT Hand-off Extensions for Reverse Tunneling 22 Feb 2002 Firstly, the reverse smooth tunneled packets from the nFA to the oFA should not be forwarded by the oFA towards the HA until the reverse tunneled packets from the old link have all been sent. The MN is in control of which link it uses to send reverse tunneled packets, and knows when it has finished with the old link. The MN can then either act to bring the link down, or it can send an explicit L2 signal so that in either case the oFA can start forwarding the packets that have come from the nFA. An even safer and more universal solution is that the MN only sends reverse tunnel packets over one link at any time during MBB hand-off but this may be unnecessarily overcautious. Secondly, the fan-in binding in conjunction with in-flight packets from both the oFA and the nFA direct to the HA can again cause packet re- ordering. This can be avoided by the nFA delaying using the direct path for a small interval, with one potential value being equal to the BU / BUack RTT. This is a useful measure because the path lengths to the HA from the two neighbouring FAs is likely to be similar and the BU/BUack RTT is representative of the extra path length undertaken by the reverse smooth tunneled packets plus a safety margin. Whilst not deterministic, this measure should be reasonable in general as the aim is simply to minimize rather than absolutely avoid re-ordering. 4.4. Signalling Requirements The MN needs to be able to request a smooth hand-off for both forward and reverse traffic. The existing PFANE and the MIP Reg 'T' flag is sufficient for this such that reverse tunneling is never requested independently of forward smooth tunneling. Reverse smooth forwarding is subsequently enabled if the oFA has reverse tunneling state for the MN and the BU has the new 'T' bit set, indicating that the new MIP Reg via the nFA also requested reverse tunneling. The MN does not need to separately signal reverse smooth forwarding because it is only relevant when forward smooth forwarding is requested, and incurs no cost in being signaled with all smooth hand- offs because the nFA is still in control of subsequent reverse packet routing independent of the oFA. The MN and nFA do not need to know in advance if reverse smooth tunneling or fan-in bindings are supported in the oFA because the BU/BUack will enable the nFA discover this, and if the oFA does not support them then the nFA simply forwards to the HA. The MN and nFA do not need to know in advance if fan-in bindings are supported in the HA because the MIP Reg/Rep will enable the nFA to discover this. If the oFA does not support them then the nFA should still forward directly to the HA, after receiving the MIP Reply. Unfortunately, this will potentially cause packets in flight from the oFA to the HA to be lost when the nFA CoA replaces the oFA CoA. The only benefit therefore of advanced knowledge about the HA features is that if they do not support fan-in bindings then it would be better for the nFA to buffer reverse tunnel packets until the MIP Reply is received, and then forward direct to the HA, rather than forward them via the oFA. The FA should therefore cache knowledge of HA fan-in binding support as it learns this from MIP Replies. A.W. O'Neill Expires Sept 2002 [Page 7] INTERNET-DRAFT Hand-off Extensions for Reverse Tunneling 22 Feb 2002 4.5 Low Latency Hand-off To this point this draft has focused on the smooth hand-off from [RoutOp] and the associated PFANE extension. The MIP wg has in addition defined an alternative hand-off model that is described in [lowLat]. This has alternative signaling models but ultimately still supports inter-FA forwarding and hence can benefit from the reverse inter-FA tunneling defined in this draft. 5. New Packet Formats 5.1. Binding Update The binding Update message is modified as described below. 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|T| Rsv | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- A new BU flag, the 'T' flag, is added to indicate a request for reverse smooth forwarding of reverse tunneled packets from the nFA via the oFA CoA to the HA. The BU 'T' flag is only set if the MIP Registration to the nFA, that generated the BU also has the 'T' bit set. It is mandatory that a BU with the 'T' bit set must also have the 'A' bit set so that the BU sender has confirmation that the oFA will forward the reverse packets and therefore avoid the nFA forwarding into a dead end. 5.2. Binding Acknowledge Message A Binding Acknowledge message is used to acknowledge receipt of a Binding Update message. It SHOULD be sent by a node receiving a Binding Update message in which the acknowledge (A) bit is set; if in addition that message also contains a valid authentication extension and Identification, the Binding Acknowledge MUST be sent. A.W. O'Neill Expires Sept 2002 [Page 8] INTERNET-DRAFT Hand-off Extensions for Reverse Tunneling 22 Feb 2002 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 | Reserved | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Binding Acknowledge message is illustrated above, and is unchanged, apart from extending the allowed values of the status field. The processing is such that if a BU is sent with the 'T' 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]. Proposed new status values are: 1x1 reverse smooth not supported 1x2 reverse smooth tunnel requested but oFA has no state This raises a problem though because to acknowledge the failure of the reverse smooth tunnel requires the oFA to also fail the forward smooth tunnel to then trigger the nFA to resend a simpler BU just for the forward smooth tunnel. This is because all non-zero status codes represent a failure. It would therefore be better to re-use the design from the Registration Req/Reply, whereby non-zero status codes can indicate a success but carry partial failure information. In this case: 0 BU was successful 1 Forward BU was successful but reverse failed 2 Reverse BU was successful but forward failed 5.3 Mobility Agent Advertisement Extension There is no change to the Mobility Agent Advertisement Extension [1]. It simply needs to advertise the 'T' for reverse tunneling as in [RevTun] and the 'S' for smooth hand-off as in [RoutOp]. A.W. O'Neill Expires Sept 2002 [Page 9] INTERNET-DRAFT Hand-off Extensions for Reverse Tunneling 22 Feb 2002 5.4. Fan-in Lifetime Extension The Fan-in Lifetime Extension MAY optionally be included in a MIP Registration if the 'T' bit is set and the MN is registering via a FA. The Fan-in Lifetime may be built in the FA by copying the PFANE lifetime. In this case, the HA should only accept the Fan-in Lifetime if the nFA and HA share an SA. If the MN does not include the PFANE then the nFA may add the Fan-in Lifetime extension itself. If this extension is absent, and the 'T' bit is set, then the HA should still apply fan-in bindings for a short configured time sufficient to minimize reverse tunnel packet loss during hand-off in the local topology. A suggested default is 1 second. Mobile Nodes, Foreign agents and Home Agents SHOULD support the Fan-in lifetime 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 | Lifetime ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Length 2 Lifetime The period of time during which both the existing and the new FA CoA should be valid for incoming reverse tunneled traffic at the HA. This is the number of seconds remaining before the fan-in binding cache entry for the oFA CoA must be considered expired. A value of all ones indicates infinity. A value of zero indicates that the existing binding should be removed and replaced by the new binding in the MIP Registration, effectively preventing a fan- in binding. 5.5. New Registration Reply Codes Registration replies from the HA MUST convey if the request for fan-in bindings failed. This is so that the FA can stop forwarding via the oFA and immediately start sending directly to the HA. The new reply codes are defined as follows: Partially successful registration: 2 Registration accepted but fan-in bindings unsupported 3 Registration accepted but simultaneous and fan-in bindings unsupported A.W. O'Neill Expires Sept 2002 [Page 10] INTERNET-DRAFT Hand-off Extensions for Reverse Tunneling 22 Feb 2002 Service denied by the foreign agent: None. If reverse smooth BU fails then the oFA should retry without setting the 'T' bit and instead reverse tunnel packets to the HA. Service denied by the Home Agent: None. If fan-in bindings are not supported then the Registration should still succeed. 6. IPv6 Considerations Mobile IPv6 [MIPv6] 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, and a Local Mobility Agent and/or a hierarchical mobility agent might instead need to be modified to undertake the reverse smooth functionality defined in this draft. The IPv6 HA should support the automatic invocation of a fan-in binding if reverse tunneling is requested. 7. Security Considerations No new security issues are raised by this draft than are already considered in the design of MIPv4 and MIPv6 smooth hand-offs [RoutOpt] and reverse tunneling. The fan-in binding does open up the small chance of a rogue host injecting packets via the stale oCoA entry but this can only be achieved via either a compromised oFA or via any edge node that does not undertake source address checking. There is however no way for such a rogue host to detect when the opportunity to inject such packets exists unless it is able to snoop MIP signaling traffic at the oFA and/or HA. 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 11] INTERNET-DRAFT Hand-off Extensions for Reverse Tunneling 22 Feb 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. [LowLat] K.E. Malki, Ed., "Low Latency Handoffs in Mobile IPv4", Internet-Draft, draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt, November 2001. [MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6", Internet- Draft, draft-ietf-mobileip-ipv6-15.txt (work in progress), 2 July 2001. 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 12]