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

[Michael Richardson <mcr@sandelman.ca>]

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


{cutting many from the CC}
I realized while reading your patches that I don't think we have a way for an
application to tell if a packet (such as an ICMPv6 packet received on a raw
IP socket) arrives with a 2-byte or 8-byte address, or for an application to
ask for 8-byte address, despite there being a 2-byte address available.

Do you think we could do this via neighbour caches for directly connected
nodes?  For not directly connected nodes part of an RPL mesh, the RPL daemon
would install routes using the router's 2-byte address if it can anyway.

This will matter for handling of ND, in particular the DAR/DAC processing.

I also wonder: if we configure an IPv6 address via SLAAC with our 8-byte
EUI64, and we configure another v6 address via SLAAC with our 2-byte address,
if we should:
   a) always use the 2-byte layer-2 when there is a matching 2-byte v6
      address in the source.  and vv for 8-byte EUI64s
   b) preference the 2-byte layer-3 address so that it is chosen by
      source address selection.

I think that the above probably gets us all the mechanisms we need for
transmit.   For receive, I think that we have no APIs that will give you the
layer-2 address for an incoming packet the way that IPV6_RECVPKTINFO will
do for layer-3 addresses and extensions.   It would be nice to have such
an API.

What do others think?

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