Adding support for IPv6 in IPv4 client/server apps - sin6_flowinfo and sin6_scope_id fields?

Question

I work on implementing IPv6 support for several applications, but I wondered what are these 2 fields for. There are so few questions about this here so I'm not sure I got it right.

• About scope ID ( sin6_scope_id ) - well, Q1 , Q2 , Q3 and Q4 gave me idea about the scope ID and I think I get it. So, I'll have to add one more config parameter, to make the scope-id configurable. (I decided to add this here, in case that someone is interested in this). Shortly - scope ID is necessary to uniquely determine which is the device, that should handle the traffic - because there may be several interfaces, with the same IP, but with different (interface?) ID. So far, so good.
• But how about the "flow information" ( sin6_flowinfo )
  • What is it for? I couldn't find anything interesting about that. I read the RFC but it didn't help me at all.
  • Are there some possible values for sin6_flowinfo (like - several values, like flags, which mean something), or it's like the sin6_scope_id - may be any value, depending on the device, I'm trying to connect to?
  • Should I worry about it at all, or I my just leave it 0 (as in Beej's Guide to Network Programming . And yes, I tried that, it works, but I'm not sure if it works only in this case (if it depends on some network configuration), or it will always work, if it's set to 0?
  • Or, maybe, I should make it configurable, I mean - add one more config option and let the user defines it's value?
  • google-ing "sin6_flowinfo" gives me struct definitions and man pages, nothing useful about this field. Any interesting source? (understandable one..not RFC :D )

---

EDIT: Well, after @glglgl 's answer and after the hint, that sin6_flowinfo may be obsolete, I found some interesting sources: RFC: IPv6 Flow Label Specification , IETF draft: Flow Label as Transport-Layer Nonce , Practical guide for solaris and wikipedia .
The field is not obsolete (or I couldn't find such source, that confirms this), but it looks like 0 as value is good enough.

Answer 1

The best way to go is to use getaddrinfo().

Pseudo code:

struct addrinfo *restrict hints = { .ai_family = AF_UNSPEC, .ai_socktype = SOCK_STREAM };
struct addrinfo * res, r;
if (0 == getaddrinfo("foo.bar.baz", "http", &hints, &res)) {
    for (r=res; r; r=r->ai_next) {
        sock = socket(r->ai_family, r->ai_socktype, r->ai_protocol);
        connect(sock, r->ai_addr, r->ai_addrlen);
        if error: continue
        break
    }
}
freeaddrinfo(res);

This will take the worry about sin6_scope_id from you; which is normally 0, except if you have link-local addresses like fe80::1234:56ff:fe78:9abc%eth2. This eth2 is converted to the correct scope ID.

sin6_flowinfo is obsolete (AFAIK) and thus set to 0 in your resulting struct addrinfo's ai_addr.