Skip to main content

Babel routing protocol

Document Charter Babel routing protocol WG (babel)
Title Babel routing protocol
Last updated 2022-03-23
State Approved
WG State Active
IESG Responsible AD Andrew Alston
Charter edit AD Andrew Alston
Send notices to


Babel is a loop-avoiding, distance vector routing protocol with good
provisions for dynamically computed link metrics. The core of the Babel
protocol and security extensions are described in Experimental
Independent Stream RFCs 6126, 7557, and 7298.

These RFCs are the basis of three independent, open source
implementations. There is some production deployment of these
implementations, notably in hybrid networks (networks that include
classical, wired parts with meshy radio bits) and in global overlay
networks (networks built out of large numbers of tunnels spanning

The Working Group will focus on moving the Babel protocol to IETF
Proposed Standard with IETF review. This includes clarifying RFC 6126
and integrating RFC 7557 and feedback provided by independent
implementations, and resolving comments. It is not a requirement that
the Babel protocol produced is backwards compatible with RFC 6126. It
is a requirement that Babel support at least one profile that is
auto-configuring. Other documents that are relevant to the above work
can also be produced. Particular emphasis will be placed on work needed
for a Proposed Standard routing protocol, such as ensuring manageability
and strong security. Link metric measurement or link metric calculation
procedures significantly more complex that those currently in Babel are
out of scope.

The Babel WG should coordinate with other Working Groups, such as the
HOMENET WG for likely applicability, the RTGWG and V6OPS WG about
Source-Specific Routing to support IPv6 multihoming, the PIM WG for
discussion around multicast, and the MANET WG for considerations around

The Babel WG should liaise as necessary with the Broadband Forum to
facilitate use of the Babel Information Model for TR-069.

Work Items:

  • Produce a revision of RFC 6126 suitable for publication as a Proposed
    -- incorporate in the revision developments since RFC 6126
    -- resolve technical issues found
    -- include in the base specification the extensibility work in RFC
    -- support auto-configuration
    -- consider any important changes based on experience with Babel to

  • Address security needs for BABEL. This may include using the
    techniques in RFC 7298, or other alternatives. Security may be
    included in the base spec or the base spec may normatively reference a
    separate Proposed Standard specification. This is required as part of
    moving Babel to Proposed Standard.

  • Address manageability of Babel by producing a Babel informational
    model to help provide guidance and derive the data models. This
    information model is useful as a common source of information for the
    case where the Customer-Premise Equipment (CPE) is managed by the
    Service Provider (SP) with the Broadband Forum TR-069 protocol and its
    associated data model. To be consistent with the ongoing effort to use
    YANG data models in the Routing Area, a Babel YANG data model should
    be specified to support management of Babel routers.

  • As the Proposed Standard version of Babel is completed, an
    Applicability Statement should be finalized to guide those potentially
    interested in deploying Babel. This Applicability Statement may
    include deployment advice and will be published as an RFC.

  • The Working Group should document its ongoing implementation
    experience with Babel, so that new WG participants can understand the
    state that is driving this work and the experience driving changes.
    This documentation may be on the Working Group's wiki, in
    an internet-draft that isn't expected to be published as an RFC, or a

  • As a non-primary focus, the Working Group may work on multicast
    aspects of Babel. This may include discussion of any potential issues
    for supporting Babel running with PIM-SM in an auto-configuration
    profile. It may include exploring Babel carrying separate metrics for
    multicast. It may include discussion and consultation with the PIM
    WG about Babel providing the ability to build multicast routing
    tables. With AD and WG agreement, once an approach is understood,
    then a milestone may be added for an associated document targeted as
    Proposed Standard.

  • As a non-primary focus, the Working Group may work on documents
    defining source specific routing extensions for Babel as a way of
    handling IPv6 multihoming.