On Nov 18, 2011, at 9:38 AM, "Brian E Carpenter" <[email protected]> wrote: > Operators say that they want (approximate) feature parity so > that they can have (approximate) alignment between their > operational procedures for v4 and v6, especially in a dual stack > network. I assert that this is a very good engineering reason, > and it isn't for the IETF to get on its high horse and say that > experienced operators don't know how to manage OPEX.
This is the exact use case Tomek cited, and is (some of us think) adequately satisfied by a vendor-specific route option in the BBF and/or 3GPP vendor option spaces. John was pretty sure that there was no demand for this from Cablelabs, although I'd certainly be interested in hearing other opinions on this question. The question is whether there is some use case that justifies a general-purpose DHCPv6 option that would wind up being widely deployed and likely used *instead* of RA in some network to which arbitrary nodes might need to connect. > I don't know whether my final comment belongs on this thread or > the drawbacks thread, but it's clear that a strong constraint on > any DHCPv6 option that overlaps in functionality with RA is that > it must convey exactly the same semantics or a proper superset > of the same semantics. If we do that, DHCPv6 will not undercut > RA and a special algorithm for RA vs DHCPv6 conflict resolution > will not be needed. It's difficult to see how we could ensure that this was true, since the DHCPv6 server and router might actually be operated by independent entities with no coordination. _______________________________________________ mif mailing list [email protected] https://www.ietf.org/mailman/listinfo/mif
