Subject: Re: Allowing ifconfig to automatically fill in IPv6 host ID
To: None <>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-net
Date: 03/26/2002 17:10:09
    Date:        Mon, 25 Mar 2002 22:49:51 -0500
    Message-ID:  <>

  | in particular
  | ifconfig fo0 | sed -e '1,/inet /d' -e '/inet /d' -e 's/.* fe[0-9][0-9]:://' -e 's/%.*//' | head -1
  | does the trick for extracting the EUI64 from an ethernet interface

I don't think that's exactly the script I'd use (aside from anything else,
it is OK to assume that a link local addr will start fe80 - anything else
certainly isn't going to be an autoconfigured link local), and the 'd'
commands seem a little weird.

That is
	sed -n '/inet6.*fe80/s/.*fe80::\(.*\)%.*/\1/p'
is the kind of command I'd use if I was to use sed for this, or if I
was worried that there might be more than one line, then
	sed -n -e '/inet6.*fe80/!d' -e 's/.*fe80::\(.*\)%.*/\1/p' -e q

But this whole approach has a much bigger problem - to be useful, this kind
of thing needs to be able to be embedded in /etc/ifconfig.fo0 so the
interfaces can be configured the same as any other.   That can use the !
notation if needed to run a command, though running ifconfig via ! notation
isn't exactly what that was planned for, I suspect.

But all that happens in single user mode, without /usr mounted, so you can't
use sed (nor awk, let alone perl) to assist, really just what the shell is
able to do for you.

Now, I have no doubt but that it is possible to do all that is needed in the
NetBSD /bin/sh but this seems like something that is useful enough that
having ifconfig able to do it seems like the better way.

But only just - if you're going to manually configure (which you have to
do for routers at the minute) then it is probably just as easy to simply
count for the IID, and use 1, 2, 3, for your various systems (the 64 bits
means that you can assign a number to a node, to use on all of its interfaces,
forever, and not have to worry about assigning different numbers on each
interface as is required for address efficiency with v4).

More important, and only available via the kernel, is (for hosts this time,
not routers) a way to tell the kernel not to use a particular prefix, even
if it is seen advertised via routers.  With a "prefix" option to ifconfig
I could do

	ifconfig fo0 prefix abcd:: prefixlen 16 delete

(or similar) and have fo0 remember to never use abcd::/16 when it is
processing RA's advertising prefixes.   Of course, the ioctl to do that and
the previous would be quite similar, each with a prefix, a prefixlen,
and a ttl (how long the command should be obeyed, with 0 meaning forever).
Just one adds a prefix to the RA list, the other subtracts (and of course,
on a router, where RA's are not accepted, the RA list manually built that
way would still be used).

Of a similar nature - if I have decided to use 1, 2, 3... to number my routers
it seems natural to be able to use the same sequence for my important hosts
as well (DNS server, dhcp server, mail server, ...) - make certain that they
get addresses that are independent of the interface they happen to be using,
or anything else related to the current hardware.

It may be that there's a method to do this already, but to make this easy,
it would be nice to be able to config just the IID part of the address, and
then allow the host (these are hosts, not routers...) autoconfigure from the
prefixes obtained via RA's (or the above ioctls via ifconfig if that gets
done).  Note: changing the MAC addr in order to have it build an EUI-64
out of a configured mac addr isn't the right way to achieve this!

I am fully aware that none of this is essential (except possibly the ability
to ignore prefixes from RAs) in the kernel - all the rest can be done in
user space (so, if one wanted to implement "ifconfig prefix" by fetching the
link local addr, and doing bit manipulations inside ifconfig, that would be
possible).   But we need to have at least the front end user interface (net
administrator config interface) for this available - not hidden behind "do it
yourself with a script").   IPv6 should be easy to use, let's not just be
content with "well, it is possible to do ..." and instead truly make it easy.