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
NCE exists, then the 6LR SHOULD silently ignore the ARO thereby
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 protected]]
Sent: August 25, 2010 11:40 PM
To: [email protected]; 'Colin O'Flynn'
Cc: 'Carsten Bormann'; '6lowpan 6lowpan'
Subject: RE: [6lowpan] ND Short Address Collisions
Hi Robert,
Please see below.
From: [email protected] [mailto:[email protected]] 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
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 23/08/2010 8:57 PM, Colin O'Flynn wrote:
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 protected]]
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
