Subject: [6lowpan] 6lowpan-nd neighbour table collision

From: "Colin O'Flynn" <[email-masked]>
Date: Wed, 6 Oct 2010 17:37:52 +0100

Hello,

I had a question / possible problem with 6lowpan-nd and would appreciate
clarification from the 6lowpan-nd authors or others familiar with it.

Assume you have the following network, for simplicity I've used all fe80::
addresses. I'll bring a hypothetical network up here:

Step #1: Initial State

Border Router: fe80::33:44
                    |
Router 1:      fe80::11:22
                    |
Router 2:      fe80::55:66

Consider router 2. It's neighbor cache (NC) will have the following:

NC:
fe80::11:22

As it cannot talk to fe80::33:44 directly it should not be present in the
NC.

Step #2: New Device attempts to join with address fe80::33:44

Border Router: fe80::33:44
                    |
Router 1:      fe80::11:22
                    |
Router 2:      fe80::55:66
                    |
New Device:    fe80::33:44

Router 2's state:
NC:
fe80::11:22
fe80::33:44 (temporary NCE for 6lowpan-ND)

According to 6lowpan-nd, it will check it's NC and its own address for
collisions. Finding none, it will now attempt multi-hop ND after adding the
temporary NCE.

The ABR is address fe80::33:44 so it will now send a multihop ND message.
The regular IPv6 sending algorithm will first search the NC for connectivity
before sending through the default router (fe80::11:22). 

However - the NC now has an entry for fe80::33:44 so it will attempt to send
directly to this device. Indeed all connectivity for the ABR will be broken
until that temporary NCE times out.

If this is correct I can see two possible solutions:

#1) Update 6lowpan-nd to say that you check the joining node's address is
not in the NC OR the ABR you will be performing multi-hop ND with. It
doesn't matter if the address is of some intermediate node as it will still
result in the default router being used, you just need to check against the
ABR.

#2) Send from a known-unique address and carry the address in the ARO, but I
think this won't be accepted still...

Regards,

  -Colin

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 6 Oct 2010 16:19:03 -0700

Hi Colin,

I'd assume that temporary NCE will not be used for data sending. I think the
purpose of creating temporary NCE is to prevent processing the duplicate
request when the previous one is under flight to/from the 6LBR.

I'd add a flag to the NCE marking it as temporary and will not use for
sending data or determining nexthop resolution. Thus a little modification
is needed in NCE-lookup code in the kernel and the ND response messages
could use the SLLAO for MAC-address and turn the temporary entry to
permanent entry by clearing the flag after DAD verification.

Erik and Zach, do you have similar view on the temporary NCE? Looks like we
need to check the document to see if there is enough clarification.

Thanks,
-Samita

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Colin O'Flynn
> Sent: Wednesday, October 06, 2010 9:38 AM
> To: [email-masked]
> Subject: [6lowpan] 6lowpan-nd neighbour table collision
> 
> Hello,
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Westergreen Mads-MWEST2 <[email-masked]>
Date: Thu, 7 Oct 2010 09:58:31 +0100

Samita,

Wouldn't it just be much simpler to have the short address in an option
instead of adding a temporary NC entry that you don't use.

It would make the ND process much simpler and clean. 

Br,
Mads

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Samita Chakrabarti
Sent: 7. oktober 2010 01:19
To: 'Colin O'Flynn'; [email-masked]
Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision

Hi Colin,

I'd assume that temporary NCE will not be used for data sending. I think
the purpose of creating temporary NCE is to prevent processing the
duplicate request when the previous one is under flight to/from the
6LBR.

I'd add a flag to the NCE marking it as temporary and will not use for
sending data or determining nexthop resolution. Thus a little
modification is needed in NCE-lookup code in the kernel and the ND
response messages could use the SLLAO for MAC-address and turn the
temporary entry to permanent entry by clearing the flag after DAD
verification.

Erik and Zach, do you have similar view on the temporary NCE? Looks like
we need to check the document to see if there is enough clarification.

Thanks,
-Samita

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Colin O'Flynn
> I had a question / possible problem with 6lowpan-nd and would 
> appreciate clarification from the 6lowpan-nd authors or others
familiar with it.
> As it cannot talk to fe80::33:44 directly it should not be present in 
> the NC.
> 

> collisions. Finding none, it will now attempt multi-hop ND after 
> adding
the
> However - the NC now has an entry for fe80::33:44 so it will attempt 
> to
send
> #1) Update 6lowpan-nd to say that you check the joining node's address

> is not in the NC OR the ABR you will be performing multi-hop ND with. 
> It doesn't matter if the address is of some intermediate node as it 
> will
still
> result in the default router being used, you just need to check 
> against
the
> ABR.
> 
> #2) Send from a known-unique address and carry the address in the ARO,

> but
I

---

From: "Colin O'Flynn" <[email-masked]>
Date: Thu, 7 Oct 2010 10:29:59 +0100

Hi Samita,

> I'd assume that temporary NCE will not be used for data sending.

What is the temporary NCE used for anymore? With the errors-to address you
don't need it to send the response, and if the address is successful you
create the NCE before sending the response so it will exist at the correct
point.

Regards,

  -Colin

-----Original Message-----
From: Westergreen Mads-MWEST2 [mailto:[email-masked]] 
Sent: October 7, 2010 9:59 AM
To: Samita Chakrabarti; Colin O'Flynn; [email-masked]
Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision

Samita,

Br,
Mads

-----Original Message-----

Hi Colin,

Thanks,
-Samita

familiar with it.

the
send

still
the

I

---

From: "Colin O'Flynn" <[email-masked]>
Date: Thu, 7 Oct 2010 10:49:51 +0100

...of course the NCE is used for the L2 address if the NA is successful, so
ignore that!

Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Colin O'Flynn
Sent: October 7, 2010 10:30 AM
To: 'Westergreen Mads-MWEST2'; 'Samita Chakrabarti'; [email-masked]
Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision

Hi Samita,

Regards,

  -Colin

-----Original Message-----
From: Westergreen Mads-MWEST2 [mailto:[email-masked]] 
Sent: October 7, 2010 9:59 AM
To: Samita Chakrabarti; Colin O'Flynn; [email-masked]
Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision

Samita,

Br,
Mads

-----Original Message-----

Hi Colin,

Thanks,
-Samita

familiar with it.

the
send

still
the

I

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 7 Oct 2010 11:10:13 -0700

Hi Colin,

I missed one point yesterday in your example, so let's discuss that now (see
in-line in the example scenario):

> > collisions. Finding none, it will now attempt multi-hop ND after

 OK.

> > The ABR is address fe80::33:44 so it will now send a multihop ND

I am not sure I understand this sentence.

Are you talking about the ABRO option 6LBR address?
6LBR Address:  IPv6 address of the 6LBR that is the origin of the
                  included version number

There are two cases: 1) 6LBR is a neighbor of 6LR through which the
duplicate-addressed node is registering  2) 6LBR is multi-hop away from the
6LR

ABRO 6LBR option should carry the global IPv6 address of the 6LBR interface
in route-over scenario. 

Case 1) - Let's assume, 6LR saved fe80::33:44 in its NC since it received
the RA directly from the 6LBR; in this case if a node wants to register with
fe80::33:44, this will be immediately detected before adding a temporary
NCE.

Case 2) 6LBR is multiple hop away from 6LR. If a node tries to register with
fe80::33:44 address, then 6LR will add it in its neighbor cache since there
is no conflict. But it'll send the multihop DAD request to 6LBR's global
IPv6 address. In this case routing table will be consulted and nexthop is
determined to be the next 6LR of MAC address ending with 11:22. The NCE will
be consulted for fe80::11:22. So I don't see any issue here.
When 6LBR received this multihop DAD request it should be able to find out
the conflict with its own address and send an error to the global address of
the sending 6LR.

Are you trying to use route-over topology and link-local IP-addresses over
multiple hops - that is not a correct usage.

-Samita

> From: Colin O'Flynn [mailto:[email-masked]]
> Sent: Thursday, October 07, 2010 2:30 AM
> Of Samita Chakrabarti
the
> Erik and Zach, do you have similar view on the temporary NCE? Looks like
we

---

From: "Colin O'Flynn" <[email-masked]>
Date: Thu, 7 Oct 2010 19:29:25 +0100

Hi Samita,

For clarity I used all link-local addresses, they indeed would normally be
global addresses.

I am talking about case 2. But assume you register with the *exact same*
address of the 6LBR. You will create the temporary NCE with the *exact same*
address of the 6LBR.

Hence you just broke connectivity to the 6LBR, and the multihop-ND will
fail. The connectivity will be broken until the temporary NCE times out.
Depending on the timeouts this could take a bit as the attaching node may
retry a few times, since it won't hear any response to the NS at all. 

Eventually 6lowpan-nd will recover of course, since the attaching node will
try a new address and the temporary NCE will be removed.

Regards,

  -Colin

-----Original Message-----
From: Samita Chakrabarti [mailto:[email-masked]] 
Sent: October 7, 2010 7:10 PM
To: 'Colin O'Flynn'; 'Westergreen Mads-MWEST2'; [email-masked]
Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision

Hi Colin,

 OK.

-Samita

the
we

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 8 Oct 2010 09:41:56 +0200

Hi Colin,

It seems to me that if the addresses are global, presumably built on a
off-link prefix there is no problem.

> before sending through the default router (fe80::11:22). 

Actually what the IPv6 algorithm says is 
"  Next-hop determination for a given unicast destination operates as
   follows.  The sender performs a longest prefix match against the
   Prefix List to determine whether the packet's destination is on- or
   off-link.  If the destination is on-link, the next-hop address is the
   same as the packet's destination address.  Otherwise, the sender
   selects a router from the Default Router List"
"  Once the IP address of the next-hop node is known, the sender
   examines the Neighbor Cache for link-layer information about that
   neighbor."

Best,
Mathilde

---

From: "Colin O'Flynn" <[email-masked]>
Date: Fri, 8 Oct 2010 09:26:12 +0100

Hi Mathilde,

I appreciate the link to that description, as it raises some other questions
for me. In 6lowpan-nd it specifically says that anything but link-local is
off-link, in which case you wouldn't use the NC for anything but link-local
correct?

I had assumed the NC could be used to check if a specific address was
on-link or not in the absence of other information. From RFC4861 definition:

   Neighbor Cache
              - A set of entries about individual neighbors to
                     which traffic has been sent recently.  Entries are
                     keyed on the neighbor's on-link unicast IP address
                     and contain such information as its link-layer
                     address, a flag indicating whether the neighbor is...

But 6lowpan-nd says anything but fe80:: is off-link. Thus if you have a
message to a global prefix device, you always send to the default router?

Thus lacking a routing protocol, how could a 6LR send a NA to a 6LN if that
6LN registered a global address? The 6lowpan-nd-examples currently have
this:

If Status is a Success:

    6LR ---------NA-Reg------->6LN
    Src= LL64 (6LR)
    Dst= GP16 (6LN)
    ARO with Status = 0

If this is 'illegal' then I take full credit for not fully understanding how
IPv6 works in creating that example ;-) But I think other people were
assuming that would work fine as well w/o a routing protocol.

Regards,

  -Colin

-----Original Message-----
From: Mathilde Durvy (mdurvy) [mailto:[email-masked]] 
Sent: October 8, 2010 8:42 AM
To: Colin O'Flynn; [email-masked]
Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision

Hi Colin,

Best,
Mathilde

---

From: Robert Cragie <[email-masked]>
Date: Fri, 08 Oct 2010 12:35:40 +0100

I agree with what Colin says regarding the NCE usage and what 
link-local means for 6lowpan networks.

Just to reiterate on ND: The creation of an NCE to hold the unconfirmed 
IP/LL address of the joining node does not make sense for the reasons 
Colin has clearly outlined. It also contradicts generally the usage of 
options to carry information where statelessness is required, e.g. 
RS/RA. Therefore, as I have said many times before, it makes more sense 
to carry this (these) addresses in the options.

Please note these observations are coming from an interop event with 10 
participants, all using different, real-world platforms based on radios 
and all observing the same issue. Therefore I think this really needs to 
be given proper credence in the working group. I would go so far as to 
say we should change ND to carry the information in the options and 
consider if there are any issues with that. SEND was mentioned, but I 
would like to see a proper explanation of why that is an issue.

We will probably implement an alternative and test that to prove it 
works and would be the right way forward.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 8 Oct 2010 14:14:19 +0200

Hi Colin,

Admittedly I know better 4861 than 6lowpan-nd but I think the "conceptual
sending algorithm" is mostly the same. So let me try to answer based on my
understanding...

[Colin] I appreciate the link to that description, as it raises some other
questions
for me. In 6lowpan-nd it specifically says that anything but link-local is
off-link, in which case you wouldn't use the NC for anything but link-local
correct?
[Mathilde] Correct, although you still need the NC to find the mapping
between the default router IPv6 address and its L2 address 

[Colin] I had assumed the NC could be used to check if a specific address
was
[Mathilde] yes; default router or next-hop as specified by the routing
protocol.

[Colin] Thus lacking a routing protocol, how could a 6LR send a NA to a 6LN
if that
6LN registered a global address? The 6lowpan-nd-examples currently have
this:
If Status is a Success:

    6LR ---------NA-Reg------->6LN
    Src= LL64 (6LR)
    Dst= GP16 (6LN)
    ARO with Status = 0
If this is 'illegal' then I take full credit for not fully understanding how
IPv6 works in creating that example ;-) But I think other people were
assuming that would work fine as well w/o a routing protocol.
[Mathilde] ] My understanding is that registrations are treated differently
as traditional ND entries (or tentative NCE). Like traditional entries they
contain the IPv6 address / l2 address mapping however in terms of
"conceptual sending algorithm behavior" they are more like routing table
entries. 

-----Original Message-----
From: Mathilde Durvy (mdurvy) [mailto:[email-masked]] 
Sent: October 8, 2010 8:42 AM
To: Colin O'Flynn; [email-masked]
Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision

Hi Colin,

Best,
Mathilde

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Oct 2010 15:21:30 +0200

Hi Robert

I agree with what Colin says regarding the NCE usage and what link-local
means for 6lowpan networks.

[Pascal] Same here. That was the 6AO was for up to draft 07 or 8. One
main advantage was to allow many registrations in one message. Another
was that the mechanism was extensible to register other stuff at the
same time, which could be injected in the routing over fabric.

[Pascal] No big harm. You'll have to register the CGA addresses
separately, and build all that are registered together from the same CGA
modifier. This is done in
http://tools.ietf.org/html/draft-thubert-3122bis-01 for example. 

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

Hi Mathilde,
 
I appreciate the link to that description, as it raises some other
questions
for me. In 6lowpan-nd it specifically says that anything but link-local
is
off-link, in which case you wouldn't use the NC for anything but
link-local
correct?
 
I had assumed the NC could be used to check if a specific address was
on-link or not in the absence of other information. From RFC4861
definition:
 
   Neighbor Cache
                     address, a flag indicating whether the neighbor
is...

But 6lowpan-nd says anything but fe80:: is off-link. Thus if you have a
message to a global prefix device, you always send to the default
router?
 
Thus lacking a routing protocol, how could a 6LR send a NA to a 6LN if
that
6LN registered a global address? The 6lowpan-nd-examples currently have
this:
 
If Status is a Success:

If this is 'illegal' then I take full credit for not fully understanding
how
IPv6 works in creating that example ;-) But I think other people were
assuming that would work fine as well w/o a routing protocol.
 
Regards,
 
  -Colin
 
-----Original Message-----
From: Mathilde Durvy (mdurvy) [mailto:[email-masked]] 
Sent: October 8, 2010 8:42 AM
To: Colin O'Flynn; [email-masked]
Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision
 
Hi Colin,

	The ABR is address fe80::33:44 so it will now send a multihop ND
message.
	The regular IPv6 sending algorithm will first search the NC for

connectivity

 
Best,
Mathilde

---

From: "Colin O'Flynn" <[email-masked]>
Date: Fri, 8 Oct 2010 20:09:49 +0100

Hi Mathilde,

> Like traditional entries they

Indeed, then you have this neighbor table collision problem if you use them
as such.

I think 6lowpan-nd is not clear on updating the 'conceptual sending
algorithm' though and how it works over different links. This is especially
a problem for example with mesh-under, where everything is on-link and you
need to send directly.

Regards,

  -Colin

-----Original Message-----
From: Mathilde Durvy (mdurvy) [mailto:[email-masked]] 
Sent: October 8, 2010 1:14 PM
To: Colin O'Flynn; [email-masked]
Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision

Hi Colin,

-----Original Message-----
From: Mathilde Durvy (mdurvy) [mailto:[email-masked]] 
Sent: October 8, 2010 8:42 AM
To: Colin O'Flynn; [email-masked]
Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision

Hi Colin,

connectivity

Best,
Mathilde

---

From: Zach Shelby <[email-masked]>
Date: Wed, 13 Oct 2010 15:06:01 +0300

Hi,

Let me try to summarize on this thread, I do agree with Mathilde that we need to improve the sending algorithm behavior in the draft. I will make a new ticket to deal with these.

First of all, tentative NCE entries were not intended to be used for on-link determination, as Samita pointed out. If we remove the tentative NCE entries from the draft, then this is no issue (see Robert's request). Otherwise we need to clarify this. 

As mentioned below, the sending algorithm does need updating. First of all, the intention was that a normal NCE is used for on-link determination of a global address, as well as for address resolution, as we can't match the prefix in the route-over case. Text should be added on that to Section 5.6. 

Mathilde brought up the mesh-under on-link issue. This is a good point, and I agree that with mesh-under technologies you might want to use the L (on-link) flag of the RA to indicate that the prefix is on-link.  Even in some types of mesh-under networks it might be wise to assume prefixes are off-link, and thus traffic goes through the 6LBR. This change would require the text in Sections 6.1 and Section 5.6 to be updated.

Would these updates resolve the issues brought up in this thread?

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Zach Shelby <[email-masked]>
Date: Wed, 13 Oct 2010 15:21:21 +0300

Robert,

On Oct 8, 2010, at 2:35 PM, Robert Cragie wrote:

> Just to reiterate on ND: The creation of an NCE to hold the unconfirmed IP/LL address of the joining node does not make sense for the reasons Colin has clearly outlined. It also contradicts generally the usage of options to carry information where statelessness is required, e.g. RS/RA. Therefore, as I have said many times before, it makes more sense to carry this (these) addresses in the options.

Please go back and check http://tools.ietf.org/html/draft-ietf-6lowpan-nd-10. Notice that in this version there was no tentative NCE made while multihop-DAD was being performed. Instead all the needed information was carried in an ARO + SLLAO combination, and the NCE was made only after a successful response came back from the 6LBR. Then the WG asked us to change that, and instead make a tentative NCE (which appeared in -11).

My person view is that if the WG does not see a need for the tentative NCE, and just finds it confusing, then I would have no problem removing that and instead carrying the L2 address with the ARO similar to what was done in -10. Notice that this doesn't enable the 6LR to detect a duplicate while an address is being checked by the 6LBR, but it will be detected by the 6LBR instead. A rare case anyways, so I don't see it as an issue.

Note that this issue is orthogonal to the NS/NA+ARO exchange between the 6LN and 6LR. 

Zach

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Oct 2010 14:40:45 +0200

I'm sufficiently confused at this point that I'm really uncomfortable with discussing this with terms like "the L2 address" etc.
There are multiple addresses at multiple layers in multiple states of tentativeness involved, so please invent some terminology so we know which of these we are talking about.  (This only gets more complicated when the purpose of an L3 message it to validate a freshly made up L2 address through validating the L3 address derived from it, while already using some? of these addresses as well as a different L2 address as a fallback for error messages.)

Gruesse, Carsten

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 13 Oct 2010 17:19:01 +0200

Hi Zach,

I think you are giving me undeserved credit. Those were mostly Colin
comments not mine :-)
Although I do agree we need to refine the "conceptual sending algorithm" for
registrations. 

Best,
Mathilde

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: mercredi, 13. octobre 2010 14:06
To: Colin O'Flynn
Cc: Mathilde Durvy (mdurvy); [email-masked]
Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision

Hi,

Let me try to summarize on this thread, I do agree with Mathilde that we
need to improve the sending algorithm behavior in the draft. I will make a
new ticket to deal with these.

First of all, tentative NCE entries were not intended to be used for on-link
determination, as Samita pointed out. If we remove the tentative NCE entries
from the draft, then this is no issue (see Robert's request). Otherwise we
need to clarify this. 

As mentioned below, the sending algorithm does need updating. First of all,
the intention was that a normal NCE is used for on-link determination of a
global address, as well as for address resolution, as we can't match the
prefix in the route-over case. Text should be added on that to Section 5.6. 

Mathilde brought up the mesh-under on-link issue. This is a good point, and
I agree that with mesh-under technologies you might want to use the L
(on-link) flag of the RA to indicate that the prefix is on-link.  Even in
some types of mesh-under networks it might be wise to assume prefixes are
off-link, and thus traffic goes through the 6LBR. This change would require
the text in Sections 6.1 and Section 5.6 to be updated.

Zach

link-local
how

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 19 Oct 2010 18:11:45 -0700

Hi Mads,

> instead of adding a temporary NC entry that you don't use.
[SC>]  My apology for the late response.

A separate option for a secondary address was one of the solutions the
authors discussed before. But this way there might be some compatibility
issues with other existing protocols such as SEND.

BTW, tentative NCE are there to protect the pending registration from being
hijacked by an another node.
If tentative NCE is not recorded, and a multihop DAD request on the way,
then the second node came in and sent the registration request, if the
response of this request arrives earlier than the first request, the wrong
node gets in and the original request is denied.  Also this can induce a
flood of multihop DAD requests from 6LR to 6LBR by an attacker.

So, tentative NCE is useful and the implementation can flag this entry not
to include it in the regular data path.

Thanks,
-Samita

the
we

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 19 Oct 2010 18:46:54 -0700

Hi,

Sorry for the late response.  I know Zach already is taking care of the
issues. Here is one clarification from implementation point of view.

> It seems to me that if the addresses are global, presumably built on a
off-
> link prefix there is no problem.
> 
[SC>]  Agree with Mathilde. There should not be any issue if the
implementation is done right.

Note, that if multihop DAD is implemented for route-over scenario, then some
change in the IPv6-stack is needed. The reason is that we are using same
prefix over multiple hops. 

When the data is sent to the 6LBR's address, it should not first look into
the NCE table because it is an off-link address. It should look into the
routing table and then resolve the nexthop address through Neighbor Cache.

If the implementation is not mindful about this change in behavior, the
traditional behavior might first look into the NCE table thinking that 6LBR
address is a on-link address as it is sharing the same prefix with the
sending interface. This is purely an implementation issue.

If routing protocol is not running, then the packet is sent to the
default-router address. Default-router MAC address is resolved at the NCE. 

The ND message(RA, NA) response to the requestor will be handled separately
and will be sent directly to the requestor.

So, if one runs the multi-hop DAD with route-over topology which is
conceptually different than the concept of regular IPv6 subnet and link,
then some stack code needs to be updated to handle the differences.
However, Erik previously offered a separate message type for multihop DAD -
which should clean-up some of the confusions of overloading NS/NA.

Thanks,
-Samita

message.
> Actually what the IPv6 algorithm says is "  Next-hop determination for a
> given unicast destination operates as

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Oct 2010 15:28:59 +0200

> > Wouldn't it just be much simpler to have the short address in an
> > option instead of adding a temporary NC entry that you don't use.
> >
> node gets in and the original request is denied.  Also this can induce
a flood
> of multihop DAD requests from 6LR to 6LBR by an attacker.

[Pascal]
 I do not find those arguments very convincing:

- An attacker can claim the same address on the next LR and get the same
chances to hijack
- If an attacker has access to the medium, then it can register tons of
different global addresses from a number of forged mac addresses. If he
has access to the geography, then it can simply jam the spectrum.

> 
> So, tentative NCE is useful and the implementation can flag this entry
not to
> include it in the regular data path.

[Pascal] Which illustrates again the danger of mixing the properties and
usages of the registration table and the neighbor cache.
The state that you are talking about (PENDING_VALIDATION_BY_LBR) does
not exist in the classical Neighbor Cache FSM.
It makes a sense to me to keep the table and the cache abstractly
separate - exactly like we did with MIPv6 and the BCE -, because though
the data have a lot in common, the lifecycles and operations are really
different.

> > purpose of creating temporary NCE is to prevent processing the
6LBR.
> > > Assume you have the following network, for simplicity I've used
all
> > fe80::
> > > As it cannot talk to fe80::33:44 directly it should not be present
> > > in the NC.
> > >
> > > directly to this device. Indeed all connectivity for the ABR will
be
> > broken

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 20 Oct 2010 13:12:26 -0700

Hi Pascal,

Please see the response in-line. Thanks.

>  I do not find those arguments very convincing:
[SC>]  The point is that the state is kept for sometime in order to prevent
DOS problems.
In 6lowpan the bandwidth is small and so preventing known DOS problems are
useful.

> different global addresses from a number of forged mac addresses. If he
has
> access to the geography, then it can simply jam the spectrum.
> 
[SC>]  The above examples assume that the node gets L2-access because
L2-access is not secure.

But the problem with tentative NCE can appear from a node with secured
L2-access. A node may have a bad implementation and starts sending hundreds
of registration messages that require multihop DAD. If the state is not
kept, the 6LR will be busy processing and forwarding the same request over
and over.
6lowpan-nd assumes that the L2-layer is secure.

> The state that you are talking about (PENDING_VALIDATION_BY_LBR) does not
> exist in the classical Neighbor Cache FSM.
[SC>] 
      Classical Neighbor Cache does not do Route-over topology either nor
does it support
Multi-hop DAD concept. 

Good that you are talking about the PENDING_VALIDATION state; it is needed.
But, the draft is flexible about how to implement it.
An implementation may keep the classical implementation intact and add a new
table for tentative_NCEs so that the original NCE-table is dedicated to the
fastpath.

As for timing out of existing NCEs - it is also done in the existing
classical NCE. But in case of multihop, the operation is different. Again,
if it makes sense the implementation may maintain a separate data structure
pointer from the NCE flagged for multi-hop verification.

In case of MIP6, the BCE is absolutely needed as the destination was indeed
a neighbor who has changed its IP-address and is no longer a neighbor.  So,
I don't think the tentative NCE is exactly the same as BCE in MIP6.

Regards,
-Samita

> It makes a sense to me to keep the table and the cache abstractly separate
-
> exactly like we did with MIPv6 and the BCE -, because though the data have
a
> lot in common, the lifecycles and operations are really different.
> 
> >
> > Thanks,
> > -Samita
> >