[Babel-users] AE 3 spec versus implementation

[Juliusz Chroboczek]

> 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