How to enable IPv6 on a subset of interfaces

[Brett Lee]

David Horn wrote:
> On Tue, Jan 12, 2010 at 4:36 PM, Brett Lee <Brett.Lee at sun.com> wrote:
>> Hello,
>>
>> Using FreeBSD 8.0-RELEASE, and am trying variations in /etc/rc.conf in an
>> attempt to enable IPv6 on ONLY one of the systems two interfaces.
>>
>> Specifically, em0 should be enabled IPv4 DHCP, and bge0 should be enabled
>> IPv6 only.
>>
>> From the KAME link below, and the files /etc/network.subr and
>> /etc/defaults/rc.conf, am reading that "ipv6_network_interface" should work;
>> however the following still results in em0 obtaining IPv6 addresses:
>>
>> http://www.kame.net/~suz/freebsd-ipv6-config-guide.txt
>>
>> ifconfig_em0="DHCP"
>> ipv6_enable="YES"
>> ipv6_network_interface="bge0"
>> ipv6_network_interfaces="bge0"
>>
>> In another attempt (see link below), it looks like "ifconfig_em0" may
>> support a "NOIPV6" param, but in practice it doesn't seem to work for me:
>>
>> http://lists.freebsd.org/pipermail/freebsd-rc/2007-May/001106.html
>>
>> ifconfig_em0="DHCP NOIPV6"
>> ipv6_enable="YES"
>> #ipv6_network_interface="bge0"
>> #ipv6_network_interfaces="bge0"
>>
>> Am hopeful that someone might point out how I could enable this
>> configuration.
>>
>> Thanks in advance!  -Brett
> 
> NOIPV6 is not a valid rc.conf configuration token at this time.
> 
> I am assuming that you are using SLAAC for IPv6 prefix/address
> distribution (via rtadvd/radvd), and not DHCPv6.
> 
> ipv6_network_interfaces is the correct rc.conf(5) variable to use to
> specifically control which interface gets configured using SLAAC via
> rtsol(8), but will not stop other interfaces from getting the RA
> (Router Advertisement) packet which starts IPv6 SLAAC (Stateless
> Autoconfiguration).
> 
> In -current/9.0 there are nice new ifconfig parameters (inet6
> ifdisabled -nud -accept_rtadv) and rc.conf variables that do just what
> you are looking for, but they are not in 8.0 at this time.
> 
> In 8.0 you can use the ndp(8) utility to set the -accept_rtadv (and/or
> ifdisabled/nud,etc.) flags on a per-interface basis. The
> "-accept_rtadv" flag will disable SLAAC for the specified interface,
> but must be called before the interface gets the "RA" packet to be
> effective.
> 
> You can do an ugly *unsupported hack* in 8.0 to call ndp from within
> rc.conf/rc.d startup scripts until the new code makes it into a
> release:
> 
> ipv6_enable="YES"
> ipv6_network_interfaces="bge0"
> ifconfig_em0="DHCP `ndp -i em0 ifdisabled -nud -accept_rtadv >/dev/null 2>&1`"
> ifconfig_bge0="UP"
> 
> This will cause some boot-time error messages about not finding ndp
> (before /usr is mounted), but these can be ignored, as the backticked
> ndp line will be run EVERY time that rc.conf is sourced.   This is
> just a work-around for 8.0 that happened to work for me at the time.
> If someone else has a better solution that fits properly within the
> confines of rc.conf, please speak up.
> 
> While on the subject, I have been thinking about putting together a
> patchset to experiment with adding some improved logic surrounding
> using DHCPv6 vs DHPCPv4 vs SLAAC/RTSOL in the rc.conf scripts and
> adding M+0 flag support +rdnss (RFC 5006) support to the kernel and
> userland and devd.  If I can ever get a working prototype, I will
> share to get some feedback.
> 
> Good Luck.
> 
> ---Dave Horn

In trying this:

ifconfig_em0="DHCP `ndp -i em0 (if?)disabled -nud -accept_rtadv 
 >/dev/null 2>&1`"

it seems like it will be "good enough" for our purposes.  The em0 
interface is not collecting the global SLAAC prefix and forming a global 
address; it is not learning about routers on that subnet; it is also not 
collecting reachability information about neighbors.  The last one is 
probably the most important to us.

The goal was to eliminate all global AND link local addressing/routing 
on em0, however, it was mentioned in one of the replies that this is not 
possible.  This question arose from an effort is to use FreeBSD 8.0 to 
verify a test platform that consists of the myriad of Tahi IPv6 test 
suites, while still maintaining direct connectivity between this host 
and the v4/v6 LANs.  With the solution above, I expect that this will 
suffice for our purposes.  If not, will fall back to the serial console.

Thanks everyone for your replies/suggestions!  -Brett