Hosting provider allocation advice

Bernhard Schmidt berni at birkenwald.de
Fri Oct 16 14:23:39 CEST 2009


Hi Wouter,

> What holds me a bit back though is the use of link-local.

It is done because of two things:
* systems that don't have a global IPv6 prefix routed do not have a 
global address at all, thus they cannot speak outside
* if you use private VLANs your customer boxes can only speak to each 
other using the router. Since there is no transfer network they won't 
see any (global) address as directly connected, using the router all the 
time.

> This would indeed mean that our customers need to manually specify the
> link-local address of our router, but if we'd swap interfaces, our
 > link-local would change.

You can usually set the link-local address of the router to be something 
like FE80::1. With HSRPv6 this is even a necessity.

You have to differentiate between two things here:
* Traffic routed to the customer is sent to his link-local address, 
which should not change without an equipment change (changing MAC), 
which you hopefully have to know/record anyway (port security).
* Traffic sent by your customer to your link-local address, which should 
probably be set to be device-independent

> So RA comes indeed into the picture.
> However.... just as with DHCP, you'd need to ensure that only _our_
> equipment can send RA ?
> This can't be enforced I think, without heavy support in your
> access-switches ?
> So if a server receives 20 RA's, which one does it pick ?

A random one.

There are tools that can snoop into a VLAN and react on rogue RA by 
spoofing a matching one with timers set to 0, but that is only a band-aid.

Totally regardless of how you manage your routing (to link-local or 
not), if your customers can send RA to each other you are just screwed. 
But if they can send traffic to each other you are an easy target for 
spoofing attacks anyway. So you are just having the very same security 
problems you already have with IPv4 with IPv6 as well.

> Also, we don't have support for private vlans in our access-switches at
> the moment.

It breaks my hard to say this, but doing native IPv6 in a shared VLAN 
without any security features is very likely a very bad idea. You should 
consider tunneling the last hop if you cannot solve that.

Can your equipment do MAC ACLs? You might be able to filter IPv6 frames 
sent to 33:33:00:00:00:01. At least unsolicited RAs won't get through 
this way, you probably have to do something about solicited RAs as well.

> (Yes, we probably need new equipment :>)

I'd say so, yes, but also for IPv4.

Bernhard


More information about the ipv6-ops mailing list