>> 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.
>
>Good. I think I now understand your distinction between a hybrid
>stack and a dual stack.
Great. See my last mail to Mauro too just sent I go into more detail on
the principle (or is that principal :----))
>>> 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.
>...
>> 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.
>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).
>> 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).
>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.
>> 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 is definately the way to go. I shouldn't even have to "turn on
>IPv6 Integration". If all of my interfaces are ifconfig'd with v4
>addresses, then I don't do IPv6...
I agree. Simple is beautiful to most users.
>> This will come up at ipng meeting via Dave Thaler agenda item.
>
>I'll make a point of attending, thanks.
That would be good as your one of those **real** users of this API we
need to hear from.
/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]
--------------------------------------------------------------------
