Generating IPv6 EUI64 based addresses

[Robert Elz]

What do I have to tell dhcpcd in order to have it
generate me plain old ordinary EUI-64 type addresses
for IPv6 (the way they were originally specified) ?

Currently (on one test Xen DomU - hence their weird MAC addr)
I am getting...

address: 76:d0:2b:91:ab:03
inet6 fe80::37a1:2259:66d1:de9b%xennet0 prefixlen 64 scopeid 0x1
inet6 2001:3c8:9009:181:251a:3362:ec98:db5 prefixlen 64
inet6 2001:3c8:9009:181:1407:dac:dc89:3a56 prefixlen 128

I'd much prefer to have

inet6 fe80::74d0:2bff:fe91:ab03
inet6 2001:3c8:9009:181:74d0:2bff:fe91:ab03

(and I have no idea what the /128 is about, it doesn't seem useful,
so could just go away.) (Aside: those were hand computed EUI-64
based addrs, if I made an error in that, I do not mean I need that
error duplicated - whatever the correct EUI-64 would be is the aim.)

Having the same low bits for the LL and global addresses improves NDP
(only one multicast addr needed).

If there is some good reason that EUI-64 addrs are impossible (if it
is just a matter of altering the MAC addr, I'll do that) then at least
could the address be stable - currently if I reinstall (keeping the same
MAC addr, but everything else new - it is a test system) I get a
different set of addresses every time. Fortunately just a reboot does
not seem to cause that.

kre


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

[Jarle Greipsland]

Post by Robert Elz
What do I have to tell dhcpcd in order to have it
generate me plain old ordinary EUI-64 type addresses
for IPv6 (the way they were originally specified) ?

Maybe change 'slaac private' to 'slaac hwaddr' in
/etc/dhcpcd.conf?
-jarle
--
"Whiteboards are remarkable."

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

[Robert Elz]

Date: Sun, 08 May 2016 09:35:20 +0200 (CEST)
From: Jarle Greipsland <***@uninett.no>
Message-ID: <***@uninett.no>

| Maybe change 'slaac private' to 'slaac hwaddr' in
| /etc/dhcpcd.conf?

Thanks, I'll try that next time I reboot. I suspected there would
be some easy way...

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: Sun, 08 May 2016 09:35:20 +0200 (CEST)
| Maybe change 'slaac private' to 'slaac hwaddr' in
| /etc/dhcpcd.conf?
Thanks, I'll try that next time I reboot. I suspected there would
be some easy way...

Any suggestions on how dhcpcd.conf(5) could be improved?

slaac [hwaddr | private]
Selects the interface identifier used for SLAAC generated IPv6
addresses. If private is used, a RFC7217 address is gen‐
erated.

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: Sun, 08 May 2016 11:07:25 +0100
From: Roy Marples <***@marples.name>
Message-ID: <***@uberpc.marples.name>

| Any suggestions on how dhcpcd.conf(5) could be improved?

No, but I was kind of hoping there would be a way using just rc.conf
(and maybe there will be when I look at it closer). That is, I read
the dhcpcd man page to see if there was a command line option I could
set, but nothing jumped out at me. So I had not gotten around to looking
in there before it was suggested to me.

The system in question gets built by newfsing its partition, mounting
it, setting the DESTDIR for a build to that directory, doing a complete
build, then unmount, copy appropriate DomU kernel to where xen expects to
find it, and boot. I am kind of hoping for as few mods as possible being
required to what a full build produces - I have fstab, hosts, and rc.conf
(and now. dhcpcd.conf as well) which I copy in after the build finishes,
before unmounting. The fstab copied in allows nfs mounting the src
directory, so after it boots, it can set about building all over again
(all this to verify that everything builds and works before committing
changes to sh ...)

The stable address is desireable so the nfs server can permit just that
system to mount the sources, without needing to fiddle it every time.

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: Sun, 08 May 2016 11:07:25 +0100
| Any suggestions on how dhcpcd.conf(5) could be improved?
No, but I was kind of hoping there would be a way using just rc.conf
(and maybe there will be when I look at it closer). That is, I read
the dhcpcd man page to see if there was a command line option I could
set, but nothing jumped out at me. So I had not gotten around to looking
in there before it was suggested to me.

dhcpcd --slaac hwaddr

also works.
The problem I have is that most dhcpcd.conf options works on the commandline
and most commandline options also work in dhcpcd.conf.
However, this is not 100% the case and have yet to work out how I can easily
manage this in two man pages without over duplication.

Ideas are welcome :)

Post by Robert Elz
The system in question gets built by newfsing its partition, mounting
it, setting the DESTDIR for a build to that directory, doing a complete
build, then unmount, copy appropriate DomU kernel to where xen expects to
find it, and boot. I am kind of hoping for as few mods as possible being
required to what a full build produces - I have fstab, hosts, and rc.conf
(and now. dhcpcd.conf as well) which I copy in after the build finishes,
before unmounting. The fstab copied in allows nfs mounting the src
directory, so after it boots, it can set about building all over again
(all this to verify that everything builds and works before committing
changes to sh ...)
The stable address is desireable so the nfs server can permit just that
system to mount the sources, without needing to fiddle it every time.

You could just preserve dhcpcd.secret as well to keep the same private
addresses If you wanted to have that feature or not.

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: Sun, 08 May 2016 12:02:44 +0100
From: Roy Marples <***@marples.name>
Message-ID: <***@uberpc.marples.name>

| dhcpcd --slaac hwaddr

Thanks that arrived just in time ... I was just looking at what to config

I saw in dhcpcd.conf that it says that everything is suppord to be possible
on the command line, but it doesn't say how to achieve that.

I was looking at the options listed in dhcpcd(1) and couldn't find anything
there either, so...

| The problem I have is that most dhcpcd.conf options works on the
| commandline and most commandline options also work in dhcpcd.conf.
| However, this is not 100% the case and have yet to work out how I can
| easily manage this in two man pages without over duplication.
|
| Ideas are welcome :)

Just (somewhere before the huge list of options, in dhcpcd(1)) say
something like:

In addition to the options listed here, any of the configuration
options listed in dhcpcd.conf(5) (except where otherwise noted)
can be given by preceding the option name with '--'.

And maybe give an example of that. Then for any options where that
won't work, just say so (in dhcpcd.conf(5)).

And if the rest of the command line options in dhcpcd(1) also work
in /etc/dhcpcd.conf say something similar in dhcpcd.conf(5) about them,
including just how to put one of those options in /etc/dhcpcd.conf
(and again, perhaps with an example).

Then just list the options (aside from in examples) once each, in the
place where it is most likely that they will want to be used (which may
be as you have them divided up now.)

| You could just preserve dhcpcd.secret as well to keep the same private
| addresses If you wanted to have that feature or not.

No, not particularly interested in private addresses, and particularly not
for this system which will never talk to anything except its host Dom0
(which is also its NFS server.)

I still don't know what that /128 address is though - and that's the one
that seems to be used (longest prefix probably) for connections initiated
from the system - and that one does not seem to be affected by the
--slaac hwaddr option. How do I make it simply go away? (I don't have
/128 addresses on any of my other systems, most of which don't run any
form of dhcp client, but have fully statically configured addresses.)

By "go away" - I mean not get created in the first place, I understand how
to "ifconfig inet6 ... -alias" to delete it (but don't know if dhcpcd would
eventually just put it back again.)

Thanks,

kre


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

[Robert Elz]

| By "go away" - I mean not get created in the first place, I understand how
| to "ifconfig inet6 ... -alias" to delete it (but don't know if dhcpcd would
| eventually just put it back again.)

I did (delete it) and it did (put it back). So what is it intended to
be for, why do we need it, and how do we get rid of it?

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
I still don't know what that /128 address is though - and that's the one
that seems to be used (longest prefix probably) for connections initiated
from the system - and that one does not seem to be affected by the
--slaac hwaddr option. How do I make it simply go away? (I don't have
/128 addresses on any of my other systems, most of which don't run any
form of dhcp client, but have fully statically configured addresses.)
By "go away" - I mean not get created in the first place, I understand how
to "ifconfig inet6 ... -alias" to delete it (but don't know if dhcpcd would
eventually just put it back again.)

/128 addresses are not associated with any prefix.
As such it's extremely likely it was given to you by a DHCPv6 server.
Now, dhcpcd will handle DHCPv6, but will only start it if configured to do so
(not by default) OR if instructed to by a Router Advertisement (which is
probably what happened here).

So basically your IPv6 router is saying there is a DHCPv6 network address to
negotiate as well.

You can instruct dhcpcd it ignore this by using the nodhcp6 option.

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: Sun, 08 May 2016 16:17:01 +0100
From: Roy Marples <***@marples.name>
Message-ID: <***@uberpc.marples.name>

| As such it's extremely likely it was given to you by a DHCPv6 server.

That seems to be it, thanks.

| So basically your IPv6 router is saying there is a DHCPv6 network address
| to negotiate as well.

Yes, .... (no idea why, but there are a bunch of IPv6 related experiments
take place on that net, so anything is possible...)

(this has been re-wrapped for e-mail convenience from what tcpdump
actually produced)

02:04:17.935763 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58)
payload length: 64) fe80::1 > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 64 hop limit 64,
Flags [managed, other stateful], pref medium, router lifetime 1800s,
reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 00:24:c4:6a:13:ff
mtu option (5), length 8 (1): 1500
prefix info option (3), length 32 (4): 2001:3c8:9009:181::/64,
Flags [onlink, auto], valid time 2592000s, pref. time 604800s


| You can instruct dhcpcd it ignore this by using the nodhcp6 option.

Thanks, will do that, and you can expect to hear no more from me about this.

kre


--
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 Robert Elz
02:04:17.935763 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58)
payload length: 64) fe80::1 > ff02::1: [icmp6 sum ok]
ICMP6, router advertisement, length 64 hop limit 64,
Flags [managed, other stateful], pref medium, router lifetime 1800s,

^^^^^^^^^^^^^^

is the crucial part.

Joerg

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