Update TODO and README
This commit is contained in:
parent
698dd6d7d1
commit
2ef49eb3bd
21
TODO
21
TODO
@ -1234,14 +1234,14 @@ o Network (net/, drivers/net)
|
||||
|
||||
Title: ICMPv6 FOR 6loWPAN
|
||||
Description: The current ICMPv6 and neighbor-related logic only works with
|
||||
Ethernet MAC. For 6loWPAN, a new more conservative ICMPv6
|
||||
definitions is provided by RFC 6775. This RFC needs to be
|
||||
supported in order to support ping6 on a 6loWPAN network.
|
||||
Ethernet MAC. For 6loWPAN, a new more conservative IPv6
|
||||
neigbor 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.
|
||||
can
|
||||
|
||||
UPDATE: With ICMPv6 neighbor discovery, any IPv6 address may
|
||||
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
|
||||
@ -1256,15 +1256,18 @@ o Network (net/, drivers/net)
|
||||
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 ICMPv6 is useless in the current implementation.
|
||||
think IPv6 neighbor discover is useless in the current
|
||||
implementation.
|
||||
|
||||
If we want to use ICMPv6, 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 ICMPv6.
|
||||
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.
|
||||
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
|
||||
|
@ -1,4 +1,35 @@
|
||||
Optimal 6loWPAN Configuration
|
||||
6LoWPAN Addressing
|
||||
------------------
|
||||
|
||||
The current 6LoWPAN implementation uses only link local, MAC-based
|
||||
addressing addressing (as discussed in more detail below). Thus if you know
|
||||
the node addressing, then you know the IPv6 address (and vice-versa)
|
||||
|
||||
IPv6 Neighbor Discovery is not supported. The current ICMPv6 and neighbor-
|
||||
related logic only works with Ethernet MAC. For 6LoWPAN, a
|
||||
new more conservative IPv6 neigbor discovery is provided by RFC 6775 which
|
||||
is not currently suppored. 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 circumvents 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 kind of addressing
|
||||
to compress the IPv6 address to nothing but a single bit indicating that the
|
||||
IP address derives from the node address. In this use case, IPv6 neighbor
|
||||
discover is not useful: 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.
|
||||
|
||||
However, it would still be nice to have enough in place to support ping6.
|
||||
Full neighbor support would be necessary if we wanted to route 6LoWPAN frames
|
||||
outside of the WPAN.
|
||||
|
||||
Optimal 6LoWPAN Configuration
|
||||
-----------------------------
|
||||
|
||||
1. Link local IP addresses:
|
||||
|
Loading…
Reference in New Issue
Block a user