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 615063 - Support IPv6 ULAs
Support IPv6 ULAs
Status: RESOLVED NOTABUG
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2010-04-07 14:37 UTC by Fabian Deutsch
Modified: 2010-10-01 09:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ULA by example - Problem and solution (2.93 KB, text/plain)
2010-04-12 16:57 UTC, Fabian Deutsch
Details

Description Fabian Deutsch 2010-04-07 14:37:36 UTC
Beside the current support for IPv6 dhcp, manual and link-local it would be good to have tsupport for unique local addresses [1].
They seem to be the IPv6 pendant for IPv4 private networks.


--
[1] http://en.wikipedia.org/wiki/Unique_local_address
Comment 1 Dan Williams 2010-04-08 19:10:01 UTC
Is the current behavior of the kernel automatically assigning an IPv6 Link-Local address when the interface is brought up not sufficient?  I thought those link-scope addresses were the same thing as the ULA ones.  If not, then the standards here are really, really weird since these two appear to do the same thing.

Basically, if we're talking about IPv6 LL addresses, then that's already handled for us by the kernel whenever the interface is brought up, independent of NetworkManager.
Comment 2 Fabian Deutsch 2010-04-08 19:44:58 UTC
First: I am no IPv6 expert.

ULA addresses are different from LL.
LL addresses can not be routed. 

It seems as if the kernel assigns LL addresses, not ULA:
inet6 Adresse: fe80::20d:60ff:fe2e:ffba/64

LL-Prefix: fe80
ULA-Prefix: fc00, fd00

I thought it would solve the following problem (which is unpractical and weird for newbies): You need to specify a interface if you use ping6.

# ping6 -I eth0 ahost.local

or

# ping6 ahost.local%eth0

But as I tried, even using ULA do not solve this :-/

Anyway: Is this behavior seen as a problem by others?
Comment 3 Fabian Deutsch 2010-04-12 16:42:17 UTC
So, I asked some people on irc://irc.freenode.net/#ipv6 and the recommendation for IPv6 addresses comparable to IPv4 private networks was to use ULAs as mentioned above.

An easy way to reproduce the current problem:

1. Install Fedora 12
2. Make sure IPv6 is activated for eth0
3. sudo ifconfig eth0
...
inet6 addr: fe80::217:f2ee:ae32:3d8/64 Scope:Link
...

4. Get a second computer and do steps 1-3, you should have a different part behind ::, but the same prefix: fe80 (link-local)

5. On both computers try to ping6 each other.
   This should not work, you will get the error:

# ping6 IPV6-OF-OTHER-HOST
connect: Network is unreachable

   To prevent this error use:

# ping6 IPV6-OF-OTHER-HOST%eth0
connect: Network is unreachable

This is ... not very handy, to specify an interface when trying to reach a computer on the lan.

The solution, use ULAs:
1. The above steps 1-4
2. Remove the link-local address on both computers:
# ifconfig eth0 del fe80::REST-OF-IP/64
3. Add the ULA address on both computers:
# ifconfig eth0 add fd00::REST-OF-IP/64
4. ping6 each other. The ping should work.
Comment 4 Fabian Deutsch 2010-04-12 16:57:25 UTC
Created attachment 158505 [details]
ULA by example - Problem and solution
Comment 5 Dan Williams 2010-04-23 20:07:54 UTC
I knew about Site-Local, hadn't realized they'd gotten renamed a while back to ULA.  So yeah, there's LL (only for your local link/ethernet loop/whatever) and  then site-local which can be routed, just not into the actual internet.

Link-local and site-local should be available all the time if desired, while routable address methods are mutually exclusive.  So that probably means some checkboxes on the IPv6 page to separately enable LL and UL addresses, then the dropdown to select between [ Auto (RA + DHCP), DHCP Only, Local only, Shared ].
Comment 6 Fabian Deutsch 2010-04-24 13:36:06 UTC
Section "4.6 Use of Local IPv6 Addresses for Local Communication" of RFC 4193 states:

"""
  Local IPv6 addresses, like global scope unicast addresses, are only
   assigned to nodes if their use has been enabled (via IPv6 address
   autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually).  They are
   not created automatically in the way that IPv6 link-local addresses
   are and will not appear or be used unless they are purposely
   configured.
"""

So doesn't this mean, that why can not automatically (so at boot time) enable ULA, because it is not intended in such a way?

A method named "manual - Site local (ULA)" might be a good way to present this method to the user. If this method is selected, an ULA get's added to the list of addresses.

In the Auto and DHCP case, the correpsonding router would have assigned a ULA.
Comment 7 Charles R. Anderson 2010-08-08 15:40:18 UTC
Right, ULAs won't be useful unless every host in the same administrative domain (site, org, whatever) uses the same ULA prefix.  This can be coordinated manually, or via DHCPv6 or RA.  In fact, I don't see why ULA needs to be treated specially by NM, because it is just another address that you can get either automatically or set manually.  You can already add multiple IPv6 addresses manually in the Connection Editor and for the other cases I don't see why NM (or the kernel) wouldn't take a ULA that comes from DHCPv6 (or an RA) and install it as usual, although I haven't tested it.
Comment 8 Fabian Deutsch 2010-10-01 09:12:03 UTC
Yes, Okay.

In my eyes it is still not a user friendly setup, when having link-local addresses. But this might not be the problem of NM.
I'm closing this.