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

From: "Woojune Kim" <[email-masked]>
Date: Wed, 12 Feb 2003 10:20:20 -0500

Rajeev,

Thanks for your reply. Comments below. 

>-----Original Message-----
>Woojune Kim wrote:
>
>> 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 ?
>>
>
>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.
>
>
>>
>> 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 ?
>>
>
>Upon processing the HI and HAck messages, the PAR
>bids PCoA with NAR's address and the NAr creates a host route
>entry.
>
>

OK, I guess I understand your thinking better now. Basically, you will be using the Hi / Hack messages to setup the tunnel. But it will be triggered by the reception of the FBU at the PAR. i.e. MN will send the FBU, this will be received at the PAR, the PAR will then send HI / HACK to setup a tunnel with the NAR. 

I don't think this really agrees with your aim of making the semantics of FBU similar to normal MIPv6 BU. In normal BU, the BU / BACK exchange in itself is enough to setup the tunnel. The fact that FBU in itself is not enough to setup all tunnel related state in the PAR / NAR means that it is essentially a different message. Also not really sure what role FBACK plays in the case where FNA will ALWAYS be sent. The FBACK isn't enough to setup tunnel state in the NAR, nor does it confirm the use of the NCOA, as now FNA will always have to be sent. So doesn't this really break any relationship it had with MIPv6 BU / BACK exchanges ?

Anyway, according to your suggestions it seems

[a] If the MN sends the FBU while still on the old link, the FBU should be able to setup a tunnel immediately based on it. (I agree security is still an open issue ..  ). MN always sends FNA once it moves to NAR.

[b] If the MN sends the FBU when it has moved to the NAR, it is passed to the PAR, which THEN sends a HI / HACK to setup the tunnel. MN always sends FNA once it moves to NAR.

The case [b] seems to result in redundant messages. It seems either we could have the NAR (PAR) add extensions to the FBU (FBACK) messages so that they will be able to setup the tunnel state on the PAR (NAR), or we just make the MN NOT send an FBU in case [b], and instead the FNA reception at the NAR will trigger a HI / HACK exchange with the PAR.

If we make such a change, what we arrive at is
a) The MN will only send an FBU if it decides to do move to the NAR while it is still able to the PAR over the old link. This should trigger a tunnel setup.
b) If the MN has already arrived at the NAR, it should just send the FNA, which should trigger a tunnel setup with the NAR.

Of course the ability to send the FNA will rely on PrRtSol/Adv exchange before hand so as to be able to at least get the NAR's Prefixes etc.

Now we only need some way of securing the FBU exchanged btw the MN and the PAR over the old link. (Same problem as before, but maybe the problem space is more restricted as we only have link local things to take care of..)

But then then isn't this basically what is being suggested by James Kempf (change FBU to what Redirect) ? (Sorry James for going the round about route to a clearer understanding of your position)

thanks

Woojune

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 12 Feb 2003 10:00:55 -0800

Woojune Kim wrote:

> I don't think this really agrees with your aim of making the semantics of FBU similar to normal MIPv6 BU. In normal BU, the BU / BACK exchange in itself is enough to setup the tunnel. The fact that FBU in itself is not enough to setup all tunnel related state in the PAR / NAR means that it is essentially a different message. Also not

The primary objective is to reduce the amount of signaling
during handover. And, for 802.11 networks, it helps to obtain
the map of neighborhood APs and ARs since the MN may attach
to any AP (and potentially a different AR). Having a corresponding
AR's MAC and prefix information facilitates FBU to be sent out
quickly and also allows the MN to quickly determine a new CoA.
At least some of these have been discussed earlier. Also, having a
look at the last IETF presentation does not hurt before engaging
in this discussion further.

> really sure what role FBACK plays in the case where FNA will ALWAYS be sent. The FBACK isn't enough to setup tunnel state in the NAR, nor does it confirm the use of the NCOA, as now FNA will always have to be sent. So doesn't this really break any relationship it had with MIPv6 BU / BACK exchanges ?
>

If the FBack has been received, the MN simply announces its
presence to the new router. There is no need to confirm the
NCoA or attempt (re)configuring a fresh NCoA.

I do not wish the discussion to center around comparison with
MIPV6.. We have to move the draft forward by addressing the
outstanding issues.

> The case [b] seems to result in redundant messages. It seems either we could have the NAR (PAR) add extensions to the FBU (FBACK) messages so that they will be able to setup the tunnel state on the…

If the MN never sent FBU before attaching to NAR, there
is no need to send FNA. The purpose of the FNA is to confirm
NCoA and/or announce presence. Sorry if it was not clear from
the previous message(s).

> b) If the MN has already arrived at the NAR, it should just send the FNA, which should trigger a tunnel setup with the NAR.

How do you address authorizing traffic re-direction ? FBU
authorizes the PAR to actually start forwarding on the
tunnel.

Again, we went through this discussion at length. For instance,
there is allowance in the draft to set up tunnel using link-layer
indication, but the forwarding on the tunnel begins once
FBU authorizes PAR. We ran a set of issues, and based on the
responses, this (FBU authorization) has been adopted.

> Now we only need some way of securing the FBU exchanged btw the MN and the PAR over the old link. (Same problem as before, but maybe the problem space is more restricted as we only have link local…

Well, if the MN was ever able to establish any SA with PAR,
the same SA can be re-used while sending FBU from
the new link.

Regards,

-Rajeev

---

From: Robert Chalmers <[email-masked]>
Date: Wed, 12 Feb 2003 10:23:47 -0800

Rajeev,

> in this discussion further.
One option that I don't believe has been floated yet is to pull the 
PrRtrSol and PrRtrAdv out of FastMIPv6 entirely, and to use CARD to 
fulfill the roll of providing the map of AP to AR prefix info.  Then, 
the focus of FMIPv6 would be simply to setup forwarding state between 
the ARs, and to possibly pre-configure a new CoA.

Originally, the PrRtr(Sol/Adv) were designed to provide prefix info for 
a single AR. Since the discussion around piggybacking CARD and Fast 
MIPv6 signalling has arisen, the general focus has been to extend the 
use of the PrRtr(Sol/Adv) to carry info for multiple AP/ARs, but of 
course this is what CARD is being designed to do. If you also want to 
push the PrRtr(Sol/Adv) prior to handover, then it sounds like you want 
to do a very specific form of CARD signalling, rather than the other way 
around.

Now, I know that pulling the PrRtr(Sol/Adv) out of FastMIPv6 would 
implicitly create a dependance upon an unyet designed protocol. However, 
it may simplify the design and focus the intent of Fast MIPv6 
considerably, by disengaing the discovery portion of the protocol.

my 2 cents,
bob

-- 
/****************************************************************

  Robert Chalmers
  UCSB Computer Science Doctoral Candidate
  Network and Multimedia Systems Lab (NMSL)

  "My heart is in the code, but my soul lies in the process"

  | [email-masked] || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Feb 2003 11:02:56 -0800

> authorizes the PAR to actually start forwarding on the

MN authorizes traffic redirection through NAR as part of Router Discovery. NAR
initiates tunnel to PAR via HI/HaCK.

Our experiments with this design in MIPv4 indicate that it achieves about the
same performance as prehandover tunneling initiation at high wireless bandwidths
(and only slightly worse performance at lower bandwidths), modulo the lack of
ability to inform the NAR about the upcoming handover, which would allow the NAR
to buffer packets during the link blackout. Of course, if a prehandover trigger
is available on the MN (and only on the MN) some kind of prehandover signaling
from the MN at L3 could be used to initiate the tunnel, and NAR would have the
opportunity to buffer during the link blackout.

> responses, this (FBU authorization) has been adopted.

If the link layer provides the possiblity of resolving the authorization, the
draft should allow the tunnel to be initiated by PAR or NAR without any L3
signaling over the wireless link. The draft currently doesn't do this.

> the same SA can be re-used while sending FBU from

This does not follow, IMHO. The SA will be for a link local address. That
address won't be valid on the new link. RFC 2641 specifically states that the
address on an RA is a link local address, not a global address.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 13 Feb 2003 08:39:06 -0800

Hello Bob,

thank you for your comments.

> the ARs, and to possibly pre-configure a new CoA.

Actually, this has been suggested, but not adopted for few reasons.

- FMIPv6 needs these messages for anticipation, which is
    an integral part of the protocol
- FMIPv6, including anticipation, has been shown to work
    with static configuration
- Even with the revision to move the messages ahead, FMIPV6
   can inter-work with CARD.
- And, of course dependency is not desirable

> a single AR. Since the discussion around piggybacking CARD and Fast

Right. But with 802.11b, it helps to have the neighboorhood
information. FMIPv6 defines a carrier to resolve an AP-Id to
an AR's prefix, and it only requires a canonical listing of
this tuple to get the neighborhood information. Note that
how the tuple is created is beyond FMIPv6, which is perhaps
a natural realm of CARD.

> to do a very specific form of CARD signalling, rather than the other way

We had discussion on this prior to last IETF, and during the
IETF meeting. Based on that discussion, I am indicating the
changes I would like to incorporate..
The purpose is to allow this to happen ahead of handover. This
does not make FMIPv6 depend on anything. I see this as
crucial to allow for better performance (reducing the number of messages
during handover, reduced time for handover state management, etc). And, I
don't see why this cannot work with CARD.

> considerably, by disengaing the discovery portion of the protocol.

The focus and intent of FMIPv6 has been to allow for anticipation
and provide continued packet forwarding without significant delay
compared to what is imparted by the link layer. And, I belive the
proposed revisions are not changing the focus in any way.

> my 2 cents,

Thanks,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 13 Feb 2003 10:49:57 -0800

> opportunity to buffer during the link blackout.

So, this comes down to how to send an equivalent of FBU
through NAR. We need to discuss this further.

> signaling over the wireless link. The draft currently doesn't do this.

Around Yokohama IETF, we had a set of issues (with "AGREE",
"DISAGREE" kind of input from the WG). Based on the outcome of
that, the draft has been revised. So, my understanding is that we have
closed that issue, please :-)
Seriously, we need to move on.

> address on an RA is a link local address, not a global address.

What stops you from establishing an SA for global address ?
Or, even site-local address ? I don't know what is the current
thinking in IPv6 about site-local addresses, but, IF using global
addresses is not desired, site-local addresses are an option.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Feb 2003 11:40:02 -0800

> Seriously, we need to move on.

I don't agree that it is resolved and I will raise it again in last call, and
again in IETF last call with the IESG. It is vital to wireless ISPs that this
capability be available for link layers, like cellular layers, where the link
layer is secure enough to allow the routing fixup to be handled by the network.
If the PAR detects a routing failure by any means and it can determine where to
send the packets, it should be able to utilize that information. We have done
experimental measurements that show having the link layer handle the routing
failure is by far the most reliable way, the measurements are reported in "Fast
Mobile IPv6 Packet Loss Performance" to be presented at WCNC in March.  It
doesn't have to be MUST or even SHOULD, it can be a MAY.

If you don't want to put it into the draft, then we can have it in a separate
draft, but we need this capability.

> addresses is not desired, site-local addresses are an option.

Because router discovery never gives you a global or site local address! Read
RFC 2541 (Section 4.2, Router Advertisement Format):

    IP Fields:
        Source Address
                    MUST be the link-local address assigned to the interface
from which this message is sent.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 13 Feb 2003 13:21:00 -0800

> draft, but we need this capability.

Ok.

> from which this message is sent.

And, Mobile IPv6 extends this with the global address using the
'H' bit.

In any case, if an SA is with a router's link-local address, how would
that hold on some other router ?

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Feb 2003 13:54:34 -0800

> And, Mobile IPv6 extends this with the global address using the

Right and here is what draft-ietf-mobileip-ipv6-20.txt has to say about the H
bit (Section 6.1.7):

Home Registration (H)

      The Home Registration (H) bit is set by the sending mobile node to
      request that the receiving node should act as this node's home
      agent.  The destination of the packet carrying this message MUST
      be that of a router sharing the same subnet prefix as the home
      address of the mobile node in the binding.

An arbitrary access router in a foreign network is not going to share the same
subnet prefix as the home address of the mobile node.

> that hold on some other router ?

That's my whole point, it won't. The SA for ND only holds with nodes that are on
the same link as the interface the router is advertising. The new router has the
same SA, but it only holds with the nodes on the link.

I suppose you can make an AAA based security relationship (I'm not going to say
SA because that has a specific meaning in the context of IPsec) work between a
node on the new router and the old router, but there is still the problem of
getting an address for the router that allows the FBU to get to it from the new
link. RFC 2461 is very specific about this, any interface advertising as a
router MUST use a link local address. I believe that was done for a reason: to
prevent the possibility of off-link nodes obtaining a globally routable address
which they could then use to cause mischief.

            jak

---

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

> considerably, by disengaing the discovery portion of the protocol.

I agree with Rajeev that, we should not split FMIPv6 into two and
transfer discovery to Seamoby. Discovery is an integral part of the
protocol, and it has been there since the beginning. I don't see a
clear benefit of such a split. There might be some harmonization
effort between two protocols if their scope overlaps.

Just to clarify, I'm saying these in the context of front-end of CARD.
Backend of CARD can very well replace the required manual
configuration of L2-L3 information table. That's fine.

alper

---

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

> subnet prefix as the home address of the mobile node.

[this was discussed, but...] When the MN sends a FBU to the oldAR:
care_of address = newCoA
home_address  = oldCoA
home_agent = oldAR

.... as in "forwarding from previous care-of address" mechanism.

So, this is in fact a home registration that complies with the above
text.

alper

---

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

> configuration of L2-L3 information table. That's fine.

If it's not split then there is no point in moving the PrRtSol signaling so that
it is not coupled to handover. CARD provides exactly the same functionality, but
is not coupled to handover.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 13 Feb 2003 16:15:40 -0800

> it is not coupled to handover. CARD provides exactly the same functionality, but

I think there is non-trivial gain without splitting anything.

- fewer messages during handover
- avoid need for handover state establishment and management
   ahead of actual handover (i.e., processing of FBU)
- better chances of anticipating a new CoA
- facilitate faster connectivity in WLAN by allowing the
    MN to associate AP-ID to AR's MAC address and prefix
    information.

All these are possible by moving messages ahead of FBU, and
without needing another protocol.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 13 Feb 2003 16:34:59 -0800

> subnet prefix as the home address of the mobile node.

Actually, even without the 'H' bit, the RA includes the
"Prefix Information Option".

In Section 4.6.2. in 2461,

"Prefix Length  8-bit unsigned integer.  The number of leading bits
                             in the Prefix that are valid.  The value ranges
                             from 0 to 128."

"Prefix         An IP address or a prefix of an IP address.  The
                     Prefix Length field contains the number of valid
                     leading bits in the prefix. ..."

> same SA, but it only holds with the nodes on the link.

So, using link-local SA is not useful, right ?

-Rajeev

---

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

> So, using link-local SA is not useful, right ?

No the FBU/FBaCK is not useful.

I'd like for you to explain to me how the Mobile Node is going to get a globally
routable address for the current last hop router so it can send an FBU/FBaCK to
it from the new link.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 14 Feb 2003 11:01:04 -0800

> routable address for the current last hop router so it can send an FBU/FBaCK to

From an earlier e-mail..

In Section 4.6.2. in 2461 (concerning Prefix Information Option),

                       ^^^^^^^^^^^^

I see no reason why a router cannot provide the global address.

Another option, which I have indicated earlier, is to see if you
would like to restrict the scope to site-local address (again provided
via the Prefix Information option).

Alper made a point that FA's global address is "exposed". Is there
a precedence for DoS ?

A related, perhaps an important, point I would like to make is that
once there is an SA between the MN and its AR (for the non-link-local
address), you would reasonably expect the MN to not misbehave. If this were not
the case, what is the point of authenticating the MN ? Of course one could argue
that authentication does not lead to blanket assurance of innocuous behavior, but
that's a tradeoff you make.
A misbehaving MN could "expose", perhaps quite inadvertantly, the HA's
address to rogue node(s) and could cause DoS for the home link, and may never
get traced. I guess that's an acceptable tradeoff, right ?

-Rajeev