Is the current situation good enough? In the procps package, the default
is still "2". Image deployments change that as Scott described in
comment #23 (but that was 3y ago, might have changed). I don't know how
server installs using the text mode installer behave, it's been a while
since I last
Is the current situation good enough? In the procps package, the default
is still "2". Image deployments change that as Scott described in
comment #23 (but that was 3y ago, might have changed). I don't know how
server installs using the text mode installer behave, it's been a while
since I last
Hi Christian. Some comments/corrections:
1) On servers privacy extensions are *not* always enabled. As I pointed
out in comment #24, if NM is not in use, privacy extensions are only
enabled for userspace-created interfaces such as "vlan123". It is *not*
enabled by default for physical interfaces
Thanks Tore for checking so much Details and all the relations to
NetworkManager it might have on a Desktop.
On a server (no NM) I'd think it is always enabled i'd think.
But if that is a bug or not is a"discussion".
Just as much as users want it off (here) others want it on - see bug 176125 and
In case anyone's interested in knowing why setting
net/ipv6/conf/all/use_tempaddr=2 no longer changes the value of pre-
existing interfaces (thus ensuring privacy extensions are disabled by
default for physical interfaces configured through
/etc/network/interfaces), it's because
Correction to my previous comment: "disable_ipv6" should of course have
read "use_tempaddr" throughout, except for the part about NM bouncing
the disable_ipv6 sysctl.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The situation appears to have improved somewhat in Xenial. The
net/ipv6/conf/all/disable_ipv6 sysctl appears to have become a no-op in
recent kernels, so when 10-ipv6-privacy.conf gets applied during the
bootup sequence (by systemd-sysctl.service) it does *not* change the
effective per-device
** Tags added: trusty
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1068756
Title:
IPv6 Privacy Extensions enabled on Ubuntu Server by default
To manage notifications about
** Tags added: trusty
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1068756
Title:
IPv6 Privacy Extensions enabled on Ubuntu Server by default
To manage notifications about this bug go to:
ok. so some updates.
Ben fixed this in the cloud image build process via [1] (commit [2]), and
limited the change to utopic+.
The fix was done by adding a file /etc/sysctl.d/99-cloudimg-ipv6.conf
The problem with this change is described in bug 1352255 and bug
994931. If ipv6 addresses are
ok. so some updates.
Ben fixed this in the cloud image build process via [1] (commit [2]), and
limited the change to utopic+.
The fix was done by adding a file /etc/sysctl.d/99-cloudimg-ipv6.conf
The problem with this change is described in bug 1352255 and bug
994931. If ipv6 addresses are
interestingly enough, modifying the privacy settings via sysctl has some
negative affects if addresses are already up. see diagnosis in bug
1377005 .
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
interestingly enough, modifying the privacy settings via sysctl has some
negative affects if addresses are already up. see diagnosis in bug
1377005 .
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Just to document additional support. I concur that on a Server install,
PE should disabled by default. A server doesn't fall into the use case
of needing to protect the privacy of the user. It is meant to be known,
not obfuscated.
--
You received this bug notification because you are a member
Just to document additional support. I concur that on a Server install,
PE should disabled by default. A server doesn't fall into the use case
of needing to protect the privacy of the user. It is meant to be known,
not obfuscated.
--
You received this bug notification because you are a member
marked this 'triaged' in cloud-init while still not really relevant.
Ben Howard has disabled the privacy extensions in cloud images in 14.10, and
the plan is to just do the same for 14.04.
** Changed in: cloud-init (Ubuntu)
Status: New = Triaged
** Changed in: cloud-init (Ubuntu)
marked this 'triaged' in cloud-init while still not really relevant.
Ben Howard has disabled the privacy extensions in cloud images in 14.10, and
the plan is to just do the same for 14.04.
** Changed in: cloud-init (Ubuntu)
Status: New = Triaged
** Changed in: cloud-init (Ubuntu)
Disabled IPv6 privacy extensions for Ubuntu 14.10 via /etc/sysctl.d. I
would be in favor of making this a default for 14.04 as well.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
Disabled IPv6 privacy extensions for Ubuntu 14.10 via /etc/sysctl.d. I
would be in favor of making this a default for 14.04 as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1068756
Title:
given RFC4941 SHOULD (RFC capitalisation) be turned off by default above, and
the general lack of value of privacy extensions being enabled on a server or
cloud geust, i really think we should:
a.) turn off privacy extensions on cloud-images for 14.10+
b.) look for a way to disable them by
given RFC4941 SHOULD (RFC capitalisation) be turned off by default above, and
the general lack of value of privacy extensions being enabled on a server or
cloud geust, i really think we should:
a.) turn off privacy extensions on cloud-images for 14.10+
b.) look for a way to disable them by
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1068756
Title:
IPv6 Privacy Extensions enabled on
Neil: the metadata is just one example (though that's not happening).
The firewall rule thing applies irrespective of the metadata. The cloud
environment created requires only /128 addresses it knows about to be
accessible, and firewalls everything else out. Reasons for this include
prevention of
There's no problem with using it in an IPv6 environment if you use
IPv6 prefix mechanisms as designed
If you've tied down your cloud environment too tight (and technically
contra the spec - IPv6 is prefix based, not address based) then you
have to expect to make alterations to the standard
This affects 14.04 too
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1068756
Title:
IPv6 Privacy Extensions enabled on Ubuntu Server by default
To manage notifications about
That doesn't work if (for instance) you have 2 machines on the same SDN
virtual LAN, which is a /64, and you want to prevent source spoofing
between them. For avoidance of doubt, we do use /64s.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
I would suggest that is a design flaw in your network - which is
working in an IPv4 manner, not an IPv6 one. You should have used a
prefix smaller than /64
The problem here is with the network design, not the image.
On 4 June 2014 14:40, Alex Bligh ubu...@alex.org.uk wrote:
That doesn't work if
In my view this is NOT a software bug, its an OS bug.
Here's a completely different why this causes problems.
We use Ubuntu UEC images. There are no meaningful privacy considerations
here because we generate both the MAC address and the IP address of the
servers concerned. IE, if the machine is
The metadata request on IPv6 should ask to use the global address on
outgoing connection. If it did, then the firewall rule would work, the
metadata obtained and that can turn off the temporary address
mechanism if that is what you want.
Badly coded applications should be fixed to work properly
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1068756
Title:
IPv6 Privacy Extensions enabled on Ubuntu Server by
Neil: the metadata is just one example (though that's not happening).
The firewall rule thing applies irrespective of the metadata. The cloud
environment created requires only /128 addresses it knows about to be
accessible, and firewalls everything else out. Reasons for this include
prevention of
There's no problem with using it in an IPv6 environment if you use
IPv6 prefix mechanisms as designed
If you've tied down your cloud environment too tight (and technically
contra the spec - IPv6 is prefix based, not address based) then you
have to expect to make alterations to the standard
That doesn't work if (for instance) you have 2 machines on the same SDN
virtual LAN, which is a /64, and you want to prevent source spoofing
between them. For avoidance of doubt, we do use /64s.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This affects 14.04 too
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1068756
Title:
IPv6 Privacy Extensions enabled on Ubuntu Server by default
To manage notifications about this bug go to:
I would suggest that is a design flaw in your network - which is
working in an IPv4 manner, not an IPv6 one. You should have used a
prefix smaller than /64
The problem here is with the network design, not the image.
On 4 June 2014 14:40, Alex Bligh ubu...@alex.org.uk wrote:
That doesn't work if
RFC 4941:
The use of temporary addresses may cause unexpected difficulties with
some applications.
...
Consequently, the use of temporary addresses SHOULD be disabled by
default in order to minimize potential disruptions.
--
You received this bug notification because you are a
From 'include/linux/in6.h'
/* RFC5014: Source address selection */
#define IPV6_ADDR_PREFERENCES 72
#define IPV6_PREFER_SRC_TMP 0x0001
#define IPV6_PREFER_SRC_PUBLIC 0x0002
#define IPV6_PREFER_SRC_PUBTMP_DEFAULT 0x0100
#define IPV6_PREFER_SRC_COA 0x0004
I can confirm all of the security addresses by default are marked
Global. There is no application level workaround for this.
$ ifconfig eth0 | awk '/inet6/ {print $1,$2,ipv6addr,$4}'
inet6 addr: ipv6addr Scope:Global
inet6 addr: ipv6addr Scope:Global
inet6 addr: ipv6addr Scope:Global
inet6 addr:
No the IPv6 system prefers privacy addresses over standard addresses if not
explicitly told otherwise.
Server *userspace software* should tell the system explicitly what it wants
to do so that clients can connect to it.
The problem is with the userspace software, not the IPv6 configuration. It
Neil Wilson n...@aldur.co.uk writes:
No the IPv6 system prefers privacy addresses over standard addresses if not
explicitly told otherwise.
Server *userspace software* should tell the system explicitly what it wants
to do so that clients can connect to it.
You keep asserting this but don't
I don't think you are correct. Here's why: the comments in the file
mentioned in my original bug report (of which I actually included the
full contents of the file) state the following:
'2 - prefer privacy addresses and use them over the normal addresses.'
Heavy emphasis on the word prefer.
That's a bug in the software - not the server system. If the software
requires a global source address to work, then it should ask for one when
doing the bind or provide an option to do so.
If it doesn't do that then that is a buggy IPv6 implementation and should
be reported as such.
The problem
The problem is that by default pieces of software will use that address
when communicating over IPv6. Such as wget downloading a file over IPv6
or connecting to a system using SSH.
This should absolutely not be the default for a server system.
-Tim
--
You received this bug notification because
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: procps (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1068756
Title:
Although I sympathise with the sentiments in this bug, the real problem
is that the application is not implementing the address selection
process indicated in RFC 5014.
When an application opens a socket it can indicate that it requires the
public address.
If you find an application that fails
45 matches
Mail list logo
