Subject: [6lowpan] ND Short Address Collisions

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 17 Aug 2010 21:08:45 +0100

Hello,

I had some questions/concern about 6lowpan-ND:

#1)

I know there was much discussion about handling the case when a node
registers to a parent, and that parent already has a node registered to it
with the same address (or it is the parents address), and how to route the
response back.

I'm not convinced the addition of a 'temporary' NC makes a lot of sense to
be honest. I think a better solution is to explicitly spell out in
6lowpan-ND what happens when the case of a response not being received
occurs.

The easiest solution I can think of is that after sending
MAX_UNICAST_SOLICIT times, you take the same action as if you had a
duplicate address. You try that maybe 3 times, and if it still fails select
another router (if available). 

Then what happens in the case of a duplicate entry, is the NA is routed to
the wrong device or yourself. It will throw it away since it is either not
expecting the ARO, and/or the EUI-64 does not match in the ARO. It takes an
extra few messages since the target will be re-trying but the chances of
this are minimal at least.

#2)

An interesting aspect of the above is that when the NA is sent back, there
are actually two nodes listening they will both send an 802.15.4 ACK. This
will result in a collision and the parent may not actually hear the ACK,
resulting it in thinking a failure occurred at the 802.15.4 layer. 

We may not care about this, but if someone ties together the failure at the
802.15.4 layer to higher layers it might result in unnecessary traffic. 

#3)

Considering the above, what was so wrong with sending from a known-unique
IPv6 address for that first hop?

There is zero added complexity, and a minimal overhead in terms of bytes.
Since you are carrying the EUI-64 inline you actually already have that
nodes address anyway, and could eliminate the SLLAO from the initial NS if
wanted (this could be a link-specific optimization , and need not be part of
6lowpan-ND).

Indeed the best idea would be to send from the link-local address based on
the EUI-64. Nodes which are using mostly 'plain' ND with special extensions
would still work fine in their neighbor table. Nodes which are specially
programmed could avoid needing an entry in the neighbor table since they can
form the destination of the NA based on the EUI-64. 

Regards,

   -Colin

---

From: Dario Tedeschi <[email-masked]>
Date: Tue, 17 Aug 2010 16:48:14 -0700

Hi Colin

I'm all for item #3. It makes handling of IP address conflicts simpler,
helps avoid media-access issues (like you mention in #2) and is more
inline with the IPv6 paradigm.

Dario

Colin O'Flynn wrote:

Hello,

#1)

I know there was much discussion about handling
the case
when a node registers to a parent, and that parent already has a node
registered to it with the same address (or it is the parents address),
and how
to route the response back.

I’m not convinced the addition of a ‘temporary’
NC makes a lot of sense to be honest. I think a better solution is to
explicitly spell out in 6lowpan-ND what happens when the case of a
response not
being received occurs.

The easiest solution I can think of is that
after sending MAX_UNICAST_SOLICIT
times, you take the same action as if you had a duplicate address. You
try that
maybe 3 times, and if it still fails select another router (if
available).

Then what happens in the case of a duplicate
entry, is the
NA is routed to the wrong device or yourself. It will throw it away
since it is
either not expecting the ARO, and/or the EUI-64 does not match in the
ARO. It
takes an extra few messages since the target will be re-trying but the
chances
of this are minimal at least.

#2)

An interesting aspect of the above is that when
the NA is
sent back, there are actually two nodes listening they will both send
an
802.15.4 ACK. This will result in a collision and the parent may not
actually hear
the ACK, resulting it in thinking a failure occurred at the 802.15.4
layer.

We may not care about this, but if someone ties
together the
failure at the 802.15.4 layer to higher layers it might result in
unnecessary traffic.

#3)

Considering the above, what was so wrong with
sending from a
known-unique IPv6 address for that first hop?

There is zero added complexity, and a minimal
overhead in
terms of bytes. Since you are carrying the EUI-64 inline you actually
already
have that nodes address anyway, and could eliminate the SLLAO from the
initial
NS if wanted (this could be a link-specific optimization , and need not
be part
of 6lowpan-ND).

Indeed the best idea would be to send from the
link-local
address based on the EUI-64. Nodes which are using mostly ‘plain’
ND with special extensions would still work fine in their neighbor
table. Nodes
which are specially programmed could avoid needing an entry in the
neighbor
table since they can form the destination of the NA based on the
EUI-64.

Regards,

-Colin

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Robert Cragie <[email-masked]>
Date: Wed, 18 Aug 2010 05:51:41 +0100

I did raise this at the IETF meeting in Maastricht but let's say it 
wasn't met with universal approval. What was put in was a tentative NCE, 
which is better than what was there before but still has the issues 
Colin has pointed out below. I have always thought the right way is to 
carry the 16-bit tentative MAC address in the ARO option all the way to 
the ABRO, which then really just views it as a number at that point. 
Only when it finally gets back to the joining node does it then become a 
true MAC address and is then autoconfigured as an IPv6 address.

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/>

On 18/08/2010 12:48 AM, Dario Tedeschi wrote:
> Hi Colin
>
> I'm all for item #3. It makes handling of IP address conflicts 
> simpler, helps avoid media-access issues (like you mention in #2) and 
> is more inline with the IPv6 paradigm.
>
> Dario
>
> Colin O'Flynn wrote:
>>
>> Hello,
>>
>> registers to a parent, and that parent already has a node registered 
>> to it with the same address (or it is the parents address), and how 
>> I'm not convinced the addition of a 'temporary' NC makes a lot of 
>> sense to be honest. I think a better solution is to explicitly spell 
>> out in 6lowpan-ND what happens when the case of a response not being 
>> received occurs.
>>
>> duplicate address. You try that maybe 3 times, and if it still fails 
>> select another router (if available).
>>
>> Then what happens in the case of a duplicate entry, is the NA is 
>> routed to the wrong device or yourself. It will throw it away since 
>> it is either not expecting the ARO, and/or the EUI-64 does not match 
>> in the ARO. It takes an extra few messages since the target will be 
>> re-trying but the chances of this are minimal at least.
>>
>> #2)
>>
>> An interesting aspect of the above is that when the NA is sent back, 
>> there are actually two nodes listening they will both send an 
>> actually hear the ACK, resulting it in thinking a failure occurred at 
>> the 802.15.4 layer.
>>
>> We may not care about this, but if someone ties together the failure 
>> at the 802.15.4 layer to higher layers it might result in unnecessary 
>> traffic.
>>
>> #3)
>>
>> Considering the above, what was so wrong with sending from a 
>> There is zero added complexity, and a minimal overhead in terms of 
>> bytes. Since you are carrying the EUI-64 inline you actually already 
>> have that nodes address anyway, and could eliminate the SLLAO from 
>> the initial NS if wanted (this could be a link-specific optimization 
>> , and need not be part of 6lowpan-ND).
>>
>> Indeed the best idea would be to send from the link-local address 
>> based on the EUI-64. Nodes which are using mostly 'plain' ND with 
>> special extensions would still work fine in their neighbor table. 
>> Nodes which are specially programmed could avoid needing an entry in 
>> the neighbor table since they can form the destination of the NA 
>> based on the EUI-64.
>>
>> Regards,
>>
>>    -Colin
>>
>> ------------------------------------------------------------------------
>>

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 18 Aug 2010 10:57:53 -0700

Robert Cragie wrote:

I did raise this at the IETF meeting in Maastricht but let's say it
wasn't met with universal approval. What was put in was a tentative
NCE, which is better than what was there before but still has the
issues Colin has pointed out below. I have always thought the right way
is to carry the 16-bit tentative MAC address in the ARO option all the
way to the ABRO, which then really just views it as a number at that
point. Only when it finally gets back to the joining node does it then
become a true MAC address and is then autoconfigured as an IPv6
address.

Are you then advocating removing the IP address field in the ARO
entirely and replacing it with a 16bit MAC address field? If yes, then
how would a node register an arbitrary IPv6 Address (i.e. having an IID
not derived from the 16bit MAC address). On some nodes, it would be
nice to allow an administrator to manually configure an IPv6 address
and still have the network perform DAD on that address. There may be
cases where a node needs a static IP address (e.g. a node providing
some kind of name-service in the PAN).

Robert

Gridmerge Ltd.

89 Greenfield Crescent,

Wakefield, WF4 4WA, UK

+44 1924 910888

+1 415 513 0064

http://www.gridmerge.com

Hi Colin

Dario

Colin O'Flynn wrote:

Hello,

I had some questions/concern about
6lowpan-ND:

#1)

I know there was much discussion about
handling the case when a node registers to a parent, and that parent
already has a node registered to it with the same address (or it is the
parents address), and how to route the response back.

I’m not convinced the addition of a
‘temporary’ NC makes a lot of sense to be honest. I think a better
solution is to explicitly spell out in 6lowpan-ND what happens when the
case of a response not being received occurs.

The easiest solution I can think of is that
after sending MAX_UNICAST_SOLICIT times, you take the same action as if
you had a duplicate address. You try that maybe 3 times, and if it
still fails select another router (if available).

Then what happens in the case of a duplicate
entry, is the NA is routed to the wrong device or yourself. It will
throw it away since it is either not expecting the ARO, and/or the
EUI-64 does not match in the ARO. It takes an extra few messages since
the target will be re-trying but the chances of this are minimal at
least.

#2)

An interesting aspect of the above is that
when the NA is sent back, there are actually two nodes listening they
will both send an 802.15.4 ACK. This will result in a collision and the
parent may not actually hear the ACK, resulting it in thinking a
failure occurred at the 802.15.4 layer.

We may not care about this, but if someone
ties together the failure at the 802.15.4 layer to higher layers it
might result in unnecessary traffic.

#3)

Considering the above, what was so wrong
with sending from a known-unique IPv6 address for that first hop?

There is zero added complexity, and a
minimal overhead in terms of bytes. Since you are carrying the EUI-64
inline you actually already have that nodes address anyway, and could
eliminate the SLLAO from the initial NS if wanted (this could be a
link-specific optimization , and need not be part of 6lowpan-ND).

Indeed the best idea would be to send from
the link-local address based on the EUI-64. Nodes which are using
mostly ‘plain’ ND with special extensions would still work fine in
their neighbor table. Nodes which are specially programmed could avoid
needing an entry in the neighbor table since they can form the
destination of the NA based on the EUI-64.

Regards,

-Colin

---

From: Westergreen Mads-MWEST2 <[email-masked]>
Date: Wed, 18 Aug 2010 15:14:23 +0100

I also agree with this approach!.

Br,

Mads Westergreen

Senior Platform Architect, Wireless Connectivity Operation
Freescale Semiconductor

Mobile: +45 20 31 45 03
e-mail [email-masked]

This e-mail, and any associated attachments have been classified as:
[ ] Freescale Semiconductor General Business
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Robert Cragie
Sent: 18. august 2010 06:52
To: Dario Tedeschi
Cc: [email-masked]
Subject: Re: [6lowpan] ND Short Address Collisions

Robert

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

Hi Colin

Dario

Colin O'Flynn wrote: 

Hello,

#1)

I know there was much discussion about handling the case when a node
registers to a parent, and that parent already has a node registered to
it with the same address (or it is the parents address), and how to
route the response back.

I'm not convinced the addition of a 'temporary' NC makes a lot of sense
to be honest. I think a better solution is to explicitly spell out in
6lowpan-ND what happens when the case of a response not being received
occurs.

Then what happens in the case of a duplicate entry, is the NA is routed
to the wrong device or yourself. It will throw it away since it is
either not expecting the ARO, and/or the EUI-64 does not match in the
ARO. It takes an extra few messages since the target will be re-trying
but the chances of this are minimal at least.

#2)

An interesting aspect of the above is that when the NA is sent back,
there are actually two nodes listening they will both send an 802.15.4
ACK. This will result in a collision and the parent may not actually
hear the ACK, resulting it in thinking a failure occurred at the
802.15.4 layer. 

We may not care about this, but if someone ties together the failure at
the 802.15.4 layer to higher layers it might result in unnecessary
traffic. 

#3)

There is zero added complexity, and a minimal overhead in terms of
bytes. Since you are carrying the EUI-64 inline you actually already
have that nodes address anyway, and could eliminate the SLLAO from the
initial NS if wanted (this could be a link-specific optimization , and
need not be part of 6lowpan-ND).

Indeed the best idea would be to send from the link-local address based
on the EUI-64. Nodes which are using mostly 'plain' ND with special
extensions would still work fine in their neighbor table. Nodes which
are specially programmed could avoid needing an entry in the neighbor
table since they can form the destination of the NA based on the EUI-64.

Regards,

   -Colin

________________________________

---

From: "Colin O'Flynn" <[email-masked]>
Date: Sat, 21 Aug 2010 12:45:21 +0100

Hello,

Would there be support for putting in 6lowpan-ND that you must send from an
address based on the EUI-64 instead of anticipated 16-bit address? I think
it is more consistent with what is already in 6lowpan-ND. Consider the
following:

>From the assumptions section of 6lowpan-ND, we have:

   o  EUI-64s are globally unique.

   o  All nodes in the LLN have an EUI-64 interface identifier in order

      to do address auto-configuration and detect duplicate addresses.

Thus 6lowpan-ND is already assuming we have a link-local address based on an
EUI-64. Based on those two assumptions you could greatly simplify processing
of NA by performing the following when you receive a NA message:

       [1] Is the EUI-64 my address? If so skip to general processing (not
shown here)

       [2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing
more to do.

       [3] Generate an address by performing the address autoconfiguration

               algorithm on the EUI64 in the ARO with the link-local prefix

       [4] Forward the message to the address generated in step 3,
recalculating ICMPv6 checksum

Such a setup has the following disadvantages:

 -You ALWAYS transmit the registered address in the ARO on first hop,
wasting 16 bytes

But the following advantages:

-Cannot have collision of two 802.15.4 ACK's because you are transmitting to
two nodes at once

-Less FLASH usage, since you have removed temporary NCE, and always use the
same ARO Length which further simplifies code

-Less SRAM usage, since you never need a neighbor cache entry for multi-hop
DAD to complete

-ARO registered address can be changed by ABR. For example if ABR notices a
node is re-registering after that node reboots, the ABR could change
registered address to nodes old address in NA it sends back.

-Avoids "hacks" when sending last-hop NA. By "hack" I mean that people may
just take registered address out of ARO, and send 802.15.4 message to lower
16 bits of registered address, since they are only every registering GP16
addresses in their case. By instead explicitly using EUI-64 to generate
address, you decouple the registered IPv6 address from the MAC address used
during registration. Thus the same code could in the future be used to
register any address, not just GP16 addresses. It is only the final hop that
knows if there should be any correlation between IPv6 address & 802.15.4
address, not intermediate nodes.

-Does not need SLLAO in initial NS

Comments?

  -Colin

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Westergreen Mads-MWEST2
Sent: August 18, 2010 3:14 PM
To: [email-masked]; Dario Tedeschi
Cc: [email-masked]
Subject: Re: [6lowpan] ND Short Address Collisions

Br,

Mads Westergreen

Mobile: +45 20 31 45 03

 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Robert Cragie
Sent: 18. august 2010 06:52
To: Dario Tedeschi
Cc: [email-masked]
Subject: Re: [6lowpan] ND Short Address Collisions

I did raise this at the IETF meeting in Maastricht but let's say it wasn't
met with universal approval. What was put in was a tentative NCE, which is
better than what was there before but still has the issues Colin has pointed
out below. I have always thought the right way is to carry the 16-bit
tentative MAC address in the ARO option all the way to the ABRO, which then
really just views it as a number at that point. Only when it finally gets
back to the joining node does it then become a true MAC address and is then
autoconfigured as an IPv6 address. 

Robert

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

Hi Colin

I'm all for item #3. It makes handling of IP address conflicts simpler,
helps avoid media-access issues (like you mention in #2) and is more inline
with the IPv6 paradigm.

Dario

Colin O'Flynn wrote: 

Hello,

#1)

#2)

#3)

Regards,

   -Colin

  _____

---

From: Dario Tedeschi <[email-masked]>
Date: Mon, 23 Aug 2010 10:26:25 -0700

I support this idea.

Colin O'Flynn wrote:

Hello,

Would
there be support for
putting in 6lowpan-ND that you must send from an address based on the
EUI-64
instead of anticipated 16-bit address? I think it is more consistent
with what
is already in 6lowpan-ND. Consider the following:

From the
assumptions section of
6lowpan-ND, we have:

o  All nodes in the LLN have an EUI-64
interface identifier in order

to do address
auto-configuration and detect duplicate addresses.

Thus
6lowpan-ND is already
assuming we have a link-local address based on an EUI-64. Based on
those two
assumptions you could greatly simplify processing of NA by performing
the
following when you receive a NA message:

more to
do.

[4]
Forward the message to the address generated in step 3, recalculating
ICMPv6
checksum

Such a
setup has the following
disadvantages:

-You
ALWAYS transmit the registered
address in the ARO on first hop, wasting 16 bytes

But the
following advantages:

-Cannot
have collision of two 802.15.4
ACK’s because you are transmitting to two nodes at once

-Less
FLASH usage, since you
have removed temporary NCE, and always use the same ARO Length which
further
simplifies code

-Less
SRAM usage, since you
never need a neighbor cache entry for multi-hop DAD to complete

-ARO
registered address can be
changed by ABR. For example if ABR notices a node is re-registering
after that
node reboots, the ABR could change registered address to nodes old
address in
NA it sends back.

-Avoids
“hacks” when
sending last-hop NA. By “hack” I mean that people may just take
registered address out of ARO, and send 802.15.4 message to lower 16
bits of registered
address, since they are only every registering GP16 addresses in their
case. By
instead explicitly using EUI-64 to generate address, you decouple the
registered IPv6 address from the MAC address used during registration.
Thus the
same code could in the future be used to register any address, not just
GP16
addresses. It is only the final hop that knows if there should be any
correlation between IPv6 address & 802.15.4 address, not
intermediate nodes.

-Does not
need SLLAO in initial
NS

Comments?

-Colin

From:
[email-masked]
[mailto:[email-masked]] On Behalf Of Westergreen
Mads-MWEST2

Cc: [email-masked]

I also
agree with this
approach!.

Br,

Mads
Westergreen

Senior
Platform Architect, Wireless
Connectivity Operation

Freescale Semiconductor

Mobile:
+45 20 31 45 03

From:
[email-masked]
[mailto:[email-masked]] On Behalf Of Robert Cragie

To: Dario Tedeschi

Cc: [email-masked]

I did raise this at the IETF meeting in
Maastricht but let's
say it wasn't met with universal approval. What was put in was a
tentative NCE,
which is better than what was there before but still has the issues
Colin has
pointed out below. I have always thought the right way is to carry the
16-bit
tentative MAC address in the ARO option all the way to the ABRO, which
then
really just views it as a number at that point. Only when it finally
gets back
to the joining node does it then become a true MAC address and is then
autoconfigured as an IPv6 address.

Robert

Gridmerge Ltd.

89 Greenfield Crescent,

Wakefield, WF4 4WA, UK

+44 1924 910888

+1 415 513 0064

http://www.gridmerge.com

Hi Colin

I'm all for item #3. It makes handling of IP address conflicts simpler,
helps
avoid media-access issues (like you mention in #2) and is more inline
with the
IPv6 paradigm.

Dario

Colin O'Flynn wrote:

Hello,

#1)

I’m not convinced the addition of a
‘temporary’ NC makes a lot of sense to be honest. I think a better
solution is to explicitly spell out in 6lowpan-ND what happens when the
case of
a response not being received occurs.

The easiest solution I can think of is that
after sending
MAX_UNICAST_SOLICIT times, you take the same action as if you had a
duplicate
address. You try that maybe 3 times, and if it still fails select
another
router (if available).

#2)

An interesting aspect of the above is that when
the NA is
sent back, there are actually two nodes listening they will both send
an 802.15.4
ACK. This will result in a collision and the parent may not actually
hear the
ACK, resulting it in thinking a failure occurred at the 802.15.4 layer.

unnecessary
traffic.

#3)

Regards,

-Colin

6lowpan mailing list

[email-masked]

6lowpan mailing list

[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 23 Aug 2010 21:09:31 +0200

On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:

> putting in 6lowpan-ND that you must send from an address based on the EUI-64

(I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit address.)

One of the decisions we made on the way from ND-08 to ND-09 was to simplify the protocol by basing more of it on the assumption of uniqueness of the EUI-64 address.
Your proposal therefore seems like a logical consequence, as it seems it indeed simplifies things more.

But let's consider what we lose:

-- the use of privacy addresses in this capacity.  Since we already need to have the EUI-64 exposed to do DAD, I see little loss.
-- the use of CGA (cryptographically generated addresses) in this capacity.   Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it MIGHT be a good substitute if the keys are generated with the same care that we think EUI-64s are instilled.
-- any other scheme that really wants to use a different kind of address for uniqueness.

I haven't formed an opinion yet -- I'm still in the process of trying to understand the trade-offs.

Gruesse, Carsten

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 23 Aug 2010 20:57:46 +0100

Hi Carsten,

Such a system as I'm proposing would only need to use the LL-64 based
address for the initial part of DAD. Only the node it is registering
through/to knows about this LL-64 based address.

When the node first powered on and performed a RS, it would have already
used the LL-64 address as the source of the RS.

Thus I don't think you are really exposing/using any additional information,
since your one-hop neighbors already talked to you on your LL-64 based
address.

One additional consideration I thought of:

The method as currently used in ND-12 DOES provide the linkage between the
L2 address & IPv6 address being registered. This allows the parent of the
node to update its neighbor cache when it receives the confirmation of a
successful address registration. Using the method I'm proposing would
require:
  -Infer the L2 address somehow, for example in the GP16 case you can infer
the L2 address
  -Add a SLLAO/TLLAO to the NS message that tells the parent what the L2
address of this IPv6 address that is being registered WOULD be if the
registration is successful. This is probably hacking RFC4861 in unacceptable
ways.
  -Add the link-layer address to the ARO, the only 'clean' solution I see.

Regards,

  -Colin O'Flynn

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions

EUI-64

(I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit
address.)

One of the decisions we made on the way from ND-08 to ND-09 was to simplify
the protocol by basing more of it on the assumption of uniqueness of the
EUI-64 address.
Your proposal therefore seems like a logical consequence, as it seems it
indeed simplifies things more.

-- the use of privacy addresses in this capacity.  Since we already need to
have the EUI-64 exposed to do DAD, I see little loss.
-- the use of CGA (cryptographically generated addresses) in this capacity.
Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it
MIGHT be a good substitute if the keys are generated with the same care that
we think EUI-64s are instilled.
-- any other scheme that really wants to use a different kind of address for
uniqueness.

I haven't formed an opinion yet -- I'm still in the process of trying to
understand the trade-offs.

Gruesse, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Tue, 24 Aug 2010 16:57:38 +0100

I fully support this. I am disappointed that it got such short shrift 
in Maastricht, to be honest.

Firstly, one question is: Is 6lowpan ND always going to be for just 
6lowpan? This may seem a stupid question but consideration has been 
given so far to cases which clearly do not exist in 6lowpan, e.g CGAs 
and IP addresses which do not have two-way mapping with a MAC address. 
If the answer to this is yes, there is a strong argument for optimising 
all of the ND protocol to benefit from the two-way mapping between the 
IP address and MAC address property, including e.g. eliding LLAOs. Also 
the whole CGA issue is also meaningless for 6lowpan as the addresses are 
clearly not cryptographically generated.

If the answer to the first question is "possibly not", would we then 
have to carry both the tentative MAC address and IP address in the ARO 
and have the ABRO check both for the case where there is no two-way 
mapping between the IP address and MAC address? The alternative could be 
to carry it in the target address, but that is overloading its meaning 
somewhat and probably not appropriate. Also, if we have to consider 
CGAs, then it would be possible to carry some addtional option.

Robert

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

On 23/08/2010 8:57 PM, Colin O'Flynn wrote:
> L2 address&  IPv6 address being registered. This allows the parent of the

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 25 Aug 2010 13:36:59 -0700

I would think the SLLAO in an NS would tell a 6LR that both the IP 
source address and the IP address in the ARO resolve to the same MAC 
address. However, if we wanted a different MAC address for the IP 
address in the ARO why not just add another SLLAO following the ARO. 
Question is though: Do we really need this separation, since both IP 
addresses are essentially assigned to one interface with one MAC 16bit 
address.

Dario

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 25 Aug 2010 15:18:04 -0700

Hi Colin and all,

We have been discussing the short address and duplicate MAC address
implementation issues for a while. The similar problem may happen in IPv6
today during DAD phase. My understanding is that Neighbor discovery protects
the hosts from having duplicate IP-addresses while we are discussing the
corner case of how to solve duplicate MAC address via 6lowpan-ND.

Please note that 6lowpan-ND assumes that link is secure and each host
possesses EUI-64 unique number for its interface. Thus if one turns on short
MAC address (16bit MAC) feature which is not guaranteed to be unique, it is
very logical to assume that uniqueness of such MAC address would be verified
at the link-level during the bootstrap by checking with a network-wide
authentication server or via DHCP service. 

ND-12 updates section 8.2 with the following text:

"   For the synchronous multihop DAD the 6LR performs some additional
   checks to ensure that it has a Neighbor Cache entry it can use to
   respond to the host when it receives a response from a 6LBR.  This
   consists of checking for an already existing (Tentative or
   Registered) Neighbor Cache entry for the registered address with a
   different EUI-64.  If such a Registered NCE exists, then the 6LR
   SHOULD respond that the address is a duplicate.  If such a Tentative
   NCE exists, then the 6LR SHOULD silently ignore the ARO thereby
   relying on the host retransmitting the ARO."

The IETF draft will define specification in general case, but it will not
provide specification for each implementation in a specific standard
development organization. By using GP16 addresses, ZigBee can specify
additional constraints upon using 6lowpan-nd for deployment. But it does not
require change in the IETF document. Please understand this difference.

Zach provided some examples as to how to support GP16 addresses in ND phase
on the mailing list. In later version, we can add one of those examples in
the Appendix section of the document to clarify usage in short MAC address
cases, if that is helpful for ZigBee IP implementation.

Please see below. These are some of my personal comments.

> Of Carsten Bormann
> Sent: Monday, August 23, 2010 12:10 PM
> To: Colin O'Flynn
> Cc: 6lowpan 6lowpan
EUI-
> 64
[SC>]  Originally we had the restriction of EUI-64-based address support
only.
ND-simple and other previous version of 6lowpan-nd. But we relaxed that to
support other types of addresses [ as mentioned by Carsten below] and
ofcourse GP16 addresses. But we still require a EUI-64 bit unique number to
identify an interface uniquely in ARO.

In terms of SLLAO, we require SLLAO to be provided with NS because no state
or NCE is created before then. This is done for maintaining generality of
implementations and for double checking the uniqueness of link-layer
addresses for the requested address registration. Also note that 6lowpan-nd
allows a tentative NCE after receiving RS, but there is a timeout.

Thanks,
-Samita

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Colin O'Flynn
Sent: Saturday, August 21, 2010 4:45 AM
To: 'Westergreen Mads-MWEST2'; [email-masked]; 'Dario Tedeschi'
Cc: [email-masked]
Subject: Re: [6lowpan] ND Short Address Collisions

Hello,

Comments?

  -Colin

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 25 Aug 2010 15:40:25 -0700

Hi Robert,

Please see below.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Robert Cragie
Sent: Tuesday, August 24, 2010 8:58 AM
To: Colin O'Flynn
Cc: 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] ND Short Address Collisions

I fully support this. I am disappointed that it got such short shrift in
Maastricht, to be honest.

[SC>] Sorry for your disappointment.  The problem is that we cannot tune the
IETF document too much to one deployment or implementation. Also, note that
tentative NCE solves the duplicate IP-address detection problem immediately
at the on-link and on multi-hop cases. Trying to solve duplicate MAC address
detection by 6lowpan-ND, IMHO is too much to ask from the L3 protocol. Can't
6lowpan-nd assume that the L2-address uniqueness are ensured by either
assigning EUI-64 based MAC addresses or by some other means during
bootstrapping?

Firstly, one question is: Is 6lowpan ND always going to be for just 6lowpan?
This may seem a stupid question but consideration has been given so far to
cases which clearly do not exist in 6lowpan, e.g CGAs and IP addresses which
do not have two-way mapping with a MAC address. 

[SC>] 

6lowpan-nd, to my knowledge is targeting a larger scope. 6lowpan is
obviously the primary deployment area today. It could also be equally
applicable to any lossy or unreliable mesh network such as Wifi mesh-network
or a mesh network of any route-over topology.

If the answer to this is yes, there is a strong argument for optimising all
of the ND protocol to benefit from the two-way mapping between the IP
address and MAC address property, including e.g. eliding LLAOs. Also the
whole CGA issue is also meaningless for 6lowpan as the addresses are clearly
not cryptographically generated.

If the answer to the first question is "possibly not", would we then have to
carry both the tentative MAC address and IP address in the ARO and have the
ABRO check both for the case where there is no two-way mapping between the
IP address and MAC address? The alternative could be to carry it in the
target address, but that is overloading its meaning somewhat and probably
not appropriate. Also, if we have to consider CGAs, then it would be
possible to carry some addtional option.

[SC>]  What you are proposing here  seems only needed for non-unique MAC
addressed multi-hop network. Perhaps we can look into adding an optional
multihop-address option between 6LR-6LBR to take care of this. It might be
applicable for other scenarios than GP16 address collision. Let me check
with the co-authors.

BTW, I assume you meant 6LBR instead of ABRO above - right?

Thanks,

-Samita

Robert

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

Hi Carsten,

 

 
Regards,
 
  -Colin O'Flynn
 
-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions

EUI-64

 

 
Gruesse, Carsten

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 25 Aug 2010 19:40:57 -0700

Hi Colin,

Here is an attempt to address your concerns.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Colin O'Flynn
Sent: Tuesday, August 17, 2010 1:09 PM
To: [email-masked]
Subject: [6lowpan] ND Short Address Collisions

Hello,

#1)

[SC>]  Your concern is about responding to the neighbor who tried to use its
neighbor's GP16 address by having a duplicate 16-bit MAC address. I assume
there is no issue in detecting the duplicate address by using the ARO fields
EUI-64 and address to be registered. 

How do we handle this problem today?  If the MAC address is a duplicate one
and it remained undetected so far - then bad luck!

Do you assume that when RS is sent, the node uses LL64 unique address and
receive RA correctly?

[SC>]  Temporary NCE is added for detecting duplicates at the first hop
immediately.

[SC>] Section 5.5 already addresses how many times the NS can be
retransmitted for address registration. Do you want to see a specific
sentence on that again on section 5.5.1 (Sending NS)?

[SC>]  Yes. As in any other case today.

#2)

[SC>]  How is it a ND issue?

#3)

[SC>]  You are talking about an optimization/hack for a special case. We
cannot assume that SLLAO is always same as EUI-64.

 

[SC>]  In a deployment, ideally one should use LL64 address in order to
maintain uniqueness. But if one wants to use LL64 for communication and then
verify LL16 address with the 6LR/6LBR to make sure that is unique before
using it, that is a unique requirement. That is beyond DAD check. However,
if this solution is nice to have through ND, we will look into it. However,
I'd like to make sure that folks understand that this should not hold the
draft from starting WG-LC - agree?

Thanks,

-Samita

   -Colin

---

From: Robert Cragie <[email-masked]>
Date: Thu, 26 Aug 2010 06:13:17 +0100

Hi Samita,

Comments inline, bracketed by <RCC></RCC>

Robert

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

On 25/08/2010 11:40 PM, Samita Chakrabarti wrote:
>
> Hi Robert,
>
> Please see below.
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Robert Cragie
> *Sent:* Tuesday, August 24, 2010 8:58 AM
> *To:* Colin O'Flynn
> *Cc:* 'Carsten Bormann'; '6lowpan 6lowpan'
> *Subject:* Re: [6lowpan] ND Short Address Collisions
>
> */[SC>] Sorry for your disappointment.  The problem is that we cannot 
> tune the IETF document too much to one deployment or implementation. 
> Also, note that tentative NCE solves the duplicate IP-address 
> detection problem immediately at the on-link and on multi-hop cases. 
> Trying to solve duplicate MAC address detection by 6lowpan-ND, IMHO is 
> too much to ask from the L3 protocol. Can't 6lowpan-nd assume that the 
> L2-address uniqueness are ensured by either assigning EUI-64 based MAC 
> addresses or by some other means during bootstrapping?/*
>
<RCC>
The point is this work was developed under the 6lowpan WG. So it seems 
contradictory to then state that it can't be tuned to one deployment or 
implementation; surely that was the whole point of developing it in the 
first place? On the basis that 802.15.4 uses 16-bit addresses, and 
6lowpan is aimed at 802.15.4, it has to be correctly supported in the 
proposal. The way 6lowpan is specified now, and the general case of 
address autoconfiguration will mean there is always a two-way 
relationship between the MAC and the IPv6 address. In that case, it 
seems reasonable to me that duplicate address detection for the IPv6 
address performs the same function.

So if you additional bootstrapping is needed to ensure the 16-bit MAC 
address is unique prior to ND, then, based on the autoconfiguration 
rules, there will be no particular need for NS/NA to perform the address 
registration for the purposes of address conflict resolution as this 
will already have been done. If this is the intention, then the way 
ZigBee IP for one uses 6lowpan ND will have to be completely reconsidered.
</RCC>
> *//*
> */[SC>] /*
> */6lowpan-nd, to my knowledge is targeting a larger scope. 6lowpan is 
> applicable to any lossy or unreliable mesh network such as Wifi 
> mesh-network or a mesh network of any route-over topology./*
>
> */ /*
>
> If the answer to this is yes, there is a strong argument for 
> optimising all of the ND protocol to benefit from the two-way mapping 
> between the IP address and MAC address property, including e.g. 
> eliding LLAOs. Also the whole CGA issue is also meaningless for 
> 6lowpan as the addresses are clearly not cryptographically generated.
>
> mapping between the IP address and MAC address? The alternative could 
> be to carry it in the target address, but that is overloading its 
> meaning somewhat and probably not appropriate. Also, if we have to 
> consider CGAs, then it would be possible to carry some addtional option.
>
> */[SC>]  What you are proposing here  seems only needed for non-unique 
> MAC addressed multi-hop network. Perhaps we can look into adding an 
> optional multihop-address option between 6LR-6LBR to take care of 
> this. It might be applicable for other scenarios than GP16 address 
> collision. Let me check with the co-authors./*
>
> */BTW, I assume you meant 6LBR instead of ABRO above -- right?/*
>
<RCC>It is needed where the IPv6 address is not autoconfigured from the 
MAC address and where the MAC address itself needs to be checked. 
Earlier you say it's too much to ask for an L3 protocol, but LLAOs are 
used widely, so I don't think it's out of scope. Yes, I meant 6LBR (the 
device the ABRO points to).</RCC>
> *//*
> */ /*
> */Thanks,/*
> */-Samita/*
> */ /*
> */ /*
> */ /*
> [email-masked]  <mailto:[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Aug 2010 09:16:11 +0200

On Aug 26, 2010, at 00:40, Samita Chakrabarti wrote:

> Trying to solve duplicate MAC address detection by 6lowpan-ND, IMHO is too much to ask from the L3 protocol. 

I completely disagree.

Being able to DAD-check IP addresses formed from tentative 16-bit MAC addresses is a core function of 6lowpan-ND.  This is not the time to retract that functionality.

Gruesse, Carsten

---

From: "Colin O'Flynn" <[email-masked]>
Date: Thu, 26 Aug 2010 09:31:40 +0100

Hello,

>In a deployment, ideally one should use LL64 address in order to maintain
uniqueness. But if one >wants to use LL64 for communication and then verify
LL16 address with the 6LR/6LBR to make sure >that is unique before using it,
that is a unique requirement.

>through ND, we will look into it. However, I'd like to make sure that folks
understand that this should >not hold the draft from starting WG-LC - agree?

Disagree, as I understood the entire point of 6lowpan-ND was to guarantee
uniqueness of the 802.15.4 16-bit addresses. If it is not suitable for use
in such a situation it has failed completely.  

If you are using LL64/GP64 addresses you don't need DAD. You only need DAD
if you want to use random addresses, or addresses based on unknown MAC
addresses. Realistically the second case is going to see far more use than
the first. I'm aware of possible uses w/o unknown MAC addresses sure
(privacy addresses), but the bigger issue is addresses based on unknown MAC
addresses.

> unreliable mesh network such as Wifi mesh-network or a mesh network of any
route-over topology.

I think there is something to be said for limiting the scope to make these
protocols useful. It MAY be used for other protocols, but the primary
objective is 6LoWPAN I thought.

> Can't 6lowpan-nd assume that the L2-address uniqueness are ensured by
either assigning EUI-64 based

> MAC addresses or by some other means during bootstrapping?

The entire problem I, and I think many other people, looked for 6lowpan-ND
was to solve was to verify MAC address uniqueness. Generally people
understood that you won't get away with MAC-layer stuff at the IETF, so it
was moved to verifying IPv6 addresses with the understanding there is a
direct correlation between IPv6 addresses and MAC addresses in many cases.

The current draft requires you to send the NS from the global address you
are registering. So say you register a GP16, 2002::ff:fe00:1122. What you
are REALLY asking is to find out if anyone else is being the short address
1122, so you can auto-configure the GP16 2002::ff:fe00:1122.

For this to work you MUST send from the short address 1122, which you don't
know if it is unique. You need to send from it because (a) the SLLAO in the
initial NS needs to come from that address for the NC entry to be correct
and (b) you want maximum compression at the 6LoWPAN layer.

The entire thing seems very "kludgy" as it requires you to have this special
NC entry status. It makes implementing 6lowpan-ND on a standard IPv6 stack
very difficult as you need to perform low-level overrides of the NC.

> address registration. Do you want to see a specific sentence on that again
on section 5.5.1 (Sending 

> NS)?

Sorry, I actually mean changing the sentence in section 5.5.3 that says:

        ... fail for two reasons: no response to Neighbor Solicitations is
        received (NUD failure)... In the case of NUD failure the entry for
        that router will be removed thus address registration is no longer
        of importance.

So what I mean is that if you register with a duplicate address and get NO
response, you should maybe try with another address on the same router if
you have no other router. This to me would be required to work with what it
says later in section 8.2:

        If such a Tentative

        relying on the host retransmitting the ARO.  (This is needed to

        handle the case when multiple hosts try to register the same IPv6

        address at the same time.)

As another point I didn't see how you move between different routers. If you
register with a different router for example, do you retry the address you
just tried or try a new address?

Regards,

  -Colin O'Flynn

From: Samita Chakrabarti [mailto:[email-masked]] 
Sent: August 25, 2010 11:40 PM
To: [email-masked]; 'Colin O'Flynn'
Cc: 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: RE: [6lowpan] ND Short Address Collisions

Hi Robert,

Please see below.

[SC>] 

Thanks,

-Samita

Robert

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

Hi Carsten,

 

 
Regards,
 
  -Colin O'Flynn
 
-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions

EUI-64

 

 
Gruesse, Carsten

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 26 Aug 2010 17:49:53 -0700

Hi Colin, Carsten and Robert,

[SC>]  Understood your point.

I got the message from the wg to fix the 16bit-MAC-addr duplicate return
check for 16bit MAC duplicate to form the unique short address using
multihop DAD. We will need to fix this problem as the wg wants.

We will look at the suggestions Colin and Robert proposed and the ND-authors
will come up with the proposal for review.

Thanks for the feedback and suggestions,.

-Samita

route-over topology.

        If such a Tentative

Regards,

  -Colin O'Flynn

Hi Robert,

Please see below.

[SC>] 

Thanks,

-Samita

Robert

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

Hi Carsten,

 

 
Regards,
 
  -Colin O'Flynn
 
-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions

EUI-64

 

 
Gruesse, Carsten

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 26 Aug 2010 18:00:15 -0700

Hi Colin,

 
[SC>] The assumption for this ND is to use a single prefix throughout the
6lowpan and that's how it maintains simple mobility. So as long as it is
within a 6lowpan its prefix or IP-address does not change even if it
registers with a different router under the administration of the same 6LBR.
So, yes, it should retry the same address.  If it is not clear in the
document, we can clarify this.
 
Thanks,
-Samita

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 26 Aug 2010 19:31:51 -0700

Hi Robert/Colin:

For our understanding, here is the problem statement that we are trying to
address. Please confirm:

Improvement Requirement:

1.      A EUI-64 node may want to use non-EUI-64 based IPv6 address for
communication or it may want to register multiple addresses at the same time
via multihop DAD mechanism. We need a way to verify that the additional
IPv6-address and its corresponding link-layer address(non-EUI-64) are unique
in a 6lowpan network. [ via multi-hop DAD mechanism]. However, for the
address registration NS message, the node uses EUI-64 based IPv6-address and
corresponding MAC address to avoid any collision in the local link due to
duplicate MAC-addresses.

Thanks,

-Samita

From: Robert Cragie [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2010 10:13 PM
To: Samita Chakrabarti
Cc: 'Colin O'Flynn'; 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: Re: [6lowpan] ND Short Address Collisions

Hi Samita,

Robert

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

Hi Robert,

Please see below.

<RCC>
The point is this work was developed under the 6lowpan WG. So it seems
contradictory to then state that it can't be tuned to one deployment or
implementation; surely that was the whole point of developing it in the
first place? On the basis that 802.15.4 uses 16-bit addresses, and 6lowpan
is aimed at 802.15.4, it has to be correctly supported in the proposal. The
way 6lowpan is specified now, and the general case of address
autoconfiguration will mean there is always a two-way relationship between
the MAC and the IPv6 address. In that case, it seems reasonable to me that
duplicate address detection for the IPv6 address performs the same function.

So if you additional bootstrapping is needed to ensure the 16-bit MAC
address is unique prior to ND, then, based on the autoconfiguration rules,
there will be no particular need for NS/NA to perform the address
registration for the purposes of address conflict resolution as this will
already have been done. If this is the intention, then the way ZigBee IP for
one uses 6lowpan ND will have to be completely reconsidered.
</RCC>

[SC>] 

<RCC>It is needed where the IPv6 address is not autoconfigured from the MAC
address and where the MAC address itself needs to be checked. Earlier you
say it's too much to ask for an L3 protocol, but LLAOs are used widely, so I
don't think it's out of scope. Yes, I meant 6LBR (the device the ABRO points
to).</RCC>

Thanks,

-Samita

Robert

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

Hi Carsten,

 

 
Regards,
 
  -Colin O'Flynn
 
-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions

EUI-64

 

 
Gruesse, Carsten

---

From: "Colin O'Flynn" <[email-masked]>
Date: Fri, 27 Aug 2010 08:32:21 +0100

Hi Samita,

Yes that is a good description of the problem! Registering multiple
addresses at the same time isn't totally necessary, but my proposed change
happened to get that for "free".

Regards,

  -Colin

From: Samita Chakrabarti [mailto:[email-masked]] 
Sent: August 27, 2010 3:32 AM
To: [email-masked]
Cc: 'Colin O'Flynn'; 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: RE: [6lowpan] ND Short Address Collisions- Problem statement

Hi Robert/Colin:

 

Improvement Requirement:

 

Thanks,

-Samita

Hi Samita,

Robert

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

Hi Robert,

Please see below.

<RCC>

[SC>] 

Thanks,

-Samita

Robert

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

Hi Carsten,

 

 
Regards,
 
  -Colin O'Flynn
 
-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions

EUI-64

 

 
Gruesse, Carsten

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 30 Aug 2010 18:04:46 -0700

On 08/21/10 04:45 AM, Colin O'Flynn wrote:
> Hello,
>
> Would there be support for putting in 6lowpan-ND that you must send from
> an address based on the EUI-64 instead of anticipated 16-bit address? I
> think it is more consistent with what is already in 6lowpan-ND. Consider
> the following:

What you are proposing is very different than how RFC 4861 and 
6lowpan-nd works for NS and NA. Currently NS and NA make a statement 
about the source address when they include a SLLAO. But with your 
approach it is sometimes a statement about the source address, and 
sometimes a statement about the ARO registered address.

I think this will lead to confusion, and result in corner cases that are 
hard to handle.

And in fact you don't need any of that. All you seem to need to handle 
your concerns is an "errors-to" MAC address, which the host might set to 
its EUI-64 MAC address. (It could also be an "errors-to" IPv6 address 
like the LP64.) We can easily add such a field to the ARO.

But having some packets, depending on option content, redefine the IPv6 
source address field as the "errors-to" field makes no sense to me.

Two examples of corner cases to worry about in the short term.
1. Assume an NS with ARO+SLLAO where IPv6 source is LL64 and the 
registered address is a GP16. In that case what should happen if
  1a. There is no NCE for the LL64? (Should one be created?)
  1b. There is an NCE for the LL64, but the stored mac address is 
different than what is in the SLLAO. (Should it be updated?)
Those questions don't arise in 6lowpan-nd-12 because the NS only applies 
to one address - the one in the IPv6 source field.

2. Apply ARO to CGA addresses and Secure Neighbor Discovery. In that 
case, which addresses should be used for the SeND verification?
In 6lowpan-nd-12 the answer is simple since it is always the IPv6 source 
address.

> Thus 6lowpan-ND is already assuming we have a link-local address based
> on an EUI-64. Based on those two assumptions you could greatly simplify
> processing of NA by performing the following when you receive a NA message:
>

I listed a few architectural disadvantages above. In addition this 
causes more complexity in the implementation since an implementation 
still has to handle NS and NA messages that do not contain an ARO, and 
the rules for how such messages are processed will be different than 
when the ARO is in place.

> -Cannot have collision of two 802.15.4 ACK’s because you are
> transmitting to two nodes at once
>
> -Less FLASH usage, since you have removed temporary NCE, and always use
> the same ARO Length which further simplifies code

The ARO length is already overloaded to distinguish between multi-hop 
DAD messages (which are disjoint for all other use of NS and NA) from 
normal NS/NA.

Hence as 6lowpan-nd is currently written hosts can't send ARO with 
length=4 since those have completely different semantics. That detail 
could be fixed, but is an example of the confusion in this space.

>
> -Less SRAM usage, since you never need a neighbor cache entry for
> multi-hop DAD to complete

First of all, wouldn't you need the SRAM once the DAD has completed?
Second of all, I think the notion of a temporary NCE is needed to avoid 
security issues (preventing an off-link attacker from creating bogus 
NCEs - there is no ttl check on the multi-hop DAD messages to protect 
against such attacks.)

> -ARO registered address can be changed by ABR. For example if ABR
> notices a node is re-registering after that node reboots, the ABR could
> change registered address to nodes old address in NA it sends back.

Why is this an important problem to solve? How does it relate to the 
importance of your original issue around short address collisions? How 
does it relate to the overall goal of making 6lowpan compact, simple, 
and sufficient to handle 6lowpans.

> -Avoids “hacks” when sending last-hop NA. By “hack” I mean that people
> may just take registered address out of ARO, and send 802.15.4 message
> to lower 16 bits of registered address, since they are only every
> registering GP16 addresses in their case. By instead explicitly using
> EUI-64 to generate address, you decouple the registered IPv6 address
> from the MAC address used during registration. Thus the same code could
> in the future be used to register any address, not just GP16 addresses.
> It is only the final hop that knows if there should be any correlation
> between IPv6 address & 802.15.4 address, not intermediate nodes.

I'm sure misguided implementors can still be creative in coming up with 
things that violate the letter or intent of the specification.

> -Does not need SLLAO in initial NS

I suspect you are referring to the notion of "first time an address is 
registered with a particular 6LR" when you say "initial NS".

That notion only exists on a the 6LR. In particular, a host can not 
reliably know whether or not a particular 6LR has a NCE for the host's 
address.
Thus for robustness all messages that contain the ARO must be able to 
function whether or not the 6LR has an NCE.

So while I understand the problem you are trying to solve, the proposed 
solution looks like it is making things a few orders of magnitude worse 
than the problem you tried to solve.

Introducing an "errors-to" field in the ARO (either as a MAC address or 
an IP address) solves the problem without adding more confusion, 
complexity, and ill-defined behaviors.

Regards,
    Erik

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 31 Aug 2010 09:21:10 +0100

Hi Erik,

Thanks for looking through my proposal & commenting. I think a lot of the
problems come from my original e-mail/proposal not being clear enough, or
mixing possible implementation-specific optimizations with what the general
case I saw was. Let me try to clarify some of those:

>. Currently NS and NA make a statement about the source address when they
include > a SLLAO. But with your approach it is sometimes a statement about
the source 
> address, and sometimes a statement about the ARO registered address.

Not sure I understand that one. If the SLLAO is included, the LLAO has the
address associated with the IPv6 source address is all I assume. The ARO
registered address is ALWAYS the address which you wish the 6lowpan-ND
action on (register, re-register, etc).

>  1a. There is no NCE for the LL64? (Should one be created?)

6lowpan-nd-12 already has this if I'm reading your e-mail correctly. Section
5.2 Interface Initialization says that:

   A link-local address is formed based on
   the EUI-64 assigned to the interface, and then the host sends Router
   Solicitation messages as described in [RFC4861] Section 6.3.7.

Hence the router may have already created a NC entry if it is using standard
ND. In my suggestion it's up to implementers HOW the deal with routing the
NA response back. They may use a normal NC, they may use a special NC that
only stores entries from NS, or they may fake it out by sending to the
EUI-64 of the ARO if their specific network design allows such faking. 

>different than what is in the SLLAO. (Should it be updated?)

My understanding is standard ND processing would deal with this. When the NS
(or anything else) was sent from the LL64, the SLLAO would always point to
the correct mac address to use. Which will for efficiency reasons always be
the EUI-64 in 6LoWPAN networks. 

> 2. Apply ARO to CGA addresses and Secure Neighbor Discovery.

Not sure on this one. I've never implemented SeND so don't know about
resource requirements, is it something which could be implemented on the
type of nodes we are looking to run 6lowpan-ND on?

But I don't have a good response to that concern, AFAIK my proposal isn't
cleanly compatible with SeND.

> . In addition this causes more complexity in the implementation since an 
> implementation still has to handle NS and NA messages that do not contain
an ARO

Huh? How is this different from 6lowpan-ND currently? In fact I thought it
even easier, as the processing only needs to check the EUI-64, and generally
keeps processing of messages more streamlined.

These observations are at least based on how I've implemented 6lowpan-ND.
Perhaps I'm missing very obvious optimizations in ND-12, but from my
perspective of someone who has written a 6lowpan-ND implementation, the
proposed changes would be considerably easier. 

>DAD messages

My proposal moves to distinguishing based on the src/dest IP addresses.
Multi-hop uses global IP addresses, everything else uses link-local.

> First of all, wouldn't you need the SRAM once the DAD has completed?

It was more that you could get away without a NC at all in the intermediate
6LR. Again this isn't required in the general case, but if using for example
RPL on top you could get away without a NC on the 6LRs.

> security issues

Hmm good point. That would require changes to my proposal, either:

-Include the temporary NCE again

-On receiving a NA, check if the IPv6 address you will send to based on the
EUI-64 is already in your NC. It should be in the NC as you received a NS
from it. This basically uses the LL64 as the temporary NCE.

-Include something like a nonce in the reserved space of the ARO. This is
less in line with current 6lowpan-ND so probably not worth the hassle.

> How 

It would cleanly allow extensions to 6lowpan-ND that could do the following
(if someone later wanted to):

* Have the 6LBR tell you a better short address to use instead of the one
you picked. If the network is packed, maybe it's better than the guess &
check method.

* Would let the 6LBR tell a node which is re-registering what his old short
address was. 

I don't mean we will add them to 6lowpan-ND immediately. But these are
things I could see being useful, and having the protocol designed such that
the EUI-64 and NOT the registered address is used to uniquely identify the
NS sender makes sense to me.

> function whether or not the 6LR has an NCE

My message probably wasn't clear, as I didn't mean in the general case you
can remove the SLLAO. Just that in specific implementations, it would give
them the flexibility to remove the SLLAO as they KNOW the same information
is carried in e.g. the EUI-64. But I probably shouldn't have mixed
implementation-specific optimizations and the general case. 

>an IP address) solves the problem

One of the problems I was looking to solve is with people using "standard"
stacks. Such stacks had trouble sending a packet to a destination IPv6
address that was in the neighbor cache, BUT the mac address was something
different. Thus it should be an IP address that the "error-to" is.

To save space though it would be better if the error-to was just a MAC
address & you auto-configure the IPv6 address based on this. Or if the
error-to is the LL64. After all the RS should have come from the LL64, so
presumably you have an entry in your NC for the LL64 of that node. 

Regards,

  -Colin O'Flynn

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: August 31, 2010 2:05 AM
To: Colin O'Flynn
Cc: 'Westergreen Mads-MWEST2'; [email-masked]; 'Dario
Tedeschi'; [email-masked]
Subject: Re: [6lowpan] ND Short Address Collisions

> -Cannot have collision of two 802.15.4 ACK's because you are

> -Avoids "hacks" when sending last-hop NA. By "hack" I mean that people

Regards,
    Erik

---

From: Robert Cragie <[email-masked]>
Date: Tue, 31 Aug 2010 10:10:10 +0100

Hi Erik,

Comments below bracketed by <RCC></RCC>

Robert

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

On 31/08/2010 2:04 AM, Erik Nordmark wrote:
> 6lowpan-nd works for NS and NA.
<RCC>NS and NA behave very differently for 6lowpan ND than RFC 4861 ND 
with regard to address registration. I never really understood the 
necessity to use NS for address registration; personally I preferred the 
earlier NR/NC approach. NS/NA doesn't align with what's in RFC 4861 
anyway. Whilst there isn't an equivalent of address registration, DAD 
seems to be the closest function and this uses unspecified address as 
the source address.</RCC>

> Currently NS and NA make a statement about the source address when 
> they include a SLLAO. But with your approach it is sometimes a 
> statement about the source address, and sometimes a statement about 
> the ARO registered address.
<RCC>Quite the contrary. The way it is written now the SLLAO makes a 
statement about the registration address (which is also the unproven and 
possibly duplicate source address) in the NS. In the proposal, the SLLAO 
would always be consistent with the source address and not refer the ARO 
registered address at all (if I understand the proposal correctly).</RCC>
>
> I think this will lead to confusion, and result in corner cases that 
> are hard to handle.
<RCC>There is confusion currently amongst multiple vendors trying to do 
interoperability testing with real products. I thought the IETF way was 
to a) put out a specification, b) try it and c) change it if it doesn't 
work. The process for (c) doesn't seem to be happening well for some 
reason.</RCC>
> your concerns is an "errors-to" MAC address, which the host might set 
> to its EUI-64 MAC address. (It could also be an "errors-to" IPv6 
> address like the LP64.) We can easily add such a field to the ARO.
<RCC>I disagree. Strictly speaking you should not be using that 16-bit 
MAC address at all as a source or destination until you are convinced 
that it is unique within the PAN. MAC association in 802.15.4 is built 
around that principle. Perhaps we should be using that mechanism for 
registration, although that would complicate matters by introducing 
another management entity function when there seems to be a perfectly 
acceptable alternative. On the other hand, if it were done using MAC 
association, in 6lowpan (or indeed any network where the IP address is 
autoconfigured from its IID (hence MAC address), the need for 
independent address registration of IP addresses would probably go 
away.</RCC>
>
> But having some packets, depending on option content, redefine the 
> IPv6 source address field as the "errors-to" field makes no sense to me.
>
<RCC>I am assuming one isn't needed just as one isn't strictly needed 
for RS/RA, which uses LL64. The LBR should not strictly have to maintain 
state for the joining node for address registration purposes. The NCE 
would be created when the successful NA comes back from the 
authoritative 6LBR.</RCC>
> Those questions don't arise in 6lowpan-nd-12 because the NS only 
> applies to one address - the one in the IPv6 source field.
<RCC>There shouldn't be one. This would actually be end up being more 
consistent as it means that NCEs only exist for the registered IPv6/MAC 
address pair.</RCC>
> In 6lowpan-nd-12 the answer is simple since it is always the IPv6 
> source address.
<RCC>CGAs do not occur in 6lowpan (this is *6lowpan* ND we are talking 
about here). If you really needed a CGA, you can add the option in for 
the registered address.</RCC>

> when the ARO is in place.
<RCC>In my opinion, it causes less complexity in that NCEs only exist 
for addresses which will be used. The LL64 can be considered ephemeral 
up to the point the registered address is acknowledged to be unique. As 
for the other uses of NS in 6lowpan from RFC 4861, I think we need to 
carefully go through them as it is not clear from the current draft 
exactly when they would be used as 6lowpan ND is written as a kind of 
'addendum' to RFC 4861.</RCC>
> could be fixed, but is an example of the confusion in this space.
<RCC>Multihop NS/NA will by necessity use IP addresses which have a 
global/UL prefix. This distiguishes them.</RCC>
> Second of all, I think the notion of a temporary NCE is needed to 
> avoid security issues (preventing an off-link attacker from creating 
> bogus NCEs - there is no ttl check on the multi-hop DAD messages to 
> protect against such attacks.)
<RCC>
Another kludge and why it is wrong to overload NS/NA in this way. There 
are two solutions here:

1) Set ttl properly. This limits the attacker space to the same radius 
as the 6LBR which in practice means inside the 6lowpan.
2) Create state for the NS/NA. This doesn't have to be a NCE, simply a 
record of the corresponding NS. This would be a 'belt and braces' 
approach on top of (1)
</RCC>

> and sufficient to handle 6lowpans.
<RCC>Maybe it isn't but if complementary functions like this appear, it 
usually means the approach is the right one. The corollary being that if 
it becomes awkward to add complementary functions using existing 
specified mechanisms, the existing mechanisms are probably wrong.</RCC>
> I'm sure misguided implementors can still be creative in coming up 
> with things that violate the letter or intent of the specification.
<RCC>Similar to my point above - if something is implemented correctly, 
the desire to do hacks goes away to some extent as the hacks no longer 
appear efficient.</RCC>
> So while I understand the problem you are trying to solve, the 
> proposed solution looks like it is making things a few orders of 
> magnitude worse than the problem you tried to solve.
<RCC>Like it or not, 6lowpan, 802.15.4 and the 'schizophrenic' MAC 
address add complexity. The aim is surely to deal with these in L2/L3 
management cleanly and not to violate the rules. L3 management has to 
consider the properties of L2 addressing (if it is used); the use of 
LLAOs throughout indicate the need to propagate L2 addresses into L3 
managament. Quite simply, the use of a 16-bit MAC address before it has 
been proven to the best of the network's ability to be unique should be 
avoided, so deliberately specifying it like is done in nd-12 clearly 
violates the requirement.</RCC>
>
>
> Introducing an "errors-to" field in the ARO (either as a MAC address 
> or an IP address) solves the problem without adding more confusion,