summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9080.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9080.txt')
-rw-r--r--doc/rfc/rfc9080.txt417
1 files changed, 417 insertions, 0 deletions
diff --git a/doc/rfc/rfc9080.txt b/doc/rfc/rfc9080.txt
new file mode 100644
index 0000000..ea2f1ab
--- /dev/null
+++ b/doc/rfc/rfc9080.txt
@@ -0,0 +1,417 @@
+
+
+
+
+Internet Engineering Task Force (IETF) J. Chroboczek
+Request for Comments: 9080 IRIF, University of Paris-Diderot
+Category: Standards Track August 2021
+ISSN: 2070-1721
+
+
+ Homenet Profile of the Babel Routing Protocol
+
+Abstract
+
+ 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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc9080.
+
+Copyright Notice
+
+ Copyright (c) 2021 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
+ (https://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. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction
+ 1.1. Requirements Language
+ 1.2. Background
+ 2. The Homenet Profile of Babel
+ 2.1. Requirements
+ 2.2. Optional Features
+ 3. Interactions between HNCP and Babel
+ 3.1. Requirements
+ 3.2. Optional Features
+ 4. Security Considerations
+ 5. IANA Considerations
+ 6. References
+ 6.1. Normative References
+ 6.2. Informative References
+ Acknowledgments
+ Author's Address
+
+1. Introduction
+
+ The core of the Homenet protocol suite consists of the Home
+ Networking Control Protocol (HNCP) [RFC7788], a protocol used for
+ flooding configuration information and assigning prefixes to links,
+ combined with the Babel routing protocol [RFC8966]. Babel is an
+ extensible, flexible, and modular protocol: minimal implementations
+ of Babel have been demonstrated that consist of a few hundred lines
+ of code, while the "large" implementation includes support for a
+ number of extensions and consists of over ten thousand lines of C
+ code.
+
+ This document consists of two parts. The first specifies the exact
+ subset of the Babel protocol and its extensions that is required by
+ an implementation of the Homenet protocol suite. The second
+ specifies how HNCP interacts with Babel.
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+1.2. Background
+
+ The Babel routing protocol and its extensions are defined in a number
+ of documents:
+
+ * RFC 8966 [RFC8966] defines the Babel routing 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 IPv4 and IPv6
+ routes. It leaves link cost estimation, metric computation, and
+ route selection to the implementation. Distinct implementations
+ of Babel [RFC8966] will interoperate, in the sense that they will
+ 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 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 will not exchange any routes. In addition, if
+ implementations use conflicting route selection policies,
+ persistent oscillations might occur.
+
+ * The informative Appendix A of [RFC8966] suggests a simple and
+ easy-to-implement algorithm for cost and metric computation that
+ has been found to work satisfactorily in a wide range of
+ topologies.
+
+ * While RFC 8966 does not provide an algorithm for route selection,
+ its Section 3.6 suggests selecting the route with the smallest
+ metric with some hysteresis applied. An algorithm that has been
+ found to work well in practice is described in Section III.E of
+ [DELAY-BASED].
+
+ * Four documents define optional extensions to Babel: authentication
+ based on Hashed Message Authentication Code (HMAC) [RFC8967],
+ source-specific routing [RFC9079], delay-based routing
+ [BABEL-RTT], and ToS-specific (Type of Service) routing
+ [ToS-SPECIFIC]. All of these extensions interoperate with the
+ core protocol as well as with each other.
+
+2. The Homenet Profile of Babel
+
+2.1. Requirements
+
+ REQ1: A Homenet implementation of Babel MUST encapsulate Babel
+ control 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 address.
+
+ Rationale: Since Babel is able to carry both 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 some features that make
+ implementations somewhat simpler and more reliable
+ (notably properly scoped and reasonably stable link-local
+ addresses), we require carrying control data over IPv6.
+
+ REQ2: A Homenet implementation of Babel MUST implement the IPv6
+ subset of the protocol defined in the body of RFC 8966.
+
+ Rationale: Support for IPv6 routing is an essential
+ component of the Homenet architecture.
+
+ REQ3: A Homenet implementation of Babel SHOULD implement the IPv4
+ subset of the protocol defined in the body of RFC 8966. Use
+ of other techniques for acquiring IPv4 connectivity (such as
+ multiple layers of NAT) is strongly discouraged.
+
+ Rationale: Support for IPv4 will likely remain 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 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 problems.
+
+ REQ4: A Homenet implementation of Babel MUST implement source-
+ specific routing for IPv6, as defined in RFC 9079 [RFC9079].
+
+ Rationale: Source-specific routing is an essential
+ component of the Homenet architecture. Source-specific
+ routing for IPv4 is not required, since HNCP arranges
+ things so that a single nonspecific IPv4 default route is
+ announced (Section 6.5 of [RFC7788]).
+
+ REQ5: A Homenet implementation of Babel must use metrics that are
+ of a similar magnitude to the values suggested in Appendix A
+ of [RFC8966]. In particular, it SHOULD assign costs that are
+ no less than 256 to wireless links and SHOULD assign costs
+ between 32 and 196 to lossless wired links.
+
+ Rationale: If two implementations of Babel choose very
+ different values for link costs, combining routers from
+ different vendors will cause suboptimal routing.
+
+ REQ6: A Homenet implementation of Babel SHOULD distinguish between
+ 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 is wireless. It SHOULD
+ dynamically probe the quality of wireless links and derive a
+ suitable metric from its quality estimation. Appendix A of
+ [RFC8966] gives an example of a suitable algorithm.
+
+ Rationale: Support for wireless transit links is a
+ distinguishing feature of Homenet, and one that is
+ requested by our users. In the absence of dynamically
+ computed metrics, the routing protocol attempts to
+ minimise the number of links crossed by a route and
+ therefore prefers long, lossy links to shorter, lossless
+ ones. In wireless networks, "hop-count routing is worst-
+ path routing".
+
+ While it would be desirable to perform link-quality
+ probing on some wired link technologies, notably power-
+ line networks, these kinds of links 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 require link-quality estimation for wired
+ links of any kind.
+
+2.2. Optional Features
+
+ OPT1: A Homenet implementation of Babel MAY perform route selection
+ by applying hysteresis to route metrics, as suggested in
+ Section 3.6 of [RFC8966] and described in detail in
+ Section III.E of [DELAY-BASED]. However, hysteresis is not
+ required, and the implementation may simply pick the route
+ with the smallest metric.
+
+ Rationale: Hysteresis is only useful in congested and
+ highly dynamic networks. In a typical home network, which
+ is stable and uncongested, the feedback loop that
+ hysteresis compensates for does not occur.
+
+ OPT2: A Homenet implementation of Babel may include support for
+ other extensions to the protocol, as long as they are known
+ to interoperate with both the core protocol and source-
+ specific routing.
+
+ Rationale: A number of extensions to the Babel routing
+ protocol have been defined over the years; however, they
+ are useful in fairly specific situations, such as routing
+ over global-scale overlay networks [BABEL-RTT] or multi-
+ hop wireless networks with multiple radio frequencies
+ [BABEL-Z]. Hence, with the exception of source-specific
+ routing, no extensions are required for Homenet.
+
+3. Interactions between HNCP and Babel
+
+ The Homenet architecture cleanly separates configuration, which is
+ done 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 unavoidable.
+
+ All the interactions between HNCP and Babel consist of HNCP causing
+ 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 implementation detail that is outside the scope of
+ this document; while it could conceivably be done using a private
+ communication channel between HNCP and Babel, in existing
+ implementations, HNCP installs a route in the operating system's
+ kernel that is later picked up by Babel using the existing
+ redistribution mechanisms.
+
+3.1. Requirements
+
+ REQ7: If an HNCP node receives a DHCPv6 prefix delegation for
+ 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 a source-specific default route
+ with source prefix P over Babel.
+
+ Rationale: Source-specific routes are the main tool that
+ Homenet uses to enable optimal routing in the presence of
+ multiple IPv6 prefixes. External connections with
+ nontrivial prefix policies are explicitly excluded from
+ this requirement, since their exact behaviour is
+ application specific.
+
+ REQ8: If an HNCP node receives a DHCPv4 lease with an IPv4 address
+ and wins the election for NAT gateway, then it MUST act as a
+ NAT gateway and MUST announce a (nonspecific) IPv4 default
+ route over Babel.
+
+ Rationale: The Homenet stack does not use source-specific
+ routing for IPv4; instead, HNCP elects a single NAT
+ gateway and publishes a single default route towards that
+ gateway ([RFC7788], Section 6.5).
+
+ REQ9: If an HNCP node assigns a prefix P to an attached link and
+ announces P in an Assigned-Prefix TLV, then it MUST announce
+ a route towards P over Babel.
+
+ Rationale: Prefixes assigned to links must be routable
+ within the Homenet.
+
+3.2. Optional Features
+
+ OPT3: An HNCP node that receives a DHCPv6 prefix delegation MAY
+ announce a nonspecific IPv6 default route over Babel in
+ addition to the source-specific default route mandated by
+ requirement REQ7.
+
+ Rationale: Since the source-specific default route is more
+ specific than the nonspecific default route, the former
+ will override the latter if all nodes implement source-
+ specific routing. Announcing an additional nonspecific
+ route is allowed, since doing that causes no harm and
+ might simplify operations in some circumstances, e.g.,
+ when interoperating with a routing protocol that does not
+ support source-specific routing.
+
+ OPT4: An HNCP node that receives a DHCPv4 lease with an IPv4
+ address and wins the election for NAT gateway SHOULD NOT
+ announce a source-specific IPv4 default route.
+
+ Rationale: Homenet does not require support for IPv4
+ source-specific routing. Announcing IPv4 source-specific
+ routes will not cause routing pathologies (blackholes or
+ routing loops), but it might cause packets sourced in
+ different parts of the Homenet to follow different paths,
+ with all the confusion that this entails.
+
+4. Security Considerations
+
+ Both HNCP and Babel carry their control data in IPv6 packets with a
+ link-local source address, and implementations are required to drop
+ packets sent from a global address. Hence, they are only susceptible
+ to attacks from a directly connected link on which the HNCP and Babel
+ implementations are listening.
+
+ The security of a Homenet network relies on having a set of
+ "Internal", "Ad Hoc", and "Hybrid" interfaces (Section 5.1 of
+ [RFC7788]) 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 these trusted links. "External" and "Guest" interfaces
+ are connected to links that are not trusted, and any HNCP or Babel
+ packets that are received on such interfaces are ignored. ("Leaf"
+ interfaces are a special case since they are connected to trusted
+ links, but HNCP and Babel traffic received on such interfaces is
+ ignored.) This implies that the security of a Homenet network
+ depends on the reliability of the border discovery procedure
+ described in Section 5.3 of [RFC7788].
+
+ If untrusted links are used for transit, which is NOT RECOMMENDED,
+ then any HNCP and Babel traffic that is carried over such links MUST
+ be secured using an upper-layer security protocol. While both HNCP
+ and Babel support cryptographic authentication, at the time of
+ writing, no protocol for autonomous configuration of HNCP and Babel
+ security has been defined.
+
+5. IANA Considerations
+
+ This document has no IANA actions.
+
+6. References
+
+6.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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
+ Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
+ 2016, <https://www.rfc-editor.org/info/rfc7788>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing
+ Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021,
+ <https://www.rfc-editor.org/info/rfc8966>.
+
+ [RFC9079] Boutier, M. and J. Chroboczek, "Source-Specific Routing in
+ the Babel Routing Protocol", RFC 9079,
+ DOI 10.17487/RFC9079, August 2021,
+ <https://www.rfc-editor.org/rfc/rfc9079>.
+
+6.2. Informative References
+
+ [BABEL-RTT]
+ Jonglez, B. and J. Chroboczek, "Delay-based Metric
+ Extension for the Babel Routing Protocol", Work in
+ Progress, Internet-Draft, draft-ietf-babel-rtt-extension-
+ 00, 26 April 2019, <https://datatracker.ietf.org/doc/html/
+ draft-ietf-babel-rtt-extension-00>.
+
+ [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing
+ Protocol", Work in Progress, Internet-Draft, draft-
+ chroboczek-babel-diversity-routing-01, 15 February 2016,
+ <https://datatracker.ietf.org/doc/html/draft-chroboczek-
+ babel-diversity-routing-01>.
+
+ [DELAY-BASED]
+ Jonglez, B., Boutier, M., and J. Chroboczek, "A delay-
+ based routing metric", March 2014,
+ <http://arxiv.org/abs/1403.3488>.
+
+ [RFC8967] Dô, C., Kolodziejak, W., and J. Chroboczek, "MAC
+ Authentication for the Babel Routing Protocol", RFC 8967,
+ DOI 10.17487/RFC8967, January 2021,
+ <https://www.rfc-editor.org/info/rfc8967>.
+
+ [ToS-SPECIFIC]
+ Chouasne, G. and J. Chroboczek, "TOS-Specific Routing in
+ Babel", Work in Progress, Internet-Draft, draft-chouasne-
+ babel-tos-specific-00, 3 July 2017,
+ <https://datatracker.ietf.org/doc/html/draft-chouasne-
+ babel-tos-specific-00>.
+
+Acknowledgments
+
+ A number of people have helped with defining the requirements listed
+ in this document. I am especially indebted to Barbara Stark and
+ Markus Stenberg.
+
+Author's Address
+
+ Juliusz Chroboczek
+ IRIF, University of Paris-Diderot
+ Case 7014
+ 75205 Paris CEDEX 13
+ France
+
+ Email: jch@irif.fr