Subject: Re: [netlmm] Issue: Link-local address collision on the access link

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 7 Aug 2007 07:58:22 -0700 (PDT)

Option 2 is the best option and since LLA has to be transferred between MAGs establishing the option 3, I think Option 3 is also good. 

Regards,

--behcet

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: [email-masked]
Sent: Tuesday, August 7, 2007 3:15:08 AM
Subject: Re: [netlmm] Issue: Link-local address collision on the access link

Hi Sri, 

Thanks for summarizing the issue. I support solution 2 
(see my comments on the proposed solutions inlined 
below).

> Proposed Solutions:
>
> 1. Configure the DNAv6 Configuration Parameter
>
> One of the workarounds for this issue is to set the
> DNAv6 configuration parameter, DNASameLinkDADFlag to
> TRUE and that will force the mobile node to redo DAD
> operation every time the interface comes up, even
> when DNAv6 stack on the mobile node does not detect
> a link change .

If the MN is forced to redo DAD after each handover, 
this will severely impact the handover performance of 
NETLMM since upon each handover a MN will have to wait 
for DAD completion before transitioning its address 
from tentative to assigned state. With the default DAD 
parameters (i.e. DupAddrDetectTransmits is 1 and 
RetransTimer is RETRANS_TIMER = 1000 milliseconds) 
that means that the MN will not be able to communicate 
for 1 second. 

I thought that the bad effects of DAD could be 
alleviated by having the router (MAG) overriding the 
default value of RetransTimer with a lower value. 

This is however not possible since RFC2462 says that 
1) "in some link-layer environments, particularly with 
MLD-snooping switches, no multicast reception will be 
available until the MLD report is sent", and 2) "a 
node SHOULD delay joining the solicited-node multicast 
address by a random delay between 0 and 
MAX_RTR_SOLICITATION_DELAY". There is hence a 
possibility that the MN doesn't not receive multicast 
traffic sent to the solicited-node address and thus 
can't detect a duplicate address. Therefore, it 
doesn't seem safe to reduce RetransTimer to less than 
MAX_RTR_SOLICITATION_DELAY (1 second) if we want to 
keep DAD robust.

> 2. Upload the link-local address of the mobile node
> to the mobile node's policy profile.

This is what I've been suggesting and I think that's 
the best solution out of the four listed in your note.

> 3. Establish domain-wide link-local address
> uniqueness.

We discussed that many time and concluded that it is 
problematic when multiple LMAs are used in a single 
NetLMM domain.

> 4. MAG should always do a DAD when ever it detects a
> new mobile node on its access link.

This has the same issue as 1. above since it means that 
the MAG won't be able to communicate before DAD 
completes after each handover, i.e. 1 second service 
interruption.

Thus I support option 2.

--julien

On Tuesday 07 August 2007, Sri Gundavelli wrote:
> This issue was discussed with Julien on quite a few
> threads.
>
> The issue is related to establishing the link-local
> address uniqueness on the access link and when DNAv6
> is enabled on the mobile node.
>
> Even though the odds are extremly low, 1:billion,
> the possibility of a link-local address collision on
> a point-to-point link and between the MAG and the
> MN. But, for the sake of completeness we need to do
> some thing here. There is higher probability for the
> network going down due to million other reasons as
> supposed to due to link-local address collision on a
> p2p link.
>
> Also, IMO, this is primarily due to the missing
> semantics in 2461 for an access router to force a
> node to do DAD operation on demand. DAD is designed
> with the fixed view of the network. A node joining a
> LAN will do a DAD and enter the game and after that
> only the new nodes joining that link will do the DAD
> operation. NETLMM modifies this view slightly. A
> mobile node in the NETLMM domain always thinks its
> still on the same link, but, it has a new neighbor
> after each handoff. Interstingly, DNAv6 makes it
> worse by supressing the DAD operation after a link
> up/down event.
>
>
> Proposed Solutions:
>
> 1. Configure the DNAv6 Configuration Parameter
>
> One of the workarounds for this issue is to set the
> DNAv6 configuration parameter, DNASameLinkDADFlag to
> TRUE and that will force the mobile node to redo DAD
> operation every time the interface comes up, even
> when DNAv6 stack on the mobile node does not detect
> a link change .
>
>
> 2. Upload the link-local address of the mobile node
> to the mobile node's policy profile.
>
>
> 3. Establish domain-wide link-local address
> uniqueness.
>
>
> 4. MAG should always do a DAD when ever it detects a
> new mobile node on its access link.
>
>
> IMO, option#3 is out of question. Please comment.
>
> Sri
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 15 Aug 2007 08:30:51 -0700 (PDT)

Hi Jonne,
  If MAG is not the default router, I am afraid PMIPv6 route optimization will not be possible.
  In MIPv4, FA is the default router and PMIPv6 MAG acts very much like an FA as per the base draft, so MAG should also be the default router.

Regards,

Behcet

----- Original Message ----
From: Soininen Jonne (NSN - FI/Espoo) <[email-masked]>
To: ext Julien Laganier <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, August 15, 2007 7:20:37 AM
Subject: Re: [netlmm] Issue: Link-local address collision on the access link

Julien,

ext Julien Laganier wrote:
> On Tuesday 14 August 2007, Soininen Jonne (NSN - 
> FI/Espoo) wrote:
>   
>> Hello everybody,
>>     
>
> Hi Jonne,
>
>   
>> *chair hat off*
>>
>> Very stupid question, 
>>     
>
> There's no such thing, only stupid answers :)
>   

No, believe me: There are also stupid questions. My mail might help to 
prove the fact... ;)

>   
>> very late state in the protocol discussion: Why does
>> the MAG have to be the default router? If the LMA
>> would be the default router (and would send the RA)
>> the DAD wouldn't have to be done at every handover as
>> the risk of having overlapping addresses would go
>> away. 
>>     
>
> Let's give the stupid answer first so that I'm sure I 
> won't say it later: That's always been the assumption 
> that the MAG is the default router :)
>   

This much I knew already... ;)
> More seriously: If we want the LMA to be the default 
> router we either need:
>
> 1- an L2 tunnel between MAG and LMA (and need to 
> analyse the consequences of that w.r.t. 
> multi-access-techologies NETLMM domains.)
>   

The tunnel between MAG and LMA is already an "L2-tunnel" in a way. It is 
an IP in IP tunnel, which is invisible for the end-host. There is no 
need for any special L2-tunnel functionality, if that's what you mean.

> 2- the MAG to be an IP layer bridge, and we should 
> specify the behavior of that IP layer bridge, how that 
> operate.
>   

The MAG just forwards everything coming from access to the appropriate 
tunnel and vice versa. There is not too much to specify there... (OK, 
I'm a bit simplifying it here...)

> 3- the MAG to be a ND proxy [RFC4389]. That has problem 
> with Secure Neighbor Discovery. That would also be a 
> downref since 4389 is experimental.
>   

The MAG does not have to be an ND proxy. As the MAG just forwards 
packets without processing them it would in a way work like a L2 bridge. 
ND proxy is definitely not needed.

> So I'd say that it is not so as easy as saying "the LMA 
> is the default router" since each of 1-3 above needs 
> some work (And there's also quite some work to do to 
> have the WG reaching consensus on choosing one of the 
> solution above ;)
>
> It's good that you ask the question. I'd like to hear 
> other folks' opinions?
>   
Look, I don't have in any way strong feelings about this. Either way is 
ok for me. However, the trade-off in my opinion, which is more difficult 
and wastes more resources: Doing DAD on every handover or making sure 
the MAG and the host addresses never collide, or to define LMA as the 
default router. I'm sure both sides have pros and cons. Though, I didn't 
want to start any project now deeply analyze these, I just wanted to 
raise awareness about the fact that the architecture of PMIP in this 
regard can be changed if the current architecture seems difficult to 
realize...

Cheers,

Jonne.