.\" .sp <n> insert n+1 empty lines
.\" for manpage-specific macros, see man(7)
.SH NAME
-6bed4server \- server-side daemon for 6bed4 service
+6bed4router \- server-side daemon for 6bed4 service
.SH SYNOPSYS
-.B 6bed4server
+.B 6bed4router
[\fB\-t\fR \fI/dev/tunX\fR] \fB\-l\fR \fIv4addr\fR \fB\-L\fR \fIv6prefix/64\fR
.PP
-.B 6bed4server
+.B 6bed4router
[\fB\-h\fR]
.SH DESCRIPTION
.PP
-Through a \fB6bed4server\fR daemon, it is possible to make a small range of IPv6
+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.
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 \fB6bed4server\fR
+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
\fB\-t\fR \fI/dev/tunX\fR
.TP
\fB\-\-tundev\fR \fI/dev/tunX\fR
-Instead of creating a tunnel for the duration that \fB6bed4server\fR runs,
+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 \fB6bed4server\fR. All that is required is acccess to
-the tunnel device by the user that runs \fB6bed4server\fR. Optional on Linux.
+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
the IPv6 addresses. Required.
.IP
If no \fB\-t\fR option is given, a tunnel will be created for the time that
-\fB6bed4server\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 \fB6bed4server\fR,
+\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
Print usage information and exit.
.SH ADDRESS FORMAT
.PP
-An IPv6 address used from \fB6bed4server\fR reveals the IPv4 address and UDP port
+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 \fB6bed4server\fR are:
+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 \fB6bed4server\fR.
+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 \fB6bed4server\fR is to get IPv6-only tools and
+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
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 \fB6bed4server\fR will
+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 \fB6bed4server\fR.
+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 6bed4server daemon starts. If the NAT mapping changes during the uptime
+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.
mapping between the internal and external address space.
.SH SECURITY CHECKS
.PP
-Not everything will be passed through \fB6bed4server\fR, even if this would be
+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
Tunnel commands should adhere to the format of RFC 5722 and may not
contain any NUL characters.
.SH BUGS
-Currently, \fB6bed4server\fR does not use ICMP notifications at the IPv4
+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 \fB6bed4server\fR or similar service. A general naming
+needs to find a \fB6bed4router\fR or similar service. A general naming
or numbering scheme is needed to make that straightforward. The
-\fB6bed4server\fR service could be setup privately and configured in
+\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, \fB6bed4server\fR would be near all heavily connected nodes
+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 \fB6bed4server\fR running
+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 \fB6bed4server\fR without
+forth can go through different instances of \fB6bed4router\fR without
posing problems.
.PP
-The \fB6bed4server\fR daemon is a piece of highly efficient code,
+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
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 \fB6bed4server\fR and comparable TSP tunnel services to
+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
-\fB6bed4server\fR.
+\fB6bed4router\fR.
.PP
http://0cpm.org/ \- the homepage of the 0cpm project.
.PP
RFC 5722 \- the authoritative description of TSP, of which \fB6bed4\fR
implements a specific profile for public service under NAT traversal.
.SH AUTHOR
-\fB6bed4server\fR was written by Rick van Rein from OpenFortress.
+\fB6bed4router\fR was written by Rick van Rein from OpenFortress.
It was created to support the 0cpm project.
projects / 6bed4 / commitdiff