In your previous mail you wrote:
I believe that your comments are based on a host model that does not
entirely cover reality.
=> but this model has many implementations, including routers or
multi-homed hosts.
An IP address, v4 or v6, designates an
interface, not a host. A host can have many IP addresses; it can be
multi-homes to several interfaces, and it can be "artificially divided"
into several "sub-host", e.g. when the host is the platform for several
"sites", each with its own servers for HTTP, FTP, telnet and SMTP.
In a multi-homed host, processes must obviously be able to bind to a
specific address. For example, if a host supports www.example1.com and
www.example2.com, you definitely expect that two different mail server
processes will bind to www.example1.com:25 and www.example2.com:25.
Another reason to do so may be to insist that a specific service is only
reachable through a specific interface. You expect to achieve the
address or interface selection by binding the socket to a specific
address+port combination, not just a port number. Indeed, you want to be
able to support this function for IPv4 and IPv6 addresses.
=> I agree but problems are not there:
- some implementations have a non-BSD SO_REUSEADDR option
- some implementations have bad interference between :: and 0.0.0.0
The second point was solved by V6ONLY, the first point is more political
but SO_REUSEADDR has a clear behavior for every BSD systems
(the documentation is *poor* but to fix it is not the job of the IPv6 WG).
In a multi-homed host that uses IPv4 and IPv6, you get quite a number of
combinations. I may want a socket to all interfaces and all protocols,
to a specific interface and a specific protocol. I could also imagine to
"all protocols on a specific interface, but there is a slippery slope
here. As we start taking advantage of the large IPv6 address space, we
introduce new concepts such as privacy addresses, so we loose the
restriction of "one address per interface", and the correspondence
between "the IPv4 address of the interface" and "the IPv6 address of the
interface" becomes fuzzy. Then, there are interfaces such as 6to4 that
are IPv6 only. Pretty soon, you realize that the easiest way to select
an interface is to bind to a port on a fully specified address, and that
such sockets will by definition be single protocol.
=> I disagree (about the bind on fully specified addresses). This makes
the code more complex (several sockets when one can be enough) and
more important this relies on good routines to get and track all
addresses. The SIOCGIFCONF is a nightmare, everybody fixed it but
in different ways. And to follow emergence of new addresses is even more
difficult. What you need is a *standard* way to get the destination
address of incoming queries over UDP and to bind a socket per possible
address is not a good solution, cf. sendmail, bind, etc.
Regards
[EMAIL PROTECTED]
PS: security filtering is different. The common close TCP connection
when one doesn't like the peer is a very bad way to do it but the issue
is more in a lack of denial in the application protocol (more polite)
or a denial (TCP RST) in the kernel like it is done for TP4. To summarize
this issue is simply that "accept" is a wrong name for the accept system call.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
