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
<draft-oneill-mip-revtun-ho-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
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]