Making net.inet6.ip6.v6only=0 default

[JINMEI Tatuya / 神明達哉]

At Fri, 28 Jun 2013 17:30:21 -0500,
"Mark Felder" <feld at feld.me> wrote:

> Later after a bit more digging and discussion I've come to learn that the  

So, you've gone through the literature on this topic including
http://tools.ietf.org/html/draft-cmetz-v6ops-v4mapped-api-harmful-01
?

> security aspect may simply be "unexpected behavior -- the binding to ipv6  
> sockets and endusers not realizing it, thus creating a security hole for  
> environments with only an ipv4 firewall".
> 
> We ship a dual stack firewall by default, and now since FreeBSD 9 we have  
> the rc.conf setting ipv6_activate_all_interfaces="YES" which seems  
> sufficient to mitigate this; the user would have to know they're enabling  
> ipv6 and what its consequences could be.

I'm afraid it's a bit too optimistic.  We also need to rely on
either application programmers being careful enough to write code like
this:
-      sin6 = (struct sockaddr_in6 *) sa;
-      inet_ntop( AF_INET6, (void *) sin6->sin6_addr.s6_addr, addr, sizeof
-                 addr );
-      /* If it's an IPv4 mapped address, drop the leading '::ffff:' */
-      if ( IN6_IS_ADDR_V4MAPPED( &(sin6->sin6_addr) ) )
-        strncpy( wrapper_addr, addr + 7, sizeof wrapper_addr );
-      /* otherwise surround the address with braces to hopefully match 
-         what tcp wrapper expects */
-      else sprintf( wrapper_addr, "%s", addr );
-    }
(taken from the FreeBSD port patch for rwhois)
so a naive user can safely write a rule like
  deny 192.0.2.1
  allow all
or the user is careful enough to write ACLs like:
  deny 192.0.2.1
  deny ::ffff:192.0.2.1
  allow all

In theory, people (either or both of programmers and users) can make
it safe.  In practice, I personally think it's sufficiently error
prone.

Admittedly, however, different people may have difference senses on
the severity of this point.  And (in my understanding) that's why
relevant people failed to get a clear consensus at the time they
discussed this API.  In the end the "standard" default behavior was
documented with leaving lots of controversy.  Unfortunately, this also
left portability problems.  It's not only for FreeBSD; as far as I
know NetBSD still keeps the same default as FreeBSD, and, as far as I
know OpenBSD still even refuses to allow this usage of IPv4-mapped
IPv6 addresses.  And, I suspect some of them do so "religiously", and
will never change the behavior no matter what the "standard"
documentations state.

So...

> So I guess the question is: what do we do? It looks like we're in  
> violation of both RFC 3493, Section 5.3 and POSIX 2008, Volume 2, Section  
> 2.10.20*.

...aside from what FreeBSD should do for ip6.v6only, I personally
believe that realistically this issue should be resolved at the
application side, i.e., explicitly set the IPV6_V6ONLY socket option
to 1 and use both AF_INET (for IPv4) and AF_INET6 (for IPv6, and only
for IPv6) sockets.  As far as I know this is the most portable
behavior.  Regarding the rwhois case, I'd first suggest updating the
patch with this socket option setting.  Hopefully it can be accepted
by the upstream because it's most portable.  If they still reject it
because "it's against the standard" (and even if it's less portable in
reality), my next suggestion is to explicitly set the IPV6_V6ONLY
socket option to 0.  This setting is "redundant" in the sense of
standard purity, but hopefully less controversial for those preferring
the standard compliance as it only requires a small change and will
make it still more portable.

Going back to the question of what FreeBSD should do for ip6.v6only:
Personally, I'd still suggest keeping the same default because I agree
this behavior is sufficiently safer (as noted above) *and* there'll
be portability issues anyway (OSes using the different default
"religiously" will never change it).  But I also understand the
argument that standard compliance is more important than debatable
safety.  In either case, it would help if we provide detailed
discussion for the description of this sysctl knob.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.