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

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 23 Jun 2001 02:57:14 +0900

>I was under the impression that IPV6_V6ONLY after a bind() should just
>plain fail, in which case the problem you describe above wouldn't
>happen.

	that makes sense and eliminates many of scenarios i had in mind.
	thanks.  i still need to go through a lot of cases...

itojun
--------------------------------------------------------------------
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: "Dave Thaler" <[email-masked]>
Date: Fri, 22 Jun 2001 10:37:18 -0700

Itojun writes:
> >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option
> >
> >   Then the IPv6 sockets would have to be explicitly allowed to
accept
> >   IPv4 connections. So the programs that use the IPv6 centric way
have
> >   to be modified a bit, but the buggy implementations and the
unworkable
> >   one could be corrected without losing features. Just making
> >   IPV6_V6ONLY default to on would have the same results.
> 
> 	I really love to see this happen (polarity change is enough).
> 	also, if IPv4 mapped address support becomes optional
(explicitly)
> 	to OS implementers it would be much better.
> 
> 	However, we need to be careful - after looking into IPV6_V6ONLY
(or
> 	IPV6_ACCEPTV4MAPPED) more closer, I came to realize some mess in
> 	setsockopt(2) behavior.
> 
> 	for example:
> 	- A issues bind(:: port 80).  as IPV6_V6ONLY is turned on, it
grabs
> 	  IPv6 traffic only.
> 	- B issues bind(0.0.0.0 port 80).  it grabs IPv4 traffic only.
> 	- now, turn off IPV6_V6ONLY on A.  what should happen?
> 	  (1) check if there's anyone listening to 0.0.0.0 port 80.
since
> 	  there is B, the setsockopt should fail.
> 	  (2) doesn't matter.  if there's B, IPv4 traffic goes into B as
> 	  B gives better match than A to any IPv4 traffic.
> 	  btw, there's no spec talks about how traffic should be routed
> 	  to which socket!
> 
> 	there are A LOT of combinations we need to think about.

-Dave