On 12/03/2013 11:41 AM, Kim Minh Kaplan wrote:
> But this *is* the approach that SKS uses, except that it does not have
> to set IPV6_V6ONLY. Like I wrote in a previous answer, SKS requires the
> administrator to list all addresses, IPv4 and IPv6. As an alternative you
> can use the hostname. But I do not recommend this as you then have to be
> sure that all your DNS system is working fine at SKS startup time.

ah, i'm finally understanding your suggestion, Kim.  thanks for persisting.

Indeed, when i change zimmermann's recon_address from :: to an explicit
list of all public IP addresses, things seem to work as expected.

> Note that there is no real operational problem to fix in SKS with regard
> to IPv6. It works fine for many (all?) people. The only annoyance I know
> is that you cannot use the catchall :: address on systems that provide
> IPv4-mapped addresses by default, like Linux.

Could we update the wiki to include that suggestion?  attached is a
patch for Peering.wiki.

        --dkg
diff -r 389b4e01f450 Peering.wiki
--- a/Peering.wiki	Mon Dec 02 21:27:55 2013 +0000
+++ b/Peering.wiki	Tue Dec 03 12:06:22 2013 -0500
@@ -53,14 +53,14 @@
 
 You probably want a DNS hostname of ##keyserver## or ##sks## or ##pgp-keys## in your domain.  Eg, ##keyserver.example.com##.  You need that hostname to resolve to the IP on which your SKS server listens **and** which will be used for outbound TCP connections.  You want to use a dedicated hostname for this, so that you can move the SKS service independently of other services (the SKS peering protocols do not support hacks like HTTP redirects).
 
-If your machine has more than one IP address, it may be wise to set the ##hkp_address## and ##recon_address## options in your ##sksconf## file.  Both options should be set to the same value(s).  For example, assuming you have IPv6 connectivity and want to provide service on both IPv4 and IPv6:
+If your machine has more than one IP address, it may be wise to set the ##hkp_address## and ##recon_address## options in your ##sksconf## file.  You should explicitly set all public addresses used, and avoid relying on the "::" catchall.  Unless you are using a reverse proxy (see below), both options should be set to the same value(s).  For example, assuming you have IPv6 connectivity and want to provide service on both IPv4 and IPv6:
 {{{
 hostname: keyserver.example.com
 hkp_address: 192.0.2.42 2001:DB8::1:42
 recon_address: 192.0.2.42 2001:DB8::1:42
 }}}
 
-(Strictly speaking: every address in ##recon_address## needs to be in ##hkp_address##, or covered by a wildcard address in ##hkp_address##, but they don't need to be the same.  But part of using recon involves making connections to the hkp port on the same host.)
+(Strictly speaking: every address in ##recon_address## needs to be in ##hkp_address##, or covered by a wildcard address in ##hkp_address##, or mapped back to an address in ##hkp_address## via a reverse proxy, but they don't need to be the same.  But part of using recon involves making connections to the hkp port on the same host.)
 
 Note that ##recon_address## serves two purposes: it defines which addresses your recon server will //listen// on, and defines preferred source IP addresses for //outbound// connections too.  For instance, if you specify one IPv4 address in the option, then outbound IPv4 connections will use that source address, while outbound IPv6 connections will use the system default.
 
@@ -323,4 +323,4 @@
 
 == Editorial bias note ==
 
-This wiki page was written by someone who'll peer with almost anyone, but who really is happy when he sees a keyserver showing that it has a full keydump, as he's been bitten a couple of times by this issue.
\ No newline at end of file
+This wiki page was written by someone who'll peer with almost anyone, but who really is happy when he sees a keyserver showing that it has a full keydump, as he's been bitten a couple of times by this issue.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Reply via email to