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
