* Request for reports on ipv6 issues
@ 2012-09-30 16:57 Rich Felker
2012-09-30 19:05 ` Rich Felker
0 siblings, 1 reply; 2+ messages in thread
From: Rich Felker @ 2012-09-30 16:57 UTC (permalink / raw)
To: musl
One area I've been meaning to address for a while is the quality and
completeness of ipv6 support in musl. I've never used ipv6 seriously
so while I can read the specification for how the interfaces are
supposed to behave, I don't have any good intuition beyond that.
I know AI_ADDRCONF is not supported, and should be. I also know glibc
has experienced a lot of bugs with it not behaving as expected, so
this one probably requires some attention to the details.
Apparently ipv6 has some sort of "scope" which I don't understand, and
which I don't think we handle now.
The AI_V4MAPPED and AI_ALL flags are not supported at all yet, but
they seem pretty straightforward.
Anything else?
Rich
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Request for reports on ipv6 issues
2012-09-30 16:57 Request for reports on ipv6 issues Rich Felker
@ 2012-09-30 19:05 ` Rich Felker
0 siblings, 0 replies; 2+ messages in thread
From: Rich Felker @ 2012-09-30 19:05 UTC (permalink / raw)
To: musl
On Sun, Sep 30, 2012 at 12:57:18PM -0400, Rich Felker wrote:
> One area I've been meaning to address for a while is the quality and
> completeness of ipv6 support in musl. I've never used ipv6 seriously
> so while I can read the specification for how the interfaces are
> supposed to behave, I don't have any good intuition beyond that.
>
> I know AI_ADDRCONF is not supported, and should be. I also know glibc
> has experienced a lot of bugs with it not behaving as expected, so
> this one probably requires some attention to the details.
The concept of having an "address configured" seems to be poorly
defined. So far, the approach that seems ideal to me is, when
AI_ADDRCONFIG is specified, attempting to connect a datagram socket to
each candidate address. This will not generate any network traffic,
and will succeed if and only if the kernel thinks there's a route.
This approach also allows us to obtain the source address that would
be used to make a connection, so that the semantics of RFC 3484 could
be implemented if desired. However, I'd rather not go there unless a
need is demonstrated.
It may be possible (albeit a stretch) to claim the current behavior
(igoring AI_ADDRCONFIG entirely) is conformant when used on Linux
systems in the default configuration, since the loopback interface by
default has IPv4 and IPv6 addresses configured. Whether this behavior
suffices to make applications happy, I have no idea.
> Apparently ipv6 has some sort of "scope" which I don't understand, and
> which I don't think we handle now.
Link local addresses, etc., are only valid in the context of a
particular scope id. For link-local, that id is the interface number.
This explains why POSIX standardized the otherwise-apparently-useless
if_nametoindex and if_indextoname functions: to fill in the scope id
of ipv6 link-local addresses.
Rich
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-09-30 19:05 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-30 16:57 Request for reports on ipv6 issues Rich Felker
2012-09-30 19:05 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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).