>> poorly documented, complicates both kernel and user code, leads to
>> insecure user code, and should be deprecated. yes, I dislike it.
>Fully agreed. I insisted on this from since prehistoric time.
>This behaviour cannot be optional though: we should select either this
>or this.
>
>Splitting port spaces allows to split hash tables, it is natural
>from all the viewpoints and simplifies code a lot. Preserving mapped
>addresses optionally we win nothing.
unfortunately there are a lot of confusion due to the way RFC2553/
2553bis is specified, and there a lot of flavors in third-party
programs. for example:
- server program listens to AF_INET6 wildcard socket only by.
it will grab IPv6 traffic only on openbsd/netbsd, IPv4/v6 traffic on
freebsd/bsdi/linux.
- server program listens to AF_INET6 and AF_INET wildcard sockets
(bind AF_INET6 first).
it will behave like this:
- *bsd: IPv6 traffic comes from AF_INET6 socket, IPv4 traffic comes
from AF_INET socket.
- current linux (correct me if I'm wrong): AF_INET wildcard bind(2)
is disallowed, so the program fails to bind(2) to AF_INET socket.
IPv4/v6 traffic will come up to AF_INET6 socket.
- server program that listens to AF_INET and AF_INET6 wildcard sockets
(bind AF_INET first).
it will behave like this:
- *bsd: IPv6 traffic comes from AF_INET6 socket, IPv4 traffic comes
from AF_INET socket.
- current linux (correct me if I'm wrong): AF_INET6 wildcard bind(2)
is disallowed, so the program fails to bind(2) to AF_INET6 socket.
IPv4 traffic will come up to AF_INET socket, no IPv6 traffic
received.
- server program that listens to wildcard addresses returned by
getaddrinfo(2). depending on getaddrinfo(3) ordering, it will
present behavior presented above.
to support programs like first bullet with smallest amount of changes,
i kept IPv4 mapped address behavior in netbsd, as an optional behavior.
openbsd's position is to drop support for programs like the first
bullet, to keep simplicity in kernel/usreland; if we run two daemons
(one for AF_INET and one for AF_INET6) we should be okay.
i hope to hear your position regarding to bind(2) ordering. bind(2)
ordering and conflict logic must be decided in a consistent way
with IPv4 mapped address behavior. also, getaddrinfo(3) return
value ordering as well.
itojun
