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
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
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. As
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
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
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 think there
-
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, 12:23 -0400 schrieb Bound, Jim:
So you don't believe that the RA
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
; 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 must wait to receive an RA before initiating
stateless or stateful DHCPv6? Asked
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
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,
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
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
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
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 sends an HCB request
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.
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 hard
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 RFC3513.
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
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
;
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.
That's not what I mean. The point is that it's early days
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
.
- 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@ietf.org; ipv6@ietf.org
Subject: Re: [dhcwg] RE: purpose of m/o bit
On 27-mei-2005, at 14:56
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 prefixes in an RA with the A
bit set, and the M and/or O bits
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:
One of the permutations missing
@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 imagine
that it would be moderately useful if a client knows in advance
whether it's going
: 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 implementations.
I imagine we could design a specification
@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 between the
bits, we should deprecate one of the bits (O
; 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 clients and servers do not support this new
behavior
is 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: [dhcwg] RE: purpose of m/o bit
Why
@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
/jim
-Original Message-
From: [EMAIL PROTECTED
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] RE: purpose of m/o bit
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 version.
That's not what I mean. The point is that it's early days
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
; 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 confusion in
understanding the M/O
bits? Instead of leaving
: 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:
Why?
If we update the DHCPv6 protocol to allow other
configuration options
to be returned in an Advertise for a Solicit,
Information-Request
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,
]
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, Bernie Volz (volz) wrote:
If people
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
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
: 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.]
snip
: All of this, coupled with the fact
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 Of Woundy, Richard
Sent: Wednesday, May 25, 2005
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 implementation is
43 matches
Mail list logo
