miniupnp
miniupnpd: PCP announcements not sent from IPv6 GUA
instead, they are sent from the IPv6 link-local address, making it impossible to correctly discover the daemon with PCP and IPv6. Also, there is no other way for clients to discover the IPv6 GUA of the router, since IPv6 usually has a link-local gateway. Otherwise, PCP clients will have to try to find the gateway's IPv6 GUA, which may or may not succeed depending on the network configuration. Other implementations only send them from the IPv6 GUA with PCP.
RFC 6887 states that
FF02::1is the address to use.
From/source address was meant
RFC 6887 states that
FF02::1is the address to use.From/source address was meant
have you some code sample (from other implementation) to do that ?
Other implementations only send them from the IPv6 GUA with PCP.
I found this with wireshark. It is the AVM implementation. Also, there is no other way for clients to discover the IPv6 GUA of the router, since IPv6 usually has a link-local gateway.
What help do you need?
some code sample to send the PCP announcement from the correct address.
I've been investigating deploying this on IPv6-only networks. Being able to configure the address(es) used to send announcements and the scope would be extremely useful.
I operate gateway devices with Debian GNU/Linux, using systemd-networkd and nftables. I'm aiming to provide a seamless way for internal clients and services to ask the gateway to add/remove specific forwarding of routes (prefix or unicast) and unicast + port.
I can contribute code.
Consider this scenario:
- IPv6-only network, possibly with DNS64/NAT64 on the gateway
- Gateway uses ULA (formerly site-local) address internally that all clients can reach but isn't exposed globally
- Gateway also has GUAs for routing on public and private interfaces
- Clients are assigned both GUA and ULA addresses (ULA chosen for internal-only services)
- Multiple segments and links so link-local addresses aren't sufficient
- Gateway public multi-homed (multiple upstream interfaces: e.g. primary and fallback [each with its own GUA delegated prefix])
- Public via tunnel to gateway in some remote data-center (PCP at DC host - not affected by tunnel [with GUA delegated prefix from DC])
- Gateway private multi-home (multiple LAN interfaces and segments each with its own internally delegated sub-prefix and downstream routers [e.g: VM/container hosts] )
Example gateway devices:
PC Engines APU series (up to 4 Ethernet ports, cellular mini-PCIe, Wifi) Turris Mox series (up to 25 Ethernet ports, 1 SFP, cellular mini-PCIe, Wifi)
@iam-TJ do you have sample code that sends packets from the GUA to FF02::1 ?
@iam-TJ do you have sample code that sends packets from the GUA to
FF02::1?
Not as yet; I've been exploring the possibilities before committing myself. One potential solution I'm considering is integrating into firewalld so, as an example, a client firewalld allow rule can automatically be forwarded to the gateway firewalld instance.
I have been into some testing. On my FreeBSD 13.3 machine, when I send packets to FF02::1, the source address indeed the Link Local address (starting with fe80).
When I try to force the source address to the GUA of the network interface, I have an error : "No route to host"
Read the following in the context of me researching the protocols.
- Client discovery of the GUA of the PCP server. RFC7291 "DHCP Options for the Port Control Protocol (PCP)" is the way this should be done.
- For multi-homed clients (with multiple upstream PCP servers) RFC7488 "Port Control Protocol (PCP) Server Selection"
- For IPv6-only networks with a gateway doing NAT64 RFC7225 "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)"
I have been into some testing. On my FreeBSD 13.3 machine, when I send packets to FF02::1, the source address indeed the Link Local address (starting with fe80).
That is expected. The scop field (2nd octet, least-significant nibble) of 2 means link-local. RFC4291 (updated by RFC7346) defines the scope nibble values. I'd think you need site-local or organisation-local if the PMP server is listening on a ULA (Unique Local Address), or global if it is listening on a globally routable address (I cannot think of a reason to have the server on a globally routable address; ULA would be preferrable - akin to IPv4 RFC1918 private addresses).
Other implementations only send them from the IPv6 GUA with PCP.
As far as I understand, this is not possible as the announcement must be sent to [ff02::1]:5350 so they are from the Local-Link address.
I'm closing this issue for now.
As the announcements are sent to [ff02::1]:5350 they can't be sent from the IPv6 GUA, according to my tests and the scope of [ff02::1].
@Self-Hosting-Group I will need actual C code that does that to change the current behavior.