Using AF_INET6 as only socket and handling both v4 and v6 can only be done well if the implementation supports a hybrid v4-v6 stack. A pure dual stack (code path for v4 and code path for v6 see URL pdf below) is not friendly to use v4-mapped and I will assume all understand that on this list. Basic examples that benefit from v4mapped are any app that runs via inetd (e.g. ftp, telnet) and for more complex applications like Netscape browser and Mozilla example removes the need for if and test conditions for address types. Clearly if a vendor platform does not support a hybrid stack and thus not optimal for v4mapped it creaates an engineering trade-off. The market should not be driven by a few implementations in any scenario is my hope. Most all implementations support the use and option of v4mapped. We shall see how the application market develops and in progress now. Another example is a large database application vendor can use AF_INET6 to support both v4 and v6 as one release and it reduces that part of the code path length to deal with both address types and the user would be transparent to how v4 or v6 is used by the application.
See the IPv6 porting explanation at the URL below: http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html Good slides depicting the use of both IPv6-ONLY and v4mapped http://www.usipv6.com/2003arlington/presents/Eva_Castro.pdf /jim > -----Original Message----- > From: Colm MacCarthaigh [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 02, 2005 5:13 AM > To: Jeroen Massar > Cc: Bound, Jim; IPv6 WG > Subject: Re: IPv6 Address Architecture update question > > On Wed, Feb 02, 2005 at 10:41:08AM +0100, Jeroen Massar wrote: > > We still have a chance IPv4 mapped to at least _deprecate_, that is > > what I mentioned in my other message, the usage of these > addresses and > > to note that implementors should really be using separate sockets, > > which is also what getaddrinfo() tells one to do. > > RFC3493 solves this by having IPV6_V6ONLY. We just need to > wait for all platforms to implement it :) > > > What has Netscape to do with Apache? Or am I really missing > something? > > Then again I don't follow corporate takeovers and such, got better > > things to do; Netscape do have some influence with > Mozilla/Firefox et > > al, and they also had a lot of problems with this, they actually > > almost refused to do a Windows IPv6 version because they didn't > > understand the concept of a separate IPv6 and IPv4 socket. Also see: > > https://bugzilla.mozilla.org/show_bug.cgi?id=175340 > > Just to clear things up, I wrote a lot of the code that deals > with it in Apache httpd, and apr. And I've never worked for > Netscape. I think Jim may be implying that Netscape took a > different (possibly superiour) approach. I know not :) > > > There are many more examples of code out on the internet that > > demonstrate that having the v4-mapped addresses only gives a lot of > > issues. You haven't named one application though that does > not have it. > > In fairness, this does not matter. mapped-addresses are > useful from a certain perspective anyway. If there is some > in-house trivial application that only needs to run on Linux, > there is no good reason why mapped-addresses should not be > used as an easy migration. > > Whether or not the portability problems outweigh this kind of > limited benefit is a subjective judegment call - and one on > which consensus is unlikely to ever be reached. > > RFC3493 encourages vendors to implement the IPV6_V6ONLY > option (something neither 2133 nor 2553 had), so that's the > nod that's needed on this front. > > Really the only remaining portability issue is the default > behaviour of > bind(::) (without any specific options set). > > So in summary, my mind has been changed a little on mapped-addresses > - in that although I wouldn't use them, they have a use in limited > circumstances - but some kind of encouragement to vendors > to consolidate a standard behavior for a bind/listen call > could be desirable. > > -- > Colm MacCárthaigh Public Key: > [EMAIL PROTECTED] > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
