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

["Tony Hain" <alh-ietf@tndh.net>]

People that prefer to use DHCP should have the tools to do that (an RA
should still inform hosts that DHCP is the mechanism this network uses).
People that prefer to avoid the costs associated with that independent
service should have the tools to do that through the RA. Hosts should accept
configuration information from either. The IETF's job is to specify the
tools, not the operational deployment model. 

Jari's misguided issue about multiple mechanisms only becomes valid when it
is not possible to deploy an operational network without both (see the
Chicago fiasco). There are financial reasons for each deployment model, and
there is no real conflict between them. The IETF needs to stop trying to
force the world to go a particular way and just make sure each deployment
model is complete. That means adding the DHCP options Ralph is talking
about, as well as the RA options that fill the gap on that side. 

Tony

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Friday, August 03, 2007 4:17 AM
> To: alh-ietf@tndh.net
> Cc: 'Durand, Alain'; 'Jari Arkko'; marc.blanchet@viagenie.ca;
> v6ops@ops.ietf.org
> Subject: Re: DHCP failures (was RE: Do you want to have more meetings
> outsi de US ?)
> 
> The dhc WG has received a request to develop, on behalf of network
> operators who have expressed the specific requirement that they do
> not want the operation of their network to depend on RAs, new options
> for DHCPv6 to pass prefix and default router information to a host.
> That information would allow a host to get all of its configuration
> information from DHCPv6, obviating the use of RAs.
> 
> Will the IETF elite allow the standardization of these new options to
> support this different mode of configuration or will those network
> operators who would prefer to use only DHCPv6 be forced to continue
> to use RAs?
> 
> - Ralph, who is astonished that the IPv6 community hasn't solved
>    multihoming, PI vs. PA addressing, core routing table scaling,
>    renumbering and ad hoc networking, but does have time to rehash,
>    yet again, the problem of Making the Internet Safe from DHCP
> 
> On Aug 2, 2007, at Aug 2, 2007,5:57 PM, Tony Hain wrote:
> 
> > I did not say that DHCP should be deprecated. There are real-world
> > situations like the ones that took down the IETF DHCP service, that
> > are
> > clearly operational/implementation/deployment rather than protocol
> > issues.
> > Just because some organizations run DHCP does not mean everyone
> > else MUST
> > because the IETF elite refuse to allow an operationally different
> > alternative to be standardized.
> >
> > Tony
> >
> >> -----Original Message-----
> >> From: Durand, Alain [mailto:Alain_Durand@cable.comcast.com]
> >> Sent: Thursday, August 02, 2007 1:26 PM
> >> To: Jari Arkko; alh-ietf@tndh.net
> >> Cc: marc.blanchet@viagenie.ca; v6ops@ops.ietf.org
> >> Subject: RE: DHCP failures (was RE: Do you want to have more
> meetings
> >> outsi de US ?)
> >>
> >> I agree. Cable networks have proven that DHCP can be scaled
> >> to tens of million of leases...
> >>
> >> The fact that something went wrong at IETF is no proof
> >> that the model is broken.
> >>
> >>   - Alain.
> >>
> >>> -----Original Message-----
> >>> From: owner-v6ops@ops.ietf.org
> >>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Jari Arkko
> >>> Sent: Thursday, August 02, 2007 3:53 PM
> >>> To: alh-ietf@tndh.net
> >>> Cc: marc.blanchet@viagenie.ca; v6ops@ops.ietf.org
> >>> Subject: RE: DHCP failures (was RE: Do you want to have more
> >>> meetings outsi de US ?)
> >>>
> >>> I may be missing some context (I'm bandwidth challenged right
> >>> now and unable to check archives). But its unclear to me
> >>> where you jumped to the conclusion that DHCP problems in
> >>> Chicago had something to do with a specific protocol and that
> >>> this implies we need to deploy an alternate solution in IPv6.
> >>> If anything, multiple solutions seem to increase the
> >>> likelihood of interop and configuration problems.
> >>>
> >>> Jari
> >>>
> >>>
> >>>