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

From: Soliman Hesham <[email-masked]>
Date: Fri, 7 Nov 2003 05:35:00 -0500

Jim, 

 > I realize hosts today "could" use prefixes from L bit being 
 > set to know
 > its on a new link. But that is not why the L bit is there.  
 > The L bit is
 > there as an optimization to avoid an NS or direct send knowing it is
 > onlink and a fast path could be written to just move the 
 > packet to the
 > link-layer address.  
 > 
 > The reason it is good to not use it is when one does not 
 > want to make an
 > annoucement of all prefixes on a Link and force NS's.  

=> Completely understand, but I was not referring to the L
bit in my email, I was referring to the disappearance
of the _entire_ prefix option. 

I happen to agree with a few people that the best solution
to this problem is to introduce the LinkID which makes
it much simpler to detect movement. 

   The R bit defined in MIPv6 solves
 > the problem below.  When the node reaches the link it will 
 > hear the new
 > RA with R bit set and new router prefix.  So what has to 
 > happen is MIPv6
 > routers have to be turned on to deploy.  But that is ok 
 > because without
 > MIPv6 routers MIPv6 won't work :--)

=> Sure. But in the scenario discussed in this issue, 
the whole prefix option disappears. Therefore, there is
no R bit either. The question is if some router designer
decided to save BW and not advertise all options all
the time. The MN first hears Prefix1 and Prefix2 (from one
or two routers doesn't matter). It derives
a CoA based on Prefix1. The next adv contains Prefix2 only
(because its timer was about to expire and therefore had
to be advertised again, while prefix1 didn't need to. Or
because there were two routers and one of them decided 
that it doesn't need to advertise its prefix this time). 
Now, this might force a movement detection implementation
to think that it _might_ have moved. Depending on how
"conservative" that implemenation is, the reaction
will vary from: "form a new CoA based on prefix2" (not conservative)
to "check that prefix1 and default router are still alive" (conservative). 
If the MN hadn't moved at all (as is the case in this example),
neither action is desirable. 

Having a new option (not suggesting to add that to 2461)
called a LinkID (could be a globally unique address) and
included in every RA sent from all routers on the same link, 
would allow the router to save other options, while 
eliminating movement detection problems.

But since there is no concensus on the solution (some prefer
the "complete bit"), or its inclusion in 2461 (Vs DNA or 
another IPv6 draft), it seems like we should either reject
this issue or delay the discussion until we resolve
all the other issues and hope that opinions have converged
by that time.

 > Help me here I think this is pretty basic stuff :--)  

=> Hope this helps :)  

Hesham

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

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sat, 8 Nov 2003 01:15:33 +0900

Hesham Soliman wrote: 

[Omitted] 
> eliminating movement detection problems.

LinkID solution can prevent MN from assuming movement 
while it has not. But I am afraid, when an MN actually moves, 
LinkID by itself is of limited use.  

Assume an MN actually moves into another link and receives 
an unsolicited RA with only LinkID. To get necessary prefix 
information, an MN should perform additional RS/ RA exchange. 
This will take time because a router is supposed to execute random 
delay before sending RA. 

Otherwise, after movement, an MN may receive a link-layer hint 
notifying link-layer change. Then an MN can sent triggered RS message 
and will receive a solicited RA with all the options. In this case, LinkID 
plays little role.  

> another IPv6 draft), 

I agree with sigh. 

> it seems like we should either reject

I agree. We need more elaboration and IPv6 WG may not be the best 
place for this. 

I have one question. Is it possible for us to define complete bit in DNA? 

>> I believe an IETF spec can extend a core spec and it just needs to be
>> reviewed by that core spec center of expertise without adding to the
>> core spec.  

As Jim wrote above, if DNA spec can extend a core spec, RFC 2461, 
it's O.K. for me to close this issue. 

If not, I am for the delay. 

Best regards

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