← Revision 4 as of 2005-03-09 03:02:01
|Deletions are marked like this.||Additions are marked like this.|
|Line 98:||Line 98:|
|HyipInvestment EgoldEcurrency GetRich MakeMoney MlmAndDownlines ForexTrading WorkFromHome HomeBusiness OnlineInvesting SafeInvestment|
To solve problems inherent to layer 3 client roaming
This is needed because as a wireless user moves between specific nodes, several things change.
- Leased DHCP Address
- Layer 2 State
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
TCP/IP Protocol Stack Layer n refferences are based on the following 4-Layer Model:
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
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 ;).