90 | | (Since the hackathon hasn't happened, I'm just listing things here that need coverage - a number of them already agreed last year, but not yet done) |
91 | | |
92 | | * --float with TLS HMAC / new packet format |
93 | | |
94 | | * OpenVPN 3 |
95 | | |
96 | | * plan for the technical development of 2.4 and 3? |
97 | | * 2.4 (cron2): IPv6 enhancements |
98 | | * handle overlapping IPv6 server address and pushed IPv6 routes ("2001:608::/32 and server inside 2001:608::/32 -> recursive routing"). This is done for IPv4 but not IPv6 yet. Ask OS for default gateway, install route to OpenVPN server to that gateway, then install pushed routes. Cleanup on exit. |
99 | | * --block-ipv6 for mobile clients (blocking inside OpenVPN) |
100 | | |
101 | | * windows and the interactive service |
102 | | * end result: while not in full agreement on details, we'll go forward with what d12fk already has ("working code" trumps "perfect world"). |
103 | | |
104 | | * packet format and alignment (James/--tls-float patch) |
105 | | * HMAC and encrypted data is not 32bit aligned today due to the opcode |
106 | | * propose to byte-swap the opcode with the last byte in the packet, so after swapping back the HMAC is 32bit aligned |
107 | | * can be done by sending IV_PROTO=<supported max version> by the client (server can then immediately turn it on) and pushing "wire-proto <x>" from the server to the client (and then the client can immediately turn it on) |
108 | | * slightly related: include session ID in the data packet, "if you feel like it might be needed"? (to handle --float in TLS-mode without opening ourselves to UDP->HMAC CPU DoS) |
109 | | * "don't send it more than 1/second, don't send it unless you have heard from the server for more than <n> seconds"... |
110 | | * watch out for MTU jumps -> "set aside that amount of space even if not used" |
111 | | * TODO: |
112 | | * define opcodes for "wire-protocol 2" for "short/swapped mode" and "swapped mode with session id" |
113 | | * add "wire-protocol 2" to option.c etc |
114 | | * add push-peer-info IV_PROTO=2 |
115 | | * add logic to server to read IV_PROTO and push "wire-protocol <x>" to the maximum supported by client and server |