git:// links no longer work, refer to the https:// one.

[wiki] / goals.mdwn

diff --git a/goals.mdwn b/goals.mdwn
index 8a0eebb..57bffec 100644 (file)
--- a/goals.mdwn
+++ b/goals.mdwn
@@ -65,7 +65,7 @@ The 1.1 branch of tinc has been created as a stepping stone towards
 2.0. Only gradual changes to the source code are allowed, ensuring
 that the code is always in a mostly usable state. The protocol will
 stay compatible with that of the 1.0 branch. The following features
-are planned in this branch:
+are planned or are already implemented in this branch:
 
 **Replaceble cryptography backend**
 
@@ -93,16 +93,6 @@ in the tinc.conf files. It is desirable to have tinc manage the
 creation of control connections as well, so that the administrator
 does not have to do this manually anymore.
 
-**Deal with NAT**
-
-The 1.0 branch by default tries to exchange packets via UDP.
-However, if one or more peers are behind a NAT, and source ports
-might be changed or packets may not arrive at all, the
-administrator had to manually enable the TCPOnly option or use
-another workaround to get tinc to work. Tinc should be able to cope
-with altered source ports, and should detect whether or not packet
-exchange via UDP works at all, and if not fall back to TCP.
-
 **Automate setting up nodes**
 
 The tincctl utility should have a wizard-like interface that asks a few
@@ -146,14 +136,14 @@ PGP, where peers can sign each other, and if there are enough
 signatures, they can allow communication. Trust management should
 be simple, for example using a command like
 
-    tinc trust *foo*
+    tinc trust foo
 
 which should let the local tinc
 daemon trust information from the peer named *foo*. To authorise
 the use of addresses on the VPN, a command like the following could
 be used:
 
-    tinc allow *bar* 192.168.3.0/24
+    tinc allow bar 192.168.3.0/24
 
 This should generate a small certificate that proves that the node that
 issued this command trusts node *bar* with the 192.168.3.0/24 range
@@ -162,11 +152,11 @@ tinc daemon's configuration, but also spread immediately amongst
 the other peers in the VPN. It is also important to allow trust and
 authorisation to be revoked in the same way:
 
-    tinc distrust *foo*
+    tinc distrust foo
 
 This should make the local tinc daemon stop trusting any information from *foo*.
 
-    tinc deny *bar*
+    tinc deny bar
 
 This should generate a certificate (with a newer timestamp than the previous one) denying
 *bar* any access, and spread this amongst the other peers as well.