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

From: "Woojune Kim" <[email-masked]>
Date: Tue, 11 Feb 2003 18:14:35 -0500

James,

Comments below ..

>> 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.
>
>  

Yes, I was assuming some sort of context transfer was occuring in the network. This coupled with notification by PrRtAdv of the NCOA validity, seems to be enough for some possible optimizations on the MN when it is using a PPP link.

As for PPP context transfer, I thought I had seen a note on the Seamoby list a while back by someone proposing a PPP context transfer as an example of the context transfer protocol usage. (Anyone with better records ?)

thanks

Woojune

---

From: "Woojune Kim" <[email-masked]>
Date: Tue, 11 Feb 2003 18:23:25 -0500

Hi Greg,

Comments below ..

>> 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.
>
>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.
>

Sorry if I was unclear, but I was just trying to say that the MN had the option of doing address configuration on its own schedule. Not that the actual address configuration itself was fast or slow, but that the MN could start it off slowly. I understood James Kempf's earlier comment as such. 

>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.
>
>> 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 ? 
>
>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.
>
>

Yes, I agree. I just asked this of James to confirm my understanding of his proposal. 

> > 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.
> > 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.
>

I agree with you that we should not have to propose changes to the link layer protocols. I was more aiming at showing how PrRtAdv / Sol messages combined with some appropriate PPP context transfer mechanism (something that I had left out in my earlier e-mail as pointed out by James) would enable some intelligent MN / AR implementations to just skip the PPP renegotiation phase. While such a proposal would hinge on both sides of the PPP link being cognizant of such implementations, I don't think it would be impossible. (Each side would just be optimistic and try to skip PPP renegotiation. If either one is unhappy, just initiate renegotiation ..)

thanks

Woojune

---

From: "Woojune Kim" <[email-masked]>
Date: Thu, 13 Feb 2003 16:57:55 -0500

Rajeev,

First of all, I must say that I agree with James that allowing tunnel setup by the NAR would be useful in many cases.

From your simple OK to James' comments it seems you are saying that you want a separate draft. Is this correct ? 

While if that is the only acceptable solution to the WG it cannot be helped, overall I think it would be much better to capture any such possibilities in the FMIPv6 draft. Couldn't just a section or an appendix be added that would describe changes necessary? Any new draft I feel would probably end up overloading whatever tunnel setup mechanisms that would be described in the FMIPv6 just making it harder to make sense of the whole thing. 

(And apologies if I'm a broken record repeating things ..)

thanks

Woojune Kim

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Thursday, February 13, 2003 4:21 PM
To: James Kempf
Cc: Woojune Kim; [email-masked]
Subject: Re: [mobile-ip] Fast Handover document revision

James Kempf wrote:

>
> 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.
>

Ok.

>
> > 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.
> >
>
> 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.
>

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

>             jak

---

From: "Woojune Kim" <[email-masked]>
Date: Tue, 18 Feb 2003 19:44:19 -0500

While it is true that a possible mechanism for advertising a router's global address is in the base MIPv6 spec, as has been pointed out, it was originally designed to support Dynamic HA discovery. It says so very clearly at the beginning of sec 7.2 of MIPv6.

The suggestion in this thread has been that this can be extended to ALL FMIPv6 capable ARs. 

While I am not sure if this is an issue or not, it does significantly extend what I believe is the intent of the MIPv6 draft, where presumably only the HA is supposed to advertise its global address (most of the time, yes I know the text allows all routers!!). 

So the questions is 

1) for the editors / authors of the MIPv6 draft : what was the intent of NOT making only HAs  able to send out their global addresses  ?

2) for IPv6 ND experts : Is there a problem if global addresses of routers is known ? 

BTW can't a node more or less guess a router's global address just from the prefix information and any link layer address ? So is there a problem with advertisements carrying more specific information ? 

thanks

Woojune Kim

>From: Xiaoming Wang [mailto:[email-masked]]
>Sent: Tuesday, February 18, 2003 7:11 PM
>To: Hesham Soliman (EAB); Alper Yegin; James Kempf; Woojune Kim; Rajeev
>Koodli; [email-masked]
>Subject: RE: [mobile-ip] Fast Handover document revision
>
>
>>  > 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.
>>
>> => Claim 2) is incorrect. Any AR can include its global
>> address in the prefix option. See section 7.2 in the MIPv6
>> spec.
>>
>
>In 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"
>Any AR MAY  include its global address in the prefix option, 
>but not MUST.
>For FMIPv6, MAY is not enough, and stronger requirement is 
>necessary (SHOULD
>or MUST).
>
>
>