Subject: RE: [mobile-ip] Fast Handover document revision

From: "Woojune Kim" <[email-masked]>
Date: Tue, 11 Feb 2003 12:46:45 -0500

Rajeev 

Question on proposal 3 below ...

>3. Based on the discussion prior to the last IETF and
>     during the last IETF, I would like to allow PrRtSol and PrRtAdv
>    exchange to be possible ahead of the handover. So, for instance,
>    a MN may exchange these messages upon attaching to a router.
>    This means fewer messages during handover, shorter time for
>    which the handover state needs to be managed and better chances
>    of anticipating a new CoA. Also, the binding at the old router is
>    created upon processing the FBU, and is more consistent with the
>    base Mobile IPv6 spec.

In principle I aggree with this proposal but have some questions.

Would you allow the PrRtAdv to return a NCOA valid indication and the NCOA value ? To this would require the PAR and the NAR to exchange messages to confirm the use of NCOA. I guess this would mean the current HI / HACK messages will be retained but used in a slightly different manner ?

I assume the HI / HACK tunnel setup function would be taken over (taken back ?) by FBU / FBACK ? 

But if this is the case, when is the binding on the new router created ? Can't there be situations where the MN will send an FBU in anticipation while it is still at the PAR. This would enable the PAR to setup a binding, how would the NAR get the necessary information ? Would the NAR set up its end of the tunnel (not really a binding but a host route I guess) AFTER it gets the MN's "refined FNA" ? Or do you expect the messages exchanged earlier to verify the NCOA to set this up at the NAR ? 

thanks

Woojune Kim

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Feb 2003 11:07:50 -0800

> Would you allow the PrRtAdv to return a NCOA valid indication and the NCOA
value ? To this would require the PAR and the NAR to exchange messages to
confirm the use of NCOA. I guess this would mean the current HI / HACK messages
will be retained but used in a slightly different manner ?
> I assume the HI / HACK tunnel setup function would be taken over (taken back
?) by FBU / FBACK ?

I assume that if the SolPrRtAdv/PrRtAdv were to continue to allow anticpated
address configuration, the HI/HAck would need to be done considerably prior to
the handover. If the MN were to do this often, it would end up reserving
addresses on a collection of routers around the current subnet. These routers
would need to defend the address by doing proxy ND. The PAR would also need to
be careful to filter PrRtAdvs so that it only sent those which corresponded to
subnets with wireless (!= wired) connectivity with the current wireless subnet.

Addresses aren't as scarce a resource in IPv6 as in IPv4, but they are a
resource nonetheless, and so there is an issue here. In addition, we would need
some way to indicate when the proxy ND should time out and the router should
stop defending the address, and how to renew the address.

Alternatively, we could drop anticipated address configuration. I believe this
was originally included in the design as a way to reduce the amount of time
involved in doing stateful or stateless autoconfiguration on the new link.
However, if the MN is getting its packets through the tunnel, the address
autoconfiguration can take as long as necessary. Also, there have been some
proposals to reduce the amount of time involved in DAD (FastDAD).

> But if this is the case, when is the binding on the new router created ? Can't
there be situations where the MN will send an FBU in anticipation while it is
still at the PAR. This would enable the PAR to setup a binding, how would the
NAR get the necessary information ? Would the NAR set up its end of the tunnel
(not really a binding but a host route I guess) AFTER it gets the MN's "refined
FNA" ? Or do you expect the messages exchanged earlier to verify the NCOA to set
this up at the NAR ?

Most of the experimental work we've conducted on FMIPv6 shows that the fastest,
most reliable performance is obtained if there is no L3 signaling between the
PAR and the MN during handover. This is only possible if the PAR has information
from the link layer about where the MN is going and when the link goes down, so
it can set up the tunnel in response to the old link to the MN dropping.

For many link layers, the PAR doesn't have this information (for example, it is
not available on 802.11). On these link layers, it makes sense for the MN to
signal the PAR somehow *if* the MN is initiating the handover from L3. If the MN
simply moves in response to an L2 link switch, then discovers afterwards that it
has moved, there must be some way to initiate the tunnel from the new link.

The current design requires the MN to send a FBU back to the PAR. There are a
variety of difficulties with this proposal, as discussed last fall on this list.
An example is the need for a globally routable address for the PAR. Currently,
RFC 2461 and RFC 2462 only require a node to have a link local address for its
router, so this would be a large departure in the current ND protocol. While
"security by obscurity" is never the ideal case, it would also make it easier
for an attacker anywhere on the Internet to mount a DoS attack on the router,
because the MN could send the globally routable IP address to another party.

My proposal for solving this problem is to:

a) Allow the PAR to set up the tunnel if properly secured information is
available from the link layer about when the MN leaves the link,

b) Use a modified form of Redirect for MN to PAR communication prior to handover
if the MN initiated the handover without the PAR/access point knowing it. The
Redirect would inform the PAR that the MN is moving to a new subnet. If the
Redirect is cut off by the handover, the optimization fails, but there is
nothing one can do if the link layer doesn't provide enough information to the
network to optimize tunnel setup. The PAR does HI/HaCK with NAR to start the
tunnel.

c) Define an option that the MN can add to the RS when it comes up on the new
link that allows the MN to inform the NAR to start the tunnel if the MN's L2
moves it to the new link without telling L3 and the network doesn't know either.
The NAR does HI/HaCK with PAR to start the tunnel. This would allow the MN to
start the process of CoA configuration on the new link and, simultaneously,
initiate the tunnel via the NAR.

These confine the signaling to the local link ("think global, act local"), and
define the signaling as a subset of the ND signaling, modularizing local link
movement.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 11 Feb 2003 16:25:30 -0800

Hello Woojune,

sorry if you receive multiple responses.. My mailer has
been crashing between "Sends".

> Would you allow the PrRtAdv to return a NCOA valid indication and the NCOA value ? To this would require the PAR and the NAR to exchange messages to confirm the use of NCOA. I guess this would mean…

You do HI and HAck only upon processing FBU, and not when
you process RtSolPr/PrRtAdv. Note that regardless of when you
do/did HI and HAck, NCoA is not confirmed until FBack is
received. So, moving RtSolPr/PrRtAdv ahead does not cause
state to be created and managed until handover occurs.
However, you may not wish to constrain the MN to receive
FBack on the old link. So, a MN always sends a refined FNA
that confirms the NCoA and/or announces the presence to
the new router.

> I assume the HI / HACK tunnel setup function would be taken over (taken back ?) by FBU / FBACK ?

Yes.

> But if this is the case, when is the binding on the new router created ? Can't there be situations where the MN will send an FBU in anticipation while it is still at the PAR. This would enable the…

Upon processing the HI and HAck messages, the PAR
bids PCoA with NAR's address and the NAr creates a host route
entry.

> thanks

Welcome!

-Rajeev

---

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Feb 2003 14:44:15 -0800

James,

> it can set up the tunnel in response to the old link to the MN dropping.

This result is not surprising. L2 can handle the mobility better.
But whether an approach like this is really in the scope of a network-layer
approach for the Mobile IP protocol is a debatable.

> because the MN could send the globally routable IP address to another party.

I'm not sure if we have a requirement not to expose IPv6 addresses of a
router. At least a site-local address can do the job, without exposing the
router to outside attacks. Even with a global address exposed, a network
that cares about such attacks can deploy a firewall to prevent them.
It's of course better if we didn't have to expose any address, but I don't
think this is a hard requirement on the protocol (or else Mobile IPv4 is
broken, since FA address is exposed).

alper

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Feb 2003 15:35:52 -0800

> approach for the Mobile IP protocol is a debatable.

Handover results in a failure in routing. If the router can detect the failure
and fix up the routing, then why shouldn't it? What is the difference in
principle from this case and a router failing somewhere back in the network and
the network self-healing to fix the routing? There is no involvement of the host
in that case.

> broken, since FA address is exposed).

The requirement is imposed by RFC 2461. Naturally, it could be changed, but we
had better understand why the decision was made to require a site local address
in the first place, and have a good reason. I think running all the signaling
through the current router is architecturally cleaner, as it clearly separates
out the global and local mobility ("think global, act local").

            jak

---

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Feb 2003 16:59:50 -0800

> and fix up the routing, then why shouldn't it?

Nothing wrong with them as solutions if we disregard that we are looking for
a solution in Mobile IP wg for Mobile IP protocol. This is almost same as
what happens with L2 mobility in WLAN and also GTP of 3GPP. Without any L3
involvement from (mobile) node's perspective (i.e., default router
and IP address stays same), network shuffles around and routing is fixed.
I don't see Mobile IP in this.

> What is the difference in

There shouldn't be, and maybe even there cannot be. Because this
has nothing to do with the actions host is taking. So, why should it even
know about it.

> The requirement is imposed by RFC 2461.

Does RFC2461 really say non-link local addresses of routers must not be
exposed to hosts?

> Naturally, it could be changed, but we

Yes, but this is not link-local mobility. So exposing all the parties
involved in the handover to each other is not as unacceptable, imo.

alper

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Feb 2003 08:31:02 -0800

Hi Alper,

> Does RFC2461 really say non-link local addresses of routers must not be

Why don't you read it and find out for yourself? Here's the URL:

    http://www.ietf.org/rfc/rfc2461.txt?number=2461

            jak

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 14 Feb 2003 09:29:15 -0800

Hello Jim,

>    http://www.ietf.org/rfc/rfc2461.txt?number=2461

I have four comments about this...

- I didn't find the prohibition in the text.

- Mobile nodes are expected to know non-link-local addresses of routers
   (viz, home agents)

- That's a 90+ page document, so your challenge is not so easily met.
   If you have something specific in mind, I'm sure it would help to 
point it out.

- If we need something to make fast handovers work, then we should
   determine what that is, and try to make sure that it does not mess
   up other protocols.

- As I understand the language in RFC 2461, the intention is to allow
   prefixes to change without having to change stored global IP addresses
   of routers.  We can do fast handovers without violating the intention.

oops, that was five.

Regards,
Charlie P.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 Feb 2003 16:50:23 -0800

Hi James,

>   http://www.ietf.org/rfc/rfc2461.txt?number=2461

Getting a reference to your claim would be the logical approach, rather
than an exhaustive search for its inexistence (my claim).
But nevertheless, no I cannot find the statement in the rfc
leading to your claims....

And I can give this reference:

Mobile IPv6 draft, section 7.2 "Modified Prefix Information
Option Format", talks about this issue and how the global IPv6
address of the home agent can be conveyed using router advertisements.
So, the required feature is already there.

alper

---

From: "Xiaoming Wang" <[email-masked]>
Date: Tue, 18 Feb 2003 15:17:40 +0900

> So, the required feature is already there.

Two comments are here:
1) There is no statement in ND that prohibit expose the global IP address of
routers.
2) Alper's reference is only appliable for home agents, not for all access
routers.
    Therefore, not all the required feature is already there.

Xiaoming

---

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Feb 2003 12:32:50 -0800

>   Therefore, not all the required feature is already there.

oldAR is configured as a home agent.

alper

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Feb 2003 13:25:08 -0800

> oldAR is configured as a home agent.

Could someone explain to me from an architectural standpoint just what a global
routing proxy like a home agent and an access router have in common?

            jak

---

From: "Xiaoming Wang" <[email-masked]>
Date: Wed, 19 Feb 2003 08:59:30 +0900

> oldAR is configured as a home agent.

[xiaoming]:
I don't agree with it. It means all access routers with FMIP support should
be configured as a home agent. It's not clean and adds additional complexity
to access routers.

Actually I DO agree that we expose the global IP address of routers for fast
handoff. It can be achieved by modification on MIPv6:

Mobile IPv6 draft, section 7.2
"In a Router Advertisement, a home agent MUST, and all other routers
 MAY, include at least one Prefix Information option with the Router
 Address (R) bit set"

We can change MAY into SHOULD or MUST. Before that we should ascertain that
it will not do harm to security of MIPv6. By doing so, it will be accepted
with less objections.

---

From: "Xiaoming Wang" <[email-masked]>
Date: Wed, 19 Feb 2003 09:04:28 +0900

> Could someone explain to me from an architectural standpoint just
> what a global routing proxy like a home agent and an access router have in
common?

They are all routers and should do what a router should do. Nothing else.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Feb 2003 18:11:03 -0800

> be configured as a home agent. It's not clean and adds additional complexity

If you look at what is required of FMIP ARs according to the spec, you'll
see all the required functionalities is a superset of  HA's, and this is not
a coincedence. We discussed this twice on this mailing list, and once we
even went over a list of functionalities. oldAR does "forwarding from
previous care-of address" and the node that does this is a "home agent". Too
bad the section that describes this mechanism is yanked from the MIPv6 spec.
It could have really helped to put this in perspective.

> it will not do harm to security of MIPv6. By doing so, it will be accepted

No need to make this restriction in the Mobile IPv6 spec. FMIPv6 spec
can say that.

alper

---

From: "Youn-Hee Han" <[email-masked]>
Date: Fri, 21 Feb 2003 09:06:07 +0900

> No need to make this restriction in the Mobile IPv6 spec. FMIPv6 spec

About above discussion, an editorial inconsistency has been found 
in the current draft (v.20).

In section 7.2, the draft says...

However, in section 8.3 which describes "Requirements of All IPv6 Routers",
the draft says...

"Each router SHOULD include at least one prefix with the Router
 Address (R) bit set and with its full IP address in its Router Advertisements"

The two different words (MAY and SHOULD)  are needed to be identical.

For supporting enhanced mobility service (such as FHMIPv6), 
I think that SHOULD is more appropriate than MAY.

Youn-Hee Han

---

From: "James Kempf" <[email-masked]>
Date: Fri, 21 Feb 2003 08:08:04 -0800

> I think that SHOULD is more appropriate than MAY.

I think MAY is sufficient. There are other ways to support FMIPv6.

            jak