On Sun, 2012-10-21 at 17:54 -0700, Mark Smith wrote: > > network. Mitigation would need filters everywhere, just in case. > True, however you also have the same sort of vulnerability issues to rogue > DHCP servers.
Unicast queries go only to the correct servers. Rogues don't get a look
in - except on the single link they are actually on, and filtering
doesn't help there (except on the hosts themselves, I suppose, which
doesn't scale well). You could automate the detection of rogue DHPv6
servers by snooping on MLD - they have to add themselves to the two
DHCPv6 multicast addresses. It'd be an interesting feature to add to
switches, and probably fairly trivial since an IPv6 aware switch already
does MLD snooping...
> Well, the same multicast address would be used on the relays' configurations,
The default for a relay is to send to a well-known site-local multicast
address. No config needed at all. RFC3315:
20. Relay Agent Behavior
[...]If the relay agent has not been explicitly
configured, it MUST use the All_DHCP_Servers multicast address as the
default.
You could put a *different* multicast address on the relays, provided
the servers can be configured to support it. However, I reckon unicast
is a better idea, so I'd be interested in the experience of anyone who
has actually tried the multicast method.
> so they'd all be the same. The drawback of unicast is that the relay
> target DHCPv6 server becomes a single point of failure.
You configure the relays with a list of unicast addresses, just as you
do IPv4 "relays" now. No SPOF. RFC3315 again:
20. Relay Agent Behavior
The relay agent MAY be configured to use a list of destination
addresses, which MAY include unicast addresses, the
All_DHCP_Servers
multicast address, or other addresses selected by the network
administrator.
> you could use or whether it would be wise to use an anycast address as a
> DHCPv6 server address in that scenario.
Actually I'm not sure anycast would work, I haven't thought about it
enough yet ;-) I think there would be issues if failover ever gets
reimplemented for IPv6.
Regards, K.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog
GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
signature.asc
Description: This is a digitally signed message part
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
