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