Re: bluetooth 6lowpan interfaces are not virtual anymore

[Michael Richardson <mcr@sandelman.ca>]

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


Alexander Aring <aar@pengutronix.de> wrote:
    > What does the 6LoWPAN interface?

    > It will do a protocol change (an adaptation, because 6LoWPAN should
    > provide the same functionality as IPv6) from IPv6 to 6LoWPAN (tx) and
    > vice versa for (rx). In my opinion this should be handled as a virtual
    > interface and not as an interface with a queue.

I wonder if modeling all the 6lowpan work as a virtual interface is even
the right abstraction anymore.  I think that it was certainly a good model at
the time the interface was created, given no other clear thing to do.

We don't model IPv6 ND (or IPv4 ARP) or fragmentation in general as a
virtual interface on top of a raw interface.

Really, it's a set of operations that happens on a packet.
802.15.4 is notable for it's current lack of an ethertype (IEEE is fixing
that though), so you can't actually run different protocols on the
same PANID.
BT does have a variety of different protocols, and IPv6 is only one.

In a classic SVR4 STREAMS works, it would have been just another module.
(No, I'm not a fan of *STREAMS* or of SVR4 in general,  although I liked
some of the ideas).

At this time, things like PANID and channel are set on the wpanX interface.
If they were set on the 6lowpan interface, such that one could (in theory,
assuming the hardware could do it, which some can, and some can not) then
one could have multiple 6lowpan interfaces on top of the same wpanX.
Or one could run some non-IP protocol like pre-IP Zigbee on one PANID
while one runs 6lowpan on another.  THEN, a virtual interface would make
sense for the same reason VLAN interfaces make sense.