Network2: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
 
(181 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{TOCright}}
This page proposes a rough design for networking for a highly collaborative world, based on Scott's [[Network Principles]].
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]].
= Design =


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.
== Protocols ==


'''Quick links''': '''[[Network2/Paper|the Paper]]''' : (finished/''unfinished'' sections)
We take [http://tools.ietf.org/html/rfc2460 IPv6] and [http://tools.ietf.org/html/rfc1034 DNS] as the basis of our system and rely heavily the Linux Documentation Project's IPv6 [http://tldp.org/HOWTO/html_single/Linux+IPv6-HOWTO/ documentation].


* Prior work: [[networking]], [[collaboration]], [[network principles]]
A couple of key facts and expectations inform the rest of this design, like:
* 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...'''
* hosts will have multiple interfaces,
* interfaces will have multiple addresses,
* DNS queries (used via <tt>getaddrinfo()</tt>) will return multiple results
* these results will be sorted in a [http://tools.ietf.org/html/rfc3484 sane order], and
* 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.


# "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."
== Client IPv6 Configuration ==
# "I want a design that has 20% fewer ways to fail, and that offers manual overrides for the failure modes that remain."
# "I want to chop 2-3 levels from the current collaboration stack's 6-level 'fast-path'."
# "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!
Your job is to be an IPv6 node. Consequently, when you bring up your interfaces,


==Subpages==
# You might [http://tools.ietf.org/html/rfc2461 discover] an IPv6 router [http://tools.ietf.org/html/rfc2463 advertising] on one of your links.
{{Special:PrefixIndex/{{PAGENAMEE}}/}}
#* (See <tt>sysctl net.ipv6.conf.all.accept_ra</tt> and related variables.)
# You might try out [https://fedorahosted.org/dhcpv6/ dhcp6c].
# 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.


== Server IPv6 Configuration ==


[[Category:Network2]]
Your job is to be an IPv6 router and a [http://tools.ietf.org/html/rfc1035 DNS server]. One of several situations might obtain:
[[Category:Subsystems]]

# 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?)

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

== Server DNS Configuration ==

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.)

''(Other possibilities: maybe DNSSEC isn't so hard? Maybe DNSCurve will be usable?)''

== Client DNS Configuration ==

Clients which have been registered with one or more servers need to update those servers when their addresses change using the protcol described above.


= Analysis =

== Bandwidth Usage ==

Several important numbers that we need to predict and to measure:

tx == transmit, rx == receive, btx == broadcast
btx/tx/rx - ICMPv6+IPv6+phys - router discovery (RD)
btx/rx - ICMPv6+IPv6+phys - duplicate address detection (DAD)
tx/rx - ICMPv6+IPv6+phys - NS neighbor discovery (ND)
tx/rx - UDP+IPv6+phys - DNS query
tx/rx - JSON+SSH+TCP+IPv6+phys - DNS update
where "phys" describes the equations' dependence on the "physical" layer's
frame overhead and MTU
notable "phys" layers:
Ethernet -- ad-hoc wifi, infra wifi, 802.11s mesh, switch, hub
TLS+UDP+IPv4 -- openvpn
L2TP+IPsec+IPv4 -- raccoon, isakmpd, openswan, etc.
UDP+IPv4 -- teredo

== Debugging Techniques ==

Start recording a typescript so that we can see what you did.

TESTDIR=`pwd`/testing
mkdir -p $TESTDIR && cd TESTDIR
script
ulimit -c unlimited

Check that you've got the right DNS name for the person you want to talk to.

NAME=the.right.person
echo $NAME > peer

Dump your addresses, routes, and perhaps your open connections.

hostname --fqdn | tee host
ip addr show | tee addrs
ip route show | tee ipv4_routes
ip -6 route show | tee ipv6_routes
netstat -anp | tee conns

If you have wireless devices,

iwconfig | tee iwconfig
iwlist scan | tee iwlist_scan

Fire up tcpdump:

tcpdump -w packets -s0 &

Resolve that name to addresses. Check that the addresses seem sane.

dnshash_lookup $NAME | tee peer_addrs_dnshash
dig $NAME | tee peer_addrs_dig

Route to the addresses:

ping6 -I $IFACE $ADDR | tee ping
traceroute6 $ADDR | tee traceroute
tracepath6 $ADDR | tee tracepath

Connect to the address:

nc6 $ADDR $PORT
# echo "SSH-2.0-Hi" | nc6 $ADDR 22
# printf "GET / HTTP/1.0\r\n\r\n" | nc6 $ADDR 80
# ssh $ADDR
# curl -I http://$ADDR/
# ...

Conduct a bandwidth test:

iperf -c -V $ADDR

Collect logs from your application and send them to developers:

kill -SIGINT %1
cd ..
tar c $TESTDIR | lzma -c > logs.tar.lzma

== Self-Test Algorithm ==

As we gain experience with the system, we'll write a decision-list here which inspects the output of the diagnostic procedures listed above and which identifies the proximate cause of networking failure based on those results.

== Advice for Coders ==

There are two critical changes that you'll need to make to your design in order to really make it sing.

First, you'll want to add some mechanism for your users to type in hostnames that they want you to connect to. This lets them do all sorts of cool stuff like:

* copy-and-paste links from websites or cerebro
* type in names from a physical display like a blackboard or a handout,

Second, you'll want to be prepared to re-resolve names in order to get fresh addresses each time your connectivity changes. For the time being, you should do this by calling libc's <tt>[http://linux.die.net/man/3/getaddrinfo getaddrinfo()]</tt> function.

Third, go check out [http://tools.ietf.org/html/rfc4960 SCTP] ([http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol wikipedia], [http://linux.die.net/man/7/sctp man page]). It's support for multi-homing, multi-streaming with and without ordering guarantees, and for updating the addresses you're using to talk to your peer on the fly seem particularly serendipitous.

== Advice for Deployers ==

Ask your ISPs to provide IPv6 prefixes or tunnel endpoints. After all -- if none of their customers ask, then what incentive will they ever have to upgrade?

== Security ==

* [[Communications security]] and petnames. A very rough road along which something reasonable ''might'' lie:
*# Use physical introduction to CNAME <tt>cscott.michael.laptop.org</tt> to <tt>''&lt;key&gt;''.cscott.laptop.org</tt>.
*# Then, my [http://dnscurve.org dnscurve]-compatible DNS resolver will refuse to give me addresses unless the nameserver I contact for cscott proves knowledge of cscott's private key.
*# Then I have a nice shared secret with which to configure IPsec security associations.

== Future Work ==

* Per-host networks and per-app IPs and names.
* Sample code.

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"