Technical work required on encapsulation/format specification:
- Previously, the protocol type was 5 bits, allowing a single-byte fixed overhead. In the current format document, this was changed to 11 bits, requiring two bytes. Gabriel clarified that the fragmentation and reassembly function of the encapsulation would be needed not just for IP itself and its various header compression variants, but also for the intra-mesh routing protocol (e.g., AODV). Christian Huitema suggested looking at existing IANA registries for protocol types to avoid having to set up another one. Specifically, he suggested looking at IP protocol identifiers. Other people suggested looking at link-layer registries such as Ethertype and PPP
protocol IDs. This item requires further work. [6lowpan at IETF 63]
When examining a specific registry, we should make sure that it actually is a good fit. The payloads for the 6lowpan encapsulation are somewhat 6lowpan specific. Raw IPv6 packets are just one type; we also will have a number of rather 6lowpan specific header compression schemes. In addition, routing and registration/management messages are quite likely to be entirely 6lowpan specific.
One other consideration would be whether the 6lowpan registrations would place an undue burden on the original registry. E.g., there are only 256 IP protocol numbers, which makes them a scarce resource.
One other way to manage the number space would be to make one or more existing registries part of the 6lowpan number space. E.g., there could be a selector that chooses between IP protocol numbers and PPP protocol numbers (assuming both actually make sense in this context).
IP protocol numbers are 8 bits. PPP protocol numbers are 14 bits (expressed in either 8 or 16 bits depending on the low order bit of the first byte).