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

From: "Lori Napoli" <[email-masked]>
Date: Fri, 22 Jun 2001 14:42:09 -0400

We have come to the same conclusion that IPV6_V6ONLY  should be allowed to
change only if no bind or connect has been called on that socket.  Do the
RFC authors agree?  If so,  can we expect the next draft of this RFC to
have this restriction?

Thanks
Lori

--------------------------------------------------------------------
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: Sat, 23 Jun 2001 13:55:20 +0200

In your previous mail you wrote:

   We have come to the same conclusion that IPV6_V6ONLY should be allowed to
   change only if no bind or connect has been called on that socket.

=> I agree that to change IPV6_V6ONLY on a bound socket (i.e. after a bind
or connect) is silly. I've looked at my code: it forbids to set IPV6_V6ONLY
on a bound socket (not exactly what you ask for).
Conclusion: wording should be very accurate.

Regards

[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Sun, 24 Jun 2001 22:27:33 -0400 (EDT)

Compaq implements it the same way.

But as one author NO this should not go in the spec.  It is implementation
defined.  The only way to force this is to discuss porting assumptions of
the market place.  That is at best an art and not a science at this point
with IPv6.  If someone does not do it this way and they are the only one
the market will not use their system.

thanks

/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])

---

From: [email-masked]
Date: Mon, 25 Jun 2001 15:01:00 -0300

¡Hola!

> the market will not use their system.

We should convert the art into science, and so the spec should be clear. As
in telling when is allowed to change IPV6_V6ONLY value, or specifying what
should happen if it is changed after bind/connect.

Main problem with RFC2553 is that it is too ambiguous. Different
implementations of the same standard are a Bad Thing, and vague standards
are so a Bad Thing too. RFC 2553 should be made clearer, not vaguer.

> /jim
					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]

---

From: Jim Bound <[email-masked]>
Date: Mon, 25 Jun 2001 23:36:47 -0400 (EDT)

Clarity is mandatory.  What text exactly is not clear?

thanks

/jim

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 26 Jun 2001 13:00:27 +0900

>Clarity is mandatory.  What text exactly is not clear?

	at least the following items are not documented on 2553bis-03.
	for most of the items we agreed to disagree (or to leave them
	unspecified) on apifolks list.
	they raise fundamental portability issues when you implement more
	complex applications like BIND9 (see BIND9 doc/misc/ipv6).
	(NOTE: the following items does not suggest anything outside of
	2553bis-03, like changes to IPv4 mapped address behavior)

	http://www.kame.net/newsletter/20010504/
	http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/bindtest/
	for the current status of the world - everyone is doing this
	differently.

itojun

with IPV6_V6ONLY = off on AF_INET6 socket, if you bind(2) to A, and then
bind(2) to B, what happens?  will it raise error or will it go successful?
	pick A and B from the following.  we need to define all combinations.
	:: ::1 0.0.0.0 127.0.0.1 ::ffff:0.0.0.0 ::ffff:127.0.0.1
no consensus on apifolks (leave it unspecified)

with IPV6_V6ONLY = on on AF_INET6 socket, if you bind(2) to A, and then
bind(2) to B, what happens?  will it raise error or will it go successful?
	ditto
almost no consensus on apifolks (leave it unspecified), but it seems that
most people are happy to allow 0.0.0.0 bind(2) after :: bind(2).

what happens if you mix IPV6_V6ONLY = on AF_INET6 socket and off AF_INET6
socket with the above?
no consensus on apifolks (leave it unspecified)

after all bind(2) operation combintion, who will receive the inbound traffic?
for example, if you permit both :: and 127.0.0.1 to bind(2), what kind of
traffic goes to which?  how about :: and 0.0.0.0? (traffic from 10.0.0.1
go to the former as if from ::ffff:10.0.0.1, or the latter as if from 10.0.0.1?)
no consensus on apifolks (leave it unspecified)

what should getaddrinfo return on the following invocation:
	memset(&hints, 0, sizeof(hints));
	hints.ai_flags = AI_PASSIVE;
	hints.ai_socktype = SOKC_STERAM;
	getaddrinfo(NULL, "80", &hints, &res);
consensus seems to be both :: and 0.0.0.0, in this order.

what should getaddrinfo return on the following invocation:
	memset(&hints, 0, sizeof(hints));
	hints.ai_socktype = SOKC_STERAM;
	getaddrinfo(NULL, "80", &hints, &res);
consensus seems to be both ::1 and 127.0.0.1, in this order.

can we return items other than AF_INET/AF_INET6 from getaddrinfo?
no consensus so far, Linux guys and NRL seem to want this.

can we issue setsockopt(IPV6_V6ONLY) after bind(2) or connect(2)?
consensus seems to be NO.
--------------------------------------------------------------------
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, 26 Jun 2001 14:57:02 +0200

=> we introduce the V6ONLY stuff in order to fix this. Are you
saying there are still issues if:
 - the implementation is RFC 2553 bis compliant
 - the implementation has IPV6_V6ONLY as specified in the draft
 - the implementation has a BSD style SO_REUSEADDR
?

=> this is the only item about this stuff which is not yet in the draft.
It should not change the way to code applications, it is just a specification
for an error/undefined behaviour case.

Regards

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 26 Jun 2001 23:10:51 +0900

> - the implementation has a BSD style SO_REUSEADDR

	IPV6_V6ONLY is a good thing, but there still are items unclear.
	please re-read drafts with fresh eyes, and you'll find out.

itojun