Small/Home Office Network IPv6 wish list
|
by Craig Miller
The CPE (Customer Premise Equipment) or home router is beginning to see support for IPv6, but it is far from complete. In the past, I have written about OpenWrt, an open source software for home routers. The IPv6 features of OpenWrt will be the basis of my IPv6 wish list for every home router.
Small Office/Home Office (SOHO) networks tend to grow organically. Starting with a single ISP connected router, adding additional routers as ports fill up, or technology requirements expand. Additionally, technologies such as IPv6-only, Wireguard IPv6-enabled VPN, and separation of networks (i.e. DMZ/VLAN) for IoT devices must be accommodated.
Expanded SOHO Network
The IETF Standards
Fortunately, there has been some good work done by the IETF (Internet Engineering Task Force) to define minimum feature support of CPEs. Notably, Basic Requirements for IPv6 Customer Edge Routers RFC 7084. Transitional technologies offering IPv4 over IPv6 with MAP-T RFC 7597 and MAP-E RFC 7599. And the most recently minted Operational Security Considerations for IPv6 Networks RFC 9099
RFC 7084 Basic Requirements for IPv6 Customer Edge Routers
Rather than summarize this RFC, I have included the requirements section (4). This RFC is a basic set of requirements for CPE/Home routers supporting IPv6, including:
G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node
Requirements specification [RFC6434].
G-2: The IPv6 CE router MUST implement ICMPv6 according to
[RFC4443]. In particular, point-to-point links MUST be handled
as described in Section 3.1 of [RFC4443].
G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between
its LAN interface(s) and its WAN interface until the router has
successfully completed the IPv6 address and the delegated
prefix acquisition process.
G-4: By default, an IPv6 CE router that has no default router(s) on
its WAN interface MUST NOT advertise itself as an IPv6 default
router on its LAN interfaces. That is, the "Router Lifetime"
field is set to zero in all Router Advertisement messages it
originates [RFC4861].
G-5: By default, if the IPv6 CE router is an advertising router and
loses its IPv6 default router(s) and/or detects loss of
connectivity on the WAN interface, it MUST explicitly
invalidate itself as an IPv6 default router on each of its
advertising interfaces by immediately transmitting one or more
Router Advertisement messages with the "Router Lifetime" field
set to zero [RFC4861].
W-1: When the router is attached to the WAN interface link, it MUST
act as an IPv6 host for the purposes of stateless [RFC4862] or
stateful [RFC3315] interface address assignment.
W-2: The IPv6 CE router MUST generate a link-local address and
finish Duplicate Address Detection according to [RFC4862] prior
to sending any Router Solicitations on the interface. The
source address used in the subsequent Router Solicitation MUST
be the link-local address on the WAN interface.
W-3: Absent other routing information, the IPv6 CE router MUST use
Router Discovery as specified in [RFC4861] to discover a
default router(s) and install a default route(s) in its routing
table with the discovered router's address as the next hop.
W-4: The router MUST act as a requesting router for the purposes of
DHCPv6 prefix delegation ([RFC3633]).
W-5: The IPv6 CE router MUST use a persistent DHCP Unique Identifier
(DUID) for DHCPv6 messages. The DUID MUST NOT change between
network-interface resets or IPv6 CE router reboots.
W-6: The WAN interface of the CE router SHOULD support a Port
Control Protocol (PCP) client as specified in [RFC6887] for use
by applications on the CE router. The PCP client SHOULD follow
the procedure specified in Section 8.1 of [RFC6887] to discover
its PCP server. This document takes no position on whether
such functionality is enabled by default or mechanisms by which
users would configure the functionality. Handling PCP requests
from PCP clients in the LAN side of the CE router is out of
scope.
Link-layer requirements:
WLL-1: If the WAN interface supports Ethernet encapsulation, then
the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464].
WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE
router MUST support IPv6 over PPP [RFC5072].
WLL-3: If the WAN interface supports PPP encapsulation, in a dual-
stack environment with IPCP and IPV6CP running over one PPP
logical channel, the Network Control Protocols (NCPs) MUST be
treated as independent of each other and start and terminate
independently.
Address assignment requirements:
WAA-1: The IPv6 CE router MUST support Stateless Address
Autoconfiguration (SLAAC) [RFC4862].
WAA-2: The IPv6 CE router MUST follow the recommendations in
Section 4 of [RFC5942], and in particular the handling of
the L flag in the Router Advertisement Prefix Information
option.
WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client
behavior.
WAA-4: The IPv6 CE router MUST be able to support the following
DHCPv6 options: Identity Association for Non-temporary
Address (IA_NA), Reconfigure Accept [RFC3315], and
DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to
support the DNS Search List (DNSSL) option as specified in
[RFC3646].
WAA-5: The IPv6 CE router SHOULD implement the Network Time
Protocol (NTP) as specified in [RFC5905] to provide a time
reference common to the service provider for other
protocols, such as DHCPv6, to use. If the CE router
implements NTP, it requests the NTP Server DHCPv6 option
[RFC5908] and uses the received list of servers as primary
time reference, unless explicitly configured otherwise. LAN
side support of NTP is out of scope for this document.
WAA-6: If the IPv6 CE router receives a Router Advertisement
message (described in [RFC4861]) with the M flag set to 1,
the IPv6 CE router MUST do DHCPv6 address assignment
(request an IA_NA option).
WAA-7: If the IPv6 CE router does not acquire a global IPv6
address(es) from either SLAAC or DHCPv6, then it MUST create
a global IPv6 address(es) from its delegated prefix(es) and
configure those on one of its internal virtual network
interfaces, unless configured to require a global IPv6
address on the WAN interface.
WAA-8: The CE router MUST support the SOL_MAX_RT option [RFC7083]
and request the SOL_MAX_RT option in an Option Request
Option (ORO).
WAA-9: As a router, the IPv6 CE router MUST follow the weak host
(Weak End System) model [RFC1122]. When originating packets
from an interface, it will use a source address from another
one of its interfaces if the outgoing interface does not
have an address of suitable scope.
WAA-10: The IPv6 CE router SHOULD implement the Information Refresh
Time option and associated client behavior as specified in
[RFC4242].
Prefix delegation requirements:
WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation
requesting router behavior as specified in [RFC3633]
(Identity Association for Prefix Delegation (IA_PD) option).
WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating
router the size of the prefix it requires. If so, it MUST
ask for a prefix large enough to assign one /64 for each of
its interfaces, rounded up to the nearest nibble, and SHOULD
be configurable to ask for more.
WPD-3: The IPv6 CE router MUST be prepared to accept a delegated
prefix size different from what is given in the hint. If the
delegated prefix is too small to address all of its
interfaces, the IPv6 CE router SHOULD log a system management
error. [RFC6177] covers the recommendations for service
providers for prefix allocation sizes.
WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix
delegation when either the M or O flags are set to 1 in a
received Router Advertisement (RA) message. Behavior of the
CE router to use DHCPv6 prefix delegation when the CE router
has not received any RA or received an RA with the M and the
O bits set to zero is out of scope for this document.
WPD-5: Any packet received by the CE router with a destination
address in the prefix(es) delegated to the CE router but not
in the set of prefixes assigned by the CE router to the LAN
must be dropped. In other words, the next hop for the
prefix(es) delegated to the CE router should be the null
destination. This is necessary to prevent forwarding loops
when some addresses covered by the aggregate are not
reachable [RFC4632].
ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA
prefix [RFC4193].
ULA-2: An IPv6 CE router with a ULA prefix MUST maintain this prefix
consistently across reboots.
ULA-3: The value of the ULA prefix SHOULD be configurable.
ULA-4: By default, the IPv6 CE router MUST act as a site border
router according to Section 4.3 of [RFC4193] and filter
packets with local IPv6 source or destination addresses
accordingly.
ULA-5: An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime greater than zero whenever all
of its configured and delegated prefixes are ULA prefixes.
LAN requirements:
L-1: The IPv6 CE router MUST support router behavior according to
Neighbor Discovery for IPv6 [RFC4861].
L-2: The IPv6 CE router MUST assign a separate /64 from its
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) for each of its LAN interfaces.
L-3: An IPv6 CE router MUST advertise itself as a router for the
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) using the "Route Information Option" specified
in Section 2.3 of [RFC4191]. This advertisement is
independent of having or not having IPv6 connectivity on the
WAN interface.
L-4: An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime [RFC4861] greater than zero if
it has no prefixes configured or delegated to it.
L-5: The IPv6 CE router MUST make each LAN interface an advertising
interface according to [RFC4861].
L-6: In Router Advertisement messages ([RFC4861]), the Prefix
Information option's A and L flags MUST be set to 1 by
default.
L-7: The A and L flags' ([RFC4861]) settings SHOULD be user
configurable.
L-8: The IPv6 CE router MUST support a DHCPv6 server capable of
IPv6 address assignment according to [RFC3315] OR a stateless
DHCPv6 server according to [RFC3736] on its LAN interfaces.
L-9: Unless the IPv6 CE router is configured to support the DHCPv6
IA_NA option, it SHOULD set the M flag to zero and the O flag
to 1 in its Router Advertisement messages [RFC4861].
L-10: The IPv6 CE router MUST support providing DNS information in
the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646].
L-11: The IPv6 CE router MUST support providing DNS information in
the Router Advertisement Recursive DNS Server (RDNSS) and DNS
Search List options. Both options are specified in [RFC6106].
L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6
options (as listed in Section 5.3 of [RFC3736]) received from
the DHCPv6 client on its WAN interface to its LAN-side DHCPv6
server.
L-13: If the delegated prefix changes, i.e., the current prefix is
replaced with a new prefix without any overlapping time
period, then the IPv6 CE router MUST immediately advertise the
old prefix with a Preferred Lifetime of zero and a Valid
Lifetime of either a) zero or b) the lower of the current
Valid Lifetime and two hours (which must be decremented in
real time) in a Router Advertisement message as described in
Section 5.5.3, (e) of [RFC4862].
L-14: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable
message, code 5 (Source address failed ingress/egress policy)
for packets forwarded to it that use an address from a prefix
that has been invalidated.
- Transition Technology Support specifically 6rd & DS-Lite
6rd requirements:
6RD-1: The IPv6 CE router MUST support 6rd configuration via the 6rd
DHCPv4 Option 212. If the CE router has obtained an IPv4
network address through some other means such as PPP, it
SHOULD use the DHCPINFORM request message [RFC2131] to
request the 6rd DHCPv4 Option. The IPv6 CE router MAY use
other mechanisms to configure 6rd parameters. Such
mechanisms are outside the scope of this document.
6RD-2: If the IPv6 CE router is capable of automated configuration
of IPv4 through IPCP (i.e., over a PPP connection), it MUST
support user-entered configuration of 6rd.
6RD-3: If the CE router supports configuration mechanisms other than
the 6rd DHCPv4 Option 212 (user-entered, TR-069 [TR-069],
etc.), the CE router MUST support 6rd in "hub and spoke"
mode. 6rd in "hub and spoke" requires all IPv6 traffic to go
to the 6rd Border Relay. In effect, this requirement removes
the "direct connect to 6rd" route defined in Section 7.1.1 of
[RFC5969].
6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to
be active alone as well as simultaneously in order to support
coexistence of the two technologies during an incremental
migration period such as a migration from 6rd to native IPv6.
6RD-5: Each packet sent on a 6rd or native WAN interface MUST be
directed such that its source IP address is derived from the
delegated prefix associated with the particular interface
from which the packet is being sent (Section 4.3 of
[RFC3704]).
6RD-6: The CE router MUST allow different as well as identical
delegated prefixes to be configured via each (6rd or native)
WAN interface.
6RD-7: In the event that forwarding rules produce a tie between 6rd
and native IPv6, by default, the IPv6 CE router MUST prefer
native IPv6.
DS-Lite WAN requirements:
DLW-1: The CE router MUST support configuration of DS-Lite via the
DS-Lite DHCPv6 option [RFC6334]. The IPv6 CE router MAY use
other mechanisms to configure DS-Lite parameters. Such
mechanisms are outside the scope of this document.
DLW-2: The IPv6 CE router MUST NOT perform IPv4 Network Address
Translation (NAT) on IPv4 traffic encapsulated using DS-Lite.
DLW-3: If the IPv6 CE router is configured with an IPv4 address on
its WAN interface, then the IPv6 CE router SHOULD disable the
DS-Lite Basic Bridging BroadBand (B4) element.
- Security requirements for Firewalls.
S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular,
the IPv6 CE router SHOULD support functionality sufficient for
implementing the set of recommendations in [RFC6092],
Section 4. This document takes no position on whether such
functionality is enabled by default or mechanisms by which
users would configure it.
S-2: The IPv6 CE router SHOULD support ingress filtering in
accordance with BCP 38 [RFC2827]. Note that this requirement
was downgraded from a MUST from RFC 6204 due to the difficulty
of implementation in the CE router and the feature's redundancy
with upstream router ingress filtering.
S-3: If the IPv6 CE router firewall is configured to filter incoming
tunneled data, the firewall SHOULD provide the capability to
filter decapsulated packets from a tunnel.
RFC 7597 & RFC 7599 Transitional Technologies of IPv4 over IPv6 using MAP-T & MAP-E, respectfully
Mapping of Address and Port (MAP) is a standards-based approach MAP-ing by encapsulation (MAP-E) or by translation of the IPv4 address into an IPv6 address (MAP-T). Fortunately the most current release of OpenWrt (21.02.1) supports MAP-T & MAP-E.
RFC 9099 Operational Security Considerations for IPv6 Networks, Sect 3.8 General Device Hardening
With almost all devices being IPv6 enabled by default and with many endpoints having IPv6 connectivity to the Internet, it is critical to also harden those devices against attacks over IPv6.
The same techniques used to protect devices against attacks over IPv4 should be used for IPv6 and should include but are not limited to:
- restricting device access to authorized individuals;
- monitoring and auditing access to the device;
- turning off any unused services on the end node
- understanding which IPv6 addresses are being used to source traffic * and changing defaults if necessary;
- using cryptographically protected protocols for device management (Secure Copy Protocol (SCP), SNMPv3, SSH, TLS, etc.);
- using host firewall capabilities to control traffic that gets processed by upper-layer protocols;
- applying firmware, OS, and application patches/upgrades to the devices in a timely manner;
- using multifactor credentials to authenticate to devices; and
- using virus scanners to detect malicious programs.
Additional IPv6 Features
Additionally to the excellent RFC's, I'd like to see the following also supported.
- Support a simple routing protocol such as RIPng (RFC 2080) or Babel (RFC 8966) support. The venerable RIPng does not require routing protocol knowledge from the User. Just turn it on it works silently in the background with reasonable convergence times.
- Downstream DHCPv6-PD support. Not only should the SOHO router make requests on the WAN port, and advertise the delegated prefix to the LAN clients, but it should also answer DHCPv6-PD requests from the LAN-side, further delegating prefix address space.
- Downstream SLAAC support. There are some OSs which do not implement DHCPv6, most notably Android devices, including Android-based-IoT. All of these devices will be able to communicate via SLAAC & IPv6 however.
- DNS Auto Naming Support for both SLAAC & DHCPv6 Nodes on the SOHO Network. As IPv6 is more readily used, the age of memorizing IP addresses is coming to an end. DNS will be how SOHO users access devices on the network. A DNS auto naming system will map local node IPv6 addresses to names. An excellent example of mapping SLAAC IPv6 addresses to names is the ip6neigh project for OpenWrt. Additionally support for mDNS Proxy, such as Avahi relay, is required for multiple subnets in the SOHO network.
- Sane default Firewall Rules. NDP (Neighbour Discovery Protocol) requires ICMPv6 to enter the SOHO router from all interfaces (WAN and LAN). The default Firewall Rules should permit passing of ICMPv6 messages, and optionally rate limit them. OpenWrt provides an excellent example of this.
- Wireless Mesh Support. the SOHO router should be able to enable 802.11s, including Hybrid Wireless Mesh Protocol (HWMP), an IEEEE standard for wireless mesh. In addition to 802.11s the SOHO router may support other implementations of Wireless Mesh.
- Wi-fi Calling. Although there are no specific router requirements to support Wi-fi Calling, the SOHO router should include default firewall rules to permit it.
Summary
The SOHO router must be able to act as a stand alone gateway to the IPv6 Internet, or in concert with other IPv6-enabled routers. It must be ready to support IPv6-only, including IPv6-only management of the device, and a transition technology (such as NAT64). Lastly, the SOHO router must be ready to grow as the SOHO network itself becomes a complex network, with the concept that the person deploying the SOHO network is not a networking expert. Features such as auto-addressing, and auto name service (DNS) are key to the "deploy and go" mindset.
30 March 2021
Updated 2 September 2021
Updated 9 November 2021 - added MAP
Update 7 December 2021 - removed HomeNet
Updated 20 December 2021 - added mDNS Proxy