Subject: RE: Issue 13: Omission of prefix options - resolution

From: Soliman Hesham <[email-masked]>
Date: Wed, 5 Nov 2003 01:24:18 -0500

>So we have at least two solutions which provide
>unambiguous prefix indications:
>
>LinkID + Solicited RA (lower overhead)
>Completeness Bit      (simpler)

=> Agreed. Both of those options would solve the problem.

The LinkID + Solicited RA would seem to solve
the movement detection problem quicker than the 
"Completeness" bit. If you can see the LinkID you'd
only solicit if you see a different one. However, with
the completeness bit, you really don't know if you moved
whenever you receive an incomplete RA, right? Meaning, 
a paranoid MN with no other hints, could end up soliciting
for a complete RA more often that in the case where it 
sees the LinkID and know whether it should solicit. 

It seems like the LinkID is a better approach then? Or 
am I missing something?

Hesham

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Nov 2003 08:42:46 +0200 (EET)

> It seems like the LinkID is a better approach then? Or 

Maybe, maybe not.  Can't say for sure yet.  My worry is that we're opening
up a problem we don't understand yet, one for which there basically only
-00 I-D's of.

I can be pretty sure we don't understand the problems and the mechanisms 
to fix those problems well enough yet.

So, the best fix could just be to try to clarify 2461bis, and if 
modifications are required, let them be done separately..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 5 Nov 2003 18:01:35 +0900

> It seems like the LinkID is a better approach then? Or 

There are pro and con between them. For example, if an MN receives a complete 
RA which contains all the prefixes, it can form new CoA immediately. Whereas, if 
it receives a RA which contains  LinkID but no prefixe, an additional RS/ RA 
exchange is needed. 

As Tim Hartrick wrote, the code or bit don't work all by themselves. They are not
sufficient for efficient MD. We need to specify new protocol machinery, which, 
I hope, will be done at DNA quickly. 

Best regards.

JinHyeock 1H>þ°¢¹"ž+¢êfj)bž	b²Ø©¿¨žµú+€fŠx¬¶¶Š÷‘z«ž²Û!¶Úlÿü0ÃXžµú+ƒùšŠYšŸùb²Ø§~â¦þ

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 5 Nov 2003 18:24:59 +0900

> up a problem we don't understand yet, one for which there basically only

I am glad to say that there actually is at least one -01 I-D. :-). 

Movement Detection Optimization in Mobile IPv6
http://www.ietf.org/internet-drafts/draft-daley-mobileip-movedetect-01.txt

Greg Daley and I wrote a few IDs on this problem. 
 
> to fix those problems well enough yet.

I agree. We try to have better understanding at DNA BoF. 
 
> modifications are required, let them be done separately..

We need to specify new operational procedures for efficient MD/ DNA, which 
may be done at DNA BoF. But for them, we need to modify RFC 2461, which 
needs to be done at IPv6 WG, whether it to define a new bit or adopt a new 
Option. 

Best regards

JinHyeockLR¿¬(®H§‚
èº™šŠX§‚X¬¶*oê'~ŠàÙ¢ž+-«b½ä^ªç¬¶Èm¶›?ÿ0Ö'~Šàþf¢–f§þX¬¶)ß£ø©¿

---

From: Markku Savela <[email-masked]>
Date: Wed, 5 Nov 2003 11:30:16 +0200

> From: "JinHyeock Choi" <[email-masked]>

> it receives a RA which contains  LinkID but no prefixe, an additional RS/ RA 

MIP6 should not configure new COA just because it sees RA. It should
always wait until stack has accepted and configured valid address.

Mobile IP6 should be considered as two almost independent components:
MIP6 and Movement detection (MOVD). Something like follows

        IP6 Stack
      ----------
      |        |
    MIP6      MOVD

MIP6 has really no need for messing with RA's. It should just detect
"movement" by the fact that the CoA it has been using has been removed
from the stack. Then it can find a new CoA from the stack, when it
configures.

MOVD may monitore RA's (and use LinkId's or whatever) or use other
Layer2 meeans to detect movement. When it notices that the link has
changed, it only needs an api to prematurely expire the addressess and
prefixes associated with the old link.

This way MIP6 works regardless of the reason why link goes down (even
if it is done manually).

---

From: Benny Amorsen <[email-masked]>
Date: Wed, 05 Nov 2003 14:33:46 +0100

> from the stack. Then it can find a new CoA from the stack, when it

In some cases, imminent death of a CoA is known in advance, and the new
address already available. Would it not make sense to initiate
switchover before the old address finally goes away? With both addresses
working in parallel for a little while, the switchover might not even
lead to a single lost packet.

/Benny