Network2

From OLPC
Revision as of 20:49, 14 July 2009 by Mstone (talk | contribs)
Jump to: navigation, search

This page proposes a fresh design for network configuration in a highly collaborative world, based on Scott's Network Principles in general and on these micro-principles in particular:

  1. Ease of debugging is paramount.
  2. Orthogonal pieces.
  3. Self-test functionality.

However, unlike the Network Principles situation, we also describe how to integrate several kinds of NAT-traversal technology, primarily to support dog-fooding and diagnosis by remote developers.

Client IPv6

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

  1. You might discover an IPv6 router advertising on one of your links.
    • (See sysctl net.ipv6.conf.all.accept_ra and related variables.)
  2. You might try out dhcp6c.
  3. You might have some kind of IPv4 connectivity. If so, connect to the Internet or to other internetworks (openvpn, ...) of your choice.
  4. Use dnshash to add guessable link-local addresses to all your links.

Server IPv6

Your job is to be an IPv6 router and a DNS server. One of several situations might obtain:

  1. You might discover an IPv6 router advertising one or more IPv6 prefixes on your outbound link(s).
  2. You might have some kind of IPv4 connectivity. If so, connect to the Internet or to other internetworks (openvpn, ...) of your choice.
  3. You might be under a tree. If so, generate a Unique Local Address prefix.
  4. (Use dnshash to add guessable link-local addresses to all your links?)

When done, use radvd or dhcp6d to share addresses.

Server DNS

One of the server's most important jobs is to get itself on the Internet or on other well-known internetworks so that it can dynamically map clients' stable (DNS) names to their unstable names [IPv6 addresses]. ( and try to offer your resources to your clients, if you can recognize them.