I think tech-net is the right forum for this (rather than netbsd-help
or something), but feel free to redirect.

It also may be that the underlying problem I am seeing is really rooted
in IETF mentality, rather than anything specific to NetBSD, but I wanted
to check to make sure that the believe isn't just that we have an
implementation  limitation that should be fixed (I think we do, though
I don't think that fixing it will really solve all of the problems).

I had an opportunity to set up IPv6 over PPP for the first time last
night (both ends NetBSD, which is how I got to be able to control fate
better than usual dial up).

The theory of IPv6 over PPP operation seems to be (I am no PPP expert)
that the two ends negotiate IPv6 IIDs using PPP LCP, and having done that
treat the PPP link just as if it was an ethernet.   That is, LL addresses
are configured using the IID's obtained, after which the "client" sends
an RS, and gets an RA from the "server"/"router" which tells the client of
any global address prefixes that exist on the link, from which the client
configures its global IPv6 address (using the IID).

I believe that's how it is expected to operate, as there are no LCP
(LCPv6) options for passing around IPv6 address information of any kind
(there's a draft to add one to supply DNS server addresses, but that's
certainly not relevant).

This stuff all works, more or less, on NetBSD as it is - except there are
a couple of problems that make life more difficult.

First, to get rtadvd to send RA's out the ppp interface, the ppp interface
needs to be listed on rtadvd's command line.  But it can only be there
when the ppp interface in use actually exists, or rtadvd aborts.
That means, the ip-up script at the server end has to restart rtadvd
adding in the new ppp interface name when the link comes up, then it
needs to be restarted again, without that ppp interface name when the
link goes down again.   This is all possible, but really very ugly.

Second, the "client" in my case (and I suspect for may of us here) is
not a host, but a router.   To get this address configuration to work,
I need to tell my router to accept RAs - which is something that routers
aren't normally supposed to do.    That's OK, I can do that, in my
case I know there won't be anything sending RA's on any of the other
interfaces on the client.

This is the first real NetBSD limitation - the "accept RA" is a global
switch, which should almost certainly apply per interface (as an ifconfig
setting, rather than a sysctl).

Third, given that it is possible for the ppp "server" to tell me the
correct IPv6 address to use (it needs to tell me, I could be dialing
into anywhere after all, my system can't know the appropriate address),
using the "RS & RA" method to get the address results in it being applied
to the PPP link - I'd much rather treat the PPP link as unnumbered
(globally) and use the prefix on a convenient ethernet - but given that
the kernel takes the RA, and constructs an address on the interface
over which the RA was received, this is a bit tricky to manage.

This is the second NetBSD limitation - perhaps the kernel should get
out of the business of RA processing, and leave all of that to rtsold ?
Then, with a suitably smart (and appropriately configured) rtsold,
an RA received on a p2p interface like this, could supply prefixes
that are actually assigned to ethernets (and if there was more than
one prefix supplied, or a prefix length < 64, they could be split
and assigned to different ethernets).

Of course, this one assumes that the RS/RA model is the appropriate way
for PPP servers to inform clients (temporary attach) clients of
addressing available to them - which I actually doubt, I'd think it
would make much more sense for this to be done using LCP.

Opinions?

Should I dive into fixing NetBSD to make it possible to act "sensibly"?

Has no-one else run into this kind of issue before (does no-one else do
IPv6 over dial up from a network, rather than an isolated host) ?

Or is this something that the IETF PPP/v6 people should be fixing before
we waste any effort on improving NetBSD behaviour?

kre