RE: SCTP API draft (was Re: New "IP Version 6 Addressing Architec ture" draft)

2000-07-26 Thread Kacheong Poon
> If the multiple addresses have different prefixes, then the packets will be > routed through different paths. This provides a useful failover situation, > from a failing provider to a valid provider, even if the interface is the > same. This can be one criterion in picking multiple addresses fr

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

2000-07-26 Thread Kacheong Poon
> 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

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

2000-07-25 Thread Kacheong Poon
> 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. Allowing bind() to subsets of addresses does not necessarily mean that such option is of no use. A SCTP app may

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

2000-07-25 Thread Kacheong Poon
> 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...). This is a point which is not clear in the c