> On Fri, 27 May 2005 19:20:51 +0200,
> Christian Vogt <[EMAIL PROTECTED]> said:
> one comment concerning RFCs 2461bis and 2462bis. The documents define
> that a node must delay...
I'd like to begin with a general note...
> To make this story short: Even at the risk of suggesting som
> Does anyone really see any value in 1?
>
> And this is always possible - just don't configure the DHCPv6 server
> with any configuration parameters to send out.
I don't and never did. I think it odd too. I will share my view of one
reason why this happened. Realize my priority is always co
: 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
Does anyone really see any value in 1?
And this is always possible - just don't configure the DHCPv6 server
with any configuration parameters to send out.
- Bernie
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Bound, Jim
> Sent: Friday, May 27,
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
There also came up the case that addrconf is not set at all. The client
receives no advice from router or ND as to what they should do.
1. We leave this to industry to determine based on deployment and
implementations. This is our default today.
2. We state default is start dhc client.
I vote
If we believe we will inform clients to use or not use dhc and I am
going to guess all agree with that so we have to multitask here in
cyberspace.
What semantic conditions do we inform clients about when we inform them
to use dhc via ND packet.
Points from the many mails are as follows.
1. use d
I think Ted makes good point. I am now sending this to both lists. I
will build my filter in a minute :--). So all respond to this mail with
dissention if you have any.
Resent text:
Lets do one step at a time so assumptions are known first.
Do we want bits within ND packet to inform nodes on
The question asked is what is the implementation affect. I know
something about this hands on from coding it :--)
If it was just dhc client and dhc server that I will input can be
changed rather easily to support a change in syntax and semantics, and
as dhc for ipv6 is now just being deployed it
Ralph, I think there are two parts. This has affect to neighbor
discovery protocol too. That is clearly the IPv6 WG. It also then
affect to Addrconf and that is IPv6 WG. I just sent mail to IPv6 taking
this as baby step to first ask a very basic assumption question. I want
to see how that simpl
my input is dhcpv6 implementation and deployment state is quite flexible
for this topic and code affect and config/admin affect. If we move to
unicast instead of multicast for dhc answer would be different ok.
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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
Lets do one step at a time so assumptions are known first.
Do we want bits within ND packet to inform nodes on a link to use or not
use dhc?
This not to dicuss the placement, use of, or semantics of the bits.
I think consensus is from the beginning that we do believe as a WG this
is required?
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
Erik:
As I believe Spock said - "there are always possibilities".
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
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
at least have discussion where all agree for sure. not clear a document
is needed if we can put it in dhc or possibly biz update to 2462 yet
again :)
/jim
> -Original Message-
> From: Syam Madanapalli [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 27, 2005 1:41 PM
> To: ipv6@ietf.org
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
Hi everybody,
one comment concerning RFCs 2461bis and 2462bis. The documents define
that a node must delay...
- its initial Router Solicitation after interface (re-) initialization
(D1) [RFC 2461bis]
- joining the solicited-nodes multicast address after interface (re-)
initialization (D2) [
Also, the servers aren't impacted by the M/O bits. They don't use them.
Though changing the DHCPv6 protocol as we've contemplated, would impact
the servers and the clients.
But if you're currently deploying with either the M set or the O set,
there is no problem. Sure, if a client talks to a new
sure but breaking production code has to jump a higher bar regardless
and I am not convinced that all have come to good set of statements and
assumptions what those bits mean right now and I think that is prudent
before changing them. prefix delegation puts another and new variable in
the analysis
hmmm I wonder if part of the confusion is for prefix delegation to
happen maybe that should be signaled by the m bit. The o bit or its
function should be pristine to mean only use dhc for configuration data
like dns, link information, services information etc.
when m bit set it is client/server i
because thinking was router should be able to tell client use for
addresses and not configuration or use just for configuration, or don't
even use dhc. no comment on that I agree or disagree this is just what
the purpose was. agree or not agree can only happen once people get why
what is there is
ughh. sorry know of three production servers in use Lucent, HP, and
Linux version.
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Ted Lemon
> Sent: Friday, May 27, 2005 11:16 AM
> To: Bernie Volz (volz)
> Cc: dhcwg@ietf.org; Iljitsch van Beij
the o bit was to state use dhcpv6 but not for addresses. it is not
binary but ternary.
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Bernie Volz (volz)
> Sent: Friday, May 27, 2005 8:56 AM
> To: [EMAIL PROTECTED]; Ralph Droms (rdroms);
> d
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
> 1 1 send Solicit send Information-Request
But what happens if the stateful server is down and stateless is
running? Though I would never recommend that a link have both of these
types of servers.
We could easily resolve this by adjusting the DHCPv6 protocol as
proposed (ie, st
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
I didn't mean to imply that the AAC and DHCP addresses would come from
the same prefix - there's nothing that precludes such assignment; I
can't think of a reason why it would be done in practice. I simply
stated that the host would configure a collection of AAC addresses and
DHCP-assigned address
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
> 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 addresses and DHCP-assigned addresses.
That assumes that the DHCPv6 will provide addresses on that prefix. In
most cases, I would suspect that is not the case. How
> 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
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 client identifier
and likely
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,
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
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
43 matches
Mail list logo
