sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] [PATCH] IPv6 support


From: Yaron Minsky
Subject: Re: [Sks-devel] [PATCH] IPv6 support
Date: Thu, 5 Mar 2009 07:33:48 -0500

I'm really happy to see these changes being tried out.  I'll read over the diff today and try to get you some feedback.

y

On Thu, Mar 5, 2009 at 2:24 AM, Phil Pennock <address@hidden> wrote:
On 2009-03-02 at 02:52 -0800, Phil Pennock wrote:
> Can those with more experience in OCaml please take a look over this and
> tell me if I'm heading down the right path?
>
> This patch theoretically adds support for IPv6 in recon; it adds the
> settings hooks for hkp too, but doesn't add anything that uses that yet.
> It should both listen on IPv6 and connect outbound too.
>
> It compiles.  It runs.  I see both listening sockets with lsof.  It
> doesn't do anything soon enough for me to see tonight how well I've
> done, as I need to go get some sleep.  I'm not sufficiently comfortable
> to leave sks-peer.spodhuis.org running this code overnight, so I've
> reverted to 1.1.0.
>
> It's my first OCaml hacking and my style sucks and I spend more time
> debugging to get it to compile than I care to think about.
>
> A critical eye and constructive comments appreciated.
>
> Oh, and I've no idea how recent support for IPv6 in OCaml is and have
> made no effort to gracefully degrade to either old OCaml environments or
> systems without IPv6 support.  First, I want to get it working for
> anyone, *then* I can worry about making it conditional.

I've now extended the code to implement IPv6 for hkp, not just recon,
and to make outbound connections fine.

People have a choice:

 * Kim's simpler patch, which relies upon the OS supporting IPv6-mapped
  IPv4 addresses; the *BSD systems disable this by default, but you can
  change this system-wide by setting sysctl net.inet6.ip6.v6only to 0.
  I believe that OCaml lacks the necessary support in its setsockopt
  shim to set this option, so it can't be worked around

 * My larger patch, which opens separate sockets for each stack and
  which adds recon6_address and hkp6_address options to sksconf if you
  want to use a binding address other than :: (the IPv6 equivalent to
  0.0.0.0).

In particular, if anyone has an IPv4-only system, I would like to know
what problems are caused by my patch, but I'll fully understand if
people don't want to try that out.  :)

I'm now running my patch live, eating my own dogfood.  I've used gpg to
get a key from the HKP port over IPv6, but not yet seen recon, in part
because my DNS didn't include an AAAA record.  I've updated my DNS and
we're now past the TTL expiry.
 $ gpg --keyserver 'hkp://[2001:980:fff:31::10]' --recv-key $keyid

I am not providing a Mercurial repository, as I'm not sufficiently
familiar with the system to assess the security risks of doing so and
don't want to leave up a daemon which I'd access so rarely.  If I used
Mercurial on a regular basis, that would be a different matter.

So, attached, please find what I currently believe to be a complete IPv6
support patch.  Unless you define "complete" to mean "can disable it".

I would have sent this mail 2 hours ago but I realised that the
membership code just taking the first address found was a bad plan, as
then there would be a 50% chance of a connection from a mutually IPv6
host failing -- if they connected over IPv4 and you only record the IPv6
address, that would be rejected.  So I've just broken my brain on
O'Caml's type system while making sure that the membership handling will
track _all_ the IP addresses of each peer.

Note that one side-effect is that in theory, with this, you could peer
with a cluster of hosts where one name has multiple IPs.  But you
wouldn't want to do that normally, especially since the "that's myself"
test will drop any item where any of the IP addresses are any of the
local recon addresses (either the one configured address or any of the
addresses for hostname).  Oh, and that would possibly not be a good plan
from the point of view of the synchronisation protocol itself.

With this latest fix, I'm not rejecting so many recon connects now.  ;)

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.

Thanks,
-Phil

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]