Re: [RFC] AI_ADDRCONFIG tweaks?
Le 2014-05-02 04:13, Jérémie Courrèges-Anglas a écrit : I don't like AI_ADDRCONFIG. It's useless as specified, and making it useful requires interpretations and deviations. Can you justify this? Sounds to me like a blanket statement as it is. My understanding is that its goal is to solve a real world problem, as in avoiding useless and potentially harmful DNS requests. So why not make it do that, and just that? Because I don't think the end goal is preventing IPv6 link-local communication, or communication with ::1 or localhost, etc. I don't understand the above paragraph at all. Facts only please, and no hyperbole. What's the problem exactly? -bit is set, IPv4 addresses will be returned only if an IPv4 address is -configured on an interface, and IPv6 addresses will be returned only if an IPv6 -address is configured on an interface. +bit is set, DNS requests for IPv4 addresses will be performed only if an +IPv4 address is configured on an interface, and DNS requetsts for IPv6 +addresses will be performed only if an IPv6 address is configured on an +interface. Targeting only DNS is wrong. That's not at all what AI_ADDRCONFIG does. It is of no use to return an IPv6 address that you found in a non-DNS database if the host has no IPv6 address configured on its interfaces. But take the above with a grain of salt because I absolutely don't understand the problem you're trying to fix. Simon
Re: [RFC] AI_ADDRCONFIG tweaks?
Simon Perreault si...@per.reau.lt writes: Le 2014-05-02 04:13, Jérémie Courrèges-Anglas a écrit : I don't like AI_ADDRCONFIG. It's useless as specified, and making it useful requires interpretations and deviations. Can you justify this? Sounds to me like a blanket statement as it is. Didn't you need to make it ignore link-local addresses to make it useful? My understanding is that its goal is to solve a real world problem, as in avoiding useless and potentially harmful DNS requests. So why not make it do that, and just that? Because I don't think the end goal is preventing IPv6 link-local communication, or communication with ::1 or localhost, etc. I don't understand the above paragraph at all. Facts only please, and no hyperbole. What's the problem exactly? Let's say you have a machine with no IPv6 address configured (or rather, only link-local addresses configured and ::1 on lo0). With the AI_ADDRCONFIG flag (either set explicitely or assumed if the caller passes no hints structure): - getaddrinfo(fe80::...%em0) fails with no address associated with name - getaddrinfo(::1) fails similarly - more generally, getaddrinfo(numeric IPv6 address) fails with no address associated with that name - getaddrinfo(localhost) now requires IPv4/v6 connectivity on non-lo interfaces. oops. All those are IMHO poor behavior (lies), especially since getaddrinfo is supposed to handle pretty much anything you're throwing at it. Yet it is now the default behavior when you pass no hints, and adding explicit AI_ADDRCONFIG flags to base programs has been recently proposed. -bit is set, IPv4 addresses will be returned only if an IPv4 address is -configured on an interface, and IPv6 addresses will be returned only if an IPv6 -address is configured on an interface. +bit is set, DNS requests for IPv4 addresses will be performed only if an +IPv4 address is configured on an interface, and DNS requetsts for IPv6 +addresses will be performed only if an IPv6 address is configured on an +interface. Targeting only DNS is wrong. That's not at all what AI_ADDRCONFIG does. I'm proposing to change its semantics so that it targets only DNS. Saying that it doesn't target DNS doesn't help much. :) Why do we ignore link-local IPv6 addresses when iterating over the result of getifaddrs? Because without this AI_ADDRCONFIG would be almost useless; yet the spec doesn't say we should ignore link-local addresses... It is of no use to return an IPv6 address that you found in a non-DNS database if the host has no IPv6 address configured on its interfaces. ... I see it the other way. I think that if AI_ADDRCONFIG has been proposed to avoid *useless and potentially harmful* DNS requests. I'd feel better if it had not been adopted in the first place, because it's basically useless if interpreted literally. But also it helps to cope with the stupid behavior some CPEs exhibit, instead of forcing people (hi, Orange) to fix their errors. That is not a good thing IMHO. But take the above with a grain of salt because I absolutely don't understand the problem you're trying to fix. I hope its clearer this way. :) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [RFC] AI_ADDRCONFIG tweaks?
Le 2014-05-02 10:48, Jérémie Courrèges-Anglas a écrit : Let's say you have a machine with no IPv6 address configured (or rather, only link-local addresses configured and ::1 on lo0). With the AI_ADDRCONFIG flag (either set explicitely or assumed if the caller passes no hints structure): - getaddrinfo(fe80::...%em0) fails with no address associated with name - getaddrinfo(::1) fails similarly - more generally, getaddrinfo(numeric IPv6 address) fails with no address associated with that name - getaddrinfo(localhost) now requires IPv4/v6 connectivity on non-lo interfaces. oops. All those are IMHO poor behavior (lies), especially since getaddrinfo is supposed to handle pretty much anything you're throwing at it. I think you need to change your expectations. If you're running on a host without IPv6, why would you want getaddrinfo() to return any IPv6 results? What good would it do to you? AI_ADDRCONFIG is all about what it *returns*. The fact that it allows skipping DNS requests is a nice side-effect. If your program needs to resolve addresses for the sake of resolving addresses, and you want accuracy, you need to explicitly unset AI_ADDRCONFIG. You're writing something special. In the general case, where you will just connect() or bind() on the returned addresses, AI_ADDRCONFIG makes sense as is. Has this caused any real-world problems? Simon
Re: [RFC] AI_ADDRCONFIG tweaks?
Simon Perreault si...@per.reau.lt writes: Le 2014-05-02 10:48, Jérémie Courrèges-Anglas a écrit : Let's say you have a machine with no IPv6 address configured (or rather, only link-local addresses configured and ::1 on lo0). With the AI_ADDRCONFIG flag (either set explicitely or assumed if the caller passes no hints structure): - getaddrinfo(fe80::...%em0) fails with no address associated with name - getaddrinfo(::1) fails similarly - more generally, getaddrinfo(numeric IPv6 address) fails with no address associated with that name - getaddrinfo(localhost) now requires IPv4/v6 connectivity on non-lo interfaces. oops. All those are IMHO poor behavior (lies), especially since getaddrinfo is supposed to handle pretty much anything you're throwing at it. I think you need to change your expectations. I don't think that any of the failing examples given above can qualify as reasonable expectation. If you're running on a host without IPv6, why would you want getaddrinfo() to return any IPv6 results? What good would it do to you? What's a regular OpenBSD host with no IPv6? I'd assume that it is a host that can perform IPv6 connections to ::1 / localhost and reach its neighbors through link-local addresses. It is certainly not a host that has been butchered by removing option INET6 or removing all automatically configured IPv6 address (link-local / lo0). If you pass a raw IPv6 address to getaddrinfo, is no address associated with name a reasonable result? AI_ADDRCONFIG is all about what it *returns*. The fact that it allows skipping DNS requests is a nice side-effect. Yet people use it for this side-effect, else why would you propose to make the base programs use it (explicitely) as a way to mitigate the impact of switching to family inet6 inet4 by default? If your program needs to resolve addresses for the sake of resolving addresses, and you want accuracy, I think that I've clearly explained that it is more than mere accuracy. you need to explicitly unset AI_ADDRCONFIG. You're writing something special. In the general case, where you will just connect() or bind() on the returned addresses, AI_ADDRCONFIG makes sense as is. Has this caused any real-world problems? All the examples I've listed above are cases where programs that used no hints will now fail. I think they're valid, real-world cases. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [RFC] AI_ADDRCONFIG tweaks?
I think I have already addressed all your points below, no need to rehash endlessly. I'll let others chime in. I'm still very interested in any real-world problems this might have caused. Simon Le 2014-05-02 11:35, Jérémie Courrèges-Anglas a écrit : Simon Perreault si...@per.reau.lt writes: Le 2014-05-02 10:48, Jérémie Courrèges-Anglas a écrit : Let's say you have a machine with no IPv6 address configured (or rather, only link-local addresses configured and ::1 on lo0). With the AI_ADDRCONFIG flag (either set explicitely or assumed if the caller passes no hints structure): - getaddrinfo(fe80::...%em0) fails with no address associated with name - getaddrinfo(::1) fails similarly - more generally, getaddrinfo(numeric IPv6 address) fails with no address associated with that name - getaddrinfo(localhost) now requires IPv4/v6 connectivity on non-lo interfaces. oops. All those are IMHO poor behavior (lies), especially since getaddrinfo is supposed to handle pretty much anything you're throwing at it. I think you need to change your expectations. I don't think that any of the failing examples given above can qualify as reasonable expectation. If you're running on a host without IPv6, why would you want getaddrinfo() to return any IPv6 results? What good would it do to you? What's a regular OpenBSD host with no IPv6? I'd assume that it is a host that can perform IPv6 connections to ::1 / localhost and reach its neighbors through link-local addresses. It is certainly not a host that has been butchered by removing option INET6 or removing all automatically configured IPv6 address (link-local / lo0). If you pass a raw IPv6 address to getaddrinfo, is no address associated with name a reasonable result? AI_ADDRCONFIG is all about what it *returns*. The fact that it allows skipping DNS requests is a nice side-effect. Yet people use it for this side-effect, else why would you propose to make the base programs use it (explicitely) as a way to mitigate the impact of switching to family inet6 inet4 by default? If your program needs to resolve addresses for the sake of resolving addresses, and you want accuracy, I think that I've clearly explained that it is more than mere accuracy. you need to explicitly unset AI_ADDRCONFIG. You're writing something special. In the general case, where you will just connect() or bind() on the returned addresses, AI_ADDRCONFIG makes sense as is. Has this caused any real-world problems? All the examples I've listed above are cases where programs that used no hints will now fail. I think they're valid, real-world cases.
Re: [RFC] AI_ADDRCONFIG tweaks?
On Fri, May 02, 2014 at 05:35:13PM +0200, Jérémie Courrèges-Anglas wrote: | If you're running on a host without IPv6, why would you want | getaddrinfo() to return any IPv6 results? What good would it do to you? | | What's a regular OpenBSD host with no IPv6? I'd assume that it is | a host that can perform IPv6 connections to ::1 / localhost and reach | its neighbors through link-local addresses. Why would you expect to be able to reach your neighbors through link-local addresses if you have no IPv6 (which I take to mean 'no *configured* IPv6', please correct me if I'm wrong here)? I believe your expectation here is wrong (although it is the current state of IPv6 on OpenBSD). Can you explain why you disagree? (sorry to hijack the thread, your remark piqued my interest) Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: [RFC] AI_ADDRCONFIG tweaks?
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: Simon Perreault si...@per.reau.lt writes: [...] Has this caused any real-world problems? All the examples I've listed above are cases where programs that used no hints will now fail. I think they're valid, real-world cases. Some bugs: - https://sourceware.org/bugzilla/show_bug.cgi?id=12398 - http://article.gmane.org/gmane.comp.freedesktop.xcb/6973 - https://svn.boost.org/trac/boost/ticket/8503 Links with more information: - http://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG - https://fedoraproject.org/wiki/Features/FixNetworkNameResolution - http://tools.ietf.org/html/rfc2553 obsolete and also informational, specified AI_ADDRCONFIG for DNS () purposes only (dunno why this has been changed) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [RFC] AI_ADDRCONFIG tweaks?
Le 2014-05-02 13:19, Jérémie Courrèges-Anglas a écrit : Some bugs: - https://sourceware.org/bugzilla/show_bug.cgi?id=12398 - http://article.gmane.org/gmane.comp.freedesktop.xcb/6973 - https://svn.boost.org/trac/boost/ticket/8503 Links with more information: - http://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG - https://fedoraproject.org/wiki/Features/FixNetworkNameResolution - http://tools.ietf.org/html/rfc2553 obsolete and also informational, specified AI_ADDRCONFIG for DNS () purposes only (dunno why this has been changed) Thanks! I'll look at these in detail and get back to you. Simon
