Subject: Re: [6lowpan] NS source address in nd-09

From: "Reddy, Joseph" <[email-masked]>
Date: Wed, 2 Jun 2010 19:48:39 -0500

Hi Erik,

Another possible solution to the handling of the neighbor cache 

If we allow the multihop NS/NA packets ( between the 6LR and 6LBR ) to carry the SLLA option in their payload, that will negate the need for the 6LR to create an NCE entry imemdiately. Instead it can wait until it gets a succesful response from the 6LBR

-Regards, Joseph

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Sunday, May 30, 2010 5:51 AM
To: Reddy, Joseph
Cc: [email-masked]
Subject: Re: [6lowpan] NS source address in nd-09

On 05/28/10 04:29 PM, Reddy, Joseph wrote:
>
> Hi Erik,
>
>>> Is there a reason why the unspecified address is not used for the 
>>> source ( and include the address in the ARO option ) like in classic 
>>> ND ?
>
>> RFC 4861 only allows the unspecified source address in NS message for 
>> the purposes of DAD, which is integral to using multicast packets for 
>> DAD.
>
>> Is there a reason to use the unspecified address in some new way?
>
> [JSR] The reason would be the handling of neighbor cache on the parent 
> router. In the current draft, it is possible that an inaccurate 
> neigbor cache entry is temporarily created on a Router and that could 
> lead to potential problems.
>
> Consider a scenario where Host1 registers its address with Router1 and 
> succesfully undergoes multihop DaD
>
> Now suppose Host2 attempts to register the same IP address with 
> Router2. While the multihop DaD is ongoing, Router2 will have a 
> neighbor cache entry with the duplicate IP address ( that actually 
> belongs to Host1 ) and the LL address of Host2 ( note that is 
> necessary for the Router2 to create a neighbor cache entry at this 
> stage, otherwise the SLLA of Host2 would not be available later to 
> send the NA ).

I see some more care is needed in the specification around multihop DAD. 
In the case of multihop DAD I don't think the 6LR should create a Neighbor Cache entry until DAD has been verified. A possible way to handle not forgetting the SLLA (to be able to respond as you point out) would be to create a NCE but mark it as "unverified". Then an unverified NCE can be be used to send the response to the host, and if the response was "ok" then the unverified NCE would become a normal NCE, otherwise it would be deleted.

This means that in the case of two hosts attached to the same 6LR try to use the same IP address at the same time, then the 6LR might end up with two unverified NCEs for the same IP address; at most one of those will "win" as determined by the 6LBR(s). Thus when a response comes from the 6LBR the 6LR will use the IPv6 address plus the EUI-64 to find any "unverified" NCE.

In any case, I don't see how using the unspecified source address would make this any easier. The fundamental issue is that an 6LR needs to retain sufficient information about a host while multihop DAD is in progress, and not let that "in progress" information be confused with authoritative and verified registrations.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 02 Jun 2010 23:59:01 -0700

On 06/ 2/10 05:48 PM, Reddy, Joseph wrote:
> If we allow the multihop NS/NA packets ( between the 6LR and 6LBR )
> to carry the SLLA option in their payload, that will negate the need
> for the 6LR to create an NCE entry imemdiately. Instead it can wait
> until it gets a succesful response from the 6LBR

Good idea.
I essence this is just information that is carried "through" the 6LBR 
without it acting on it, and it means that the 6LR doesn't have to 
create any "unverified" state.

    Erik

> -Regards, Joseph
>
>
> -----Original Message----- From: Erik Nordmark
> [mailto:[email-masked]] Sent: Sunday, May 30, 2010 5:51 AM
> To: Reddy, Joseph Cc: [email-masked] Subject: Re: [6lowpan] NS
> source address in nd-09
>
>>>> Is there a reason why the unspecified address is not used for
>>>> the source ( and include the address in the ARO option ) like
>>>> in classic ND ?
>>
>>> RFC 4861 only allows the unspecified source address in NS message
>>> for the purposes of DAD, which is integral to using multicast
>>> packets for DAD.
>>
>> [JSR] The reason would be the handling of neighbor cache on the
>> parent router. In the current draft, it is possible that an
>> inaccurate neigbor cache entry is temporarily created on a Router
>> and that could lead to potential problems.
>>
>> Consider a scenario where Host1 registers its address with Router1
>> and succesfully undergoes multihop DaD
>>
> I see some more care is needed in the specification around multihop
> DAD. In the case of multihop DAD I don't think the 6LR should create
> a Neighbor Cache entry until DAD has been verified. A possible way to
> handle not forgetting the SLLA (to be able to respond as you point
> out) would be to create a NCE but mark it as "unverified". Then an
> unverified NCE can be be used to send the response to the host, and
> if the response was "ok" then the unverified NCE would become a
> normal NCE, otherwise it would be deleted.
>
> This means that in the case of two hosts attached to the same 6LR try
> to use the same IP address at the same time, then the 6LR might end
> up with two unverified NCEs for the same IP address; at most one of
> those will "win" as determined by the 6LBR(s). Thus when a response
> comes from the 6LBR the 6LR will use the IPv6 address plus the EUI-64
> to find any "unverified" NCE.
>
>
> In any case, I don't see how using the unspecified source address
> would make this any easier. The fundamental issue is that an 6LR
> needs to retain sufficient information about a host while multihop
> DAD is in progress, and not let that "in progress" information be
> confused with authoritative and verified registrations.
>
> Erik