summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7557.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7557.txt')
-rw-r--r--doc/rfc/rfc7557.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc7557.txt b/doc/rfc/rfc7557.txt
new file mode 100644
index 0000000..9ddd3dd
--- /dev/null
+++ b/doc/rfc/rfc7557.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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
+ this document.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
+ this document are to be interpreted as described in [RFC2119].
+
+2. Mechanisms for Extending the Babel Protocol
+
+ This section describes each of the mechanisms available for extending
+ the Babel protocol.
+
+2.1. New Versions of the Babel Protocol
+
+ The header of a Babel packet contains an eight-bit protocol version.
+ The current version of the Babel protocol is version 2; any packets
+ containing a version number different from 2 MUST be silently
+ ignored.
+
+ Versions 0 and 1 were earlier experimental versions of the Babel
+ protocol that have seen some modest deployment; these version numbers
+ SHOULD NOT be reused by future versions of the Babel protocol.
+ Version numbers larger than 2 might be used by a future incompatible
+ protocol.
+
+2.2. New TLVs
+
+ An extension may carry its data in a new TLV type. Such new TLVs
+ will be silently ignored by implementations of the original Babel
+ protocol, as well as by other extended implementations of the Babel
+ protocol, as long as the TLV types do not collide.
+
+ All new TLVs MUST have the format defined in [RFC6126], Section 4.3.
+ New TLVs SHOULD be self-terminating, in the sense defined in the next
+ section, and any data found after the main data section of the TLV
+ SHOULD be treated as a series of sub-TLVs.
+
+ TLV types 224 through 254 are reserved for Experimental Use
+ [RFC3692]. TLV type 255 is reserved for expansion of the TLV type
+ space, in the unlikely event that eight bits turn out not to be
+ enough.
+
+
+
+Chroboczek Experimental [Page 3]
+
+RFC 7557 Babel Extension Mechanism May 2015
+
+
+2.3. Sub-TLVs
+
+ With the exception of the Pad1 TLV, all Babel TLVs carry an explicit
+ length. With the exception of Pad1 and PadN, all TLVs defined by the
+ original protocol are self-terminating, in the sense that the length
+ of the meaningful data that they contain (the "natural length") can
+ be determined without reference to the explicitly encoded length. In
+ some cases, the natural length is trivial to determine: for example,
+ a HELLO TLV always has a natural length of 2 (4 including the Type
+ and Length fields). In other cases, determining the natural length
+ is not that easy, but this needs to be done anyway by an
+ implementation that interprets the given TLV. For example, the
+ natural length of an Update TLV depends on both the prefix length and
+ the amount of prefix compression being performed.
+
+ If the explicit length of a TLV defined by the original protocol is
+ larger than its natural length, the extra space present in the TLV is
+ silently ignored by an implementation of the original protocol;
+ extended implementations MAY use it to store arbitrary data and
+ SHOULD structure the additional data as a sequence of sub-TLVs.
+ Unlike TLVs, the sub-TLVs themselves need not be self-terminating.
+
+ An extension MAY be assigned one or more sub-TLV types. Sub-TLV
+ types are assigned independently from TLV types: the same numeric
+ type can be assigned to a TLV and a sub-TLV. Sub-TLV types are
+ assigned globally: once an extension is assigned a given sub-TLV
+ number, it MAY use this number within any TLV. However, the
+ interpretation of a given sub-TLV type can depend on which particular
+ TLV it is embedded within.
+
+ Sub-TLV types 224 through 254 are reserved for Experimental Use
+ [RFC3692]. TLV type 255 is reserved for expansion of the sub-TLV
+ type space, in the unlikely event that eight bits turn out not to be
+ enough. The format of sub-TLVs is defined in Section 3 below.
+
+2.4. The Flags Field
+
+ The Flags field is an eight-bit field in the Update TLV. Bits 0 and
+ 1 (the bits with values 80 and 40 hexadecimal) are defined by the
+ original protocol and MUST be recognised and used by every
+ implementation. The remaining six bits are not currently used and
+ are silently ignored by implementations of the original protocol.
+
+ Due to the small size of the Flags field, it is NOT RECOMMENDED that
+ one or more bits be assigned to an extension; a sub-TLV SHOULD be
+ assigned instead. An implementation MUST ignore any bits in the
+ Flags field that it does not know about and MUST send them as zero.
+
+
+
+
+Chroboczek Experimental [Page 4]
+
+RFC 7557 Babel Extension Mechanism May 2015
+
+
+2.5. Packet Trailer
+
+ A Babel packet carries an explicit length in its header. A Babel
+ packet is carried by a UDP datagram, which in turn contains an
+ explicit length in its header. It is possible for a UDP datagram
+ carrying a Babel packet to be larger than the size of the Babel
+ packet. In that case, the extra space after the Babel packet, known
+ as the packet trailer, is silently ignored by an implementation of
+ the original protocol.
+
+ The packet trailer was originally intended to be used as a
+ cryptographic trailer. However, the authentication extension to
+ Babel [RFC7298] ended up using a pair of new TLVs, and no currently
+ deployed extension of Babel uses the packet trailer. The format and
+ purpose of the packet trailer is therefore currently left undefined.
+
+3. Format of Sub-TLVs
+
+ A sub-TLV has exactly the same structure as a TLV. Except for Pad1
+ (Section 3.1.1), all sub-TLVs have the following structure:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Body...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Fields:
+
+ Type The type of the sub-TLV.
+
+ Length The length of the body, in octets, exclusive of the Type
+ and Length fields.
+
+ Body The sub-TLV body, the interpretation of which depends on
+ both the type of the sub-TLV and the type of the TLV within
+ which it is embedded.
+
+3.1. Sub-TLVs Specified in This Document
+
+ This document defines two types of sub-TLVs, Pad1 and PadN. These
+ two sub-TLVs MUST be correctly parsed and ignored by any extended
+ implementation of the Babel protocol that uses sub-TLVs.
+
+
+
+
+
+
+
+
+Chroboczek Experimental [Page 5]
+
+RFC 7557 Babel Extension Mechanism May 2015
+
+
+3.1.1. Pad1
+
+ 0
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Type = 0 |
+ +-+-+-+-+-+-+-+-+
+
+ Fields:
+
+ Type Set to 0 to indicate a Pad1 sub-TLV.
+
+ This sub-TLV is silently ignored on reception.
+
+3.1.2. PadN
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 1 | Length | MBZ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+ Fields:
+
+ Type Set to 1 to indicate a PadN sub-TLV.
+
+ Length The length of the body, in octets, exclusive of the Type
+ and Length fields.
+
+ MBZ Set to 0 on transmission.
+
+ This sub-TLV is silently ignored on reception.
+
+3.2. Unknown Sub-TLVs
+
+ Any unknown sub-TLV MUST be silently ignored by an extended
+ implementation that uses sub-TLVs.
+
+4. Choosing between Extension Mechanisms
+
+ New versions of the Babel protocol should only be defined if the new
+ version is not backwards compatible with the original protocol.
+
+ In many cases, an extension could be implemented either by defining a
+ new TLV or by adding a new sub-TLV to an existing TLV. For example,
+ an extension whose purpose is to attach additional data to route
+ updates can be implemented either by creating a new "enriched" Update
+ TLV or by adding a sub-TLV to the Update TLV.
+
+
+
+Chroboczek Experimental [Page 6]
+
+RFC 7557 Babel Extension Mechanism May 2015
+
+
+ The two encodings are treated differently by implementations that do
+ not understand the extension. In the case of a new TLV, the whole
+ unknown TLV is ignored by an implementation of the original protocol,
+ while in the case of a new sub-TLV, the TLV is parsed and acted upon,
+ and the unknown sub-TLV is silently ignored. Therefore, a sub-TLV
+ should be used by extensions that extend the Update in a compatible
+ manner (the extension data may be silently ignored), while a new TLV
+ must be used by extensions that make incompatible extensions to the
+ meaning of the TLV (the whole TLV must be thrown away if the
+ extension data is not understood).
+
+ Using a new bit in the Flags field is equivalent to defining a new
+ sub-TLV while using less space in the Babel packet. Due to the
+ limited Flags space, and the doubtful space savings, we do not
+ recommend the use of bits in the Flags field -- a new sub-TLV should
+ be used instead.
+
+ We refrain from making any recommendations about the usage of the
+ packet trailer due to the lack of implementation experience.
+
+5. IANA Considerations
+
+ IANA has created three new registries, called "Babel TLV Types",
+ "Babel Sub-TLV Types", and "Babel Flags Values". The allocation
+ policy for each of these registries is Specification Required
+ [RFC5226].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chroboczek Experimental [Page 7]
+
+RFC 7557 Babel Extension Mechanism May 2015
+
+
+ The initial values in the "Babel TLV Types" registry are as follows:
+
+ +---------+-----------------------------------------+---------------+
+ | Type | Name | Reference |
+ +---------+-----------------------------------------+---------------+
+ | 0 | Pad1 | [RFC6126] |
+ | | | |
+ | 1 | PadN | [RFC6126] |
+ | | | |
+ | 2 | Acknowledgment Request | [RFC6126] |
+ | | | |
+ | 3 | Acknowledgment | [RFC6126] |
+ | | | |
+ | 4 | Hello | [RFC6126] |
+ | | | |
+ | 5 | IHU | [RFC6126] |
+ | | | |
+ | 6 | Router-Id | [RFC6126] |
+ | | | |
+ | 7 | Next Hop | [RFC6126] |
+ | | | |
+ | 8 | Update | [RFC6126] |
+ | | | |
+ | 9 | Route Request | [RFC6126] |
+ | | | |
+ | 10 | Seqno Request | [RFC6126] |
+ | | | |
+ | 11 | TS/PC | [RFC7298] |
+ | | | |
+ | 12 | HMAC | [RFC7298] |
+ | | | |
+ | 13 | Source-specific Update | [BABEL-SS] |
+ | | | |
+ | 14 | Source-specific Request | [BABEL-SS] |
+ | | | |
+ | 15 | Source-specific Seqno Request | [BABEL-SS] |
+ | | | |
+ | 224-254 | Reserved for Experimental Use | this document |
+ | | | |
+ | 255 | Reserved for expansion of the type | this document |
+ | | space | |
+ +---------+-----------------------------------------+---------------+
+
+
+
+
+
+
+
+
+
+Chroboczek Experimental [Page 8]
+
+RFC 7557 Babel Extension Mechanism May 2015
+
+
+ The initial values in the "Babel Sub-TLV Types" registry are as
+ follows:
+
+ +---------+-----------------------------------------+---------------+
+ | Type | Name | Reference |
+ +---------+-----------------------------------------+---------------+
+ | 0 | Pad1 | this document |
+ | | | |
+ | 1 | PadN | this document |
+ | | | |
+ | 2 | Diversity | [BABEL-DIV] |
+ | | | |
+ | 3 | Timestamp | [BABEL-RTT] |
+ | | | |
+ | 224-254 | Reserved for Experimental Use | this document |
+ | | | |
+ | 255 | Reserved for expansion of the type | this document |
+ | | space | |
+ +---------+-----------------------------------------+---------------+
+
+ The initial values in the "Babel Flags Values" registry are as
+ follows:
+
+ +-----+-------------------+-----------+
+ | Bit | Name | Reference |
+ +-----+-------------------+-----------+
+ | 0 | Default prefix | [RFC6126] |
+ | | | |
+ | 1 | Default router-id | [RFC6126] |
+ | | | |
+ | 2-7 | Unassigned | |
+ +-----+-------------------+-----------+
+
+6. Security Considerations
+
+ This document specifies the structure of fields that are already
+ present in the original Babel protocol and does not, by itself, raise
+ any new security considerations. Specific extensions may change the
+ security properties of the protocol, for example, by adding security
+ mechanisms [RFC7298] or by enabling new kinds of attack.
+
+
+
+
+
+
+
+
+
+
+
+Chroboczek Experimental [Page 9]
+
+RFC 7557 Babel Extension Mechanism May 2015
+
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
+ Considered Useful", BCP 82, RFC 3692,
+ DOI 10.17487/RFC3692, January 2004,
+ <http://www.rfc-editor.org/info/rfc3692>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ DOI 10.17487/RFC5226, May 2008,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+ [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
+ DOI 10.17487/RFC6126, April 2011,
+ <http://www.rfc-editor.org/info/rfc6126>.
+
+7.2. Informative References
+
+ [BABEL-DIV] Chroboczek, J., "Diversity Routing for the Babel Routing
+ Protocol", Work in Progress, draft-chroboczek-babel-
+ diversity-routing-00, July 2014.
+
+ [BABEL-RTT] Jonglez, B. and J. Chroboczek, "Delay-based Metric
+ Extension for the Babel Routing Protocol", Work in
+ Progress, draft-jonglez-babel-rtt-extension-01, May 2015.
+
+ [BABEL-SS] Boutier, M. and J. Chroboczek, "Source-Specific Routing
+ in Babel", Work in Progress, draft-boutier-babel-
+ source-specific-01, May 2015.
+
+ [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code
+ (HMAC) Cryptographic Authentication", RFC 7298,
+ DOI 10.17487/RFC7298, July 2014,
+ <http://www.rfc-editor.org/info/rfc7298>.
+
+
+
+
+
+
+
+
+
+
+Chroboczek Experimental [Page 10]
+
+RFC 7557 Babel Extension Mechanism May 2015
+
+
+Acknowledgments
+
+ I am grateful to Denis Ovsienko and Gabriel Kerneis for their
+ feedback on previous draft versions of this document.
+
+Author's Address
+
+ Juliusz Chroboczek
+ PPS, University of Paris-Diderot
+ Case 7014
+ 75205 Paris Cedex 13
+ France
+
+ EMail: jch@pps.univ-paris-diderot.fr
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chroboczek Experimental [Page 11]
+