> Bound, Jim wrote:
> > But it is possible to change the meaning of A=0 to mean use
> dhc if you have
> > it.
> >
> > Also multiple prefixes can be provided.
> >
> > L and A are orthogonal. If you set L and not A all that was
> stated is use
> > these for link knowlege but not for autoconfi
Bound, Jim wrote:
But it is possible to change the meaning of A=0 to mean use dhc if you have
it.
Also multiple prefixes can be provided.
L and A are orthogonal. If you set L and not A all that was stated is use
these for link knowlege but not for autoconfigure.
But the fact that the A flag
On 4-jun-2005, at 7:30, Bound, Jim wrote:
But it is possible to change the meaning of A=0 to mean use dhc
Sure.
if you have it.
But not that part. If the autonomous address configuration flag is
zero for all prefixes in an RA, a host not implementing DHCPv6 is
dead in the water.
(Som
: Erik Nordmark [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 03, 2005 1:22 PM
> To: [EMAIL PROTECTED]
> Cc: Bound, Jim; [EMAIL PROTECTED]; dhcwg@ietf.org; ipv6@ietf.org
> Subject: Re: [dhcwg] RE: purpose of m/o bit
>
> [EMAIL PROTECTED] wrote:
>
> > Yes, agreed. Goin
[EMAIL PROTECTED] wrote:
Yes, agreed. Going further, maybe A=0 could signal this?
But the A flag is per prefix, not per RA.
And so far we haven't assigned any semantics to a flag in the prefix
being zero; the semantics are associated with the flags being set to one.
That model seems to be use
L; Christian Schild; dhcwg@ietf.org; ipv6@ietf.org
> Subject: RE: [dhcwg] RE: purpose of m/o bit
>
>
> Fred,
>
> Good questions. But could cause gigantic rat-hole :--)
>
> > At the risk of covering old ground, one question I had is
> > whether a client mu
Mat,
> Yes, agreed. Going further, maybe A=0 could signal this?
Not bad Mat. That might actually work. Kudos to your logic parsing
here. In our fury to make sure we told clients use stateless we added
the M bit. O bit was an anomaly IMO. Need to roll this around in my
brain with implementer
> -Original Message-
> From: Christian Schild [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 03, 2005 2:38 AM
> To: Bound, Jim
> Cc: dhcwg@ietf.org; ipv6@ietf.org
> Subject: RE: [dhcwg] RE: purpose of m/o bit
>
> Hi Jim,
>
> Am Donnerstag, den 02.06.2005
Hi Jim,
Bound, Jim wrote:
> Mat,
>
>> stateful/stateless is of no concern to the client, right? so if the
>> initiator is always the same, then the question of authority becomes
>> moot.
>
> Let me restate I don't think you parsed my question, which
> may have been
> unclear in hingsight?
I thi
On 3-jun-2005, at 8:38, Christian Schild wrote:
I don't believe that suppression of (client) DHCPv6 packets is
enforceable. What if the client is not pleased with what he got?
Whether something is enforceable is not the point. The IETF can't
enforce _anything_, that's a given.
What's impor
On 3-jun-2005, at 0:00, Templin, Fred L wrote:
At the risk of covering old ground,
Yeah, we wouldn't want that. :-)
one question I had is whether a client must wait to receive an RA
before initiating stateless or stateful DHCPv6?
How would it know the value of the M and O bits if it didn
Hi Jim,
Am Donnerstag, den 02.06.2005, 12:23 -0400 schrieb Bound, Jim:
> > So you don't believe that the RA in ND should be the authority to
> > use a stateful model on an IPv6 link?
Thanks for your question, I think that's a key part of the discussion.
I know what you are trying to achieve.
Fred,
Good questions. But could cause gigantic rat-hole :--)
> At the risk of covering old ground, one question I had is
> whether a client must wait to receive an RA before initiating
> stateless or stateful DHCPv6? Asked another way, can DHCPv6
> still be used if there are no advertising ro
Jim et al,
At the risk of covering old ground, one question I had is whether a client must
wait to receive an RA before initiating stateless or stateful DHCPv6? Asked
another way, can DHCPv6 still be used if there are no advertising routers on
the link?
To an even more speculative question, if
Mat,
> stateful/stateless is of no concern to the client, right? so if the
> initiator is always the same, then the question of authority becomes
> moot.
Let me restate I don't think you parsed my question, which may have been
unclear in hingsight?
For an IPv6 link the RA informs nodes whether t
[EMAIL PROTECTED] wrote:
>> It would be really nice and handy to initiate either stateless or
>> stateful DHCPv6 with the same message. If so, we wouldn't need
>> the M/O bits anymore. In this case the client would simply initiate
>> a(n Information) Request message and would get all the informatio
> It would be really nice and handy to initiate either stateless or
> stateful DHCPv6 with the same message. If so, we wouldn't need
> the M/O bits anymore. In this case the client would simply initiate
> a(n Information) Request message and would get all the information
> that are available on t
On 1-jun-2005, at 18:24, Iljitsch van Beijnum wrote:
[always cool following up on your on posts...]
Because I fell in the middle of this discussion, and there seems to
be a rather substantial disconnect between my views and those of many
others, I decided to read up on earlier posts a bit.
Mohacsi Janos wrote:
> On Wed, 1 Jun 2005 [EMAIL PROTECTED] wrote:
>
>> [EMAIL PROTECTED] wrote:
>>> On Wed, 1 Jun 2005, Ralph Droms wrote:
2) Ability for a host to get all desired and available DHCP
configuration with a single DHCP message exchange
- if a host wants HCB, it sen
> Treating RA information that DHCPv6 servers aren't available as a
> hint and ignoring the hint is an implementation of the ability to do
> DHCP without having to configure routers.
I agree and I think most agree that the router RA determines if dhc is
to be used at all. Thus that purpose of
On 1-jun-2005, at 14:25, Bernie Volz ((volz)) wrote:
4 Ability to do DHCP without having to configure routers
I'm not sure I'd draw that conclusion. I think the point was that
hosts
*MAY* ignore any RA "hints" and do what they are manually
configured to
do
Treating RA information that D
On Wed, 1 Jun 2005 [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
On Wed, 1 Jun 2005, Ralph Droms wrote:
2) Ability for a host to get all desired and available DHCP
configuration with a single DHCP message exchange
- if a host wants HCB, it sends an HCB request (Solicit) and
rec
[EMAIL PROTECTED] wrote:
> On Wed, 1 Jun 2005, Ralph Droms wrote:
>> 2) Ability for a host to get all desired and available DHCP
>> configuration with a single DHCP message exchange
>> - if a host wants HCB, it sends an HCB request (Solicit) and
>> receives HCB and/or ICB replies
>
> It wo
> We need to agree on requirements before we try to engineer solutions.
> Here is what I've heard as requirements:
>
> 1) Ability to indicate to a host "DHCP is not available on this link",
>with the expectation that the host won't send any DHCP messages
>
> 2) Ability for a host to get all
On Wed, 1 Jun 2005, Ralph Droms wrote:
2) Ability for a host to get all desired and available DHCP
configuration with a single DHCP message exchange
- if a host wants HCB, it sends an HCB request (Solicit) and receives
HCB and/or ICB replies
It would be even better to keep backward comp
Pekka - In theory, I agree. In practice, it's early enough to make a
change before we have extensive deployments and the lack of backward
compatibility only affects a few deployments, where a host requesting
HCB would be satisfied with and ICB response. So, I don't think
backward compatibility is
CTED]
> On Behalf Of Iljitsch van Beijnum
> Sent: Wednesday, June 01, 2005 8:05 AM
> To: Ralph Droms (rdroms)
> Cc: dhcwg@ietf.org; IETF IPv6 Mailing List
> Subject: [dhcwg] Re: purpose of m/o bit
>
> On 1-jun-2005, at 13:31, Ralph Droms wrote:
>
> >
On 1-jun-2005, at 13:31, Ralph Droms wrote:
We need to agree on requirements before we try to engineer solutions.
:-)
Here is what I've heard as requirements:
1) Ability to indicate to a host "DHCP is not available on this link",
2) Ability for a host to get all desired and available D
We need to agree on requirements before we try to engineer solutions.
Here is what I've heard as requirements:
1) Ability to indicate to a host "DHCP is not available on this link",
with the expectation that the host won't send any DHCP messages
2) Ability for a host to get all desired and ava
On 30-mei-2005, at 22:23, Bound, Jim wrote:
Folks, the purpose of this thread is to define the purpose of the bits
for ND and addrconf not resolve how dhc works. We need to finish that
first ok.
The router is sending m and o bits now. What is their purpose and do
they work. If we change th
On 30-mei-2005, at 17:16, Christian Schild (JOIN Project Team) wrote:
It would be really nice and handy to initiate either stateless or
stateful DHCPv6 with the same message.
I don't see a use case for this.
Assume you have a stateless server available on a link and M/O bits
are missing or
Folks, the purpose of this thread is to define the purpose of the bits
for ND and addrconf not resolve how dhc works. We need to finish that
first ok.
The router is sending m and o bits now. What is their purpose and do
they work. If we change them it affects far more than dhc.
The thread to h
Am Montag, den 30.05.2005, 15:46 +0200 schrieb Iljitsch van Beijnum:
> On 30-mei-2005, at 14:51, Christian Schild wrote:
>
> > In my mind RFC3736 is flawed, as it's clients use an
> > Information-Request message to initiate communication with a
> > DHCPv6 server and not a Solicit message like RFC3
On 30-mei-2005, at 14:51, Christian Schild wrote:
In my mind RFC3736 is flawed, as it's clients use an
Information-Request message to initiate communication with a
DHCPv6 server and not a Solicit message like RFC3513.
It is _too_ lite.
What is it that you want to do for which full DHCPv6 is to
Am Freitag, den 27.05.2005, 13:45 -0700 schrieb Erik Nordmark:
> The issue I see if we recommend that clients (which implement both
> RFC
> 3315 and 3736) always send a Solicit (when some bit is set in the RA
> telling it to use DHCP), then such a client will not interoperate
> with
> currently
On Fri, May 27, 2005 at 09:39:52AM -0700, Ted Lemon wrote:
> On May 27, 2005, at 9:35 AM, Bound, Jim wrote:
> >ughh. sorry know of three production servers in use Lucent, HP, and
> >Linux version.
> >
>
> That's not what I mean. The point is that it's early days, and
> updating servers isn't a
On Fri, 27 May 2005, Erik Nordmark wrote:
The issue I see if we recommend that clients (which implement both RFC 3315
and 3736) always send a Solicit (when some bit is set in the RA telling it to
use DHCP), then such a client will not interoperate with currently deployed
3736 DHCP servers.
My u
van Beijnum; ipv6@ietf.org;
> Bernie Volz (volz); Ralph Droms (rdroms)
> Subject: Re: [dhcwg] RE: purpose of m/o bit
>
> On May 27, 2005, at 9:35 AM, Bound, Jim wrote:
> > ughh. sorry know of three production servers in use Lucent, HP, and
> > Linux version.
> >
>
On May 27, 2005, at 11:55 AM, Bound, Jim wrote:
If others want the cross posting that is fine I just asked the
question
and would like to hear what people think that is all.
Seems like part of what's going on is that we needed to have this
discussion cross-posted a year or three ago, so it'
On May 27, 2005, at 6:18 AM, Bernie Volz (volz) wrote:
These changes would potentially cause some issues with any deployments
today because the clients and servers do not support this "new"
behavior, but it that's why it is critical we work this out ASAP.
However, those clients, if they use the M
On May 27, 2005, at 11:25 AM, Bernie Volz (volz) wrote:
If people are really concerned about this, we can always add a DHCPv6
option to the Solicit that tells the server "I'm a new client and am
able to receive other configuration parameters even if you're not
going
to give me any addresses."
On May 27, 2005, at 9:35 AM, Bound, Jim wrote:
ughh. sorry know of three production servers in use Lucent, HP, and
Linux version.
That's not what I mean. The point is that it's early days, and
updating servers isn't a hard problem. My point is that I don't
know of any widespread deploy
: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
: On Behalf Of Iljitsch van Beijnum
: Sent: Wednesday, May 25, 2005 2:43 AM
:
: [Crossposted to dhcwg even though I'm not on that list, as
: people there may be able to add some useful insights.]
: All of this, coupled with the fact that, A
Bernie Volz (volz) wrote:
But realisticly, do you expect any old client to check for these "other
configuration" parameters and if they got them, what might they do? Drop
the packet? Well, that is what the client would essentially have done
anyway since it got no addresses. So, while a poorly imp
On 27-mei-2005, at 18:16, Bernie Volz ((volz)) wrote:
1 1 send Solicit send Information-Request
But what happens if the stateful server is down and stateless is
running?
Buy more servers?? Some solutions are simple. :-)
Though I would never recommend that a link have bo
> -Original Message-
> From: Ralph Droms [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 27, 2005 2:51 PM
> To: Bound, Jim
> Cc: dhcwg@ietf.org; ipv6@ietf.org
> Subject: Re: Where do we do this work: purpose of m/o bit
>
> Jim - it would be great to sort this out in o
TECTED]
> On Behalf Of Ted Lemon
> Sent: Friday, May 27, 2005 2:40 PM
> To: Bernie Volz (volz)
> Cc: dhcwg@ietf.org; Ralph Droms (rdroms); Erik Nordmark;
> ipv6@ietf.org; Iljitsch van Beijnum
> Subject: Re: [dhcwg] RE: purpose of m/o bit
>
> On May 27, 2005, at 11:25 AM, Be
Jim - it would be great to sort this out in one group or the other. But
I think the eventual solution will require input from both ipv6 and dhc
WGs, so we might have to continue the cross-posting or set up a short-
lived mailing list just for this discussion.
- Ralph
On Fri, 2005-05-27 at 14:40
Do we need to continue cross posting and we should decide where we sort
this out IPv6 or DHC.
My suggestion is the bits need to be understood for ND and Addrconf thus
lets get this done in the IPv6 WG. That would make job of what DHC has
to do easy.
/jim
--
But the discussion says nothing about how complex the underlying issues
are. I think there is significant room for simplification (but no more
simplification than necessary!), especially if we set aside
preconceptions about the M/O bits and look at what we've learned through
discussion, implementa
From: Erik Nordmark [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 27, 2005 1:43 PM
> To: Bernie Volz (volz)
> Cc: Iljitsch van Beijnum; ipv6@ietf.org; dhcwg@ietf.org;
> Ralph Droms (rdroms)
> Subject: Re: [dhcwg] RE: purpose of m/o bit
>
> Bernie Volz (volz) wrote:
> >
Erik - the idea is to allow a client to initiate either HCB or ICB with
the same message, which turns into a 4 message exchange for HCB (2
messages w/ "rapid commit") or 2 message exchange for ICB.
- Ralph
On Fri, 2005-05-27 at 10:30 -0700, Erik Nordmark wrote:
> Ralph Droms wrote:
> > Seems to m
gt; To: ipv6@ietf.org; dhcwg@ietf.org
> Cc: Ted Lemon; Bound, Jim; Iljitsch van Beijnum; Ralph Droms
> (rdroms); Bernie Volz (volz); Thomas Narten;
> [EMAIL PROTECTED]
> Subject: Re: [dhcwg] RE: purpose of m/o bit
>
> Isn't it such a long idscussion a proof for the confusio
Bernie Volz (volz) wrote:
Why?
If we update the DHCPv6 protocol to allow "other configuration" options
to be returned in an Advertise for a Solicit, Information-Request/Reply
and Solicit/Advertise are then essentially the same in a stateless
DHCPv6 environment (though the Solicit does require a
Ralph Droms wrote:
Seems to me I'm hearing two requirements out of this thread:
1) Ability to indicate to a host "DHCP is not available on this link",
with the expectation that the host won't send any DHCP messages
2) Ability for a host to get all desired and available DHCP
configuration
Isn't it such a long idscussion a proof for the confusion in
understanding the M/O
bits? Instead of leaving the discussion here, thinking that there is
no confusion or
be fore taking any radical changes (either discarding M or O or both flags, or
making changes to the DHCPv6 protocols), it is bett
ie Volz (volz); dhcwg@ietf.org; Iljitsch van Beijnum;
> ipv6@ietf.org; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] RE: purpose of m/o bit
>
> On May 27, 2005, at 9:35 AM, Bound, Jim wrote:
> > ughh. sorry know of three production servers in use Lucent, HP, and
> > Linux ve
I think now.
/jim
> -Original Message-
> From: Ted Lemon [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 27, 2005 12:40 PM
> To: Bound, Jim
> Cc: Bernie Volz (volz); dhcwg@ietf.org; Iljitsch van Beijnum;
> ipv6@ietf.org; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] R
Cc: dhcwg@ietf.org; ipv6@ietf.org
> Subject: RE: [dhcwg] RE: purpose of m/o bit
>
> m == use dhc for addresses, o == use dhc for just configuration bow do
> you do this with one bit? neither m or o not set says don't use dhc.
> thus my reason for ternary.
>
> thx
> /
there is there.
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Bernie Volz (volz)
> Sent: Friday, May 27, 2005 9:18 AM
> To: Iljitsch van Beijnum
> Cc: ipv6@ietf.org; dhcwg@ietf.org; Ralph Droms (rdroms)
> Subject: RE: [dhc
.org; Iljitsch van Beijnum; ipv6@ietf.org;
> Ralph Droms (rdroms)
> Subject: Re: [dhcwg] RE: purpose of m/o bit
>
> On May 27, 2005, at 6:18 AM, Bernie Volz (volz) wrote:
> > These changes would potentially cause some issues with any
> deployments
> > today because the
h Droms (rdroms);
> dhcwg@ietf.org; ipv6@ietf.org
> Subject: RE: [dhcwg] RE: purpose of m/o bit
>
> We don't but it avoids issues with backwards compatibility (though I
> don't believe that is a big issue yet).
>
> I think if we come to agreement on having no distinction
h Droms
> Sent: Friday, May 27, 2005 8:59 AM
> To: [EMAIL PROTECTED]
> Cc: dhcwg@ietf.org; ipv6@ietf.org
> Subject: [dhcwg] RE: purpose of m/o bit
>
> Mat - thanks for your review and input. I specified the two bits only
> for backward compatibility with existing implementation
Droms (rdroms);
> dhcwg@ietf.org; ipv6@ietf.org
> Subject: Re: [dhcwg] RE: purpose of m/o bit
>
> On 27-mei-2005, at 15:18, Bernie Volz ((volz)) wrote:
>
> > Why?
>
> Well, why not?
>
> I'm not too familiar with the internals of DHCPv6, but I can imag
On 27-mei-2005, at 15:18, Bernie Volz ((volz)) wrote:
Why?
Well, why not?
I'm not too familiar with the internals of DHCPv6, but I can imagine
that it would be moderately useful if a client knows in advance
whether it's going to do full DHCP and may receive stateful
information, or it's
On 27-mei-2005, at 15:30, da Silva, Ron wrote:
One of the permutations missing in your algorithm is if a device is
configured for always-full-DHCPv6 on an interface AND it receives RA
with AAC set...I presume in that case the device would get multiple
addresses, right?
Like Ralph, I didn't inc
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > On Behalf Of Ralph Droms (rdroms)
> > Sent: Friday, May 27, 2005 9:45 AM
> > To: da Silva, Ron
> > Cc: dhcwg@ietf.org; Iljitsch van Beijnum; IETF IPv6 Mailing List
> > Subject: Re: [dhcwg] Re: purpo
mailto:[EMAIL PROTECTED]
> On Behalf Of da Silva, Ron
> Sent: Friday, May 27, 2005 9:31 AM
> To: Iljitsch van Beijnum
> Cc: dhcwg@ietf.org; IETF IPv6 Mailing List
> Subject: [dhcwg] Re: purpose of m/o bit
>
> > To me, assuming the current specs, the following would make sense
tsch van Beijnum; IETF IPv6 Mailing List
> Subject: Re: [dhcwg] Re: purpose of m/o bit
>
> Ron - Use of AAC on specific prefixes advertised in RAs, as controlled
> by the A bit in a prefix information option, is independent of the use
> of DHCP ... so you're right, if there are pr
> To me, assuming the current specs, the following would make sense:
One of the permutations missing in your algorithm is if a device is
configured for always-full-DHCPv6 on an interface AND it receives RA
with AAC set...I presume in that case the device would get multiple
addresses, right?
-ron
Ron - Use of AAC on specific prefixes advertised in RAs, as controlled
by the A bit in a prefix information option, is independent of the use
of DHCP ... so you're right, if there are prefixes in an RA with the A
bit set, and the M and/or O bits are set in that RA, the host would
configure both AAC
able. It is just new
clients with old servers that may have issues.
- Bernie
> -Original Message-
> From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 27, 2005 9:07 AM
> To: Bernie Volz (volz)
> Cc: [EMAIL PROTECTED]; Ralph Droms (rdroms);
> dhcwg@iet
On 27-mei-2005, at 14:56, Bernie Volz ((volz)) wrote:
I think if we come to agreement on having no distinction between the
bits, we should deprecate one of the bits (O-bit?); though for
backwards
compatibility, we can't remove/reassign it until many years from
now (if
ever).
I think havin
Mat - thanks for your review and input. I specified the two bits only
for backward compatibility with existing implementations.
I imagine we could design a specification that retains one bit and
deprecates the other, with rules about the appearance of the depre
backward compatibility. At least,
ove/reassign it until many years from now (if
ever).
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of [EMAIL PROTECTED]
> Sent: Friday, May 27, 2005 8:42 AM
> To: Ralph Droms (rdroms); dhcwg@ietf.org; ipv6@ietf.org
> Subjec
Ralph Droms <[EMAIL PROTECTED]> wrote:
> Seems to me I'm hearing two requirements out of this thread:
>
> 1) Ability to indicate to a host "DHCP is not available on this link",
>with the expectation that the host won't send any DHCP messages
>
> 2) Ability for a host to get all desired and a
Seems to me I'm hearing two requirements out of this thread:
1) Ability to indicate to a host "DHCP is not available on this link",
with the expectation that the host won't send any DHCP messages
2) Ability for a host to get all desired and available DHCP
configuration with a single DHCP me
On 26-mei-2005, at 22:24, da Silva, Ron wrote:
This seems way to complicated though, and it would be much more
deterministic for a CM to simply do #4 in all cases which would
make the
M/O bits useless.
You know what's really deterministic? Manual configuration.
There is a baby in this bath
Ron,
Thanks for doing this and this permits us to discuss it simply :--).
Response on your matrix via my interpretation as implementer, no comment
on your needs and appreciate you sharing that here big time, I find it
very useful. Thanks.
> There are nine scenarios, right?
>
> 1) RA w/auto-con
There are nine scenarios, right?
1) RA w/auto-conf, M off, O off
2) RA w/auto-conf, M on, O off
3) RA w/auto-conf, M off, O on
4) RA w/auto-conf, M on, O on
5) RA w/o auto-conf, M off, O off
6) RA w/o auto-conf, M on, O off
7) RA w/o auto-conf, M off, O on
8) RA w/o auto-conf, M on, O on
9) No RA
; Iljitsch van Beijnum; Thomas Narten
Cc: dhcwg@ietf.org; IETF IPv6 Mailing List
Subject: RE: [dhcwg] Re: purpose of m/o bit
So Rich, I'll ask. What would you like to see happen?
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf
ich
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Iljitsch van Beijnum
Sent: Wednesday, May 25, 2005 5:43 AM
To: Thomas Narten
Cc: dhcwg@ietf.org; IETF IPv6 Mailing List
Subject: [dhcwg] Re: purpose of m/o bit
[Crossposted to dhcwg even though I'm not on t
cwg@ietf.org; IETF IPv6 Mailing List
> Subject: RE: [dhcwg] Re: purpose of m/o bit
>
> >All of this, coupled with the fact that, AFAIK, no OS implements
> DHCPv6, means that there is essentially zero experience with DHCPv6 in
> the operational community. This means that at this time,
> On Wed, 25 May 2005 11:43:07 +0200,
> Iljitsch van Beijnum <[EMAIL PROTECTED]> said:
> These implementations are: KAME DHCP6, the unnamed Linux fork of the
> KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco
> IOS implemenation.
> Conclusion: the Cisco implementat
[Crossposted to dhcwg even though I'm not on that list, as people
there may be able to add some useful insights.]
On 24-mei-2005, at 16:45, Thomas Narten wrote:
I wonder if there is key question here that the community has simply
not agreed on (yet), and that that question is at the heart of
On 24-mei-2005, at 18:10, Bound, Jim wrote:
Bernie, I think your honing down to valid points. I view m bit set
implying o bit use too. but that is not stated.
RFC 2462:
In addition, when the value of the
ManagedFlag is
TRUE, the value of OtherC
> Does the community feel that operators need RA bits that
> control/indicate whether a client is to invoke DHC? That is, is there
> a need for the sys admin to signal to client whether DHC is to be
> invoked?
YES
> Second, is it important that such a signal be honored by clients?
> (That is, if
eally don't care if it is two bits.
- Bernie
> -Original Message-
> From: Soohong Daniel [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 24, 2005 11:15 PM
> To: Bernie Volz (volz); 'Bound, Jim'; 'Thomas Narten';
> ipv6@ietf.org;
> But if the client supports both (really this means it is a "full" 3315
> client), does it do both in parallel, initiate stateful (Solicits) and
> failover to stateless at some point (and does it continue to
> do stateful in the background), or? These areas that are not well
> documented in the
> On Tue, 24 May 2005 11:35:41 -0400,
> "Bernie Volz (volz)" <[EMAIL PROTECTED]> said:
> I believe were there are issues are in the details about what each bit
> means and how they interact and what happens if they're not set
> correctly.
> Personally I think the last issue should be a n
> On Tue, 24 May 2005 10:45:19 -0400,
> Thomas Narten <[EMAIL PROTECTED]> said:
> Does the community feel that operators need RA bits that
> control/indicate whether a client is to invoke DHC? That is, is there
> a need for the sys admin to signal to client whether DHC is to be
> invoked?
pv6@ietf.org; dhcwg@ietf.org
> Subject: RE: purpose of m/o bit
>
> Thomas/Jim:
>
> I believe that most of us are in agreement on the main points -- the
> bit(s) are useful and SHOULD be acted on by clients accordingly.
>
> I believe were there are issues are in the details abou
red.)
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Bound, Jim
> Sent: Tuesday, May 24, 2005 11:13 AM
> To: Thomas Narten; ipv6@ietf.org
> Subject: RE: purpose of m/o bit
>
>
> > Does the community feel
> Does the community feel that operators need RA bits that
> control/indicate whether a client is to invoke DHC? That is, is there
> a need for the sys admin to signal to client whether DHC is to be
> invoked?
yes.
>
> Second, is it important that such a signal be honored by clients?
> (That i
I wonder if there is key question here that the community has simply
not agreed on (yet), and that that question is at the heart of all
this "confusion".
Does the community feel that operators need RA bits that
control/indicate whether a client is to invoke DHC? That is, is there
a need for the sy
95 matches
Mail list logo
