[CUWiN-Dev] RADVD and Domain Names

[Quantum Scientific]

On Wednesday 09 March 2005 19:35, David Young wrote:
> I doubt that name assignment is part of router advertisement, since
> that would be a stateful extension to a stateless protocol.  Router
> advertisement is a stateless protocol.  The router does not actually
> assign anybody an IPv6 number, it just advertises prefixes.  Hosts make
> unique IPv6 numbers by tacking an advertised prefix to the front of
> their EUI64---it is the host's responsibility to ensure uniqueness.
> If the router was going to assign names, it would have to remember which
> names it had assigned already, so it wouldn't be stateless any longer.

Ah!  You're right, I'd forgotten RAdvD is stateless.  Very nice.

 
> BTW, there is something called DHCPv6.  That may be what you're after.
> 
> Dave
> 
> [*] Really, you want to auto-configure a host name with the help of the
>     nameserver, not the router.

I was hoping to avoid another major overlay and depend on inherent IPV6 
characteristics, but maybe this isn't possible at a low level.

What I'm trying to get at is a meshed cloud where the gateway knows who is 
who.  So that when a given client associates & authenticates, their name in 
the cloud domain is pre-determined and assigned, correlated with MAC and 
location, but in your other email I see you already have thoughts on this.  
With most meshing systems, it is rather hard to identify who's doing what in 
the cloud, much less to route virtual domains.


> I don't know too much about UPnP.  Maybe somebody can give me a 
> 10,000-foot overview of what it does, whether it's open, and how/
> whether it's important?  

I don't know much about it either, but I do know that no one uses it, most 
firewalls block it, and it has serious security vulns.  For clients' own 
protection we will block uPnP.  Maybe even ad/spyware block with the 
hosts-127./::1 trick, en/disabled by web interface.  Comcast blocks only 
ports 67, 68, 135, 137, 138, 139, 445, 512, 520, & 1080.

I'm working on an ip6tables firewall script, which I will then propose to the 
project.  Only thing missing at the moment is stateful filtering (due to the 
primitive Linux IPV6 stack).  Perhaps this could easily be ported to 
whichever BSD packetfilter is used.

WRT your Alice example, I now understand your thinking better.  We are 
planning pure IPV6 down to the client, meaning every machine with a public 
IP, and no NATting.  Of course client machines will not be secure, and so I 
was planning to firewall at the gateway level, but I see you're pushing 
firewalling down to the node level.  I doubt firewalling here would reduce 
mesh traffic, but it is in keeping with the IPV6 plan.  Maybe you see the 
gateway more as just a bridge.  Only drawbacks I can see in reducing the 
gateway's role are, it would decentralize/complicate administration & 
updates, and nodes' memory may be too limited for name & web object caching 
daemons.  There would still need to be a central authentication server.  
Decentralization would make multiple gateways easy though.

I doubt 95% of users will understand setting pass/block rules;  they may cause 
service requests, by blocking a port and forgetting about it when they need 
it.  There are some wonderful features available through web interface in 
wireless routers, but most users don't know they exist.  So most ISP's set up 
a system and listen for complaints.  I guess the user should have some 
control, but I suggest it be patterned after the nice web-based controls in 
the Belkin F5D8230.  

This is one helluva router in all the important ways;  I've tested it 
thoroughly (with the exception of VoIP) and it is superb.  >4 Mb throughput 
at 3.3% link quality (48%/44% s/n)... I can't test for higher throughput, as 
this is Comcast's limit.  May eliminate the need for two radios, although I'm 
trying to find out tech details on it now.  It's the Airgo MIMO (pre-802.11n) 
reference design.  No one makes a miniPCI yet.

Carl Cook