Begin With HTTP

It should come as no surprise that a central element of the Plexnet is a web server. AKA, a Plexnet Node. Nodes MUST be fully conformant to the HTTP/1.1 specification [RFC-2616]. Support for the following functionality, in particular, are key:

• The basic HTTP verbs: GET, HEAD, PUT, POST, DELETE, OPTIONS.
• Asynchronous file-serving (including range requests).
• Gzip compression to save on the bandwidth bill.
• Larger than 512 byte response bodies for errors like 404s.
• SSL/TLS connections [RFC-4346] for authentication/privacy.
• Inclusion of [Plexnet] in the Server field of response headers.

Given the high scalability needs of the modern web [Kegel-2001], it is RECOMMENDED that an event-driven approach is taken when implementing Nodes. If other approaches are used, care should be taken to ensure that the Node can support at least 10,000 concurrent persistent HTTP 1.1 connections on a modern computer.

IPv6 Native

With the coming crunch of the IPv4 address space [Bush-2007], it is vital that the transition to IPv6 [RFC-2460] is fully supported. Therefore Plexnet Nodes MUST support access via an IPv6 address.

If a native IPv6 address cannot be used, tunnelling protocols like 6to4 [RFC-3056] or Teredo [RFC-4380] are available.

One of the side-benefits of using Teredo is that it allows for better access of Nodes than is often possible with NAT-ed IPv4 web servers. Thus, direct Node-to-Node communication would be possible without expensive relays.

Of course the flip side is that the surface for attack vectors is increased. But that is a risk for operators of any internet service. Plexnet Nodes are no special in this regard.

The following public Teredo servers are available for use:

• debian-miredo.progsoc.org (Australia)
• teredo.ipv6.microsoft.com (USA)
• teredo.remlab.net (France)
• teredo.plexnet.org (Germany)
• 203.233.154.10 (Korea)

Accessible Globally & Locally

All Plexnet Nodes SHOULD be accessible over the “Public Internet”. This might seem like a rather draconian requirement, but it should be understandable given that net neutrality [Cerf-2006] may soon just be a beautiful dream we all once had.

A sample configuration file for a Node may look like:

node.id = '6409808a-3548-11db-f2fd-0016cb90e4dc'
node.ipv4 = '64.233.187.99'
node.ipv6 = '2001:4860:0:1001::68'

node.teredo_server = 'teredo.plexnet.org'
node.stun_server = 'stun.plexnet.org'

In the event that a Node's public IPv4 and IPv6 addresses are not set, its IPv4 address will be auto-detected through the use of STUN [RFC-3489]. Likewise, with the use of Teredo for IPv6. If both of these fail to resolve, then the Node SHOULD fail to operate.

The following public STUN servers are available for use:

• stunserver.org
• stun.plexnet.org

In addition to binding to the given public addresses, a Node MUST also bind to localhost — 127.0.0.1 (IPv4) [RFC-3330] and ::1 (IPv6) [RFC-3513]. This is to ensure that Nodes are always accessible locally.

Nodes MUST run on the ports 8010 (HTTP) and 9010 (HTTPS). These ports have been registered with the IANA Port Registry and the harmonisation allows for ease of discoverability of Plexnet Nodes.

Thus the Node from the example configuration above, should be globally accessible via:

• http://64.233.187.99:8010/
• https://64.233.187.99:9010/
• http://[2001:4860:0:1001::68]:8010/
• https://[2001:4860:0:1001::68]:9010/

And locally accessible via:

• http://127.0.0.1:8010/
• https://127.0.0.1:9010/

Node Identity

“Nodes will behave in a P2P (Peer-to-Peer) manner”

Nodes have traditionally acted as just servers — responding to requests from browser clients. In contrast, Plexnet Nodes will behave in a P2P (Peer-to-Peer) manner.

It is expected that, instead of directly accessing web sites, users will access various resources through a Plexnet Node running locally. The Node will then access the resources from other Nodes using direct Node-to-Node communication.

To facilitate this, Nodes MUST generate a 128-bit node.id — using the MAC-based version 1 UUID protocol [RFC-4122]. Whilst this reveals the MAC-address, there is no requirement for the UUID to be generated on the same host machine as the Node.

These Node Identifiers serve a similar purpose to host names in the Domain Name System [RFC-1034]. DNS has served extremely well as the “phone book” of the internet. But, despite all of ICANN's great work, it is tainted by greed [Cheng-2008] and censorship [Ardia-2008] by the Registrars.

This should have been expected. “Projecting our notion of names onto DNS [subjects] the stability of links to the whims of political and social policy” [Frankston-2001]. The Plexnet solves this by handling the issue of naming with a separate Plexnames mechanism.

This separation also helps the longevity of URIs [Berners-Lee-1998] — which are currently dependent on yearly renewal of associated domain names. It is shocking that we entrust so much to a mechanism that is guaranteed to decay!

A side-benefit of all this is an expected decrease in crime. Cybersquatting and phishing cease to have any value in a world where Node Identifiers no longer represent people-friendly .com handles.

Node Registry

In addition, Nodes MUST generate a public/private keypair in the form of X.509 certificates [RFC-3280] for the purposes of acting as a Certificate Authority (CA). The Common Name (CN) field MUST be the 36-byte human readable format of the Node Identifier, e.g.

6409808a-3548-11db-f2fd-0016cb90e4dc

Standard precautions should be taken to ensure appropriate key length, duration and protection of the keys. The public key node.certificate MUST be DER encoded and node.fingerprint should be an ordered pair of the hash algorithm used, e.g. SHA-1 [FIPS-180-1], and the unencoded digest:

>>> node.fingerprint
('sha1', '\xa5\xcaX\xaf\xb9\x98Zcv\xa80\xf3\x97\x03ro\xab/\xc8\xdf')

When printed on paper for out-of-band exchange of certificates, the fingerprint SHOULD be presented in the format:

SHA1: A5CA 58AF B998 5A63 76A8 30F3 9703 726F AB2F C8DF

Ideally all exchange and verification of unknown certificates would happen in person. But given how lazy we all are, it is RECOMMENDED that Node operators at least use the phone to verify the fingerprint of new Trusted Nodes. Man-in-the-middle attacks are very real.

Gestures

Gestures have been a key innovation in digital interaction. From the “drag” feature implemented on the early Apple Macintoshes to the implementations in the likes of Lionhead's Black & White game and the Opera browser to the recent day iPhone and Wii. [Saffer-2007]

Alternatives to TCP

Anyone who has suffered congestion caused by heavy TCP traffic on a wireless network will be aware of TCP's shortcomings. In some applications, e.g. VoIP, it doesn't matter if packets are dropped but that they are delivered in “real-time”.

Airhook [Egnor-2001] is an alternative to TCP [RFC-793] — implemented on top of UDP [RFC-768] — which may offer a solution to these problems. And since HTTP is protocol independent, Nodes can start supporting Airhook for Node-to-Node communications without need for support from operating system or browser vendors.

One interesting problem to solve would be to figure out how applications could take advantage of Airhook's flexibility from the HTTP level. Of course, even if Airhook does turn out to be a viable alternative, TCP won't disappear overnight. Both protocols would have to be concurrently supported for a while.