[email protected] writes: >> > Some of us would disagree rather strongly with one or more of those >> > points. For instance, for us DHCPv6 is a hard requirement. >> > >> Why the hard requirement? Is this for a MAC<->IP association table? >> I'm working on a method (might not work mind you) to make a SLAAC >> network forfill this requirement...I have to so we meet our upstream >> AUP requirements but running DHCPv6 kinda misses the point for why you >> try to deploy IPv6. :) > > This is an old discussion, and has been rehashed a number of times on > various DHCP and IPv6 mailing lists. In any case: > > - SLAAC cannot distribute all the parameters that DHCP distributes to > customers today. Example of parameters needed: DNS servers, domain > name, NTP servers, ...
No it can't, but personally I see that as a feature :-) We need to publish DNS servers, but RFC 5006 solves that. The other DHCP options are mostly unecessary bloat. Are there really that many DHCP clients doing anything useful with the NTP option? I guess you may have set-top boxes using it, but those can just as well be pre-configured with the well-known DNS name of your NTP servers. > - DHCP is tightly integrated with various operational and support > systems. Sure, but given the differences between DHCP and DHCPv6 I wonder if you can reuse much of it anyway? I find it just as easy to modify our RADIUS support to provide the IPv6 prefix(es) and DNS servers. In fact, it's easier. > - DHCP lets us control customer address allocation from one central > point, instead of having to individually configure routers. You can do that with SLAAC too, e.g. by using RADIUS. We'll of course use DHCPv6 too, mostly because we want prefix delegation. But I still think SLAAC is useful in some settings, even for ISPs. I want both. Bjørn _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
