Merge branch 'es' into testing

Conflicts:
	doc/usr/en/pool4.md

.gitignore

@@ -21,6 +21,8 @@
 # binaries
 jool
 jool_siit
+# documentation
+_site
 
 # Packages #
 ############

doc/usr/en/contact.md

@@ -8,7 +8,6 @@ title: Contact
 # Contact
 
 - [email protected] is a mail list intended for general public discussion and news. Questions, requests and comments welcomed.  
-  A misplaced security gimmic currently prevents the archives from being public, but they are actually being built and will become available as soon as the TODO reaches one of our admins.  
   You can register to this list [here](https://mail-lists.nic.mx/listas/listinfo/jool-list).
 - [email protected] is a mail list intended to inform news to its recipients. At this point, it is only used to signal new releases being published at this site.  
   Anyone can listen, but only the dev team can place mails here, so you don't have to worry about spam.  

doc/usr/en/dns64.md

@@ -80,22 +80,20 @@ user@B:~# apt-get install bind9
 
 The most basic configuration is very minimalistic. In order to turn on DNS64, the options section from the named.conf file (in my case, `/etc/bind/named.conf.options`) is the only one in which statements must be updated:
 
-{% highlight bash %}
-options {
-	(...)
-
-	# Listening on IPv6 is off by default.
-	listen-on-v6 { any; };
-
-	# This is the key. Note that you can write multiple of these if you need
-	# more IPv6 prefixes.
-	# "64:ff9b::/96" has to be the same as Jool's `pool6`.
-	dns64 64:ff9b::/96 {
-		# Options per prefix (if you need them) here.
-		# More info here: https://kb.isc.org/article/AA-01031
+	options {
+		(...)
+
+		# Listening on IPv6 is off by default.
+		listen-on-v6 { any; };
+
+		# This is the key. Note that you can write multiple of these if you need
+		# more IPv6 prefixes.
+		# "64:ff9b::/96" has to be the same as Jool's `pool6`.
+		dns64 64:ff9b::/96 {
+			# Options per prefix (if you need them) here.
+			# More info here: https://kb.isc.org/article/AA-01031
+		};
 	};
-};
-{% endhighlight %}
 
 And remember to reload.
 

doc/usr/en/intro-nat64.md

@@ -25,15 +25,13 @@ This document provides a general introduction to SIIT and NAT64.
 
 SIIT (_Stateless IP/ICMP Translation_) and NAT64 ("NAT six four", not "NAT sixty-four") are technologies meant to communicate networking nodes which only speak [IPv4](http://en.wikipedia.org/wiki/IPv4) with nodes that only speak [IPv6](http://en.wikipedia.org/wiki/IPv6).
 
-The idea is basically that of an "upgraded" [NAT](http://en.wikipedia.org/wiki/Network_address_translation); an "IPv4/IPv6 translator" not only replaces addresses and/or ports within packets, but also layer 3 headers.
+- SIIT mangles packets, simply replacing IPv4 headers with IPv6 headers and viceversa.
+- _Stateful NAT64_ (or "NAT64" for short) is a combination between an SIIT and a (theoretical) IPv6 NAT; the point is to mask several IPv6 nodes behind a few IPv4 addresses.
 
-- SIIT is the simpler form, and allows preconfigured 1-to-1 mappings between IPv4 addresses and IPv6 addresses.
-- A _Stateful NAT64_ (or NAT64 for short) allows several IPv6 nodes to dynamically share few IPv4 addresses (useful when you're a victim of [IPv4 address exhaustion](http://en.wikipedia.org/wiki/IPv4_address_exhaustion)).
+In their basic forms, SIIT only helps communicating nodes speaking different protocols, while NAT64 also helps with [IPv4 address exhaustion](http://en.wikipedia.org/wiki/IPv4_address_exhaustion) (at the cost of being more computationally expensive).
 
 For historic reasons, sometimes we mess up and label SIIT as "Stateless NAT64". Because this expression does not seem to appear in any relevant standards, we consider it imprecise, despite the fact it makes some degree of sense. If possible, please try to suppress it.
 
-An SIIT implementation mangles network headers and sometimes transport checksums. A Stateful NAT64 also mangles transport identifiers.
-
 That's all, really. Keep reading for more detail and examples.
 
 ## SIIT with EAM
@@ -50,8 +48,6 @@ Assuming everyone's default gateway is _T_, how do you communicate _A_ (IPv6) wi
 - You tell _A_, "_V_'s address is 2001:db8:4::16".
 - You tell _V_, "_A_'s address is 198.51.100.8".
 
-The first one is accomplished by SIIT. The latter can be done via DNS.
-
 This will happen:
 
 ![Fig.2 - EAM flow](../images/flow/eam-en.svg)

doc/usr/en/logging.md

@@ -24,15 +24,15 @@ Jool uses four levels in the severity spectrum (see `dmesg --help`):
 
 Debug messages are normally compiled out of Jool's binaries because they are lots and can slow things down. If you are testing or troubleshooting however, they can be of help.
 
-If you want Jool to print debug messages, go back to the kernel module's compilation step and run `make debug` instead of just `make`. Reinstall and remodprobe as you usually do, and you should see a lot of mumbling as a result of network traffic translation, which should give you ideas as to what might be wrong:
+If you want Jool to print debug messages, go back to the kernel module's compilation step and include the `-DDEBUG` flag. After reinstalling and remodprobing normally, you should see a lot of mumbling as a result of network traffic translation, which should give you ideas as to what might be wrong:
 
 	$ cd Jool/mod
-	$ make debug
+	$ make JOOL_FLAGS=-DDEBUG -- This is the key --
 	$ sudo make modules_install
 	$ sudo depmod
 	$
 	$ sudo modprobe -r jool_siit
-	$ sudo modprobe jool_siit
+	$ sudo modprobe jool_siit pool6=...
 	$
 	$ dmesg | tail -5
 	[ 3465.639622] ===============================================

doc/usr/en/mod-install.md

@@ -38,7 +38,7 @@ $ /bin/uname -r
 $ # OK, fine.
 {% endhighlight %}
 
-If you're just getting acquainted with IPv4/IPv6 Translation, some people have an easier time picturing the ordeal when the translator has two separate network interfaces (one to interact with IPv6 networks, one for IPv4 networks). This is not a requirement; you can get away with only one interface (by dual stacking on it), and you can also have more than one per protocol. This is possible because figuring out which interface should a packet be dispatched through is routing's problem, which is already well implemented in the kernel.
+If you're just getting acquainted with IPv4/IPv6 Translation, some people have an easier time picturing the ordeal when the translator has two separate network interfaces (one to interact with IPv6 networks, one for IPv4 networks). This is not a requirement; you can get away with only one interface (by [dual stacking](mod-run-alternate.html) on it), and you can also have more than one per protocol. This is possible because figuring out which interface should a packet be dispatched through is routing's problem, which is already well implemented in the kernel.
 
 Because the tutorials are first and foremost a tool to get newcomers on the right mindset, most of the deployment discussion will assume two separate interfaces (exemplified below: eth0 and eth1).
 

doc/usr/en/pool4.md

@@ -38,21 +38,21 @@ We call this "transport address domain" the "IPv4 pool" ("pool4" for short), and
 
 To illustrate:
 
-![TODO](../images/flow/pool4-simple1-en.svg)
+![Fig. 1 - n6's request](../images/flow/pool4-simple1-en.svg "Fig. 1 - n6's request")
 
 In Jool, we write transport addresses in the form `<IP address>#<port>` (as opposed to `<IP address>:<port>`). The packet above has source IP address `2001:db8::8`, source port (TCP or UDP) 5123, destination address `64:ff9b::192.0.2.24`, and destination port 80.
 
-Assuming pool4 holds transport addresses `203.0.113.1#5000` through `203.0.113.1#6000`, one possible translation of the packet is this:
+Assuming pool4 holds transport addresses `192.0.2.1#5000` through `192.0.2.1#6000`, one possible translation of the packet is this:
 
-![TODO](../images/flow/pool4-simple2-en.svg)
+![Fig. 2 - T's translation - version 1](../images/flow/pool4-simple2-en.svg "Fig. 2 - T's translation - version 1")
 
 Another one, equally valid, is this:
 
-![TODO](../images/flow/pool4-simple3-en.svg)
+![Fig. 3 - T's translation - version 2](../images/flow/pool4-simple3-en.svg "Fig. 3 - T's translation - version 2")
 
-NAT64s are not overly concerned with retaining source ports. In fact, for security reasons, [recommendations exist to drive NAT64s as unpredictable as possible](https://tools.ietf.org/html/rfc6056).
+NAT64s are not overly concerned with retaining source ports. In fact, for security reasons, [recommendations exist to drive NAT64s as unpredictable as possible]({{ site.draft-nat64-port-allocation }}).
 
-Each connection being translated will borrow a transport address from the pool. If you have _n_ transport addresses in pool4, you can have _n_ simultaneous translating connections. After a connection expires, its transport address becomes re-eligible for assignment.
+When defining the addresses and ports that will belong to your pool4, you need to be aware that they must not collide with other services or clients within the same machine. If _T_ tries to open a connection from transport address `192.0.2.1#5000` and at the same time a translation yields source transport address `192.0.2.1#5000`, Jool will end up combining the the information transmitted in both connections.
 
-You can fine-tune your pool4 table by means of the [`--pool4`](usr-flags-pool4.html) userspace configuration mode, and the connection expiration timeouts by tweaking  [`--udp-timeout`](usr-flags-global.html#udp-timeout), [`--tcp-est-timeout`](usr-flags-global.html#tcp-est-timeout), [`--tcp-trans-timeout`](usr-flags-global.html#tcp-trans-timeout) and [`--icmp-timeout`](usr-flags-global.html#icmp-timeout).
+Linux's ephemeral port range defaults to 32768-61000. Therefore, Jool's port range for any given address defaults to 61001-65535. [You can change the former by tweaking sysctl `sys.net.ipv4.ip_local_port_range`, and the latter by means of `--pool4 --add` userspace application commands](usr-flags-pool4.html#notes).
 

doc/usr/es/about.md

@@ -8,12 +8,12 @@ title: Acerca de ...
 # Acerca de ...
 
 
-JOOL es un [Traductor IPv4/IPv6](intro-nat64.html) de código abierto. Jool nació como un Stateful NAT64 pero ha sido ampliado para soportar también SIIT & SIIT EAM.
+Jool es un [Traductor IPv4/IPv6](intro-nat64.html) de código abierto. Nació como un Stateful NAT64 pero ha sido ampliado para soportar también SIIT.
 
 Jool es financiado y desarrollado por [NIC Mexico](http://nicmexico.mx/) en colaboración con el [ITESM](http://www.itesm.mx/).
 
 
-Contactáctanos por medio de [[email protected]](mailto:[email protected]). :mailbox:
+Contactáctanos por medio de [[email protected]](mailto:[email protected]). ![mailbox](../images/mailbox.png)
 
 
 

doc/usr/es/bib.md

@@ -9,26 +9,61 @@ title: BIB
 
 # BIB
 
-El _Binding Information Base_ (BIB) es una colección de tablas en un *Stateful NAT64*. Su especificación detallada se encuentra en la [Sección 3.1, del RFC 6146 ](http://tools.ietf.org/html/rfc6146#section-3.1).
+## Índice
 
-A modo de breve introducción podemos decir que los registros en esta base de datos mapean las direcciones de transporte de la conexión de un nodo IPv6 a la dirección de transporte que Jool está usando para enmascararlo en  IPv4. Por ejemplo, si el siguiente mapeo existe en tu NAT64:
+1. [Qué es la BIB?](#qu-es-la-bib)
+2. [Estructura](#estructura)
+3. [Tipos](#tipos)
+4. [Ejemplos](#ejemplos)<br />
+	a) [Registro 01](#registro-01)<br />
+	b) [Registro 02](#registro-02)<br />
+	c) [Registro 03](#registro-03)
+5. [Lecturas adicionales](#lecturas-adicionales)
 
+## Qué es la BIB?
 
-| Dirección IPv6 de Transporte | Dirección IPv4 de Transporte | Protocol |
-|------------------------------|------------------------------|----------|
-| 6::6#66                      | 4.4.4.4#44                   | TCP      |
+El _Binding Information Base_ (BIB) es una colección de tablas en el *Stateful NAT64*. Aunque este concepto nace con los NATs y está definido en el [RFC 2263, 1999](https://tools.ietf.org/html/rfc2663). 
 
+La podríamos llamar Base de Datos de Asociaciones o Enlaces porque en ella se guardará por pares la asociación (dirección IPv6, puerto IPv6) con  (dirección IPv4, puerto IPv4) si es una paquete de UDP o TCP. A esas duplas se le llaman [direcciones de transporte](http://tools.ietf.org/html/rfc6146#section-1.2). Cuando es un paquete de ICMP, se guardan los pares (dirección IPv6, identificador IPv6) con  (dirección IPv4, identificador IPv4). Para conocer todos los detalles sobre la BIB lee [la Sección 3.1, del RFC 6146 ](http://tools.ietf.org/html/rfc6146#section-3.1).
 
-Entonces los nodos IPv4 pueden encontrar el servicio TCP publicado en 6::6 por el puerto 66, enviando una solicitud a 4.4.4.4 por el puerto 44. En otra palabras, Jool engaña a los nodos IPv4 haciendoles pensar que 6::6#66 es 4.4.4.4#44.
+Dicho de otra manera, podemos decir que los registros en esta base de datos mapean las _direcciones de transporte_ de la conexión de un nodo IPv6 a la _dirección de transporte_ que Jool está usando para enmascarar éste en IPv4 en los protocolos UDP y TCP. Y mapeará la dupla (IP, identificador) de la conexión de un nodo IPv6 a la dupla (IP, identificador)  que Jool está usando para enmascarar éste en IPv4 si es un mensaje de ICMP.
 
-* LLamamos "registro BIB" a un registro en la tabla BIB (ej. el identificador de una máscara).
-* Llamamos "tabla BIB" a una colección de registros que comparten un protocolo. Hay tres protocolos soportados(TCP, UDP y ICMP), como resultado Jool tiene tres tablas BIB.
-* Llamamos "BIB" a la colección de las tres tablas BIB de Jool.
+## Estructura
+
+* **Registro BIB** es un registro en la tabla BIB y está compuesto por duplas.
+* **Tabla BIB** es una colección de registros que comparten un protocolo. Dado que hay tres protocolos soportados (TCP, UDP y ICMP) por el RFC 6146, como resultado Jool tiene tres tablas BIB.
+* **BIB** es la colección de las tres tablas BIB de Jool.
+
+## Tipos
 
 Hay dos tipos de registros BIB:
 
-* Estáticos: Los creas manualmente, para publicar un servicio IPv6 hacia la Internet IPv4. Ésto es análogo al [redireccionamiento de puertos](http://es.wikipedia.org/wiki/Redirecci%C3%B3n_de_puertos) href="http://en.wikipedia.org/wiki/Port_forwarding" en NATs normales.
-* Dinámicos: Jool crea estos al vuelo. Esto se tiene que hacer por que las conecciones IPv6 iniciadas también necesitan máscaras IPv4(de otra manera no serían capaces de recibir respuestas).
+* Dinámicos: Jool crea estos al iniciar la comunicación de IPv6 a IPv4, para acceder a lo servicios de IPv4.
+* Estáticos: Los puedes dar de alta manualmente, para publicar un servicio IPv6 hacia la Red de IPv4, ya sea privada o pública. Esto es análogo al [redireccionamiento de puertos](http://es.wikipedia.org/wiki/Redirecci%C3%B3n_de_puertos) en NATs.
+
+## Ejemplos
+
+Por ejemplo, si los siguiente mapeos existen en tu NAT64:
+
+| No.Registro| Dirección IPv6 de Transporte | Dirección IPv4 de Transporte | Protocol |
+|----------- |------------------------------|------------------------------|----------|
+|    01      | 6::6#66                      | 4.4.4.4#44                   | TCP      |
+|    02      |            |                              | TCP      |
+|    03      | 2001:db8::8#40000            | 203.0.113.2#                 | TCP      |
+
+
+### Registro 01
+
+Entonces los nodos IPv4 pueden encontrar el servicio TCP publicado en 6::6 por el puerto 66, enviando una solicitud a 4.4.4.4 por el puerto 44. En otras palabras, Jool engaña a los nodos IPv4 haciendoles pensar que 6::6#66 es 4.4.4.4#44.
+
+### Registro 02
+
+### Registro 03
+
+## Lecturas adicionales
+
+Si quieres aprender sobre:
 
-Ve la [introducción](static-bindings.html) o el [material de referencia](usr-flags-bib.html) para obtener información de cómo crear y destruir registros manualmente. Ve [`--address-dependent-filtering`](usr-flags-global.html#filtrado-dependiente-de-direccion) si crees que los registros dinámicos son peligrosos.
+1. Cómo crear y destruir registros manualmente, ve a [mapeo estático](static-bindings.html) o consulta [usando la opción BIB](usr-flags-bib.html).
+2. Cómo restringir el uso de los registros dinámicos, ve a [`--address-dependent-filtering`](usr-flags-global.html#address-dependent-filtering).
 

doc/usr/es/contact.md

@@ -11,33 +11,28 @@ Ponte en contacto con nosotros mediante:
 
 ## Lista de Discusión
 
--- [email protected] es una lista de correo general para la discusión pública del proyecto y la difusión de noticias. 
+-- [email protected] es una lista de correo general para la discusión pública del proyecto y difusión de noticias. 
 
-:email: Sus preguntas, solicitudes y comentarios son bienvenidos. Registrate [aquí](https://mail-lists.nic.mx/listas/listinfo/jool-list).
-
-Actualmente, existe un problema de "exceso" de seguridad que está siendo corregido.
+![email](../images/email.png) Preguntas, solicitudes y comentarios son bienvenidos. El registro es [aquí](https://mail-lists.nic.mx/listas/listinfo/jool-list).
 
 ## Lista de Noticias
 
--- [email protected] es una lista de correos para informar solo noticias.
+-- [email protected] es una lista de correos para difundir noticias.
 
-:mailbox_with_mail: Es utilizada para notificar sobre las nuevas versiones que están siendo liberadas en este sitio. Suscribete [aquí](https://mail-lists.nic.mx/listas/listinfo/jool-news).
+![mailbox_with_mail](../images/mailbox_with_mail.png) Es utilizada para notificar a usuarios sobre las nuevas versiones de Jool conforme se liberan. El registro es [aquí](https://mail-lists.nic.mx/listas/listinfo/jool-news).
 
-Solo el equipo de desarrollo puede enviar mails en esta lista, así que no tienes que preocuparte de recibir *spam*. <br />
-Debido a este próposito, esta lista raramente genera más de un e-mail por mes.
+Solo el equipo de desarrollo puede enviar mails en esta lista, de modo que no tiene riesgo de spam.  
+Debido a su próposito, esta lista raramente genera más de un correo por mes.
 
-## Lista Oficial de Errores
+## Bug Tracker
 
--- [Github corner](https://github.com/NICMx/NAT64/issues) es nuestra lista oficial de errores.
+-- [La lista de issues de Github](https://github.com/NICMx/NAT64/issues) es nuestro sistema de seguimiento de errores.
 
-:pencil: Este también es un buen lugar para solicitar nuevas características.
+![pencil](../images/pencil.png) Este también es un buen lugar para solicitar nuevas características.
 
 ## Mail a los Desarrolladores
 
--- [[email protected]](mailto:[email protected]) es una cuenta de correo que puedes utilizar para dirigirte 
-                                     solo a nosotros los desarrolladores.
-
-Aunque te podríamos dar algún consejo a través de este medio, nosotros agradeceremos que uses la cuenta de <br />
-[email protected] para este propósito, con el fin de quedar registrado y que pueda ser de beneficio para algún <br />
-otro usuario en el futuro.
+-- [[email protected]](mailto:[email protected]) es una cuenta de correo que se puede usar para alcanzar solamente a los desarrolladores.
+
+A pesar de que podemos proveer soporte mediante este medio, agredeceríamos que se prefiera [email protected] para este propósito para beneficiar futuras búsquedas.