[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DHCP failures (was RE: Do you want to have more meetings outsi de US ?)



Tony - I think you are focusing on the traditional DHCPv4 model of a centralized DHCP service, managing IP address and other configuration information, on one or a few large servers. My model of the use of DHCPv6 for other configuration information is that the "servers" are, in fact, colocated with the ND machinery in network elements. As we have learned through our implementations of DHCPv6 at Cisco, building a DHCP server that responds to InformationRequest messages can be *very* simple to implement and to configure. Therefore, I disagree that there are "financial constraints" or configuration complexity constraints or, for that matter, any other operational constraints for or against one or the other deployment model.

As I pointed out earlier in this thread, depending on the routers used in the IETF network, I believe the IPv6 service could very easily have used this standards-based deployment model for prefix, default router, address and other configuration information to provision systems using Vista "out of the box" in Chicago. I'm not so sure about various versions of *nix with a 3rd-party DHCPv6 client. OS X is a somewhat more interesting case, as I don't know of a DHCPv6 client for OS X as yet.

Finally, I realize I'm rehashing arguments which have been made several times before. I wouldn't do it if I didn't think the arguments didn't need to be refreshed in various caches.

- Ralph

On Aug 3, 2007, at Aug 3, 2007,4:26 PM, Tony Hain wrote:

Jari Arkko wrote:
... So far in
this thread I have heard people avoiding DHCP completely or using
solely DHCP. Its clear that the two extremes would have a problem
communicating...

Absolute BS. There is no need for those to communicate. A host needs to be
able to get configuration from either mechanism.

The architectural principles of the Internet call for
trying to find one solution, even if it is not 100% perfect in all
cases.

No it doesn't. If anything it only requires that there be no more than one
for any particular set of financial constraints.

Also, given that we have existing protocols for these things, and
implementations out there, its not clear that we want to find other
ways of doing the same... particularly when we have real, unsolveed
problems left. I'd rather spend cycles on those.

This does not mean we never do alternates - we did publish RA- based DNS
discovcery, for instance.

More BS. This is not on the standards track, so it will not get real
implementations that matter.

And DHC WG will take a serious look at the
customer requirements that Ralph mentioned. But it means we are going
to ask hard questions about things like interop with existing hosts.

There is no hope for the existing environment because it requires an
incomplete set of both mechanisms to be deployed. That does not fit the financial models that drive people toward their favored approach. It is not the IETF's job to dictate a deployment model. The IETF needs to define the tools to make either approach complete and deployable without reliance on
the other.

Tony