rfc9080xml2.original.xml   rfc9080.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="no" ?>
<rfc category="std" docName="draft-ietf-homenet-babel-profile-07"
ipr="trust200902">
<front>
<title abbrev="Homenet Babel profile">Homenet profile of the Babel routing proto
col</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
<organization>IRIF, University of Paris-Diderot</organization>
<address>
<postal>
<street>Case 7014</street>
<city>75205 Paris Cedex 13</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>jch@irif.fr</email>
</address>
</author>
<date day="18" month="July" year="2018"/>
<abstract> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<t>This document defines the exact subset of the Babel routing protocol
and its extensions that is required by an implementation of the Homenet
protocol suite, as well as the interactions between the Home Networking
Control Protocol (HNCP) and Babel.</t>
</abstract>
</front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-ietf-homenet-babel-profile-07"
number="9080"
ipr="trust200902"
obsoletes=""
updates=""
submissionType="IETF"
category="std"
consensus="true"
xml:lang="en"
tocInclude="true"
tocDepth="2"
symRefs="true"
sortRefs="true"
version="3">
<middle> <!-- xml2rfc v2v3 conversion 3.2.1 -->
<section title="Introduction"> <front>
<title abbrev="Homenet Babel Profile">Homenet Profile of the Babel Routing P
rotocol</title>
<seriesInfo name="RFC" value="9080"/>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
<organization>IRIF, University of Paris-Diderot</organization>
<address>
<postal>
<street>Case 7014</street>
<city>Paris CEDEX 13</city>
<code>75205</code>
<country>France</country>
</postal>
<email>jch@irif.fr</email>
</address>
</author>
<date month="August" year="2021"/>
<t>The core of the Homenet protocol suite consists of the Home Networking <abstract>
Control Protocol (HNCP) <xref target="RFC7788"/>, a protocol used for <t>This document defines the exact subset of the Babel routing protocol
and its extensions that is required by an implementation of the Homenet
protocol suite, as well as the interactions between the Home Networking
Control Protocol (HNCP) and Babel.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>The core of the Homenet protocol suite consists of the Home Networking
Control Protocol (HNCP) <xref target="RFC7788" format="default"/>, a protocol us
ed for
flooding configuration information and assigning prefixes to links, flooding configuration information and assigning prefixes to links,
combined with the Babel routing protocol <xref target="RFC6126bis"/>. combined with the Babel routing protocol <xref target="RFC8966" format="default"
Babel is an extensible, flexible and modular protocol: minimal />.
Babel is an extensible, flexible, and modular protocol: minimal
implementations of Babel have been demonstrated that consist of a few implementations of Babel have been demonstrated that consist of a few
hundred lines of code, while the "large" implementation includes support hundred lines of code, while the "large" implementation includes support
for a number of extensions and consists of over ten thousand lines of for a number of extensions and consists of over ten thousand lines of
C code.</t> C code.</t>
<t>This document consists of two parts. The first specifies the exact
<t>This document consists of two parts. The first specifies the exact
subset of the Babel protocol and its extensions that is required by an subset of the Babel protocol and its extensions that is required by an
implementation of the Homenet protocol suite. The second specifies how implementation of the Homenet protocol suite. The second specifies how
HNCP interacts with Babel.</t> HNCP interacts with Babel.</t>
<section numbered="true" toc="default">
<section title="Requirement Language"> <name>Requirements Language</name>
<t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in BCP 14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, RECOMMENDED</bcp14>",
they appear in all capitals, as shown here.</t> "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</section> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref tar
<section title="Background"> get="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.
<t>The Babel routing protocol and its extensions are defined in a number </t>
</section>
<section numbered="true" toc="default">
<name>Background</name>
<t>The Babel routing protocol and its extensions are defined in a number
of documents: of documents:
<list style="symbols"> </t>
<t>RFC&nbsp;6126bis <xref target="RFC6126bis"/> defines the Babel routing <ul spacing="normal">
<li>RFC&nbsp;8966 <xref target="RFC8966" format="default"/> defines th
e Babel routing
protocol. It allows Babel's control data to be carried either over protocol. It allows Babel's control data to be carried either over
link-local IPv6 or over IPv4, and in either case allows announcing both link-local IPv6 or over IPv4 and in either case allows announcing both
IPv4 and IPv6 routes. It leaves link cost estimation, metric computation IPv4 and IPv6 routes. It leaves link cost estimation, metric computation,
and route selection to the implementation. Distinct implementations of and route selection to the implementation. Distinct implementations of
RFC&nbsp;6126bis Babel will interoperate, in the sense that they will Babel <xref target="RFC8966" format="default"/> will interoperate, in the sense that they will
maintain a set of loop-free forwarding paths. However, if they implement maintain a set of loop-free forwarding paths. However, if they implement
conflicting options, they might not be able to exchange a full set of conflicting options, they might not be able to exchange a full set of
routes; in the worst case, an implementation that only implements the IPv6 routes. In the worst case, an implementation that only implements the IPv6
subset of the protocol and an implementation that only implements the IPv4 subset of the protocol and an implementation that only implements the IPv4
subset of the protocol will not exchange any routes. In addition, if subset of the protocol will not exchange any routes. In addition, if
implementations use conflicting route selection policies, persistent implementations use conflicting route selection policies, persistent
oscillations might occur.</t> oscillations might occur.</li>
<t>The informative Appendix&nbsp;A of RFC&nbsp;6126bis suggests a simple and <li>The informative <xref target="RFC8966" section="A" sectionFormat="
easy to implement algorithm for cost and metric computation that has been of" format="default"/> suggests a simple and
found to work satisfactorily in a wide range of topologies.</t> easy-to-implement algorithm for cost and metric computation that has been
<t>While RFC&nbsp;6126bis does not provide an algorithm for route selection, found to work satisfactorily in a wide range of topologies.</li>
its Section&nbsp;3.6 suggests selecting the route with smallest metric <li>While RFC&nbsp;8966 does not provide an algorithm for route select
ion,
its Section <xref target="RFC8966" section="3.6" sectionFormat="bare" format="de
fault"/>
suggests selecting the route with the smallest metric
with some hysteresis applied. An algorithm that has been found to work with some hysteresis applied. An algorithm that has been found to work
well in practice is described in Section&nbsp;III.E of well in practice is described in Section&nbsp;III.E of
<xref target="DELAY-BASED"/>.</t> <xref target="DELAY-BASED" format="default"/>.</li>
<t>Five RFCs and Internet-Drafts define optional extensions to Babel: <li>Four documents define optional extensions to Babel:
HMAC-based authentication <xref target="RFC7298"/>, source-specific authentication based on Hashed Message Authentication Code (HMAC) <xref target="
routing <xref target="BABEL-SS"/>, delay-based routing RFC8967" format="default"/>,
<xref target="BABEL-RTT"/> and ToS-specific routing source-specific routing <xref target="RFC9079" format="default"/>,
<xref target="ToS-SPECIFIC"/>. All of these extensions interoperate with delay-based routing <xref target="I-D.ietf-babel-rtt-extension" format="default"
the core protocol as well as with each other.</t> />, and
</list> ToS-specific (Type of Service) routing <xref target="I-D.chouasne-babel-tos-spec
</t> ific" format="default"/>.
All of these extensions interoperate with
</section> the core protocol as well as with each other.</li>
</ul>
</section> </section>
</section>
<section title="The Homenet profile of Babel"> <section numbered="true" toc="default">
<name>The Homenet Profile of Babel</name>
<section title="Requirements"> <section numbered="true" toc="default">
<name>Requirements</name>
<t>REQ1: a Homenet implementation of Babel MUST encapsulate Babel control <ol type="REQ%d:" group="req" indent="8">
<li anchor="req1"><t>A Homenet implementation of Babel <bcp14>MUST</bcp1
4> encapsulate Babel control
traffic in IPv6 packets sent to the IANA-assigned port 6696 and either the traffic in IPv6 packets sent to the IANA-assigned port 6696 and either the
IANA-assigned multicast group ff02::1:6 or to a link-local unicast IANA-assigned multicast group ff02::1:6 or to a link-local unicast
address.</t> address.</t>
<t indent="3">Rationale: Since Babel is able to carry both
<t><list style="empty"><t>Rationale: since Babel is able to carry both
IPv4 and IPv6 routes over either IPv4 or IPv6, choosing the protocol used IPv4 and IPv6 routes over either IPv4 or IPv6, choosing the protocol used
for carrying control traffic is a matter of preference. Since IPv6 has for carrying control traffic is a matter of preference. Since IPv6 has
some features that make implementations somewhat simpler and more reliable some features that make implementations somewhat simpler and more reliable
(notably properly scoped and reasonably stable link-local addresses), we (notably properly scoped and reasonably stable link-local addresses), we
require carrying control data over IPv6.</t></list></t> require carrying control data over IPv6.</t></li>
<li anchor="req2"><t>A Homenet implementation of Babel <bcp14>MUST</bcp1
<t>REQ2: a Homenet implementation of Babel MUST implement the IPv6 subset 4> implement the IPv6 subset
of the protocol defined in the body of RFC&nbsp;6126bis.</t> of the protocol defined in the body of RFC&nbsp;8966.</t>
<t indent="3">Rationale: Support for IPv6 routing is an
<t><list style="empty"><t>Rationale: support for IPv6 routing is an essential component of the Homenet architecture.</t></li>
essential component of the Homenet architecture.</t></list></t> <li anchor="req3"><t>A Homenet implementation of Babel <bcp14>SHOULD</bc
p14> implement the IPv4
<t>REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 subset of the protocol defined in the body of RFC&nbsp;8966. Use of other
subset of the protocol defined in the body of RFC&nbsp;6126bis. Use of other
techniques for acquiring IPv4 connectivity (such as multiple layers of techniques for acquiring IPv4 connectivity (such as multiple layers of
NAT) is strongly discouraged.</t> NAT) is strongly discouraged.</t>
<t indent="3">Rationale: Support for IPv4 will likely remain
<t><list style="empty"><t>Rationale: support for IPv4 will likely remain
necessary for years to come, and even in pure IPv6 deployments, including necessary for years to come, and even in pure IPv6 deployments, including
code for supporting IPv4 has very little cost. Since HNCP makes it easy code for supporting IPv4 has very little cost. Since HNCP makes it easy
to assign distinct IPv4 prefixes to the links in a network, it is not to assign distinct IPv4 prefixes to the links in a network, it is not
necessary to resort to multiple layers of NAT, with all of its necessary to resort to multiple layers of NAT, with all of its
problems.</t></list></t> problems.</t></li>
<li anchor="req4"><t>A Homenet implementation of Babel <bcp14>MUST</bcp1
<t>REQ4: a Homenet implementation of Babel MUST implement source-specific 4> implement source-specific
routing for IPv6, as defined in draft-ietf-babel-source-specific routing for IPv6, as defined in RFC 9079
<xref target="BABEL-SS"/>.</t> <xref target="RFC9079" format="default"/>.</t>
<t indent="3">Rationale: Source-specific routing is an
<t><list style="empty"><t>Rationale: source-specific routing is an
essential component of the Homenet architecture. Source-specific routing essential component of the Homenet architecture. Source-specific routing
for IPv4 is not required, since HNCP arranges things so that a single for IPv4 is not required, since HNCP arranges things so that a single
non-specific IPv4 default route is announced (Section&nbsp;6.5 of <xref nonspecific IPv4 default route is announced (<xref target="RFC7788" section="6.5
target="RFC7788"/>).</t></list></t> " sectionFormat="of" format="default"/>).</t></li>
<li anchor="req5"><t>A Homenet implementation of Babel must use metrics
<t>REQ5: a Homenet implementation of Babel must use metrics that are that are
of a similar magnitude to the values suggested in Appendix&nbsp;A of of a similar magnitude to the values suggested in
RFC&nbsp;6126bis. In particular, it SHOULD assign costs that are no less <xref target="RFC8966" section="A" sectionFormat="of" format="default"/>.
than 256 to wireless links, and SHOULD assign costs between 32 and 196 to In particular, it <bcp14>SHOULD</bcp14> assign costs that are no less
than 256 to wireless links and <bcp14>SHOULD</bcp14> assign costs between 32 and
196 to
lossless wired links.</t> lossless wired links.</t>
<t indent="3">Rationale: If two implementations of Babel
<t><list style="empty"><t>Rationale: if two implementations of Babel
choose very different values for link costs, combining routers from choose very different values for link costs, combining routers from
different vendors will cause sub-optimal routing.</t></list></t> different vendors will cause suboptimal routing.</t></li>
<li anchor="req6"><t>A Homenet implementation of Babel <bcp14>SHOULD</bc
<t>REQ6: a Homenet implementation of Babel SHOULD distinguish between p14> distinguish between
wired and wireless links; if it is unable to determine whether a link is wired and wireless links; if it is unable to determine whether a link is
wired or wireless, it SHOULD make the worst-case hypothesis that the link wired or wireless, it <bcp14>SHOULD</bcp14> make the worst-case hypothesis that
is wireless. It SHOULD dynamically probe the quality of wireless links the link
and derive a suitable metric from its quality estimation. Appendix&nbsp;A is wireless. It <bcp14>SHOULD</bcp14> dynamically probe the quality of wireless
of RFC&nbsp;6126bis gives an example of a suitable algorithm.</t> links
and derive a suitable metric from its quality estimation.
<t><list style="empty"><t>Rationale: support for wireless transit links is <xref target="RFC8966" section="A" sectionFormat="of" format="default"/>
gives an example of a suitable algorithm.</t>
<t indent="3">Rationale: Support for wireless transit links is
a distinguishing feature of Homenet, and one that is requested by our a distinguishing feature of Homenet, and one that is requested by our
users. In the absence of dynamically computed metrics, the routing users. In the absence of dynamically computed metrics, the routing
protocol attempts to minimise the number of links crossed by a route, and protocol attempts to minimise the number of links crossed by a route and
therefore prefers long, lossy links to shorter, lossless ones. In therefore prefers long, lossy links to shorter, lossless ones. In
wireless networks, "hop-count routing is worst-path routing".</t> wireless networks, "hop-count routing is worst-path routing".</t>
<t indent="3">While it would be desirable to perform link-quality prob
<t>While it would be desirable to perform link-quality probing on some ing on some
wired link technologies, notably power-line networks, these kinds of links wired link technologies, notably power-line networks, these kinds of links
tend to be difficult or impossible to detect automatically, and we are not tend to be difficult or impossible to detect automatically, and we are not
aware of any published link-quality algorithms for them. Hence, we do not aware of any published link-quality algorithms for them. Hence, we do not
require link-quality estimation for wired links of any kind.</t></list></t> require link-quality estimation for wired links of any kind.</t></li>
</ol>
</section> </section>
<section numbered="true" toc="default">
<section title="Optional features"> <name>Optional Features</name>
<ol type="OPT%d:" group="opt" indent="8">
<t>OPT1: a Homenet implementation of Babel MAY perform route selection by <li anchor="opt1"><t>A Homenet implementation of Babel <bcp14>MAY</bcp14
applying hysteresis to route metrics, as suggested in Section&nbsp;3.6 of > perform route selection by
RFC&nbsp;6126bis and described in detail in Section&nbsp;III.E of <xref applying hysteresis to route metrics, as suggested in
target="BABEL-RTT"/>. However, hysteresis is not required, and the <xref target="RFC8966" section="3.6" sectionFormat="of" format="default"/>
and described in detail in Section&nbsp;III.E of <xref target="DELAY-BASED" form
at="default"/>.
However, hysteresis is not required, and the
implementation may simply pick the route with the smallest metric.</t> implementation may simply pick the route with the smallest metric.</t>
<t indent="3">Rationale: Hysteresis is only useful in
<t><list style="empty"><t>Rationale: hysteresis is only useful in congested and highly dynamic networks. In a typical home network, which is stab
congested and highly dynamic networks. In a typical home network, stable le
and uncongested, the feedback loop that hysteresis compensates for does and uncongested, the feedback loop that hysteresis compensates for does
not occur.</t></list></t> not occur.</t></li>
<li anchor="opt2"><t>A Homenet implementation of Babel may include suppo
<t>OPT2: a Homenet implementation of Babel may include support for other rt for other
extensions to the protocol, as long as they are known to interoperate with extensions to the protocol, as long as they are known to interoperate with
both the core protocol and source-specific routing.</t> both the core protocol and source-specific routing.</t>
<t indent="3">Rationale: A number of extensions to the Babel
<t><list style="empty"><t>Rationale: a number of extensions to the Babel
routing protocol have been defined over the years; however, they are routing protocol have been defined over the years; however, they are
useful in fairly specific situations, such as routing over global-scale useful in fairly specific situations, such as routing over global-scale
overlay networks <xref target="BABEL-RTT"/> or multi-hop wireless networks overlay networks <xref target="I-D.ietf-babel-rtt-extension" format="default"/>
with multiple radio frequencies <xref target="BABEL-Z"/>. Hence, with the or multi-hop wireless networks
with multiple radio frequencies <xref target="I-D.chroboczek-babel-diversity-rou
ting" format="default"/>. Hence, with the
exception of source-specific routing, no extensions are required for exception of source-specific routing, no extensions are required for
Homenet.</t></list></t> Homenet.</t></li>
</ol>
</section> </section>
</section>
</section> <section numbered="true" toc="default">
<name>Interactions between HNCP and Babel</name>
<section title="Interactions between HNCP and Babel"> <t>The Homenet architecture cleanly separates configuration, which is done
<t>The Homenet architecture cleanly separates configuration, which is done
by HNCP, from routing, which is done by Babel. While the coupling between by HNCP, from routing, which is done by Babel. While the coupling between
the two protocols is deliberately kept to a minimum, some interactions are the two protocols is deliberately kept to a minimum, some interactions are
unavoidable.</t> unavoidable.</t>
<t>All the interactions between HNCP and Babel consist of HNCP causing
<t>All the interactions between HNCP and Babel consist of HNCP causing
Babel to perform an announcement on its behalf (under no circumstances Babel to perform an announcement on its behalf (under no circumstances
does Babel cause HNCP to perform an action). How this is realised is an does Babel cause HNCP to perform an action). How this is realised is an
implementation detail that is outside the scope of this document; while it implementation detail that is outside the scope of this document; while it
could conceivably be done using a private communication channel between could conceivably be done using a private communication channel between
HNCP and Babel, in existing implementations HNCP installs a route in the HNCP and Babel, in existing implementations, HNCP installs a route in the
operating system's kernel which is later picked up by Babel using the operating system's kernel that is later picked up by Babel using the
existing redistribution mechanisms.</t> existing redistribution mechanisms.</t>
<section numbered="true" toc="default">
<section title="Requirements"> <name>Requirements</name>
<ol type="REQ%d:" group="req" indent="8">
<t>REQ7: if an HNCP node receives a DHCPv6 prefix delegation for prefix <li anchor="req7"><t>If an HNCP node receives a DHCPv6 prefix delegation
for prefix
P and publishes an External-Connection TLV containing a Delegated-Prefix P and publishes an External-Connection TLV containing a Delegated-Prefix
TLV with prefix P and no Prefix-Policy TLV, then it MUST announce TLV with prefix P and no Prefix-Policy TLV, then it <bcp14>MUST</bcp14> announce
a source-specific default route with source prefix P over Babel.</t> a source-specific default route with source prefix P over Babel.</t>
<t indent="3">Rationale: Source-specific routes are the main
<t><list style="empty"><t>Rationale: source-specific routes are the main
tool that Homenet uses to enable optimal routing in the presence of tool that Homenet uses to enable optimal routing in the presence of
multiple IPv6 prefixes. External connections with non-trivial prefix multiple IPv6 prefixes. External connections with nontrivial prefix
policies are explicitly excluded from this requirement, since their exact policies are explicitly excluded from this requirement, since their exact
behaviour is application-specific.</t></list></t> behaviour is application specific.</t></li>
<li anchor="req8"><t>If an HNCP node receives a DHCPv4 lease with an IPv
<t>REQ8: if an HNCP node receives a DHCPv4 lease with an IPv4 address and 4 address and
wins the election for NAT gateway, then it MUST act as a NAT gateway and wins the election for NAT gateway, then it <bcp14>MUST</bcp14> act as a NAT gate
MUST announce a (non-specific) IPv4 default route over Babel.</t> way and
<bcp14>MUST</bcp14> announce a (nonspecific) IPv4 default route over Babel.</t>
<t><list style="empty"><t>Rationale: the Homenet stack does not use <t indent="3">Rationale: The Homenet stack does not use
source-specific routing for IPv4; instead, HNCP elects a single NAT source-specific routing for IPv4; instead, HNCP elects a single NAT
gateway and publishes a single default route towards that gateway gateway and publishes a single default route towards that gateway
(<xref target="RFC7788"/> Section 6.5).</t></list></t> (<xref target="RFC7788" section="6.5" sectionFormat="comma" format="default"/>).
</t></li>
<t>REQ9: if an HNCP node assigns a prefix P to an attached link and <li anchor="req9"><t>If an HNCP node assigns a prefix P to an attached l
announces P in an Assigned-Prefix TLV, then it MUST announce a route towards ink and
announces P in an Assigned-Prefix TLV, then it <bcp14>MUST</bcp14> announce a ro
ute towards
P over Babel.</t> P over Babel.</t>
<t indent="3">Rationale: Prefixes assigned to links must be
<t><list style="empty"><t>Rationale: prefixes assigned to links must be routable within the Homenet.</t></li>
routable within the Homenet.</t></list></t> </ol>
</section>
</section> <section numbered="true" toc="default">
<name>Optional Features</name>
<section title="Optional features"> <ol type="OPT%d:" group="opt" indent="8">
<li anchor="opt3"><t>An HNCP node that receives a DHCPv6 prefix delegati
<t>OPT3: an HNCP node that receives a DHCPv6 prefix delegation MAY on <bcp14>MAY</bcp14>
announce a non-specific IPv6 default route over Babel in addition to the announce a nonspecific IPv6 default route over Babel in addition to the
source-specific default route mandated by requirement REQ7.</t> source-specific default route mandated by requirement <xref target="req7" format
="none">REQ7</xref>.</t>
<t><list style="empty"><t>Rationale: since the source-specific default <t indent="3">Rationale: Since the source-specific default
route is more specific than the non-specific default route, the former route is more specific than the nonspecific default route, the former
will override the latter if all nodes implement source-specific routing. will override the latter if all nodes implement source-specific routing.
Announcing an additional non-specific route is allowed, since doing that Announcing an additional nonspecific route is allowed, since doing that
causes no harm and might simplify operations in some circumstances, causes no harm and might simplify operations in some circumstances,
e.g.&nbsp;when interoperating with a routing protocol that does not e.g., when interoperating with a routing protocol that does not
support source-specific routing.</t></list></t> support source-specific routing.</t></li>
<li anchor="opt4"><t>An HNCP node that receives a DHCPv4 lease with an I
<t>OPT4: an HNCP node that receives a DHCPv4 lease with an IPv4 address and Pv4 address and
wins the election for NAT gateway SHOULD NOT announce a source-specific wins the election for NAT gateway <bcp14>SHOULD NOT</bcp14> announce a source-sp
ecific
IPv4 default route.</t> IPv4 default route.</t>
<t indent="3">Rationale: Homenet does not require support for IPv4
<t><list style="empty"><t>Homenet does not require support for IPv4
source-specific routing. Announcing IPv4 source-specific routes will not source-specific routing. Announcing IPv4 source-specific routes will not
cause routing pathologies (blackholes or routing loops), but it might cause routing pathologies (blackholes or routing loops), but it might
cause packets sourced in different parts of the Homenet to follow cause packets sourced in different parts of the Homenet to follow
different paths, with all the confusion that this entails.</t></list></t> different paths, with all the confusion that this entails.</t></li>
</ol>
</section> </section>
</section>
</section> <section numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Security Considerations"> <t>Both HNCP and Babel carry their control data in IPv6 packets with
<t>Both HNCP and Babel carry their control data in IPv6 packets with
a link-local source address, and implementations are required to drop a link-local source address, and implementations are required to drop
packets sent from a global address. Hence, they are only susceptible to packets sent from a global address. Hence, they are only susceptible to
attacks from a directly connected link on which the HNCP and Babel attacks from a directly connected link on which the HNCP and Babel
implementations are listening.</t> implementations are listening.</t>
<t>The security of a Homenet network relies on having a set of "Internal",
<t>The security of a Homenet network relies on having a set of "Internal", "Ad Hoc", and "Hybrid" interfaces (<xref target="RFC7788" section="5.1" sectionF
"Ad Hoc" and "Hybrid" interfaces (Section 5.1 of <xref target="RFC7788"/>) ormat="of" format="default"/>)
that are assumed to be connected to links that are secured at a lower that are assumed to be connected to links that are secured at a lower
layer. HNCP and Babel packets are only accepted when they originate on layer. HNCP and Babel packets are only accepted when they originate on
these trusted links. "External" and "Guest" interfaces are connected to these trusted links. "External" and "Guest" interfaces are connected to
links that are not trusted, and any HNCP or Babel packets that are links that are not trusted, and any HNCP or Babel packets that are
received on such interfaces are ignored. ("Leaf" interfaces are a special received on such interfaces are ignored. ("Leaf" interfaces are a special
case, since they are connected to trusted links but HNCP and Babel traffic case since they are connected to trusted links, but HNCP and Babel traffic
received on such interfaces is ignored.) This implies that the security received on such interfaces is ignored.) This implies that the security
of a Homenet network depends on the reliability of the border discovery of a Homenet network depends on the reliability of the border discovery
procedure described in Section 5.3 of <xref target="RFC7788"/>.</t> procedure described in <xref target="RFC7788" section="5.3" sectionFormat="of" f
ormat="default"/>.</t>
<t>If untrusted links are used for transit, which is NOT RECOMMENDED, <t>If untrusted links are used for transit, which is <bcp14>NOT RECOMMENDE
then any HNCP and Babel traffic that is carried over such links MUST be D</bcp14>,
then any HNCP and Babel traffic that is carried over such links <bcp14>MUST</bcp
14> be
secured using an upper-layer security protocol. While both HNCP and Babel secured using an upper-layer security protocol. While both HNCP and Babel
support cryptographic authentication, at the time of writing no protocol support cryptographic authentication, at the time of writing, no protocol
for autonomous configuration of HNCP and Babel security has been defined.</t> for autonomous configuration of HNCP and Babel security has been defined.</t>
</section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
</section> <displayreference target="I-D.ietf-babel-rtt-extension" to="BABEL-RTT"/>
<displayreference target="I-D.chouasne-babel-tos-specific" to="ToS-SPECIFIC"/>
<section title="IANA Considerations"> <displayreference target="I-D.chroboczek-babel-diversity-routing" to="BABEL-Z"/>
<t>This document requires no actions from IANA.</t>
</section>
<section title="Acknowledgments">
<t>A number of people have helped with defining the requirements listed in
this document. I am especially indebted to Barbara Stark and Markus
Stenberg.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119"><front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"/>
<date year="1997" month="March"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174"><front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba"/>
<date year="2017" month="May"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC6126bis"><front>
<title>The Babel Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<author fullname="David Schinazi" initials="D." surname="Schinazi"/>
<date month="October" year="2017"/>
</front>
<seriesInfo name="Internet Draft" value="draft-ietf-babel-rfc6126bis-04"/>
</reference>
<reference anchor="RFC7788"><front>
<title>Home Networking Control Protocol</title>
<author initials="M." surname="Stenberg" fullname="M. Stenberg"/>
<author initials="S." surname="Barth" fullname="S. Barth"/>
<author initials="P." surname="Pfister" fullname="P. Pfister"/>
<date year="2016" month="April"/>
</front>
<seriesInfo name="RFC" value="7788"/>
<seriesInfo name="DOI" value="10.17487/RFC7788"/>
</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 day="4" month="August" year="2018"/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-babel-source-specific-03'/>
</reference>
</references>
<references title="Informative References">
<reference anchor='RFC7298'><front>
<title>Babel Hashed Message Authentication Code (HMAC) Cryptographic Authenticat
ion</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-RTT"> <references>
<front> <name>References</name>
<title>Delay-based Metric Extension for the Babel Routing Protocol</title> <references>
<author initials='B' surname='Jonglez' fullname='Baptiste Jonglez'></author> <name>Normative References</name>
<author initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'></author <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
> FC.2119.xml"/>
<date month='May' day='27' year='2015' /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.8174.xml"/>
<seriesInfo name='Internet-Draft' value='draft-jonglez-babel-rtt-extension-01' / <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
> FC.7788.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8966.xml"/>
<reference anchor="BABEL-Z"><front> <reference anchor='RFC9079'>
<title>Diversity Routing for the Babel Routing Protocol</title> <front>
<author initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'></author <title>Source-Specific Routing in the Babel Routing Protocol</title>
> <author initials='M' surname='Boutier' fullname='Matthieu Boutier'>
<date month='February' day='15' year='2016' /> <organization />
</front> </author>
<seriesInfo name='Internet-Draft' value='draft-chroboczek-babel-diversity-routin <author initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'>
g-01'/> <organization />
</author>
<date month='August' year='2021' />
</front>
<seriesInfo name="RFC" value="9079"/>
<seriesInfo name="DOI" value="10.17487/RFC9079"/>
</reference> </reference>
<reference anchor="DELAY-BASED"><front> </references>
<title>A delay-based routing metric</title> <references>
<author fullname="Baptiste Jonglez" initials="B." surname="Jonglez"/> <name>Informative References</name>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date month="March" year="2014"/>
</front>
<annotation>Available online from http://arxiv.org/abs/1403.3488</annotation>
</reference>
<reference anchor="ToS-SPECIFIC"><front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>https://tools.ietf.org/id/draft-chouasne-babel-tos-specific-00.xml</title FC.8967.xml"/>
> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<author fullname="Gwendoline Chouasne" initials="G." surname="Chouasne"/> .ietf-babel-rtt-extension.xml"/>
<date day="3" month="July" year="2017"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
</front> .chroboczek-babel-diversity-routing.xml"/>
<seriesInfo name='Internet-Draft' value='draft-chouasne-babel-tos-specific-00'/>
</reference>
</references> <reference anchor="DELAY-BASED" target="http://arxiv.org/abs/1403.3488">
<front>
<title>A delay-based routing metric</title>
<author fullname="Baptiste Jonglez" initials="B." surname="Jonglez"/
>
<author fullname="Matthieu Boutier" initials="M." surname="Boutier"/
>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboc
zek"/>
<date month="March" year="2014"/>
</front>
</reference>
</back> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.chouasne-babel-tos-specific.xml"/>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>A number of people have helped with defining the requirements listed in
this document. I am especially indebted to <contact fullname="Barbara Stark"/>
and
<contact fullname="Markus Stenberg"/>.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 57 change blocks. 
344 lines changed or deleted 313 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/