Extension Mechanism for the Babel Routing Protocol
RFC 7557
Document | Type |
RFC - Experimental
(May 2015; No errata)
Updates RFC 6126
Was draft-chroboczek-babel-extension-mechanism (individual)
|
|
---|---|---|---|
Last updated | 2015-10-14 | ||
Stream | ISE | ||
Formats | plain text pdf htmlized bibtex | ||
IETF conflict review | conflict-review-chroboczek-babel-extension-mechanism | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2015-02-15) | ||
IESG | IESG state | RFC 7557 (Experimental) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack |
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 inShow full document text