[babel] [PATCH] First shot at integrating RFC7557 into RFC6126bis

[Toke Høiland-Jørgensen <[e-mail]>]

The extension mechanism text is integrated into section 4 (with a brief
mention in the introduction, and the IANA stuff copied over as well).
Since RFC7557 basically says either "don't do that" or "we don't know"
with respects to defining new flag values or using the packet trailer, I
decided to just nuke both from this version. I figure they can be added
back in after we converge on a recommendation on what to do with them.

This changeset is somewhat shorter than the original RFC7557 because it
doesn't have to establish context and cross-reference other documents as
much.

Signed-off-by: Toke Høiland-Jørgensen <[e-mail]>
---
 draft-chroboczek-babel-rfc6126bis-00.xml | 249 ++++++++++++++++++++++++++++++-
 1 file changed, 247 insertions(+), 2 deletions(-)

diff --git a/draft-chroboczek-babel-rfc6126bis-00.xml b/draft-chroboczek-babel-rfc6126bis-00.xml
index b64c7b6..44906b3 100644
--- a/draft-chroboczek-babel-rfc6126bis-00.xml
+++ b/draft-chroboczek-babel-rfc6126bis-00.xml
@@ -113,6 +113,14 @@ use in mobile networks that implement automatic prefix aggregation.</t>
 
 </section>
 
+<section title="Extensibility">
+
+<t>The Babel protocol is designed with extensibility in mind. The extension
+mechanism is described in <xref target="extension-mechanism"/>.
+</t>
+
+</section>
+
 <section title="Specification of Requirements">
 
 <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -1309,6 +1317,31 @@ target="JITTER"/>.  In order to allow accurate computation of packet loss
 rates, this delay MUST NOT be larger than half the advertised Hello
 interval.</t>
 
+<section title="Extension mechanism" anchor="extension-mechanism">
+
+<t>The Babel protocol can be extended either by defining new TLVs, or by
+defining sub-TLVs that can be appended to existing TLVs. Implementations MUST
+silently ignore TLV and sub-TLV types it does not understand, which ensures
+interoperability with implementations that do not implement a given
+extension.</t>
+
+<t>In many cases, an extension could be implemented by defining either a new TLV
+or a new sub-TLV. For example, an extension with the purpose of attaching 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.</t>
+
+<t>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 that does not understand it, 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).</t>
+
+</section>
+
 <section title="Data Types">
 
 <section title="Interval">
@@ -1383,7 +1416,7 @@ packets with a first octet different from 42 MUST be silently ignored.</t>
 
 </section>
 
-<section title="TLV Format">
+<section title="TLV Format" anchor="tlv-format">
 
 <t>With the exception of Pad1, all TLVs have the following structure:</t>
 
@@ -1400,7 +1433,8 @@ packets with a first octet different from 42 MUST be silently ignored.</t>
 <t hangText="Type">The type of the TLV.</t>
 <t hangText="Length">The length of the body, exclusive of the Type and
   Length fields.  If the body is longer than the expected length of a given
-  type of TLV, any extra data MUST be silently ignored.</t>
+  type of TLV, any extra data MUST be interpreted as a sequence of sub-TLVs
+  (see <xref target="sub-tlvs"/>).</t>
 <t hangText="Body">The TLV body, the interpretation of which depends on
 the type.</t>
 </list></t>
@@ -1838,6 +1872,113 @@ one neighbour.  A request MUST NOT be forwarded if its Hop Count field is
 
 </section>
 </section>
+
+<section title="Sub-TLVs" anchor="sub-tlvs">
+
+<t>With the exception of the Pad1 TLV, all Babel TLVs carry an explicit length.
+With the exception of Pad1 and PadN, all TLVs 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.</t>
+
+<t>If a TLV is received with an explicit length larger than its natural length,
+the extra space present in the TLV MUST be interpreted as a sequence of
+sub-TLVs. A sub-TLV has exactly the same structure as a TLV. Except for Pad1
+(<xref target="sub-tlv-pad1"/>), all sub-TLVs have the following structure:</t>
+
+<figure><artwork><![CDATA[
+ 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...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+]]></artwork></figure>
+
+
+<t>Fields :
+<list style="hanging" hangIndent="10">
+<t hangText="Type">The type of the sub-TLV.</t>
+<t hangText="Length">The length of the body, exclusive of the Type and
+  Length fields.</t>
+<t hangText="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.</t>
+</list></t>
+
+<t>Sub-TLVs with an unknown type value MUST be silently ignored. Unlike TLVs,
+the sub-TLVs themselves need not be self-terminating.</t>
+
+</section>
+
+<section title="Details of specific sub-TLVs">
+
+<section title="Pad1" anchor="sub-tlv-pad1">
+<figure><artwork><![CDATA[
+ 0
+ 0 1 2 3 4 5 6 7
++-+-+-+-+-+-+-+-+
+|   Type = 0    |
++-+-+-+-+-+-+-+-+
+]]></artwork></figure>
+
+<t>Fields :
+<list style="hanging" hangIndent="10">
+<t hangText="Type">Set to 0 to indicate a Pad1 sub-TLV.</t>
+</list></t>
+<t>This sub-TLV is silently ignored on reception.</t>
+
+<section title="PadN">
+<figure><artwork><![CDATA[
+ 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...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+]]></artwork></figure>
+
+<t>Fields :
+<list style="hanging" hangIndent="10">
+<t hangText="Type">Set to 1 to indicate a PadN sub-TLV.</t>
+<t hangText="Length">The length of the body, exclusive of the Type and
+Length fields.</t>
+<t hangText="MBZ">Set to 0 on transmission.</t>
+</list></t>
+<t>This sub-TLV is silently ignored on reception.</t>
+</section>
+
+</section>
+
+</section>
+
+<section title="Assigning new TLV or sub-TLV types">
+
+<t>An extension MAY be assigned one or more TLV types, or one or more sub-TLV
+types, or both. The choice of whether to TLVs or sub-TLVs for a given extension
+SHOULD be made in consideration of <xref target="extension-mechanism"/>.</t>
+
+<t>All new TLVs MUST have the format defined in <xref target="tlv-format"/>. New
+TLVs SHOULD be self-terminating, in the sense defined in <xref
+target="sub-tlvs"/>, and any data found after the main data section of the TLV
+SHOULD be treated as a series of sub-TLVs.</t>
+
+<t>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.</t>
+
+<t>Both TLV and sub-TLV types 224 through 254 are reserved for Experimental Use
+<xref target="RFC3692"/>. TLV and sub-TLV type 255 is reserved for expansion of
+the type space, in the unlikely event that eight bits turn out not to be
+enough.</t>
+
+
+</section>
+
 </section>
 
 <section title="IANA Considerations">
@@ -1848,6 +1989,47 @@ by the Babel protocol.</t>
 <t>IANA has registered the IPv6 multicast group ff02:0:0:0:0:0:1:6 and the
 IPv4 multicast group 224.0.0.111 for use by the Babel protocol.</t>
 
+<t>IANA has created two new registries, called "Babel TLV types" and "Babel
+sub-TLV types". The allocation policy for both of these registries is Expert
+Review with Specification Required <xref target="RFC5226"/>.</t>
+
+<texttable>
+<preamble>The initial value of the Babel TLV types registry is as follows:
+</preamble>
+<ttcol>Type</ttcol><ttcol>Name</ttcol><ttcol>Reference</ttcol>
+<c>0</c><c>Pad1</c><c>(this document)</c>
+<c>1</c><c>PadN</c><c>(this document)</c>
+<c>2</c><c>Acknowledgment Request</c><c>(this document)</c>
+<c>3</c><c>Acknowledgment</c><c>(this document)</c>
+<c>4</c><c>Hello</c><c>(this document)</c>
+<c>5</c><c>IHU</c><c>(this document)</c>
+<c>6</c><c>Router-Id</c><c>(this document)</c>
+<c>7</c><c>Next Hop</c><c>(this document)</c>
+<c>8</c><c>Update</c><c>(this document)</c>
+<c>9</c><c>Route Request</c><c>(this document)</c>
+<c>10</c><c>Seqno Request</c><c>(this document)</c>
+<c>11</c><c>TS/PC</c><c><xref target="RFC7298"/></c>
+<c>12</c><c>HMAC</c><c><xref target="RFC7298"/></c>
+<c>13</c><c>Source-specific Update</c><c><xref target="BABEL-SS"/></c>
+<c>14</c><c>Source-specific Request</c><c><xref target="BABEL-SS"/></c>
+<c>15</c><c>Source-specific Seqno Request</c><c><xref target="BABEL-SS"/></c>
+<c>224-254</c><c>Reserved for Experimental Use</c><c>(this document)</c>
+<c>255</c><c>Reserved for expansion of the type space</c><c>(this document)</c>
+</texttable>
+
+<texttable>
+<preamble>The initial value of the Babel sub-TLV types registry is as
+follows:
+</preamble>
+<ttcol>Type</ttcol><ttcol>Name</ttcol><ttcol>Reference</ttcol>
+<c>0</c><c>Pad1</c><c>(this document)</c>
+<c>1</c><c>PadN</c><c>(this document)</c>
+<c>2</c><c>Diversity</c><c><xref target="BABEL-DIVERSITY"/></c>
+<c>3</c><c>Timestamp</c><c><xref target="BABEL-RTT"/></c>
+<c>224-254</c><c>Reserved for Experimental Use</c><c>(this document)</c>
+<c>255</c><c>Reserved for expansion of the type space</c><c>(this document)</c>
+</texttable>
+
 </section>
 
 <section title="Security Considerations">
@@ -1887,6 +2069,16 @@ packets are carried over IPv4.</t>
   <seriesInfo name="RFC" value="2119"/>
 </reference>
 
+<reference anchor='RFC3692'>
+  <front>
+    <title>Assigning Experimental and Testing Numbers Considered Useful</title>
+    <author initials='T.' surname='Narten' fullname='T. Narten'></author>
+    <date year='2004' month='January' />
+  </front>
+  <seriesInfo name='BCP' value='82' />
+  <seriesInfo name='RFC' value='3692' />
+</reference>
+
 <reference anchor="ADDRARCH"><front>
     <title>IP Version 6 Addressing Architecture</title>
     <author fullname="Robert M. Hinden" initials="R. M." surname="Hinden"/>
@@ -1896,6 +2088,18 @@ packets are carried over IPv4.</t>
   <seriesInfo name="RFC" value="4291"/>
 </reference>
 
+<reference anchor="RFC5226">
+  <front>
+    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
+    <author initials='T.' surname='Narten' fullname='T. Narten'></author>
+    <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'></author>
+    <date year='2008' month='May' />
+  </front>
+  <seriesInfo name='BCP' value='26' />
+  <seriesInfo name='RFC' value='5226' />
+</reference>
+
+
 </references>
 
 <references title="Informative References">
@@ -1991,6 +2195,47 @@ packets are carried over IPv4.</t>
   <seriesInfo name="RFC" value="5444"/>
 </reference>
 
+<reference anchor='RFC7298'>
+<front>
+<title>Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication</title>
+<author initials='D.' surname='Ovsienko' fullname='D. Ovsienko'></author>
+<date year='2014' month='July' />
+</front>
+<seriesInfo name='RFC' value='7298' />
+</reference>
+
+
+<reference anchor="BABEL-SS">
+<front>
+<title>Source-Specific Routing in Babel</title>
+<author initials='M' surname='Boutier' fullname='Matthieu Boutier'></author>
+<author initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'></author>
+<date month='November' day='20' year='2014' />
+</front>
+<seriesInfo name='Internet-Draft' value='draft-boutier-babel-source-specific-00' />
+</reference>
+
+<reference anchor="BABEL-RTT">
+<front>
+<title>Delay-based Metric Extension for the Babel Routing Protocol</title>
+<author initials='B' surname='Jonglez' fullname='Baptiste Jonglez'></author>
+<author initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'></author>
+<date month='July' day='2' year='2014' />
+</front>
+
+<seriesInfo name='Internet-Draft' value='draft-jonglez-babel-rtt-extension-00' />
+</reference>
+
+<reference anchor="BABEL-DIVERSITY">
+<front>
+<title>Diversity Routing for the Babel Routing Protocol</title>
+<author initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'></author>
+<date month='July' day='4' year='2014' />
+</front>
+<seriesInfo name='Internet-Draft' value='draft-chroboczek-babel-diversity-routing-00' />
+</reference>
+
+
 </references>
 
 <section title="Cost and Metric Computation">
-- 
2.10.0