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 679512 - Support IPv6to4
Support IPv6to4
Status: RESOLVED DUPLICATE of bug 641194
Product: NetworkManager
Classification: Platform
Component: general
0.9.x
Other All
: Normal enhancement
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2012-07-06 12:06 UTC by Olav Vitters
Modified: 2012-07-27 16:52 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Olav Vitters 2012-07-06 12:06:23 UTC
ifcfg can setup an IPv6to4 tunnel like the following:
  IPV6INIT=yes
  IPV6TO4INIT=yes
  IPV6TO4_IPV4ADDR=62.195.84.29

It would be nice if NetworkManager had native support for this. Meaning: I don't want it to parse ifcfg-eth0 or anything, just support the IPv6to4 functionality.

Note that I am behind a router, would be nice if NetworkManager could automatically figure out the correct IPv4 address, but not needed (configuration setting).
Comment 1 Pavel Simerda 2012-07-26 13:09:22 UTC
Although 6to4 has not been finally deprecated, it is not as important as it used to be.

I don't see any valid use cases for NetworkManager's 6to4 support for the following reasons:

1) 6to4 requires a public IPv4 address. Public IPv4 is not generally available
at hotspots and cafes. Therefore it's virtually useless for nomadic users.

2) 6to4 is typicall supported by the local router for the whole LAN. Although
NetworkManager includes limited support for routing, it is not intended to
be used as a router solution. It's preferable to have an IPv6 router.

3) In serverhouse, AFAIK you can usually get an IPv6 address.

You can still use whatever you already used for experimenting.

Keeping open for other developers' opinions.
Comment 2 Olav Vitters 2012-07-26 22:01:59 UTC
I know the number of people who might use this is small.

My reason is twofold:
1. Ensuring that NetworkManagers feature set is greater than 'ifcfg'
   In detail: I'm a Mageia packager. I prefer if Mageia would use NetworkManager for everything. Currently we have our own tool which conflicts with NetworkManager. If we'd switch from that anyway, it would be easier to only support NetworkManager (even in case of servers).
2. Fun for playing around
   I might get an actual IPv6 address somewhere this year. But that has been promised for years now. This functionality allows me to play around with IPv6 without having to wait for ISP. It is also dead simple to setup (no need to setup tunnels, etc). My IPv4 address very infrequently (way less than once per 2 years).

Regarding your points:
1. Agree.
2. My ISP (millions of customers) has a combined cable modem/router thing. It doesn't do 6to4. :-(
3. Don't think you'd want 6to4 for a server. Getting an IPv6 address is not super easy btw. Red Hat NOC is not planning on IPv6 any time soon. Meaning: most of *.gnome.org cannot run on IPv6. Fedora uses 6to4 + tunnels for their IPv6 setup, but IMO that is ugly (traffic might be routed in weird ways).

Using exist thing: That means disabling NetworkManager and going back to ifcfg. I only want to use NetworkManager (advocacy reasons).


Btw, I know that the priority is low.. I like 6to4 as it allows me to play around. Still, if it is possible to add such support with a few hours of work, then I'd really appreciate!
Note: I have no clue how much work this is.. plus lack knowledge to help.
Comment 3 Pavel Simerda 2012-07-26 23:45:12 UTC
> if it is possible to add such support with a few hours of work,
> then I'd really appreciate!

I'm sorry to say that, but speaking for myself the priority would
be “patches welcome”. Keeping open anyway.
Comment 4 Pavel Simerda 2012-07-27 16:52:18 UTC
6to4 is actually a special configuration of 6in4. And 6in4 (including 6to4) is probably in much wider use and will stay that, I'm merging.

*** This bug has been marked as a duplicate of bug 641194 ***