Network2/Design: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (New page: == Network Architecture == We want to offer maximally efficient and robust support for our ''ideal network scenarios'' (nos. 1 and 9, denoted with bold text, below) while offering seamles...)
 
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Network2 header}}
== Network Architecture ==

We want to offer maximally efficient and robust support for our ''ideal network scenarios'' (nos. 1 and 9, denoted with bold text, below) while offering seamless support for ''optional network enhancements'' like fancy links, routers, tunnel endpoints, and transit agreements that may be provided by the ''surrounding ecosystem'' of deployment organizations, universities, individuals, and commercial entities.

Network Scenarios:

# '''access to at least one shared-media link.'''
# a more efficient link, like an 802.3 switch or an 802.11 access point.
# a bridge, like an XS or a good access point, between two or more otherwise separate single-link networks.
# a local router, like an XS, routing between two or more otherwise separate (but potentially complicated) local networks
# a restrictive local router which provides some IPv4 connectivity but which drops IPv6 traffic
# credentials for some sort of dedicated local tunnel endpoint (like a SOCKS proxy or an HTTP proxy)
# a remote router offering us some sort of access to a larger internetwork, typically via (perhaps restricted) IPv4
# credentials for some sort of dedicated remote tunnel endpoint (like an SSL or IPsec VPN or a 6to4 tunnel, etc.)
# '''a remote router offering great access to a larger internetwork'''

Based on these scenarios, we imagine our network as being organized into three kinds of composable layers:

# a ''link layer'', usually implemented via 802.3 wired Ethernet, 802.11b/g wifi in either ad-hoc or infrastructure mode, or various sorts of tunneling over IPv4, perhaps across NATs and firewalls,
# an ''internetworking layer'', based on [http://tools.ietf.org/html/rfc2460 IPv6] ([http://tldp.org/HOWTO/html_single/Linux+IPv6-HOWTO/ tutorial documentation]), and
# a ''naming'' layer, based on [http://tools.ietf.org/html/rfc1034 DNS], for binding logical addresses from networks with different failure modes to stable human-memorable names

We find this layered conceptual model helpful for estimating dependency ("what has to work before this layer can work?") and cost ("what does it cost to traverse this layer?").

== IPv6 Configuration ==
== IPv6 Configuration ==
Prerequisite concepts: [[Network2/Concept/Peer|peer]], [[Network2/Concept/Server|server]], [[Network2/Concept/IPv6|IPv6]], [[Network2/Concept/Link|link]], [[Network2/Concept/Router|router]], [[Network2/Concept/Prefix|prefix]], [[Network2/Concept/Tunnel|tunnel]], [[Network2/Concept/dnshash|dnshash]]


'''Peers:'''
'''Peers:'''
Line 48: Line 26:


== DNS Configuration ==
== DNS Configuration ==
Prerequisite concepts: [[Network2/Concept/Server|server]], [[Network2/Concept/Discovery|discovery]], [[Network2/Concept/Presence|presence]], [[Network2/Concept/Authentication|authentication]]


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 peers.
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 peers.
Line 63: Line 42:


(NB: In order to perform this update, it will usually have been necessary for the peer to have been cryptographically introduced to the server.)
(NB: In order to perform this update, it will usually have been necessary for the peer to have been cryptographically introduced to the server.)

== Unfinished Ideas ==

==== Security ====
This ''optional'' section is included merely to offer some hints about where we think communications security ought to be headed.

# Spoofing, Integrity, Confidentiality. See [[communications security]] and [http://passpet.org/ petnames] for some background. A very rough road along which something reasonable ''might'' lie:
#* Use [http://dev.laptop.org/git/projects/barcode 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 basis with which to configure IPsec security associations.
# System Integrity
# DoS

==== Performance ====

Wad points out that people writing software are probably going to want some help figuring out what routes are ''best'' to use. (e.g. in terms of bandwidth, latency, jitter, integrity, confidentiality, availability, ...)

Latest revision as of 06:01, 29 July 2009

IPv6 Configuration

Prerequisite concepts: peer, server, IPv6, link, router, prefix, tunnel, dnshash

Peers:

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 of your choice.
    • (miredo and openvpn seem particularly easy to configure and hence to experiment with...)
  4. Use dnshash to add guessable link-local addresses to all your interfaces.

Servers:

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

DNS Configuration

Prerequisite concepts: server, discovery, presence, authentication

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

Discovery:

Peers need help locating one or more DNS servers. See RFC 4339 for available mechanisms; pay particular attention to RDNSS discovery.

Update

Here are two approaches for solving the update problem, based on how peers might want to communicate with DNS servers:

  1. Use a DNS UPDATE client like ipcheck or ddclient with shared keys with a DNS server like BIND.
  2. Run a bespoke control protocol over an existing secure tunnel, e.g. something based on with XML-RPC over HTTPS + client certs or on access to a restricted shell over SSH.

(NB: In order to perform this update, it will usually have been necessary for the peer to have been cryptographically introduced to the server.)

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