-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
my understanding of the 6lowpan format draft version 13 is that the Flow Label and UDP Source/Destination Ports would might not end on a byte-boundary. As a result, all further values carried after such a field with byte-unaligned end would possibly also get misaligned and bit shifting would be needed to actually read the correct values. From a discussion with Carsten Bormann I understood that this may not have been the intention when writing the format draft and some byte-alignment/padding could take place earlier than just at the very end after all the compressed/inline-carried fields. The advantage would be easier processing of and not having to bit-shift all subsequent fields. Could someone provide more insights? IMHO, a possible workaround would be to 1) pad the Flow Label with 4 bits of zeros. It usually is not used anyway and hence the possible additional wasted byte could be acceptable in a rather unlikely situation. 2) put the UDP Ports as the last UDP fields rather than the first UDP ones and hence possibly requiring bit-shifting unless both UDP ports are compressed. Should more fields follow after the UDP one in a future version of the draft, padding with zeros could be used after the UDP Ports. Matus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGdx4W43LQWDWf0QIRAqyUAKClOXgQ7+LIldgn5fsfpcExsCi9hACfemqh G9RkSpdqAV7zww6Ob9GwzLM= =pdRZ -----END PGP SIGNATURE----- _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
