This page aims to be a collection of open IPv6 tasks need to be done in the FreeBSD kernel and userland.

Add a task to the "New/Unclassified" section as you find something new, take a task and let us know if you have the resources to work on it or ask if you are looking for someone to fix it for you. Main contact persons are BjoernZeeb (bz@), HirokiSato (hrs@). GeorgeNevilleNeil (gnn@) and others might also volunteer to help.

Further details for each task are given below.

Google Summer of Code

For Google Summer of Code some projects are too simple tasks and you might want to pick multiple. But be careful - some easy sounding tasks are really big. In case you have your own ideas we'd like to hear about them as well. We'd suggest you'd get in contact with the aforementioned committers and discuss things.



nd6 locking

The current locking is incomplete and cannot be easily implemented in some places leaving possible race conditions.

This should possibly addressed with reworking the if/ifaddr locking using a read-mostly lock.

mld6 locking

mld6 locking state is unknown after the update from BruceSimpson for 8.0. Re-check.

unlocked globals

Some global variables are used to cache state either for fast lookup or to actually keep state between different functions in the input/output paths. There is no locking and thus races are easy leading to panics or invalid results.

Some of these have been removed in the past. Review the list which is easier to identify these days due to the VNET flagging.

Rename in6p macros

For IPv6 a lot of inp values are aliased to in6p using macros. This is confusing and unhelpful these days when searching for certain fields for example.

Quite a few have been renamed already. Recheck for current leftovers.

Should have been done with VIMAGE integration to not mangle the trees too often?

Assimilate v4 and v6 code

IPv4 and IPv6 have a lot of similar code for upper layer protocols. A lot of those duplicate code can be merged into a single function without code obfuscation or much effort and will help maintanance and make sure the one or other IPv[46] implementation is not missed.

Quite a bit of that has happened already.

PULLDOWN_TESTS and m_pullup

The original KAME (regression) checks based on certain mbuf assumptions are intermangled in the code. We should make sure that things just work with the general mbuf usage we do, not assuming anything more special and remove the tests to make the code more readable.

Coordinate with whomever will touch mbufs next (jeffr, rwatson, ..?)

There is an outdated work in progress in p4:bz_ipv6(?).

No modification of in-flight variables

For IPv4 inp handling we are trying hard to be able to not have any comitted changes in case of error. For IPv6 inp handling and in general on the stack we sometimes update state for called functions to have it availabale but can no longer properly rollback in case of error leaving us in an unknown state.

Some initial changes were done along with the inp and jail+v6 changes.

IPv6 IPsec fallout

With implementing IPv6 support for FAST_IPSEC (now know as IPSEC) and removing KAME IPsec there are some lose ends and problems that need to be addressed, including panics and missing features like v4-over-v6 or v6-over-v4 support.


Carp and IPv6 did not work out of the box. It seemed to be a rc.* startup problem.

Review if still true. Might most likely be fixed.

PR kern/153848

in6_ifattach and bridge

in6_ifattach() behaves special when trying to assign a link-local address to a bridge. That should not be fixed.

embedded scope in KAME

KAME did embed the scope in the address (probably for memory reasons back then). This troubles things here and then. We should try to see if we can normalize things.

NFS over IPv6

Old NFS v6 mount "hangs", was that nlm or not? NFS v6 netboot code support from loader onwards (nfsclient basically). UEFI/EFI netboot?

struct sockaddr_in {}s everywhere. Can see endless mount retries and failures if going IPv6 only.

IPv6 class

Implement IPv6 class support in all places.

PMTU blackhole detection

MTU blackhole detection (RFC 2923) for IPv6.

Note: ume points out the patch in the PR is not good enough.

IPv6 Loopback performance

IPv6 Loopback performance is significantly lower than IPv4. Run PCM, figure out all the bottlenecks -- it's not (only) the checksumming.

Mobile IPv6

Should we try to pick up Mobile IPv6 work, update the locking and get it in?

HirokiSato could contact people with SHISA (ex KAME implementation).

ff01/2::1 not ok in 9

ff01/2::1 handling seems ok in 8.1 but not in 9.0.

Make sure we pass TAHI again

FreeBSD is currently not passing all TAHI tests.


ipfw(8) me[46]

ipfw(8) has "me" and "me6", suggest to add "me4" as a synonym for IPv4.

natd/divert/rdr/fwd IPv6 support

natd(8) doesn't support IPv6 (probably caused by absence of an IPv6 divert socket) divert(4) should have an IPv6 equivalent.

Follow nat66 etc. discussion in IETF before implementing anything.

According to ErmalLuci pf can do prefix rewriting. Anyone Checked?


Do we want to support prefix rewriting (NAT66)? pf supports this.

cleanup ipfw syntax completely

ipfw syntax with reagrd to ipv6 (if not also ipv4) is awkward and complicated and non-intuitive. Break backward compatibility and clean the mess up. Maybe have a coverter?

Transition Technologie

stf icmp ratelimit issue for pmtu

Should (at least) be documented in the man page.


A patch on top of stf(4) was posted to net@. It might need minor improvements but we should get it finished and in. Another patch form someone in .jp exists; see pfsense or net@ 20120315.

stf(4) performance

Someone had mentioned to him that stf(4) has performance issues. Shuld we consider fixing it given that 6to4 is considered "bad"? On the other hand people will have to run it for another couple of years.


IETF work. Shoud we implement it. Implement == integrate gif + dhcp + rc.conf +... etc. mostly. Might be simple enough to support?

Be aware of ISC AFTR which implements the 'other side' and can be used to tests against.


Hoh, why are people pondering some many different names for transition technology. What's this and is it worth looking?


There is a patch for unbound from Viagenie and newer BINDs support DNS64. There is also a NAT64 implementation for pf based on a patch from Viagenie. need to get these in.


IPv6 userland problems

Many userland network utilities do not work correctly with IPv6.

IMPORTANT : Plenty of them are currently part of the IPv6 Improvement project

who(1) truncates IPv6 addresses in its output (still true?). This project could also include a broader survey of other network services in userland to make sure they are all IPv6 clean.

rpc and nfs code is very legacy IPish in places

rpc.statd(8) is not IPv6 clean. rpc.rquotad(8) is not IPv6 clean.

inetd.conf requires {tcp,udp}6 instead of just tcp in v6 only env

If running inetd in an IPv6 only setup all services need changing to tcp6 oder udp6 rather than working with the default of tcp and udp.

cvs client inet only

Our in-tree cvs client is INET-only for pserver mode. Patch available for testing: http://people.freebsd.org/~bz/patch-20110103-01-cvs-client-ipv6-pserver.diff Updated patch available for testing: http://svnweb.freebsd.org/socsvn/soc2012/exxo/patches/

openssl s_client

openssl is a gethostbyname() user as well, not only for s_client.


Given the experience with cvs and openssl, scan the entire tree for gethostbyname() et. al consumers and fix them to do better name lookups.

routed broken

routed / route6d are broken? Keep in base and fix or remove from base and possibly use ports?


Evaluate and integrate one of the DCHPv6 implementations.


Create an IPv6 demo Image

Create a framework to automatically bundle a couple of dual-stack and IPv6-only or IPv4-only machines, maybe creating VM images, to be used for demonstration and training purposes. This could also use the experimental VIMAGE kernel feature for multiple network stacks and extend Immunes or other simulation frontends to give a nice UI to users. Ideally we would bundle the most interesting transition technologies as well.

Standards compliance and IETF drafts (old and new)

The FreeBSD IPv6 network stack, derived from the KAME IPv6 implementation, for historical reasons includes various earlier IETF draft work. Go through the stack and identify this work, clearly marking it and evaluate if it either needs to be updated to later RFC texts, should be made optional (kernel option for INET6_EXPERIMENTAL or the like) for standard compliance reasons, or kept as-is.

Also going through the list of IPv6 standards documents and see which parts FreeBSD implements and which we are lacking.

In either case implementing, testing and submitting patches should be the immediate follow-up work to address the findings.

CategoryTodo CategoryIpv6

IPv6TODO (last edited 2017-09-18 12:47:04 by KubilayKocak)