This behavior seems fine in lieu of what the client can reasonably be expected 
to know. My fear is in the case of a pool with 10+ ipv4 AND 10+ ipv6 sources: 
If I have a single-stack host, will it load a list of [max sources] time 
sources and THEN determine if they're reachable or will it do initial 
reach-ability followed by populating [max sources] in the active list based on 
which hosts responded? I suspect the behavior is the former, putting the 
overall average number of reachable nodes for a single-stack host at [max 
sources]/2. This SHOULD be adequate in most cases, but is probably sub-optimal. 
I'm thinking now about making separate v4 and v6 pools for hosts...

Is that the reason for the pool.ntp.org being ipv4-only and 2.pools.ntp.org 
having v4 and v6 together? Is there a best practice recommendation for clients 
in a mixed ipv4/ipv6 single/dual stack environment?

Dan

----- Original Message -----
> From: "Dag-Erling Smørgrav" <[email protected]>
> To: "Dan Geist" <[email protected]>
> Cc: "lst hoe02" <[email protected]>, [email protected]
> Sent: Saturday, November 7, 2015 7:11:56 AM
> Subject: Re: [Pool] pool IPv4/IPv6 behavior with ntpd

> Dan Geist <[email protected]> writes:
>> I'm not sure I agree with that behavior (from a client/peer use-case
>> perspective). Wouldn't it make more sense to only use the stack that's
>> actually available? That's how it works with DNS typically: If
>> ghostbyname yields an A and AAAA record, applications don't attempt to
>> use the AAAA record if there is no ipv6 stack configured, right?
> 
> There is no reliable way for an application to tell whether IPv6 is
> supported.  Standard procedure is to use getaddrinfo(), iterate over the
> results, try to bind or connect to each address (depending on whether
> you're a server or a client) and ignore any failures as long as at least
> one address works.
> 
> DES
> --
> Dag-Erling Smørgrav - [email protected]

-- 
Dan Geist dan(@)polter.net
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool

Reply via email to