> To give a v4-specific listener priority over a v6 listener is not up
> to the API but the stack's PCB lookup function, yes? The only reason
> I can see for a sockopt is to allow overriding this behavior -- but
> the v6 application could do this more simply by binding to the v4
> address (be it wildcard or not) in addition to any others.
Another clarfication on the meaning of binding in the SCTP context. The above
just talks about finding an endpoint to take an association request. In SCTP
an endpoint can have multiple addresses. An SCTP endpoint can use any of
those addresses to communicate with a peer endpoint. The binding to
in6addr_any means that when setting up an association, the system will
associate all its addresses to the endpoint. This means that the peer can use
any (there is always a primary) of those addresses to communicate with it. In
the current draft, all means both v4 and v6 addresses. This may not be
desirable if the app uses some v6 features, e.g. routing header, which are not
applicable to v4 addresses. This means that SCTP may not be able to use those
v4 addresses associated with the endpoint. If this is the case, why should
those v4 addresses be associated with the endpoint in the first place?
Note that how the system picks those addresses are still not "clearly"
specified. It may not make sense to pick all addresses associated with an
interface. The reason for having multiple addresses is that SCTP can failover
to another address if the primary fails. But if all the addresses are
associated with an interface, failover may not make sense at all. There are
still a lot of work to be done in this area in the draft...
K. Poon.
[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]
--------------------------------------------------------------------
