IPv6 Stable Private Addresses RFC 7217

[Roy Marples]

Hi List

The next dhcpcd release will have support for IPv6 Stable Private
Addresses, RFC 7217.
http://wiki.netbsd.org/projects/project/ipv6-stable-privacy-addresses/
http://tools.ietf.org/html/rfc7217

In summary, this is designed as a replacement interface identifier for
the normal hardware derived one when using SLAAC.
By storing a persistent secret key and combing this with stable network
information such as prefix, ssid (if available), hardware address and a
dad_counter we can then take an interface identifier from a hash of the
above information combined.

The most basic goal is that the host is no longer track-able across
different networks based on their global address, but the address
remains stable on each network.

My question is this: should this be enabled by default as privacy is a
good thing, or should the normal hardware based address be kept?

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Loganaden Velvindron]

Post by Roy Marples
Hi List
The next dhcpcd release will have support for IPv6 Stable Private Addresses,
RFC 7217.
http://wiki.netbsd.org/projects/project/ipv6-stable-privacy-addresses/
http://tools.ietf.org/html/rfc7217

So it's a userland implementation if I understand correctly ?

No plans for a kernel-based implementation ?

Post by Roy Marples
In summary, this is designed as a replacement interface identifier for the
normal hardware derived one when using SLAAC.
By storing a persistent secret key and combing this with stable network
information such as prefix, ssid (if available), hardware address and a
dad_counter we can then take an interface identifier from a hash of the
above information combined.
The most basic goal is that the host is no longer track-able across
different networks based on their global address, but the address remains
stable on each network.
My question is this: should this be enabled by default as privacy is a good
thing, or should the normal hardware based address be kept?
Thanks
Roy

[Roy Marples]

Post by Loganaden Velvindron

Post by Roy Marples
Hi List
The next dhcpcd release will have support for IPv6 Stable Private Addresses,
RFC 7217.
http://wiki.netbsd.org/projects/project/ipv6-stable-privacy-addresses/
http://tools.ietf.org/html/rfc7217

So it's a userland implementation if I understand correctly ?

Yes

Post by Loganaden Velvindron
No plans for a kernel-based implementation ?

No. Why would you want it in the kernel?
Part of it needs to be userland anyway, to create, store and re-use the
host secret key.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Roy Marples

Post by Loganaden Velvindron
So it's a userland implementation if I understand correctly ?

Yes

Post by Loganaden Velvindron
No plans for a kernel-based implementation ?

No. Why would you want it in the kernel?

Because if it's not, if anyone ever tries to do netboot or diskless
operation over IPv6, the host's address may suddenly change once userland
is running?

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Thor Lancelot Simon

Post by Roy Marples

Post by Loganaden Velvindron
So it's a userland implementation if I understand correctly ?

Yes

Post by Loganaden Velvindron
No plans for a kernel-based implementation ?

No. Why would you want it in the kernel?

Because if it's not, if anyone ever tries to do netboot or diskless
operation over IPv6, the host's address may suddenly change once userland
is running?

Surely a diskless host should be able to cope with address changes? I
mean, changing address via DHCPv4 is neither new nor rocket science.

This is quite important, because if another host somehow picks the same
interface identifier as our host then the host in conflict will increase
the dad_counter and generate a different interface identifier. So given
this, it's impossible to guarantee a 100% stable address unless you
manage every piece of your network which is something the software just
doesn't know.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

Surely a diskless host should be able to cope with address changes? I mean, changing address via DHCPv4 is neither new nor rocket science.

The issue would arise if you were using IP addresses to authenticate your NFS mounts. I haven't followed the state of the art in NFS for a long time, so I don't know if this is still required, but it certainly was back when I used to use it, and there's a PR for dhclient that remains unaddressed that has to do with this issue.

The right way to fix it is definitely to use a different authentication mechanism that is robust in the face of IP address changes.

If you want the same behavioral traits as IPv4 then at a guess you would need to make IN6_IFF_NODAD assignable from userland (currently it's rejected).
I'm not entirely sure that's a good idea though.

As a general rule, if you want the behavior traits of IPv4, the best way to get them is to use IPv4. Trying to make IPv6 look like IPv4 because of some IPv4 behavior to which one is accustomed is generally not a good idea, because you are likely to break something in the process.

That said, there are unaddressed problems with respect to server numbering for IPv6 in the presence of DAD, as well as in the presence of prefix deprecation during renumbering.

The DAD problem is that if a server is supposed to have address MY_PREFIX::1, and some other device on the network claims that address, the server ought to win, because its address is no doubt published in the DNS, and isn't suitable for changing.

This is related to the renumbering problem: you have a host that you want to be reachable using a particular domain name, but numbering on your network is not guaranteed to be stable: you are subject to renumbering from your ISP, or when switching ISPs. You'd like the host's AAAA record to change when it's renumbered. Right now there's no way to do this.

Addressing this problem by providing a mechanism for updating the DNS automatically when DAD fails or when you get renumbered would be a win. However, DNS doesn't guarantee freshness for updates that occurred more recently than the TTL on the record, so this still doesn't really solve the DAD problem--it just mitigates it somewhat. To solve it you need something like SAVI on your switches, so that they can prevent address stealing. IOW, this is not something you can actually prevent on the host.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Ted Lemon
This is related to the renumbering problem: you have a host that you
want to be reachable using a particular domain name, but numbering on
your network is not guaranteed to be stable: you are subject to
renumbering from your ISP, or when switching ISPs. You'd like the
host's AAAA record to change when it's renumbered. Right now there's
no way to do this.
Addressing this problem by providing a mechanism for updating the DNS
automatically when DAD fails or when you get renumbered would be a
win.

DNS updated could be done via a dhcpcd hook script (similar to
dhclient-script but extended for other things)
However, there isn't a standard means of updating DNS from a host that
I'm aware of otherwise I'd supply one with dhcpcd.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Jun 4, 10:13am, Ted Lemon wrote:
}
} Addressing this problem by providing a mechanism for updating
} the DNS automatically when DAD fails or when you get renumbered
} would be a win. However, DNS doesn't guarantee freshness for
} updates that occurred more recently than the TTL on the record,
} so this still doesn't really solve the DAD problem--it just
} mitigates it somewhat. To solve it you need something like SAVI
} on your switches, so that they can prevent address stealing.
} IOW, this is not something you can actually prevent on the host.

What is SAVI?

}-- End of excerpt from Ted Lemon

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

My question is this: should this be enabled by default as privacy is a good thing, or should the normal hardware based address be kept?

What do stable privacy addresses have to do with DHCP? Otherwise, yes, this should be the default behavior. Nice to see such quick action on a new RFC!


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Ted Lemon

Post by Roy Marples
My question is this: should this be enabled by default as privacy is a
good thing, or should the normal hardware based address be kept?

What do stable privacy addresses have to do with DHCP? Otherwise,
yes, this should be the default behavior. Nice to see such quick
action on a new RFC!

Glad you asked! This has nothing todo with DHCP.

Yes, dhcpcd started out life as a DHCP client, but it's evolved into a
network management daemon over time.
I see DHCP(4/6), IPv4LL and IPv6 SLAAC as part of automatic network
configuration.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

Yes, dhcpcd started out life as a DHCP client, but it's evolved into a network management daemon over time.
I see DHCP(4/6), IPv4LL and IPv6 SLAAC as part of automatic network configuration.

Hm. I'm accustomed to using rtsold for SLAAC, but dhcpcd does seem to do a nicer job. This model of doing everything outside the kernel, rather than doing it automatically in-kernel as Linux does, seems like the right move. I've never loved the in-kernel dhcpv4 client anyway--it seems like an additional attack vector, and bootstrapping with a small in-memory userland which is jettisoned after NFS is running seems like a perfectly cromulent solution to the diskless problem.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

What is SAVI?

Source Address Validation Improvements. It's a mechanism that you can set up in smart switches to track who has what address where, so that devices can't spoof each other, and so that you don't have to do anything manual to make it work.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Roy Marples
In summary, this is designed as a replacement interface identifier
for the normal hardware derived one when using SLAAC.

Replacement or addition? I'm not sure I like removing the normal MAC
derived autoconfig address, but I am certainly fine with having a
separate (non-link local) address. This would be more in line with the
behavior of the privacy extension implementetd in many systems.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

Post by Joerg Sonnenberger
Replacement or addition? I'm not sure I like removing the normal MAC
derived autoconfig address, but I am certainly fine with having a
separate (non-link local) address. This would be more in line with the
behavior of the privacy extension implementetd in many systems.

It's intended by the IETF to be a replacement. The address is meant to be stable, so you don't need some other stable address for receiving connections, the way you would with temporary addresses.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Ted Lemon

Post by Joerg Sonnenberger
Replacement or addition? I'm not sure I like removing the normal MAC
derived autoconfig address, but I am certainly fine with having a
separate (non-link local) address. This would be more in line with the
behavior of the privacy extension implementetd in many systems.

It's intended by the IETF to be a replacement. The address is meant
to be stable, so you don't need some other stable address for receiving
connections, the way you would with temporary addresses.

In that case, enabling it by default would certainly violate POLA.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

Post by Joerg Sonnenberger
In that case, enabling it by default would certainly violate POLA.

Only if you make a habit of statically configuring SLAAC addresses in the DNS. For nearly all uses you don't know what your SLAAC address is, because it's too many digits to memorize (unless you are particularly gifted at that sort of thing).


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Joerg Sonnenberger

Post by Ted Lemon

Post by Joerg Sonnenberger
Replacement or addition? I'm not sure I like removing the normal MAC
derived autoconfig address, but I am certainly fine with having a
separate (non-link local) address. This would be more in line with the
behavior of the privacy extension implementetd in many systems.

It's intended by the IETF to be a replacement. The address is meant
to be stable, so you don't need some other stable address for receiving
connections, the way you would with temporary addresses.

In that case, enabling it by default would certainly violate POLA.

It might, but the automatic MAC-derived addresses can be viewed as a bug
(that seems to be how the privacy extensions people view them), and
turning them off can be viewed as a bug fix. I think the key question
is whether current IETF standards-track documents say that the RFC7217
addresses SHOULD be the default.

[Ted Lemon]

Post by Greg Troxel
I think the key question
is whether current IETF standards-track documents say that the RFC7217
addresses SHOULD be the default.

Not yet, but stay tuned.

http://tools.ietf.org/html/draft-ietf-6man-default-iids-00


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael Richardson]

Post by Greg Troxel

Post by Joerg Sonnenberger

It's intended by the IETF to be a replacement. The address is meant
to be stable, so you don't need some other stable address for
receiving connections, the way you would with temporary addresses.

In that case, enabling it by default would certainly violate POLA.

It might, but the automatic MAC-derived addresses can be viewed as a
bug (that seems to be how the privacy extensions people view them), and
turning them off can be viewed as a bug fix. I think the key question
is whether current IETF standards-track documents say that the RFC7217
addresses SHOULD be the default.

The stable private addresses SHOULD be configured on the interface by
default. The SLAAC addresses MAY be configured on an interface by sysctl,
and I think that for a major release, this shoud be on by default.
Privacy Extensions addresses should also be easily turned on.

The question of which address shoud be used for outgoing connections is
really the question that we are discussing. I'm not even sure how that is
determined these days. And the choice of SLAAC, 7217, privacy extensions,
should probably be settable on a per-application and/or per-user basis.
(Probably, on a process session basis)

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Michael Richardson
The question of which address shoud be used for outgoing connections is
really the question that we are discussing.

Is it? Not for me at least. I am perfectly fine with using a temporary
address (i.e., PE) for the outgoing connections unless requested
differently by a program (think Postfix). I do care about loosing
connectivity to a machine just because I have updated it.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

Post by Joerg Sonnenberger
I do care about loosing
connectivity to a machine just because I have updated it.

You mean having your shell connection broken because you updated dhcpcd, or having your IP address change so that you can't reconnect using the previous address after rebooting?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael Richardson]

Post by Joerg Sonnenberger

Post by Michael Richardson
The question of which address shoud be used for outgoing connections is
really the question that we are discussing.

Is it? Not for me at least. I am perfectly fine with using a temporary
address (i.e., PE) for the outgoing connections unless requested
differently by a program (think Postfix). I do care about loosing
connectivity to a machine just because I have updated it.

Well, I'm saying that we should err on the side of maintaining connectivity.
To me, there is no question there. The question is what address to prefer.
SMTP (Postfix), as you noted, really wants to a stable address which is
in reverse DNS.

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Ted Lemon

Post by Joerg Sonnenberger
I do care about loosing
connectivity to a machine just because I have updated it.

You mean having your shell connection broken because you updated
dhcpcd, or having your IP address change so that you can't reconnect
using the previous address after rebooting?

More the latter case, but the former is the root source.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

Post by Joerg Sonnenberger
More the latter case, but the former is the root source.

So, if you want a stable address, why aren't you configuring one manually?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by Ted Lemon

Post by Joerg Sonnenberger
More the latter case, but the former is the root source.

So, if you want a stable address, why aren't you configuring one manually?

Because I want a central repository of the stable addresses.
My preferred way to use DHCP is for it to give out fixed addresses
to each client, and without a pool of 'spare' addresses.

Even if addresses are allocated from a pool, I want a system to (usually) have
the same address after a reboot. Even when the shutdown sequence gives up
the DHCP lease.

I've had to setup and run my own dhcp server at work (and I had to hack
the ISC source) because the corporate server is so broken.
It wouldn't give a machine back the same IP address after a reboot.

David

[Roy Marples]

Post by David Laight

On Jun 5, 2014, at 2:07 PM, Joerg Sonnenberger

Post by Joerg Sonnenberger
More the latter case, but the former is the root source.

So, if you want a stable address, why aren't you configuring one manually?

Because I want a central repository of the stable addresses.
My preferred way to use DHCP is for it to give out fixed addresses
to each client, and without a pool of 'spare' addresses.
Even if addresses are allocated from a pool, I want a system to (usually) have
the same address after a reboot. Even when the shutdown sequence gives up
the DHCP lease.

What we are talking about here is part of the RA/RS protocol.
DHCP is separate still in IPv6.

The prefix in the RA has a flag to say "create an an automatic address
for this prefix".
This discussion is about changing the hardware element of the address
into a stable private stateless one, generated by the host.
The latest dhcpcd code also uses the same logic to generate stable
private LL addresses as well, provided it beats another operation
bringing the interface up at boot time (like say wpa_supplicant or
ifconfig).

The same RA can also have flags to say obtain an address statefully via
DHCP.
I don't know of a use case where you would want both flags set but it's
possible and dhcpcd allows this.

Post by David Laight
I've had to setup and run my own dhcp server at work (and I had to hack
the ISC source) because the corporate server is so broken.
It wouldn't give a machine back the same IP address after a reboot.

A broken server should not form part of this discussion.
But they are the bane of my life at times.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Fernando Gont]

Hi, Roy,

Post by Roy Marples

Post by David Laight
Even if addresses are allocated from a pool, I want a system to (usually) have
the same address after a reboot. Even when the shutdown sequence gives up
the DHCP lease.

What we are talking about here is part of the RA/RS protocol.
DHCP is separate still in IPv6.
The prefix in the RA has a flag to say "create an an automatic address
for this prefix".
This discussion is about changing the hardware element of the address
into a stable private stateless one, generated by the host.
The latest dhcpcd code also uses the same logic to generate stable

I'm a bit confused. You've implemented RFC7217 for SLAAC, and have also
"ported" the same algrithm to DHCPv6?

Post by Roy Marples
private LL addresses as well, provided it beats another operation
bringing the interface up at boot time (like say wpa_supplicant or
ifconfig).

Would you mind elaborating a bit more on this one?

Thanks!

Best regards,
--
Fernando Gont
e-mail: ***@gont.com.ar || ***@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Fernando Gont
Hi, Roy,

Post by Roy Marples

Post by David Laight
Even if addresses are allocated from a pool, I want a system to (usually) have
the same address after a reboot. Even when the shutdown sequence gives up
the DHCP lease.

What we are talking about here is part of the RA/RS protocol.
DHCP is separate still in IPv6.
The prefix in the RA has a flag to say "create an an automatic address
for this prefix".
This discussion is about changing the hardware element of the address
into a stable private stateless one, generated by the host.
The latest dhcpcd code also uses the same logic to generate stable

I'm a bit confused. You've implemented RFC7217 for SLAAC, and have also
"ported" the same algrithm to DHCPv6?

DHCPv6 doesn't use SLAAC directly.
However, it does rely on a link-local address assigned to the interface
which is SLAAC generated.

Post by Fernando Gont

Post by Roy Marples
private LL addresses as well, provided it beats another operation
bringing the interface up at boot time (like say wpa_supplicant or
ifconfig).

Would you mind elaborating a bit more on this one?

Sure.

When dhcpcd starts up it scans for interfaces it can use.
For each interface it adds the currently known addresses to it.
When dhcpcd decided to start IPv6RS or forced DHCPv6 on an interface it
consults it's list of known address for a link-local address.
If none found, it will add one using SLAAC.
Then it will UP the interface and continue on it's merry way.

BSD kernels will only add a link-local address on UP if none present.
Linux kernels will add one regardless, but actually use the 1st one
assigned (from my testing anyway).
As this is a kernel operation, it's quite possible for another userland
application which UPs the interface to do this before dhcpcd does it.
Because if this, I added a toggle to NetBSD sysctl to stop the kernel
from doing this - other BSD and Linux have the same toggle.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Wed, 02 Jul 2014 00:48:01 +0100
From: Roy Marples <***@marples.name>
Message-ID: <***@mail.marples.name>

| BSD kernels will only add a link-local address on UP if none present.
| Linux kernels will add one regardless, but actually use the 1st one
| assigned (from my testing anyway).

That's weird - do you mean that every time the interface goes down/up
(on a linux system) it generates a new LL addr? Or just that there is one
particular LL addr (probably EUI64 based as a guess) that they believe an
interface just must have, and if that one isn't there, they add it, even if
there's another perfectly good one already existing that they actually use?
Either way looks wrong to me (but the first of those much more wrong than
the second). (That is, the BSD (KAME) way is correct I think.)

| As this is a kernel operation, it's quite possible for another userland
| application which UPs the interface to do this before dhcpcd does it.

Of course, is that some kind of problem?

| Because if this, I added a toggle to NetBSD sysctl to stop the kernel
| from doing this - other BSD and Linux have the same toggle.

I have no problem with the sysctl (is it per interface, or system wide?
or perhaps the ideal solution - both - a system wide default, with per
interface overrides) which (I am assuming) prevents the kernel assigning
a LL addr when the interface comes up) - but I don't understand your use
model.

In fact, I'd normally expect the interface to be up, and a LL addr assigned,
before dhcpcd can possibly start (at least, before it can start doing anything
dhcp related). The LL addr is needed to send an RS to obtain the RA that
indicates whether DHCP should be used or not after all. But I assume for this
the part of dhcpcd that counts is the part that receives and processes RA's,
and I assume sends the RS ? (The general network management role for which
the name dhcpcd is something of an anachronism).

Does it really matter if the LL is already assigned by some other process,
and if there is some other process that needs to use the network (perhaps
part of system booting, loading the kernel / modules (and dhcpcd itself...)
shouldn't it be able to configure the net as it needs it, and then simply
have it left that way? If dhcpcd wants to take over monitoring RA's and
managing prefix changes after, that's OK, it does not need to be involved in
the initial address assignment (either LL or global) for that to happen,
does it?

Further, I cannot see how the sysctl really helps - rather than being used
by dhcpcd it should be something dhcpcd obeys when set by the network
manager, to prevent v6 usage on an interface (or on the whole system).
(There should be a similar one for v4 incidentally.) After all, any
application that knows it needs an addr assigned, can trivially easily
alter the sysctl value if that's what it needs to make things work.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Robert Elz
Date: Wed, 02 Jul 2014 00:48:01 +0100
| BSD kernels will only add a link-local address on UP if none present.
| Linux kernels will add one regardless, but actually use the 1st one
| assigned (from my testing anyway).
That's weird - do you mean that every time the interface goes down/up
(on a linux system) it generates a new LL addr? Or just that there is one
particular LL addr (probably EUI64 based as a guess) that they believe an
interface just must have, and if that one isn't there, they add it, even if
there's another perfectly good one already existing that they actually use?
Either way looks wrong to me (but the first of those much more wrong than
the second). (That is, the BSD (KAME) way is correct I think.)

See here:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/net/ipv6/addrconf.c?id=refs/tags/v3.15.3#n2731
There is no checking if there is already a suitable LL address.

Post by Robert Elz
| As this is a kernel operation, it's quite possible for another userland
| application which UPs the interface to do this before dhcpcd does it.
Of course, is that some kind of problem?
| Because if this, I added a toggle to NetBSD sysctl to stop the kernel
| from doing this - other BSD and Linux have the same toggle.
I have no problem with the sysctl (is it per interface, or system wide?
or perhaps the ideal solution - both - a system wide default, with per
interface overrides) which (I am assuming) prevents the kernel
assigning
a LL addr when the interface comes up) - but I don't understand your use
model.

Per interface with a global default.

Post by Robert Elz
In fact, I'd normally expect the interface to be up, and a LL addr assigned,
before dhcpcd can possibly start (at least, before it can start doing anything
dhcp related). The LL addr is needed to send an RS to obtain the RA that
indicates whether DHCP should be used or not after all. But I assume for this
the part of dhcpcd that counts is the part that receives and processes RA's,
and I assume sends the RS ? (The general network management role for which
the name dhcpcd is something of an anachronism).

You missed the part where dhcpcd adds it's own LL address which is
private
but stable, unlike the hardware derived address the kernel adds.
The kernel has no notation of how to do this, and frankly, nor should it
unless
you're happy with feeding it a private key loaded at boot time.
I would infact argue that too much IPv6 happens in the kernel.

Please read RFC 7217 and understand it's goals before commenting further
as you
seem to have ignored it.

And you are mistaken slightly, RA is not a pre-requisite for DHCPv6.
DHCPv6 has no routing knowledge in the normal use case RA is required,
but when
requesting a prefix delegation you don't need a RA to start DHCPv6.

Post by Robert Elz
Does it really matter if the LL is already assigned by some other process,
and if there is some other process that needs to use the network (perhaps
part of system booting, loading the kernel / modules (and dhcpcd itself...)
shouldn't it be able to configure the net as it needs it, and then simply
have it left that way? If dhcpcd wants to take over monitoring RA's and
managing prefix changes after, that's OK, it does not need to be involved in
the initial address assignment (either LL or global) for that to happen,
does it?
Further, I cannot see how the sysctl really helps - rather than being used
by dhcpcd it should be something dhcpcd obeys when set by the network
manager, to prevent v6 usage on an interface (or on the whole system).
(There should be a similar one for v4 incidentally.) After all, any
application that knows it needs an addr assigned, can trivially easily
alter the sysctl value if that's what it needs to make things work.

It matters because the kernel hardware address only assignment is not
desired
as stated above and dhcpcd cannot control the boot order so a sysctl is
infact
needed by the operator to say "turn this off, I know what I'm doing."
dhcpcd will work correctly either way.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Joerg Sonnenberger

Post by Michael Richardson
The question of which address shoud be used for outgoing connections is
really the question that we are discussing.

Is it? Not for me at least. I am perfectly fine with using a temporary
address (i.e., PE) for the outgoing connections unless requested
differently by a program (think Postfix). I do care about loosing
connectivity to a machine just because I have updated it.

This is easily handled in a few ways - some ideas:

* Documentation for upgraders

* dhcpcd binary defaults to hardware based iid but dhcpcd.conf
defaults to stable private iid
new installations get private addresses
upgraders stay as they are until get upgrade their dhcpcd.conf

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

Post by Roy Marples
upgraders stay as they are until get upgrade their dhcpcd.conf

It's possibly worth noting that the context where this matters is that you have a device that's moving around. It really doesn't make as much difference for a static device. So your pmax that you have sitting in the garage at home doesn't need stable private addresses as much as your laptop does.

Unfortunately, I don't see a way to make dhcpcd notice the difference.

What I do about this in practice at home is to use MDNS. This is no more or less safe than relying on the SLAAC address not to change, since the threat model is the same: an attacker on the wire. So when I want to hack on my server, I just type "ssh server.local". Ultimately I think this is a better practice when you are using IPv6 anyway, because the addresses are so unwieldy.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Fernando Gont]

Post by Ted Lemon

Post by Roy Marples
upgraders stay as they are until get upgrade their dhcpcd.conf

It's possibly worth noting that the context where this matters is
that you have a device that's moving around. It really doesn't make
as much difference for a static device. So your pmax that you have
sitting in the garage at home doesn't need stable private addresses
as much as your laptop does.

They do. Stable-privacy addresses (RFC7217) are also meant to mitigate
host scanning attacks -- that was actually my motivation when I started
working on it at the time.

Cheers,
--
Fernando Gont
e-mail: ***@gont.com.ar || ***@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ted Lemon]

Post by Fernando Gont
They do. Stable-privacy addresses (RFC7217) are also meant to mitigate
host scanning attacks -- that was actually my motivation when I started
working on it at the time.

Fair point. I should have said "needs them less." In any case, it's doubtful that host scanning attacks will target NetBSD--not enough customers.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Ted Lemon

Post by Fernando Gont
They do. Stable-privacy addresses (RFC7217) are also meant to mitigate
host scanning attacks -- that was actually my motivation when I started
working on it at the time.

Fair point. I should have said "needs them less." In any case,
it's doubtful that host scanning attacks will target NetBSD--not
enough customers.

I think the fact it's running NetBSD is irrelevant for what the intended
attack is for and what RFC7217 is trying to address.
dhcpcd also supports other OS's ;)

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Roy Marples
The next dhcpcd release will have support for IPv6 Stable Private
Addresses, RFC 7217.
http://wiki.netbsd.org/projects/project/ipv6-stable-privacy-addresses/
http://tools.ietf.org/html/rfc7217
In summary, this is designed as a replacement interface identifier for
the normal hardware derived one when using SLAAC.
By storing a persistent secret key and combing this with stable
network information such as prefix, ssid (if available), hardware
address and a dad_counter we can then take an interface identifier
from a hash of the above information combined.
The most basic goal is that the host is no longer track-able across
different networks based on their global address, but the address
remains stable on each network.

This has now been imported into -current.
Let me know how it works for you!

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Fernando Gont]

Post by Roy Marples
My question is this: should this be enabled by default as privacy is a
good thing, or should the normal hardware based address be kept?

Enable by default -- that is where we're formally going to (see
draft-ietf-6man-ipv6-default-iids).

Thanks,
--
Fernando Gont
e-mail: ***@gont.com.ar || ***@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de