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