Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft)

[La Monte Henry Piggy Yarroll]

On Tue, 25 Jul 2000 14:00:35 -0400 Jim Bound <[EMAIL PROTECTED]> wrote:
>Great.  See my last mail to Mauro too just sent I go into more detail on
>the principle (or is that principal :----))

I didn't see it on either of the lists.  I'm still interested in your
definitions to see if I understand.

>>Is this v4 listener listening on INADDR_ANY and the v6 listener
>>listening on in6addr_any for the same port?  IMHO this should be
>>illegal.  The second listener should get an EBUSY when attempting to
>>bind.
>
>I think it should be illegal too.  Its like running telnetv4 and
>telnetv6 on the same node.  Pretty stupid IMO.  But if we have a socket
>level option to not accept v4mapped for af_inet6 it will let it happen
>in theory (not that I believe we should).

Forget the socket level option--just adopt the SCTP solution in
general.  If you are going to allow binding to subsets of addresses
you might as well make it completely general.

...
>>> 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. [...] 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).
>
>>Blech!  In SCTP we need to allow binding on arbitrary subsets of
>>addresses.  Our solution is to allow multiple calls to bind().  There
>>is nothing special about the sets "all IPv4 addresses" and "all IPv6
>>addresses" (well, there shouldn't be...).
>
>I agree so an sctp app in this case would not set the socket level
>option.

There need not be anything SCTP-specific about calling bind() multiple
times...  You do not need the socket option at all.
-- 
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.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------