howto/IPv6-Multicast.md
... ...
@@ -0,0 +1,168 @@
1
+# IPv6 Multicast
2
+
3
+The following guide illustrates how to set up an IPv6 multicast router using [PIM-SM](https://en.wikipedia.org/wiki/Protocol_Independent_Multicast#Sparse_mode) (Protocol Independent Multicast in Sparse Mode) with your own personal multicast prefix.
4
+
5
+## Quickstart
6
+
7
+* Install pim6sd from here: https://github.com/troglobit/pim6sd/
8
+ ```sh
9
+ cd /usr/src
10
+ git clone https://github.com/troglobit/pim6sd.git
11
+ cd pim6sd
12
+ ./autogen.sh
13
+ ./configure
14
+ make
15
+ ```
16
+* Find a peer who is already connected to the dn42 multicast backbone
17
+* Calculate your personal, embedded-RP multicast prefix matching your network prefix via [RFC3956](https://tools.ietf.org/html/rfc3956)
18
+ * Example:
19
+ * Pattern: `ff7e:<RIID><plen>:<prefix>::/96`
20
+ * Prefix: `fd00:2001:db8::/48`
21
+ * Prefix length: `48 == 0x30`
22
+ * RIID: An arbitrary number between `0x1` and `0xf`, for instance `0x2`
23
+ * Result:
24
+ * Multicast prefix: `ff7e:230:fd00:2001:db8::/96`
25
+ * RP address: ``fd00:2001:db8::<RIID>`` -> ``fd00:2001:db8::2``
26
+
27
+* Create a dummy interface to hold your calculated unicast Rendezvous Point address. This one needs to be reachable from within dn42. Also set "multicast on" on this dummy interface. Example:
28
+
29
+ ```
30
+ # /etc/network/interfaces.d/pim6sd
31
+ auto pim-router-id
32
+ iface pim-router-id inet manual
33
+ pre-up ip link add name $IFACE type dummy
34
+ post-up ip link set multicast on dev $IFACE
35
+ post-up ip -6 a a fd00:2001:db8::2/128 dev $IFACE
36
+ post-down ip link del $IFACE
37
+ ```
38
+
39
+* Create the configuration file:
40
+
41
+ ```sh
42
+ # /etc/pim6sd.conf
43
+ # disable all interfaces by default
44
+ default_phyint_status disable;
45
+
46
+ # enable the pim-router-id interface first to acquire the correct primary address
47
+ phyint pim-router-id enable;
48
+
49
+ # add multicast-capable peer interfaces below
50
+ phyint dn42-peer1 enable;
51
+
52
+ # configure rendezvous point for the personal multicast prefix
53
+ cand_rp pim-router-id;
54
+ group_prefix ff7e:230:fd00:2001:db8::/96;
55
+ ```
56
+
57
+ The `phyint` statement enables [PIM](https://tools.ietf.org/html/rfc7761) and [MLD](https://tools.ietf.org/html/rfc2710) on the target interface - by default all interfaces are in the disable state. Enable an interface if it is directed towards a multicast-capable peer or other multicast-capable routers in your autonomous system. Also enable it for downstream network segments with multicast listeners and senders, like for example your home (W)LAN segments.
58
+
59
+ With `cand_rp` and `group_prefix` statements you can configure this router as a Rendezvous Point (RP) for your personal multicast group prefix. The address on the interface given as `cand_rp` will be used as the primary address for your RP, it therefore *must* be routable.
60
+
61
+---
62
+
63
+## Testing & Applications
64
+
65
+### Creating a test network namespace
66
+
67
+On your router:
68
+
69
+```sh
70
+allow-hotplug pim-ns0
71
+iface pim-ns0 inet manual
72
+ pre-up ip link add pim-ns0 type veth peer name pim-ns1
73
+ post-up ip netns add pim-ns0
74
+ post-up ip link set addr 02:11:22:00:00:02 netns pim-ns0 name pim-ns0 up dev pim-ns1
75
+ post-up ip link set addr 02:11:22:00:00:01 up dev pim-ns0
76
+ post-up ip -6 a a fdd5:69d5:c530:1::1/64 dev pim-ns0
77
+ post-up ip netns exec pim-ns0 ip -6 a a fdd5:69d5:c530:1::2/64 dev pim-ns0
78
+ post-up ip netns exec pim-ns0 ip -6 r a default via fdd5:69d5:c530:1::1
79
+ post-down ip link del pim-ns0
80
+ post-down ip netns del pim-ns0
81
+```
82
+
83
+You can now switch into this test network namespace via "ip netns exec /bin/bash". Inside this network namespace you can try:
84
+
85
+### Creating a test multicast listener
86
+
87
+```
88
+$ socat -u UDP6-RECV:1234,reuseaddr,ipv6-join-group="[ff7e:230:fdd5:69d5:c530::123]:eth0" -
89
+```
90
+
91
+### Creating a test multicast sender
92
+
93
+First select which interface should be the default one for your multicast traffic. Then send multicast packets via ICMPv6:
94
+
95
+```
96
+$ ip -6 route add ff7e:230:fdd5:69d5:c530::/96 dev eth0 table local
97
+$ ping6 -t 16 ff7e:230:fdd5:69d5:c530::123
98
+```
99
+
100
+The "-t 16", a hop-limit of 16, is important here as **by default all multicast traffic is usually send with a hop-limit of just 1**.
101
+
102
+---
103
+
104
+## Advanced Configurations
105
+
106
+
107
+
108
+### Nomenclature
109
+
110
+#### Bootstrap Router (BSR)
111
+
112
+Router that collects multicast group information from all RP in the network and advertises it across the network.
113
+
114
+#### Rendezvous Point (RP)
115
+
116
+Router where senders and receivers will meet for a certain multicast address. Senders must send their data to it, after which it will be forwarded to receivers. As soon as a receivers DR learns of the sender it will ask their router to forward data along a direct path between sender and receiver.
117
+
118
+#### Designated Router (DR)
119
+
120
+First-hop router that stand in for sender and receiver on their downstream networks. The senders DR sends their data towards the RP encapsulated in PIM Register packets. The receivers DR will send join and prune messages to the RP, managing the group subscription.
121
+
122
+### RFC3306: "Unicast-Prefix-based IPv6 Multicast Addresses"
123
+
124
+Before RFC3956 (embedded RP addresses) personal, network prefix based multicast prefixes were calculated via RFC3306. Example:
125
+
126
+* Pattern: `ff3e:<plen>:<prefix>::/96`
127
+ * Prefix: `fd00:2001:db8::/48`
128
+ * Prefix length: `48 == 0x30`
129
+ * Result: `ff3e:30:fd00:2001:db8::/96`
130
+
131
+* Pros:
132
+ * More flexible RP address selection
133
+ * Allows filtering on the BSR
134
+
135
+* Cons:
136
+ * Needs a central BSR for coordination (or static RP configuration)
137
+ * Allows filtering on the BSR
138
+
139
+However you can usually just announce and use both RFC3306 and RFC3956 based multicast prefixes, if you want to. pim6sd allows adding multiple ``group_prefix`` entries.
140
+
141
+### Address Management
142
+
143
+#### Bootstrap Router
144
+
145
+If you want to be participate as a bootstrap router candidate, please read up on how PIM works first. If you join with a bootstrap router candidate add it here below with contact information and join #dn42-multicast on HackInt:
146
+* <BSR-ADDR1> - [email protected], foo@HackInt
147
+* <BSR-ADDR2> - ...
148
+
149
+#### Shared multicast addresses
150
+
151
+Next to personal multicast prefixes generated by network prefix (RFC3306 or RFC3956) there can also be multicast addresses not owned by a specific AS. In general any one can just set up a multicast sender or listener for those. However to work, they need a reliable RP for coordination.
152
+
153
+If you want to offer an RP candidate for a shared multicast address, please read up on how PIM works first. If you join with an RP candidate for a shared multicast address add it here below with contact information and join #dn42-multicast on HackInt:
154
+* <multicast-address1>/128:
155
+ - <RP-address1> - [email protected], foo@HackInt
156
+ - <RP-address2> - [email protected], bar@HackInt
157
+* <multicast-address2>/128:
158
+ - ...
159
+
160
+## Questions?
161
+
162
+* Join: ``#dn42-multicast`` on ``HackInt``
163
+
164
+---
165
+
166
+ToDo:
167
+* We have a solution for personal multicast prefixes tied to the network prefix of an AS owner. But what to do with multicast addresses that not only have listeners but also senders globally? We could have everyone add an additional "group_prefix ff00::/8" and then multicast router with the lowest address would win and become the central RP for all these addresses... not really scalable, robust or decentral though :-/. Should we use PIM-DM for some of these addresses instead (e.g. ones which generally have a low throughput, for instance Bittorrent Local Peer Discovery)? Or maybe those global addresses should be managed and configured as /128 and people who are interested in managing a specific, global multicast address will coordinate with each other?
168
+* bootstrap router coordination; according to RFCs a bootstrap router can alter/filter the multicast prefixes it received from candidate RPs. Should a bootstrap router check and filter any multicast prefix that was generated from a network prefix which does not match the network prefix used by the PR?
... ...
\ No newline at end of file