The Hyperledger implementation (https://github.com/hyperledger/iroha-ed25519)
contains changes to the assembly code to allow PIC. This in turn fixes
compilation/linking of ZeroTier One when "full hardening" flags are used.
Version 1.1.6 contains several significant improvements for use in complex network
environments along with some minor bug fixes and improvements to path stability and
dead path detection.
ROUTE MANAGEMENT AND FULL TUNNEL SUPPORT
1.1.6 is the first version of ZeroTier One to permit "full tunnel" (default route
override) operation on Linux, Mac, and Windows. This allows all Internet traffic
to be tunneled through ZeroTier while allowing ZeroTier peer-to-peer traffic to
continue to use the physical interface. 1.1.6 also brings route management support
and permissions settings for local networks to control whether networks are allowed
to modify the routing table or override default routing.
This is currently considered a beta/experimental feature and must be enabled via
the command line interface.
Route management and default route override requires support at the network controller.
When my.zerotier.com is updated and ready, we will post more information and testing
instructions at: https://www.zerotier.com/community
HIGHLY SCALABLE CONTAINER NETWORKING
1.1.6 also brings a new multicast-free (NDP emulated) IPv6 private addressing scheme
called "6plane." 6plane provides each host with a private IPv6 /80 and routes *all*
IPv6 traffic for this subnet to the host via transparent NDP emulation. This /80 can
then be assigned to Docker or other container/VM managers to assign a network-wide
IPv6 /128 to every container. Since NDP is emulated and multicast isn't needed, this
system can scale to millions of containers or more on a single backplane network with
a high degree of efficiency and reliability.
6plane also requires controller support. Look for it at my.zerotier.com once we have
upgraded our core infrastructure and web UIs.
(All hosts must be running 1.1.6 for 6plane to work properly. Other IPv6 addresses
or addressing modes are not affected and normal IPv6 NDP will continue to work
alongside 6plane in the same network.)
OTHER CHANGES
* Upgraded bundled miniupnpc, libnatpmp, and http-parser.
* New Debian and RPM packaging that is closer to compliance with distribution
guidelines, and a new Dockerized Linux package build system in linux-build-farm/
that can build every package on actual images of the correct distribution.
* Improvements to dead path detection.
* IPv6 now uses keepalive because a significant number of stateful IPv6 edge
routers have very short timeouts (30 seconds or less!).
* Significant performance improvements to network controllers under high load.
* Enable -fstack-protector-strong for better stack canary (security) support
in binaries. Note that this may require newer gcc/g++ or clang.
COMING SOON
The next version of ZeroTier One should have a new Mac UI. It's a system tray app
that looks and behaves a lot like the Mac WiFi pulldown menu. We'll also be adding
GUI support for default route and route management options and other new features.
Shortly after that we plan on adding full OpenFlow-like SDN rules engine support
to the ZeroTier core, making our planetary Ethernet switch a fully manageable smart
switch and enabling sophisticated security and flow rule management.
ZeroTier 1.1.0 introduces a number of fixes and improvements in several areas.
We incremented the secondary version to indicate the significance of this release.
Version numbering has been a bit ad-hoc in the past. In future versions we will
adopt the following scheme: odd-numbered revision numbers like 1.1.1 will indicate
development versions, while even numbered ones like 1.1.2 will indicate tagged
releases. The public git repo branching has also been revised: master will always
be the latest tagged release, dev will be usually-working development, and edge
will host maybe-broken "bleeding edge" development. Pull requests on GitHub should
generally be made against dev, not master or edge. Other branches that may appear
from time to time may be feature or experimental branches. Only master is confirmed
good, with dev usually being okay but not guaranteed to be such. (To the extent
that any software is ever guaranteed to be anything.)
Change summary:
User-facing changes and improvements:
- Windows now has a new .NET-based native UI, which replaces the old WebControl
wrapper around the React UI. This just didn't work well on older Windows systems,
and we did not want to bundle 40+ megabytes of web browser with our app just for
its very simple UI.
- The web UI (still used for Mac and usable in Linux as well) is updated with
improved look and simplifications.
- Both UIs no longer have the "Peers" tab, since several users reported that non-
technical users found this confusing and even alarming (does this mean people
can access my system?). This information is visibile with "listpeers" from the
command line (zerotier-cli).
New features:
- Virtual networks that use our RFC4193-based IPv6 numbering scheme now emulate
IPv6 NDP for queries that target these addresses within the same network. This
allows for faster multicast-free connection init and improved security since
the address is now hard-wired to the device ID (which is a crypto token). This
does not affect IPv6 NDP for other IPv6 addresses or link-local, which will
continue to work normally. This also opens the potential for a reduced footprint
multicast-free build for embedded applications.
- This version includes beta support for a feature called CIRCUIT_TEST. Network
controllers for networks you have joined can now send a special message called
CIRCUIT_TEST which allows for ZeroTier-layer link testing and remote diagnosis
of link issues. Any operator of a network controller can do this; more
documentation will be forthcoming. The only information that may be gathered
in this way is IP addressing info and very basic system info (OS, 32/64 bit,
ZeroTier version). No personal information, hard drive data, location, or other
private info is available. This can only be ordered by a controller of a network
you have joined and is secured using cryptographic signatures.
- This version includes an alpha version of clustering a.k.a. multi-homing! This
powerful feature allows for a single ZeroTier device to be run from multiple
endpoints, with connecting peers being handed off to endpoints that are closer
via GeoIP lookup and/or are more lightly loaded. Currently this is only suitable
for use in our soon-to-be-upgraded root server infrastructure (details will be
blogged soon), but in the future it will be capable of hosting multi-homed
devices on user networks. This will allow things like (for example) a geo-
clustered Cassandra server that appears behind a single IP on a virtual LAN.
This feature must be enabled with the ZT_ENABLE_CLUSTER=1 build option.
Bug fixes and other improvements (including performance!):
- A faster version of the Poly1305 cryptographic MAC function was substituted
for sometimes greatly improved performance.
- C++ STL std::map was replaced throughout the entire core with a hand-rolled
Hashtable implementation for improved performance and in some cases a reduced
memory footprint. Some maps are still used in peripheral code that is not
performance critical or where ordered keys are needed.
- The zerotier-cli and zerotier-idtool symbolic links are now created in
/usr/local/bin on OSX to comply with El Capitan file security restrictions.
- The OSX tap device driver has been updated. This update may fix issues that
some users have reported with bridging on OSX. This new tap device driver
drops 32-bit support, but if you have a 32-bit system you can manually install
the old driver from ext/bin/tap-mac.
- Mac users could experience a problem with the UI if they installed ZeroTier,
then uninstalled it, then installed again. This is now fixed.
- UPnP port mappings should work better on some routers, and a different local
port is now used for UPnP mapped traffic vs. NAT-t'd traffic to get around
a bug in several popular mid-tier routers where using UPnP mapping alongside
traditional NAT traversal made a port unreachable.
- Debian package now builds with the right arch label on armv7l systems (Pi 2)
- The old "root topology" has been replaced with a similar but better thought
out concept called a World. The World defines the root servers and possibly
in the future other things, and can be updated in-band from trusted peers
allowing for software-upgrade-free network upgrades to keep up with growing
demand. See node/World.hpp for details.
- A fix was made to "self-awareness," which keeps track of your external IP
info and adapts to changes, to eliminate a problem that could cause "link
thrashing" behind some symmetric NATs.
- Escalating UDP TTLs was re-introduced to better transit some port-restricted
cone NATs such as Linux IP MASQ (used for Docker).
- An otherwise harmless crash-on-exit bug in the network controller was fixed.
- All new direct links are now confirmed in both directions. This adds a very
small amount of initial HELLO/OK traffic but fixes some edge cases where an
incomplete or unidirectional path might be used.
- [SECURITY] Better rate limiting was put in place for VERB_PUSH_DIRECT_PATHS
to prevent potential abuse for amplification attacks.
- [SECURITY] Build flags were tweaked on OSX to ensure that all code including
dependency libraries are built with full stack canary protection and ASLR
support.
Visit https://www.zerotier.com/blog or follow @ZeroTier on Twitter for updates
and announcements!
(1) Yes, you *can* create a mixed 32/64 bit Windows MSI installer that installs drivers. All you have to do is... umm... create individual sub-MSI files for each driver (one for 32, one for 64) and then package those in the main MSI files as "chained" MSI installers. Each of these must only be considered a prerequisite on 32 or 64 bit machines, respectively.
(2) Upgrade Advanced Installer version, add rules to uninstall NDIS6 tap device on uninstall.
(3) Fix IE issue in UI code.
This version is mostly a bug fix release. It fixes a bug that could cause
the service to crash on Windows while running the GUI application. It also
contains a number of fixes to the Linux installer and Linux support for
systemd-based init systems.
It also includes a minor tweak to the multicast algorithm. Version 1.0.0
sent multicasts in a deterministic order, while this version randomizes
the order. The vast majority of users will notice nothing, but this may result
in superior coverage for service announcements on very large networks. It's
a hard variation to test, so we're releasing like this to gather information
from users about the effect. Nothing will change on small networks, and
ordinary multicast functions like ARP and NDP should be unaffected.
The next version will likely focus on additional improvements to Microsoft
Windows support, since there are several known Windows issues in need of
attention. We're working on an NDIS6-based Tap driver that should address
the driver issues experienced by a small number of Windows 7 users.
The primary focus of this version is better integration with the
Microsoft Windows operating system.
Virtual networks should now be detected as "real" networks. For
each network, a message box should pop up the first time the network
is detected and classified allowing the user to choose its services
and security designation. On Windows 7 this is "work," "home," or
"public." On Windows 8 it's a simple choice of whether or not to
enable file and printer sharing and other services.
Several bugs have been fixed. Among these are a Windows threading
issue, several minor threading deadlock issues that could manifest
if rapidly adding and removing networks, and a command line interface
issue. The network list now shows the network MAC address as well,
a UI oversight in previous versions. A vectorized SSE implementation
of Salsa20 is now included for improved encrypt/decrypt performance.
The sending of low-TTL "firewall opener" packets has been disabled
in this version, since they may not be necessary and may harm NAT
traversal in some configurations. We will measure the effectiveness
of NAT traversal and see if this change improves performance in the
field.
Finally, this version obsoletes both the Tokyo and Sydney supernodes
in favor of a single larger supernode in Singapore. This decision was
made on the basis of bandwidth costs-- both Tokyo and Sydney are
significantly more expensive. We'd like to keep the basic service free,
so keeping bandwidth costs for relaying low is important. Since NAT
traversal works well and is constantly being improved, most users will
not see a speed decrease from this. Some Chinese users may see
improved performance since Singapore may be closer than Tokyo to many
Chinese cities.
The next major releases will focus on better Macintosh platform integration,
further improvements to NAT traversal, and UI improvements.
This version fixes several bugs including an issue with networks that have
EtherType filtering disabled, a file permission issue that affected non-English
versions of Windows, a multicast propagation bug that caused multicasts to
be dropped more often than they should be, and an issue with IP auto-configuration.
It also introduces experimental support for bridging between physical and virtual
networks, a much-requested and powerful ability that's been planned from the start.
ZeroTier One can now replace the functionality of ordinary VPNs, link multiple
offices into a single LAN, and connect virtual machine backplanes in the cloud to
physical networks at home, among other things.
Bridging support isn't "officially" out yet, since the web UI part is still
in development. But when that is done, an official announcement will be
made on the blog and users can try it out. So far bridging has only
been tested under Linux with the Linux kernel's native bridging driver.
YMMV on other platforms. Try it out and let us know by filing bugs at GitHub
or e-mailing them to "contact@zerotier.com".
This version fixes a few more issues with TCP tunneling including GitHub issue #63.
It also adds automatic announcement and location of peers on physical LANs (GitHub
issue #56) which should greatly improve performance if you happen to be on the same
LAN or WiFi network as another peer. It can take 60 seconds or so for this to occur,
but it should.
