Homenet Profile of the Babel Routing Protocol
Extracted elements (21)
Babel control traffic is required over IPv6 rather than IPv4 because IPv6 provides properly scoped and reasonably stable link-local addresses, which makes implementations simpler and more reliable.
Dynamic wireless link-quality probing is required because 'hop-count routing is worst-path routing' in wireless networks: without quality metrics, the routing protocol minimizes hop count and prefers long lossy links over shorter reliable ones.
Hysteresis in route selection (OPT1) is optional rather than required because it is only useful in congested and highly dynamic networks; a typical home network is stable and uncongested, so the feedback loop hysteresis compensates for does not occur.
IPv4 source-specific routing is not required because HNCP elects a single NAT gateway and publishes a single nonspecific IPv4 default route (RFC 7788, Section 6.5), making per-source IPv4 routing architecturally unnecessary for Homenet.
Source-specific routing for IPv6 is a mandatory part of the Homenet profile because it is an essential component of the Homenet architecture, enabling optimal routing in the presence of multiple IPv6 prefixes from multiple upstream ISPs.
An HNCP node MAY announce a nonspecific IPv6 default route in addition to the source-specific default route required by REQ7. The source-specific route takes precedence on nodes that support it, and the nonspecific route may simplify interoperation with routing protocols that do not support source-specific routing.
Distinct Babel implementations maintain loop-free forwarding paths, but if they implement conflicting options they may not exchange a full set of routes. In the worst case, an IPv6-only and an IPv4-only implementation will exchange no routes at all.
A Homenet implementation of Babel MUST encapsulate Babel control traffic in IPv6 packets sent to IANA-assigned port 6696 and either the multicast group ff02::1:6 or a link-local unicast address.
A Homenet implementation of Babel MUST implement source-specific routing for IPv6 as defined in RFC 9079. Source-specific routing for IPv4 is not required.
A Homenet implementation of Babel MUST implement the IPv6 subset of the Babel protocol defined in RFC 8966. IPv6 routing support is an essential component of the Homenet architecture.
A Homenet implementation of Babel SHOULD assign link costs no less than 256 to wireless links and between 32 and 196 to lossless wired links, using magnitudes similar to those suggested in Appendix A of RFC 8966.
A Homenet implementation of Babel SHOULD distinguish between wired and wireless links (defaulting to the worst-case wireless assumption if uncertain), SHOULD dynamically probe wireless link quality, and SHOULD derive a suitable metric from quality estimation.
A Homenet implementation of Babel SHOULD implement the IPv4 subset of the protocol defined in RFC 8966. Use of multiple layers of NAT as an alternative is strongly discouraged.
An HNCP node that wins the NAT gateway election SHOULD NOT announce a source-specific IPv4 default route; Homenet does not require IPv4 source-specific routing, and doing so may cause packets from different parts of the network to follow different paths.
If an HNCP node assigns a prefix P to an attached link and announces P in an Assigned-Prefix TLV, it MUST announce a route towards P over Babel to ensure the prefix is routable within the Homenet.
If an HNCP node receives a DHCPv4 lease with an IPv4 address and wins the election for NAT gateway, it MUST act as a NAT gateway and MUST announce a nonspecific IPv4 default route over Babel.
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, it MUST announce a source-specific default route with source prefix P over Babel.
If untrusted links are used for transit (NOT RECOMMENDED), any HNCP and Babel traffic carried over such links MUST be secured using an upper-layer security protocol.
All HNCP-Babel interactions are unidirectional: HNCP causes Babel to perform route announcements on its behalf; Babel never causes HNCP to act. In existing implementations, HNCP installs routes in the OS kernel that Babel picks up via standard redistribution mechanisms.
Both HNCP and Babel carry control data in IPv6 packets with link-local source addresses; implementations must drop packets sent from global addresses, confining the attack surface to directly connected links on which the protocols are listening.
Homenet security depends on interface classification: Internal, Ad Hoc, and Hybrid interfaces are trusted and accept HNCP/Babel traffic; External and Guest interfaces are untrusted and HNCP/Babel packets received on them are ignored. Overall security therefore depends on the reliability of the border discovery procedure in RFC 7788 Section 5.3.