docs/99506: FreeBSD Handbook addition: IPv6 Server Settings

[Antonio Querubin]

>Number:         99506
>Category:       docs
>Synopsis:       FreeBSD Handbook addition:  IPv6 Server Settings
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 27 00:10:18 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Antonio Querubin <tony at lava.net>
>Release:        FreeBSD 4.11-RELEASE-p13 i386
>Organization:
LavaNet
>Environment:
System: FreeBSD cheesecake.lava.net 4.11-RELEASE-p13 FreeBSD 4.11-RELEASE-p13 #2: Tue Nov 8 12:19:37 HST 2005 adrian at cheesecake.lava.net:/usr/obj/usr/src/sys/LAVA i386

>Description:

The default setting of ipv6_ipv4mapping="NO" in /etc/defaults/rc.conf in 
FreeBSD 5.x and 6.x catches people by surprise if they're setting up dual 
stack IPv6/IPv4 servers since it breaks the protocol-independent feature 
of the socket API.  I suspect the majority of daemons that have been 
updated to comply with the IPv6 socket API are coded to only open a single 
protocol-independent socket and do not care whether the connection is IPv4 
or IPv6.  As a result, the default setting can break IPv4 connectivity for 
such daemons when a server is enabled for IPv6.

>How-To-Repeat:

>Fix:

I recommend adding the following section (or some similar wording) to the 
FreeBSD Handbook to clarify the workaround for IPv6-enabled servers and 
mention the security implication for such workaround.

"27.10.5.4 IPv6 Server Settings

If your server will be running services listening on both IPv4 and IPv6
addresses, you will probably need to add:

ipv6_ipv4mapping="YES"

This applies only to FreeBSD 5.x and 6.x and ensures programs written in a 
protocol-independent manner and comply with the Basic Socket Interface 
Extensions for IPv6 (RFC3493) can respond to IPv4 connections 
transparently.

Note:  if you enable the ipv4mapping feature and you do any kind of 
detection or access control of IPv4 addresses, you may need to convert 
your filters to use the IPv4-mapped representation of those addresses.  
For example, an access control list for a daemon on an IPv4 server that 
targets 192.168.100.0/24 may need to be updated to use 
::ffff:192.168.100.0/120 on an IPv6 server to continue to be effective."
>Release-Note:
>Audit-Trail:
>Unformatted: