1 .TH 6BED4 8 "Februari 1, 2011"
2 .\" Please adjust this date whenever revising the manpage.
4 .\" Some roff macros, for reference:
5 .\" .nh disable hyphenation
6 .\" .hy enable hyphenation
8 .\" .ad b justify to both left and right margins
9 .\" .nf disable filling
10 .\" .fi enable filling
11 .\" .br insert line break
12 .\" .sp <n> insert n+1 empty lines
13 .\" for manpage-specific macros, see man(7)
15 6bed4router \- server-side daemon for 6bed4 service
18 [\fB\-d\fR \fI/dev/tunX\fR] \fB\-l\fR \fIv4addr\fR \fB\-L\fR \fIv6prefix/64\fR [\fB\-m\fR/\fB\-i\fR/\fBs\fR/\fBt\fR/\fBu\fR \fI...\fR]
24 Through a \fB6bed4router\fR daemon, it is possible to make a small range of IPv6
25 addresses available to a potentially large number of IPv4-only users. This means that even an IPv4-only
26 network can host IPv6-only applications, as long as they can fall back on
27 a tunnel based on this profile.
29 Use the \fB6bed4router\fR on nodes that support \fB6bed4peer\fR clients
30 anywhere; instead, use the \fB6bed4node\fR on nodes that want to provide
31 native IPv6 on a local network.
33 These tunnels are intended for mobile and embedded devices, to assist them
34 in instant changeover from being IPv4-only to eventually being IPv6-only.
36 restricted resources in embedded applications, this is likely to improve
37 the speed of transitioning to IPv6. To avoid cluttered access, these
38 tunnels should be reserved for resource-hampered devices. For routers,
39 transitioning mechanisms like 6to4 and 6in4 are more suitable. For
40 desktops, tunnelling routers or a direct link to a subscription tunnel
41 service is a better solution.
43 The NAT traversing aspect of this profile is needed to support the normal
44 openness of IPv6 connections. This is achieved by packing IPv6 into UDP
45 and then into IPv4. This is a guaranteed manner of traversing NAT,
46 provided that this daemon listens to a public IPv4 address. The daemon
47 currently does not support any other modes of operation.
49 The public-use aspect of this profile means that there is no requirement for
50 clients to register. However, this does not mean that the use of \fB6bed4router\fR
51 makes it possible to browse IPv6 networks anonymously; in order to
52 ensure traceability of abusive behaviour, the IPv4 address and UDP port
53 of the tunnel client are mentioned in the IPv6 address. See ADDRESS FORMAT
54 below for details, and SECURITY CHECKS for further precautions against abuse.
56 The intended application of clients under this transitionary mechanism are
57 IPv6-only devices that need a transport over an IPv4-only network. The
58 reason for defining IPv6-only device can be simplicity, or making IPv6
59 more efficient and/or more useful. To avoid making IPv6 a breaking
60 requirement in roll-outs, devices for such an IPv6-only service could
61 implement this mechanism to provide a simple backward-compatible mode for
62 IPv4-only network nodes, without impairing all advantages of being IPv6-only.
64 This daemon is in fact a stateless translation between an IPv4 client
65 and the general IPv6 world; to configure an IPv6 address on the tunnel
66 client side it will perform autoconfiguration over the tunnel. The
67 assigned prefix will be a /112, with 16 bits of interface identifiers
68 to fill in. The interface identifier 0 is reserved for the router,
69 or in other words, the tunnel server.
71 The tunnel server implementation listens to a UDP socket on port 3653
72 on the IPv4 side, and to a
73 tunnel endpoint to capture all traffic matching an IPv6 /64 prefix.
74 It basically tosses traffic back and forth between these interfaces,
75 but not without performing the SECURITY CHECKS desribed below
76 on what is tossed at it.
79 \fB\-d\fR \fI/dev/tunX\fR
81 \fB\-\-tundev\fR \fI/dev/tunX\fR
82 Instead of creating a tunnel for the duration that \fB6bed4router\fR runs,
83 use one that already exists and that has already been setup with
84 the proper IPv6 prefix. This option makes it possible for
85 non-root users to run \fB6bed4router\fR. All that is required is acccess to
86 the tunnel device by the user that runs \fB6bed4router\fR. Optional on Linux.
88 \fB\-l\fR \fIv4addr\fR
90 \fB\-\-v4listen\fR \fIv4addr\fR
91 Bind to the given local IPv4 address and listen for incoming IPv6
92 neighbour discovery packages as well as general IPv6 traffic. Required.
94 \fB\-L\fR \fIv6prefix/64\fR
96 \fB\-\-v6prefix\fR \fIv6prefix/64\fR
97 Bind to the given IPv6 address range through a tunnel device, and
98 forward incoming IPv6 messages to IPv4-based UDP tunnel endpoints.
99 See ADDRESS FORMAT below for an explanation of the lower half of
100 the IPv6 addresses. Required.
102 If no \fB\-d\fR option is given, a tunnel will be created for the time that
103 \fB6bed4router\fR is running, and the \fIv6prefix/64\fR is used as a router address
104 on that interface. Routing table entries will not be setup by \fB6bed4router\fR,
105 nor will the general ablity to forward IPv6 traffic.
107 \fB\-m\fR \fIv6addr\fR
109 \fB\-\-masqhost\fR \fIv6addr\fR
110 Use the given IPv6 address as the target for masqueraded operation. This
111 means that any ports setup with \fB\-\-sctp\fR, \fB\-\-tcp\fR or \fB\-\-udp\fR
113 to this address when addressed on the client's idea of the 6bed4 router
114 address. Note that the router only uses a few ICMPv6 messages, so the use
115 of these additional ports can benefit various applications, ranging from
116 authentication services to honeypots.
118 \fB\-s\fR \fIport\fR[\fB:\fIport\fR]
120 \fB\-t\fR \fIport\fR[\fB:\fIport\fR]
122 \fB\-u\fR \fIport\fR[\fB:\fIport\fR]
124 \fB\-sctp\fR \fIport\fR[\fB:\fIport\fR]
126 \fB\-tcp\fR \fIport\fR[\fB:\fIport\fR]
128 \fB\-udp\fR \fIport\fR[\fB:\fIport\fR]
129 Apply the masquerading port or port range for SCTP, TCP or UDP to the
130 masquerading host set by the last preceding \fB\-\-masqhost\fR option,
131 or use the tunnel's IPv6-side address
132 if none was set yet. Ports that have been previously bound will not make it,
133 so it is possible to first relay a port with \fB\-t 22\fR to a service and
134 then pass the rest to a honeypot with \fB\-t 1:65535\fR.
137 Apply masquerading for ICMPv6 to the masquerading host set by the last
138 preceding \fB\-\-masqhost\fR option, or use the tunnel's IPv6-side address
139 if none was set yet. The ICMPv6 messages with a special meaning to 6bed4
140 are exempted (Router and Neighbor Solicitation and Advertisement, as well
141 as Redirect) but other messages will be masqueraded.
146 Print usage information and exit.
149 An IPv6 address used from \fB6bed4router\fR reveals the IPv4 address and UDP port
150 used by the tunnel endpoint. This format is checked on sending from
151 the IPv4 tunnel to IPv6, and used to reconstruct the IPv4 tunnel access
152 information for traffic from IPv6 to the IPv4 tunnel.
154 The format of the IPv6 addresses managed by \fB6bed4router\fR are:
156 \fIv6prefix\fR + \fIv4addr\fR + \fIudp-port\fR + \fIinterfaceidentifier\fR
158 In this format, the \fIv6prefix\fR is configured with the \fB\-L\fR option,
159 and the \fIv4addr\fR with the \fB\-l\fR option. The \fIudp-port\fR is noted on
160 arrival of a packet on the IPv4 tunnel side of \fB6bed4router\fR.
162 The \fIinterfaceidentifier\fR is always 0 on the router side, and may be set
163 to other values to distinguish 65,535 different client addresses. As
164 the main application foreseen for \fB6bed4router\fR is to get IPv6-only tools and
165 devices working on an IPv4-only network, it is very likely that the clients
166 will pick a fixed \fIinterfaceidentifier\fR such as 1 and hard-code it.
168 Due to the IPv6 practice of assigning link-local names composed of \fBfe80::\fR
169 and the \fIinterfaceidentifier\fR, the router-side of a tunnel can always
170 be addressed as \fBfe80::0\fR and clients can be found at addresses ranging
171 from \fBfe80::1\fR to \fBfe80::ffff\fR.
173 Incoming IPv6 traffic destined for a serviced address is first checked
174 as specified under SECURITY CHECKS, and then forwarded to \fIudp-port\fR at
175 \fIv4addr\fR. In doing so, the IPv6 packet is embedded in whole inside
176 the UDP packet. The IPv6 addresses are not altered, but only used
177 to derive IPv4 contact information.
179 Outgoing IPv6 traffic arriving on the IPv4 tunnel side of \fB6bed4router\fR will
180 be checked to have been sent from the right \fIv6prefix\fR and mention
181 the \fIv4addr\fR and \fIudp-port\fR matching the client's public side. That
182 is, NAT may translate the IPv4 address and UDP port used, but these
183 parts of the IPv6 address should show how it is forwarded to \fB6bed4router\fR.
184 Note that autonegotiation protocol provides this necessary information at the
185 time the \fB6bed4router\fR daemon starts. If the NAT mapping changes during the uptime
186 of the tunnel, a new Router Advertisement is sent from tunnel server to
187 client, to notify it of the new prefix to use. The original message is
190 If it is desired to keep the same IPv6 address for longer periods, it
191 is recommended that the client keeps NAT state intact by regularly
192 sending over the UDP port to the tunnel endpoint. For example, a regular
193 ping could do that. Alternatively, a client-mode only daemon could
194 ensure that it is sending regularly during the times that an outside
195 party might wish to send to it. This is under the assumption that no
196 explicit mapping in NAT overtakes this responsibility of an active
197 mapping between the internal and external address space.
200 Not everything will be passed through \fB6bed4router\fR, even if this would be
201 technically possible. A few security checks are applied to silently
202 drop traffic that looks evil.
204 Packets should be long enough to at least contain the IPv6 traffic
205 and a minimal payload size. Also, it should not exceed a predefined
206 MTU of 1280 bytes for IPv6.
208 IPv6 traffic uploaded through the IPv4 side should reveal the proper
209 IPv4 settings in the IPv6 source address, as specified under
210 ADDRESS FORMAT above. This is basically the tunnel aspect of egress
213 Tunnel commands should adhere to the format of RFC 5722 and may not
214 contain any NUL characters.
216 Currently, \fB6bed4router\fR does not use ICMP notifications at the IPv4
217 level to provide smart feedback to an IPv6 client. It is undecided
218 at this point if this would add value.
220 To be able to fallback to this TSP profile, an IPv6-only application
221 needs to find a \fB6bed4router\fR or similar service. A general naming
222 or numbering scheme is needed to make that straightforward. The
223 \fB6bed4router\fR service could be setup privately and configured in
224 individual IPv6-only nodes, but it could accelerate the introduction
225 of IPv6-only nodes if this were organised by network providers.
227 Ideally, \fB6bed4router\fR would be near all heavily connected nodes
228 of the Internet. There, they would improve connectivity without
229 being a detour for the traffic. Alternatively, it would be located
230 in various uplinks. To optimise routing, it is possible to assign
231 a fixed IPv4 address and IPv6 prefix for \fB6bed4router\fR running
232 anywhere; its stateless operation means that traffic going back and
233 forth can go through different instances of \fB6bed4router\fR without
236 The \fB6bed4router\fR daemon is a piece of highly efficient code,
237 and it should be able to handle very high bandwidths. A stress
238 test has not been conducted yet.
240 This daemon does not pass on QoS headers as it should according to the
243 Released under a BSD-style license without advertisement clause.
245 The 0cpm project is an example of an IPv6-only SIP application
246 that can use \fB6bed4router\fR and comparable TSP tunnel services to
247 demonstrate the advantages of IPv6 to end users. It is also
248 a typical example of a transitionary need for something like
251 http://0cpm.org/ \- the homepage of the 0cpm project.
253 http://devel.0cpm.org/6bed4/ \- the homepage of \fB6bed4\fR.
255 RFC 5722 \- the authoritative description of TSP, of which \fB6bed4\fR
256 implements a specific profile for public service under NAT traversal.
258 \fB6bed4router\fR was written by Rick van Rein from OpenFortress.
259 It was created to support the 0cpm project.
projects / 6bed4 / blob