Dear All:
One note to all you readers.. this draft is a very very early
first cut. We rushed it out to get it in to the drafts editor
and thus it requires quite a bit of work yet :->
I did not get Jim's original email so I have a hard time
reading the snippet below and making sense of it...
I can see a "Tcp compatible issue" in that it may be a bit
strange to listen on a "compatible" type socket and get
a connection to one that is only IPv4.. This may just be
a issue of NOT allowing it on the "TCP compatability type"
socket... The new interface I think should work fine ..I don't
see issues with it. I would be glad to note comments on these
and other items... as I said it is rough I am sure there are
all sorts of spelling and grammer problems yet to be fixed ..
Regards
R
La Monte Henry Piggy Yarroll wrote:
>
> 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.
> Effectively, we can create a passive socket which listens for
> connections on both af_inet and af_inet6 ports.
>
> 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.
>
> May I invite you to read draft-stewart-sctpsocket-sigtran-00.txt and
> comment? Have we missed a critical IPv6 consideration?
> --
> Put no trust in extortion, La Monte Henry Piggy Yarroll
> set no vain hope in plunder; NIC Handle LY
> if riches increase,
> do not set your heart upon them.
>
> Jim Bound <[EMAIL PROTECTED]> writes:
> >Mauro,
> >
> >>> but v4 mapped does not affect the ISV porting effort at all and in fact
> >>> makes their job much easier if the platform they are porting to supports
> >>> that paradigm.
> >
> >>you are absolutely right. my concern was about api issues. a modification
> >>in the behaviour of af_inet6 passive socket, so that they are not allowed
> >>to accept connections from af_inet sockets, would have imho nightmarish
> >>effects.
> >
> >An af_inet6 socket should not accept a connection for an af_inet socket.
> >Any implementation specific code path in a hybrid stack (different from
> >a dual stack I think you know??) that does this or neglects the issue
> >will have problems as you state. If an implementation does this it is
> >broken, the market will fix the correction. Also we have never had this
> >problem at any test event. Also early on I have run ftp, telnet, etc at
> >the same time and have not seen any bugs. In fact what you ask is a
> >test at present.
> >
> >No where in any spec do we (the IETF or the XNET TBD API we are buildin
> >the base for here on ipng group) require how one uses mapped,
> >compatible, or native IPv6 addresses. Nor should we other than to
> >define them and make them available to applications via the API.
--
Randall R. Stewart
[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]
--------------------------------------------------------------------
