On Thu, 10 Mar 2011 13:31:58 +0100 (CET) sth...@nethelp.no wrote: > > > > The common argument from the "stateful-only crowd" seems to be that > > > > they need to have a log of IPv6 address/MAC addresses for audit > > > > purposes, and therefore think they need to have stateful, database > > > > driven addressing to do that, probably because that is how it has > > > > been done in IPv4. > > > > > > In our (service provider) case the basic requirement is to be able to > > > associate a dynamic IPv6 address with a specific *customer*. > > > > Can't you use RADIUS for that? I'm working in a SLAAC > > environment for SP customers over PPP/PPPoE or L2TP, and RADIUS is > > reporting everything we're interested in knowing, including username, > > PPP IPV6CP IIDs, chosen dynamic prefixes for the PPP session and dynamic > > delegated prefixes if they're requested and the customer falls in that > > service type. > > Sure we can. If we redo our DHCP infrastructure to use Radius instead. > It is a major change, and we don't really want to do it unless we > absolutely have to.
Where did I say you had to change what you already had and were satisfied with? All I've said is that I think SLAAC plus more detailed ND state logging would be functionality equivalent to what those who advocate stateful DHCPv6 addressing usually state they require, and that is generally in the (unstated) common case of a LAN environment, although it may also be applicable in an SP/CPE scenario. I think if the choice between SLAAC + more detailed router ND state recording verses stateful DHCPv6 was commonly available, the SLAAC option would be the most likely choice, due to more (and most likely all) IPv6 end-nodes supporting SLAAC (in the common case context of a LAN environment). > > There are plenty of *other* bumps in the road on our way to IPv6. I > see no need to introduce more of these than necessary. > Maintaining state costs CPU, RAM, and potentially disk space and network traffic. Reducing the amount of state and/or gaining more value out of existing essential state seems to me to be a worthy goal. In practical terms, I think reducing the end-node requirement for stateful DHCPv6, and leveraging the existing and essential NUD state to achieve the same functional results for most use cases of stateful DHCPv6 would be something worth aiming for. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
