4 ms·

I wish they provided enough actual technical details to see what's new here. As far as I'm aware, the usual way to do IP-over-Bluetooth encapsulation is using t

I wish they provided enough actual technical details to see what's new here. As far as I'm aware, the usual way to do IP-over-Bluetooth encapsulation is using the Personal Area Networking profile [1], which has required support for IPv6 support since 2001. (I've never tested it on real hardware with anything other than IPv4, so maybe it was specified but never implemented? Regardless, it seems odd that a mechanism that tunnels Ethernet packets would have to care about higher levels of the protocol stack.) [1]: http://grouper.ieee.org/groups/802/15/Bluetooth/PAN-Profile.pdf http://grouper.ieee.org/groups/802/15/Bluetooth/PAN-Profile....

rwg 12y ago
I'm guessing it's related to IPv6 over Bluetooth Low Energy, which is currently working its way through the bowels of the IETF: https://tools.ietf.org/html/draft-ietf-6lo-btle https://tools.ietf.org/html/draft-ietf-6lo-btle Basically, they saw what a glorious success 6LoWPAN (IPv6 over 802.15.4) has been (</sarcasm>), realized BLE/L2CAP has a fair bit in common with 802.15.4 (focus on minimizing power consumption, low data rates, crazy small per-packet payload sizes), and decided to reuse 6LoWPAN's IPv6 header compression (RFC 6282) in this IPv6-over-BLE standard.
- teacup50 12y ago
  To be fair, 6lowpan has suffered in no small part due to 802.15.4 itself having no real deployment outside of use for proprietary mesh network protocols. BTLE has far, far, far wider hardware deployment.
- maguirre 12y ago
  while 6LoWPAN hasn't seen as wide adoption as I would have expected it appears that much if the standard will be implemented by google's THREAD, although not guaranteed success I'd not dismiss 6LoWPAN just yet