Network2/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:

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

1. 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,
2. an internetworking layer, based on IPv6 (tutorial documentation), and
3. a naming layer, based on 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?").