New versions will be coming fast and furious for a bit as bugs get fixed and
testing is done in prep to the first binary release.
This version fixes a problem with WAN path discovery and a possible security
issue in PacketDecoder. (see previous comments)
(1) The changes to path learning in the two previous releases were poorly thought out,
and this version should remedy that by introducing PROBE. This is basically a kind of
ECHO request and is used to authenticate endpoints that are not learned via a valid
request/response pair. Thus we will still passively learn endpoints, but securely.
(2) Turns out there was a security oversight in _doHELLO() that could have permitted...
well... I'm not sure it was exploitable to do anything particularly interesting since
a bad identity would be discarded anyway, but fix it just the same.
This version contains few changes that are visible to users building from source.
It contains an almost-complete version of the Qt-based GUI in ZeroTierUI, though
this is still a work in progress. It also contains the software update infrastructure,
which is not yet enabled by default but does basically work. Some cleanup and
dead code removal has also occurred.
The next release will probably be the first binary release with auto-update and a
full UI experience for Linux and Mac. Windows will follow later, as more work has
to be done on the Windows port.
This version fixes a recurrent gremlin in the tap driver for Mac. If you are
having this issue, you should reinstall the tap.
If you're already running ZT1, shut it down (sudo killall zerotier-one) and
then do:
sudo kextunload /Library/Application\ Support/ZeroTier/One/tap.kext
This should unload the old version. Then type 'sudo make install-mac-tap' in
the ZT1 source home directory and the new version will be installed. ZT1 will
load the module again when it next starts.
In addition to a fix, I am now distributing tap binaries and it is no longer
built in the default Makefile. This is because Apple's in the midst of some
changes that have made building it somewhat difficult.
Another note for Mavericks users:
The first time you use ZT1, you will get a popup about unsigned kernel
extensions. This will vanish once we're out of beta and have signing keys
and signed drivers.
Other changes in this version:
* Minor improvement to Utils::getSecureRandom
* Bug fixes and a small change to certificates of membership for private
networks, which now appear to be working very well!
* Stubbed out messages for auto-update, which will be done in-band via
the ZT1 protocol. Not implemented yet.
This version removes the peer DBM present in earlier releases. It is not necessary for
regular clients and has been a source of problems.
There is a long-term identity cache that can be enabled by making a directory called
"iddb.d" in the home folder and restarting ZT1. This is probably something only our
supernodes would need, since regular nodes can easily WHOIS peers they've forgotten
about.
On shutdown, the peer database is dumped to disk. It's then restored on startup.
Peers that have not been used in a while are cleaned out, so this keeps this data
set small.
A DBM may re-appear later if it's needed, but for now it was YAGNI.
Version 0.6.0 marks the transition of ZeroTier One from ALPHA to BETA.
Major updates to the web site and binary packages for MacOS and Linux
are coming soon, followed by Windows soon thereafter.
This version contains a number of changes including:
* Speed improvements to encryption
* A new much-improved identity algorithm, which unfortunately requires an
identity regeneration. This should happen automatically, and should be
the last time for a good long while assuming there's nothing wrong with
what's here.
* Cleaned up the Network::Config mess in the code, factored out Config
into its own NetworkConfig class.
* Lots of work to support private networks, which are still in testing.
Concurrent with the web site update will be another minor release to
include any fixes there.
* Some changes to the protocol for better future-proofing.
* Netconf support for ARP caching parameters configurable on per-network
basis.
You must update to stay connected to the network; this version will not
talk to 0.5.0. After this, I'm going to be much more reluctant to make
incompatible changes.
Whew. This is a big one. More of a marathon than a sprint.
First, four big things:
1) This version breaks backward compatibility with all prior versions.
It's in alpha, I can do that.
2) The port has changed from 8993 to 9993 to mark this change. Probably
not necessary but why not? Also 8993/UDP turned out to be used by some
enterprise LDAP thingy, which doesn't matter much either but again why
not?
3) This version, unlike previous versions, does NOT auto-join the Earth
network. Soon there will be more than one net, and not everyone is going
to want to get dumped on a flat global LAN right out of the box. To
join Earth use the command line interface:
sudo zerotier-cli join bc8f9a8ee3000001
4) Finally, you will get a different IP on Earth. The whole cryptosystem
has changed and we're not going to bother with continuity issues in
alpha testing.
So what's changed? See the blog:
http://blog.zerotier.com/post/62991430345/alpha-zerotier-one-network-is-down-briefly
The net should be up shortly after this commit. If there are any issues,
0.5.0 will be rapidly followed by 0.5.1. :-) Otherwise the next sprint
will be finishing up support for private networks. Then it's off to the
races with BETA, then Windows. (Decided to move into beta before Windows
in all likelihood.)
Changes:
* It now builds and runs on Windows with Visual Studio 2012. Windows is
not ready for prime time yet though for several reasons, so no Windows
release yet. If you're brave you can try to DIY, but the driver is
not signed yet either. Windows is a work in progress still.
* Networks now pull their ethernet type whitelist from the netconf master
instead of having it hard-coded. (Prep for network mgmt.)
* Netconf master now sends name and description of networks so this can
be used to set Windows network display names.
* A couple minor bug fixes here and there, nothing major.
* No protocol changes that break compatibility.
In addition to a lot of Windows port work that isn't finished yet (and doesn't
affect the *nix platforms at all), this version contains quite a bit of multicast
cleanup and code simplification.
I also pulled rate limits for now, as it seems to be causing problems. More testing
on the testnet is going to be needed.
This version fixes problems with locating the 'ip' command on Gentoo
and possibly other Linux systems, and a problem that could cause a
crash if EthernetTap was unable to locate one of the commands it
invokes to configure IP information on tap devices.
The code also now builds on Windows. It doesn't run yet, but it's a
step. Windows port is in full swing.
Finally, the multicast rate limit defaults were raised a little. More
testing is needed here, and real world measurments.
This version fixes problems with locating the 'ip' command on Gentoo
and possibly other Linux systems, and a problem that could cause a
crash if EthernetTap was unable to locate one of the commands it
invokes to configure IP information on tap devices.
The code also now builds on Windows. It doesn't run yet, but it's a
step. Windows port is in full swing.
Version 0.4.2 is largely a cleanup release. Changes are minor:
* Programatically replace libcrypto's random number generator with our
own (using /dev/urandom or Windows CAPI) since libcrypto's RNG likes
to use uninitialized memory as one of its entropy sources. This causes
massive floods of valgrind (debugger) errors during memory error
profiling analysis.
* Clean up some other code to eliminate valgrind errors.
Valgrind now runs on Linux with only one error. This error is in
EthernetTap and is a false positive.
This version adds a draft of the multicast rate limiting architecture. A
few minor bugs are also fixed. The Linux version builds in debug mode for
now.
In keeping with the wild west alpha phase of this software, this version is
a major departure from 0.3.0 and an upgrade is required.
The protocol hasn't changed much, but the system of network membership, network
IDs, and network configuration bootstrapping has changed dramatically.
The mechanism for network autoconfiguration is now in-band, via the ZeroTier
protocol itself, rather than using an HTTP API. This simplifies the code and
allows us to use a consistent system of encryption and authentication.
To accomodate this change, network IDs now contain in their most significant
40 bits the ZeroTier address of a node responsible for overseeing the addressing
of participating network members. The remaining bits are free, so each network
controller (netconf node) can control up to 2^24 networks. The code for the
netconf service is in /netconf-service, but for ordinary users there's not much
need to look at it or use it. It's just there to be open source.
The system for network membership tracking is also revamped. For open networks
like Earth this doesn't matter, but for closed networks membership is now driven
by something called a membership certificate that is signed by the controlling
node in the network. There's still work to be done here, so private network
support isn't fully baked yet. But public open networks work fine.
Nodes still join "Earth" by default. The ID for Earth has changed from 1 to
6c92786fee000001 (hex). This means that old 0.3.0 clients and older will not
be able to communicate with 0.4.0 as their network IDs will not match.
The new certificate-based network membership system scales better than the old
HTTP API system and will support some pretty amazing features. Stay tuned!
For now just update and relaunch. You should get the same IPv4 address you
had before.
The second big change is zerotier-cli. Try running it as root (or after
copying the auth file to the path it tells you about when you first run it)
with 'help' as a command.
This version is not compatible with versions prior to 0.3.0, so
'git pull' and restart if you are following the alpha.
Changes from 0.2.5:
- All multicast frames are now signed by the original sender. This
will permit very efficient and fault tolerant rate limitation
across networks, and imposes a kind of "hash cash" cost on those
who wish to flood the network by forcing them to keep regenerating
new identities.
- Simplified peer last unicast / last multicast accounting.
- Improvements to multicast propagation algorithm to achieve better
coverage with less redundant messages.
- The bloated Switch class went on a diet, having packet decoding
broken out into PacketDecoder and multicast propagation algorithm
broken out into Multicaster.
- Multicaster is implemented as a template mockable class to permit
future simulations of huge scale multicast using the actual code
instead of mockups in another language.
- Introduced a faster non-cryptographic random source for things
like multicast propagation and address choosing.
- Some code cleanup, removal of outdated comments, etc.
(1) Probable fix for issue #7 and major cleanup of EthernetTap code with consolidation for all unix-like systems and specialization for different flavors only when needed.
(2) Refactor of Buffer<> to make its members private, and Packet to use Buffer's methods exclusively to access them. This improves clarity and means we're no longer lying about Buffer's role in the code's security posture.
(3) Add -fstack-protect to Makefile to bounds check stack variables.
ZeroTier One creates flat virtual Ethernet networks of almost unlimited size. [Visit ZeroTier on the web](https://www.zerotier.com/) for more information.
ZeroTier One creates flat virtual Ethernet networks of almost unlimited size. [Visit ZeroTier Networks on the web](https://www.zerotier.com/) for more information.
This code is presently in **ALPHA** testing. That means that the protocol spec may change in incompatible ways, and it certainly has bugs. Testers should "git pull," rebuild, and restart fairly often. If things mysteriously stop working, do that.
This project is now in beta, which means that major incompatible protocol shifts should now become considerably more rare. You should still update very often if you plan to use it. Binary packages with auto-update are coming very soon.
See BUILDING.txt and RUNNING.txt for instructions. It currently builds on Mac and Linux. A Windows port is coming soon. Nice packages/installers and auto-update are also coming when alpha transitions to beta.
Follow the [ZeroTier blog](http://blog.zerotier.com/) and the [GitHub project](https://github.com/zerotier/ZeroTierOne) to stay up to date.
Note that this won't work if your firewall does not allow outbound UDP. It must allow UDP conversations on port 8993 at a minimum.
See BUILDING.txt and RUNNING.txt for instructions. It currently runs on Mac and Linux. A Windows port is well along the way to completion. If you're brave you can load the Visual Studio 2012 solution and play around.
At present there is only one virtual LAN and you are dumped there by default. It's called Earth, and is exactly what it sounds like. The ability to create and join additional networks is coming soon. Once you're on, visit [earth.zerotier.net](http://earth.zerotier.net/) to see your Earth LAN IP address and other information.
Once you have it running you can join the Earth network -- a LAN for the planet -- by using the 'zerotier-cli' tool: 'sudo zerotier-cli join 8056c2e21c000001'. Right now Earth is the only network. Ability to create private networks, as well as some additional special-purpose public ones, will be coming soon. (Note: previous alpha versions auto-joined Earth, but since 0.5.0 it no longer does this.)
**Security warning:** You read that right. ZeroTier One places your computer on an absolutely open global Ethernet party line. Please ensure that you are up to date on your OS patches and we recommend turning off unnecessary services. Also be sure that anything else you are sharing is password protected provided you don't want to share it: printers, iPhoto and iTunes shares, etc.
Note that this won't work if your firewall does not allow outbound UDP. It must allow two way UDP conversations on port 9993 at a minimum.
ZeroTier One is licensed under the GNU General Public License version 3. You are free to use, modify, or redistribute it under the terms of that license. If you would like to embed ZeroTier One in a closed source product or create a closed source derivative product, contact ZeroTier Networks LLC.
Check out the [blog](http://blog.zerotier.com/) for announcements, in-depth articles, and related thoughts. There is also a [Google group](https://groups.google.com/forum/#!forum/zerotier-one-users) for questions and discussion.
----
**FAQ**
**Q:** What can I do with this?
**A:** For starters, try opening iTunes if you have it installed. If others are also online and sharing their collections, you might see them. If you have any games that run over a LAN (except those that require IPX), try those. What else can you think of to do on a completely flat, open network? Games? Collaborative software development? Remote debugging? Transferring files using simple drive shares? Sharing your desktop printer to someone on another continent? Use your imagination.
**Q:** Why do I get an IP address in the 27.0.0.0 or 28.0.0.0 range? And why does a lookup claim these addresses belong to the U.S. Department of Defense?
**A:** Short answer: because IPv4 needs to die. Long answer: the Earth network assigns IPv4 IPs from these ranges. They do in fact belong to the DOD, but they are *not* routed to the open Internet. The DOD owns them but uses them internally for private networks. As a result, there is nothing *technically* wrong with "bogarting" these for our own private network. It's considered bad practice, but if you want a private address space in IPv4 that is unlikely to overlap other private address spaces (like 10/8 and 192.168/16), it's the only way. [Cellular carriers](http://www.androidcentral.com/sprint-internet-dept-defense-and-you) and [cable companies](http://www.dslreports.com/forum/r25679029-Why-is-my-first-hop-to-a-DoD-assigned-IP-address-) frequently do the same thing.
**Q:** Is IPv6 supported?
**A:** Yes. IPv6 link-local addresses (those in the fe80::/10 block) are auto-assigned and should work fine. No other IPv6 addresses are assigned *yet*, but there are plans to do interesting things in this area in the future.
**Q:** I don't want a giant Ethernet party line. Can I leave it and create private LANs instead?
**A:** Yes, soon. A GUI to configure such things is in development. But for now there's only Earth.
**Q:** Are you going to charge for this?
**A:** Public virtual LANs will remain free. We intend to charge for private networks in some way, but the exact model is TBD. Other cloud-supported paid features are also TBD.
**Q:** What's a supernode?
**A:** Supernodes are nodes run by ZeroTier Networks that orindary users use to find one another and communicate until/unless they can perform NAT traversal and connect directly. They run the exact same software as everyone else. The only thing that really makes a supernode special is that it's designated as such.
**Q:** Can I run a supernode?
**A:** No, not at the moment, and there would be no benefit to doing so.
**Q:** Will my local firewall rules apply to ZeroTier One traffic?
**A:** ZeroTier creates a virtual Ethernet tap device (zt# on Mac and Linux) that emulates a wired Ethernet port. If your firewall applies to *all* network ports, it will filter traffic through this port as well. If it applies only to the primary interface, it may not. See your OS's firewall documentation, as different OSes and flavors thereof have slightly different configurations in this regard.
**Q:** Can you see my traffic? What about other users? Can you sniff the LAN?
**A:** No. All unicast (direct computer to computer) traffic is encrypted end-to-end (even if it's being relayed), and the ZeroTier virtual LAN behaves like a LAN with a secure enterprise-grade switch that does not allow unicast conversations to be sniffed. Multicast and broadcast traffic will of course be seen by many recipients, but that's the idea.
**Q:** You say "almost unlimited size." Isn't multicast and broadcast traffic eventually going to be too much? What happens then?
**A:** ZeroTier One uses an algorithm called *implicit social switching*. The overall maximum number of recipients for a multicast is limited, so if there are too many listeners to a given multicast address then obviously not everyone will receive every message. So who does? Social switching causes multicasts to propagate in the direction of peers to whom you have recently communicated. As a result, multicasts tend to propagate along lines of association. The people most likely to get your service announcements are those with whom you frequently connect.
**Q:** Is this designed to replace IP, BGP, IPv6, routers, etc.?
**A:** No. Its purpose is to act as a collaboration tool, a VPN alternative, a network mobility tool, a testbed for the development of software that takes advantage of fully open networking, a virtual LAN party for gamers, and so on, but it's not intended (or able) to replace the core of the Internet.
**Q:** Can I bridge this to a physical port and plug in an Xbox, PlayStation, etc.?
**A:** Not currently, as foreign Ethernet frames are not forwarded. This may be possible in a future version.
----
**Status**
*What works:*
* Network auto-configuration via JSON API with identity based authentication and encryption
* End-to-end encryption with automatic key exchange
* Ethernet multicast with implicit social propagation (though the algorithm will certainly be getting tweaked as we go)
* IPv4 ARP works (see MulticastGroup.hpp for details)
* IPv6 neighbor discovery protocol works, thus IPv6 link-local addressing on the ZeroTier device also works
* mDNS (though if the LAN gets big you will not see everyone, just people nearby on your implicit social graph)
* IP-level multicast ought to "just work," though it may take up to a minute or so for a new join to propagate
* NAT traversal works pretty well, at least behind relatively sane unrestrictive firewalls/routers. You can see this by pinging another node and watching, after a few seconds, the latency drop dramatically since you're no longer relaying. If it doesn't your firewall might block such things. Additional NAT traversal strategies are coming.
* Changes in your local network configuration are generally detected and will cause peers to be re-acquired.
*Known immediate issues:*
* Multiple network support is in but there is no interface to configure it, hence it is useless. But in alpha it'll be nice to shove everyone onto "Earth" in order to stress test that little "almost unlimited size" boast.
* There is no multiple-launch protection yet and multiple instances on the same system do not work well due to route conflicts. Take care that zerotier-one is not running before launching it again. The command "sudo killall zerotier-one" is helpful.
* Sometimes ZeroTier One doesn't like to terminate when asked nicely. This is related to issues with the tap device closing down properly. If it hangs around after a TERM signal, send it a KILL (9) signal.
* The locally bound UDP port isn't configurable yet. It's 8993 by default.
* Known security issues:
* There is no rate limit for multicast. Please be nice during alpha testing and don't flood.
* There is no filtering. Whether or not to try to do port-level filtering is not yet decided, as technically the local OS firewall and OS service configuration should do this and ZeroTier is not about re-inventing wheels. But certain things *will*need to be filtered by ZT1 itself. These include certain ICMP and ICMPv6 messages: router advertisement, router solicitation, source redirect, etc. DHCP and BOOTP should probably also be filtered at a minimum.
* ARP and IPv6 NDP want extra security measures to prevent poisoning and spoofing. The best mechanism is being researched.
* If a supernode goes down, this takes quite a while to be detected and things will go dead. Fast recovery from relay failure is in the works.
* If by a one in 2^40 chance two people generate the same ZeroTier address, this is currently not handled. It's unlikely and also hard (as in cryptographically hard) to do intentionally. See comments in Identity.cpp for details.
*What doesn't work and might not work for a while, if ever:*
* Only ARP, IPv4, and IPv6 frames are allowed. The ability to permit other ethertypes on user-created networks may be added later to allow things like old games that use IPX or private networks to remote administer weird hardware.
* Bridging of the ZeroTier device to other networks will not work, and may never. This is TBD.
* VLAN tagged frames will not work and probably never will, as higher level network provisioning handles that concept.
Loaded 20 of 372 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Adam Ierymenko
Adam Ierymenko
Gurjeet Singh
Paul Furley
Andy Pilate