ICMPv6 FOR 6LoWPAN

```
Description: The current ICMPv6 and neighbor-related logic only works with
Ethernet MAC. For 6LoWPAN, a new more conservative IPv6
neighbour discovery is provided by RFC 6775. This RFC needs to
be supported in order to support ping6 on a 6LoWPAN network.
If RFC 6775 were implemented, then arbitrary IPv6 addresses,
including addresses from DHCPv6 could be used.

UPDATE: With IPv6 neighbor discovery, any IPv6 address may
be associated with any short or extended address. In fact,
that is the whole purpose of the neighbor discover logic: It
plays the same role as ARP in IPv4; it ultimately just manages
a neighbor table that, like the arp table, provides the
mapping between IP addresses and node addresses.

The NuttX, Contiki-based 6LoWPAN implementation circumvented
the need for the neighbor discovery logic by using only MAC-
based addressing, i.e., the lower two or eight bytes of the
IP address are the node address.

Most of the 6LoWPAN compression algorithms exploit this to
compress the IPv6 address to nothing but a bit indicating
that the IP address derives from the node address. So I
think IPv6 neighbor discover is useless in the current
implementation.

If we want to use IPv6 neighbor discovery, we could dispense
with the all MAC based addressing. But if we want to retain
the more compact MAC-based addressing, then we don't need
IPv6 neighbor discovery.

So, the full neighbor discovery logic is not currently useful,
but it would still be nice to have enough in place to support
ping6. Full neighbor support would probably be necessary if we
wanted to route 6LoWPAN frames outside of the WPAN.

Status: Open
Priority: Low for now. I don't plan on implementing this. It would
only be relevant if we were to decide to abandon the use of
MAC-based addressing in the 6LoWPAN implementation.
```