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

From: Francis Dupont <[email-masked]>
Date: Sun, 01 Jul 2001 15:36:16 +0200

In your previous mail you wrote:

   we have only to keep the discussion within boundaries (i don't like
   flame wars).
   
=> this discussion already occured without any result (no flame war too
but only because we kept it within boundaries). It is just too late
and to get a RFC 2553 bis published is more important than to try again
to get a consensus on a subject we know it is near impossible.

Regards

[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: Sun, 01 Jul 2001 15:47:45 +0200

it seems that there are many people in favor of changing the behaviour
   of AF_INET6 sockets: itojun, pekka, me, horape, brian, erik.

=> but there are more people in favor of keeping the behaviour of
AF_INET6 sockets, they are only too bored by this discussion...

   only jim and francis do not agree.

=> don't answer in the list is not an agreement and don't forget
this discussion already happened and the current 2553 bis only reflects
the opinion of the majority at the last poll.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 01 Jul 2001 17:50:27 +0200

In your previous mail you wrote:

   >From my reading of 2553bis, there seem to be at least two ways this
   can be implemented (not counting the semantic changes being proposed):
   
=> yes, you can have merged or split port space. Both are commonly
implemented and the 2553 bis document accepts both.

   2553 doesn't seem to specify which is the correct behavior.

=> of course: none is incorrect.

   it sounds like several others have as well (implemented separate space).
   
=> I implemented a shared space (before to adopt the "IPv6 is a new version,
not a new protocol") and some others too. I don't believe one solution is
definitely better than the other, in fact it is hard to see the difference.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 01 Jul 2001 18:34:02 +0200

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.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 01 Jul 2001 18:41:35 +0200

In your previous mail you wrote:

   > >> => you can use it with the V6ONLY stuff.
   > >yes, but on rfc2553-compliant system you cannot have both an AF_INET
   > >and an AF_INET6 socket listening on the same port.
   >
   > 	(just a picky comment)  RFC2553 does not talk about the behavior
   > 	when try to bind(2) to both :: and 0.0.0.0 on the same port.  some
   > 	systems reject bind(2) to 0.0.0.0, some does not.
   
   ok. i will try to explain better my thoughts.
   
=> OK because I don't understand what you want.

   i don't want to change RFC2553. i think that V6ONLY is a very good feature
   and may be sufficient to achieve a good af-indipendence. however, this
   moves the focus on the behaviour of bind and getaddrinfo (which is not
   described in detail in RFC2553 - i suppose because there is no consensus).
   
   some implementations of bind(2) allow binding of 0.0.0.0 and :: address
   on the same port, and some do not. i think that this may be a problem for
   the developers which are working in multi-platform environments.
   
=> the V6ONLY stuff is just here in order to give a way to enforce the
same behavior on any compliant platform.

   i'd really like to minimize the negative effect of this behaviour, but i
   understand that there is not much that can be done about this.
   
=> one thing we can not do is to pick up an implementation and to make
all others non-compliant. When there is no way to get a portable code
for every compliant implementation we update the 2553 document. This was
done for BIND 9 filtering and gave V6ONLY stuff. We should not go further
without very good reasons, we should not break old codes too.

   i hope that we will come to a *BSD-like de-facto standard for the
   behaviour of bind and getaddrinfo, but i wonder if having no standard
   is even worse than having a bad standard (linux-like).
   
=> we have a specification (not a standard for the IETF, APIs are never
on the standard track) and many years of experiments with it.
Use it and close this discussion.