On Wed, 18 Feb 2015 20:13, d...@fifthhorseman.net said:
> Reasonable IPv6 stacks should return an ENETUNREACH (Network is
> unreachable) error message when trying to connect() to an address for
> which there is no route, which should already cause dirmngr to failover
The error handler after a con
It was not my intention to start an IPv6 advocacy thread, but in case
anyone is interested in facts about the current state of things, this is
a good summary:
http://www.slideshare.net/AkamaiTechnologies/edge-2014-ipv6-is-here-what-you-need-to-know
_
> I'm not convinced that it's gnupg's job to compensate for
> unreasonably-configured IPv6 stacks that think they have a route but
> actually don't.
Nor am I, but the world has never much cared whether something was my
job: it concerns itself more with ensuring there are consequences for
the job
> I didn't claim that one version was better than another version, I
> said it will probably never become widespread.
It already *is* widespread. China and Japan have signed onto it in a
big way. In the US, the largest wireless carrier -- Verizon -- has
migrated over a third of its smartphones t
On 18-02-2015 19:56, Peter Lebbing wrote:
>> Admit it, IPv6 has failed. It may get some uses, but the widespread
>> adaptation of carrier NAT has made it largely obsolete.
> Tired as I may be of this discussion (what's your next argument, NAT provides
> beneficial firewalling behaviour?), I still
> On 18 Feb 2015, at 19:07, Johan Wevers wrote:
>
> Admit it, IPv6 has
> failed. It may get some uses, but the widespread adaptation of carrier
> NAT has made it largely obsolete.
Utter, complete, nonsense.
--
Ville
___
Gnupg-users mailing list
Gnu
> On 18 Feb 2015, at 21:13, Daniel Kahn Gillmor wrote:
>
> I'm not convinced that it's gnupg's job to compensate for
> unreasonably-configured IPv6 stacks that think they have a route but
> actually don’t.
I agree. I think the actual problem should be addressed at the networking level
instead o
On Wed 2015-02-18 06:40:12 -0500, Werner Koch wrote:
> On Wed, 18 Feb 2015 06:24, r...@sixdemonbag.org said:
>
>> I don't have IPv6 routing, period. This raises the question of why
>> GnuPG is trying to reach an IPv6 address at all.
>
> Because the resolver tells that there is an record. It
On 18/02/15 18:07, Johan Wevers wrote:
> Admit it, IPv6 has failed. It may get some uses, but the widespread
> adaptation of carrier NAT has made it largely obsolete.
Tired as I may be of this discussion (what's your next argument, NAT provides
beneficial firewalling behaviour?), I still wish to s
On Wed, 18 Feb 2015 12:59, joh...@vulcan.xs4all.nl said:
> The most easy solution in such cases is to try IPv4 first, if that
> doesn't work or is unavailable, try IPv6 if available.
That server has no v4 address. For obvious reasons we use the standard
version first and only then fallback to a
On 18-02-2015 17:31, Doug Barton wrote:
>> The most easy solution in such cases is to try IPv4 first, if that
>> doesn't work or is unavailable, try IPv6 if available.
> Yeah, please DO NOT do that. The more traffic we can push to IPv6 the
> better for everyone, both now and in the future.
I've
On 2/18/15 3:59 AM, Johan Wevers wrote:
On 18-02-2015 12:40, Werner Koch wrote:
Because the resolver tells that there is an record. It seems that
we need to figure out at runtime whether v6 is actually working. Any
hints on how to do that?
The most easy solution in such cases is to try
On 18-02-2015 12:40, Werner Koch wrote:
> Because the resolver tells that there is an record. It seems that
> we need to figure out at runtime whether v6 is actually working. Any
> hints on how to do that?
The most easy solution in such cases is to try IPv4 first, if that
doesn't work or i
On Wed, 18 Feb 2015 06:24, r...@sixdemonbag.org said:
> I don't have IPv6 routing, period. This raises the question of why
> GnuPG is trying to reach an IPv6 address at all.
Because the resolver tells that there is an record. It seems that
we need to figure out at runtime whether v6 is act
> You are using this keyserver. ping6 shows that this server is
> currently up. May it be that your v6 routing is not working
> correct?
I don't have IPv6 routing, period. This raises the question of why
GnuPG is trying to reach an IPv6 address at all.
Worked fine under 2.0.x; under 2.1, this
On Tue, 17 Feb 2015 20:23, r...@sixdemonbag.org said:
> S # . pool.sks-keyservers.net
> S # . --> 6 8 1 13 20 4 10 11 7 2 15 5 12 17 9 19* 14 3 16 18
> S # 19 6 sks.spodhuis.org v6=[2a02:898:31::48:4558:73:6b73]
You are using this keyserver. ping6 shows that this server is curr
> gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye
Okay. I have no idea what I'm looking for, but here goes.
quorra:~ rjh$ gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 pool.sks-keyservers.net
S # . pool.
> You don't know that the hosts in those two situations are the
> same...
I know, which is why I said:
> It also affects all keyservers I tested, not just the round-robin
> front-end.
I tried several different non-round-robin servers. Same thing.
__
On Tue, 17 Feb 2015 02:21, r...@sixdemonbag.org said:
> quorra:~ rjh$ gpg - --keyserver x-hkp://pool.sks-keyservers.net
> --recv-key 0xD6B98E10
> gpg: using character set 'utf-8'
> gpg: keyserver receive failed: No route to host
It should have swithed to the next host of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/17/2015 02:21 AM, Robert J. Hansen wrote:
> Is there any explanation for this behavior, or is this a 2.1.2
> bug? (This is using Patrick's OS X package, if that matters. It
> also affects all keyservers I tested, not just the round-robin
> fro
Is there any explanation for this behavior, or is this a 2.1.2 bug?
(This is using Patrick's OS X package, if that matters. It also affects
all keyservers I tested, not just the round-robin front-end.)
quorra:~ rjh$ gpg - --keyserver x-hkp://pool.sks-keyservers.net
--recv-
21 matches
Mail list logo
