Network2: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
 
(216 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{TOCright}}
This page proposes a fresh design for network configuration in a highly collaborative world, based on Scott's [[Network Principles]]. However, unlike the pure Network Principles, we also outline where and how to integrate several kinds of NAT-traversal technology, primarily to support dog-fooding and diagnosis by remote developers.
Last updated: [[User:Mstone|Michael Stone]] 04:15, 15 January 2010 (UTC) | '''[[Network2/Paper|paper version]]'''


Sugar's desired realtime collaboration experience can only be provided atop a robust and efficient network stack designed to accommodate automated diagnosis and standardized workarounds -- anything less only wastes students' and teachers' time and patience, contrary to our [[OLPC Human Interface Guidelines/Design Fundamentals/Key Design Principles|human interface guidelines]].
We take [http://tools.ietf.org/html/rfc2460 IPv6] as the basis of our system and rely heavily its [http://tldp.org/HOWTO/html_single/Linux+IPv6-HOWTO/ documentation] for Linux.


This '''unfinished''' essay summarizes an attempt to work out a simple way to realize this sort of network experience, with existing software and hardware, while also demonstrating the sort of thinking which might help other parts of the system achieve the same standard of quality.
A key fact about IPv6 is that it's /expected/ that hosts will have multiple interfaces, that interfaces will have multiple addresses, that DNS queries (used via <tt>getaddrinfo()</tt>) will return multiple results sorted in a [http://tools.ietf.org/html/rfc3484 sane order], and that hosts will choose routes for packets based on how specifically the routes match the destination and on any QoS information available to the routing node.


'''Quick links''': '''[[Network2/Paper|the Paper]]''' : (finished/''unfinished'' sections)
These features combine to provide a particularly good user experience for RESTful protocols.


* Prior work: [[networking]], [[collaboration]], [[network principles]]
== Client IPv6 ==
* Background: [[Network2/Purpose|purpose]], [[Network2/Scenarios|scenarios]], [[Network2/Architecture|architecture]]
* Designs: [[Network2/Design|naming and internetworking]], ''[[Network2/Security|security ideas]]'', [[Network2/Diagnosis|diagnosis techniques]]
* Analyses: ''[[Network2/Dynamics|cost model]]'', ''[[Network2/Self-test|self-test algorithm]]''
* Experiments: [[Network2/Experiments/Dnshash|dnshash]], [[Network2/Experiments/Openvpn|openvpn]], ''[[Network2/Experiments/HE|6to4: HE]]'', ''[[Network2/Experiments/Sixxs|6to4: Sixxs]]'', ''[[Network2/Experiments/Simulation|simulation]]'', ''[[Network2/Experiments/openwrt|openwrt]]'', ''[[Network2/Experiments/tinydns|olpcdyndns1]]''


'''Personal goals...'''
Your job is to be an IPv6 node. Consequently, when you bring up your interfaces,


# "I want to use familiar tools in my activities, -- like Twisted, curl, ssh, rsync, and email -- both under a tree, in a walled garden, and out on the public Internet, without modification or wrappers."
# You might [http://tools.ietf.org/html/rfc2461 discover] an IPv6 router [http://tools.ietf.org/html/rfc2463 advertising] on one of your links.
# "I want a design that has 20% fewer ways to fail, and that offers manual overrides for the failure modes that remain."
#* (See <tt>sysctl net.ipv6.conf.all.accept_ra</tt> and related variables.)
# "I want to chop 2-3 levels from the current collaboration stack's 6-level 'fast-path'."
# You might try out [https://fedorahosted.org/dhcpv6/ dhcp6c].
# "I want to collaborate with people who only have web browsers -- they outnumber people with Jabber clients by millions."
# You might have some kind of IPv4 connectivity. If so, [http://www.sixxs.net/faq/connectivity/?faq=comparison connect] to the Internet or to other internetworks of your choice.
#* ([http://www.remlab.net/miredo/ miredo] and [http://openvpn.net/ openvpn] seem particularly easy to configure and hence to experiment with...)
# Use [[dnshash]] to add guessable link-local addresses to all your links.


'''Finally, to help out''', please improve my writing, experiment with my ideas, and share this work with your friends!
== Server IPv6 ==


==Subpages==
Your job is to be an IPv6 router and a [http://tools.ietf.org/html/rfc1034 DNS] [http://tools.ietf.org/html/rfc1035 server]. One of several situations might obtain:
{{Special:PrefixIndex/{{PAGENAMEE}}/}}


# You might discover an IPv6 router advertising one or more IPv6 prefixes on your outbound link(s).
# You might have some kind of IPv4 connectivity. If so, [http://www.sixxs.net/faq/connectivity/?faq=comparison connect] to the Internet or to other internetworks of your choice.
# You might be under a tree. If so, generate a [http://tools.ietf.org/html/rfc4193 Unique Local Address] prefix.
# (Use [[dnshash]] to add guessable link-local addresses to all your links?)


[[Category:Network2]]
When done, use [http://www.litech.org/radvd/ radvd] or [https://fedorahosted.org/dhcpv6/ dhcp6d] to share addresses.
[[Category:Subsystems]]

== Server DNS ==

One of the server's most important jobs is to get itself on appropriate internetworks so that it can dynamically map stable (DNS) names to unstable names (IPv6 addresses) for itself and its clients.

Unfortunately, the most reliable and secure means of updating these mappings is likely to be bespoke -- [http://tools.ietf.org/html/rfc2136 RFC 2136] is not widely implemented and specifies no concrete security protocol while DNSSEC seems immature at present.

Consequently, I propose the following strawman update protocol -- exchange an RFC-2136 UPDATE packet and response over your favorite authenticated RPC protocol with the nameserver.

(My favorite protocol for this sort of thing is currently "json-over-SSH-to-python-and-make", but variations (ucspi-ssl, 9p, etc.) make me smile.)

Latest revision as of 04:15, 15 January 2010

Last updated: Michael Stone 04:15, 15 January 2010 (UTC) | paper version

Sugar's desired realtime collaboration experience can only be provided atop a robust and efficient network stack designed to accommodate automated diagnosis and standardized workarounds -- anything less only wastes students' and teachers' time and patience, contrary to our human interface guidelines.

This unfinished essay summarizes an attempt to work out a simple way to realize this sort of network experience, with existing software and hardware, while also demonstrating the sort of thinking which might help other parts of the system achieve the same standard of quality.

Quick links: the Paper : (finished/unfinished sections)

Personal goals...

  1. "I want to use familiar tools in my activities, -- like Twisted, curl, ssh, rsync, and email -- both under a tree, in a walled garden, and out on the public Internet, without modification or wrappers."
  2. "I want a design that has 20% fewer ways to fail, and that offers manual overrides for the failure modes that remain."
  3. "I want to chop 2-3 levels from the current collaboration stack's 6-level 'fast-path'."
  4. "I want to collaborate with people who only have web browsers -- they outnumber people with Jabber clients by millions."

Finally, to help out, please improve my writing, experiment with my ideas, and share this work with your friends!

Subpages

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Network2&oldid=230397"