we do not document product platform differences in the IETF.
but here is how the market will work.
the market picks a market leader. today that market leader for most of IP
stuff for "Servers" is Sun Microsystems (not all but most if you look at
market share). For the client its Microsoft.
If Microsoft uses v6only as default and does not adhere to 2553 most
likely thats the way all client apps will code.
If Sun uses v6only as default the same.
The rest of us are debating academics here and the majority of folks
believe the model we have is correct.
Those viewing the purist API model of Address Family independence believe
IPv4 and IPv6 are separate protocols. I for one think that is not true
and an error in their model. IPv6 is an extension to IPv4. Hence IPv6 AF
should be able to deal with IPv4 notation of IPv6 which is v4mapped.
Some others believe we have to worry about yet another real new protocol
such as OSI in the past. I think that is nonsense for at least 10 years.
In Internet time 10 years will change so many things the API is the least
of our worries as Internet engineers IMO.
The other problem is some have built a complete dual stack IPv4 and IPv6.
If this was done it was a poor design and coding effort or a hack job to
get it done quick. They are dead meat with the variant issues such as
crossover in kernel code base suppoting two stacks, code bloat, and all
the things an experienced (at least 10 years of programming) OS network
kernel engineer would not do. These are just broken and the market will
force them to fix it. All we ever ask for in any specs in this area is a
dual IP layer.
We should wrap up the 4+28 split merge the text with what IEEE 1003 has
done (which is going to be a lot of work for us authors fyi) and ship this
spec to the market.
It is in all our interests if we stop this now. We are at a stalemate and
stalemate means prior art wins IMO and that prior art is what the Base API
spec has preached and delivered for 6 years.
Otherwise we will have a shism here and if you think its bad now imagine
how bad it will be if the UNIX vendors go one way, Microsoft goes another
way, and the public domain stuff goes another way.
Just use 2553-bis-03 and be done with it.
Anyone who can't make it work please send the code that won't work and I
will bet those who support 2553-bis-03 will show you how it works.
But if its just a matter of style then thats another issue.
/jim
"Shout it out G.L.O.R.I.A." (Them [Van Morrison])
On Mon, 25 Jun 2001, Jun-ichiro itojun Hagino wrote:
> >> we really need to convince random book authors to update their
> >> programming examples, from gethostbyname() to getnameinfo()...
> >how can you expect them do so, when there's so much difference between
> >the behaviour of the various TCP/IPv6 stacks?
>
> yes, that is the issue. i was trying to suggest example be using
> getaddrinfo(3) loop, which should work for the most cases.
> if OS designers are sane enough to design bind(2) behavior and
> getaddrinfo(3) behavior with care, getaddrinfo(3) loop has a good
> chance to work in many cases.
> we need to document platform differences, of course.
>
> for exaplme, for server side, assume that the goal is to accept both
> IPv4 and IPv6 traffic.
> - if getaddrinfo(3) returns :: and 0.0.0.0, the code will work
> for the following cases:
> bind(2) in any order is permitted, traffic accepted as
> necessary
> bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket
> grabs IPv4 traffic
> but not for the following case:
> bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket
> does not grab IPv4 traffic (seems very broken to me)
> - if getaddrinfo(3) returns :: only, it will work for the following
> cases:
> AF_INET6 socket grabs IPv4 traffic
> but not for the following cases:
> AF_INET6 socket does not grab IPv4 traffic (getaddrinfo seems
> broken to me on this platform)
>
> (note to OS imlementers - so getaddrinfo(3) behavior has to be
> carefully designed consdidering your bind(2) and IPv4 mapped addr
> behavior!)
>
> >IMHO, draft-ietf-ipngwg-rfc2553bis-03.txt should specify what is the
> >correct behaviour for bind(2). i vote for the *BSD one: by having two
> >different sockets binding indipendently one from the other, we can
> >get rid of all the problems given by IPv4-mapped IPv6 address, and
> >have true af-indipendence. the IPV6-ONLY option and IPv4-mapped IPv6
> >address should not be deprecated, but their use should be unrecommended.
> >this policy would lead to the best result with only minor changes in the
> >draft and in the existing ipv6 implementations.
>
> I have been trying SO HARD to suggest it in api discussion group (which
> is a small group of people who contributed 2553bis-03 updates), but
> was rejected. it is a holy war where there's no end. one side
> advocates AF_INET6 only world, one side advocates AF_INET6/AF_INET
> splitted socket (or at least make the default behavior so).
> I'm of course in the second camp.
>
> in fact, as far as i understand, there's no good standard document
> on bind(2) interaction between two IPv4 sockets. so defining it
> for IPv4/v6 interaction would be a big task.
>
> >in fact, when called with AI_PASSIVE flag set and AF_UNSPEC protocol
> >family, in a both ipv4- and ipv6-compliant system, getaddrinfo should
> >return two different results (::1 for ipv6 and 127.0.0.1 for ipv4).
> >moreover, calling getaddrinfo with AF_UNSPEC protocol family should
> >produce a result that's the sum of the results of two getaddrinfo
> >calls (one for AF_INET and one for AF_INET6).
> >
> >getnameinfo does not need to be modified.
>
> it is what i have been believed, but there are people believing in
> different behavior.
>
> >> it is a bit dated, but the content should be still valid.
> >> do you have any suggestions for improvements?
> >some code examples would be useful. the paper doesn't explain how to
> >handle IPv4-mapped IPv6 address and the IPV6_ONLY option, for example.
>
> aha, I was biased to independent AF_INET/AF_INET6 implementation ;-)
> as IPV6_V6ONLY support is still rare, not sure if it worth document it.
> thanks anyways.
>
> 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 PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
