Re: howto WLAN, several subnets
On Fri, Nov 21, 2003 at 05:29:15PM +0100, Joel Jaeggli wrote: So instead of forcing key+essid on the clients, would setting the AP's MAC address on the clients be a solution? not really unless you want to want to be associated with one of 30 aps for the entire conference... The problem I ran into was seeing a number of IBSSs, most of which seemed to be using unallocated mac addresses. Unfortunately I did not keep any notes of what I acutally did see. I wished I could have told my 4.8 FreeBSD system to only associate with one of a list of APs. I would have given it a list of all of the real APs and told it to only choose one of those. Wildcarding might have also been useful - I would have done (say) two mac address ranges the real APs were using ignored the rest. [EMAIL PROTECTED] (Andrew Partan)
Re: IETF58 - Network Status
On Thu, Nov 13, 2003 at 07:57:33PM -0600, Harald Tveit Alvestrand wrote: so rather than worrying, let's see what we can do to help if someone - for instance - has EFFECTIVE tools for triangulating and locating ad-hoc stations, perhaps they can bring them to the next IETF meeting? Another suggestion - it would have been real useful if the software on my laptop could have been told to ignore some APs (or some other laptops pretending to be APs), or to only listen to this other set of APs. White/black listing of APs... --asp
Re: IPv6: Past mistakes repeated?
address space shortage is just one of many possible problems. as long as the network keeps growing at exponential rates we are bound to run into some other major hurdle in a few years. it might be address space but the chances are good that before we hit that limitation again that we will run into some other fundamental barrier. The problem some of us have been worring about is the routing table. The routing table can either fill up or be overwhelmed by the rate of change of routing entries. There is a tradeoff between these two - no changes means that you can have a large static table; lots of changes and you will need a smaller table to have stability. Unfortunately its hard to predict when you will tip over... [EMAIL PROTECTED] (Andrew Partan)
Re: draft-ietf-nat-protocol-complications-02.txt
On Mon, Apr 24, 2000 at 04:32:38PM +0200, Sean Doran wrote: Therefore, in order to support IPv6 house-network multihoming, so as to preserve at least these three features of traditional multihoming, either the current IPv6 addressing architecture's restrictions on who can be a TLA must be abandoned (so each house becomes a TLA), or NATs must be used to rewrite house-network addresses into various PA address ranges supplied by the multiple providers. Or seperate the end system identifer from the routing goop. This solves lots of problems (while introducing others). [EMAIL PROTECTED] (Andrew Partan)
