[Babel-users] on Babel protocol decoding in tcpdump

[Denis Ovsienko]

Hello, list.

The three latest commits in my copy of tcpdump are Babel-focused. Two commits 
address Pad1 TLV iteration issue and one commit implements sub-TLV decoding, 
which so far is only used to carry channel information for the diversity 
routing feature. Somebody please review/test this before I offer these changes 
for tcpdump upstream:

https://github.com/infrastation/tcpdump

-- 
Denis Ovsienko

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] AE 3 spec versus implementation

[Denis Ovsienko]

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):

case 3:
if(pb  8  len  pb - 8) return -1;
prefix[0] = 0xfe;
prefix[1] = 0x80;
if(pb  8) {
memcpy(prefix + 8, p, pb - 8);
consumed = pb - 8;
}
break;


This is not tcpdump-specific, the babeld code implements it the same way. 
Somebody please proofread these findings.

-- 
Denis Ovsienko

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [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

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users