Introduction

In the IRC meeting on ​26th Apr 2012 the following was agreed upon (from summary):

Agreed that focusing 2.4 release cycle to cleaning up, refactoring and
modularizing the codebase makes sense and addresses many of concerns
pointed out regarding project's long-term viability. This cleanup and
simplification work would also help bring in new contributors, i.e.
lower the barriers to entry due to simpler and more understandable codebase.

This page intends to outline the changes that will be needed in 2.4 to reach those goals.

Tasks

These tasks were originally from an IRC meeting agenda:

• Android patchsets done
• Dual stack client patches done*
• Dual stack server and --inetd cleanup
• --preresolve patch
• utun on mac os x done*
  • native tun, no need for extra tun.kext
  • Supported for all OS X >= 10.6.8 (latest PPC version)
    • Unfortunatly requires root
    • Real question: Drop tun.kext support and support only utun or "try utun first, fall back to tun.kext if it fails"
• svn 2.1 patchset (snappy support, push-peer-info changes, see trac#268-273)
• management interface changes (status 2/3) done*
• Formatting and whitespace fixes (just before 2.4 release)
• --version to include git commit id and branch? yes, done
• OpenVPN-GUI installer from mattock

Cleaning up IPv4/IPv6 split

• what is this?

Android/iPhone/Windows Phone 7 support

• what is this?

Windows Interactive Service

• d12fk's new windows privilege separation scheme, permitting fully unprivileged users to safely run OpenVPN (described and agreed-upon at the MunichHackathon2013)

new frame format for data packets

• fix alignment performance penalty (byte-swap control byte with last byte of payload)
• enable DoS-safe --float in TLS mode by transmitting session ID in data frames "ever so often" (like "when not having seen a packet from the server since more than 500 milliseconds" or whatever)
• agreed-upon at the MunichHackathon2013 (last section), nothing implemented yet

the grand compression cleanup

• have the server select the "best" compression algorithm the client supports (lz4/snappy/lzo/none), based on pushed peer-info and server capabilities (can be done by a client-connect script, but "built-in" would be less error-prone)
• rework the whole "compress" and "comp-lzo " section of the openvpn.8 man page
• get rid of --enable-comp-stub - always include that, so a well-defined fallback exist (to be discussed)

IPv6 payload / payload/routing integration

• implement "redirect-gateway ipv6" in 2.x code base as well (3 has it)
• add --block-ipv6
• handle ipv6 payload over ipv6 transport, when the VPN server is inside the pushed IPv6 routes
  • discover IPv6 default gateway
  • install IPv6 route to VPN server via gateway
  • cleanup afterwards
• handle iroute-ipv6 and pushed route-ipv6 consistently with IPv4: do not send pushed routes to the very client that the iroute-ipv6 points to (local route confusion at client), also trac#354.