Mirrors_Framework/nuttx
1
0
Fork 0
mirror of https://github.com/apache/nuttx.git synced 2026-05-31 23:40:19 +08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Update TODO and README

Browse Source
This commit is contained in:
Gregory Nutt
2017-06-18 09:01:18 -06:00
parent 698dd6d7d1
commit 2ef49eb3bd
2 changed files with 44 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TODO
+12 -9
View File
@@ -1234,14 +1234,14 @@ o Network (net/, drivers/net)
Title: ICMPv6 FOR 6loWPAN Title: ICMPv6 FOR 6loWPAN
Description: The current ICMPv6 and neighbor-related logic only works with Description: The current ICMPv6 and neighbor-related logic only works with
Ethernet MAC. For 6loWPAN, a new more conservative ICMPv6 Ethernet MAC. For 6loWPAN, a new more conservative IPv6
definitions is provided by RFC 6775. This RFC needs to be neigbor discovery is provided by RFC 6775. This RFC needs to
supported in order to support ping6 on a 6loWPAN network. be supported in order to support ping6 on a 6loWPAN network.
If RFC 6775 were implemented, then arbitrary IPv6 addresses, If RFC 6775 were implemented, then arbitrary IPv6 addresses,
including addresses from DHCPv6 could be used. including addresses from DHCPv6 could be used.
can 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, be associated with any short or extended address. In fact,
that is the whole purpose of the neighbor discover logic: It that is the whole purpose of the neighbor discover logic: It
plays the same role as ARP in IPv4; it ultimately just manages 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 Most of the 6loWPAN compression algorithms exploit this to
compress the IPv6 address to nothing but a bit indicating compress the IPv6 address to nothing but a bit indicating
that the IP address derives from the node address. So I 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 If we want to use IPv6 neighbor discovery, we could dispense
based addressing. But if we want to retain the more compact with the all MAC based addressing. But if we want to retain
MAC-based addressing, then we don't need ICMPv6. the more compact MAC-based addressing, then we don't need
IPv6 neighbor discovery.
So, the full neighbor discovery logic is not currently useful, So, the full neighbor discovery logic is not currently useful,
but it would still be nice to have enough in place to support 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 Status: Open
Priority: Low for now. I don't plan on implementing this. It would Priority: Low for now. I don't plan on implementing this. It would
net/sixlowpan/README.txt
+32 -1
View File
@@ -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: 1. Link local IP addresses: