Date: Mon, 26 Jun 2006 14:07:12 -1000 (HST) From: Antonio Querubin <tony@lava.net> To: FreeBSD-gnats-submit@FreeBSD.org Subject: docs/99506: FreeBSD Handbook addition: IPv6 Server Settings Message-ID: <20060627000712.C1FD647227@cheesecake.lava.net> Resent-Message-ID: <200606270010.k5R0AJG0001138@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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@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@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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060627000712.C1FD647227>