Alexander Aring <aar@xxxxxxxxxxxxxx> wrote:
> So you want to have such "flag":
> "please force use short address always if short available" and
> "please force use extended address always (if short address is
> available)"
> _per_ neighbour? If this fits to your use-case then I think it could
> work.
yes, I think this is what I want.
> At last you need to have some "neighbour add" netlink event listener
> which reacts on if neighbours will be added and then set such flag for
> the neighbour (which is indicated by L3 address).
Yes.
> But the neighbour cache is already a hash with L3 address as key. I
> think the neighbour cache should be used for such use-case. What do you
> think.
I think it's an appropriate use.
>> This will matter for handling of ND, in particular the DAR/DAC
>> processing.
> ah, ok. So for sending out DAR/DAC we need to control somehow to use
> short or extended address?
Here, I think it's that we need the layer-2 address in the NA to validate the
ARO option in the NA, so that we can send the DAR with confidence.
I have to re-read https://tools.ietf.org/html/rfc6775#section-8.2.3 carefully
to see if I really need this or not.
> You want to send these messages via userspace? In kernelspace we could
> handle it (I think), lowpan interface knows the wpan interface and we
> could decide somehow to force using short xor extended when generating
> mac header for DAR/DAC.
I think that there is too much long-term state and policy to do this in the
kernel.
> If I understand correctly, we do at the moment a) case.
> By "Looking at L3 address and choose the L2 address according to which
> best address do more compression", isn't it?
yeah...
> I already implemented this stuff, the only one think is... it's more
> than looking into L3 address only. It depends also on fragmentation. We
> can compress maybe lot of bytes in FRAG1 which contains 6LoWPAN header
> with the right L3 address by doing extended address. But if we have ~3
> fragments (didn't calculate the number of necessary fragments now) then
> it's better to use short address, because you can compress more bytes by
> using short addresses in the fragments.
Yes, i recall discussing this with you.
> The b) stuff will work then _per_ interface. Would be maybe nice to
> have this per socket. I would say per socket would be nicer, because you
> can overwrite the setting for exactly your use-case and all other
> applications still do a). Currently I have no idea how to getting such
> information from IPv6 socket to the 6LoWPAN layer but this should be
> possible. This will also no add any 802.15.4 dependency for IPv6
> applications, default handling should be still a).
setsockopt() is the normal way to indicate this down. It gets into the
skbuff in a way that I don't recall. Probably skbuff->sock or some such.
> I also have no idea to get L2 receive information to the userspace at
> the IPv6 socket yet. Need to take a look into ipv6 sockets,
> IPV6_RECVPKTINFO is a nice hint, if we can easly extend this information.
that's the right mechanism, you send it up as aux data.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
