Re: [RFC bluetooth-next 01/20] 6lowpan: ndisc: don't remove short address

[Michael Richardson <mcr@sandelman.ca>]

[-- Attachment #1: Type: text/plain, Size: 3513 bytes --]


Alexander Aring <aar@pengutronix.de> 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@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 464 bytes --]