IPv6 TODO
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.
TOC
# # #
Kernel
nd6 locking
- Added by: BjoernZeeb
- Description:
The current locking is incomplete and cannot be easily implemented in some places leaving possible race conditions.
- Comment:
This should possibly addressed with reworking the if/ifaddr locking using a read-mostly lock.
mld6 locking
- Added by: BjoernZeeb
- Description:
mld6 locking state is unknown after the update from BruceSimpson for 8.0. Re-check.
unlocked globals
- Added by: BjoernZeeb
- Description:
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.
- Comment:
Some of these have been removed in the past. Review the list which is easier to identify these days due to the VNET flagging.
- PR: kern/128247, kern/131038
Rename in6p macros
- Added by: BjoernZeeb
- Description:
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.
- Comment:
Quite a few have been renamed already. Recheck for current leftovers.
- Comment:
Should have been done with VIMAGE integration to not mangle the trees too often?
Assimilate v4 and v6 code
- Added by: BjoernZeeb
- Description:
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.
- Comment:
Quite a bit of that has happened already.
PULLDOWN_TESTS and m_pullup
- Added by: BjoernZeeb
- Description:
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.
- Comment:
Coordinate with whomever will touch mbufs next (jeffr, rwatson, ..?)
- Comment:
There is an outdated work in progress in p4:bz_ipv6(?).
No modification of in-flight variables
- Added by: BjoernZeeb
- Description:
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.
- Comment:
Some initial changes were done along with the inp and jail+v6 changes.
IPv6 IPsec fallout
- Added by: BjoernZeeb
- Assigned to: BjoernZeeb
- Description:
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.
- PR: kern/121373, kern/151449, kern/94273, kern/155165
CARP IPv6
- Added by: BjoernZeeb
- Submitted by: PeterLosher
- Description:
Carp and IPv6 did not work out of the box. It seemed to be a rc.* startup problem.
- Comment:
Review if still true. Might most likely be fixed.
- Comment:
PR kern/153848
in6_ifattach and bridge
- Added by: BjoernZeeb
- Description:
in6_ifattach() behaves special when trying to assign a link-local address to a bridge. That should not be fixed.
embedded scope in KAME
- Added by: BjoernZeeb
- Description:
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
- Added by: BjoernZeeb
- Description:
Old NFS v6 mount “hangs”, was that nlm or not? NFS v6 netboot code support from loader onwards (nfsclient basically). UEFI/EFI netboot?
- Ponder: ignore the old code and only work on the “experimental” code.
- Patch: there is an NFS_ROOT patch from RickMacklem for the exp NFS which should be the base for getting more IPv6 in there.
- Description:
struct sockaddr_in {}s everywhere. Can see endless mount retries and failures if going IPv6 only.
IPv6 class
PMTU blackhole detection
- Added by: HirokiSato
- Description:
MTU blackhole detection (RFC 2923) for IPv6.
- PR kern/143666.
Note: ume points out the patch in the PR is not good enough.
IPv6 Loopback performance
- Added by: BjoernZeeb
- Description:
IPv6 Loopback performance is significantly lower than IPv4. Run PCM, figure out all the bottlenecks – it's not (only) the checksumming.
- Under investigation by bz as part of performance work.
- TCP is fine, UDP in general needs a bit more work on throughput but not on pps.
Mobile IPv6
- Added by: Ana Kukec
- Description:
Should we try to pick up Mobile IPv6 work, update the locking and get it in?
- Pondering:
HirokiSato could contact people with SHISA (ex KAME implementation).
ff01/2::1 not ok in 9
- Added by: HirokiSato
- Description:
ff01/2::1 handling seems ok in 8.1 but not in 9.0.
Make sure we pass TAHI again
- Added by: BjoernZeeb
- Description:
FreeBSD is currently not passing all TAHI tests.
- PR: kern/152791
# # #
Firewalls
ipfw(8) me[46]
- Added by: (copy from other TODO page)
- Description:
ipfw(8) has “me” and “me6”, suggest to add “me4” as a synonym for IPv4.
natd/divert/rdr/fwd IPv6 support
- Added by: (copy from other TODO page)
- Description:
natd(8) doesn't support IPv6 (probably caused by absence of an IPv6 divert socket) divert(4) should have an IPv6 equivalent.
- Comment:
Follow nat66 etc. discussion in IETF before implementing anything.
- Comment:
According to ErmalLuci pf can do prefix rewriting. Anyone Checked?
- PR: kern/128260
NAT66
- Added by: BjoernZeeb
- Description:
Do we want to support prefix rewriting (NAT66)? pf supports this.
- See also: natd/divert/rdr/fwd IPv6 support
cleanup ipfw syntax completely
- Added by: BjoernZeeb
- Description:
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
- Added by: BjoernZeeb
- Submitted by: FernandoGont
- Description:
Should (at least) be documented in the man page.
6RD
- Added by: HirokiSato
- Description:
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
- Added by: PeterLosher
- Description:
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.
- Possibly talk to John Brzozowski from Comcast.
DS-Lite
- Added by: BjoernZeeb
- Description:
IETF work. Shoud we implement it. Implement == integrate gif + dhcp + rc.conf +… etc. mostly. Might be simple enough to support?
- Comments:
Be aware of ISC AFTR which implements the 'other side' and can be used to tests against.
- Comments:
- For GSoC that would probably be a half-time project.
XLATE
- Added by: BjoernZeeb
- Description:
Hoh, why are people pondering some many different names for transition technology. What's this and is it worth looking?
NAT64/DNS64
- Added by: BjoernZeeb
- Assigend to: BjoernZeeb
- Description:
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.
- The changes are in upstream OpenBSD now for pf.
# # #
Userland
IPv6 userland problems
- Added by: GeorgeNevilleNeil
- Description:
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.
- See also: INET6 only
- See also: rpc and nfs code very legacy IPish in places
rpc and nfs code is very legacy IPish in places
- Added by: GeorgeNevilleNeil
- Added by: BjoernZeeb
- Description:
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
- Added by: BjoernZeeb
- Description:
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
- Added by: BjoernZeeb
- Description:
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
- Added by: BjoernZeeb
- Description:
openssl is a gethostbyname() user as well, not only for s_client.
- WIP with GSoC2012
gethostbyname()
- Added by: BjoernZeeb
- Description:
Given the experience with cvs and openssl, scan the entire tree for gethostbyname() et. al consumers and fix them to do better name lookups.
- WIP with GSoC2012
routed broken
- Added by: HirokiSato
- Description:
routed / route6d are broken? Keep in base and fix or remove from base and possibly use ports?
DHCPv6
- Added by: BjoernZeeb
- Description:
Evaluate and integrate one of the DCHPv6 implementations.
Discussion on the mailing list: https://lists.freebsd.org/pipermail/freebsd-net/2019-October/054474.html
# # #
New/Unclassified
Create an IPv6 demo Image
- Added by: BjoernZeeb
- Description:
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)
- Added by: BjoernZeeb
- Description:
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.