Re: IPv6 problems.... (dhcpcd weirdness, rshd fails, etc.)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 17 Nov 2025 23:43:41 -0800
    From:        "Greg A. Woods" <woods%planix.ca@localhost>
    Message-ID:  <m1vLGNK-00Mo5fC@more.local>

  | What does "scope" mean in this context?  Isn't the scope whether it is
  | link-local, site-local, or global, and isn't that inferred from the
  | prefix?

That's not what it means, Ted already supplied the basic answer, but the
scope isn't that (that's the address type) but which particular link a
link-local address is local on, and which particular site a site local
address is local to.  There is, of course, just one "global" so scopes
are irrelevant there.

Except that site-local addressed were abandoned (for the absurd reason
that no-one was able to define what a site was, as if it ever needed
defining - it was whatever it needed to be) but the addresses that were
site local are now unrouted local addresses (sometimes called unique instead
of unroutable, but they're not really that) - kind of the same as the
private use addresses in v4, except there are lots of them - half of that
addr space is managed, so an addr from it can be assigned and will
belong to you, never be duplicated (if everyone obeys the rules) and the
other half for random assignment by anyone who wants one - you just assign
yourself one (as you would a 192.168 or 10.x.y.z) address.   These addresses
are nominally global, and are routed just like a global address, except the
backbone routing won't carry routes to any of them, as they're not topological,
and there are simply (potentially) too many to carry a flat routing table
for every possible one.   These needed scopes when they were site-local,
but no longer do - previously a node could be connected to 2 different sites
that happened to be using the same site-local address space, the scope would
keep things working, with ULAs the users are responsible to make sure that
doesn't happen - if you're in direct contact with (and not blocking ULA
addressed packets) another site using the same ULA address block then you
are effectively the same site and need to co-ordinate (or block).

  | How can that get lost?

It is a separate field, not part of the address, and must be passed around
in addition to the address itself.   Don't do that, and ...

  | Grasping at straws, but maybe it should be using bindresvport_sa()
  | instead?

No, that's identical, just a different func prototype, which avoids
some issues with compiler type checking.

  | Interesting -- I'm not sure how I can try it with the global address --
  | i.e. how do I get the client to bind its source address to the global
  | address instead of the link-local address when it is connecting to a
  | local server?

Just specify the local server's global address instead.   Unless there
is no option (e.g.: the node has only a LL addr) it will always use an
addr of the same type when communicating with another node - use a global
addr for the dest, and the local global addr will be the source, use a ULA
for the dest, and if there is one, the node's ULA will be used as the
source (if not, the global), use a LL addr for the dest and the node's
LL addr (within the same scope - ie: on the same link) will be used as
the source.

  | I'm guessing this ongoing log entry is about dhcpcd doing router
  | solicitation, but it already got IPv6 routes too....

Maybe, someone who understands dhcpcd will need to answer that.

It may be that the router is sending RAs with the "dhcp information"
(such as other unrelated facts about the network that DHCP can provide,
other than the basic node specific addressing - like the addr of the
DNS server, or NTP server, or printer, or ... there's potentially lots)
but then isn't actually supplying the information requested when the
node solicits it, and also isn't rejecting the request, but just ignores it.


  | I don't really understand what "auto config" means in IPv6 parlance,

It means the node assigns itself an address, based upon network prefix
information "broadcast" (really multicast, v6 has no notion of broadcast,
but an "all nodes" multicast is close) by the router (router advertisments).

Then using one of several possible methods, the host combines the prefix
(64 bits generally) with 64 bits it assigns itself, verifies that no other
node is using the same one (if there is, what happens depends upon how
that addr was picked) and when there isn't, assigns that addr to itself
(and defends it should some other node later try to assign itself the same
one).   The two common methods to create the bottom 64 bits of the addr
are to use the mac address (in its 64 bit format, there's a method to turn
48 bit macs into 64 bit, defined by IEEE) - those will always have the
mac address "local" bit turned off, which in v6 addresses (unlike MAC addrs)
means the bit is set to 1, as will be the multicast bit (that will be set to
0), so these actually provide a 62 bit address space.   If some other node
is using the same one, that's a problem, and no address gets assigned.

The other method is via random number generation, simply pick a random number,
set the "local" bit (ie: make it 0) as if it had been a 64 bit mac, and see
if you've been lucky, and nothing else picked the same one.   If they have,
just generate a different random number, and try again.  If this keeps
failing after a relatively small number of attempts, some other node is
probably being  obnoxious and simply claiming to own every address, to keep
others off "its" link... nothing can be done except give up until some human
finds that node, castrates it (unplugs it from the net) and fires(/expells/...)
its owner/user.

One of those random addresses can be more or less permanent (retained for
ever) or just used for a short while (for new addr assignments - existing
connections can be allowed to continue however long they need) and then
replaced by a new one.

  | I'm guessing dhcpcd handles this as if it was getting a DHCP lease?

I'd assume so, dhcpcd does the addr creation when it is being used.

Of course, you can also do manual (human based) addr assignment, and
assign things like 1 2 3 as the bottom 64 bits of the address (which works
because the (upper byte) "local" bit is 0, which means it is a locally
invented addr, not based upon a (unique) MAC - and which is why the
(0->local 1->global) choice was made.   If you do it this way, you're
responsible for assigning the addr, and keeping up to date with any
prefix changes the ISP might decide to make - v6 global addresses are
always topological, change the connectivity (enough) and the prefix
just has to change - and that means anything from you moving to a new
ISP, to your ISP being bought out and merging with another one, to
their (bigger) ISP changing the way it connects to the world.

Do everything based upon auto assignments, and it all "just works"
(or should, if the address changes are carried out properly) but if
you're manually configuring, you need to manually update when needed.

  | I.e. I only get a global address on my NetBSD systems when I set
  | "ip6mode=autohost" and I start "dhcpcd -6" (I need the -6 as I use
  | statically assigned IPv4 addresses on the LAN for these servers).

That suggests you have no running DHCPv6 server, and what you said about
how your router is configured would support that.

You could also add statically assigned ULAs for v6 for your servers, and
then use those for internal communications - those addresses are not
topological, and only need to change if you want them to (or you move
a server to a different subnet than it was on before).

  | It's weird that this is a binary either/or choice.  Can't you have
  | DHCPv6 and auto-configuration on the same LAN -- isn't it just a matter
  | of splitting the available address range?

Not really, it doesn't make much sense - either the LAN has managed addresses
(someone, somewhere - even if it was at the factory) decides what addresses
should be made available, and potentially, to whom - and perhaps even
configures the local switch to allow this addr from that port, and only
that combination (plus LL addrs) and all ports without an assigned addr
are blocked for non LL addr use.   Or you have an unmanaged network, where
nodes simply assign addresses to themselves.

Combining the two makes little sense - anything the DHCP server failed to
hand out an address to (and perhaps also when it did) could just assign
itself an address.

Router adverts have a single "managed" bit they use to instruct the hosts
which address strategy should be used.

  | I can try the other router setting and I guess if some device doesn't
  | get an IPv6 address because it can't do DHCPv6,

Unless you have a good reason to need managed addresses, I wouldn't.
Locally assigned addresses (MAC based, random, or manual) are more
flexible, and should just work.

  | well then presumably it'll still get an IPv4 address

Independent question - for auto assignment (as distinct from manual on
the host) you need a DHCP (v4) server there, if it assigns an addr, it
will, without any regard for how v6 addresses are being assigned to the
same node.

kre