On Fri, May 17, 2019 at 2:13 PM Stuart Henderson <s...@spacehopper.org> wrote: > On 2019/05/16 23:37, Rachel Roch wrote: > > > RFC3513 says this: > > > > > > o An anycast address must not be used as the source address of > > > an IPv6 packet. > > > > > > o An anycast address must not be assigned to an IPv6 host, that > > > is, it may be assigned to an IPv6 router only. > > > > > > And to help ensure this, the kernel denies binding to an address marked > > > with the anycast flag (see netinet6/in6_pcb.c). > > > > > > This was obsoleted by RFC4291, including this change: > > > > > > o The restrictions on using IPv6 anycast addresses were removed because > > > there is now sufficient experience with the use of anycast addresses, > > > the issues are not specific to IPv6, and the GROW working group is > > > working in this area. > > > > > > So I think this restriction can now be removed, at least with this > > > change, but more might be needed > > > > Certainly in my case the current OpenBSD situation represents a bit too > > much "nanny knows best". > > No, it represents "following the (old) RFCs".
patches welcome, indeed the openbsd behaviour is adhering to now-outdated standards. > > My use-case is anycast DNS with NSD and Unbound. > > > > Both NSD and unbound provide config parameters that allow distinguishing > > between listen address and source address. > > > > But then again, is there any real reason to use the anycast flag ? To make > > NSD and unbound work I reconfigured to remove the anycast flag from IPv6 > > addresses and nothing seems broken ? > > > If you are doing a typical "internet anycast services" setup with some > routing protocol announcing the anycasted address then I don't see a use > for the flag, AFAICT it was mostly in conjunction with using an anycast > address for a local router, it feels like the usual IPv6 overengineering > to me.. Overengineering or not, there is no reason to disallow binding to interfaces which have the ANYCAST flag set. Kind regards, Job
