At Wed, 14 Apr 2010 07:58:05 -0400, Simon Perreault <simon.perrea...@viagenie.ca> wrote:
> > So in case of TCP, client which tries to connect to the server, should > > provide its link-local source address during socket(), bind() calls. > > No. On the client side there should be no bind() call, and the socket() > call is unaffected since it doesn't take any address parameter. In the > connect() call, for the struct sockaddr parameter, the sin6_addr member > will contain the server's link-local address and the sin6_scope_id > member will contain the scope id of the client's interface on which the > server can be reached. And, if the implementation supports an extension to textual address representation as described in RFC4007 Section 11, and if the application uses the getaddrinfo(3) library function that understands the extension, the application doesn't have to do anything about sin6_scope_id. I don't know how many implementations support this extension, but all BSD variants should support it, and Linux (i.e. glibc getaddrinfo) seems to support it. I heard Windows also support the extension, but I don't know much about it. BTW: to be pedantic as a co-author of RFC4007, I'd like to note that "link" is a broader scope than "interface", at least architecturally. So, for example, two different interfaces can belong to the same single link, and "the sin6_scope_id member will contain the scope id of the client's interface on which the server can be reached." should actually read "...client's link on which ...". In practice, however, many (if not all) implementations assume one-to-one mapping between links and interfaces, so we can normally use "interface" and "link" interchangeably. > > Based on that IPv6 stack will figure out the out-going interface. > > There is no need for the stack to "figure out" the outgoing interface > since the application tells it plainly in the sin6_scope_id parameter. That's true, although I've heard there used to be an implementation that tries neighbor discovery on all possible links when the outgoing link is ambiguous from the destination address. I'd also like to note that RFC4007 suggests the implementation have the notion of "default scope zone". In some sense, it could be considered a way for the stack to figure out outgoing link (interface) when it's ambiguous. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
