c1071723a7a5dcdd2edf1846419d39ab403b1486
howto/Bird-communities.md
... | ... | @@ -28,7 +28,7 @@ bw = min(up,down) for asymmetric connections |
28 | 28 | (64511, 31) :: not encrypted |
29 | 29 | (64511, 32) :: encrypted with unsafe vpn solution |
30 | 30 | (64511, 33) :: encrypted with safe vpn solution (but no PFS - the usual OpenVPN p2p configuration falls in this category) |
31 | -(64511, 34) :: encrypted with safe vpn solution with PFS |
|
31 | +(64511, 34) :: encrypted with safe vpn solution with PFS (Perfect Forward Secrecy) |
|
32 | 32 | |
33 | 33 | Propagation: |
34 | 34 | - - for latency pick max(received_route.latency, link_latency) |
... | ... | @@ -36,6 +36,22 @@ Propagation: |
36 | 36 | ``` |
37 | 37 | For example, if your peer is 12ms away and the link speed between you is 250Mbit/s and you are peering using OpenVPN P2P, then the community string would be (3, 24, 33). |
38 | 38 | |
39 | +You might want to use this [script](https://github.com/Mic92/bird-dn42/blob/master/bgp-community.rb) to measure round trip time and calculate community values automatically: |
|
40 | + |
|
41 | +``` |
|
42 | +$ ruby bgp-community.rb --help |
|
43 | +USAGE: bgp-community.rb host mbit_speed unencrypted|unsafe|encrypted|pfs |
|
44 | + -6, --ipv6 Assume ipv6 for ping |
|
45 | +$ ruby bgp-community.rb 212.129.13.123 300 encrypted |
|
46 | + # 15 ms, 300 mbit/s, encrypted tunnel (updated: 2016-02-11) |
|
47 | + import where dn42_import_filter(3,24,33); |
|
48 | + export where dn42_export_filter(3,24,33); |
|
49 | +$ ruby bgp-community.rb -6 dn42-2.higgsboson.tk 1000 pfs |
|
50 | + # 11 ms, 1000 mbit/s, pfs tunnel (updated: 2016-02-11) |
|
51 | + import where dn42_import_filter(3,25,34); |
|
52 | + export where dn42_export_filter(3,25,34); |
|
53 | +``` |
|
54 | + |
|
39 | 55 | See also this [mail](https://lists.nox.tf/pipermail/dn42/2015-December/001259.html) for communities for route origin. |
40 | 56 | |
41 | 57 | ## Example configurations |
howto/Bird.md
... | ... | @@ -384,4 +384,6 @@ bird> show route export <somepeer> # shows the route you export to someone |
384 | 384 | ``` |
385 | 385 | |
386 | 386 | # External Links |
387 | +* detailed bird configuration from Mic92: https://github.com/Mic92/bird-dn42 |
|
387 | 388 | * more bgp commands: http://danrimal.net/doku.php?id=wiki:bgp:bird:postupy |
389 | + |
howto/Getting-started.md
... | ... | @@ -93,10 +93,12 @@ To register for example 172.20.150.0/26, you need to fill in 172.20.150.0-172.20 |
93 | 93 | |
94 | 94 | **Note:** Reverse DNS works with _any_ prefix length, as long as your [recursive nameserver](/services/DNS) supports [RFC 2317](https://www.ietf.org/rfc/rfc2317.txt). Don't go for a /24 _just to have RDNS_. |
95 | 95 | |
96 | -If you want to register an [IPv6 prefix](/FAQ#frequently-asked-questions_what-about-ipv6-in-dn42), you can create an `inet6num` object. A single /48 allocation in [ULA space](https://www.sixxs.net/tools/grh/ula/) will likely provide more than enough room for all devices you will ever connect. Some people use “vanity” prefixes like fd42:23:_xyz_::/48 instead of the fully standard-conformant pseudorandom ones. |
|
96 | +If you want to register an [IPv6 prefix](/FAQ#frequently-asked-questions_what-about-ipv6-in-dn42), you can create an `inet6num` object. A single /48 allocation in [ULA space](https://www.sixxs.net/tools/grh/ula/) will likely provide more than enough room for all devices you will ever connect. Some people use “vanity” prefixes like fd42:_xyz_::/48 instead of the fully standard-conformant pseudorandom ones. |
|
97 | 97 | |
98 | 98 | [Unique Local IPv6 Generator](http://unique-local-ipv6.com/) |
99 | 99 | |
100 | +If you plan to announce this network in dn42, which you probably want in most cases, you also need to create a `route` object for ipv4 and a `route6` object for ipv6. This information is used for ROA checks (route origin authorization). If you skip this step, your network gets probably filtered by some peers. |
|
101 | + |
|
100 | 102 | # Get some peers |
101 | 103 | |
102 | 104 | In dn42, there is no real distinction between peering and transit: in most cases, everybody serves as an upstream provider to all its peers. Note that if you have very slow connectivity to the Internet, you may want to avoid providing transit between your peers, which can be done by filtering or prepending your ASN. For the sake of sane routing, try to peer with people on the same continent to avoid inefficient routing, <50ms is a good rule of thumb. You can also look into Bird communities if you are using Bird to mark the latency for the [link](/howto/Bird-communities). |
howto/IPv6.md
... | ... | @@ -0,0 +1,78 @@ |
1 | +_Work in progress_ |
|
2 | + |
|
3 | +## Introduction |
|
4 | + |
|
5 | +DN42 is a somewhat unique undertaking, and a great way to learn about networking and routing techs. |
|
6 | +If you feel like spicing the challenge up a bit, why not get familiar with IPv6 at the same time ? |
|
7 | + |
|
8 | +There's nothing too different from IPv4, except one major point: it's a separate network space, and therefore you might not be able to reach the IPv4-part of DN42. That is, without NAT64, proxies, etc.. (read more below!) or if you're running dual-stack, both IPv4 and IPv6 at the same time. |
|
9 | + |
|
10 | +## Getting Started |
|
11 | + |
|
12 | +If you're already running IPv4 on DN42, here's how to get started: |
|
13 | + * Register an inet6num block on the registry. A /56-size prefix is good, but with the space available in IPv6 space, you can probably go for /48 |
|
14 | + * Setup your interfaces to use them |
|
15 | + * Negociate with your v6-capable peers to setup peering sessions to allow your v6 prefixes |
|
16 | + * ??? |
|
17 | + * Profit! |
|
18 | + |
|
19 | +If not, you can follow the instructions on the [Getting Started](GettingStarted) page, as they'll mostly apply to IPv6 aswell. |
|
20 | + |
|
21 | +## What can i do on DN42-v6 ? |
|
22 | + |
|
23 | +A fair share of the services are available through IPv6. However some of the well known addresses might not work, so you'll have to find alternative services. |
|
24 | + |
|
25 | +Quick list of some native-IPv6-capable services: |
|
26 | + * Some instances of this Wiki, but no anycast yet |
|
27 | + * Anycast [whois.dn42](whois.dn42) |
|
28 | + * DNS, including anycast |
|
29 | + * Media boards, including DN42-Chan |
|
30 | + * torrents.dn42 |
|
31 | + * wiki.dn42/internal.dn42 |
|
32 | + |
|
33 | +What doesn't work (yet?): |
|
34 | + * Search engines, none seems to support IPv6 currently |
|
35 | + * Network Map (it doesn't show v6 AS-PATHs) |
|
36 | + * Pretty much everything from Freifunk and ChaosVPN |
|
37 | + * Any services hosted by Nixnodes or e-utp.dn42 |
|
38 | + |
|
39 | +## Accessing legacy services from an IPv6-only stack |
|
40 | +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. |
|
41 | +This can typically be done in two ways: |
|
42 | + * A dual-stack Proxy with Remote DNS |
|
43 | + * A dual-stack Router with NAT64, plus DNS64 services |
|
44 | + |
|
45 | +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. |
|
46 | + |
|
47 | +### With a SOCKS5 proxy and Remote DNS |
|
48 | +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. |
|
49 | + |
|
50 | +### NAT64+DNS64 |
|
51 | +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. |
|
52 | +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?) |
|
53 | + |
|
54 | +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). |
|
55 | + |
|
56 | +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) |
|
57 | +As such, any address that can only resolve to IPv4 will now also resolve to an address corresponding to it through the NAT64 prefix. |
|
58 | + |
|
59 | +## Routing to Internet and DN42 |
|
60 | +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 ? |
|
61 | + |
|
62 | +### With NPT |
|
63 | +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 ? |
|
64 | + |
|
65 | +Enter NPT. Address your services using a reserved private block, and map that block to a public block upon routing to internet. |
|
66 | +For example, if you've been assigned a public /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. |
|
67 | + |
|
68 | +In Linux's netfilter, this can be implemented through the use of the NETMAP target, for the example above: |
|
69 | +``` |
|
70 | +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 |
|
71 | +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 |
|
72 | +``` |
|
73 | + |
|
74 | + |
|
75 | +### With Multiple Prefixes |
|
76 | + |
|
77 | +## More Info |
|
78 | +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 |
internal/Internal-Services.md
... | ... | @@ -119,8 +119,9 @@ An [Advanced Direct Connect](https://en.wikipedia.org/wiki/Advanced_Direct_Conne |
119 | 119 | | sftp://anonsftp:Iich0zieC3retaid@files.crest.dn42:2212/ | 12TB | 1Gb/s | incoming writable | |
120 | 120 | | http://172.23.136.33 | | 100Mbit/s | some mediafiles/software | |
121 | 121 | | http://files.martin89.dn42/ | | max 2Mbit/s | download only | |
122 | -| http://172.22.42.2 | ~6.5TB | ~400kbit | WebDAV enabled, up 24/7z | | |
|
123 | -| http://filer.mhm.dn42 | 4TB | 1GBit | 24/7/365 | | |
|
122 | +| http://172.22.42.2 | ~6.5TB | ~400kbit | WebDAV enabled, up 24/7z | | |
|
123 | +| http://filer.mhm.dn42 | 4TB | 1GBit | 24/7/365 | | |
|
124 | +| http://storage.hq.c3d2.de:8080/rpool | | 2.4Mbit/s | download only webdav:k-ot| |
|
124 | 125 | |
125 | 126 | ### Down? |
126 | 127 |
services/Distributed-Wiki.md
... | ... | @@ -148,7 +148,9 @@ server { |
148 | 148 | server_name internal.dn42 wiki.dn42 as<aut-num>-<cc>.wiki.dn42; |
149 | 149 | |
150 | 150 | listen 172.23.0.80:80 default; |
151 | - listen <unicast-address>:80 default; |
|
151 | + listen [fd42:d42:d42:80::1]:80 default; |
|
152 | + listen 80; |
|
153 | + listen [::]:80; |
|
152 | 154 | |
153 | 155 | add_header X-SiteID '<aut-num>-<cc>'; |
154 | 156 | |
... | ... | @@ -164,7 +166,9 @@ server { |
164 | 166 | server_name internal.dn42 wiki.dn42 as<aut-num>-<cc>.wiki.dn42; |
165 | 167 | |
166 | 168 | listen 172.23.0.80:443 ssl default; |
167 | - listen <unicast-address>:443 ssl default; |
|
169 | + listen [fd42:d42:d42:80::1]:443 ssl default; |
|
170 | + listen 443 ssl; |
|
171 | + listen [::]:443 ssl; |
|
168 | 172 | |
169 | 173 | ssl on; |
170 | 174 | ssl_certificate <path>/ssl.crt; |
... | ... | @@ -200,7 +204,7 @@ group gollum-watchdog { |
200 | 204 | peer-as <peeras>; |
201 | 205 | } |
202 | 206 | |
203 | - ## (example) peer with one of our iBGP speakers: |
|
207 | + ## (example ipv4) peer with one of our iBGP speakers: |
|
204 | 208 | neighbor 172.22.0.1 { |
205 | 209 | router-id 172.23.0.80; |
206 | 210 | local-address 172.22.0.2; |
... | ... | @@ -208,6 +212,14 @@ group gollum-watchdog { |
208 | 212 | peer-as 123456; |
209 | 213 | } |
210 | 214 | |
215 | + ## (example ipv6) peer with one of our iBGP speakers: |
|
216 | + neighbor fd42:4992:6a6d::1 { |
|
217 | + router-id 172.22.0.80; |
|
218 | + local-address fd42:4992:6a6d::2; |
|
219 | + local-as 123456; |
|
220 | + peer-as 123456; |
|
221 | + } |
|
222 | + |
|
211 | 223 | ## ... |
212 | 224 | |
213 | 225 | process watch-gollum { |
... | ... | @@ -229,13 +241,16 @@ Run `gollum-watchdog.sh` in a shell first to validate it's working: |
229 | 241 | CURL=curl |
230 | 242 | |
231 | 243 | ## url's to check (all listed must be alive to send announce) |
232 | -URL=( "http://172.23.0.80" "https://172.23.0.80" ) |
|
244 | +URL=("http://172.23.0.80" "https://172.23.0.80" "http://[fd42:d42:d42:80::1]" "https://[fd42:d42:d42:80::1]") |
|
233 | 245 | |
234 | 246 | ## the anycast route (/28 due to prefix size limits) |
235 | 247 | ROUTE='172.23.0.80/28' |
236 | - |
|
248 | +## the anycast v6 route (/64 due to prefix size limits) |
|
249 | +ROUTE6='fd42:d42:d42:80::/64' |
|
250 | + |
|
237 | 251 | ## the next-hop we'll be advertising to neighbor(s) |
238 | 252 | NEXTHOP='<source-address>' |
253 | +NEXTHOP6='<source-address-v6>' |
|
239 | 254 | |
240 | 255 | ## regex match this keyword against HTTP response from curl |
241 | 256 | VALIDATE_KEYWORD='gollum' |
... | ... | @@ -243,45 +258,45 @@ VALIDATE_KEYWORD='gollum' |
243 | 258 | INTERVAL=60 |
244 | 259 | |
245 | 260 | ########################### |
246 | - |
|
247 | -RUN_STATE=0 |
|
248 | - |
|
249 | -check_urls() { |
|
250 | - for url in "${URL[@]}"; do |
|
251 | - |
|
261 | + |
|
262 | +RUN_STATE=0 |
|
263 | + |
|
264 | +check_urls() { |
|
265 | + for url in "${URL[@]}"; do |
|
266 | + |
|
252 | 267 | ## workaround curl errno 23 when piping |
253 | 268 | http_response=`${CURL} --insecure -L -o - "${url}"` |
254 | - |
|
255 | - echo "${http_response}" | egrep -q "${VALIDATE_KEYWORD}" || { |
|
256 | - return 1 |
|
257 | - } |
|
269 | + |
|
270 | + echo "${http_response}" | egrep -q "${VALIDATE_KEYWORD}" || { |
|
271 | + return 1 |
|
272 | + } |
|
258 | 273 | |
259 | 274 | ## add more checks |
260 | 275 | |
261 | - done |
|
262 | - return 0 |
|
276 | + done |
|
277 | + return 0 |
|
263 | 278 | } |
264 | 279 | |
265 | 280 | while [ 1 ]; do |
266 | - if [ ${RUN_STATE} -eq 0 ]; then |
|
267 | - check_urls && { |
|
268 | - RUN_STATE=1 |
|
269 | - echo "announce route ${ROUTE} next-hop ${NEXTHOP}" |
|
270 | - } |
|
271 | - else |
|
272 | - check_urls || { |
|
273 | - RUN_STATE=0 |
|
274 | - echo "withdraw route ${ROUTE} next-hop ${NEXTHOP}" |
|
275 | - } |
|
276 | - fi |
|
277 | - |
|
278 | - sleep ${INTERVAL} |
|
279 | - |
|
280 | -done |
|
281 | + if [ ${RUN_STATE} -eq 0 ]; then |
|
282 | + check_urls && { |
|
283 | + RUN_STATE=1 |
|
284 | + echo "announce route ${ROUTE} next-hop ${NEXTHOP}" |
|
285 | + echo "announce route ${ROUTE6} next-hop ${NEXTHOP6}" |
|
286 | + } |
|
287 | + else |
|
288 | + check_urls || { |
|
289 | + RUN_STATE=0 |
|
290 | + echo "withdraw route ${ROUTE} next-hop ${NEXTHOP}" |
|
291 | + echo "withdraw route ${ROUTE6} next-hop ${NEXTHOP6}" |
|
292 | + } |
|
293 | + fi |
|
294 | + |
|
295 | + sleep ${INTERVAL} |
|
296 | + |
|
297 | +done |
|
281 | 298 | |
282 | 299 | exit 0 |
283 | - |
|
284 | - |
|
285 | 300 | ``` |
286 | 301 | |
287 | 302 | #### Run |
... | ... | @@ -337,7 +352,6 @@ case ${1} in |
337 | 352 | esac |
338 | 353 | |
339 | 354 | exit 0 |
340 | - |
|
341 | 355 | ``` |
342 | 356 | |
343 | 357 |
services/IPv6-Anycast.md
... | ... | @@ -15,6 +15,8 @@ Remember, if you announce an anycast /64, then you need to provide **all** servi |
15 | 15 | | Recursive DNS resolver | `fd42:d42:d42:53::1/64` | UDP/53 | `.` and `dn42.` [Providers][] | |
16 | 16 | | Whois Database | `fd42:d42:d42:43::1/64` | TCP/43 | | |
17 | 17 | | TOR SOCKS5 Proxy | `fd42:d42:d42:9050::1/64` | TCP/9050 | | |
18 | +| internal Wiki | `fd42:d42:d42:80::1/64` | TCP/80, TCP/443 | | |
|
19 | + |
|
18 | 20 | |
19 | 21 | [Providers]: Providing-Anycast-DNS#Persons-providing-anycast-DNS-for-IPv6 |
20 | 22 |