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

From: "Woojune Kim" <[email-masked]>
Date: Tue, 11 Feb 2003 16:15:57 -0500

James,

To summarize your suggestions (please, correct me if I'm wrong)

1. You would prefer to remove address pre-configuration (assuming this is the main aim of doing PrRtAdv/Sol exchanges in FMIPv6)
2. Rely exclusively on tunnel setup (this can be initiated by PAR or NAR depending on when MN / PAR / NAR discover handoff has occured)
3. Do address configuration slowly as data is coming through tunnel.

Assuming this is correct ..

It looks to me like that the tunnel setup mechanisms as suggested by you rely on some sort of L2 Link Layer Address to L3 IP address translation occuring either at the PAR or the NAR. (your suggestion b, c presumably will only send link layer identifiers as you point out that knowing the routers global addresses is not good security). I do not know of any methods that can do this very well, but I guess at the least we could use static tables. I think 802.11 has some methods relying on RADIUS servers etc. in the IAPP specs, but don't know the latest status. Is this correct ? 

At least for PPP connections I think address preconfiguration would be useful as by checking that the NCOA is valid before moving over to the NAR, the MN can then presumably safely use the PPP link with the NAR without having to go through a new PPP IPv6CP negotiation. This is because you can view PPP IPv6CP negotiation as being IPv6 address configuration done over a point to point link. So if the MN's IP stack is intelligent, it should, in most cases, be able to infer that if its NCOA is valid, than its PPP link identifier is also valid and therefore will not need to be renegotiated. Of course, we assume the MN gets the NAR's link identifier through the PrRtAdv. While normally doing this negotiation shouldn't be painful (it should take only a couple of messages) there may be cases where the negotiation may get protracted. These case can disrupt communication due to the fact that for PPP connections (unlike 802.11 connections) you cannot be using the PPP link to transmit / r!
eceive data using the PCOA while PPP IPv6CP negotiations are going on.

>-----Original Message-----
>From: James Kempf [mailto:[email-masked]]
>Sent: Tuesday, February 11, 2003 2:08 PM
>To: Woojune Kim; Rajeev Koodli; [email-masked]
>Subject: Re: [mobile-ip] Fast Handover document revision
>
>
>> >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 ?
>>
>
>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: "James Kempf" <[email-masked]>
Date: Tue, 11 Feb 2003 14:41:16 -0800

> 1. You would prefer to remove address pre-configuration (assuming this is the
main aim of doing PrRtAdv/Sol exchanges in FMIPv6)o
> 2. Rely exclusively on tunnel setup (this can be initiated by PAR or NAR
depending on when MN / PAR / NAR discover handoff has occured)
> 3. Do address configuration slowly as data is coming through tunnel.

If we move the PrRtAdv signaling away from handover, then keeping it in requires
preallocation of addresses in remote subnets, which can lead to more complexity.

If we keep the PrRtAdv tied to handover as currently, then we could recommend
people use the Seamboy CARD protocol for obtaining information on the other
subnets. CARD will not provide preallocation of care of addresses, however.

> It looks to me like that the tunnel setup mechanisms as suggested by you rely
on some sort of L2 Link Layer Address to L3 IP address translation occuring
either at the PAR or the NAR. (your suggestion b, c presumably will only send
link layer identifiers as you point out that knowing the routers global
addresses is not good security). I do not know of any methods that can do this
very well, but I guess at the least we could use static tables. I think 802.11
has some methods relying on RADIUS servers etc. in the IAPP specs, but don't
know the latest status. Is this correct ?

Not quite. If there is no prehandover notification on PAR from the link layer,
but there is on the MN, then the MN must perform some kind of IP layer
signaling. That's the Redirect extension. Similarly, if the MN's L2 simply moves
it to a new link without telling the IP layer or the PAR (as occurs in 802.11),
then an extension to RS would cause the tunnel to be initiated.

Alternatively, if people don't like the idea of a Redirect, we could let the
PrRtSol/PrRtAdv trigger the tunnel set up.

My point is that I don't see the need for the FBU. But I don't want to belabor
the topic because we went through it on the list last fall.

> At least for PPP connections I think address preconfiguration would be useful
as by checking that the NCOA is valid before moving over to the NAR, the MN can
then presumably safely use the PPP link with the NAR without having to go
through a new PPP IPv6CP negotiation. This is because you can view PPP IPv6CP
negotiation as being IPv6 address configuration done over a point to point link.
So if the MN's IP stack is intelligent, it should, in most cases, be able to
infer that if its NCOA is valid, than its PPP link identifier is also valid and
therefore will not need to be renegotiated. Of course, we assume the MN gets the
NAR's link identifier through the PrRtAdv. While normally doing this negotiation
shouldn't be painful (it should take only a couple of messages) there may be
cases where the negotiation may get protracted. These case can disrupt
communication due to the fact that for PPP connections (unlike 802.11
connections) you cannot be using the PPP link to transmit / receive data using
the PCOA while PPP IPv6CP negotiations are going on.

Without some kind of context transfer, I have difficulty seeing how PPP could be
used on the new link without renegotiating the connection. Seamoby is working on
a context transfer protocol, but I don't believe anyone has done a PPP profile
for context transfer yet.

            jak

---

From: Greg Daley <[email-masked]>
Date: Wed, 12 Feb 2003 09:45:13 +1100

Hi Woojune,

Just a comment.

Woojune Kim wrote:
> 1. You would prefer to remove address pre-configuration
 >    (assuming this is the main aim of doing PrRtAdv/Sol
>    exchanges in FMIPv6)
> 2. Rely exclusively on tunnel setup (this can be initiated
 >    by PAR or NAR depending on when MN / PAR / NAR
>    discover handoff has occured)

Address configuration doesn't have to be slow.
Optimistic DAD (for example) can be performed when arriving on
the new link with no significant delay.

On nARs with multicast links, unless the addresses are pre-reserved
(and the nAR has complete state of which addresses are in use),
then DAD has to be performed on the address before the HAck can
be sent back to the pAR (this cannot be optimistic, since the nAR
is vouching for the address' validity for immediate use).
In this case prediction times have to be greater than the RetransTimer
for the new link (typically 1000ms). So the idea that address
configuration is slower on the new link is a fallacy.

Point-to-point links are different though, since DAD may not be
necessary.

> It looks to me like that the tunnel setup mechanisms as
 > suggested by you rely on some sort of L2 Link Layer Address
 > to L3 IP address translation occuring either at the PAR or
 > the NAR. (your suggestion b, c presumably will only send
> link layer identifiers as you point out that knowing the
> routers global addresses is not good security). I do not
> know of any methods that can do this very well, but I
> guess at the least we could use static tables. I think
> 802.11 has some methods relying on RADIUS servers etc.
> in the IAPP specs, but don't know the latest status.
> Is this correct ? 

Regarding L2/L3 lookup on the PAR I think that is
currently seen as outside the scope of FMIPv6 base
protocols (and is a management issue), although
their consideration is important nonetheless.

> At least for PPP connections I think address 
 > preconfiguration would be useful as by checking that the
 > NCOA is valid before moving over to the NAR, the MN can then
 > presumably safely use the PPP link with the NAR without
 > having to go through a new PPP IPv6CP negotiation. This is
 > because you can view PPP IPv6CP negotiation as being
> IPv6 address configuration done over a point to point link.
> So if the MN's IP stack is intelligent, it should, in most
 > cases, be able to infer that if its NCOA is valid, than its
 > PPP link identifier is also valid and therefore will not
> need to be renegotiated. Of course, we assume the MN gets
> the NAR's link identifier through the PrRtAdv. While
> normally doing this negotiation shouldn't be painful
 > (it should take only a couple of messages) there
> may be cases where the negotiation may get protracted.
> These case can disrupt communication due to the fact
> that for PPP connections (unlike 802.11 connections) you
> cannot be using the PPP link to transmit / receive data
 > using the PCOA while PPP IPv6CP negotiations are going on.

I think that we have to be _very_ careful here not to propose
changes to link-layer protocols in order to support FMIPv6.

While what you say about pre-negotiation for p-to-p links
is valid (there may be no need to do DAD). PPP NCP negotiations
are important in many implementations, and making modifications
to how MN's do these negotiations would necessarily cause
problems on some of these systems.

Certainly, if an MN has been informed that a CoA is valid, it
could send this address in a Configure-Request as a hint, but
it's a long time since I read PPP docs, so i'm not sure
what configuration options there are for IPv6CP.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Feb 2003 16:10:06 -0800

> Point-to-point links are different though, since DAD may not be

Not to be pendantic but RFC 2462 says that DAD must be performed on all
addresses.

But, I agree that there should be no reason to perform them if the address is
allocated via PPP.

            jak

---

From: Greg Daley <[email-masked]>
Date: Wed, 12 Feb 2003 16:25:20 +1100

Hi James,

I hadn't read 2461 recently and how
ND multicasting applied to point-to-point links
(have now).

Essentially, IPv6CP is one of those
stateful address configuration mechanisms which I
mentioned.

with two peers, the negotiation is from either peer end:

P1: Configure-Request - requested P1 address

P2: Configure-Request - requested P2 address.

The only case where these are rejected is if
the address is already in use by a peer.

Once IPCP completes, DAD is already complete, since you
know that no other node has the address.
If the systems use SAA, then the node better
send the NS anyway, and defend the address.
I wouldn't wait before using the IPv6CP configured address
though.

Sorry about not being rigourous before.

Greg