openwrt
Support a list of clients (IPv6 addresses) to advertise to
By default, the RA message will be sent using multicast so that every node on the link can use them
there is some security condition that I only want some of the devices to receive the RA message, and only these devices can have IPv6 address
The radvd and other production routers support this feature
- RADVD: If done, radvd does not send messages to the multicast addresses but to the configured unicast addresses only. Solicitations from other addresses are refused. This is similar to UnicastOnly but includes periodic messages and incoming client access configuration
- juniper: https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/solicit-router-advertisement-unicast.html
can we have this feature too?
Firewall.
Block solicitations from clients (add client ips to it)
config rule
option src 'lan'
option name 'block_recv'
option family 'ipv6'
list proto 'icmp'
list dest_ip 'ff02::1'
list dest_ip 'ff02::2'
option target 'DROP'
list icmp_type 'multicast-router-solicitation'
list icmp_type 'router-solicitation'
Block RA from odhcpd to multicast addr
config rule
option dest 'lan'
option name 'block_send'
option family 'ipv6'
list proto 'icmp'
list src_ip 'fe80::xxxx:xxff:fexx:xxxx' # routers fe80 ipv6 link addr.
list dest_ip 'ff02::1'
option target 'DROP'
list icmp_type 'multicast-router-advertisement'
list icmp_type 'router-advertisement'
odhcpd still unicast replies to router solicitations from non-blocked addresses.
but the RA message still broadcast through multicast？ I will try if this works，thank for the tips
It basically works. The issue is that it blocks the transmission of Router Advertisements (RA), preventing devices from immediately detecting that the network can provide IPv6 services. If immediate triggering is needed, the simplest operation is to disconnect and reconnect to the network. I think it would be better if there were a unicast option, similar to RADVD & juniper
You have just observed the effect of unicast by virtue of blocking multicast. When devices connect to the (IPv6) network, they multicast an RA solicit.
You have just observed the effect of unicast by virtue of blocking multicast. When devices connect to the (IPv6) network, they multicast an RA solicit.
yes it is，and without RA multicast send by the router periodicity，the default router / PIO will expire after their liefetime end
with RA send by the router periodicity with unicast，all allowed clients gets the default router / PIO renewed properly，which is the purpose of this issue
I can see the value of unicast replies (RFC7772, battery-saving, the kind of thing that Cisco and Juniper support), and we should probably add support for that at some point (and I guess an ideal implementation would do things like consider whether a multicast RA is imminent, etc).
I am not convinced by the security argument though... So I'm not convinced ATM that we should add further complications in the form of client lists...
I can see the value of unicast replies (RFC7772, battery-saving, the kind of thing that Cisco and Juniper support), and we should probably add support for that at some point (and I guess an ideal implementation would do things like consider whether a multicast RA is imminent, etc).
I am not convinced by the security argument though... So I'm not convinced ATM that we should add further complications in the form of client lists...
@Alphix
The security concerns in a home network are not as complex as those in enterprise environments. Sometimes, the goal is simply to prevent certain clients from obtaining PIO Methods like packet sniffing or monitoring are not under consideration here. The focus is solely on intercepting unintended configuration behaviors that occur when unauthorized clients receive RA multicast messages. Currently, odhcpd already supports unicast replies to client Router Solicitation messages—this is existing behavior. The approach mentioned by @systemcrash essentially works by filtering out multicast RAs while preserving unicast responses.
Additionally, this is merely a suggestion and not a demand that "since radvd has it, we should too." It is simply an exploration of possibilities based on certain real-world use cases.
Thank you for your time and reply.
The security concerns in a home network are not as complex as those in enterprise environments. Sometimes, the goal is simply to prevent certain clients from obtaining PIO Methods like packet sniffing or monitoring are not under consideration here. The focus is solely on intercepting unintended configuration behaviors that occur when unauthorized clients receive RA multicast messages.
Yeah, I was merely reacting to your initial message which mentioned "security".
Currently, odhcpd already supports unicast replies to client Router Solicitation messages—this is existing behavior.
Ah, good, I didn't even check.
The approach mentioned by @systemcrash essentially works by filtering out multicast RAs while preserving unicast responses.
I might be overlooking something, but wouldn't it be better to segregate those clients onto a separate network, like how people often create separate networks (using e.g. VLANs and/or separate ESSIDs) for e.g. IoT devices?
For example, I have separate networks at home with IPv4-only, IPv6-only and IPv4/IPv6 (for testing).
I might be overlooking something, but wouldn't it be better to segregate those clients onto a separate network, like how people often create separate networks (using e.g. VLANs and/or separate ESSIDs) for e.g. IoT devices?
For example, I have separate networks at home with IPv4-only, IPv6-only and IPv4/IPv6 (for testing).
Yeah, If the user's AP supports binding SSIDs to isolated VLANs, that is naturally the most accurate and "secure" method.
However, it also requires more investment in AP equipment. Ordinary home networks might just have a regular AP that doesn't support binding VLANs to SSIDs.
Additionally, some broadcast data from entertainment devices like TV screen mirroring(DLNA,SSDP) cannot cross broadcast networks.
Sometimes, performing these small operations within a single broadcast domain is actually a balance between cost and convenience.
I might be overlooking something, but wouldn't it be better to segregate those clients onto a separate network, like how people often create separate networks (using e.g. VLANs and/or separate ESSIDs) for e.g. IoT devices? For example, I have separate networks at home with IPv4-only, IPv6-only and IPv4/IPv6 (for testing).
Yeah, If the user's AP supports binding SSIDs to isolated VLANs, that is naturally the most accurate and "secure" method.
However, it also requires more investment in AP equipment. Ordinary home networks might just have a regular AP that doesn't support binding VLANs to SSIDs.
Not sure I follow? If a user wants to segregate wireless clients to their own network, a separate SSID is enough. If a user wants to segregate wireless and wired clients, a separate SSID + a VLAN (e.g. eth0.2) and/or specific ethernet port (e.g. eth2) can be bridged. That's all standard features in OpenWrt...
Or you mean if OpenWrt is used on the router and there's a separate AP device which isn't OpenWrt based?
Additionally, some broadcast data from entertainment devices like TV screen mirroring(DLNA,SSDP) cannot cross broadcast networks.
Yeah, that requires using something like mdns-repeater...
I know That's all standard features OpenWrt but to isolate the network broadcast ( IPv4-only, or both) with different wireless clients:
In software way: AP(s) of separated SSID must have a separate VLAN subnet ,not common with cheap dumb APs ( have to buy advnaced AP(s) ,not cheap)
In hardrdware way: (cheap dumb) AP(s) of separateed SSID must physically connect to openwrt port or to a VLAN switch(not cheap), more AP(s) needs to buy to fulfil the coverage (not cheap)
with the ability of send RA via unicast to a certain list of clients, this (some clients get IPv6, some are not) could be done with any cheap dumb APs