Bug 583409 - IPv6 aliases are not implemented
Summary: IPv6 aliases are not implemented
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-18 12:01 UTC by udo
Modified: 2014-03-17 03:23 UTC (History)
8 users (show)

Fixed In Version: initscripts-9.29-1.fc15
Clone Of:
Environment:
Last Closed: 2012-01-05 21:37:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch for ifup-aliases to also bring up IPv6 if IPV6ADDR or IPV6ADDR_SECONDARIES is set (517 bytes, patch)
2011-06-04 13:14 UTC, Stefan Neufeind
no flags Details | Diff

Description udo 2010-04-18 12:01:58 UTC
Description of problem:
IPv6 aliases are not implemented; in ifup-ipv6 we see:
# IPv6 don't need aliases anymore, config is skipped
REALDEVICE=$(echo ${DEVICE} | sed 's/:.*//g')
[ "$DEVICE" != "$REALDEVICE" ] && exit 0

I think we DO need them. When using IPv6 we want to use IPV6_PRIVACY=rfc3041. In that case however the box gets a different number once in a while. This makes it hard to run services on the same box (behind the firewall).
So we want an rfc3041 number for surfing but a steady number for services we run.
This was not taken in account when someone commented: `IPv6 don't need aliases anymore`. That is obviously a false statement, expressly because we have so many more numbers and so many more privacy and security threats that we need those numbers for.

Version-Release number of selected component (if applicable):
initscripts-9.02.1-1.x86_64

How reproducible:
Install Fedora 12. 

Steps to Reproduce:
1. Configure alias interface
2. Bring up interface
3. See failure to do so.
  
Actual results:
No alias.

Expected results:
Alias.

Additional info:

Comment 1 Bill Nottingham 2010-04-19 16:44:03 UTC
... how does IPV6ADDR_SECONDARIES not work for you?

Comment 2 udo 2010-04-19 16:52:06 UTC
Does that combine with https://bugzilla.redhat.com/show_bug.cgi?id=583441 ?
I mean: can I add one IPv6-number 'normally' autoconfigured with RFC3484 and add another autoconf number with just IPV6_PRIVACY=rfc3041 as special feature to the very same interface?

@@ -167,6 +167,11 @@
        done
 fi

+if [ "$IPV6_RFC3484" = "yes" ]; then
+       ipv6addrlocalrfc="$(ipv6_get_ipv6addr_of_device $DEVICE)"
+       /sbin/ip -6 addr change "$ipv6addrlocalrfc" dev "$DEVICE" preferred_lft 0
+fi
+
 # Setup of 6to4, if configured
 if [ "$IPV6TO4INIT" = "yes" ]; then
        valid6to4config="yes"

Comment 3 udo 2010-08-12 13:57:23 UTC
IPV6ADDR_SECONDARIES does just add a number; I would like to add IPV6_PRIVACY=rfc3041 to one specific interface as well.
I.e.: have one number with the privacy.
Have another, auto configured, number with RFC3484.

How do I combine all that in Fedora 13?

Comment 4 udo 2010-08-12 14:02:30 UTC
Since IPV6_PRIVACY=rfc3041 is per device I might need an alias anyway...

Comment 6 udo 2011-03-31 15:05:01 UTC
Thanks, I'll test!

Comment 7 Fedora Update System 2011-04-06 20:32:05 UTC
initscripts-9.29-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/initscripts-9.29-1.fc15

Comment 8 Fedora Update System 2011-04-07 02:20:51 UTC
Package initscripts-9.29-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing initscripts-9.29-1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/initscripts-9.29-1.fc15
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2011-04-15 21:13:30 UTC
initscripts-9.29-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Stefan Neufeind 2011-06-04 13:04:43 UTC
Using Fedora 15, initscripts-9.30-2.fc15.x86_64 here - so that incorporates the above mentioned patch.

Test scenario:
* normal ifcfg-lo
* additional ifcfg-lo:1 with following content:

DEVICE=lo:1
IPADDR=127.0.0.2
NETMASK=255.0.0.0
NETWORK=127.0.0.0
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback
IPV6INIT=yes
IPV6ADDR=::2/64
IPV6FORWARDING=no
IPV6_AUTOCONF=no

Trying to "ifdown lo; ifup lo" with that.

IPADDR here is needed since otherwise the scripts complain lo:1 does not contain an IPADDR (in ifup-aliases). Well okay, so we give it the above mentioned IPADDR for now. But that doesn't bring up the IPV6ADDR given.

With the above mentioned patch you can now "ifup-ipv6 lo:1" which brings up the IPV6ADDR. But it's attached to "lo" not "lo:1" ... depends on your view if this is correct or not. (I'd favour/suggest to have it on lo:1)

But the point is that ifup-aliases doesn't bring up the IPV6ADDR automatically (not calling ipup-ipv6). The IPv4-address is added to an interface directly inside ifup-aliases.

Suggestion: Would you agree to call ifup-ipv6 from within ifup-aliases maybe? Maybe we could even split out the IPv4-initialisation into an ifup-ipv4 as well.

Comment 11 Stefan Neufeind 2011-06-04 13:14:21 UTC
Created attachment 502987 [details]
Patch for ifup-aliases to also bring up IPv6 if IPV6ADDR or IPV6ADDR_SECONDARIES is set

Still needs a set IPADDR, since that is used in ifup-aliases "all over the place". But at least it makes IPv6 work for subinterfaces.

Comment 12 udo 2011-06-04 13:41:52 UTC
How can I test while running Fedora 14 where the bug was filed against?
I agree with Stefan that lo:1 is preferred as that is a different interface, right? This means we can use rfc3041 on that interface I hope.

Also the need for IPADDR should be removed.
So how can this bug be closed? Work is still needed.

Comment 13 Bill Nottingham 2011-06-06 19:30:34 UTC
(In reply to comment #10)
> Suggestion: Would you agree to call ifup-ipv6 from within ifup-aliases maybe?
> Maybe we could even split out the IPv4-initialisation into an ifup-ipv4 as
> well.

Ick, no - the idea is to eventually get all the weirdness from ifup-ipv6 into the normal path so we don't maintain multiple separate infrastructures.

In any case, will attach an updated version of your patch.


Note You need to log in before you can comment on or make changes to this bug.