Re: IPv6 fc00::/7 — Unique local addresses

Ray Soucy rps at maine.edu
Fri Oct 22 01:39:45 UTC 2010


(Response inline).

On Thu, Oct 21, 2010 at 9:01 PM, Owen DeLong <owen at delong.com> wrote:
>> We've decided to disable SLAAC (State-Less Address Auto-Configuration)
>> on almost all our IPv6 networks and use DHCPv6 exclusively.  This
>
> Ouch... Sounds painful.

Really?  I don't know.  Maybe as a consultant you don't see it, but I
can't run a non-trivial network without having control over which
hosts get an IPv6 address (and knowing which address they get) without
creating a lot more work running around putting out fires.  From a
"buy-in" standpoint, SLAAC was a non-starter, giving people an option
where they could enable IPv6 on a host-by-host basis ended up being
the quickest path to adoption without IPv6 getting a black eye because
of a security issue that couldn't be quickly dealt with, or older
systems (RHEL 3 comes to mind) having an IPv6 bug triggered and
crashing.

IPAM is a critical component of IPv6 for any non-trivial deployment
IMHO, I know Apple disagrees, but OK.

>> allows us to only respond with DHCPv6 to the hosts we want to get an
>> IPv6 address instead of enabling it network-wide and crossing your
>> fingers.  The disadvantage here is that DHCPv6 client support is still
>> limited (OS X has none for example).   The argument is that IPv6 isn't
>> mission critical yet, so we're waiting to see if vendors will come
>> around and include DHCPv6 client support in the future.
>>
> It also means that you are even more subject to the issues of rogue
> RA and RA Spoofing.

How so? We still have RA (with a high priority) that's the only way
DHCPv6 works.  I guess there is a lot of misunderstanding about how
DHCPv6 works, even among the experts...

>> Another thing you want to do is block rogue RA.  RA-Guard is the
>> feature name, but nobody has a working implementation yet.  If you
>> have switches that can do port-based access-lists with IPv6 you can
>> create ingress filters to block out incoming RA on a per-port basis
>> which is what we have done.
>>
> You must have a really hostile user base. I agree RA-Guard is a good
> idea and it does work on some switches. Where it is most glaringly
> lacking is in Wireless configurations, meaning that having a real RA
> is actually a limited measure of protection vs. having no RA.

Again, it sounds like you think DHCPv6 means no RA?  This is not the
case.  I consider filtering RA (accidental or malicious) critical for
any network, regardless of whether IPv6 is deployed or not.

Just above you were complaining about me having problems with rogue
RA... Now you're saying I'm being paranoid?  I know you work for HE
and everything, but really?

If you don't block RA, you can get mis-configured hosts (Windows ICS
comes to mind) hijacking traffic without even knowing about it on
networks that you don't have IPv6 deployed on.  That's the accidental
side, though.

On the malicious side, I consider IPv6 one of todays most effective
attack vectors.  I can easily jump on a network that doesn't even
monitor IPv6, declare myself as a router, advertise myself as IPv6
DNS, and proxy all traffic on a network, often without setting off
alarms.  Remember, hosts by default usually have IPv6 enabled, and
usually prefer IPv6 over IP.  In the case of servers, most
administrators who are diligent about making sure host-based firewalls
are in place completely forget about IPv6, because they haven't
deployed it yet.

Just because you haven't deployed IPv6 doesn't mean it's not running
on your network.

This is especially true in an academic setting where people bring
their own computers on to your network.

Not filtering rogue RA seems a little insane, IMHO.  I'm still shocked
that RA-Guard hasn't become the default in modern switching... but if
you don't think it's a problem, that works too.

What are the odds that there will be a virus, worm, or tojan that
decides to turn infected hosts into IPv6 routers, anyway...

I really don't buy the argument that "advertising IPv6 yourself with a
high priority will mitigate the impact of rogue RA".  As mentioned,
DHCPv6 still requires RA to work... by design, so your point is moot.
But regardless, that mindset only protects against accidental rogue
RA, not malicious RA, which is a significant security threat and
_should_ be filtered as a best practice when possible.

I would go as far as to argue it's worth pushing up switch upgrades to
make sure you have hardware capable of doing so, but maybe I am just
being paranoid.

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/




More information about the NANOG mailing list