Re: resolv.conf(5) says options inet6 does nothing
Jeremie Courreges-Anglas wrote: > New proposal after discussing this with Theo. > > > Index: net/res_init.3 > === > RCS file: /cvs/src/lib/libc/net/res_init.3,v > retrieving revision 1.2 > diff -u -p -r1.2 res_init.3 > --- net/res_init.325 Apr 2020 14:30:05 - 1.2 > +++ net/res_init.325 Apr 2020 15:59:51 - > @@ -183,6 +183,10 @@ feature. > With this option > .Xr gethostbyname 3 > will return IPv6 addresses if available. > +This option is deprecated, software should use the > +.Xr getaddrinfo 3 > +interface instead of modifying the behavior of > +.Xr gethostbyname 3 . > On some operating systems this option also causes IPv4 addresses to be > returned as IPv4-mapped IPv6 addresses. > For example, 10.1.1.1 will be returned as :::10.1.1.1. I like this a lot better, because it is clear it is the OPTION which is deprecated, and subtly hints this option existed for a bad reason.
Re: resolv.conf(5) says options inet6 does nothing
On Sat, Apr 25 2020, Jeremie Courreges-Anglas wrote: > On Fri, Apr 24 2020, Jeremie Courreges-Anglas wrote: >> On Thu, Apr 23 2020, Eric Faurot wrote: >>> On Thu, Apr 23, 2020 at 10:34:39AM -0600, Theo de Raadt wrote: It says the keyword gets parsed, but then does performs no action. But that is different from not parsing it. Additionally, this explains an option which other systems support, and by explaining it this way, it is also explaining our behaviour in case of inet6 vs inet4 conditions. So... I think it should stay. Eric, do you have an opinion? >>> >>> The doc lies because the inet6 option does not set the RES_USE_INET6 >>> flag as stated. I think we should leave the entry in the doc but fix >>> the wording to say it's there for historical reasons and does nothing. >> >> In the diff below I document the behavior on other operating systems >> since this looks useful to Claudio. How does it read? >> >> (I really think this should go but if it doesn't I don't want it to stay >> misleading as it is now.) >> >>> If we want to resurrect that option at some point, maybe we can >>> consider making it set the RES_USE_INET6 flag but that feels like a >>> bad idea right now, and this flag is apparently deprecated. >> >> I wholeheartedly with this, in my book RES_USE_INET6 and "options inet6" >> are just early IPv6 experiments that went nowhere. >> "options inet6" would break most programs that use gethostbyname(3). >> >>> But we should also fix the manpage for res_init(3) as the description >>> of the flag is wrong too. >> >> Diff below. Thoughts, oks? > > Committed, thanks. > > Eric suggested that we mark this option as deprecated. Proposal: New proposal after discussing this with Theo. Index: net/res_init.3 === RCS file: /cvs/src/lib/libc/net/res_init.3,v retrieving revision 1.2 diff -u -p -r1.2 res_init.3 --- net/res_init.3 25 Apr 2020 14:30:05 - 1.2 +++ net/res_init.3 25 Apr 2020 15:59:51 - @@ -183,6 +183,10 @@ feature. With this option .Xr gethostbyname 3 will return IPv6 addresses if available. +This option is deprecated, software should use the +.Xr getaddrinfo 3 +interface instead of modifying the behavior of +.Xr gethostbyname 3 . On some operating systems this option also causes IPv4 addresses to be returned as IPv4-mapped IPv6 addresses. For example, 10.1.1.1 will be returned as :::10.1.1.1. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: resolv.conf(5) says options inet6 does nothing
Jeremie Courreges-Anglas wrote: > On Sat, Apr 25 2020, "Theo de Raadt" wrote: > > This wording doesn't make any sense to me. > > > > When we use the term deprecate, we are talking about interfaces. > > But gethostbyname isn't actually deprecated. getaddrinfo is > > an alternative interface rather than gethostbyname. But gethostbyname > > isn't deprecated. > > I don't understand what the addition mean. > > "This option" kinda implies we're talking about RES_USE_INET6. > Why couldn't it be deprecated? > > What would you suggest? "Using this option together with > gethostbyname(3) is deprecated/discouraged in favor of getaddrinfo(3)"? It is becoming even worse. "because of A, B+C is deprecated" > > At most I think it can > > be said the option is ineffective? > > This option is effective, last commit just made this clear. So it doesn't work. Why document it?
Re: resolv.conf(5) says options inet6 does nothing
On Sat, Apr 25 2020, "Theo de Raadt" wrote: > This wording doesn't make any sense to me. > > When we use the term deprecate, we are talking about interfaces. > But gethostbyname isn't actually deprecated. getaddrinfo is > an alternative interface rather than gethostbyname. But gethostbyname > isn't deprecated. > I don't understand what the addition mean. "This option" kinda implies we're talking about RES_USE_INET6. Why couldn't it be deprecated? What would you suggest? "Using this option together with gethostbyname(3) is deprecated/discouraged in favor of getaddrinfo(3)"? > At most I think it can > be said the option is ineffective? This option is effective, last commit just made this clear. >> Index: net/res_init.3 >> === >> RCS file: /cvs/src/lib/libc/net/res_init.3,v >> retrieving revision 1.2 >> diff -u -p -r1.2 res_init.3 >> --- net/res_init.3 25 Apr 2020 14:30:05 - 1.2 >> +++ net/res_init.3 25 Apr 2020 14:38:39 - >> @@ -183,6 +183,9 @@ feature. >> With this option >> .Xr gethostbyname 3 >> will return IPv6 addresses if available. >> +This option is deprecated in favor of the >> +.Xr getaddrinfo 3 >> +interface. >> On some operating systems this option also causes IPv4 addresses to be >> returned as IPv4-mapped IPv6 addresses. >> For example, 10.1.1.1 will be returned as :::10.1.1.1. >> >> >> -- >> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: resolv.conf(5) says options inet6 does nothing
This wording doesn't make any sense to me. When we use the term deprecate, we are talking about interfaces. But gethostbyname isn't actually deprecated. getaddrinfo is an alternative interface rather than gethostbyname. But gethostbyname isn't deprecated. I don't understand what the addition mean. At most I think it can be said the option is ineffective? > Index: net/res_init.3 > === > RCS file: /cvs/src/lib/libc/net/res_init.3,v > retrieving revision 1.2 > diff -u -p -r1.2 res_init.3 > --- net/res_init.325 Apr 2020 14:30:05 - 1.2 > +++ net/res_init.325 Apr 2020 14:38:39 - > @@ -183,6 +183,9 @@ feature. > With this option > .Xr gethostbyname 3 > will return IPv6 addresses if available. > +This option is deprecated in favor of the > +.Xr getaddrinfo 3 > +interface. > On some operating systems this option also causes IPv4 addresses to be > returned as IPv4-mapped IPv6 addresses. > For example, 10.1.1.1 will be returned as :::10.1.1.1. > > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: resolv.conf(5) says options inet6 does nothing
On Fri, Apr 24 2020, Jeremie Courreges-Anglas wrote: > On Thu, Apr 23 2020, Eric Faurot wrote: >> On Thu, Apr 23, 2020 at 10:34:39AM -0600, Theo de Raadt wrote: >>> It says the keyword gets parsed, but then does performs no action. >>> >>> But that is different from not parsing it. >>> >>> Additionally, this explains an option which other systems support, and >>> by explaining it this way, it is also explaining our behaviour in case >>> of inet6 vs inet4 conditions. >>> >>> So... I think it should stay. Eric, do you have an opinion? >> >> The doc lies because the inet6 option does not set the RES_USE_INET6 >> flag as stated. I think we should leave the entry in the doc but fix >> the wording to say it's there for historical reasons and does nothing. > > In the diff below I document the behavior on other operating systems > since this looks useful to Claudio. How does it read? > > (I really think this should go but if it doesn't I don't want it to stay > misleading as it is now.) > >> If we want to resurrect that option at some point, maybe we can >> consider making it set the RES_USE_INET6 flag but that feels like a >> bad idea right now, and this flag is apparently deprecated. > > I wholeheartedly with this, in my book RES_USE_INET6 and "options inet6" > are just early IPv6 experiments that went nowhere. > "options inet6" would break most programs that use gethostbyname(3). > >> But we should also fix the manpage for res_init(3) as the description >> of the flag is wrong too. > > Diff below. Thoughts, oks? Committed, thanks. Eric suggested that we mark this option as deprecated. Proposal: Index: net/res_init.3 === RCS file: /cvs/src/lib/libc/net/res_init.3,v retrieving revision 1.2 diff -u -p -r1.2 res_init.3 --- net/res_init.3 25 Apr 2020 14:30:05 - 1.2 +++ net/res_init.3 25 Apr 2020 14:38:39 - @@ -183,6 +183,9 @@ feature. With this option .Xr gethostbyname 3 will return IPv6 addresses if available. +This option is deprecated in favor of the +.Xr getaddrinfo 3 +interface. On some operating systems this option also causes IPv4 addresses to be returned as IPv4-mapped IPv6 addresses. For example, 10.1.1.1 will be returned as :::10.1.1.1. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: resolv.conf(5) says options inet6 does nothing
On Thu, Apr 23 2020, Eric Faurot wrote: > On Thu, Apr 23, 2020 at 10:34:39AM -0600, Theo de Raadt wrote: >> It says the keyword gets parsed, but then does performs no action. >> >> But that is different from not parsing it. >> >> Additionally, this explains an option which other systems support, and >> by explaining it this way, it is also explaining our behaviour in case >> of inet6 vs inet4 conditions. >> >> So... I think it should stay. Eric, do you have an opinion? > > The doc lies because the inet6 option does not set the RES_USE_INET6 > flag as stated. I think we should leave the entry in the doc but fix > the wording to say it's there for historical reasons and does nothing. In the diff below I document the behavior on other operating systems since this looks useful to Claudio. How does it read? (I really think this should go but if it doesn't I don't want it to stay misleading as it is now.) > If we want to resurrect that option at some point, maybe we can > consider making it set the RES_USE_INET6 flag but that feels like a > bad idea right now, and this flag is apparently deprecated. I wholeheartedly with this, in my book RES_USE_INET6 and "options inet6" are just early IPv6 experiments that went nowhere. "options inet6" would break most programs that use gethostbyname(3). > But we should also fix the manpage for res_init(3) as the description > of the flag is wrong too. Diff below. Thoughts, oks? Index: share/man/man5/resolv.conf.5 === RCS file: /d/cvs/src/share/man/man5/resolv.conf.5,v retrieving revision 1.59 diff -u -p -r1.59 resolv.conf.5 --- share/man/man5/resolv.conf.524 Jan 2020 06:16:47 - 1.59 +++ share/man/man5/resolv.conf.524 Apr 2020 08:22:25 - @@ -259,12 +259,13 @@ as is often the case with .Xr pppoe 4 or with tunnels. .It Cm inet6 -Enables support for IPv6-only applications, by setting RES_USE_INET6 in -_res.options (see -.Xr res_init 3 ) . On .Ox this option does nothing. +On some operating systems, this option enables IPv6 support in +.Xr gethostbyname 3 +by setting RES_USE_INET6 in _res.options (see +.Xr res_init 3 ) . .It Cm insecure1 Do not require IP source address on the reply packet to be equal to the server's address. Index: lib/libc/net/res_init.3 === RCS file: /d/cvs/src/lib/libc/net/res_init.3,v retrieving revision 1.1 diff -u -p -r1.1 res_init.3 --- lib/libc/net/res_init.3 30 Aug 2019 18:33:17 - 1.1 +++ lib/libc/net/res_init.3 24 Apr 2020 08:25:46 - @@ -180,12 +180,14 @@ In the past, it turned off the legacy .Ev HOSTALIASES feature. .It Dv RES_USE_INET6 -Enables support for IPv6-only applications. -This causes IPv4 addresses to be returned as an IPv4 mapped address. +With this option +.Xr gethostbyname 3 +will return IPv6 addresses if available. +On some operating systems this option also causes IPv4 addresses to be +returned as IPv4-mapped IPv6 addresses. For example, 10.1.1.1 will be returned as :::10.1.1.1. -On -.Ox -this option does nothing. +IPv4-mapped IPv6 addresses are not supported on +.Ox . .It Dv RES_USE_EDNS0 Attach an OPT pseudo-RR for the EDNS0 extension, as specified in RFC 2671. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: resolv.conf(5) says options inet6 does nothing
On Thu, Apr 23, 2020 at 10:34:39AM -0600, Theo de Raadt wrote: > It says the keyword gets parsed, but then does performs no action. > > But that is different from not parsing it. > > Additionally, this explains an option which other systems support, and > by explaining it this way, it is also explaining our behaviour in case > of inet6 vs inet4 conditions. > > So... I think it should stay. Eric, do you have an opinion? The doc lies because the inet6 option does not set the RES_USE_INET6 flag as stated. I think we should leave the entry in the doc but fix the wording to say it's there for historical reasons and does nothing. If we want to resurrect that option at some point, maybe we can consider making it set the RES_USE_INET6 flag but that feels like a bad idea right now, and this flag is apparently deprecated. But we should also fix the manpage for res_init(3) as the description of the flag is wrong too. Eric.
Re: resolv.conf(5) says options inet6 does nothing
On Thu, Apr 23, 2020 at 06:31:12PM +0200, Jeremie Courreges-Anglas wrote: > On Thu, Apr 23 2020, Jason McIntyre wrote: > > On Thu, Apr 23, 2020 at 05:17:08PM +0200, Solene Rapenne wrote: > >> Is there a reason to keep this part in resolv.conf(5) about an option > >> doing nothing? > >> > >> > options inet6 > >> > Enables support for IPv6-only applications, by setting RES_USE_INET6 > >> > in _res.options (see res_init(3)). On OpenBSD this option does > >> > nothing. > >> > >> If we can remove it, here is the diff. > >> > > > > hi. > > > > i guess if you did this, you'd need to look at res_init.3 too. > > "options inet6" in resolv.conf(5) does bothing, it doesn't "set > RES_USE_INET6 in _res.options". I think we can just delete any mention > of "options inet6" in resolv.conf(5). > > RES_USE_INET6 as documented in res_init(3) should be investigated some > more. It actually does *something* in the current code, but it > doesn't enable the IPv4-mapped IPv6 addresses which we don't support. > > Maybe this option should just be deleted (probably safer to wait after > 6.7 is released). People should use getaddrinfo(3) instead. > resolv.conf and res_init is used on many other operating systems. It is defacto a standard file and so it makes sense to document options that may exist on other system. -- :wq Claudio
Re: resolv.conf(5) says options inet6 does nothing
It says the keyword gets parsed, but then does performs no action. But that is different from not parsing it. Additionally, this explains an option which other systems support, and by explaining it this way, it is also explaining our behaviour in case of inet6 vs inet4 conditions. So... I think it should stay. Eric, do you have an opinion? > Is there a reason to keep this part in resolv.conf(5) about an option > doing nothing? > > > options inet6 > > Enables support for IPv6-only applications, by setting RES_USE_INET6 > > in _res.options (see res_init(3)). On OpenBSD this option does > > nothing. > > If we can remove it, here is the diff. > > Index: resolv.conf.5 > === > RCS file: /home/cvs/src/share/man/man5/resolv.conf.5,v > retrieving revision 1.59 > diff -u -p -r1.59 resolv.conf.5 > --- resolv.conf.5 24 Jan 2020 06:16:47 - 1.59 > +++ resolv.conf.5 23 Apr 2020 15:09:42 - > @@ -258,13 +258,6 @@ particularly if there is a reduced MTU, > as is often the case with > .Xr pppoe 4 > or with tunnels. > -.It Cm inet6 > -Enables support for IPv6-only applications, by setting RES_USE_INET6 in > -_res.options (see > -.Xr res_init 3 ) . > -On > -.Ox > -this option does nothing. > .It Cm insecure1 > Do not require IP source address on the reply packet to be equal to the > server's address. >
Re: resolv.conf(5) says options inet6 does nothing
On Thu, Apr 23 2020, Jason McIntyre wrote: > On Thu, Apr 23, 2020 at 05:17:08PM +0200, Solene Rapenne wrote: >> Is there a reason to keep this part in resolv.conf(5) about an option >> doing nothing? >> >> > options inet6 >> > Enables support for IPv6-only applications, by setting RES_USE_INET6 >> > in _res.options (see res_init(3)). On OpenBSD this option does >> > nothing. >> >> If we can remove it, here is the diff. >> > > hi. > > i guess if you did this, you'd need to look at res_init.3 too. "options inet6" in resolv.conf(5) does bothing, it doesn't "set RES_USE_INET6 in _res.options". I think we can just delete any mention of "options inet6" in resolv.conf(5). RES_USE_INET6 as documented in res_init(3) should be investigated some more. It actually does *something* in the current code, but it doesn't enable the IPv4-mapped IPv6 addresses which we don't support. Maybe this option should just be deleted (probably safer to wait after 6.7 is released). People should use getaddrinfo(3) instead. > jmc > >> Index: resolv.conf.5 >> === >> RCS file: /home/cvs/src/share/man/man5/resolv.conf.5,v >> retrieving revision 1.59 >> diff -u -p -r1.59 resolv.conf.5 >> --- resolv.conf.524 Jan 2020 06:16:47 - 1.59 >> +++ resolv.conf.523 Apr 2020 15:09:42 - >> @@ -258,13 +258,6 @@ particularly if there is a reduced MTU, >> as is often the case with >> .Xr pppoe 4 >> or with tunnels. >> -.It Cm inet6 >> -Enables support for IPv6-only applications, by setting RES_USE_INET6 in >> -_res.options (see >> -.Xr res_init 3 ) . >> -On >> -.Ox >> -this option does nothing. >> .It Cm insecure1 >> Do not require IP source address on the reply packet to be equal to the >> server's address. >> > -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: resolv.conf(5) says options inet6 does nothing
On Thu, Apr 23, 2020 at 05:17:08PM +0200, Solene Rapenne wrote: > Is there a reason to keep this part in resolv.conf(5) about an option > doing nothing? > > > options inet6 > > Enables support for IPv6-only applications, by setting RES_USE_INET6 > > in _res.options (see res_init(3)). On OpenBSD this option does > > nothing. > > If we can remove it, here is the diff. > hi. i guess if you did this, you'd need to look at res_init.3 too. jmc > Index: resolv.conf.5 > === > RCS file: /home/cvs/src/share/man/man5/resolv.conf.5,v > retrieving revision 1.59 > diff -u -p -r1.59 resolv.conf.5 > --- resolv.conf.5 24 Jan 2020 06:16:47 - 1.59 > +++ resolv.conf.5 23 Apr 2020 15:09:42 - > @@ -258,13 +258,6 @@ particularly if there is a reduced MTU, > as is often the case with > .Xr pppoe 4 > or with tunnels. > -.It Cm inet6 > -Enables support for IPv6-only applications, by setting RES_USE_INET6 in > -_res.options (see > -.Xr res_init 3 ) . > -On > -.Ox > -this option does nothing. > .It Cm insecure1 > Do not require IP source address on the reply packet to be equal to the > server's address. >
resolv.conf(5) says options inet6 does nothing
Is there a reason to keep this part in resolv.conf(5) about an option doing nothing? > options inet6 > Enables support for IPv6-only applications, by setting RES_USE_INET6 > in _res.options (see res_init(3)). On OpenBSD this option does > nothing. If we can remove it, here is the diff. Index: resolv.conf.5 === RCS file: /home/cvs/src/share/man/man5/resolv.conf.5,v retrieving revision 1.59 diff -u -p -r1.59 resolv.conf.5 --- resolv.conf.5 24 Jan 2020 06:16:47 - 1.59 +++ resolv.conf.5 23 Apr 2020 15:09:42 - @@ -258,13 +258,6 @@ particularly if there is a reduced MTU, as is often the case with .Xr pppoe 4 or with tunnels. -.It Cm inet6 -Enables support for IPv6-only applications, by setting RES_USE_INET6 in -_res.options (see -.Xr res_init 3 ) . -On -.Ox -this option does nothing. .It Cm insecure1 Do not require IP source address on the reply packet to be equal to the server's address.
