An update of IPv6 in FreeBSD

Requests for filtering ip6 fragments. Some packets have a Fragment header, since only the end-points are allowed to do ip6 fragmentation, not the routers. Some devices (which ones?) send packets with such headers, but with only one fragment in the sequence. This is at least dubious. Whether this is allowed is unclear, this is kind of a grey area in the RFC.

Report of one possible ip6 panic in 7.4. Unfortunately, not enough information was given to trace back, and the reporter is no longer reachable (only popped up on IRC?).

Issues with ip4 mapped addresses (??? to investigate).

A lot of downloads of the ip6-only snapshots. A lot of them from ip4 connections! Hypothesis: this was for internal networks which work over ip6, or maybe just for fun…

First reason: this is interesting and fun! Removing ip4 support from the kernel actually started as a April's fool joke.

Second, more serious reason: when ip6 does take off, FreeBSD doesn't want to be left behind, it needs to be ready feature-wise.

Personally, Bjoern is interested in ip6 for the usual reasons. He pointed out a reason I had never heard so far: NAT breaks geo-localisation and makes following users on their IP address more difficult. As a result, targeted ads will slowly become less relevant when large-scale NAT start being deployed. So, ad-selling parasites content producers will want to push ip6.

In your kernel configuration:

nooptions INET

nodevice gre (this is a bug, GRE tunnels should work).

In src.conf, define WITHOUT_INET_SUPPORT.

Tweak the features in sysctl(8) in the net.inet6 tree.

Need to add support in ifconfig(8) and in the rc framework. With a command such as ifconfig interface addr, ifconfig would assume the inet family for the address. This is obviously not going to fly when ip6 addresses need to be configured… The general direction will be to make the inet6? keyword mandatory.

Jails were interesting. Both ip4-only and ip6-only jails have been supported for some time, but an ip6-only kernel caused some issues (I don't remember more details).

Don't rely on a usable 127.1 address :-)

Different degrees of ip6-readiness were observed:

• some software does not work with ip6 at all;
• some software works in dual-stack hosts, but start breaking if ip4 is not configured;
• some software works in dual-stack hosts where ip4 is not configured, but start breaking when ip4 is not available at all in the kernel;
• some software works in a ip6-only kernel.

Most utilities will just work without ip4. bsdinstall and pc-sysinstall know how to handle ip6-only kernels (bsdinstall is the new installer for 9.0).

ftp(1) was an example of the 3rd situation: the ftp client needs to know the size of a socket. It tries to open a dummy AF_INET socket, which fails in an ip6-only kernel…

All software that uses gethostbyname(3) will break. Some software uses getaddrinfo(3). However, while bsnmpclient(3) uses getaddrinfo(3), it passes the ai_family = AFINET option :-/. There is mush work left to get rid of old DNS interfaces.

There are sometimes confusing error messages. fetch(1) for instance: in a broken ip6 network, when called without options to get a file from a DS host, it would report Address family not supported by protocol family. When called with the -6 option (to force ip6), it would report No route to host ¹.

What would happen was that in the first case, fetch(1) would try an ip6 connection, fail because of some network issue, then try an ip4 connection, fail because AF_INET is not available, give up and print the last error according to errno. In the second case, fetch would try ip6, fail, give up because the -6 switch told it to not try ip4 and print errno. In this instance, fetch was actually doing things right, but reported only the last error, which was not the important one.