<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-CA" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi Balazs,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Excellent, that all makes sense. I expect this will appear in the next release of syslog-ng.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">And to fully confirm the below, the following will also then work I presume:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal">destination d_one {<o:p></o:p></p>
<p class="MsoNormal">    network("192.168.1.1" ip-protocol(6));<br>
};<o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal">destination d_two {<o:p></o:p></p>
<p class="MsoNormal">    network("fd07::1" ip-protocol(6));<br>
};<o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">If so, this all makes things much easier on my side (not having to detect the destination token’s applicability wrt ip-protocol(4) vs ip-protocol(6)). Moreover, all of the old (deprecated?) udp6/tcp6
 vs. udp/tcp usage/distinctions can also go away.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">-David<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> syslog-ng <syslog-ng-bounces@lists.balabit.hu>
<b>On Behalf Of </b>Balazs Scheidler<br>
<b>Sent:</b> September 26, 2018 7:01 AM<br>
<b>To:</b> Syslog-ng users' and developers' mailing list <syslog-ng@lists.balabit.hu><br>
<b>Subject:</b> Re: [syslog-ng] 'network' Destination With Hostname Resolution (IPv4 vs IPv6)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">It should work, yes. Hmm.. I've tried what I've recommended in production and it does not work without this patch:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">```<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">diff --git a/lib/host-resolve.c b/lib/host-resolve.c<br>
index b685264f9..66915fe47 100644<br>
--- a/lib/host-resolve.c<br>
+++ b/lib/host-resolve.c<br>
@@ -144,6 +144,7 @@ resolve_hostname_to_sockaddr_using_getaddrinfo(GSockAddr **addr, gint family, co<br>
   hints.ai_family = family;<br>
   hints.ai_socktype = 0;<br>
   hints.ai_protocol = 0;<br>
+  hints.ai_flags = AI_V4MAPPED | AI_ADDRCONFIG;<br>
 <br>
   if (getaddrinfo(name, NULL, &hints, &res) == 0)<br>
     {<br>
```<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">With that patch, this configuration worked even if no ipv6 address was available:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">destination d_ipv6 {<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">    network("<a href="http://host.name.somewhere.com">host.name.somewhere.com</a>" ip-protocol(6));<br>
};<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The flags above basically mean the following logic (quoting from getaddrinfo):<o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">       If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 addresses are returned in the list pointed to by res only if the local system has at least one IPv4  address  config‐<br>
       ured,  and IPv6 addresses are returned only if the local system has at least one IPv6 address configured.  The loopback address is not considered for this case as valid as a con‐<br>
       figured address.  This flag is useful on, for example, IPv4-only systems, to ensure that getaddrinfo() does not return IPv6 socket addresses that would always fail in  connect(2)<br>
       or bind(2).<br>
<br>
       If  hints.ai_flags  specifies  the  AI_V4MAPPED  flag,  and hints.ai_family was specified as AF_INET6, and no matching IPv6 addresses could be found, then return IPv4-mapped IPv6<br>
       addresses in the list pointed to by res.  If both AI_V4MAPPED and AI_ALL are specified in hints.ai_flags, then return both IPv6 and IPv4-mapped IPv6 addresses in the list pointed<br>
       to by res.  AI_ALL is ignored if AI_V4MAPPED is not also specified.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This means that as long as you have a local ipv6 address configured (loopback does not count) and the server has an IPv6 address, syslog-ng would be using that. If the server does not have one or there's no local ipv6 address, it'd be using
 an IPv4-mapped address (e.g. ::ffff:1.2.3.4) and would continue to use ipv4 on the wire.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I am posting this fix as a PR on github in a moment.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Tue, Sep 25, 2018 at 3:59 PM David Hauck <<a href="mailto:davidh@netacquire.com">davidh@netacquire.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Balázs,<br>
<br>
Thanks for your thoughts. Please see below.<br>
<br>
On Fri, 21 Sep 2018 at 04:52:00, syslog-ng <<a href="mailto:syslog-ng-bounces@lists.balabit.hu" target="_blank">syslog-ng-bounces@lists.balabit.hu</a>> On Behalf Of Scheidler, Balázs wrote:<br>
> The reason you need to explicitly ask for ip-protocol(6) is that <br>
> sometimes, syslog-ng by itself can create such a socket, can even <br>
> resolve DNS names to ipv6 addresses and then communication wouldn't <br>
> work without an actual ipv6 tunnel/connectivity. Setting ip-protocol(6) <br>
> everywhere would achieve auto-detection and it probably would make sense <br>
> to make this configurable globally, not on a per-destination basis.<br>
<br>
Independent of a potential globally configurable hint would it work to use ip-protocol(6) in all of my destination configurations directly, regardless of whether the specified <destination-address> is a hostname (which may be resolve to an IPv4 or IPv6 address),
 an IPv4 address string, or an IPv6 address string?<br>
<br>
I would really like to just specify this once for each/all destinations (I don't mind doing it for each destination, I just don't want to have to evaluate whether to use ip-protocol([46])*).<br>
<br>
Regards,<br>
-David<br>
<br>
* The destination configurations are performed programmatically and the extra determination for whether the configured <destination-address> falls into any of the above three categories is cumbersome/tricky at the locale where this done.<br>
<br>
> That would probably be something like this:<br>
> <br>
> *     introduce ipv6 related attributes in GlobalConfig, defaulting to ipv4<br>
> <br>
> *     have those attributes configurable through cfg-grammar.y (e.g.<br>
> the main configuration parser)<br>
> *     in each destination that supports ipv6, inherit the global value<br>
> unless overridden locally<br>
> <br>
> There are similar patterns in the configuration/destination relation, <br>
> for instance with log-fifo-size() where there's a global and a local setting as well.<br>
> <br>
> <br>
> With that said, I'd say that patches are welcome, I couldn't work on <br>
> it myself right now, but I am happy to review any solutions.<br>
> <br>
> <br>
> On Thu, Sep 20, 2018 at 6:03 PM David Hauck <<a href="mailto:davidh@netacquire.com" target="_blank">davidh@netacquire.com</a> <mailto:<a href="mailto:davidh@netacquire.com" target="_blank">davidh@netacquire.com</a>> > wrote:<br>
> <br>
> <br>
>       Hi Balazs,<br>
> <br>
>       On Wednesday, September 19, 2018 9:21 PM, syslog-ng <br>
> <<a href="mailto:syslog-ng-bounces@lists.balabit.hu" target="_blank">syslog-ng-bounces@lists.balabit.hu</a><br>
> <mailto:<a href="mailto:syslog-ng-bounces@lists.balabit.hu" target="_blank">syslog-ng-bounces@lists.balabit.hu</a>> > On Behalf Of Balazs Scheidler wrote:<br>
>       > Ip protocol v6 should support both ipv4 and v6. So if you use that and<br>
>       > the name resolves to a v4 address or should work.<br>
> <br>
>       OK, interesting.<br>
> <br>
>       For a different reason it would also be good if I could always <br>
> specify ip-protocol(6) (non-default) for any value of "myhost" below - <br>
> i.e., even when this is an explicit IPv4 or IPv6 address string. Would <br>
> this also work? And if this were to work (I see no reason why it <br>
> wouldn't if what you say about hostname resolution above) then I guess there is no value in specifying ip-protocol() at all, right (i.e., syslog-ng could also just know to do the right thing in these cases)?<br>
> <br>
>       Thanks,<br>
>       -David<br>
> <br>
>       > On Wed, Sep 19, 2018, 19:23 David Hauck <<a href="mailto:davidh@netacquire.com" target="_blank">davidh@netacquire.com</a>
<br>
> <mailto:<a href="mailto:davidh@netacquire.com" target="_blank">davidh@netacquire.com</a>> <mailto:<a href="mailto:davidh@netacquire.com" target="_blank">davidh@netacquire.com</a><br>
> <mailto:<a href="mailto:davidh@netacquire.com" target="_blank">davidh@netacquire.com</a>> >      >> wrote:       >       >       Hi,     >       >     
<br>
> Thought I would reach out again to see if anyone had any thoughts on the<br>
> item below.   >       >       Thanks for the consideration,   >       -David  ><br>
>       >       On Wednesday, September 12, 2018 3:39 PM, syslog-ng<br>
> <<a href="mailto:syslog-ng-bounces@lists.balabit.hu" target="_blank">syslog-ng-bounces@lists.balabit.hu</a><br>
> <mailto:<a href="mailto:syslog-ng-bounces@lists.balabit.hu" target="_blank">syslog-ng-bounces@lists.balabit.hu</a>>   ><br>
> <mailto:<a href="mailto:syslog-ng-bounces@lists.balabit.hu" target="_blank">syslog-ng-bounces@lists.balabit.hu</a><br>
> <mailto:<a href="mailto:syslog-ng-bounces@lists.balabit.hu" target="_blank">syslog-ng-bounces@lists.balabit.hu</a>> > > On Behalf Of David Hauck<br>
>       > wrote:        > Hi,   >       > I have a question regarding how to<br>
> specify a network     > destination when using a hostname when the    ><br>
> hostname can be resolved      > to either IPv4 or IPv6. In particular what<br>
> should be specified by the    > ip-   > protocol() parameter? There are<br>
> some configuration scenarios  > and/or target installations that don't  <br>
>      > know a priori whether the DNS  > configuration will resolve to an<br>
> IPv4 or IPv6 address.<br>
>>> E.g.,         >       ><br>
>       > destination d_tcp6 {  >     network(  >         "myhost"<br>
>> <br>
>       > port(514)     >         transport(udp)        ><br>
> ip-protocol(6 or 4 or ??)<br>
>       >       >         );    > };    >       > It seems like it would<br>
> simple enough to have<br>
>       > syslog-ng simply validate the resulting IP address string to<br>
>> <br>
>       > determine which of ip-protocol(4) or ip-protocol(6) is actually needed.<br>
>       > In fact, I would argue that   > specifying an IP address<br>
> string (as the<br>
>       > "<destination-address>" value) could result in the same<br>
>> determination<br>
>       > (the address string necessarily unambiguously determines whether the<br>
>       > reference is an       > IPv4 or an IPv6 address and I would think<br>
> there is a    > 1-1 relationship between this determination and       ><br>
> whether       > ip-protocol(4) or ip-protocol(6) is used - (in other words it<br>
> would         > never make sense to have      > these mixed: "::1" and<br>
> ip-protocol(4) would  > be invalid).  >       > Thanks, -David        ><br>
> <br>
> ________________________________________________________________________<br>
> ______        Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" target="_blank">
https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
>       Documentation:<br>
> <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" target="_blank">
http://www.balabit.com/support/documentation/?product=syslog-ng</a>       FAQ:<br>
> <a href="http://www.balabit.com/wiki/syslog-ng-faq" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
> <br>
><br>
______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" target="_blank">
https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" target="_blank">
http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<br>
-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Bazsi<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>