Le 22/10/2012 02:54, Mark Smith a écrit :
[...]
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.
Well, the use of multicast to identify the servers may indeed seen as a
good way towards discovering a server.
But that would assume the IP multicast is working beyond just one link.
Which is good if it is deployed, but is it. Shoudl one require PIM-SM
in the infrastructure in order to make sure that DHCP-PD works on a road
between an LV and an IV? I doubt.
(as with homenet - should I require my operator to run PIM-SM in its
network in order for me to be able to turn on an IPv6 WiFi range
extender DHCP Client which connects to the ADSL box DHCP Relay?)
Alex
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 ipv6@ietf.org Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
