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

From: "Christian Huitema" <[email-masked]>
Date: Tue, 26 Jun 2001 09:04:43 -0700

>    then why bothering to write RFC2553? if any ISV can do what he
wants it
>    has been only a useless effort.

There is a strong case to be made that the IETF should limit itself to
the definition of protocols, i.e. the bits that flow on the wire, and
should not be concerned with APIs. APIs are typically determined by two
factors, the function that you want to provide and the environment in
which you provide it. The IETF knows a lot about what function to
provide, but it generally does not know all that much about the
environment. Would you still use the socket API in a firmware
implementation? Would it be the same in a massively parallel machine?
What about a quantum computer? API definition in the IETF is always an
exception, not a norm.

In fact, we may observe that RFC 2553 is an informational document, not
a standard track document. It was produced by the WG in a burst of
enthusiasm, but it is a strange beast when in comes to process. How does
one apply the "implementation that interoperate" test? How do we
progress a document and drop features that were not in fact implemented?
How does it apply to hardware implementations of TCP/IP? If there are
not enough compliant implementations, does one obsolete the document and
forget about it? 

On the other hand, the subject makes for volume of exchanges on the WG
list, which gives us a comforting sense of liveness...

-- Christian Huitema
--------------------------------------------------------------------
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: David Borman <[email-masked]>
Date: Wed, 27 Jun 2001 12:08:19 -0500 (CDT)

In seems to me that all this discussion about what the default
behavior should be when binding to a wildcarded AF_INET6 socket
doesn't address the issue: deterministic behavior for portable
application across multiple operating systems.

And just to lay my cards on the table, I support the current
default behavior of having AF_INET6 sockets receive both IPv4 and
IPv6 packets.

Isn't the real problem that we have added an IPV6_V6ONLY option,
but not an IPV6_V4ANDV6 option?.  If we add that, then portable
applications can explictly state what actions they want, and they
don't have to worry about OS defaults.  The success and failure
cases are then obvious and well defined:

	bind#1	AF_INET6 w/IPV6_ONLY
	 bind#2	AF_INET6 - fail
	 bind#2	AF_INET4 - succeed

	bind#1 	AF_INET6 w/IPV6_V4ANDV6
	 bind#2	AF_INET6 - fail
	 bind#2	AF_INET4 - fail

	bind#1	AF_INET4
	 bind#2	AF_INET6 w/IPV6_ONLY - succeed
	 bind#2	AF_INET6 w/IPV6_V4ANDV6 - fail

Thus, you have deterministic behavior.  And that's the end goal
for portable applications, isn't it?

			-David Borman, [email-masked]

---

From: "Dave Thaler" <[email-masked]>
Date: Wed, 27 Jun 2001 11:24:16 -0700

Erik Nordmark wrote:
> > Actually I suggested it as well, so I wouldn't have a problem with
no
> > default.  Anyone who wants portable apps would just always set the
> > option, no problem.
> 
> The benefit of changing the default would be that applications using
> getaddrinfo could be more address independent.
> With either the current default or an unspecified default those
> applications need code to say
> 	if AF_INET6
> 		turn on IPv6_V6ONLY

Someone else suggested that getaddrinfo (with AF_UNSPEC and AI_PASSIVE)
should return :: if the OS has IPV6_V6ONLY default to off, and both ::
and 0.0.0.0 if the OS has IPV6_V6ONLY default to on, and I agree with
this.

Another problem I have with the current default is that app writers that
want IPv6-only need to know about the IPV6_V6ONLY option, and those that
want both IPv4+IPv6 need to know about the AI_V4MAPPED flag.  So there's
no "simple" api, you have your choice of 2 special cases.

-Dave