> During the work on the decoder I spotted another potential > issue. RFC6126 defines address encoding 3 as follows: > > o AE 3: link-local IPv6 address. The value is 8 octets long, a > prefix of fe80::/64 is implied. > > The actual code in network_prefix() looks different, in that less > than 8 octets of encoding would suffice for prefixes /120 and > shorter (as with AE 1 and AE 2):
> This is not tcpdump-specific, the babeld code implements it the same > way. Somebody please proofread these findings. Yes, you're right. I don't think there's an actual mistake in the RFC, but the formulation is not very clear. 1. In the base protocol, AE=3 is only used in IHU and NEXTHOP TLVs, where there is no prefix length and no omitted bytes. (This is implied, since UPDATE and REQUEST TLVs have no business carrying an unroutable prefix, but it should be clearly mentioned.) 2. Should a future extension define a TLV or sub-TLV that uses AE=3 with a prefix length or omitted bytes, then the value could be less than 8 octets. The tcpdump code should therefore be able to parse such address encodings, in preparation for such a future extension. (Note that I do not currently envision any such extensions -- the obvious application would be to reuse the Babel packet format for an autoconf protocol, but I'm strongly opposed to mixing routing with autoconf.) I don't think the above warrants an erratum to RFC 6126. I'll make this clear in the "Extension mechanism for the Babel protocol" RFC which I'm currently preparing (and which you already follow in your auth code). -- Juliusz _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
