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

From: "Jari Arkko" <[email-masked]>
Date: Fri, 3 Aug 2007 23:19:35 +0300

All,

Again, we need to be careful with any of these proposals, and avoid jumping to the conclusion that a protocol with a specific name will either solve all these problems or cause them.

We also care about interoperability and the ability to talk to each other; if we didn't we wouldn't need to work on standards. 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... The architectural principles of the Internet call for trying to find one solution, even if it is not 100% perfect in all cases.
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. 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.

Jari

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 3 Aug 2007 13:26:34 -0700

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

---

From: Ralph Droms <[email-masked]>
Date: Fri, 3 Aug 2007 17:13:58 -0400

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

---

From: james woodyatt <[email-masked]>
Date: Fri, 3 Aug 2007 15:05:31 -0700

On Aug 3, 2007, at 14:13, Ralph Droms wrote:
>
> OS X is a somewhat more interesting case, as I don't know of a  
> DHCPv6 client for OS X as yet.

There isn't one, and I wouldn't hold my breath waiting for it in Mac  
OS X 10.5 if I were you.  Careful examination of Apple's developer  
pages and technical specifications will show no mention of DHCPv6  
showing up in Mac OS X any time soon.

I can't say when, or even *whether*, Apple products will contain  
DHCPv6 clients.  Certainly, none of Apple's products in the market  
today are DHCPv6-enabled, so networks that require DHCPv6 will not  
admit any of them.  That includes iPhone, AppleTV and AirPort, all of  
which support IPv6 at least to some extent.  (Okay, I haven't poked  
at my new iPhone enough to know what they did with IPv6 there.  They  
*might* have turned it off.  I don't know.)

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering