Hi Karl,
----- Original Message ----- > From: Karl Auer <[email protected]> > To: [email protected] > Cc: > Sent: Monday, 22 October 2012 10:52 AM > Subject: Re: Announcing Prefix Delegation extensions to ND > draft-kaiser-nd-pd-00.txt > > On Sun, 2012-10-21 at 14:45 -0700, Mark Smith wrote: >> Actually it can, as the destination address for the server the relay uses >> can be the all-dhcp-serviers site-local (FF05:0:0:0:0:0:1:3) multicast >> address. > > I have yet to see this in the wild, and would be interested to hear if > anyone actually does this. I'd suggest that is because most people have only lived in a unicast IPv4 world, so there is very little understanding of and recognition of what value multicast can provide to network operations. That's not to say it should always be used for a relay, it is a trade off. My point was that there is a method available for a relay to discover DHCPv6 servers without the configuration issues related to only being able to use a specific GUA or ULA unicast address. > It seems to me that it is asking for trouble > - anyone could set up a server and add themselves to that group, then > receive - and answer! - DHCP queries. That is of course true anyway on > the client link, but it's a different scale of problem on the wider > network. Mitigation would need filters everywhere, just in case. True, however you also have the same sort of vulnerability issues to rogue DHCP servers. That would be one of the considerations of whether to do it or not. > Unicasting from relays requires configuration of all relays, but that is > required anyway - and all the relays could have the *same* > configuration, which is always good. > Well, the same multicast address would be used on the relays' configurations, so they'd all be the same. The drawback of unicast is that the relay target DHCPv6 server becomes a single point of failure. I'm not sure if you could use or whether it would be wise to use an anycast address as a DHCPv6 server address in that scenario. > My understanding (poor) is that since site-local was deprecated, the > various ff05::/16 addresses were pretty much deprecated as well. I'm pretty sure site-local multicast scope wasn't deprecated with site-local unicast addresses were. The issue with site-local unicast addresses wasn't that the idea of a site was invalid, it was their non-uniqueness and therefore it recreated in IPv6 all the sorts of issues similar we suffer from with overlapping or duplicated RFC1918 address spaces. If you ever want to explain to IPv4 people the issues with duplicated RFC1918 address spaces, the IPv6 site local deprecation RFC provides a good list. > Actually that's not an understanding, it's an assumption :-) And I can > see that an alternative path would be to let all the site-local > well-known addresses stand alone; no longer site-local as such, just > "they are what they are". > > Regards, K. > Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
