On 2009-03-04 at 23:24 -0800, Phil Pennock wrote: > If you try my patch out, I'd appreciate feedback. If you're peering > with sks-peer.spodhuis.org then you might want to keep an eye on > recon.log and see if you get an IPv6 peering. :) But please, keep a > safe copy of your normal binary to fall back to.
Sorry to follow up to myself, but I'll note one design decision I forgot
to mention:
sks does random peering already. When choosing an IP address from those
published by a hostname, I could choose to refactor the code to fallback
across IPs, or I could just make things a bit more random and randomly
choose one of the available IPs.
I chose to add the extra randomness.
Rationale:
* the random connects should still let the peering mesh work
* most people with IPv6 service will probably choose to move to IPv6
recon within a short enough period of time that the gain would be
short-lived
* if someone really doesn't want to peer over IPv6, then either:
(a) they're IPv4-only, so this doesn't affect them at all
or
(b) they should ask their peers to use a hostname which doesn't have
AAAA records in membership files
Just be aware that you'll see more of your outbound connections failing,
if the remote side uses a hostname with AAAA records but no AAAA recon.
Note that a web-server proxying AAAA 11370 connections onto sks does not
work and will not work and never would have worked -- the code for
checking the hostname of a peer would have seen a connection from
localhost, and since you're not peering with localhost (I assume), this
would have failed the membership test. A proxy will only ever be a
work-around for the HKP port.
Regards,
-Phil
pgptKyPNCSgem.pgp
Description: PGP signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
