Bird does not include next hop information in babel retractions, while babeld requires them

[Toke Høiland-Jørgensen]

Fabian Bläse <fabian at blaese.de> writes:

> Hi,
>
> when using both bird and babeld in our babel network, babeld regularly
> complains about malformed packets. This happens when bird sends route
> retractions without including router-id and next-hop TLVs first.
> According to rfc6126 the router-id is not used for retractions. The
> resulting error message was an issue with babeld and has been fixed
> already [1].
>
> However, babeld also does not like if retractions are not preceded by
> next-hop TLVs, which are indeed evaluated for retracting a route. Bird
> does not send next-hop TLVs for route retractions though [3] and
> ignores next-hop information, when processing received retractions
> itself [4][5].
>
> I could not find any information which of these behaviours is correct.
>
> But other than for the router-id, the encoding description of Update
> TLVs (rfc6126, section 4.4.9) does not say that the next-hop address
> is ignored for retractions.

RFC6126bis[0] (which is what Bird implements) says that it's also babeld
that is wrong here (near the end of section 4.6.9):

   If the metric field is FFFF hexadecimal, this TLV specifies a
   retraction.  In that case, the router-id, next-hop and seqno are not
   used.  AE MAY then be 0, in which case this Update retracts all of
   the routes previously advertised by the sending interface.  If the
   metric is finite, AE MUST NOT be 0; Update TLVs with finite metric
   and AE equal to 0 MUST be ignored.  If the metric is infinite and AE
   is 0, Plen and Omitted MUST both be 0.

-Toke

[0] https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-17#section-4.6