JINMEI Tatuya / 神明達哉 <jin...@isc.org> wrote in <m2ppv5k988.wl%jin...@isc.org>:
ji> > So I guess the question is: what do we do? It looks like we're in ji> > violation of both RFC 3493, Section 5.3 and POSIX 2008, Volume 2, Section ji> > 2.10.20*. ji> ji> ...aside from what FreeBSD should do for ip6.v6only, I personally ji> believe that realistically this issue should be resolved at the ji> application side, i.e., explicitly set the IPV6_V6ONLY socket option ji> to 1 and use both AF_INET (for IPv4) and AF_INET6 (for IPv6, and only ji> for IPv6) sockets. As far as I know this is the most portable ji> behavior. Regarding the rwhois case, I'd first suggest updating the ji> patch with this socket option setting. Hopefully it can be accepted ji> by the upstream because it's most portable. If they still reject it ji> because "it's against the standard" (and even if it's less portable in ji> reality), my next suggestion is to explicitly set the IPV6_V6ONLY ji> socket option to 0. This setting is "redundant" in the sense of ji> standard purity, but hopefully less controversial for those preferring ji> the standard compliance as it only requires a small change and will ji> make it still more portable. ji> ji> Going back to the question of what FreeBSD should do for ip6.v6only: ji> Personally, I'd still suggest keeping the same default because I agree ji> this behavior is sufficiently safer (as noted above) *and* there'll ji> be portability issues anyway (OSes using the different default ji> "religiously" will never change it). But I also understand the ji> argument that standard compliance is more important than debatable ji> safety. In either case, it would help if we provide detailed ji> discussion for the description of this sysctl knob. Agreed. Honestly my patch was not intended for upstream because it was too aggressive (for them). Explicitly dropping IPV6_V6ONLY may be acceptable. I am also for keeping the sysctl knob. Except for Java, most of applications which run on FreeBSD have survived with it. In addition to the points already mentioned, I do not like s/AF_INET/AF_INET6/ replacement like rwhoisd does, and I believe this kind of network programs should be implemented in an AF-independent fashion, not depending on AF_INET6, and handle each available AF separately. It prevents issues in corner cases. -- Hiroki
pgph5926RY4jB.pgp
Description: PGP signature
