Subject: [mobile-ip] fastv6: Issue 3: Support for Three Party handover

From: Rajeev Koodli <[email-masked]>
Date: Mon, 16 Sep 2002 19:08:45 -0700

Issue: Should "Three Party Handover" (Section 3.1.7 and
Section 3.4 in version 04) be specified as a natural
continuation of the base (i.e., Two Party) handover ?

Background: Both Section 3.1.7 and 3.4 describe
Three Party handover. Section 3.4 is especially
exhaustive. This is done with the objective of
avoiding potential routing loops (especially a
concern when the same IP address is used across
a series of routers) and chaining of tunnels.

Proposal: To allow the base protocol to operate
without specifically describing additional protocol
structure. In particular, if the MN returns back to
its previous AR without completing Mobile IPv6
Binding Update procedure, it must send a FBU
with lifetime of zero (Section 6.1.2 in v04), which
allows the PAR to disable any outgoing tunnels.
This, coupled with a short lifetime for the tunnels
and by making the MN configure a new CoA each
time it visits a new AR, should alleviate the need
for a special Three Party Handover protocol.

Please specify

- YES if you agree to describe Three Party
    Handover as a natural continuation of
    the base protocol with necessary requirements
- NO otherwise. Indicate a brief reason.

Thanks,

-Rajeev

---

From: Michael Thomas <[email-masked]>
Date: Tue, 17 Sep 2002 09:25:22 -0700 (PDT)

So one issue that usually arises with third party
anything is authorization. As in, what prevents an
errant/attacking FMIP router from hijacking the
mobile node's traffic? What protects the mobile
node here such that it has some say-so?

I suspect that this also applies to the two
party network initiated case too.

	      Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 17 Sep 2002 10:07:56 -0700

> party network initiated case too.

So, the proposal is to

- allow the network (i.e., ARs) to create tunnel, but
- enable forwarding on the tunnel only upon successfully
    processing an FBU

Thanks,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Sep 2002 10:23:10 -0700

Mike,

Some of us are trying to spin up a WG to secure Neighbor Discovery. The SA
established for that could be used to secure the handover traffic as well.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Sep 2002 10:47:04 -0700

> - NO otherwise. Indicate a brief reason.

These options are confusing.

What I say YES to is including some form of three party handover as an optional
part of the specification. Whether that qualifies as a "natural continuation of
the base protocol" or not I'll let you decide. :-)

I believe it must be included if the mobile node is to be given full control
over when it configures its care of address. And I believe it is *critical* to
give the mobile node full control over when it configures its care of address,
if we are to maintain the host having final control of when and where it gets
its IP service.

However, I don't think that it should be made mandatory because it may not be
necessary nor possible to support in all cases. For those cases, I believe the
above mentioned option, having the MN send a BU to cancel the tunnel, is
sufficient. However, I believe that the specification must mention that if the
implementation does not provide three way handover, the optimization is lost.
The MN will lose the tunnel and must wait for the routing change on the home
agent and at the correspondents before obtaining it again.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 17 Sep 2002 12:05:22 -0700

> the base protocol" or not I'll let you decide. :-)

What I mean is that there is no separate protocol, as it is now in v04,
but allow the base protocol to operate with tunnel cancellation feature.

> if we are to maintain the host having final control of when and where it gets

A MN can exercise its right to send packets with whatever source
IP address it may chose. The network is not obliged to forward them, however.
Indeed, without protocol support, they should get dropped.

The fast handover protocol allows using PCoA until the MN becomes
a Mobile IPv6 end-point. I see this as a natural co-existence with
base Mobile IPv6.

If you question why a MN should configure a new CoA when it
detects a new router, I think that question should first be addressed in
base Mobile IPv6.

My own thinking is that adherence to using topogically correct IP
address is an important principle that any MN should recognize and
respect. When we design protocol that treads on this principle, we
should try to diverge from the principle as little as possible. Besides,
keeping an IP address across a series of routers leads to chaining of
tunnels and potential routing loops which we should not have to
design solutions for.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Sep 2002 13:24:38 -0700

> Indeed, without protocol support, they should get dropped.

This is properly the domain of micromobility routing. Cellular IP and Hawaii
allow this, for example.

The point of debate here is whether or not the tunnel should be kept up after a
fast handover until the MN chooses to change care of address.

> a Mobile IPv6 end-point. I see this as a natural co-existence with

Again, this is not at issue. What is at issue is when the MN should be required
by the fast handover specification to change its care of address.

> detects a new router, I think that question should first be addressed in

I disagree. The issue here comes up because we are defining a new and different
handover protocol from the standard Mobile IPv6 movement detection protocol. We
need to decide, in the context of this new protocol, what makes sense.

> tunnels and potential routing loops which we should not have to

I don't disagree about the desirability for using a topologically correct IP
address, but I believe the MN should be in control of deciding when to make that
happen, and the network should support the MN until it makes that decision.

Here is an example. Suppose the mobile is receiving traffic on a narrowband
subnet, performs handover to another narrowband subnet but immediately detects
that a broadband hotspot network is available.

Should the mobile be forced by the specification to first change its care of
address into the new narrowband subnet, then move to the broadband subnet, or
should the mobile be allowed to change its care of address directly to the
broadband subnet?

If the specification requires the mobile to change its care of address as soon
as it moves, the mobile would be required to perform the care of address change
twice. If any route optimization was being done with correspondents, that would
have to be done twice too because the tunnel would be not available. This could
lead to considerable delay in the mobile moving to the broadband subnet.

Considering the increasing availability of hotspot networks, it seems like we
should allow this kind of thing.

I don't think the specification can determine all these cases beforehand, and I
certainly don't believe it should be left up to the network to determine when
the care of address can be changed, though the network might want to give the
mobile node a hint, like sending a RA indicating that tunnel service is about to
be terminated.

                jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 17 Sep 2002 14:01:23 -0700

> by the fast handover specification to change its care of address.

Actually, it is whether the fast handover specification should
require the MN to defer forming a new CoA indefinitely.

I think this would require the MN to not send RS, and not process
any unsolicited RAs, or in general, suppress ND. This is not something
the fast handover protocol should specify. That's the proposal.

> need to decide, in the context of this new protocol, what makes sense.

One could still ask the same question: when should a Mobile IPv6 host configure
a new CoA.

> should the mobile be allowed to change its care of address directly to the

The specification is not "forcing" this. This is what happens
if a host changes its subnet. The correct question to ask is should
we require it to act differently..

> lead to considerable delay in the mobile moving to the broadband subnet.

Why ? The MN may move without doing RR on the narrowband
subnet into the broadband subnet. That is not the same as intentionally
deferring its "normal" operations, and hence encumbering the protocol
with "MUST NOTs", however.

> mobile node a hint, like sending a RA indicating that tunnel service is about to

In the proposal, the hint is pre-determined: there is a parameter that defines
how long the tunnel is held up.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Sep 2002 15:33:52 -0700

Rajeev,

> tunnels and potential routing loops which we should not have to

Do you think that  base MIP uses topologically correct addresses when it tunnels
through the HA? I don't see the difference on the wired end of the tunnel
between a reverse tunnel to the HA and a tunnel from one AR to another.

On the wireless end, the topology doesn't matter on the last hop anyway, since
the AR is using a source route like the FA does in MIPv6.

So I fail to see your topology violation argument. What am I missing?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Sep 2002 15:56:55 -0700

> the fast handover protocol should specify. That's the proposal.

My view is the intermediate position, namely that the MN SHOULD begin care of
address change as soon as possible after moving, but that it MAY defer the
change for some period depending on its traffic pattern, movement, availability
of other, possibly more attractive link options, etc.

What is wrong with that?

> One could still ask the same question: when should a Mobile IPv6 host
configure

Sure. My answer would be: when it thinks it has time to do it. Basically, it
should be up to the MN. The spec should give guidance about what is desirable,
but it should not prohibit the MN from holding on to the CoA until a call
completes, or a quick move to another access router happens, or until the MN
switches the home address to a new wireless medium (intertechnology handover),
to cite a few examples.

> we require it to act differently..

The specification forces it if the wording says: "The MN MUST change its care of
address as soon as it detects that it has switched to the new link." Or,
equivalently, if the specification provides no support for continuation of the
tunnel (as is currently the case in draft-koodli) beyond a fixed lifetime. The
latter has the effect of forcing the MN to change, and is, in fact, quite
inadvisable regardless of whether the MN changes or not, because outstanding BUs
to CNs may not complete by the time the tunnel is terminated, effectively
cutting off the traffic.

> with "MUST NOTs", however.

Suppose the MN doesn't do RR, but does change care of address at the HA to the
narrowband subnet. The CNs are sending packets back to the old narrowband AR.
Now, suppose the MN wants to change to the hotspot network. How does the traffic
from the CNs get to the MN when it comes up on the hotspot network and is in the
process of changing the care of address? The traffic gets dropped at the old
narroband AR until the MN has time to complete RR with the CNs. The MN has to
either do RR with the CNs to get the traffic onto the new narrowband router,
then handover to the hotspot network, or do RR to route the traffic back through
the HA until it completes the hotspot network transition.

Without the possibility of deferring CoA change and three party handover, I
don't see any way to solve this without either tunnel chaining or packets
getting dropped.

> how long the tunnel is held up.

That's what I'm objecting to. I don't see that as practical. The MN may actually
require more time to complete RR, for example. This is independent of whether
the MN gets to hang onto an old care of address or not, but if it does, the
tunnel lifetime will need to be adaptable to when the MN actually does change
its care of address.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 17 Sep 2002 17:26:28 -0700

> of other, possibly more attractive link options, etc.

I think having the same requirement as in base Mobile IPv6 is good.

Regarding the addition of MAY however, the only protocol addition
would be to inform the MN if a tunnel is about to expire ? I guess such a
notification itself is a MAY ?

The tunnel lifetime itself has to be long enough to account for lost
BU, RR messages etc..

> the HA until it completes the hotspot network transition.

If the MN does not do RR on the 2nd subnet, upon moving to the 3rd,
it SHOULD send an FBU to AR on the 1st subnet to set up a tunnel
between AR1 and AR3.

Anyway, the risk of potential packet loss should compel the MN to become a MIPv6
end-point sooner than later :-)

> tunnel lifetime will need to be adaptable to when the MN actually does change

What if we keep the lifetime "large enough" ?  Having a constant lifetime makes
protocol simpler.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 17 Sep 2002 17:49:58 -0700

James Kempf wrote:

> through the HA?

Yes. The HA uses a topologically correct source address!

> I don't see the difference on the wired end of the tunnel

In MIPv4, there is a single reverse tunnel between FA and HA. This came
about as the Internet evolved and sites started using ingress filtering.
In MIPv6, the reverse tunneling is done by the MN when it is not using RO.
In both the cases, the use of reverse tunnels is not a function of _when exactly_
the MN configures a topologically correct CoA.

In FMIPv6, tunnel chaining and potential routing loops would result
as a result of keeping topologically incorrect IP addresses indefinitely.
The use of a reverse tunnel is a function of when the MN configures a
new CoA and establishes itself as a MIPv6 end-point.

> So I fail to see your topology violation argument. What am I missing?

I didn't say that fmipv6 is following the principle to the wire. I did say that
the divergence from the principle should be kept small. Indefinite use of
previous CoA without respecting topological correctness stretches the
balance the protocol has to accomplish in addition to the requirements
it imposes on a MN, such as suppressing ND.

In any case, having the same level of requirement as in  the base MIPv6
protocol is good. I think we can also have the MAY you suggested
as long as the MAY also applies to notification from the router about
tunnel lifetime expiration.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Sep 2002 18:33:31 -0700

> notification itself is a MAY ?

Not sure, but it is a MUST if the network operator has configured the router to
allow longer tunnels. It is a MAY if the router doesn't allow this, however.

> The tunnel lifetime itself has to be long enough to account for lost

I think the tunnel lifetime must be configurable and I think the possibility of
tunnel renewal must be allowed. The wireless link could become congested or the
response to RR from one or another CN could be delayed. Deployments will vary
and I believe the network operator must have the options of configuring this
according to the local policy and local deployment conditions.

> it SHOULD send an FBU to AR on the 1st subnet to set up a tunnel

Three party handover does this in a way that doesn't require the mobile to
signal the old AR. If the mobile moves prior to sending the FBU, it will cause
packet loss.

The new AR will find out that the mobile is moving anyway by either the PrRtSol
from the mobile or the Layer 2 prehandover notification (if available). Why not
let it transfer the tunnel? The two routers have a security association (or
should) so there should not be a security problem. The new narrowband AR can
transfer the tunnel either when it gets the (securely delivered) link down
notification or when the MN sends the FBU from the hotspot router. If the MN
sends the FBU while still on the narrowband router, the hotspot router can
buffer until the MN shows up.

> What if we keep the lifetime "large enough" ?  Having a constant lifetime
makes

I agree that it makes things simpler, but the problem is that deployments can
vary. I don't see any way to avoid having the tunnel lifetime configurable, and
allowing renewel. The alternative is that some percentage, potentially high for
a suboptimal case, of the real time sessions get dropped or experience
artifacts.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 18 Sep 2002 11:39:16 -0700

Moving forward..

I propose that

- the tunnel lifetime be a configurable parameter
- suggest default lifetime taking RTT, BER etc into account

The result is a simpler protocol that does not require a MN

- to suppress ND
- engage in additional protocol messages to renew tunnel
   lifetime
- use anticipation whenever possible

We should stick with what the guidelines are for base MIPv6.

-Rajeev

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Sep 2002 12:06:01 -0700 (PDT)

> according to the local policy and local deployment conditions.

   FWIW, I think that Jim's argument here is eminently
   reasonable. Fixed timers always seem suspect to me.

		     Mike

---

From: "James Kempf" <[email-masked]>
Date: Wed, 18 Sep 2002 14:32:40 -0700

> - the tunnel lifetime be a configurable parameter

Agree.

> - suggest default lifetime taking RTT, BER etc into account

Agree.

> The result is a simpler protocol that does not require a MN

Disagree. There are ongoing discussions about how ND might be optimized. It is
too soon to say how these may come out, but the purpose is to reduce the amount
of time involved in a MN coming up on a new link. This discussion might in fact
recommend suppressing ND. If so, then I think we should abide by that.

> - engage in additional protocol messages to renew tunnel

Disagree strongly. As I've mentioned in previous email, tunnel management,
including lifetime renewal, is a simple part of the protocol that we've
implemented as described in my previous email according to draft 04 and found
great success with. I believe that network operators will require the ability to
allow tunnels to be renewed for proper support of MNs.

Can you give me some _technical_ arguments as to why you are so opposed to this?

> - use anticipation whenever possible

I don't understand what this is. Could you explain?

> We should stick with what the guidelines are for base MIPv6.

The the base MIPv6 spec doesn't define a fast handover algorithm: it doesn't use
tunneling, and it says nothing about anticipated care of address
preconfiguration. None of these topics are included in the basic MIP movement
detection algorithm. We are, in fact, defining a protocol to replace the
movement detection algorithm.

If the movement detection algorithm is replaced, then the base spec kicks in
when the MN begins configuration of the new care of address. If we accept that
the MN has control over when that happens, as the base spec says, then we need
to figure out some way for the network to support the MN until the MN decides
that it's ready. Allowing a configurable tunnel lifetime helps, but it really
won't cover all cases, unless we allow a "good until cancelled" lifetime. As a
practical matter, I think we should avoid this, because it runs the risk of
leaving around the source routes if the MN crashes. So that leaves lifetime
renewal.

Additionally, I don't think we can avoid figuring out some way to cancel the
tunnel when the MN is through configuring its care of address by prohibiting
tunnel renewal. If the tunnel lifetime is configurable, the AR needs to be told
when the MN's routing has changed at the HA and CNs so the AR can delete the
source routes.

I frankly don't see any way that network operators can properly support allowing
the MN to select when it wants to configure its care of address unless tunnel
renewel and cancellation is included. And that is my principle concern.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 18 Sep 2002 15:45:24 -0700

> Can you give me some _technical_ arguments as to why you are so opposed to this?

As I mentioned above, the need for the MN to get involved
in tunnel management between the access routers. This would
require additional protocol messages and code which are not necessary
for a base protocol to operate. These are similar arguments you
would make to reduce the number of protocol messages sent over
the air.

Could you provide some details on how often you had to do tunnel
lifetime renewal and under what conditions
(including the configuration parameters used) ?

> I don't understand what this is. Could you explain?

I meant configure an prospective IP address through
anticipation.

> renewel and cancellation is included. And that is my principle concern.

But, why should there be a "selection" issue in the first place ? Allow the
MN to behave like a Mobile IPv6 node, i.e., it SHOULD configure a new CoA
as soon as it detects a new link. When anticipation is used, it is the question
of when that address is confirmed (i.e., FNA is sent as soon as a new link
is established). Configuring a new CoA does not mean automatic tunnel
expiry.

Anyway, if it is ok with others, this can be an option in the base protocol.

-Rajeev

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Sep 2002 08:20:37 -0700 (PDT)

> that a broadband hotspot network is available.

   I think I agree with Jim here. I guess that I'm sort of
   suspicious of protocol edicts which try to enforce higher
   principles, especially when there is already built in
   motivation. In this particular case, it seems to me that
   the mobile node already has a fair amount of motivation 
   to disentangle itself after it's moved so requiring it
   to do that is either redundant, or needlessly constrictive.
   We should really concentrate on the things that cause
   the protocol to fail... and let the IAB deal with the things
   that cause the net to fail :-)

	      Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Sep 2002 10:17:36 -0700

Hello Michael,

The protocol design is not based solely on "principle". If it
did, we should not strictly allow using previous CoA on the
new link and insert host routes.  Clearly there is a pain in not
allowing using previous CoA. So, we do allow for it, the question
is for how long. Should the host routes linger around longer than
necessary for a MN to complete its Mobile IPv6 operations ?
What is the obligation for a MN in terms of address configuration ?

From the discussion so far, I gather that the MN SHOULD become
MIPv6 end-point as soon as it attaches to a new router. However,
the protocol should take into account such events as potential
packet loss etc. So, the tunnel lifetime is a configurable parameter which
should take into account the idiosyncracies of the wire(less).
And, there should be an option to renew the tunnel
lifetime. I have to say I have not thought of all possible implications
of such a renewal..

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Sep 2002 14:01:50 -0700

> lifetime. I have to say I have not thought of all possible implications

So I've been thinking about how the protocol currently does FBU and I think
there is a semantic mismatch between how FBU is defined in the base spec and how
BU is being used in the fast handover protocol, particularly with respect to the
way RA and RS are typically used in standard movement detection and maintaining
the same semantic for PrxyRA and SolPrxyRA.

The semantic for RA and RS is that a node uses RS and RA to find out what subnet
it is on, after which it does DAD or DHCP configuration to get its address. So,
essentially, receiving the RA initializes the node in the process of
establishing a care of address on the subnet.

Similarly, a BU in the base MIP spec is only sent when the MN is in a
topologically correct location to utilize the care of address. So the care of
address is valid, the host is on the link, and the router can route traffic to
the host.

The semantics of FBU don't really match the semantics of BU in the base spec.
The MN sends FBU immediately after getting the Proxy RA. But at that point, it
may not even be in the correct topological location to receive packets at the
new CoA. It may still be on the old link, or it may have moved to the new link.
If it's moved to the new link, it may not have even sent the HA BU yet, nor the
CN BUs, so it really has not completed configuring the new care of address.

I think it might make some sense to try to match the base semantic for PrxyRA,
SolPrxyRA, and FBU more closely, with a few modifications to match the
difference that the anticipated care of address configuration is occuring on a
different link. The principles behind the modifications are these:

- Optimization of CoA configuration on the new subnet is performed by the new
router and old router as part of the anticpated care of address change. This is
different from the standard neighbor discovery sequence.

- The tunnel is there to help fix up the routing failure while the MN is
establishing the new care of address, and is maintained until the MN completes
care of address configuration with HA and CNs.

Here's my suggestion about how this might work.

- All ARs that support fast handover lock down their neighbor cache entries,
making a neighbor table, so that the neighbor table always reflects the current
set of MNs on the link and also some that might currently be undergoing handover
(as below). This is similar to MIPv4, where the ARP cache entries are locked
down in the FA as long as a MN is on the visitor list.

- After the MN receives a PrxyRA, it is considered, for routing purposes, to be
on the new subnet if the handover was confirmed (it might be denied with low
probability). Thus, as a default, all traffic for the MN should be directed to
the new subnet. Optimizations are possible and discussed below.

- The old AR, via the HI, notifies the new AR that the MN is coming, with the
old CoA, proposed new CoA, and link layer identifier. The new AR confirms
whether the proposed new CoA is not used, makes a neighbor table entry
indicating such and puts it into the "undergoing handover" state. If the CoA is
not acceptable (low probability of occuring), the AR sents error code in the
HaCK and sends a usable proposed CoA back (it could also do this for stateful
addrconfig), which is conveyed by the PrxyRA to the MN. The old AR also inserts
a source route for the old CoA in order to handle tunneled packets.

- As a default, when the old AR receives the HaCK, it starts tunneling packets
to the new AR under the old CoA. Note that the MN may still physically be on the
old link at this point, but logically, the PrxyRtAdv completes the anticipated
care of address change. The new AR may buffer tunneled packets until the MN
shows up (but probably shouldn't for real time traffic).

- The old AR may use link layer hints, like for example a secure link down
trigger, to optimize tunnel initiation. This could reduce the number of lost or
buffered packets.

- When the MN shows up on the new link, it sends the BU to HA, RR and BU to CNs,
then, when this is all complete and there is no need for the tunnel, it sends a
BU to the old AR indicating that it can receive any further packets at the new
CoA. At that point, the tunnel to new AR is brought down, but the old AR can
forward any laggard packets to the new CoA for some grace period. After the
grace period concludes, the old AR removes the source route for the old CoA.

- The two ARs maintain the tunnel until the MN has signaled, via the BU to the
old AR, that it no longer needs it. The MN SHOULD change its care of address as
soon as possible, but exceptions are allowed, subject to local network operator
policy.

- The FNA could be used to cause the new AR to switch the neighbor table entry
to "confirmed". Alternatively, this could be done by a secure link up trigger,
or when the tunnel is brought down. Probably, the FNA isn't needed.

- At any time, the new AR can send a RA to the MN indicating that it should
start configuring its care of address _now_. This is controlled by the network
policy. Some network operators may not want to support tunnel lifetimes beyond a
certain point. After the RA is sent, the new AR can keep the tunnel up for a
grace period, but then it will shut it down.

I think this gives a cleaner semantic cut between the anticipated care of
address configuration and the optimizations, and a better match between the
termination of the routing failure fixup and the base Mobile IPv6 spec BU
semantic.

Comments?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 23 Sep 2002 09:19:15 -0700

> I think this is deviating from the general Mobile IP protocol. Until now,
> only
> BU or BU's sister FBU could change a binding cache entry. Now binding
> cache can also be changed by PrRtSol....?
>

Binding cache entry? Which RFC contains text saying that an IPv6 router supports
a binding cache as part of its routing function? As far as I know, RFC 2461
specifies a neighbor table, but if the router does support a binding cache, it
is strictly part of its function as an IPv6 node that supports route
optimization of packets addressed to its IPv6 address *as an IPv6 host*, and not
as part of its function as a router. But perhaps I am missing something.

> did MN not already got a newCoA in earlier steps?
>

It did, but it may not choose to use it right away for a variety of reasons. The
timing of when to change CoA is left up to the MN.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 23 Sep 2002 10:35:26 -0700

> > > - After the MN receives a PrxyRA, it is considered, for routing
purposes,
> > to be
> > > on the new subnet if the handover was confirmed (it might be denied
with
> > low

In the context of Mobile IP, a node (host/router) intercepting IP packets on
behalf of another host and tunneling them to another IP address is basically
performing home agent functionality. And the required information for this
operation is stored in binding cache. Whether it is forwarding from previous
care-of address, or its specific instance FMIPv6, the old access router is
performing home agent functionality.

> timing of when to change CoA is left up to the MN.

alper

---

From: "James Kempf" <[email-masked]>
Date: Mon, 23 Sep 2002 14:29:49 -0700

> performing home agent functionality.

From Section 10 of the MIPv6 spec, here is a very abbreviated, high level
outline of  the requirements on Home Agents:

    1) Maintain primary care of address for client mobile nodes by processing
binding updates for changing the primary care of address.

    2) Intercept and forward packets addressed to the mobile node's home address
to its care of address.

    3) Tunnel packets addressed from the home address to the care of address.

    4) Reverse tunnel packets with the source address being the home address to
the correspondent node.

    5) Protect return routability packets through an IPsec security association.

    6) Support the dynamic home agent discovery protocol through various means.

    7) Support extensions to nework renumbering to allow MNs to be renumbered
while away from home.

There are over 16 pages of detailed specification describing what a Home Agent
must do. Are you saying that all IPv6 access routers must support these detailed
specifications in order to process a single message that terminates the tunnel?

In my view, there is no real overlap between what an access router does and what
a home agent does, except that they are both routers. The functionality of
inserting host routes and bidirectionally tunneling packets may seem common, but
the old access router doesn't even route the tunneled packets to the MN's care
of address, it routes them to the new access router. So the function being
performed is really more like what a router in the core of the network would
perform. The router is just fixing up a failure in the routing, just as a router
in the core would roll over to using an alternate route (without any end host
involvement) if another router on the path failed.

Perhaps the confusion comes from using a Binding Update in order to change
routing associated with a router (as opposed to changing end-to-end routing
using a host, or to change Home Agent routing). If so, then perhaps we need to
look into another message to terminate the tunnel, or expand the Binding Update
semantics to include this case.

                jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 24 Sep 2002 14:57:28 -0700

> outline of  the requirements on Home Agents:

Most, if not all, of the below list needs to be satisfied by the access
router
if it is going to act as "oldAR" in FMIPv6.

> binding updates for changing the primary care of address.

It has to process FBU, that maps oldCoA to another IP address (e.g., newCoA
or newAR, more on this later...)

>     2) Intercept and forward packets addressed to the mobile node's home
address

It must intercept packets addressed to oldCoA (which is perceived as a "home
address"). It must even assume ownership of this IP address and respond to
NS,
and DAD queries on behalf of the MN.

>     3) Tunnel packets addressed from the home address to the care of
address.

Yes, it must tunnel packets destined to oldCoA to newCoA.

>     4) Reverse tunnel packets with the source address being the home
address to

If ingress filtering is an issue, and the MN doesn't have a topologically
correct
source address to use, then yes, oldAR has to help with reverse tunneling as
well.

>     5) Protect return routability packets through an IPsec security
association.

If that means "make sure the protocol signaling is secure", then yes.

>     6) Support the dynamic home agent discovery protocol through various
means.

I guess , yes.. Somehow the MN should be able to discover if one or more
access
routers can perform these functionalities... (maybe PrRtSol took care of
this??)

>     7) Support extensions to nework renumbering to allow MNs to be
renumbered

OK, we can live without this, I guess. If we disregard the possibility of
the old subnet
going through renumbering while the MN is still receiving forwading service
from
the oldAR, then we don't care about this...

> specifications in order to process a single message that terminates the
tunnel?

Regardless of what variant of FMIPv6 we are looking at, the base idea is
simply "forwarding from previous care-of address", which requires home agent
functionality on the access router..

If an IPv6 router supports FMIPv6, that means it has implemented home agent
functionality (and more)... It's acting as home agent to the oldCoA of the
MN.

Of course, one might choose to place the FMIPv6 functionality, say, on a
server on the old link.. Though we cannot call it "oldAR" anymore..
I think we somehow just assumed that FMIPv6 functionality will be
implemented
on the access router (AR).

> of address, it routes them to the new access router.

As far as oldAR is concerned, there is no difference. oldAR doesn;'t care of
the
newCoA belongs to MN or some other node. It simply accepts it as "CoA" and
tunnels packets to this endpoint.

> So the function being

Yes, FBU is the extended form of BU.

alper

---

From: "James Kempf" <[email-masked]>
Date: Tue, 24 Sep 2002 21:39:37 -0700

> or newAR, more on this later...)

The base MIPv6 specification doesn't say "oldCoA" it says "home address".

> and DAD queries on behalf of the MN.

The oldCoA is not the home address. It is not in the DNS, it is not on the MN's
home link.

> If that means "make sure the protocol signaling is secure", then yes.

No, it doesn't. It means "protect return routability packets through an IPsec
security association." These are specific requiremnts on the home agent
precisely stated so as to facilitate interoperable implementations, not a
collection of nebulous generalities about security.

> routers can perform these functionalities... (maybe PrRtSol took care of

Clearly, this functionality is irrelevent for a router. It has nothing to do
with PrxyRtAdv.

> on the access router (AR).

I disagree. I don't believe home agent functionality is required for FMIPv6.
FMIPv6 is defining a modification to the IPv6 routing protocol for Mobile IP
edge routing. I believe we must make it fit well with last hop IPv6 routing as
well as Mobile IP. Home agent functionality was clearly defined with a different
purpose in mind.

I don't think the FMIPv6 functionality can be put in any old server on the link,
I think it must be in the router. We need to be very clear about the changes we
are proposing. These changes are in routing. I don't believe we need to have any
major architectural changes, like home agent servers on the last hop, in order
to make Mobile IP handover fast.

                jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 24 Sep 2002 22:23:06 -0700

> > >     2) Intercept and forward packets addressed to the mobile node's
home
> The oldCoA is not the home address. It is not in the DNS, it is not on the
MN's

This is just a"nested" Mobile IPv6 going on. or "forwarding from previous
care-of address". Same thing. Just like HA was intercepting HomeAddr and
tunneling packets to oldCoA while MN was at the old-link, if MN wants
its packets to be forwarded to newCoA, it should send a binding update
to oldAR where home address field is set to oldCoA, and the care-of address
field is set to newCoA. Now oldAR acts as a home agent for oldCoA, therefore
it intercepts packets sent to it and tunnel them to newCoA.

This is like running two instances of Mobile IP for the same MN. In one,
HomeAddr and oldCoA used, in other, oldCoA and newCoA used.
Now packets sent to HomeAddr are tunneled to oldCoA, and once
intercepted by oldAR, these packets are further tunneled to newCoA.

In the above message of mine, the IP address oldCoA is used as a
home agent when oldAR acts as a home agent.

> collection of nebulous generalities about security.

In this case, there doesn't have to be any RR that involves oldAR. All MN
needs is a tunnel from oldAR to newCoA, hence a simple (and secured)
BU/FBU to oldAR is sufficient. If the MN further wants to update CNs with
its newCoA, this BU should involve RR that goes thorugh the original HA
(and of course should happen after MN registers its newCoA with this HA).

>
> > >
> > >     6) Support the dynamic home agent discovery protocol through
various
> > > There are over 16 pages of detailed specification describing what a
Home
> > Agent
> > > must do. Are you saying that all IPv6 access routers must support
these
> > detailed
> > > specifications in order to process a single message that terminates
the
> well as Mobile IP. Home agent functionality was clearly defined with a
different

I think we have a different view on this.

> I think it must be in the router.

Well, OK, I guess since it has to respond to RS/RA, PrRtSol/PrRtAdv, we'd
have to call it a router..

> We need to be very clear about the changes we

Whether we call it a "server", or "router", this is home agent
functionality.
Nothing less.

alper

---

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Sep 2002 11:36:39 -0700

> home agent when oldAR acts as a home agent.

Forwarding from previous care of address was taken out of the base MIPv6 spec
because the functionality is covered by FMIPv6. The current state of the FMIPv6
discussion (as I understand it, Rajeev can correct me), does not include the
option of having the FBU trigger forwarding to the new CoA through a tunnel
immediately after a handover, the forwarding is to the new router at the the old
CoA to avoid the case where the MN hasn't yet got the new CoA completely
configured. In the proposal I made, the new CoA would get forwarded to after it
was fully configured, if any laggard packets were still around after the MN
compltely configured its new care of address.

It sounds like you are proposing something different, perhaps re-inserting the
former text on forwarding from previous care of address into the FMIPv6 spec? If
so, I suggest you make a proposal which we can debate in a separate thread. I
believe the functionality you are asking for is included in the proposal I made,
but in a way that is more consistent with the existing base MIPv6 spec.

> (and of course should happen after MN registers its newCoA with this HA).

Exactly whether RR or an IPsec secured tunnel should be used is open for debate.
My point is, the security on a fast handover won't look exactly like a home
agent's, therefore, it is incorrect to call the router a home agent.

> Whether we call it a "server", or "router", this is home agent

Clearly we disagree. My opinion is that a home agent is that network element
which implements the required home agent functionality in the MIPv6 base draft,
nothing more nor less. If we are to start picking and choosing functionality out
of that list and putting it in the router, then we can't call it a home agent,
and we need to consider whether the picked and chosen functionality is the
architecturally correct way to satisfy the requirements.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 25 Sep 2002 22:36:42 -0700

> because the functionality is covered by FMIPv6.

I really doesn't have to be specified anywhere, after all it's just the
nested
application of the same protocol anyways.

> The current state of the FMIPv6
> configured.

From oldAR perspective, once the binding cache entry is in place, it
really doesn't matter if the "care-of address field" has newCoA, or newAR,
or some other IP address.

> In the proposal I made, the new CoA would get forwarded to after it

Hopefully not RR. I cannot imagine MN going through RR that involves its
original home agent in the middle of a "fast handover". MN better bootstrap
a security association with its oldAR while it's still connected to it and
use IPsec.
This is what we should be looking at first, not RR. [anyways, this was a
side note].

> agent's, therefore, it is incorrect to call the router a home agent.

Just for clarification, I'm just saying that router is also implementing
"home agent functionality", like it could also have NAS and DHCP server
functionalities.

> architecturally correct way to satisfy the requirements.

I think we went over these functionailities in the earlier message, and
it seems like our oldAR satistifies almost all of them.

alper

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 26 Sep 2002 14:27:30 -0700

> option of having the FBU trigger forwarding to the new CoA through a tunnel

As I pointed out in my response to Basavaraj Patil's recommendation
on this topic for Mobile IPv6, it is not forbidden in FMIPv6 for the MN
to include NCoA. This may need to be mentioned in the draft.

-Rajeev