From: "Bill Sommerfeld via illumos-developer" <developer@lists.illumos.org>
To: developer@lists.illumos.org
Subject: [developer] [REVIEW] 16841 in.ndpd sometimes loses interface id on restart
Date: Sat, 19 Oct 2024 11:58:42 -0700 [thread overview]
Message-ID: <c56026c0-47ac-4eba-98e9-d07817d817ca@hamachi.org> (raw)
Issue: https://www.illumos.org/issues/16841
CR: https://code.illumos.org/c/illumos-gate/+/3741
Diff:
https://code.illumos.org/~diff/9ccc0daeed048cc5d86a311d9b68fb6bccb01479
The low order 64 bits of IPv6 unicast addresses come from an interface
identifier which is, by default, derived from the interface's MAC
address. The "ipadm create-addr -T autoconf" command lets you specify
an alternate value for the interface identifier, but it turns out that
if you use this option, in.ndpd will sometimes ignore it and use the
default, leading to unstable ipv6 addresses.
I've been using this configuration for a few years and have been
bothered with the instability. I believe I've finally found the cause
and have a fix.
There are multiple paths to creating a "struct phyint" inside in.ndpd,
and there were inconsistancies in what they did and how they set the
interface id-related fields of the "struct phyint".
There are two parts to the change:
1) phyint_check_ipadm_intfid() was only called if the "struct phyint"
was newly created in if_process(); if it was created earlier (for
instance, if it was mentioned by name in ndpd.conf), ndpd wouldn't use
the configured interface id in newly-created addresses.
2) When an address is set up by ndpd_create_addrs() with a configured
interface id, the "pi->pi_default_token" boolean is cleared, but when
phyint_check_ipadm_intfid() is called, pi->pi_default_token is left
unchanged. If pi->pi_default_token is left set, the interface id will
be overwritten the next time phyint_init_from_k() is called.
I'd like to thank Andy Fiddaman for creating and integrating the
link-local test in https://www.illumos.org/issues/16251; it turned out
to be a reliable way to provoke address instability.
Thanks in advance for your review.
- Bill
------------------------------------------
illumos: illumos-developer
Permalink: https://illumos.topicbox.com/groups/developer/T9d2d278184764632-M0cdefe608f1f4d20bd381f93
Delivery options: https://illumos.topicbox.com/groups/developer/subscription
reply other threads:[~2024-10-19 19:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c56026c0-47ac-4eba-98e9-d07817d817ca@hamachi.org \
--to=developer@lists.illumos.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).