Hi Colin,
I've committed both patches. No worries about pending IANA assignment, that will
be worked out before a new stable branch will be created.
Thanks,
Jaap
On 09/30/2010 02:50 PM, Colin O'Flynn wrote:
Hello,
#1)
There was an update to the 6LoWPAN patch from a while back to add
missing features, specifically “context-based” decompression.
In addition I’ve updated that patch to support the latest version of the
6lowpan standard, hc-13. Note that hc-13 has gone to last call and is
unlikely to change the protocol format.
The patch is attached to
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5085 . I’ve tested
this patch, and am also aware of a number of other people testing the
patch as well.
Would it be possible to get this committed to SVN and thus closed?
#2)
There are several I-D’s which define new protocols. Two important
updates for 6lowpan people are 6lowpan-nd (neighbor discovery
extensions) and RPL (routing protocols).
6lowpan-nd is in working-group last-call and seems unlikely to change,
there is a patch to add support at
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5086 .
The I-D however requires the assignment of 3 ND option types by the
IANA, and is temporarily using 31/32/33 as the types as defined in the
I-D. Thus the patch has these hard-coded in just like the other ND
options in packet-ipv6.h. But according to
http://www.iana.org/assignments/icmpv6-parameters this already conflicts
with another option.
How is this normally handled? Is it possible to get the code committed
despite not having official IANA assignments, and they are just updated
when they become official? Even if they were defined to zero, which
isn’t used, it would help as at least the code is present, and thus the
final “patch” is much smaller.
Regards,
-Colin
