=== Goal === To solve problems inherent to layer 3 client roaming This is needed because as a wireless user moves between specific nodes, several things change. * Association * Leased DHCP Address * Layer 2 State === Requirements === These would be the absolute basic requirements of each node that was a part of the network. Definitions follow further down. * Node IP Registry * Node Standards for DHCP === Assumptions === TCP/IP Protocol Stack ''Layer n'' refferences are based on the following 4-Layer Model: || Application || 4 || || Data Link || 3 || || Network || 2 || || Network Access || 1 || === Procedure === The following attempts to outline a basic solution that addresses these issues as simply as possible, yet still maintain efficiency and expandability as the wireless cloud grows. '''Client A''' comes within range of ''Node A'' for the very first time. Assuming no previous contact the following should happen automatically, without client intervention. * '''Client A''' establishes Layer 2 connectivity with ''Node A'' (this should be automatic so long as the AccessPoint doesn't use WEP and the clients ESSID is set to either "Any" or "www.personaltelco.net") * After connectivity at Layer 2 is established for '''Client A''' Layer 3 connectivity should be established automatically * DHCP issues a lease at this time, completing the initial steps Once initialized the complete route must be established through further means. This can be accomplished with any Portal system (such as NoCatAuth). The following steps are required when '''Client A''' leaves the coverage area of ''Node A'' and enters the established coverage area of ''Node B''. * Connectivity to ''Node A'' at Layer 2 will be broken automatically, however the ''Node A'' Layer 3 DHCP lease will remain * Layer 2 connectivity will be re-established with ''Node B'' * DHCP information from ''Node A'' will persist until '''Client A's''' lease expires * Once the old lease expires, a new lease will be obtained from ''Node B'' === Details Concerning the IP Registry === The IP Registry will be a central storage point for information concerning the IP assignments for the wireless network. These will be internal non-routable IP addresses as specified in RFC1918. Class A addresses will be in the 10.0.0.0/8 range. Each node will be given some portion of the available addresses. This information will be centrally maintained and kept consistent with the current network state. The chosen method of storage can be any easily updated information distributing medium. An Example of the IP assignments could be as follows: * 10.0.1.0/24 - reserved * 10.0.2.0/27 - Node NNX * 10.0.2.32/27 - Node NNY * 10.0.2.64/27 - Node NNZ * etc... If needed, route aggregation could be obtained by assigning specific blocks to specific regions. === Node Standards for DHCP === Each node will be identically configured with the obvious exception of the specific DHCP address pool which is configured according to information set in the IP Registry Database. Arbitrary standards may be specified that fit each networks specific conditions. It is generally assumed that each stations ESSID will remain the same through out the network (Note: there is still some debate as to whether it is better to have a single ESSID for all AccessPoints or whether to have a slightly different ESSID for each). Example DHCP configuration: * Gateway: 10.0.0.1 * Primary DNS: 10.0.0.2 * Secondary DNS: 10.0.0.3 * Netmask: 255.0.0.0 * Domain: www.personaltelco.net * Lease Time: 600 seconds * Address Pool: Assigned from node IP registry Note on DNS: It has been suggested that Public, routable IP addresses be used for DNS to facilitate accesibiltity to all members of the network. Only adequate testing could determine the best solution. Either may work sufficiently provided the DNS assigned at ''Node A'' works when the client roams to ''Node B''. === Portal Authentication System Requirements === * Ability to authenticate at ''Node A'' and recieve a cookie upon succesful authentication. * Upon Moving to ''Node B'' connectivity is updated at Layers 2 and 3 as explained previously. * Traffic from ''Client A'' will be routed to the Portal running at ''Node B'' * The centralized authentication server will recognize the cookie previously set by ''Node A'' * Authentication information will be updated at ''Node B'' * All traffic will be routed to the public internet as requested At this point a browser is required to re-authenticate at the new node. -- This draft was originally proposed by AdamShand on Fri, 5 Oct 2001 16:58:12, and discussed by other list members over the course of the next few days. It should deffinitely be considered a Work In Progress and any PersonalTelco member is welcome and encouraged to add comments and make appropriate changes. Remember to sign your name to any changes so you can get credit ;). -- EliabHelon ---- [CategoryDocumentation]