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.
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.
-Dave
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
