Yes, due to new information IMHO it's better to revert RIO till
extensive testing and reworking. Maybe it should be implemented with
additional config-file option to toggle on and explicitly set prefix to
be sent in RIO.
On 09/11/2014 01:15 AM, Simon Kelley wrote:
On 10/09/14 15:41, Steven Barth wrote:
Since this should only happen when RIO and PIO are both /64 (and on-link
flag is set for the PIO) my work-around in OpenWrt was to simply not
send the RIO when PIO and RIO would be identical which solved the
problem for the user. Obviously if RIO and PIO have different sizes this
shouldn't matter.
As a side note: since afaik Windows is about the only system to support
and enable RIOs by default and Linux kernel-defaults are to ignore RIOs
with prefix-length != 0 and Apple not implementing RIO support at all we
could get in more trouble once more platforms enable RIO-handling by
default and maybe emitting the same behavior as this host. I didn't
bother to search the RFCs for what is the correct behaviour in case
identical RIOs and PIOs exist.
Focusing on the current dnsmasq code, I guess the take-home message here
is that we're probably better off to revert the code which adds RIOs,
for now, as the only RIOs we're sending are exactly the ones which
Steven suggests should be suppressed. Should probably re-visit the issue
of more general support for RIO in the next release.
Is that reasonable?
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
--
Best regards,
Ilya Ponetaev
D-Link Corp.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
