Hi Ashwani,

we'll clarify it. Thanks for the hint.

Best regards
Michael

On May 16, 2007, at 9:46 AM, Ashwani Kathuria wrote:

>
> Hello Michael
>
> Thanks for your response.
>
> The solution of using "packed array" of IPv4 an IPv6 address in  
> sctp_bindx seems more appropriate to me also, as the memory  
> requirements of sockaddr_storage are very high.
> However, I feel that the SCTP socket draft should mention it  
> explicitly so that the implementations may take uniform/standard  
> approach. As any alternate implementation would affect the  
> application using sctp_bindx.
> Thanks & Regards -
> Ashwani Kathuria
>
> A R I C E N T
>
> The Presidency Tower –A, 351/2, Sector 14
> M.G. Road Gurgaon 122001, Haryana, India.
>
> Main     +91 124.417.6333         Extn : 5218
> Fax      +91 124.417.6225
> Mobile   +91 991.142.4546
> www.aricent.com
>
>
>
>
> Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
> 05/15/2007 08:09 PM
>
> To
> Ashwani Kathuria/HSS@HSS
> cc
> tsvwg@ietf.org
> Subject
> Re: [Tsvwg] sctp_bindx with both IPv4 and Ipv6 addresses
>
>
>
>
>
> Hi,
>
> for an IPv4 socket you can only provide struct sockaddr_in.
> For an IPv6 socket a "packed array" can be provided. Any
> mixture of struct sockaddr_in and struct sockaddr_in6.
> Based on the sa_len field on BSD or based on the
> type you know how large that array element is and therefore
> you can compute the beginning of the next one.
>
> Best regards
> Michael
>
> On May 15, 2007, at 12:54 PM, Ashwani Kathuria wrote:
>
> > Hello All
> >
> > I have a little suggestion about the sctp_bindx, please provide
> > your valuable comments in this regard.
> >
> > According to sctp socket draft
> >
> > -------------------------------------
> >    int sctp_bindx(int sd, struct sockaddr *addrs, int addrcnt,
> >                  int flags);
> >
> >   If sd is an IPv4 socket, the addresses passed must be IPv4
> > addresses.
> >   If the sd is an IPv6 socket, the addresses passed can either be  
> IPv4
> >   or IPv6 addresses.
> >
> >   A single address may be specified as INADDR_ANY or IN6ADDR_ANY,  
> see
> >   Section 3.1.2 for this usage.
> >
> >   addrs is a pointer to an array of one or more socket addresses.
> > Each
> >   address is contained in its appropriate structure.  For an IPv6
> >   socket, an array of sockaddr_in6 would be returned.  For a IPv4
> >   socket, an array of sockaddr_in would be returned.
> > -------------------------------------
> >
> > As the 'addr' is a pointer to an array of one or more socket
> > addresses and for IPv6 sockets, an array of sockaddr_in6 would be
> > returned . It means that SCTP application can either give IPv4
> > addresses or IPv6 addresses in the sctp_bindx call but not both at
> > the same time.
> > However, IMO this can be done if the addresses are taken in pointer
> > to the array of sockaddr_storage. Using the array of this generic
> > structure, both IPv4 and IPv6 addresses can be given as input to
> > the sctp_bindx at the same time.
> > Thanks & Regards -
> > Ashwani Kathuria
> >
> > A R I C E N T
> >
> > The Presidency Tower ?A, 351/2, Sector 14
> > M.G. Road Gurgaon 122001, Haryana, India.
> >
> > Main     +91 124.417.6333         Extn : 5218
> > Fax      +91 124.417.6225
> > Mobile    +91 991.142.4546
> > www.aricent.com
> >
> >
> >
> > *****Aricent-Private *****=
> > "DISCLAIMER: This message is proprietary to Aricent and is intended
> > solely for the use of the individual to whom it is addressed. It
> > may contain privileged or confidential information and should not
> > be circulated or used for any purpose other than for what it is
> > intended. If you have received this message in error, please notify
> > the originator immediately. If you are not the intended recipient,
> > you are notified that you are strictly prohibited from using,
> > copying, altering, or disclosing the contents of this message.
> > Aricent accepts no responsibility for loss or damage arising from
> > the use of the information transmitted by this email including
> > damage from virus."
>
>
>
>
> ***********************  Aricent-Unclassified    
> ***********************
> "DISCLAIMER: This message is proprietary to Aricent and is intended  
> solely for the use of the individual to whom it is addressed. It  
> may contain privileged or confidential information and should not  
> be circulated or used for any purpose other than for what it is  
> intended. If you have received this message in error, please notify  
> the originator immediately. If you are not the intended recipient,  
> you are notified that you are strictly prohibited from using,  
> copying, altering, or disclosing the contents of this message.  
> Aricent accepts no responsibility for loss or damage arising from  
> the use of the information transmitted by this email including  
> damage from virus."