typos by hugo

git-svn-id: https://map66.svn.sourceforge.net/svnroot/map66@10 3484d885-4da6-438d-b19d-107d078dd756

1 files changed, 11 insertions, 11 deletions

diff --git a/README.txt b/README.txt
index 57abc4a..f2af2d4 100644
--- a/README.txt
+++ b/README.txt
@@ -27,8 +27,8 @@ address of outgoing packets as well as the IPv6 destination address of incoming
 packets. This allows you to map an internal IPv6 address range to a second,
 externally used IPv6 address range. IPv6 address mapping is not very similar to
 IPv4 network address translation, but one can describe it as some sort of
-stateless NAT. The implementation is based on the expired the IETF discussion
-paper published here:
+stateless NAT. The implementation is based on the expired IETF discussion paper
+published here:
 
 http://tools.ietf.org/html/draft-mrw-behave-nat66-02
 
@@ -43,9 +43,9 @@ On a Debian/(EKU)buntu, the following command prepares the build environment:
 
 sudo apt-get install build-essential linux-headers iptables-dev
 
-Unpack the source tgz archive to /usr/src, change to the archive's
-sub-directory and issue "make" to build. If this compiles without errors,
-install the ip6tables extension with the following command:
+Unpack the source tgz archive below /usr/src, change to the new sub-directory
+and issue "make" to build. If this compiles without errors, install the
+ip6tables extension with the following command:
 
 sudo make install
 
@@ -82,7 +82,7 @@ Brief Version
 
 You always need to add two ip6tables-rules to your netfilter configuration. One
 rule matches outgoing packets and changes their IPv6 source address. The second
-rule matches incoming packets and revert the address change by altering their
+rule matches incoming packets and reverts the address change by altering their
 IPv6 destination address. To following commands correspond to the “Address
 Mapping Example” given in the IETF discussion paper:
 
@@ -94,9 +94,9 @@ This example is also printed to the screen if you issue ip6tables -j MAP66
 /16 are supported.
 
 For each packet, the Linux kernel module also compares the packet's source
-address to all IPv6 addresses assigned to the outgoing interface. It a match is
+address to all IPv6 addresses assigned to the outgoing interface. If a match is
 found, the packet's source address is not mapped. The same comparison happens
-on the incoming packet's destination address. The comparison require some CPU
+on the incoming packet's destination address. The comparison requires some CPU
 resources, especially if the interface has a large number of assigned IPv6
 addresses. If you are sure that the mapping cannot match the IPv6 address of
 the interface (e.g. the mapping rule defines a mapping prefix that cannot
@@ -160,7 +160,7 @@ ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-
 
 Because for both IPv6 networks the external prefix length is smaller than the
 internal prefix length, we can make sure that the mapped addresses cannot match
-the interfaces address. For example: 2001:4dd0:fe77:1::/64 cannot be converted
+the interface addresses. For example: 2001:4dd0:fe77:1::/64 cannot be converted
 to 2001:4dd0:fe77:0::1/128 in this context. For this reason, we can use the
 --nocheck speedup here.
 
@@ -254,10 +254,10 @@ on every mesh node. Why? Because the mesh nodes can use private IP addresses
 (or "ULA") to transport the tunnel data between the client PC and the gateway/
 server. Each tunneling technique typically needs a single instance (the
 "server") which forms a single point of failure. Rule-of-thumb1: avoid a SPOF
-for the infrastructure. Rule-of-thumb2: KISS.
+for the infrastructure. Rule-of-thumb2: KISS (keep it simple stupid).
 
 Using private IP addresses on the mesh nodes has a drawback: mesh node software
-updates e.g. via HTTP downloads from an Internet server is not possible. This
+updates e.g. a download via HTTP from an Internet server is not possible. This
 is where I start to think: “hey, some kind of address mapping may be nice to
 have”. While opening Pandora's NAT66 box, I discovered that IPv6 nerds do not
 like the acronym. It is always a good tactic in info wars to rename, hence the