#264 closed Feature Wish (wontfix)
[PATCH] IPv6 p2p issues
Reported by: | leres | Owned by: | Gert Döring |
---|---|---|---|
Priority: | minor | Milestone: | release 2.5 |
Component: | IPv6 | Version: | OpenVPN git master branch (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | IPv6 p2p |
Cc: | openvpn13@… |
Description
I had a couple problems adding IPv6 to an existing IPv6 p2p tunnel configuration. I want to use:
# server ifconfig-ipv6 2620:83:8000:3088::101/128 2620:83:3000:8088::445 # client ifconfig-ipv6 2620:83:8000:3088::445/128 2620:83:3000:8088::101
First I ran into:
ifconfig-ipv6: /netbits must be between 64 and 124, not /128
Once I "fixed" that the ifconfig command issued was missing the remote end:
# server openvpn_test[57456]: /sbin/ifconfig tun6 inet6 2620:83:3000:8088::101/128
Attached are patches for both changes I needed.
Attachments (3)
Change History (12)
Changed 12 years ago by
Attachment: | patch-srcopenvpnoptions.c added |
---|
Changed 12 years ago by
Attachment: | patch-src_openvpn_options.c added |
---|
Changed 12 years ago by
Attachment: | patch-src_openvpn_tun.c added |
---|
comment:1 follow-up: 6 Changed 12 years ago by
comment:2 Changed 12 years ago by
Owner: | set to Gert Döring |
---|---|
Priority: | major → minor |
Status: | new → accepted |
Type: | Bug / Defect → Feature Wish |
comment:3 Changed 11 years ago by
cron2: do we want to implement this feature at some point, or should we just close this ticket?
comment:4 Changed 9 years ago by
Milestone: | → release 2.4 |
---|---|
Version: | 2.3.0 → git master branch |
We're not changing this for 2.3, but I might be tempted to work on this (read: ensure that it actually works on all supported platforms!) for 2.4 - for example, most if the BSDs would need an extra route for the remote address, not just an extra ifconfig parameter (if that is valid at all).
But maybe not. The IPv6 code really wants a subnet.
comment:5 Changed 8 years ago by
Using such setup with custom 'up' script calling IP6 ifconfig/route/ip commands and it works fine. I do not understand why I should create subnets for openvpn when they are not needed using the ip commands.
comment:6 Changed 5 years ago by
Replying to Gert Döring:
This is not the way it is supposed to work - we run the tun interface as a network, not as a /128 with independent addresses on the left and right end (because that is not working on all supported platforms).
Just assign a /124 to the tun, and give both sides an address out of it
you have enough IPv6 addresses so you can afford "wasting" a /124 there.
I prefer if the upper-limit is increased from /124
to /127
.
comment:7 Changed 5 years ago by
Milestone: | release 2.4 → release 2.5 |
---|
We missed 2.4 release by a wide margin. Maybe I can find time to look into this again (across all platforms!) for 2.5.
"Just because it works on Linux with the 'ip' command" is not sufficiently good for an upstream change -- it either needs to work on all supported platforms or be documented appropriately.
comment:8 Changed 4 years ago by
Resolution: | → wontfix |
---|---|
Status: | accepted → closed |
I am closing this now with "wontfix".
The IPv6 handling code "for all platforms" assumes subnets, and using a /124 for a p2p link is a perfectly fine way to do so.
Yes, it works on Linux with /128s and p2p addressing.
Maybe it works on Windows, FreeBSD, NetBSD, OpenBSD, MacOS, OpenSolaris? and AIX. Maybe not. Someone needs to test this initially, and keep testing this to ensure we do not accidentially break it with some refactoring.
This is lots of work, and I do not see anyone interested in doing this (for *all* platforms). There is still bugs in the existing IPv6 code for some of the oddball configurations, so it's not good for the overall code quality and project maintenance to introduce yet another variant.
Subnets it is, if you want OpenVPN to handle IPv6 address configuration for you.
If you want something else, and that works on your platform, --up
is the tool for you.
(As a side note: /127 does not work on all platforms either. /124 is "it works always" safe land)
comment:9 Changed 12 months ago by
Gert, any reason why /124 was chosen and not /126 for example? I expect /126 to be fully compatible with every OS/implementation.
By the way, ifconfig-ipv6 is inconsistent on server and client: ifconfig-ipv6-push allows pushing 0-128 bits, while the client only accepts 64-124 bits.
This is not the way it is supposed to work - we run the tun interface as a network, not as a /128 with independent addresses on the left and right end (because that is not working on all supported platforms).
Just assign a /124 to the tun, and give both sides an address out of it
side A:
sideB:
you have enough IPv6 addresses so you can afford "wasting" a /124 there.