Subject: RE: RFC 2553 bind semantics harms the way to AF independence

From: "Christian Huitema" <[email-masked]>
Date: Mon, 2 Jul 2001 09:44:08 -0700

Francis,

I believe that your comments are based on a host model that does not
entirely cover reality. 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.

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.

-- Christian Huitema

> -----Original Message-----
> From: Francis Dupont [mailto:[email-masked]]
> Sent: Sunday, July 01, 2001 9:34 AM
> To: Mauro Tortonesi
> Cc: Jim Bound; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: RFC 2553 bind semantics harms the way to AF independence
> 
>  In your previous mail you wrote:
> 
>    > With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23
one
>    > using AF_INET and the other AF_INET6.
> 
>    RFC2553 does not state this behaviour.
> 
> => I disagree.
> 
>    in fact many implementations do not allow to do this.
> 
> => fix them!
> 
>    can you explain better? let's take two sockets, an AF_INET and an
>    AF_INET6+V6ONLY one. can i bind them on the same port only if i
>    bind first to 0.0.0.0 and then to ::? or is it also correct to bind
>    first to :: and then to 0.0.0.0?
> 
> => both, V6ONLY removes possible interferences between IPv6 and IPv4
> spaces.
> 
>    RFC2553 is silent about this.
> 
> => 2553 bis is not, reread the V6ONLY spec.
> 
> [email-masked]
> --------------------------------------------------------------------
> 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-masked]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jul 2001 09:50:00 +0200

entirely cover reality.

=> but this model has many implementations, including routers or
multi-homed hosts.

   An IP address, v4 or v6, designates an

=> 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).

=> 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

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-masked]
--------------------------------------------------------------------