Network Working Group J. Chroboczek
Internet-Draft IRIF, University of Paris-Diderot
Intended status: Informational January 5, 2017
Expires: July 9, 2017

Applicability of the Babel routing protocol


This document describes some application areas where the Babel routing protocol (RFC 6126) has been found to be useful.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 9, 2017.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Babel [RFC6126] is a loop-avoiding distance-vector routing protocol that aims to be robust in a variety of environments.

This document describes a few areas where Babel has been found to be useful. It is structured as follows. In Section 2, we describe application areas where Babel has been successfully deployed, and in Section 3, we describe application areas where deployment of Babel is not encouraged because better alternatives are available.

2. Existing successful deployments of Babel

2.1. Hybrid networks

Babel is able to deal with both classical, prefix-based ("Internet-style") routing and flat ("mesh-style") routing over non-transitive link technologies. Because of that, it has seen a number of succesful deployments in medium-sized hybrid networks, networks that combine a wired, aggregated backbone with meshy wireless bits at the edges. No other routing protocol known to us is similarly robust and efficient in this particular type of network.

2.2. Large scale overlay networks

The algorithms used by Babel (loop avoidance, hysteresis, delayed updates) allow it to remain stable and efficient in the presence of unstable metrics, even in the presence of a feedback loop. For this reason, it has been successfully deployed in large scale overlay networks, built out of thousands of tunnels spanning continents, where it is used with a metric computed from links' latencies [DELAY-BASED].

2.3. Pure mesh networks

Babel has been repeatedly shown to be competitive with dedicated routing protocols for wireless mesh networks [REAL-WORLD] [BRIDGING-LAYERS]. While this particular niche is already served by a number of mature protocols, notably OLSR-ETX and OLSRv2 [RFC7181] equipped with the DAT metric [RFC7779], Babel has seen a moderate amount of successful deployment in pure mesh networks.

2.4. Small unmanaged networks

Because of its small size and simple configuration, Babel has been deployed in small, unmanaged networks (three to five routers), where it serves as a more efficient replacement for RIP [RFC2453], with the significant advantage of having good support for wireless links.

3. Application Areas where Babel is not recommended

There exist application areas where Babel is a poor fit.

3.1. Large, stable networks

Babel relies on periodic updates, and even in a stable network, it generates a constant amount of background traffic. In large, stable, well-administered networks, it is preferable to use protocols layered above a reliable transport mechanism, such as OSPF [RFC5340], EIGRP [RFC7868] or IS-IS [RFC1195].

3.2. Low-power and constrained networks

Babel relies on periodic updates and maintains within each node an amount of state that is proportional to the number of reachable destinations. In networks containing resource-constrained or exteremely low-power nodes, it may be preferable to use a protocol that limits the amount of state maintained and propagated; we have heard of AODVv2 [AODVv2], RPL [RFC6550] and LOADng [LOADng].

4. IANA Considerations

This document requires no IANA actions. [RFC Editor: please remove this section before publication.]

5. Security Considerations

As in all distance-vector routing protocols, a Babel speaker receives reachability information from its neighbours, which by default is trusted. A number of attacks are possible if this information is not suitably protected, either by a lower-layer mechanism or by an extension to the protocol itself (e.g. [RFC7298]).

Implementors and deployers must be aware of the insecure nature of the base protocol, and must take suitable measures to ensure that the protocol is deployed as securely as required by the application.

6. Informational References

[AODVv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L. and V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing", Internet-Draft draft-ietf-manet-aodvv2-16, May 2016.
[BRIDGING-LAYERS] Murray, D., Dixon, M. and T. Koziniec, "An Experimental Comparison of Routing Protocols in Multi Hop Ad Hoc Networks", Proc. ATNAC 2010, 2010.
[DELAY-BASED] Jonglez, B. and J. Chroboczek, "A delay-based routing metric", March 2014.
[LOADng] Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T. and J. Dean, "The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)", Internet-Draft draft-clausen-lln-loadng-15, January 2017.
[REAL-WORLD] Abolhasan, M., Hagelstein, B. and J. Wang, "Real-world performance of current proactive multi-hop mesh protocols", Asia-Pacific Conference on Communication 2009, 2009.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC5340] Coltun, R., Ferguson, D., Moy, J. and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, February 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P. and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014.
[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, DOI 10.17487/RFC7298, July 2014.
[RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)", RFC 7779, DOI 10.17487/RFC7779, April 2016.
[RFC7868] Savage, D., Ng, J., Moore, S., Slice, D., Paluch, P. and R. White, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", RFC 7868, DOI 10.17487/RFC7868, May 2016.

Author's Address

Juliusz Chroboczek IRIF, University of Paris-Diderot Case 7014 75205 Paris Cedex 13, France EMail: