Operational comments on RAs vs DHC

[Tim Chown <tjc@ecs.soton.ac.uk>]

Hi,

Please don't shoot the messenger, but there was one v6ops related topic I 
was hoping to bring up this morning but for which I wasn't able to prepare
some discussion slides.

The mail about 'rogue' Router Advertisements at the IETF reminded me.

A number of administrators that I know of deploying IPv6 (dual-stack) have
commented on a common problem, specifically the problem of handling 'rogue'
RAs in their networks.   This includes one admin at our site.

We typically see the problem in our wireless networks, where perhaps a 
user brings in a laptop that's set to be a 6to4 router at home, but shouldn't
be one on our wireless.   But we also have seen it where an admin makes
a config error typically in a VLAN config and one or more RAs leak to
additional subnets/links.   Use of VLANs seems to be rising, and mistakes
maybe more common.

The general problem is how to control the rogue RA, and/or to recover from
a misconfigured state should that arise.   One of the worst cases is probably
an additional (unwanted) RA sent with infinite lifetime.

There are various tools that could be used to mitigate rogue RAs, e.g.
- Use of SEND (as and when it's implemented)
- Vendors adding RA snooping to L2 devices (doesn't help shared media though)
- Using a higher precedence RA (assuming hosts/routers support it)
- Requiring L2 authentication, e.g. 802.1x (but that doesn't help against
  unwitting users)
- Using RA authentication (but then who does DHCP auth today?)
- Using host-based packet filters (but these need configuring)

There really isn't a readily deployable countermeasure today, and I think
that's causing mild unrest with admins.   Of course, one can just wave the
issue away saying it's no different to rogue DHCP servers, though at least
there is DHCP snooping on some L2 equipment.

The related issue is whether certain timers that have been standardised 
are appropriate in the face of deployment experience.   Recovery from
an administratively configured 'errant' RA is another consideration.
The above measures may be of no benefit if the 'trusted' party messes up.
However one could also say a similar issue exists today for a host getting
a bad DHCP lease for a period should a DHC server be misconfigured.

What I hear is some admins wanting an environment for IPv6 deployment that
they're comfortable with with IPv4 today, i.e. DHCP.   So they'd use DHCPv6
for address configuration.  No problem.   But they also ask 'why not use 
DHCPv6 for default router configuration?' - they would seem to like a 
trust model in their network that they're already familiar or comfortable 
with.   Whether it's a safe model is another question, but they're asking.

I also heard this morning of a site using manually configured default
routes on hosts to avoid the rogue RA problem.

Maybe vendors are already working on L2 RA snooping, but that doesn't help
wireless environments.   The higher precedence (rfc4191) could be used as
a defence against unwitting users, assuming there is host (or router)
support.

One concern here is there may be a push to define a default gateway option
(and maybe MTU option) for DHCPv6 if the people I have heard from are
typical of other admins.   

Is there a WG viewpoint on the practical short and long term solution to
this problem?

-- 
Tim