> 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
> 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 - whether that is to run DHCPv6 always or never. But this is not
something that needs to be
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 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
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
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:
> >
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
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
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
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Ralph Droms
> Sent: Fr
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
> > 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
Depends on what the DHCPv6 server is configured to do.
AAC and DHCPv6 can assign addresses on the same prefix, but I would
suspect that in most deployments there is little reason to do that.
Instead, DHCPv6 would likely assign addresses on prefixes that are not
AAC.
More likley is that you have a
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
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
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 between the
bits, we should deprecate one of the bits (O-bit?); though for backwards
compatibility, we can't remove/reassign it unti
; 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
>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, there is little
point in asking the operational community what should happen with the M
and O bits.
Or p
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
65 matches
Mail list logo
