After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 593813 - IPv6 ppp/mobile/vpn support
IPv6 ppp/mobile/vpn support
Status: RESOLVED INVALID
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2009-09-01 15:11 UTC by Dan Winship
Modified: 2012-08-25 17:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Winship 2009-09-01 15:11:58 UTC
Right now nm-connection-editor only shows the IPv6 page for ethernet and wifi connections.

IPv6 over PPP apparently exists (RFC 5072), but I don't know how widely supported it is, or if it's supported by the mobile broadband profile of PPP, or if any mobile broadband providers actually implement it.

IPv6 over VPN obviously exists in the context of IPSEC... It looks like openvpn currently has marginal IPv6 support, and I can't figure out about vpnc. It's probably the case that some VPNs support it and some don't. It might be good for nm-connection-editor to be able to query the plugin somehow, and only show the IPv6 page when relevant (although the plugin might not be able to know until it actually authenticates to the server, so maybe it has to just be figured out at runtime).


The current NM IPv6 code probably uses device->iface and device->ip_iface inconsistently in ways that will break with ppp and vpn, because I didn't notice the distinction until after I'd already written most of it. However, there's another problem here anyway, which is that nm_ip6_manager_prepare_interface() has to be called on an interface before the interface is brought up (to disable kernel addrconf if the config requires that), which I'm not sure is possible in the ppp/vpn case where (as I understand it) a device gets created on the fly. So anyway, something will have to happen there.
Comment 1 David Woodhouse 2009-11-11 15:07:17 UTC
Why do you say that openvpn's IPv6 support is 'marginal'? It's all there, isn't it?

VPNC doesn't yet have IPv6 support, although it could. OpenConnect does, and it's in active use at berkeley.edu -- it would be good to get NM working with it.

On ppp and tunnel interfaces, you don't get address autoconf -- so does it matter that we don't call nm_ip6_manager_prepare_interface() ?

We _can_ create the device under our own control, anyway; we don't have to let the VPN dæmon itself do that "on the fly". Take a look at how openconnect manages to run as non-root -- we create the 'vpn0' tun interface in advance, then chown it to the nm-openconnect user, and invoke openconnect as that user.
Comment 2 Dan Winship 2009-11-11 16:13:58 UTC
(In reply to comment #1)
> Why do you say that openvpn's IPv6 support is 'marginal'? It's all there, isn't
> it?

Googling for "openvpn ipv6" turns up things like the OpenVPN FAQ saying "Currently, there's limited support for IPv6" and a separate repo on github (http://github.com/jjo/openvpn-ipv6) where more work seems to be happening. I didn't investigate in detail. Looking more carefully now it seems like perhaps IPv6-over-OpenVPN works, but OpenVPN-over-IPv6 does not?

> On ppp and tunnel interfaces, you don't get address autoconf -- so does it
> matter that we don't call nm_ip6_manager_prepare_interface() ?

Ah. In that case, no (although there still may be issues with the code using dev->iface where it should be using dev->ip_iface, or vice versa).

I assume configuration of the IPv6 addresses is still "automatic" from the end user's point of view, it's just that it happens via PPP/VPN options rather than via the standard IPv6 addrconf mechanism?
Comment 3 David Woodhouse 2009-11-12 00:47:38 UTC
Right, IPv6-over-OpenVPN has been working for a long time, and that's what we're interested in.

And yes, the configuration of IPv6 addresses will happen in exactly the same way that configuration of IPv4 addresses happens -- so that will still be mostly "automatic" as far as the end-user is concerned. For PPP it'll be handled by pppd, for openconnect/vpnc by the VPN client, and I'm not entirely sure about how openvpn does it.

Looking at the existing SetIp4Config method which the VPN service implementation calls... do you really want to add a separate SetIP6Config method, or should we add IPv6 information to the existing method (and probably rename it)?

You really don't want me to tell you about the IPv6 nameserver and the Legacy IP nameserver in _separate_ callbacks, do you? When you just need to add both of them side-by-side in /etc/resolv.conf regardless of their protocol family?
Comment 4 Felix Yan 2010-07-01 09:53:13 UTC
Openvpn over IPv6 has been working for some time, and I often use it using cli, could the feature be added into NetworkManager?
Comment 5 Dan Williams 2010-07-16 20:24:39 UTC
It can very well be added, is anyone willing to help out with a patch?
Comment 6 Peter Robinson 2011-10-31 11:52:10 UTC
I'm interested in IPv6 over PPPoE & PPP wwan connections. Is this on the roadmap at all?
Comment 7 Dan Williams 2011-11-02 17:37:58 UTC
Yeah it's on the roadmap, there are notes in the TODO file in git about adding IPv6 support for VPN connections (see VPN IP Methods) that could be used as a guide if somebody gets to it before me or others.
Comment 8 Bernhard Schmidt 2012-03-28 19:05:20 UTC
(In reply to comment #3)
> Right, IPv6-over-OpenVPN has been working for a long time, and that's what
> we're interested in.

JFTR, OpenVPN 2.3 is on the horizon which will support both IPv6 transport and IPv6 payload in the vanilla source. Also my university has started assigning IPv6 to VPN users in the Cisco Anyconnect VPN, which is supported quite well by the openconnect client. But not in NM unfortunately.
Comment 9 David Woodhouse 2012-03-28 20:00:24 UTC
(In reply to comment #8)
> Also my university has started assigning IPv6 to VPN users in the Cisco 
> Anyconnect VPN, which is supported quite well by the openconnect client.
> But not in NM unfortunately.

As you say, OpenConnect supports IPv6 quite well. I think there's a bug open for NetworkManager's lack of IPv6 support with OpenConnect (or indeed any VPN?). If not, please file one.
Comment 10 Bernhard Schmidt 2012-03-28 21:53:39 UTC
I thought this was the bug .-)

I haven't found anything else, I'll file an appropriate bug report for openconnect+IPv6 in the next few days.
Comment 11 David Woodhouse 2012-03-28 22:09:37 UTC
Maybe it was; sorry. I was looking at the 'ppp' in the subject and vaguely seemed to remember there was a separate one specifically for openconnect.
Comment 12 Dan Winship 2012-04-04 16:59:10 UTC
So.. I guess add NM_VPN_PLUGIN_UI_CAPABILITY_IPV6 to NMVpnPluginUiInterface, and the editor can add the page if it's set? Forcing it to be opt-in seems best, since otherwise we'd have no way to give an error if the user tried to configure IPv6 on a VPN backend that didn't support it yet.
Comment 13 Dan Winship 2012-05-18 13:50:02 UTC
i'm working on vpn now
Comment 14 David Woodhouse 2012-05-18 14:23:58 UTC
I have provided an openconnect account with IPv6. I can provide an L2TP account with IPv6 *and* DHCPv6+PrefixDelegation for PPP testing, although there's a little bit more work to bring something like http://mail.gnome.org/archives/networkmanager-list/2011-January/msg00089.html  up to date.

I can also occasionally test ADSL and 3G connectivity with exactly the same PPP setup (both IPv6 and Legacy IP on the PPP, with DHCPv6+PD).
Comment 15 Peter Robinson 2012-05-18 14:27:08 UTC
I can test IPv6 with ADSL/PPPoE.
Comment 16 Dan Winship 2012-05-30 19:51:41 UTC
IPv6 VPN support has been merged to NetworkManager and network-manager-openconnect master. Other plugins still need to be updated.
Comment 17 Pavel Simerda 2012-08-24 14:38:00 UTC
Could you please start bugs for individual plugins and close this one?
Comment 18 Dan Winship 2012-08-24 16:41:14 UTC
done
Comment 19 Peter Robinson 2012-08-25 17:17:08 UTC
(In reply to comment #18)
> done

Can you link the individual bugs here too so they might be easily found?