I think there's quite a bunch of issues, and I'll just try to list a few...
1. Make sure a mesh/community network can grow up to whatever size it's supposed to grow, and still work. This by itself it not necessarily as easy as it seems. A network with 5, 10 or even 50 nodes is fine. A network with hundreds or thousands of "nodes" (non terminal ones) and even more clients is a lot more fun. Just this implies having a correct routing design, the right protocols used, route aggregation, etc. This by itself requires coordination.
2. Make sure that when two meshes that worked well independently finally "meet", the whole thing still works, and works as a single network without the need for a full re-engineering of each of the networks. This requires at the minimum unique IP addresses, at best coordination in routing, addressing (so that IPs are not only unique, but also aggregatable, for instance). Quite a bit of coordination again.
3. After that, you have the Internet access issue. I do agree that NAT is just evil (it's very nice in a lot of situations, but not here), so proper routing is necessary, and that means real IP addresses, BGP, and the like.
Honestly, the only option I've come across that I think might work (which I already stated before) is to do the following:
- create an organization that will manage the whole thing (or one per continent, at least).
- the organization should become a LIR (Local Internet Registry), registered with the relevant RIR (Regional Internet Registry, that's ARIN, RIPE, APNIC...)
- it then gets (at least) one AS, and address space (the current minimum is a /18)
- it also needs to have one or more sites (preferably in some colo space with a lot of connectivity) with an appropriate router, and a transit connection with whatever ISP(s) can be found. Of course, free peering on all available IXes is a good thing too.
[basically, until now, that's just a new ISP I described]
- now, the organization hands out the IP addresses (either individually to nodes, or by chunks to local networks)
- the local networks get whatever Internet connection they can, and use IPsec tunnels (or any other kind of tunnel) to "connect" to the colo routers mentioned above, or WLAN links to connect to each other.
- in short, it's a big network, with links between nodes that are either IPsec tunnels via the "wired" Internet or wireless links directly between nodes.
- connectivity to/from the Internet always goes through the colo routers.
Et voil�! You've got an extension to the Internet that follows all current rules for IP allocation, routing, and so on, with fully public IP addresses. Some parts of it are an "overlay" on top of the wired Internet, but if you do it properly, no-one will notice. That means that all your local networks are actually already interconnected from the start, and you only need to re-arrange routing when you finally get direct wireless links between them. Not necessarily trivial, but should be doable if the whole network design is done properly.
Yes, there are costs to do all this. Probably N x 10K euros/USD a year, plus setup and hardware. But you can use that for a whole continent, so the cost per head can be really low. Just need critical mass to start. And a little bit of thought on the engineering side to make sure the whole thing works, but that's really not that hard with a little experience.
Of yes, you can skip the "become a LIR and ask stuff from a RIR" step and try to become a RIR directly (i.e. get a BIG chunk of address space from IANA directly), but I wouldn't wage any money on that, and you'd probably have to pay something anyway.
Jacques.
At 10:31 05/04/2003, Julian Bond wrote:
Reading the various discussions here, on meshap, and consume.net I'm convinced there is a real issue here. I'm also becoming convinced that it's hard.
First the environment. With Meshnetworks, Locustworld and others we're seeing the emergence of technology that makes it comparatively easy to link WLANs. Initially this will be a whole load of small scale experiments with two or three APs linked at a time. But there will be local pockets where we get a sudden "Mesh Disease" outbreak, and the borders of many pockets touch, creating meshes with 100s of APs. This is the epidemic model in disease transmission where isolated hotspots merge to become a pandemic. At this point, a client device talking to another client device within this meshed area have got numerous alternate potential routes between them. Some are purely within the mesh, some go via gateways in and out of the wider internet. Similarly, a meshed client device talking to a server somewhere on the internet may also have multiple potential routes through the mesh and then through multiple mesh-internet gateways.
Now the admin problem. As long as the pockets are small and involve closely linked administrators who know each other, then sorting out the routes and NATing all the client devices using a consistent IP address range is do-able with just the cup of tea protocol. We all sit down round a cup of tea and argue it out. The moment we break out and start involving unknown admins across a wide area we need some method of coordination. On the wider internet there are well defined rules and processes in a hierarchical structure for doing this.
I think WLAN meshing introduces a new issue that hasn't been seen on the internet before. The edges of the network are now involved in routing outside their control area. And the owners are not part of the hierarchy, are not part of any commercial or non-commercial organization and are acting independently. The trad approach is for your own little island of control to be NATed into a single point of contact with the mainstream internet through an organization that plays by the internet rules. Link all those NATed islands together behind the gateway and there's a fundamental change.
This has parallels with the growth of alternate namespaces such as IM, SIP, gnutella/napster/kazaa, Groove, H232. In each of those cases, the NAT boundary had to be modified or else relay-name servers had to be created to handle the cross NAT traffic. The solutions are usually at the application level and not the network level. This is a sub-optimal kludge and not very scalable, but it does work. In Meshed WLANs, we really don't want that level of overhead.
It looks to me like WIANA was created by Locustworld because they had to have something. It's not a general solution, it's a kludge but for now it does work. Jon has said that they were unable to get a suitable IPv4 block allocated to them. He's also said that they couldn't get a suitable IPv6 block allocated either. If this is all true, and I have no reason to doubt him, then the current system is broken and cannot cope with the new Meshed WLAN architecture.
So how to move this forward? I can understand an IETF view that there is nothing new here and the existing protocols handle the situation. Therefore there's no need for any IETF work. I can also understand the frustration because the current social-political way of implementing those protocols doesn't allow for the new situation. Expecting ICANN to pay attention to this is likely a non-starter given their current disarray. Particularly when the people and groups pushing back this boundary are small and/or loose confederations of programmers.
So all I've done here is describe (probably imperfectly) the current problem. Has anyone got any solutions?
-- Julian Bond Email&MSM: [EMAIL PROTECTED] Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ CV/Resume: http://www.voidstar.com/cv/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 -- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless
-- Jacques Caron, IP Sector Technologies Join the discussion on public WLAN open global roaming: http://lists.ipsector.com/listinfo/openroaming
-- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless
