Network2: Difference between revisions
mNo edit summary |
mNo edit summary |
||
Line 3: | Line 3: | ||
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. |
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. |
||
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 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. |
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. |
||
These features combine to provide a particularly good user experience for RESTful protocols. |
These features combine to provide a particularly good user experience for RESTful protocols. |
Revision as of 05:46, 15 July 2009
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.
We take IPv6 as the basis of our system and rely heavily its documentation for Linux.
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 getaddrinfo()) will return multiple results sorted in a 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.
These features combine to provide a particularly good user experience for RESTful protocols.
Client IPv6
Your job is to be an IPv6 node. Consequently, when you bring up your interfaces,
- You might discover an IPv6 router advertising on one of your links.
- (See sysctl net.ipv6.conf.all.accept_ra and related variables.)
- You might try out dhcp6c.
- You might have some kind of IPv4 connectivity. If so, connect to the Internet or to other internetworks of your choice.
- 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:
- 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, connect to the Internet or to other internetworks of your choice.
- You might be under a tree. If so, generate a Unique Local Address prefix.
- (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 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.)