I think I may have been misunderstood. Let me see if the response clears it
up?
>The discussion below raises concerns with our proposed draft for
>an SCTP sockets API. SCTP is a reliable datagram transport developed
>by SIGTRAN to carry telephony signaling information.
>One distinctive feature of SCTP is direct support for multi-homed
>hosts. SCTP has the notion of a "primary address" to which it sends
>most packets. It may optionally send heartbeat messages to other
>addresses of a correspondent node. If the primary fails SCTP switches
>to a different correspondent address.
>The issue is that a single host may have both IPv4 AND IPv6
>interfaces. SCTP allows a single association (connection) to span
>both kinds of interface. In our API draft we have suggested af_inet6
>as the socket type for associations with mixed address types.
This is a good idea and why I believe a hybrid stack is far superior to
a pure dual stack implementation. This paradigm is also inline with the
IPv6 deployment message which is IPv4/IPv6 Integration not Migration.
So I am real happy to hear SCTP is thinking that way too.
>Effectively, we can create a passive socket which listens for
>connections on both af_inet and af_inet6 ports.
Yes.
>Jim Bound's comment appears to claim this is a bad idea:
>>An af_inet6 socket should not accept a connection for an af_inet socket.
If there is a v4 listener and a v6 listener then that is fine. the
af_inet connect in should go to the v4 listener and an af_inet6 connect
in should go to the v6 listener. But it is perfectly valid for a v6
listener to accept connections from af_inet and af_inet6 incoming
connections, where af_inet will be mapped addresses. An ISV
server app can port to IPv6 supporting both v4 and v6, using af_inet6.
Above what I am saying is if a v4 listener and a v6 listener exist,
then af_inet incoming connections should be sent to the v4 listener.
Good catch I made to many assumptions about after the preposition "for"
and it was too terse. But that is what I mean't by the prep phase
"for an af_inet socket". Meaning let the v4 listner have that
connection, not the v6 listener. Sorry.
There is an issue for the case where an app that is only doing v6
listener for both incoming af_inet and af_inet6, where the app may want
to not receive any connections from v4. Bill Sommerfield pointed this
out to me offline. The issue is that the v6 socket binds before a v4
bind and the v6 socket receives the v4 address as v4mapped. What we
probably want to do is have a setsockopt in rfc2553bis that says DON"T
ACCEPT V4MAPPED connections (there are other ways to do this but the
socket level option is the cleanest). But the idea is to not have
applications have to run two instances for v4 and v6, but only one
instance (e.g. telnet, ftp, NFS, sctp app, oracle app). It also permits
ISVs to ship one code base and if the user does not even use IPv6 the
app still works, until the user turns on IPv6 ---> Integration.
This will come up at ipng meeting via Dave Thaler agenda item.
>May I invite you to read draft-stewart-sctpsocket-sigtran-00.txt and
>comment? Have we missed a critical IPv6 consideration?
Its on my plate to read. I for one will try to respond to you privately and
any other authors (as I am not on sigtran and trying to avoid that) before
next Monday a.m. Do you want me to respond to the list if I see holes?
Your call?
thanks for listening,
/jim
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
