Changes in ca11ffb: Updated IPv6 (markdown)

				howto/IPv6.md
			
          @@ -35,4 +35,41 @@ What doesn't work (yet?):

            * Pretty much everything from Freifunk and ChaosVPN

            * Any services hosted by Nixnodes or e-utp.dn42 

          -## Accessing legacy services: NAT64 and DNS64

          +## Accessing legacy services from an IPv6-only stack

          +In order to access legacy IPv4 services from the IPv6 side of DN42, you're going to need some kind of service to jump from one to the other.

          +This can typically be done in two ways:

          + * A dual-stack Proxy with Remote DNS

          + * A dual-stack Router with NAT64, plus DNS64 services

          +

          +It's important to note that since these services require IPv4 connectivity, you can't set them up yourself if you are running IPv6-only. You'll need to ask another DN42 participant to be your provider for these services, effectively using his node as a gateway/proxy.

          +

          +### With a SOCKS5 proxy and Remote DNS

          +Just set it up like you would usually. Any IPv4 connection going through the proxy will be made to the proxy by IPv6, then from the proxy to target using IPv4.

          +

          +### NAT64+DNS64

          +In order to maintain backward compatibility, a number of methods have been used to be able to reach IPv4 space from IPv6. NAT-PT was deprecated, so this mostly leaves us with NAT64.

          +NAT64 simply consists in embedding IPv4 addresses after an IPv6 prefix, and mapping the whole prefix to the whole of IPv4 space. Thanksfully, that's easily doable because we have 128-bit wide addresses in IPv6. As the name implies, we however have to perform Dynamic-NAT on the IPv4 side to squeeze all the incoming v6 space in v4 addresses (though it should be possible to run 1-1 mappings, but in that case, why not get a v4 address and NAT to it to begin with?)

          +

          +Currently, NAT64 support in DN42 is non-existant, though there are ongoing experimentations with it. Technically, it is possible to announce a global anycast prefix for NAT64, allowing seamless IPv4 connectivity from any properly configured IPv6 host, or any using the DNS64 (which can also be setup on the anycast servers).

          +

          +DNS64 itself simply allow to synthetizes AAAA records from the received usual A records. Because DNS runs at the transport level and does not care for Layer 3 triffles, this is a service that you can run on your Nameserver even without being Dual-Stack capable. (TODO: DNS64 Howto with BIND9)

          +As such, any address that can only resolve to IPv4 will now also resolve to an address corresponding to it through the NAT64 prefix.

          +

          +## Routing to Internet and DN42

          +So now that you've got IPv6 setup for DN42, you'd like to start using it on the Internet aswell. Or maybe you already do. But how to use your services on both public Internet and DN42 ?

          +

          +### With NPT

          +A first approach is to use NPT: Network Prefix Translation. Yes, this sounds a lot like NAT, but fear not: it does not have most of its problems as it is fully stateless. Initially, the purpose of NPT was to allow multi-homing without an ASN: how can you be reachable through several prefixes allocated by different ISPs ? The IPv6-way of doing it would be to assign multiple addresses from the multiple prefixes to all your nodes, but isn't that just too complicated ?

          +

          +Enter NPT. Address your services using a reserved private block, and map that block to a public block upon routing to internet. 

          +For example, if you've been assigned the <PUBLIC-PREFIX>::/48 prefix, and want to be reachable on DN42 aswell, you can use only ULA addresses from DN42 internally (or your own!), then map them to outside prefixes. Note that they'll need to all use the same prefix size to maintain the one-to-one mapping, so you may have to subnet the public prefix.

          +

          +In Linux's netfilter, this can be implemented through the use of the NETMAP target, for the example above:

          +`ip6tables -t nat -A POSTROUTING -d 2000::/3 -s <DN42-PREFIX>:<SUBNET>::/56 -j NETMAP --to <PUBLIC-PREFIX>:<SUBNET>::/56; # Map ULA to the public prefix for outgoing packets

          +ip6tables -t nat -A PREROUTING -s 2000::/3 -d <PUBLIC-PREFIX>:<SUBNET>::/56 -j NETMAP --to <DN42-PREFIX>:<SUBNET>::/56; # Map public prefix to ULA for incoming packets`

          +

          +

          +### With Multiple Prefixes

          +

          +## More Info

          +This page is a work in progress. Please contact Fira if you feel like more information should be added here! Also see ASN 4242423218 for an example of IPv6-only AS on DN42.

          \ No newline at end of file

...	...	@@ -35,4 +35,41 @@ What doesn't work (yet?):
35	35	* Pretty much everything from Freifunk and ChaosVPN
36	36	* Any services hosted by Nixnodes or e-utp.dn42
37	37
38		-## Accessing legacy services: NAT64 and DNS64
	38	+## Accessing legacy services from an IPv6-only stack
	39	+In order to access legacy IPv4 services from the IPv6 side of DN42, you're going to need some kind of service to jump from one to the other.
	40	+This can typically be done in two ways:
	41	+ * A dual-stack Proxy with Remote DNS
	42	+ * A dual-stack Router with NAT64, plus DNS64 services
	43	+
	44	+It's important to note that since these services require IPv4 connectivity, you can't set them up yourself if you are running IPv6-only. You'll need to ask another DN42 participant to be your provider for these services, effectively using his node as a gateway/proxy.
	45	+
	46	+### With a SOCKS5 proxy and Remote DNS
	47	+Just set it up like you would usually. Any IPv4 connection going through the proxy will be made to the proxy by IPv6, then from the proxy to target using IPv4.
	48	+
	49	+### NAT64+DNS64
	50	+In order to maintain backward compatibility, a number of methods have been used to be able to reach IPv4 space from IPv6. NAT-PT was deprecated, so this mostly leaves us with NAT64.
	51	+NAT64 simply consists in embedding IPv4 addresses after an IPv6 prefix, and mapping the whole prefix to the whole of IPv4 space. Thanksfully, that's easily doable because we have 128-bit wide addresses in IPv6. As the name implies, we however have to perform Dynamic-NAT on the IPv4 side to squeeze all the incoming v6 space in v4 addresses (though it should be possible to run 1-1 mappings, but in that case, why not get a v4 address and NAT to it to begin with?)
	52	+
	53	+Currently, NAT64 support in DN42 is non-existant, though there are ongoing experimentations with it. Technically, it is possible to announce a global anycast prefix for NAT64, allowing seamless IPv4 connectivity from any properly configured IPv6 host, or any using the DNS64 (which can also be setup on the anycast servers).
	54	+
	55	+DNS64 itself simply allow to synthetizes AAAA records from the received usual A records. Because DNS runs at the transport level and does not care for Layer 3 triffles, this is a service that you can run on your Nameserver even without being Dual-Stack capable. (TODO: DNS64 Howto with BIND9)
	56	+As such, any address that can only resolve to IPv4 will now also resolve to an address corresponding to it through the NAT64 prefix.
	57	+
	58	+## Routing to Internet and DN42
	59	+So now that you've got IPv6 setup for DN42, you'd like to start using it on the Internet aswell. Or maybe you already do. But how to use your services on both public Internet and DN42 ?
	60	+
	61	+### With NPT
	62	+A first approach is to use NPT: Network Prefix Translation. Yes, this sounds a lot like NAT, but fear not: it does not have most of its problems as it is fully stateless. Initially, the purpose of NPT was to allow multi-homing without an ASN: how can you be reachable through several prefixes allocated by different ISPs ? The IPv6-way of doing it would be to assign multiple addresses from the multiple prefixes to all your nodes, but isn't that just too complicated ?
	63	+
	64	+Enter NPT. Address your services using a reserved private block, and map that block to a public block upon routing to internet.
	65	+For example, if you've been assigned the <PUBLIC-PREFIX>::/48 prefix, and want to be reachable on DN42 aswell, you can use only ULA addresses from DN42 internally (or your own!), then map them to outside prefixes. Note that they'll need to all use the same prefix size to maintain the one-to-one mapping, so you may have to subnet the public prefix.
	66	+
	67	+In Linux's netfilter, this can be implemented through the use of the NETMAP target, for the example above:
	68	+`ip6tables -t nat -A POSTROUTING -d 2000::/3 -s <DN42-PREFIX>:<SUBNET>::/56 -j NETMAP --to <PUBLIC-PREFIX>:<SUBNET>::/56; # Map ULA to the public prefix for outgoing packets
	69	+ip6tables -t nat -A PREROUTING -s 2000::/3 -d <PUBLIC-PREFIX>:<SUBNET>::/56 -j NETMAP --to <DN42-PREFIX>:<SUBNET>::/56; # Map public prefix to ULA for incoming packets`
	70	+
	71	+
	72	+### With Multiple Prefixes
	73	+
	74	+## More Info
	75	+This page is a work in progress. Please contact Fira if you feel like more information should be added here! Also see ASN 4242423218 for an example of IPv6-only AS on DN42.
...	...	\ No newline at end of file