CINXE.COM

<!DOCTYPE html> <html class="client-nojs" lang="en" dir="ltr"> <head> <meta charset="UTF-8"/> <title>Network principles - OLPC</title> <script>document.documentElement.className="client-js";RLCONF={"wgBreakFrames":false,"wgSeparatorTransformTable":["",""],"wgDigitTransformTable":["",""],"wgDefaultDateFormat":"dmy","wgMonthNames":["","January","February","March","April","May","June","July","August","September","October","November","December"],"wgRequestId":"69e5a52dedf1e9932c10393c","wgCSPNonce":false,"wgCanonicalNamespace":"","wgCanonicalSpecialPageName":false,"wgNamespaceNumber":0,"wgPageName":"Network_principles","wgTitle":"Network principles","wgCurRevisionId":290755,"wgRevisionId":290755,"wgArticleId":21458,"wgIsArticle":true,"wgIsRedirect":false,"wgAction":"view","wgUserName":null,"wgUserGroups":["*"],"wgCategories":["Pages monitored by OLPC","Obsolete","Network","Software ideas"],"wgPageContentLanguage":"en","wgPageContentModel":"wikitext","wgRelevantPageName":"Network_principles","wgRelevantArticleId":21458,"wgIsProbablyEditable":false,"wgRelevantPageIsProbablyEditable":false,"wgRestrictionEdit":[],"wgRestrictionMove": [],"wgVector2022PreviewPages":[]};RLSTATE={"site.styles":"ready","user.styles":"ready","user":"ready","user.options":"loading","skins.vector.styles.legacy":"ready"};RLPAGEMODULES=["site","mediawiki.page.ready","mediawiki.toc","skins.vector.legacy.js"];</script> <script>(RLQ=window.RLQ||[]).push(function(){mw.loader.implement("user.options@12s5i",function($,jQuery,require,module){mw.user.tokens.set({"patrolToken":"+\\","watchToken":"+\\","csrfToken":"+\\"});});});</script> <link rel="stylesheet" href="/mediawiki/load.php?lang=en&modules=skins.vector.styles.legacy&only=styles&skin=vector"/> <script async="" src="/mediawiki/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector"></script> <meta name="ResourceLoaderDynamicStyles" content=""/> <link rel="stylesheet" href="/mediawiki/load.php?lang=en&modules=site.styles&only=styles&skin=vector"/> <meta name="generator" content="MediaWiki 1.39.7"/> <meta name="format-detection" content="telephone=no"/> <meta name="viewport" content="width=1000"/> <link rel="icon" href="/favicon.ico"/> <link rel="search" type="application/opensearchdescription+xml" href="/mediawiki/opensearch_desc.php" title="OLPC (en)"/> <link rel="EditURI" type="application/rsd+xml" href="http://wiki.laptop.org/mediawiki/api.php?action=rsd"/> <link rel="alternate" type="application/atom+xml" title="OLPC Atom feed" href="/mediawiki/index.php?title=Special:RecentChanges&feed=atom"/> </head> <body class="mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-Network_principles rootpage-Network_principles skin-vector action-view skin-vector-legacy vector-feature-language-in-header-enabled vector-feature-language-in-main-page-header-disabled vector-feature-language-alert-in-sidebar-disabled vector-feature-sticky-header-disabled vector-feature-sticky-header-edit-disabled vector-feature-table-of-contents-disabled vector-feature-visual-enhancement-next-disabled"><div id="mw-page-base" class="noprint"></div> <div id="mw-head-base" class="noprint"></div> <div id="content" class="mw-body" role="main"> <a id="top"></a> <div id="siteNotice"></div> <div class="mw-indicators"> </div> <h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Network principles</span></h1> <div id="bodyContent" class="vector-body"> <div id="siteSub" class="noprint">From OLPC</div> <div id="contentSub"></div> <div id="contentSub2"></div> <div id="jump-to-nav"></div> <a class="mw-jump-link" href="#mw-head">Jump to navigation</a> <a class="mw-jump-link" href="#searchInput">Jump to search</a> <div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="en" dir="ltr"><div class="mw-parser-output"><div style="background:#6abe45; color:white;">  This page is monitored by the OLPC team.</div> <table width="100%" cellpadding="0" cellspacing="0"> <tbody><tr> <td><div style="border-top:1px solid #bbb; border-bottom:1px solid #bbb; background-color:#eee; padding:6px; padding=4xcolor:#666"> <center><font color="black">The contents of this page are considered <b>outdated</b> and some of the information may be stale. Please use information here with caution, or update it.</font></center> </div> </td></tr></tbody></table> <div style="border-top:1px solid #bbb; border-bottom:1px solid #bbb; padding:4px; background-color:#eee; color:#666"> <table cellspacing="0" cellpadding="0" style="clear: right; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: auto;" class="toclimit-12"> <tbody><tr> <td><div id="toc" class="toc" role="navigation" aria-labelledby="mw-toc-heading"><input type="checkbox" role="button" id="toctogglecheckbox" class="toctogglecheckbox" style="display:none" /><div class="toctitle" lang="en" dir="ltr"><h2 id="mw-toc-heading">Contents</h2><span class="toctogglespan"><label class="toctogglelabel" for="toctogglecheckbox"></label></span></div> <ul> <li class="toclevel-1 tocsection-1"><a href="#Network_Principles"><span class="tocnumber">1</span> <span class="toctext">Network Principles</span></a> <ul> <li class="toclevel-2 tocsection-2"><a href="#No_Assumption_of_Universal_Connectivity"><span class="tocnumber">1.1</span> <span class="toctext">No Assumption of Universal Connectivity</span></a></li> <li class="toclevel-2 tocsection-3"><a href="#Direct_XO-to-XO_serverless_communication"><span class="tocnumber">1.2</span> <span class="toctext">Direct XO-to-XO serverless communication</span></a></li> <li class="toclevel-2 tocsection-4"><a href="#Human-readable_unique_identifiers_for_each_XO"><span class="tocnumber">1.3</span> <span class="toctext">Human-readable unique identifiers for each XO</span></a></li> <li class="toclevel-2 tocsection-5"><a href="#Direct_presence_interrogation"><span class="tocnumber">1.4</span> <span class="toctext">Direct presence interrogation</span></a></li> </ul> </li> <li class="toclevel-1 tocsection-6"><a href="#An_architecture_proposal"><span class="tocnumber">2</span> <span class="toctext">An architecture proposal</span></a> <ul> <li class="toclevel-2 tocsection-7"><a href="#DNS_names"><span class="tocnumber">2.1</span> <span class="toctext">DNS names</span></a></li> <li class="toclevel-2 tocsection-8"><a href="#Name_resolution"><span class="tocnumber">2.2</span> <span class="toctext">Name resolution</span></a></li> <li class="toclevel-2 tocsection-9"><a href="#Friend_links_in_HTML"><span class="tocnumber">2.3</span> <span class="toctext">Friend links in HTML</span></a></li> <li class="toclevel-2 tocsection-10"><a href="#Presence_service"><span class="tocnumber">2.4</span> <span class="toctext">Presence service</span></a></li> </ul> </li> <li class="toclevel-1 tocsection-11"><a href="#Extensions_and_improvements"><span class="tocnumber">3</span> <span class="toctext">Extensions and improvements</span></a> <ul> <li class="toclevel-2 tocsection-12"><a href="#Tunnels"><span class="tocnumber">3.1</span> <span class="toctext">Tunnels</span></a></li> <li class="toclevel-2 tocsection-13"><a href="#External_DNS"><span class="tocnumber">3.2</span> <span class="toctext">External DNS</span></a></li> <li class="toclevel-2 tocsection-14"><a href="#XO-to-XO_Security"><span class="tocnumber">3.3</span> <span class="toctext">XO-to-XO Security</span></a></li> <li class="toclevel-2 tocsection-15"><a href="#Disconnected_operation"><span class="tocnumber">3.4</span> <span class="toctext">Disconnected operation</span></a></li> </ul> </li> <li class="toclevel-1 tocsection-16"><a href="#Credits"><span class="tocnumber">4</span> <span class="toctext">Credits</span></a></li> </ul> </div> </td></tr></tbody></table> <p>OLPC's deployment strategy places laptops in many different network environments, with varying services available and levels of connectivity. In the first part of this document, we propose four basic principles for the software comprising our network stack. These principles divide our connectivity goals into functionality OLPC endeavors to provide and tasks that are the responsibility (or option) of the deployment. Further, they guide our software architecture, distinguishing the new services OLPC will design and implement from the traditional network services we will utilize and aggressively leverage. So far as possible, even the new services OLPC provides will attempt to reuse existing network protocols or userland APIs, and to remain compatible with other hosts on the inter-networks we create. </p><p>In the second part of this document, we dive more deeply into concrete proposals for network software architecture adhering to these principles. We propose a naming scheme for XOs and describe how it can be implemented using dynamic DNS. We then discuss protocols for friend and resource discovery, and describe how these can be effectively decoupled from the core XO software to allow community development of alternate directories and browsers. </p> <h2><span class="mw-headline" id="Network_Principles">Network Principles</span></h2> <p>We propose four basic principles underlying our network infrastructure and software architecture: disconnected local networks, direct peer communication, human-readable globally unique identifiers, and direct presence and status queries. </p> <h3><span class="mw-headline" id="No_Assumption_of_Universal_Connectivity">No Assumption of Universal Connectivity</span></h3> <p>We cannot assume universal connectivity between arbitrary XOs, or even connectivity between XOs and points on the global internet. Every deployment is a walled garden of some size; some deployments may endeavor to include the entire global internet inside that garden (network weather permitting); other deployments may include only a single school inside its walls; and in the limit case the "garden" may consist of only one or two XOs underneath a tree. </p><p>We will always endeavor to provide the best service possible within whatever walls we find ourselves. If we can only communicate with other XOs within a school, we will provide full collaboration within that school even though students cannot collaborate with other schools. If direct connectivity is possible between schools within a certain deployment, we fully support collaboration between schools, even if connectivity to the global internet is not available. </p><p>This principle also allows us to gracefully handle many kinds of network degradation, present in any real-world deployment. Even in the face of transient asymmetries or disconnections within the network we will provide the "best possible" behavior with the fullest achievable range of services. Central failures may interfere with collaboration among far-flung sites, but they should never interfere with the ability to use the XO locally. </p> <h3><span class="mw-headline" id="Direct_XO-to-XO_serverless_communication">Direct XO-to-XO serverless communication</span></h3> <p>Our basic networking features are built around direct XO-to-XO <b>serverless</b> (peer-to-peer) communication. Additional servers may be used as aides or proxies, but the canonical means to query the state of an XO or to collaborate with its user is to directly connect to it; no server need be involved. </p><p>By <b>direct</b> communication we mean the standard socket API and IP protocols on which the internet is built. We are not building an overlay network or providing bespoke routing or addressing services; we are using the "plain old network". Auxiliary servers, tunnels, or services may be utilized, but only on an "as available" basis or transparently (as in the case of routers or tunnels) consistent with the <a rel="nofollow" class="external text" href="http://en.wikipedia.org/wiki/End-to-end_principle">end-to-end principle</a>. </p><p>There are three main ways in which direct XO-to-XO communication fails: </p> <dl><dt>NATs or firewalls are used for control.</dt> <dd>In some deployments, XOs inside a school are placed behind a firewall or NAT to enforce web filtering or other control mechanisms. This can be unfortunate, but OLPC will not attempt to subvert this. We acknowledge that these mechanisms may create walled gardens, but that decision is the responsibility of the deployment. If the school wants to provide collaboration with other schools or individuals outside its walled garden, it is the deployment's responsibility to poke holes in its walls, not OLPC's.</dd> <dt>NATs used due to limited IPv4 address space.</dt> <dd>In some deployments, NATs or firewalls are used to work around limits in the number of available globally-routable IPv4 addresses. IPv6 is an excellent solution to this problem, but IPv6 deployment is quite poor at present. OLPC cannot single-handedly deploy IPv6 to every school endpoint; it is the responsibility of the schools or deployments to provide IPv6 connectivity, via 6-to-4 or tunneling. Again, walled gardens may result from the limited IPv4 address space; if collaboration past the NAT is desired, deployments must provide the IPv4 or IPv6 connectivity required to enable this. (OLPC will probably endeavor to assemble a best-of-breed IPv6 tunnel solution as an aid to deployment teams, but locating, installing, and maintaining the IPv6 endpoint is the responsibility of the deployment.)</dd> <dt>NATs or firewalls used for other reasons.</dt> <dd>In some instances NATs or firewalls may be imposed externally due to circumstances beyond direct control, and are not actually desired by the deployment. Again, the IPv4 or IPv6 tunneling needed to bypass this is the responsibility of the deployment. We will make an effort to use http/port 80 for services to provide "best possible operation" when reasonable.</dd></dl> <p>By relying on IPv4/IPv6 routability, deployments can improve the their ability to collaborate independent of changes to the software on the XO. </p> <h3><span class="mw-headline" id="Human-readable_unique_identifiers_for_each_XO">Human-readable unique identifiers for each XO</span></h3> <p>Direct communication implies that there is a usable address for each XO. We insist that this address be (a) human-readable, (b) invariant and indirect, and (c) globally unique. </p><p><b>Human-readable</b> names promote compatibility with other network hosts: the addressing information used to connect to an XO via ssh or a chat client from a non-XO host should be concise and logical ("<a rel="nofollow" class="external text" href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">memorable</a>" using Marc Stiegler's terminology). As a counter-example, we will state that using a 256-bit hash of a public key as the primary identification mechanism is not acceptable; even using a scheme convert binary information into quasi-readable word sequences does not yield an acceptably concise or logical address. An address for student 'Scott' at a school in Cambridge, MA, USA, should look something like <tt>scott.1cc-cambridge-ma.us.xs.laptop.org</tt>; we will describe a concrete proposal below. A key detail here is that this name identifies the XO, not the school server or some other helper. This allows direct communication consistent with the previous principle. </p><p>Although the name is a direct reference to the machine, the mapping from name to routable address is <b>indirect</b>. There may be several means to map the name to an address or service on the machine, and some of these means might take advantage of proxies or servers. The key property is that there is a <i>single</i> name by which anyone anywhere on the network uses to refer to a particular XO -- the names do not depend on the means by which the name is mapped to an address, route or service. Because of the walled garden reality, not everyone will be able to successfully map a name to a usable address, route, or service at all times --- but when network conditions change (the student goes home, school connectivity is restored, etc) the <b>invariant</b> name will be usable. Use of a shortname like 'scott' for link-local communications violates this principle. </p><p><b>Globally-unique</b> names ensure freedom of conflicts when walled gardens merge or students go home to a different network environment. This implies some central coordination, but not much: if deployments are assigned unique prefixes by OLPC, and schools are assigned unique names by the deployment, then we need only ensure that (for example) students are assigned unique names within the school. This can either be performed probabilistically in the absence of a school server (see proposal below) or by registration with a school server. Collision-detection (like in Apple's zeroconf/Bonjour) is a big help in practice, allowing the uniqueness constraint to be enforced "on-demand" when necessary. </p><p>The strong constraints on identifiers proposed in this section have privacy implications, which we propose to address using a capable <b>pseudonym</b> system. We only insist that there is <i>at least</i> one name for each XO. To preserve privacy we insist that there may be <i>many</i> such names. The name <tt>scott.1cc-cambridge-ma.us.xs.laptop.org</tt> may be the official name used for schoolwork, but the child should be able to also setup <tt>freedom76.olpc.cypherpunks.org</tt> (for example) as a pseudonym for extracurricular work. In this example, the cypherpunks infrastructure could provide additional privacy using protected proxies, onion routing, and other features to whatever degree desired. Ideally, selection among numerous pseudonyms would be made easily on the home screen of the Sugar interface. </p><p>As a practical matter, note that the requirements outlined here match <b>standard DNS</b> very well. There are A and AAAA records to map the invariant names indirectly to addresses, as well as extensible record types (DNS-SD) to map the names to other services. Domain names are designed to be human-readable, and there are existing standards to extend DNS to non-ASCII character sets. The delegation mechanisms for subdomains are appropriate delegation mechanisms to give countries control of their namespaces. There may be multiple mechanisms to perform DNS services for the user -- selecting from different available servers and protocols as well as variants like mDNS -- but we believe that the DNS API is the right abstraction for this task. </p> <h3><span class="mw-headline" id="Direct_presence_interrogation">Direct presence interrogation</span></h3> <p>This document proposes a strict separation between discovery and presence mechanisms. Discovery concerns the mechanisms used to find collaboration partners, other students in your classroom, or the teacher's XO in order to participate in guided classwork. A key principle is that <b>discovery is unconstrained</b>. We will attempt to provide best-of-breed mechanisms for discovering other local hosts, but in practice most non-local discovery needs to piggyback on social mechanisms: XO names posted using Orkut or other social networking sites, added to local or global purpose-specific wikis or static web pages, or communicated over existing IM or email networks. The concise and human readable names we assign to XOs aid their spread using these existing mechanisms, and we anticipate a variety of third-party "friend finder" activities which will expand the discovery possibilities further. One such might list the local XOs whose users are interested in chess, for example, as a way to find game partners when traveling to new network environments. </p><p><b>Presence</b> is the means by which the current status of these discovered friends or resources is ascertained. Although names are invariant, there is no guarantee of connectivity with a particular friend at any given time, and even if the friend is accessible, they may be playing checkers rather than chess right now, for example. </p><p>The canonical presence mechanism is direct: one XO connects directly to a service running on the other and queries for its status. Although the number of possible links in a network grows according to the square of the number of nodes, the interconnectedness of real social networks is quite limited: most users have 20 or so friends, with a few "super nodes" having 100 or so. Directly querying "real friends" should not be expensive in bandwidth or time. </p><p>That said, our existing presence mechanisms also attempt to determine the presence of a potentially unbounded number of <i>strangers</i>, who share the same local network or school server but who may not be actually known to the user. To manage this case, we <b>strictly limit the rate and size of presence queries</b>. A suggested limit is 1 query per second, with 1kB maximum query and response sizes. This limit ensures that overall traffic scales reasonably in the worst case even as the number of potential strangers on the network increases. </p><p>We suggest the following basic presence algorithm: first, find the friend whose status information is "most out of date", favoring real friends over strangers according to some weight mechanism. Directly query that out-of-date friend, updating the "last checked" information in their status even if the query fails. Wait an appropriate amount of time to satisfy the rate limit, and repeat. </p><p>We have formulated the above algorithm so that it transparently handles the bleed-through between discovery and presence which is inherent with some local discovery technologies. For example, if we are using <a rel="nofollow" class="external text" href="http://cerebro.mit.edu">Cerebro</a> to find strangers on the local mesh, it will also provide basic presence information for those friends in the same protocol messages. This information updates our local status behind the back of the presence algorithm, saving our direct rate-limited queries for non-local friends outside the scope of Cerebro. Similar arguments hold for strangers discovered via a school server or other mechanism. The key point is that all hosts should support direct interrogation for presence, even if other efficient mechanisms are used for partial aggregate presence in some situations. Below we will propose using a lightweight XMPP server on the XO to provide a standardized direct presence service which interoperates well with the "buddy presence" mechanisms used by existing Jabber-compatible IM clients, like <a rel="nofollow" class="external text" href="http://en.wikipedia.org/wiki/Pidgin_%28software%29">Pidgin</a> and <a rel="nofollow" class="external text" href="http://en.wikipedia.org/wiki/Google_Talk">Google Talk</a>. </p><p>The purpose of discovery and presence information is fundamentally to enable <b>collaboration</b>. Our principles above dictate that collaboration mechanisms are built using direct peer-to-peer communication. There may be several such collaboration technologies we deploy, including direct socket connection for legacy applications to non-XO hosts, wrapped sockets for legacy protocol communications to XO hosts (in which case we can provide stronger end-to-end authentication and security), as well as multi-pointer X, Tubes, RPC mechanisms, and other related technologies. </p> <h2><span class="mw-headline" id="An_architecture_proposal">An architecture proposal</span></h2> <h3><span class="mw-headline" id="DNS_names">DNS names</span></h3> <p>XOs are identified using DNS names of the form: </p> <pre>name.xxx.school.country.xs.laptop.org </pre> <p>where: </p> <ul><li><b>name</b> is a Punycode encoding of the XO nickname. Technically, the IDN ToASCII mapping operation is performed on the space-elided and punctuation-removed nickname, truncated on the right if necessary so the result is 63 characters or less; see <a rel="nofollow" class="external free" href="http://en.wikipedia.org/wiki/Internationalized_domain_name">http://en.wikipedia.org/wiki/Internationalized_domain_name</a>.</li> <li><b>xxx</b> is an encoded and truncated version of the the XO public key. If N is the (odd) numeric value of the public key, write the first three low-order digits of the quantity (N-1)/2 least-significant digit first in a variable base number system where the first digits are base 36, base 37, and base 26, respectively, and the digits are mapped into characters starting with lowercase alphabetic a-z, then numeric 0-9, then a hyphen. If I've done my math correctly (see <a rel="nofollow" class="external free" href="http://en.wikipedia.org/wiki/Birthday_paradox">http://en.wikipedia.org/wiki/Birthday_paradox</a> ), this requires about 220 students to have the same name before a collision has a 50% chance of occurring. (If we used two characters instead of three, only 36 students would be required.) If the server uses an independent means to prevent duplicate nicknames, the xxx can be replaced with '<tt>xo</tt>'.</li> <li><b>school.country.xs.laptop.org</b> is filled in by registration with a school server. If you do not have access to a school server, then you can register with <tt>xofriends.org</tt> or another independent service, which will provide an appropriate suffix. Pseudonyms can be generated with alternate suffixes via the same means.</li></ul> <p>The three-character public-key-based interpolation into the domain name is present only to allow more reliable setup in the (temporary or permanent) absence of a school server. If we are using a centralized identity service, obviously the service can (and should) enforce uniqueness, and the interpolation is unnecessary. But we would like to be able to do initial setup of an XO with a known name for the school server but no school server actually present, allowing the school server to be added to the deployment later. Three characters seems like a reasonable price to pay for this flexibility. The school server can do very mild authentication based on these characters when it is first setup, but principally we are basic this string on the public key just to avoid introducing a new source of randomness. </p><p>If a school server detects a conflict -- two students named "Michael" in the same school with the same low-order bits of their public key -- the interface should prompt the child to choose a different nickname, as in <a rel="nofollow" class="external text" href="http://www.oreilly.com/catalog/bonjour/index.html">zeroconf</a>. <i>(I could be convinced that it should instead just choose a different random three-character disambiguation component, and we should discard the explicit link between this component and the public key. Discussion welcome!)</i> </p><p>It is easy to second-guess the choice of the Punycode mechanism used by IDN; but there are serious advantages to using an existing and deployed mechanism instead of rolling our own. Using IDN, our XO names are vulnerable to <a rel="nofollow" class="external text" href="http://en.wikipedia.org/wiki/IDN_homograph_attack">homoglyph attacks</a>, but these are managed by Bitfrost mechanisms: the combination of name and public key identifies a friend; having a similar name doesn't allow you to masquerade as another unless you also have their key information. </p><p>Note that we are not violating <a rel="nofollow" class="external text" href="https://zooko.com/distnames.html">Zooko's Triangle</a>; this proposal follows closely his "strategy 4": our DNS names are "memorable" but they are not self-authenticating. As in SSH, our first introduction to a new buddy caches our buddy's public key. The DNS name, like the buddy name and color, is just a <a rel="nofollow" class="external text" href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">pet name</a>; authentication is performed by checking the public key. See <a href="#XO-to-XO_Security">#XO-to-XO Security</a> for further discussion of transparent authentication. </p> <h3><span class="mw-headline" id="Name_resolution">Name resolution</span></h3> <p>Standard <a rel="nofollow" class="external text" href="http://en.wikipedia.org/wiki/Dynamic_dns">dynamic DNS</a> mechanisms can be used to keep the DNS for <tt>name.xxx.school.country.xs.laptop.org</tt> up to date, via a NetworkManager hook which updates the school server. This is sufficient for deployments with a school server. </p><p>If a school server is unavailable, we can provide a resolver which will form an IPv6 link-local address from the lower 64 bits of the SHA-256 of the domain name. This provides "serverless" link-local resolution of friends. (If a true DNS server responds, you SHOULD use that address for further communication in this session, since it may persist even if you roam off your current mesh.) </p> <dl><dd><i>See <a href="/go/Dnshash" title="Dnshash">dnshash</a> for a prototype implementation of this concept.</i> --<a href="/go/User:Mstone" title="User:Mstone">Michael Stone</a> 23:43, 15 July 2009 (UTC)</dd></dl> <p>In the future we may implement additional DNS mechanisms, implemented using the standard Name Service Switch mechanism of glibc. A variant of mDNS is a possibility, although standard mDNS does not appear to behave well on wireless mesh networks and is explicitly limited to domains under <tt>.local</tt>. One can also imagine variants which use peer-to-peer services like <a rel="nofollow" class="external text" href="http://opendht.org/">OpenDHT</a> to implement wide-area serverless dynamic DNS. Again, the key property is that the DNS abstraction is maintained; any alternate service used will provide the same interface to user code and map the same invariant domain names. </p> <h3><span class="mw-headline" id="Friend_links_in_HTML">Friend links in HTML</span></h3> <p>Rather invent a new URI scheme for XO friends, we propose to use the <a rel="nofollow" class="external text" href="http://www.xmpp.org/extensions/xep-0147.html">standard XMPP scheme</a>: </p> <pre><a rel="nofollow" class="external free" href="xmpp:xo@nickname.xxx.school.country.xs.laptop.org?roster;name=Full%20Name">xmpp:xo@nickname.xxx.school.country.xs.laptop.org?roster;name=Full%20Name</a> </pre> <p>The "Full Name" in this scheme refers to the actual unicode XO name specified by the child, which may differ from abbreviated and encoded version used in the domain name string. </p><p>In the Browse activity, clicking on a link of this form would add this person to your buddy list. Collaborating with this buddy would begin by resolving the domain name of the address according to the mechanisms of the previous section, and then contacting the XMPP service at that address. </p><p>Friends are represented internally as user@domain. When entering friends via manual keyboard input, specialized barcode reader, or other discovery mechanism, only the domain name may be necessary, but maintaining the mostly-invariant 'xo@' portion of buddies internally allows more uniformity in our limited dealings with non-XO Jabber friends (for chat, for example). </p> <h3><span class="mw-headline" id="Presence_service">Presence service</span></h3> <p>The XMPP server on the laptop responds to roster and chat requests like a normal Jabber client, so that we interoperate with iChat, Google Talk, Pigin, etc. When a school server is present, it MAY publish a SRV record for </p> <pre>_xmpp-server._tcp.nickname.xxx.school.country.xs.laptop.org </pre> <p>specifying that it is handling XMPP requests for that user, according to <a rel="nofollow" class="external text" href="http://tools.ietf.org/html/rfc3921#page-88">RFC 3921</a>. This delegation allows the school server to proxy requests in some cases, for example if the school server is directly addressable from outside a school but the internal mesh network of XOs is not. </p><p>Additional presence information specific to the XO, for example enumeration of sharable activities, is exported using a simple service at a well-known port. This could potentially be performed with compatible extensions to XMPP, other XMPP usernames, or it could involve a simple http or other service. The XO software should interoperate well with buddies who do not support the XO-specific extensions -- I should be able to friend and chat with a Google Talk user even if the Google servers support only standard XMPP. </p> <h2><span class="mw-headline" id="Extensions_and_improvements">Extensions and improvements</span></h2> <p>In this section I outline a few additional pieces which can (a) connect groups of users behind NATs, (b) allow school children to maintain their DNS identity even if the schoolserver is deliberately inaccessible from their homes, and (c) leverage the indirection afforded by DNS to improve the end-to-end security of connections between XOs without affecting non-XO clients speaking legacy protocols. We also briefly discuss implementation issues for disconnected networks. </p> <h3><span class="mw-headline" id="Tunnels">Tunnels</span></h3> <p>As discussed above, it is undesirable to attempt to automatically route around NATs or egress firewalls. However, in cases where that is explicitly desired, IPv6-over-IPv4 (6to4) tunnels are a logical & recommended means for doing so. For example, a school in Peru might partner with a "sister school" in Africa, establishing an IPv6 tunnel between their otherwise firewalled education networks. In this case this tunnel could be established between the Peru and Africa school servers. </p><p>A similar situation might occur when a child takes their laptop home, to a NAT'ed home network which doesn't allow collaboration. In this scenario, it is desirable to have the 6to4 client endpoint on the XO itself; the server endpoint might be on the machine hosting the XO's dynDNS entry. In the dynDNS/registration protocol, it seems reasonable to expect the host might return tunnel details for the XO to use. </p><p>Note that this is a deliberately _unambitious_ proposal. We are not attempting to provide globally-routable IPv6 addresses to every XO, or to automatically discover and utilize tunnels. The difficult realities of maintaining IPv6 network endpoints make this largely infeasible. Instead we are proposing a small extension to the DNS registration mechanism that allows creation of ad-hoc and globally disconnected IPv6 networks to transparently facilitate otherwise-difficult collaboration. Importantly, we are 'not' exposing the "NAT-busting" to the application level: we are just making the underlying standard network enclose slightly more nodes than it did previously. </p> <h3><span class="mw-headline" id="External_DNS">External DNS</span></h3> <p>The use of alternate pseudonyms, expressed as differing DNS names, allows a child to continue collaborating at home even if their school server is firewalled off from home access. However, we expect that many countries will find it desirable to allow the kids to keep their "school identity" even while maintaining a closed school network. </p><p>We propose setting up a single "external DNS" server on the accessible internet to allow this. This DNS server reports itself as authoritative for the various school.country.xs.laptop.org domains to the outside world (although the school servers are still authoritative inside the school network) and allows kids to register their current network addresses to update their DNS mappings from home. Note that the XO's domain name will report different addresses inside and outside the school network; that's fine! </p><p>This lightweight "external DNS" server could also provide tunnel services, as described above, to better connect kids behind home NATs. </p> <h3><span class="mw-headline" id="XO-to-XO_Security">XO-to-XO Security</span></h3> <p>The indirection afforded by DNS allows us to use code like <a rel="nofollow" class="external text" href="ftp://ftp.porcupine.org/pub/security/index.html">tcp_wrappers</a> to transparently authenticate XO hosts, without negatively affecting interoperability with legacy software and systems. </p><p>When a friend is added to our friends list, an XO-specific protocol is used to contact the machine and obtain its public key, as ssh does. If this succeeds, the friend is specially marked as an "XO friend". </p><p>A lookaside DNS service can be taught to consult our list of "XO friends" when doing a lookup. If the given domainname is for an XO friend, a localhost address can be returned instead of the "real" address. Connecting to the localhost address wraps each socket so that communication is encapsulated with SSL (checking the "server's" key and providing our key as a client certificate) before being forwarded on to a specific port at the "real" network address. A listener at that port performs the other side of the SSL connection before forwarding traffic to it's "true" destination at that host. </p><p>In this manner end-to-end authentication of XO's can be layered on top of the network without any modification of activity software or protocols. If you use a web browser to surf to <a rel="nofollow" class="external free" href="http://myfriend.someschool.xs.laptop.org">http://myfriend.someschool.xs.laptop.org</a> from your XO, the identity of your friend is transparently verified without teaching the web browser any new tricks. Because these wrappers only apply when the domain name corresponds to a known XO friend, surfing to (say) <a rel="nofollow" class="external free" href="http://xkcd.com">http://xkcd.com</a> is unaffected. </p><p>This implements the "ssh model" of authentication, roughly. It is vulnerable to the same man-in-the-middle and key-compromise attacks ssh is; nevertheless this model has been shown to have significant practical value. </p> <h3><span class="mw-headline" id="Disconnected_operation">Disconnected operation</span></h3> <p>It is desirable to allow access to cached internet content even without access to the internet. A local caching HTTP proxy on the XO provides a simple solution, but many XOs will likely contain duplicate content. A peer-to-peer cache provides one alternative, but a transparent proxy on a school server can do better, since the school server contains much more available space. </p><p>However, XOs making web requests during disconnected operation will still attempt to resolve DNS names to addresses before initiating network requests. The school server can provide an "offline DNS cache" in the same way it provides an "offline HTTP cache", but in fact we can do better. In <a href="#Name_resolution">the name resolution section</a> above we have already presented the seeds of an answer: XOs have an alternative name resolution mechanism which resolves DNS names to a link-local IPv6 address based on a hash of the DNS name in the absence of "authoritative" DNS service. The school server's DNS server can use this strategy to provide short lifetime non-link-local IPv6 addresses for DNS names in the absence of upstream DNS, which then allows it to intercept web requests for those addresses from XOs and properly serve them from its cache. </p><p>After connectivity is restored, the school server should route connections to the advertised link-local address to the "real" internet address of the host for the duration it advertised for the domain's mapping to the link-local address. </p> <h2><span class="mw-headline" id="Credits">Credits</span></h2> <dl><dt>Author</dt> <dd>C. Scott Ananian (cscott a t laptop.org)</dd></dl></div>    </div> <div class="printfooter" data-nosnippet="">Retrieved from "<a dir="ltr" href="http://wiki.laptop.org/mediawiki/index.php?title=Network_principles&oldid=290755">http://wiki.laptop.org/mediawiki/index.php?title=Network_principles&oldid=290755</a>"</div></div> <div id="catlinks" class="catlinks" data-mw="interface"><div id="mw-normal-catlinks" class="mw-normal-catlinks"><a href="/go/Special:Categories" title="Special:Categories">Categories</a>: <ul><li><a href="/go/Category:Pages_monitored_by_OLPC" title="Category:Pages monitored by OLPC">Pages monitored by OLPC</a></li><li><a href="/go/Category:Obsolete" title="Category:Obsolete">Obsolete</a></li><li><a href="/go/Category:Network" title="Category:Network">Network</a></li><li><a href="/go/Category:Software_ideas" title="Category:Software ideas">Software ideas</a></li></ul></div></div> </div> </div> <div id="mw-navigation"> <h2>Navigation menu</h2> <div id="mw-head"> <nav id="p-personal" class="vector-menu mw-portlet mw-portlet-personal vector-user-menu-legacy" aria-labelledby="p-personal-label" role="navigation" > <h3 id="p-personal-label" class="vector-menu-heading " > <span class="vector-menu-heading-label">Personal tools</span> </h3> <div class="vector-menu-content"> <ul class="vector-menu-content-list"><li id="pt-login" class="mw-list-item"><a href="/mediawiki/index.php?title=Special:UserLogin&returnto=Network+principles" title="You are encouraged to log in; however, it is not mandatory [o]" accesskey="o"><span>Log in</span></a></li></ul> </div> </nav> <div id="left-navigation"> <nav id="p-namespaces" class="vector-menu mw-portlet mw-portlet-namespaces vector-menu-tabs vector-menu-tabs-legacy" aria-labelledby="p-namespaces-label" role="navigation" > <h3 id="p-namespaces-label" class="vector-menu-heading " > <span class="vector-menu-heading-label">Namespaces</span> </h3> <div class="vector-menu-content"> <ul class="vector-menu-content-list"><li id="ca-nstab-main" class="selected mw-list-item"><a href="/go/Network_principles" title="View the content page [c]" accesskey="c"><span>Page</span></a></li><li id="ca-talk" class="mw-list-item"><a href="/go/Talk:Network_principles" rel="discussion" title="Discussion about the content page [t]" accesskey="t"><span>Discussion</span></a></li></ul> </div> </nav> <nav id="p-variants" class="vector-menu mw-portlet mw-portlet-variants emptyPortlet vector-menu-dropdown" aria-labelledby="p-variants-label" role="navigation" > <input type="checkbox" id="p-variants-checkbox" role="button" aria-haspopup="true" data-event-name="ui.dropdown-p-variants" class="vector-menu-checkbox" aria-labelledby="p-variants-label" /> <label id="p-variants-label" aria-label="Change language variant" class="vector-menu-heading " > <span class="vector-menu-heading-label">English</span> </label> <div class="vector-menu-content"> <ul class="vector-menu-content-list"></ul> </div> </nav> </div> <div id="right-navigation"> <nav id="p-views" class="vector-menu mw-portlet mw-portlet-views vector-menu-tabs vector-menu-tabs-legacy" aria-labelledby="p-views-label" role="navigation" > <h3 id="p-views-label" class="vector-menu-heading " > <span class="vector-menu-heading-label">Views</span> </h3> <div class="vector-menu-content"> <ul class="vector-menu-content-list"><li id="ca-view" class="selected mw-list-item"><a href="/go/Network_principles"><span>Read</span></a></li><li id="ca-viewsource" class="mw-list-item"><a href="/mediawiki/index.php?title=Network_principles&action=edit" title="This page is protected.
You can view its source [e]" accesskey="e"><span>View source</span></a></li><li id="ca-history" class="mw-list-item"><a href="/mediawiki/index.php?title=Network_principles&action=history" title="Past revisions of this page [h]" accesskey="h"><span>View history</span></a></li></ul> </div> </nav> <nav id="p-cactions" class="vector-menu mw-portlet mw-portlet-cactions emptyPortlet vector-menu-dropdown" aria-labelledby="p-cactions-label" role="navigation" title="More options" > <input type="checkbox" id="p-cactions-checkbox" role="button" aria-haspopup="true" data-event-name="ui.dropdown-p-cactions" class="vector-menu-checkbox" aria-labelledby="p-cactions-label" /> <label id="p-cactions-label" class="vector-menu-heading " > <span class="vector-menu-heading-label">More</span> </label> <div class="vector-menu-content"> <ul class="vector-menu-content-list"></ul> </div> </nav> <div id="p-search" role="search" class="vector-search-box-vue vector-search-box-show-thumbnail vector-search-box-auto-expand-width vector-search-box"> <div> <h3 > <label for="searchInput">Search</label> </h3> <form action="/mediawiki/index.php" id="searchform" class="vector-search-box-form"> <div id="simpleSearch" class="vector-search-box-inner" data-search-loc="header-navigation"> <input class="vector-search-box-input" type="search" name="search" placeholder="Search OLPC" aria-label="Search OLPC" autocapitalize="sentences" title="Search OLPC [f]" accesskey="f" id="searchInput" > <input type="hidden" name="title" value="Special:Search"> <input id="mw-searchButton" class="searchButton mw-fallbackSearchButton" type="submit" name="fulltext" title="Search the pages for this text" value="Search"> <input id="searchButton" class="searchButton" type="submit" name="go" title="Go to a page with this exact name if it exists" value="Go"> </div> </form> </div> </div> </div> </div> <div id="mw-panel"> <div id="p-logo" role="banner"> <a class="mw-wiki-logo" href="/go/The_OLPC_Wiki" title="Visit the main page"></a> </div> <nav id="p-About_OLPC" class="vector-menu mw-portlet mw-portlet-About_OLPC vector-menu-portal portal" aria-labelledby="p-About_OLPC-label" role="navigation" > <h3 id="p-About_OLPC-label" class="vector-menu-heading " > <span class="vector-menu-heading-label">About OLPC</span> </h3> <div class="vector-menu-content"> <ul class="vector-menu-content-list"><li id="n-The-OLPC-Wiki" class="mw-list-item"><a href="/go/The_OLPC_Wiki"><span>The OLPC Wiki</span></a></li><li id="n-Contact-us" class="mw-list-item"><a href="/go/OLPC:Contact_us"><span>Contact us</span></a></li><li id="n-Blog" class="mw-list-item"><a href="http://blog.laptop.org" rel="nofollow"><span>Blog</span></a></li><li id="n-Communicate" class="mw-list-item"><a href="/go/Communication_channels"><span>Communicate</span></a></li><li id="n-Participate" class="mw-list-item"><a href="/go/Participate"><span>Participate</span></a></li><li id="n-laptop.org" class="mw-list-item"><a href="http://laptop.org" rel="nofollow"><span>laptop.org</span></a></li></ul> </div> </nav> <nav id="p-About_the_laptop" class="vector-menu mw-portlet mw-portlet-About_the_laptop vector-menu-portal portal" aria-labelledby="p-About_the_laptop-label" role="navigation" > <h3 id="p-About_the_laptop-label" class="vector-menu-heading " > <span class="vector-menu-heading-label">About the laptop</span> </h3> <div class="vector-menu-content"> <ul class="vector-menu-content-list"><li id="n-Specifications" class="mw-list-item"><a href="/go/Hardware"><span>Specifications</span></a></li><li id="n-Buying" class="mw-list-item"><a href="/go/Buying_XOs"><span>Buying</span></a></li><li id="n-Help-using" class="mw-list-item"><a href="/go/Getting_started"><span>Help using</span></a></li><li id="n-Support-for" class="mw-list-item"><a href="/go/Support"><span>Support for</span></a></li><li id="n-Upgrading" class="mw-list-item"><a href="/go/Releases"><span>Upgrading</span></a></li><li id="n-Repairing" class="mw-list-item"><a href="/go/Repair"><span>Repairing</span></a></li><li id="n-Disassembly" class="mw-list-item"><a href="/go/Disassembly"><span>Disassembly</span></a></li></ul> </div> </nav> <nav id="p-About_the_tablet" class="vector-menu mw-portlet mw-portlet-About_the_tablet vector-menu-portal portal" aria-labelledby="p-About_the_tablet-label" role="navigation" > <h3 id="p-About_the_tablet-label" class="vector-menu-heading " > <span class="vector-menu-heading-label">About the tablet</span> </h3> <div class="vector-menu-content"> <ul class="vector-menu-content-list"><li id="n-Specifications" class="mw-list-item"><a href="http://one.laptop.org/about/xo-tablet" rel="nofollow"><span>Specifications</span></a></li><li id="n-Buying" class="mw-list-item"><a href="http://www.walmart.com/ip/24511209" rel="nofollow"><span>Buying</span></a></li><li id="n-Help-using" class="mw-list-item"><a href="http://one.laptop.org/about/xo-tablet-faq" rel="nofollow"><span>Help using</span></a></li><li id="n-Support-for" class="mw-list-item"><a href="http://www.xotablet.com/support/" rel="nofollow"><span>Support for</span></a></li></ul> </div> </nav> <nav id="p-Projects" class="vector-menu mw-portlet mw-portlet-Projects vector-menu-portal portal" aria-labelledby="p-Projects-label" role="navigation" > <h3 id="p-Projects-label" class="vector-menu-heading " > <span class="vector-menu-heading-label">Projects</span> </h3> <div class="vector-menu-content"> <ul class="vector-menu-content-list"><li id="n-for-Educators" class="mw-list-item"><a href="/go/Educators"><span>for Educators</span></a></li><li id="n-for-Developers" class="mw-list-item"><a href="/go/Developers"><span>for Developers</span></a></li><li id="n-Software" class="mw-list-item"><a href="/go/Software_components"><span>Software</span></a></li><li id="n-Hardware" class="mw-list-item"><a href="/go/Hardware"><span>Hardware</span></a></li><li id="n-Activities" class="mw-list-item"><a href="http://activities.sugarlabs.org" rel="nofollow"><span>Activities</span></a></li><li id="n-Deployment-Guide" class="mw-list-item"><a href="/go/Deployment_Guide"><span>Deployment Guide</span></a></li><li id="n-School-Server-(XS)" class="mw-list-item"><a href="/go/School_server"><span>School Server (XS)</span></a></li><li id="n-School-Server-(XSCE)" class="mw-list-item"><a href="/go/XS_Community_Edition"><span>School Server (XSCE)</span></a></li></ul> </div> </nav> <nav id="p-OLPC_wiki" class="vector-menu mw-portlet mw-portlet-OLPC_wiki vector-menu-portal portal" aria-labelledby="p-OLPC_wiki-label" role="navigation" > <h3 id="p-OLPC_wiki-label" class="vector-menu-heading " > <span class="vector-menu-heading-label">OLPC wiki</span> </h3> <div class="vector-menu-content"> <ul class="vector-menu-content-list"><li id="n-Recent-changes" class="mw-list-item"><a href="/go/Special:RecentChanges"><span>Recent changes</span></a></li><li id="n-Glossary" class="mw-list-item"><a href="/go/Glossary"><span>Glossary</span></a></li><li id="n-Random-page" class="mw-list-item"><a href="/go/Special:Random"><span>Random page</span></a></li><li id="n-Help-using-the-wiki" class="mw-list-item"><a href="https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents"><span>Help using the wiki</span></a></li></ul> </div> </nav> <nav id="p-tb" class="vector-menu mw-portlet mw-portlet-tb vector-menu-portal portal" aria-labelledby="p-tb-label" role="navigation" > <h3 id="p-tb-label" class="vector-menu-heading " > <span class="vector-menu-heading-label">Tools</span> </h3> <div class="vector-menu-content"> <ul class="vector-menu-content-list"><li id="t-whatlinkshere" class="mw-list-item"><a href="/go/Special:WhatLinksHere/Network_principles" title="A list of all wiki pages that link here [j]" accesskey="j"><span>What links here</span></a></li><li id="t-recentchangeslinked" class="mw-list-item"><a href="/go/Special:RecentChangesLinked/Network_principles" rel="nofollow" title="Recent changes in pages linked from this page [k]" accesskey="k"><span>Related changes</span></a></li><li id="t-specialpages" class="mw-list-item"><a href="/go/Special:SpecialPages" title="A list of all special pages [q]" accesskey="q"><span>Special pages</span></a></li><li id="t-print" class="mw-list-item"><a href="javascript:print();" rel="alternate" title="Printable version of this page [p]" accesskey="p"><span>Printable version</span></a></li><li id="t-permalink" class="mw-list-item"><a href="/mediawiki/index.php?title=Network_principles&oldid=290755" title="Permanent link to this revision of this page"><span>Permanent link</span></a></li><li id="t-info" class="mw-list-item"><a href="/mediawiki/index.php?title=Network_principles&action=info" title="More information about this page"><span>Page information</span></a></li></ul> </div> </nav> </div> </div> <footer id="footer" class="mw-footer" role="contentinfo" > <ul id="footer-info"> <li id="footer-info-lastmod"> Last edited on 23:18, 5 August 2013.</li> </ul> <ul id="footer-places"> <li id="footer-places-privacy"><a href="/go/OLPC:Privacy_policy">Privacy</a></li> <li id="footer-places-about"><a href="/go/OLPC:About">About OLPC</a></li> <li id="footer-places-disclaimer"><a href="/go/OLPC:General_disclaimer">Disclaimers</a></li> </ul> <ul id="footer-icons" class="noprint"> <li id="footer-poweredbyico"><a href="https://www.mediawiki.org/"><img src="/mediawiki/resources/assets/poweredby_mediawiki_88x31.png" alt="Powered by MediaWiki" srcset="/mediawiki/resources/assets/poweredby_mediawiki_132x47.png 1.5x, /mediawiki/resources/assets/poweredby_mediawiki_176x62.png 2x" width="88" height="31" loading="lazy"/></a></li> </ul> </footer> <script>(RLQ=window.RLQ||[]).push(function(){mw.config.set({"wgPageParseReport":{"limitreport":{"cputime":"0.014","walltime":"0.016","ppvisitednodes":{"value":88,"limit":1000000},"postexpandincludesize":{"value":980,"limit":2097152},"templateargumentsize":{"value":0,"limit":2097152},"expansiondepth":{"value":5,"limit":100},"expensivefunctioncount":{"value":1,"limit":100},"unstrip-depth":{"value":0,"limit":20},"unstrip-size":{"value":0,"limit":5000000},"timingprofile":["100.00% 3.393 1 -total"," 50.07% 1.699 1 Template:Outdated"," 32.39% 1.099 1 Template:OLPC"," 13.35% 0.453 1 Template:TOCright"]},"cachereport":{"timestamp":"20241127175337","ttl":86400,"transientcontent":false}}});mw.config.set({"wgBackendResponseTime":90});});</script> </body> </html>