(Sorry for being too late response)
I am really not sure why this thread is moved to *meta thought*.
When I wrote this document, I originally thought this task was
our explicit consensus to be a seperated document from 2462bis.
Am I missing anything ? I don't think so.
See below link (October 20
t: Monday, May 23, 2005 8:48 AM
> To: Ralph Droms
> Cc: dhcwg@ietf.org; IETF IPv6 Mailing List
> Subject: Re: meta thoughts on m/o bits
>
> On 20-mei-2005, at 21:06, Ralph Droms wrote:
>
> >> In some scenarios there is a danger in the following approach:
> >> - h
; [EMAIL PROTECTED];
> ipv6@ietf.org; [EMAIL PROTECTED]; dhcwg@ietf.org
> Subject: Re: [dhcwg] RE: meta thoughts on m/o bits
>
> John - My understanding is that the selection of SLAAC addresses is
> separate from the use of DHCP; that is, a host may be in a scenario in
> which it uses
On 20-mei-2005, at 21:06, Ralph Droms wrote:
In some scenarios there is a danger in the following approach:
- hosts boots
- looks for DHCP server, doesn't find one
- Keeps looking every couple of minutes
Yes, this would clearly be harmful in cases where hosts both use
DHCPv6 and stateless au
John - I agree that in lieu of some failure or otherwise special
condition, devices should use the mechanisms built into SLAAC and DHCP
(address lifetimes) to control the use and assignment of addresses.
I think the DNAv6 work may have some impact on this discussion as
providing a more reliable me
John - My understanding is that the selection of SLAAC addresses is
separate from the use of DHCP; that is, a host may be in a scenario in
which it uses both an address chosen through SLAAC and an address
assigned through a DHCP message exchange. So, the availability of a
SLAAC address should not
Jari & Hesham,
> >=> :) I don't want them to charge users for Ralph's implementation :)
> >But seriously, charging is one thing, inefficient use of power is
> >another serious problem which can actually reduce revenue because
> >a device doesn't go dormant long enough and runs out of battery
> >
12:57 AM
> To: Soliman, Hesham
> Cc: dhcwg@ietf.org; ipv6@ietf.org; Bernie Volz (volz); Ralph
> Droms (rdroms)
> Subject: Re: meta thoughts on m/o bits
>
> Soliman, Hesham wrote:
>
> >Hi Bernie,
> >
> > > > => You can try, but my concern is about
Soliman, Hesham wrote:
Hi Bernie,
> > => You can try, but my concern is about how often you're
> going to try.
> > If there are bits that say whether you should try or not and those
> > bits are not set (i.e. no DHCP server in the network), why
> > would you try?
>
> This means that the wi
ailto:[EMAIL PROTECTED] On
> > Behalf Of Soliman, Hesham
> > Sent: Friday, May 20, 2005 3:15 PM
> > To: Ralph Droms (rdroms)
> > Cc: dhcwg@ietf.org; ipv6@ietf.org
> > Subject: RE: meta thoughts on m/o bits
> >
> >
> >
> > > No one
e bits are advisory
only.
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Soliman, Hesham
> Sent: Friday, May 20, 2005 3:15 PM
> To: Ralph Droms (rdroms)
> Cc: dhcwg@ietf.org; ipv6@ietf.org
> Subject: RE: meta thoughts on
in IPv6. Stateless address config actually
> > provides a very useful and timely way of configuring addresses
> > for mobile nodes.
> >
> > Hesham
> >
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EM
On 5/21/05, Ralph Droms <[EMAIL PROTECTED]> wrote:
> Well...DHCPv6 doesn't have any better mechanism for announcing
> availability of a server than does DHCPv4 (which is to say "none").
> There has not been an identified need to push an announcement of DHCP
> server availability out to clients.
>
>
Droms
> > Sent: Friday, May 20, 2005 2:34 PM
> > To: ipv6@ietf.org; dhcwg@ietf.org
> > Subject: Re: meta thoughts on m/o bits
> >
> >
> > Well...DHCPv6 doesn't have any better mechanism for announcing
> > availability of a server th
oms
> Sent: Friday, May 20, 2005 2:34 PM
> To: ipv6@ietf.org; dhcwg@ietf.org
> Subject: Re: meta thoughts on m/o bits
>
>
> Well...DHCPv6 doesn't have any better mechanism for announcing
> availability of a server than does DHCPv4 (which is to say "n
Small goof in previous message:
> > Those assuming a broadcast mechanism is needed may be making the
> > assumption that if an admin turns on a DHC server, it is a
> > _requirement_ that all nodes start using DHC effectively
> > _immediately_.
> >
> > It is not at all clear to me that this is a r
Comments in line...
On Fri, 2005-05-20 at 14:33 -0400, Thomas Narten wrote:
> > > => I'm curious about this, does DHCP broadcast its existence to
> > > clients that never used it when it comes up? Seems a bit strange
> > > to do that. I don't even know how it could speak to a client unsolicited.
>
(cc'ing the dhcwg list)
> On Fri, 20 May 2005 13:24:26 -0400,
> Thomas Narten <[EMAIL PROTECTED]> said:
> Stepping up a level (and this also reflects my thinking after a
> private exchange with Ralph/Bernie - but not necessarily their
> thinking!)...
> I think the M/O bits (in retrospec
Well...DHCPv6 doesn't have any better mechanism for announcing
availability of a server than does DHCPv4 (which is to say "none").
There has not been an identified need to push an announcement of DHCP
server availability out to clients.
Section 14 of RFC 3315 specifies the retransmission behavior
> > => I'm curious about this, does DHCP broadcast its existence to
> > clients that never used it when it comes up? Seems a bit strange
> > to do that. I don't even know how it could speak to a client unsolicited.
> >
> Yes, I do not think there is any message that has currently been defined
> i
On 5/20/05, Soliman, Hesham <[EMAIL PROTECTED]> wrote:
>
> > > This proposal looks better and easy to understand. However,
> > > if we just rely on timeout for concluding the
> > unavailabiliy of DHCP server,
> > > how does the client re-invoke DHCP if the DHCP server is
> > available later i
> > This proposal looks better and easy to understand. However,
> > if we just rely on timeout for concluding the
> unavailabiliy of DHCP server,
> > how does the client re-invoke DHCP if the DHCP server is
> available later in
> > time? I think we need one bit to inform the clients about
> This proposal looks better and easy to understand. However,
> if we just rely on timeout for concluding the unavailabiliy of DHCP server,
> how does the client re-invoke DHCP if the DHCP server is available later in
> time? I think we need one bit to inform the clients about the
> availabilty of
This proposal looks better and easy to understand. However,
if we just rely on timeout for concluding the unavailabiliy of DHCP server,
how does the client re-invoke DHCP if the DHCP server is available later in
time? I think we need one bit to inform the clients about the
availabilty of DHCP
serv
24 matches
Mail list logo
