[babel] Unicast Hello Messages and IHUs

[Margaret Cullen <[e-mail]>]

I spoke with Julius yesterday about the need for unicast Hello messages to support some security scenarios.  If Babel could be run using only unicast messages, this could also enable support for Babel over Non-Broadcast Multi-Access (NBMA) networks.

I’ve looked into this in some detail, and I believe that we can support unicast Hello messages and IHUs (and therefore a fully unicast implementation of Babel) with a small number of changes to the base specification to allow this practice.  In cases where peers are configured or discovered through other means, this does not involve any changes to the core Babel protocol.  The current use of broadcast Hellos and multicast IHUs would continue to be fully supported.  

We have a specialized implementation of Babel that uses unicast Hello messages and IHUs (as described below), with all of the Babel traffic running over GSSAPI in encrypted peer-to-peer sessions (which is something we need for reasons specific to our application).  We have not seen any problems related to using unicast Hello messages in this manner.

I have included a short set of document changes to rfc6126bis below that I believe would accomplish this goal.

Thoughts?

Margaret

_____

In Section 2.1 (Costs, Metric and Neighbourship)

OLD:
A Babel node periodically broadcasts Hello messages to all of its
neighbours; 

NEW:
A Babel node periodically send Hello messages to all of its
neighbours; 


In Section 3.1 (Message Transmission and Reception):

OLD: 
With the exception of Hello TLVs and acknowledgements, all Babel TLVs
can be sent to either unicast or multicast addresses,

NEW:
All Babel TLVs can be sent to either unicast or multicast addresses,

In Section 3.4.1 (Reverse Reachability Detection)
OLD:
Every Babel node sends periodic Hellos over each of its interfaces.
Each Hello TLV carries an increasing (modulo 2^16) sequence number
and the interval between successive periodic packets sent on this
particular interface.

NEW:
Every Babel node sends periodic Hellos, which may be broadcast over 
each of its interfaces, or sent in unicast messages to each of its peers.
The Hello TLV carries a sequence number
and the interval between successive periodic packets sent on this
particular interface.  The sequence number is increased (modulo 2^16)
for each Hello interval.

In Section 3.4.2 (Bidirectional Reachability Detection)
OLD:
While IHUs are conceptually unicast, they SHOULD be sent to a multicast 
address in order to avoid an ARP or Neighbour Discovery exchange and 
to aggregate multiple IHUs in a single packet.

NEW:
While IHUs are conceptually unicast, they SHOULD be sent to a multicast 
address when broadcast and multicast are in use, in order to avoid
an ARP or Neighbour Discovery exchange and to aggregate multiple IHUs
in a single packet.

In section 4.4.5 (Hello)
OLD:
Since there is a single seqno counter for all the Hellos sent by a
given node over a given interface, this TLV MUST be sent to a
multicast destination.  In order to avoid large discontinuities in link 
quality, multiple Hello TLVs SHOULD NOT be sent in the same
packet.

NEW:
Since there is meant to be a single seqno counter for all the Hellos 
sent by a given node over a given interface, this TLV MUST be sent to a
multicast destination, or the set of unicast Hellos sent on a single interface
in a single Hello interval must use the same seqno.  In order to avoid 
large discontinuities in link quality, multiple Hello TLVs SHOULD NOT 
be sent in the same packet.