Mikael Abrahamsson: > Why not? DHCP could populate the neighbour table with very > long lifetime? > > The only change I see would be for the operation of DHCPv6 to > always run > if there isn't any response to RS and no RA is seen. > > Perhaps some minor changes need to be made to allow for > populating the > neighbour table statically (and set the timeouts to whatever > is in the > DHCP lease), but I don't see this as a major change in the IPv6 stack. > > You're right, this doesn't work on unmodified hosts with > standards that > exists today, but the changes needed should be minor...
I think your idea makes most sense in cases where Internet access is provided via cable head-ends or PONs. Where everything from customer premises has to go through the head-end anyway. Yes, the need for ND in this particular case is probably questionable, at least within the provider's coax network or PON. Otherwise, I don't see the advantage of overloading the DHCP server with this new responsbility of keeping track of all physical addresses in the local net, other routers, etc. As Hesham pointed out, this concentrates more responsibility on a central server, a responsibility that is now distributed among all of the hosts (and routers) instead. My position is, I need to have a reliable way of distributing "well known" IPv6 addresses to the hosts of peer-peer networks. That's my interest in DHCPv6, vs SLAAC, for assignment of addresses. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
