Hi,
yes, but presence of IPv6 networks is often missing. It seems to be DHCP
option could be used just very similar way. Offer just H bit in DHCP
option, followed by PvD ID FQDN. Delay field probably. If nested options
should be needed, then encode them like DHCP options inside.
That way, it would make it possible to have name for local network. When
combined with H bit, it could even be verified by TLS request. Nice
alternative for autodetection of ethernet ports, which lack SSID
identification on common networks. And much more complicated RADIUS
based identification of this network.
It seems to be too complicated to listen for RA on IPv4-only network. If
L flag is set on two RA anouncements, I will not be able to choose
correct one anyway. If only one is supported, then it could be part of
DHCP message right away. If there were two separate DHCP servers, each
could provide different PvD ID, just like on different RA messages from
different routers.
dnsmasq I am working on can do RA. But I think it cannot propagate RA
without being router. It can set lifetime == 0. But it does not support
any nice configuration for RFC 8801. Because it expects every RA option
has DHCP counterpart. In case of PvD, this is not true.
Yes, that is limitation on dnsmasq code side. But I fail to see why is
this standard bound to router advertisements only. It would make sense
to me for example when requesting DHCPv6-PD (RFC 8415). It could be
trivially configured also to old hardware, where custom DHCP options can
be specified. I think some network identification is important not only
for IPv6 networks. Maching RA with DHCPv4 by a single bit in that RA
seems like a hack to me. It complicates implementation of this standard
on dual networks and makes it quite weird on ipv4-only networks.
Were there specific reason, why no DHCPv4 equivalent were included in
the spec? Would it make sense to propose it now?
Thank you,
Petr
On 14/10/2025 16:00, Eric Vyncke (evyncke) wrote:
As most if not all host OS support IPv6, the easiest way is probably
to send an IPv6 ‘empty’ RA (i.e., not pretending to be a router,
lifetime = 0, no flags, no PIO, no RIO, ...) that will be picked up by
the hosts stack.
About the use of it, you may be aware of
https://datatracker.ietf.org/doc/draft-ietf-intarea-proxy-config/
Regards
-éric (no hat except co-author of RFC 8801)
*From: *Petr Menšík <[email protected]>
*Date: *Friday, 10 October 2025 at 16:39
*To: *[email protected] <[email protected]>
*Subject: *[Int-area] How to use RFC 8801 Provisioning domains on IPv4
Hello!
I work in Red Hat as a software engineer, working in RHEL on components
like dnsmasq and unbound. I would like to improve ability of Linux to
use multiple interfaces at the same time, using localhost caching DNS
proxy.
RFC 8801 provisioning domains allows Router Advertisement messages to
contain network identification name. Which in combination with
additional TLS verified server name can identify the network I am on. In
trusted manner.
This is just great and I love it, but I lack similar approach to be used
from DHCPv4 server on the same network. Yes, for a common clients and
simple networks there would be usually just one DHCP server. I think
quite similar DHCP option would be useful also on IPv4 networks.
I am especially interested in additional information dnsZones [1]
property. Is there a correct way, how should IPv4 only host obtain
similar information from network it is connected into? Is there reason,
why similar option is not offered over DHCP protocol, both in IPv4 and
IPv6 variant?
I have some expertise in DNS protocol and understanding of DHCP or RA
messages. But I failed to find how exactly the same information can be
obtained without Router Advertisement messages. Should be RA message
used somehow even on IPv4 protocol?
Is this RFC already implemented on any released OS, including IPv4
support?
Thank you in advance!
Regards,
Petr Menšík
1.
https://www.rfc-editor.org/rfc/rfc8801.html#name-pvd-additional-information-
--
Petr Menšík
Senior Software Engieer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Petr Menšík
Senior Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
