This work overlaps with that of the [RFC], but approaches from a different angle. !! Scope This document specifies an architecture to support a community Internet Protocol network that heavily utilises IEEE 802.11 Wireless LAN technology for connectivity. !! Requirements. __Connectivity__: need to provide IP connectivity between sparsely scattered nodes to begin with. Later deal with higher levels of density. Support subnets behind attached clients and single host clients. Manage network resources in a 'fair' manner that recognises the investment by infrastructure owners. Support end-to-end security of selected communications across the network. __Scalability__: engineer to support ~ 1000 node. Clear evolution paths to higher number of nodes. __Performance__: provide efficient use of radio resources, shared in a 'fair' manner that is not open to abuse. Utilise wireless LAN commodity hardware and homebrew antenna to provide infrastructure. Support ruggedised low cost nodes capable of outside mounting and feasibly shared to assist in line of sight connectivity in sparse environs. Support higher capability nodes (that might for instance be found within a house) mixed with low cost nodes. !!! IP Networking Technologies. * IPsec, CIPE * IPv4/IPv6 mix * OSPF? * Diffserv * Secure DNS !!! Issues * Addressing * Resilience to DDoS * Security * Connectivity without requiring too many interfaces at a node. * Channel plans * Antenna configuration * Routing ! Outline Seattle wireless has the concept of (A|B|C)xNodes (http://www.seattlewireless.net/index.cgi/AxNode). This is perhaps required for a longer term network architecture, but the requirements make it difficult to build minimum expense access points that can link to the grid initially. The concept described here attempts to present a peer-to-peer architecture with no initial levels of hierarchy. !! The minimal node The basic node consists of a Linux router with either an 802.11 AP connected via an ethernet or a directly attached 802.11 interface. This node has two functions * to connect to the Melbourne Wireless WAN * to offer connectivity to local nodes ** that might be wired ** or wireless The complicating factor with a minimum node is that we attempt to use the same wireless interface to provide support for both local wireless clients, and connecting to distant Melbourne Wireless nodes. !!! Wireless interface mode of operation Two choices: we can run it in IBSS or BSS mode. If we run in IBSS mode * can connect to remote instances of this same type of node * local clients must also run in IBSS mode * cannot really support a normal access point on the end of an ethernet - although the [OpenAP] is a different matter. If it is run in BSS mode * cannot connect to remote instances of this type of node in an ad-hoc fashion; instead the node most be configured to 'bridge' to other nodes on a node-by-node basis (if it is even possible) * local clients can run in the normal BSS mode as found in normal enterprise installations of wireless LAN (less fuss in configuring wireless clients) * can support access points on the end of an ethernet connected to the router box !! To be continued.. * Using whois as a network information repository like APNIC et. al. * Benefit of (globally unique) IPv6 based services when interconnecting community WANs with NAT and Internet wormholes * Benefit of IPv6 A6 chain records for hierarchical reverse DNS and renumbering * Conversely the problem of allocating out /28s and inverse DNS delegation