Hi,
Hi,
> Hi,
>
>> Hi,
>>
>> while hacking the short address handling for Linux, I _maybe_ stumble
>> over some issue.
>> _Maybe_, because I am not sure how it really should work.
>>
>> The issue is that when setting src_len to 2 then a short address will be
>> part of source/target link address option only.
>>
>> For my knowledge the setting of "src_len" is wrong, the interface can
>> really have two mac addresses at the same time. According to 802.15.4
>> the short address is somewhat optional. If they is available then add
>> them to the address option fields. (Then you have two address option
>> fields).
src_len primary purpose is to identify the address mode the interface
uses for its source address, so I don't see how this can be "wrong".
You can't put both addresses in the 802.15.4 header.
Ah, okay. Then this is the default behaviour to use short XOR extended
as source address.
>> General proceeding is (in my opinion), copy&pasted from irc:
>>
>> 16:37 < eintopf> I think extended address address field for extended
>> address (length==2) need to be always there, then if the short address
>> is valid (not 0xffff or 0xfffe, for unicast neighbour) then add also a
>> second option for short address.
>>
>> 16:50 < eintopf> so in NS/NA source/target link address option fields:
>> extended address _always_ AND short address if link short address is
>> valid (not 0xffff or 0xfffe).
>>
>> This is how I did it for linux.
You are right that it might be possible to add both link-layer
addresses into a seperate SLLAO to NS/NA, but I don't really see a
reason why to do that: The L2 address should be "changed" (as in
mode-switched) as little as possible, so a new SLLAO can also be send
out on mode-switch. Which values are you referring to by "0xffff or
0xfffe"? The stuffing for the IID?
0xffff and 0xfffe are invalid _unicast_ short addresses according to
802.15.4 and 0xffff is default value.
> Additional notes:
>
> I also can't see the autoconfiguration for a short address based
> link-local address [0], when using short address.
Because we have no proper SLAAC yet 
ok.
> I think you need to have both addresses then, one based on extended and one
> based on (panid +) short.
>
> The SLAAC address based on short (+panid) is not compressable with
> SAM/DAM = 11 in IPHC for stateless compression, (it's in case if panid
> is zero only).
The RFCs are very unclear on the whole PAN ID thing. RFC 4944 is
specifying the translation from short address to IID by including the
PAN ID, while RFC 6282 specifies it without, while not even referring
to the previous specification. Since RFC 6282 is the more current I
decided to go for its approach, while keeping the conversion PAN ID +
short => IID optionally in there, by having them as a virtual 32-bit
address of the device.
I think these are two different things.
- RFC 4944 describes SLAAC addresses.
- RFC 6282 describes how to compress addresses which has some format
which based on short address. This isn't how to generate the SLAAC
address for short addresses.
I agree it would make sense to compress addresses which follows the
SLAAC format according to RFC 4944, but for me it doesn't look like that
they specifies it in that way.