Network2: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 3: Line 3:
== Protocols ==
== Protocols ==


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]. The main reason is its large address space, conceptual clarity, ease of tunneling, and low incremental cost of adoption by both deployments and ISPs.
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]. These choices are motivated, as described in the Network Principles document, by:


* the end-to-end principle,
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.
* the desire for unique, memorable, human-readable addresses that resolve to several potentially accessible logical addresses
* the need for conceptual clarity and tractable bandwidth models,
* their low incremental cost of adoption by application authors, deployments, and ISPs, and
* for the beneficial "network effects" that they provide, particularly with regard to existing and future Linux networking software and debugging know-how.


A couple of key facts and expectations inform the rest of this design, like:
For this reason, [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]) may be particularly effective.


* hosts will have multiple interfaces,
== Client IPv6 ==
* 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.

Notes:

* these expectations suggest that [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]) may be particularly appropriate for new software being tailored for our environment.
* you should definitely start asking your ISPs to provide IPv6 routers. After all -- if none of their customers ask, then what incentive will they ever have to upgrade?

== Client IPv6 Configuration ==


Your job is to be an IPv6 node. Consequently, when you bring up your interfaces,
Your job is to be an IPv6 node. Consequently, when you bring up your interfaces,
Line 20: Line 35:
# Use [[dnshash]] to add guessable link-local addresses to all your links.
# Use [[dnshash]] to add guessable link-local addresses to all your links.


== Server IPv6 ==
== Server IPv6 Configuration ==


Your job is to be an IPv6 router and a [http://tools.ietf.org/html/rfc1035 DNS server]. One of several situations might obtain:
Your job is to be an IPv6 router and a [http://tools.ietf.org/html/rfc1035 DNS server]. One of several situations might obtain:
Line 31: Line 46:
When done, use [http://www.litech.org/radvd/ radvd] or [https://fedorahosted.org/dhcpv6/ dhcp6d] to share addresses.
When done, use [http://www.litech.org/radvd/ radvd] or [https://fedorahosted.org/dhcpv6/ dhcp6d] to share addresses.


== Server DNS ==
== 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.
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.
Line 40: Line 55:


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

== Optional: Server Tunnel Configuration ==

== Optional: Server VPN Configuration ==

Revision as of 02:16, 16 July 2009

This page proposes a fresh design for network configuration in a highly collaborative world, based on Scott's Network Principles.

Protocols

We take IPv6 and DNS as the basis of our system and rely heavily the Linux Documentation Project's IPv6 documentation. These choices are motivated, as described in the Network Principles document, by:

  • the end-to-end principle,
  • the desire for unique, memorable, human-readable addresses that resolve to several potentially accessible logical addresses
  • the need for conceptual clarity and tractable bandwidth models,
  • their low incremental cost of adoption by application authors, deployments, and ISPs, and
  • for the beneficial "network effects" that they provide, particularly with regard to existing and future Linux networking software and debugging know-how.

A couple of key facts and expectations inform the rest of this design, like:

  • hosts will have multiple interfaces,
  • interfaces will have multiple addresses,
  • DNS queries (used via getaddrinfo()) will return multiple results
  • these results will be sorted in a 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.

Notes:

  • these expectations suggest that SCTP (wikipedia, man page) may be particularly appropriate for new software being tailored for our environment.
  • you should definitely start asking your ISPs to provide IPv6 routers. After all -- if none of their customers ask, then what incentive will they ever have to upgrade?

Client IPv6 Configuration

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

Server IPv6 Configuration

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.

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

Optional: Server Tunnel Configuration

Optional: Server VPN Configuration