'''Acronym Definition: Request For Comment''' Melbourne: Digital and Wireless Networking RFC Original by StevenHaigh - netwiz@optushome.com.au edited by DrewUlricksen Please comment in section 8. Contents: * [#1__acknowledgements 1. Acknowledgements] * [#2__equipment 2. Equipment] * [#3__ip_addressing 3. IP Addressing] * [#4__ownership 4. Ownership] * [#5__application_for_ips 5. Application for IPs] * [#6__routing___allocation 6. Routing & Allocation] * [#7__naming_convention 7. Naming Convention] * [#8__comments_ 8. Comments?] ! 1. Acknowledgements This page and it's contents are prepared by Steven Haigh for the Melbourne: Digital and Wireless group. All portions are subject to change and are for discussion on the Melbourne: Digital and Wireless mailing list or wiki ! 2. Equipment All equipment will be 802.11x based ! 3. IP Addressing All participating nodes will be assigned an address range. The assigned address range is allocated in relation to your location, the number of nodes near you, and the number of points you are hosting. The minimum number of IP's that will be allocated per node is 16 (using a 255.255.255.240 netmask). More IP addresses will be allocated to people who link to more than one person on an "as needed" basis according to the number of persons to be linked. The addresses will be in the 10.x.x.x range, and is yet to be determined. Comments from the mailing list will be acknowledged and considered. IPv6 will not be used due to lack of support and versatility. Check out the working group for up to date info [WGRoutingAddressing] ! 4. Ownership All equipment will remain the property of the node owner. The maintenance and legalities of the equipment is the responsibility of the node owner. No responsibility is taken for any nodes by Melbourne: Digital and Wireless. ! 5. Application for IPs IPs are not yet available until the addressing scheme is finalised. ! 6. Routing & Allocation The diagram in below is typical of a section of the Network. {http://www.wireless.org.au/rfc/routing.jpg routing} In this example, Node A will be allocated 4 ranges (with more ranges reserved for later expansion). Node A will typically use an AccessPoint in [BSS] with an OmniAntenna to serve clients. The link between nodes A and B will be using directional antenna connected to an [IBSS] card. Node B's client will be connected via whatever methods capable - preferably with an directional antenna connecting to an AccessPoint. Node B will be allocated 2 ranges with more reserved for later expansion. Node C will be connected to Node B via [IBSS] via a directional antenna. It will be allocated 1 range, and other ranges will be reserved for future expansion. A range is defined as a subnet of 16 IP addresses assigned by Melbourne: Digital and Wireless. Ideal hardware requirements: %%% Node A: AccessPoint, PCMCIA/PCI card, OmniAntenna, ParabolicAntenna %%% Node B: AccessPoint, 2 PCMCIA/PCI card, OmniAntenna, 2 ParabolicAntenna %%% Node C: PCMCIA/PCI card, ParabolicAntenna %%% ! 7. Naming Convention Nodes will all be named x.suburb.mlbwire.wan If more than one node exists in a suburb, a digit will be added to the suburb name. 'x' may be anything. All major nodes must be registered with the DNS Administrator - who will keep a database available on the site detailing the hardware used and link type/speed. Nodes will use an SSID of wireless.org.au ! 8. Comments? TysonClugg comments: * General ** Plenty of comments seem to be collecting but not much has changed... is there a schedule for review of this document? * Section 3 ''"IPv6 will not be used due to lack of support and versatility. "'' ** I can see no reason why IPv6 should not be used, providing that ''all'' nodes implement IPv4. ** ''Versatility.'' IPv6 is far ''more'' versatile than IPv4, in every sense of the word. I believe this statement is factually incorrect. * Section 7 ''"Nodes will all be named x.suburb.mlbwire.wan"'' ** One of the attractions of wireless technology is that you are free to ''move''. This statement suggests that all nodes have a fixed position. Am I the only person who will have a mobile node ([NodeDCG])? (good point, maybe you could replace "suburb" in your case with "mobile" -- DrewUlricksen) NeXuS comments: * Future adoption of UWB if it becomes popular and cheap? * Section 7 with regard to DNS names, could we simply have dcg.melbwire.wan for Node DCG as well as a suburb dns for those of us who are fixed nodes? (you can have as many forward DNS' as you want, but reverse should resolve to the suburb, so a tracert will show physically where your hops are going) Jeremy Lunn comments: * More thought needs to go into routing. [Zebra OSPF] (Open Shortest Path First) sounds like the best solution as it provides dynamic routing that is capable of doing load balancing between different links. (how about RSPF or mobile mesh?) Kim comments: * RSPF is for AX25 radio networks, * MobileMesh is very suited to this network, currently only runs on Linux, * ISISs is suited to mesh networks, and may work well for fixed wireless infrastructure, * OSPF [Zebra] is well suited to joining isolated network segments, different media types and low bandwidth links, * MobileIP should be avioded for system wide routing. It is fine for user and application systems. Works well for mobile clients, but not for fixed wireless infrastructure. Forces fixed node operators to run MobileIP agaents. RogerVenning comments: * IPv6 can function as either an overlay network or natively over links ** if as an overlay network, can automatically use 6to4 (for an explanation see (http://www.feyrer.de/NetBSD/6to4.html RFC 3056)) to get a /48 block of addresses (that is a prefix starting 2002:IP:v4::) ** However you shouldn't really be using RFC 1918 address space (ie. the 10.0.0.0/8 address range) as the source of the 'unique' IPv4 address for the 6to4 mechanism ** as a native network, either IPv6 address space must be obtained from (http://www.apnic.net APNIC) ** or alternatively we can begin with just site-local address space - fec0:: ** and have a global 2002:: prefixes distributed from points that might connect to the 6Bone into the network ** this means that the site level addressing hierarchy within (the sixteen bits after 2002:IP:v4::) needs to be hierarchically distributed. This problem is __exactly__ analogous to the difficulty in breaking up IPv4 address space to hand out to nodes. The only subtleties here are that we have more bits to play with effectively. * Routing ** routing protocols generally advertise reachability ** all candidates support variable length subnet masks ** efficiency considerations drive a desire to have hierarchical routing structure *** allowing for route summarisation *** which limits the number of routing table entries present on a node *** and limits the extent to which routing updates must propagate across the network ** However the class of routers that we are considering could easily handle numbers of routes in the orders of thousands ** If mobile hosts are excluded (the IGP should not handle mobility; specialised mobility protocols such as mobile IP should be used) then the remaining hosts are relatively static; link lifetimes should hopefully be in the order of days. This implies that with a thousand links, routing updates across the whole network would still ony imply a load of one update per minute - well within the processing capability of the style of routers presumed as well. * Domain Name System ** A set of root servers will need to be selected to populate other servers cache file ** Alternatively, to allow interoperation with pre-existing DNS roots, we can simply have well connected servers pretend to be authoritative for mlbwire.wan that are assigned as DNS for all connected hosts & clients. In this circumstance these servers could forward requests to the real DNS roots appropriately SimonMudd comments: * Look also at a (http://www.wl0.org/wireless/network-structure/english/article.html "local" document) I produced, originally in Spanish for the Spanish wireless groups. * I hope to incorporate this and other documents into a global RFC with comments from different members of the wireless communities. clae13@yahoo.com comments: * i propose x.mobile.mlbwire.wan or x.roaming.mlbwire.wan as variations on x.suburb.mlbwire.wan px-wl at psykax.com comments: * i know its not that important... but mlbwire.wan? its easier on my brain for it to be melbwire.wan or melwire.wan {/regexpicons/emoticons/emoticon-face1.png :)} midway2purgatory@hotmail.com comments: * If this is an australia wide project, hence the domain. I think it needs to be more along the lines of suburb.city.wireless.org.wan rather than making it very melbourne centric.. sneeze^at^alphalink.com.au * Despite the domain wireless.org.au I don't believe we shouldn't be, nor need to be, thinking outside the borders of Victoria at this stage simply because I believe most interstate groups are in the infant stages as well, and the idea of us stomping up and saying, "here is the domain we're all going to use", is not a terribly good one. Heck I'll setup a domain on the wireless lan for www.microsoft.com if I feel like it...though I may get in trouble from a legal perspective {/regexpicons/emoticons/emoticon-face3.png ;)} [DanFlett] - 22/03/04 * nodexxx.mwn seems to have been settled upon, at least everyone on the list I have written to agrees to this. But I see no reference to this in this RFC. What happened to the discussion here? Did it move to another wiki page? Or did it occur via email? However, some of us in the RGSouthern Cluster of nodes are using nodexxx.mw.wifi. I personally quite like this system. Perhaps we could put the various systems up to a vote at a MW meeting and get this long-festering issue out of the way. {/regexpicons/emoticons/emoticon-face1.png :)}