[mc1322x] 6LowPAN data payload

[Umberto Manzoli]

On 13 July 2010 20:47, Jon Smirl <jonsmirl at gmail.com> wrote:

>
> PPP/SLIP are adding an unnecessary layer of complexity. For example
> I'm not sure yet if they work right for IPv6.  It also makes routing
> more complex. Now the 802.15.4 LAN is hooked to the Ethernet LAN by a
> PTP link instead of a direct connection. Broadcast packets are not
> normally forwarded over PTP links so radvd is messed up. All of this
> is making me learn a lot more about IPv6 than I wanted to.
>
> The main problem is that PPP - because of the presence of a "type of upper
protocol" field in its frame - can handle different protocols in its
payload, so there are extensions for IPv6 and IPv6CP (IPv6 Control Protocol
for PPP). Moreover, through LCP packets, it is possible to manage the status
of the link, i.e. it is possible to send and receive alive packets to and
from the device and thus to automatically disconnect from the serial device
and make some further retries.
RFC 5072 : IPv6 over PPP
RFC 5172 : IPv6CP

SLIP is not recommended for IPv6 operations and IPv6 extensions are not
supported by all operating systems, as it is only a straight-and-forward way
to encapsulate IP frames into a serial stream. There is no link control,
neither different protocol handling.

The big problem with PPP is that the connected device turns into a router,
so a lot of Contiki routing stuff should be rewritten in order to process
and forward IP packets (maybe in different context/prefixes). This means
that device should answer to router-broadcast FE80::2 and forward them.
The other main problem is that, as the connected device acts as a router,
you cannot easily copy-and-forward packets from one interface to another,
but you should route them. So radvd should/could run over the connected
device and the 6LoWPAN nwk and the PPP link should be given different
prefixes and a way to correctly define routing should be provided, at least
at application level, once the PPP link is up.
Again, it is supposed that Linux sets up a PPP link as a slave (i.e. similar
way to the one you use when connecting to a standard modem). Thus, up to
now, IPCP and IPV6CP do provide needed IPv4 addresses and IPv6 interface
identifiers. As PPP means point-to-point, Linux do not forward neighbour
discovery/solicitations over the PPP link.

Bye,
  UM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://devl.org/pipermail/mc1322x/attachments/20100713/c9a24913/attachment.htm>