Extension Mechanism for the Babel Routing Protocol
RFC 7557

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04

Independent Submission                                     J. Chroboczek
Request for Comments: 7557              PPS, University of Paris-Diderot
Updates: 6126                                                   May 2015
Category: Experimental
ISSN: 2070-1721

           Extension Mechanism for the Babel Routing Protocol

Abstract

   This document defines the encoding of extensions to the Babel routing
   protocol, as specified in RFC 6126.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This is a contribution to the RFC Series, independently
   of any other RFC stream.  The RFC Editor has chosen to publish this
   document at its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7557.

Copyright Notice

   Copyright (c) 2015 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
   (http://trustee.ietf.org/license-info) 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.

Chroboczek                    Experimental                      [Page 1]
RFC 7557                Babel Extension Mechanism               May 2015

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Mechanisms for Extending the Babel Protocol . . . . . . . . .   3
     2.1.  New Versions of the Babel Protocol  . . . . . . . . . . .   3
     2.2.  New TLVs  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Sub-TLVs  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  The Flags Field . . . . . . . . . . . . . . . . . . . . .   4
     2.5.  Packet Trailer  . . . . . . . . . . . . . . . . . . . . .   5
   3.  Format of Sub-TLVs  . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Sub-TLVs Specified in This Document . . . . . . . . . . .   5
     3.2.  Unknown Sub-TLVs  . . . . . . . . . . . . . . . . . . . .   6
   4.  Choosing between Extension Mechanisms . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   A Babel packet [RFC6126] contains a header followed by a sequence of
   TLVs, each of which is a sequence of octets having an explicit type
   and length.  The original Babel protocol has the following provisions
   for including extension data:

   o  A Babel packet with a version number different from 2 MUST be
      silently ignored ([RFC6126], Section 4.2).

   o  An unknown TLV MUST be silently ignored ([RFC6126], Section 4.3).

   o  Except for Pad1 and PadN, all TLVs are self-terminating, and any
      extra data included in a TLV MUST be silently ignored ([RFC6126],
      Section 4.2).

   o  The Flags field of the Update TLV contains 6 undefined bits that
      MUST be silently ignored ([RFC6126], Section 4.4.9).

   o  Any data following the last TLV of a Babel packet MUST be silently
      ignored ([RFC6126], Section 4.2).

   Each of these provisions provides a place to store data needed by
   extensions of the Babel protocol.  However, in the absence of any
   further conventions, independently developed extensions to the Babel
   protocol might make conflicting uses of the available space, and
   therefore lead to implementations that would fail to interoperate.

Chroboczek                    Experimental                      [Page 2]
RFC 7557                Babel Extension Mechanism               May 2015

   This document formalises a set of rules for extending the Babel
   protocol that are designed to ensure that no such incompatibilities
   arise, and that are currently respected by a number of deployed
   extensions.

   In the rest of this document, we use the term "original protocol" for
   the protocol defined in [RFC6126], and "extended protocol" for any
   extension of the Babel protocol that follows the rules set out in