JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
[EMAIL PROTECTED] writes:
If we respect both the original sense of RFC2462 and our consensus
about the semantics separation of the M/O flags, I believe the right
solution is the following:
I think we should be careful NOT
Pekka and Bob,
On Fri, 20 May 2005, Bob Hinden wrote:
Also, I am not sure I understand what the problem is regarding knowing when
to try using DHCPv6. For practical purposes, if there isn't a router
present
(indicated by the RAs it sends) is very unlikely that there will be a
Pekka,
Actually, the lack of M or O bits is not as good a hint as their
existence. If we wanted a _good_ hint about non-existence of DHCPv6 (for
addresses or config information), we'd have to have different flag(s) like
Yes, I'm aware of what DHCPv6 is, but we don't use it in this
network.
Bob,
On Mon, 2005-05-23 at 09:48, Bob Hinden wrote:
Part of me is starting to think that we might be better off waiting for
there to be more operational experience with deployments of DHCPv6 to see
how much confusion there really is. I agree it is good for vendors to
implement similar
On Sat, 2005-05-21 at 07:51 +0300, Pekka Savola wrote:
On Fri, 20 May 2005, Bob Hinden wrote:
Also, I am not sure I understand what the problem is regarding knowing when
to try using DHCPv6. For practical purposes, if there isn't a router
present
(indicated by the RAs it sends) is
Tim - I agree 100% with your message.
- Ralph
On Mon, 2005-05-23 at 10:09 -0700, Tim Hartrick wrote:
Bob,
On Mon, 2005-05-23 at 09:48, Bob Hinden wrote:
Part of me is starting to think that we might be better off waiting for
there to be more operational experience with deployments
Bob - we ought to see what other standards bodies (for example,
CableLabs) identify as address assignment requirements and design as
IPv6 deployment architectures.
- Ralph
On Mon, 2005-05-23 at 09:48 -0700, Bob Hinden wrote:
Part of me is starting to think that we might be better off waiting
Make that 200 %.
Hesham
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of
Ralph Droms
Sent: Monday, May 23, 2005 2:47 PM
To: [EMAIL PROTECTED]
Cc: dhcwg@ietf.org; Bob Hinden; ipv6@ietf.org
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo
Savola
Cc: dhcwg@ietf.org; ipv6@ietf.org
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt
Pekka,
Actually, the lack of M or O bits is not as good a hint as their
existence. If we wanted a _good_ hint about non-existence
of DHCPv6 (for
addresses or config information
] [mailto:[EMAIL PROTECTED] On
Behalf Of Tim Hartrick
Sent: Monday, May 23, 2005 1:09 PM
To: Bob Hinden
Cc: dhcwg@ietf.org; ipv6@ietf.org
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt
Bob,
On Mon, 2005-05-23 at 09:48, Bob Hinden wrote:
Part of me is starting to think
On 23 May 2005 10:09:20 -0700,
Tim Hartrick [EMAIL PROTECTED] said:
Part of me is starting to think that we might be better off waiting for
there to be more operational experience with deployments of DHCPv6 to see
how much confusion there really is. I agree it is good for vendors to
Jinmei,
On Mon, 2005-05-23 at 14:23, JINMEI Tatuya / wrote:
More than part of me is thinking this. It seems to me that there is a
continuing confusion about how these bits interact with local decisions
by the administrator of a specific machine or network. People are
asking
On Fri, 20 May 2005, Bob Hinden wrote:
Also, I am not sure I understand what the problem is regarding knowing when
to try using DHCPv6. For practical purposes, if there isn't a router present
(indicated by the RAs it sends) is very unlikely that there will be a DHCPv6
server either (or it
(Cleaning the Cc list a bit)
On Wed, 18 May 2005 12:29:20 -0400,
Thomas Narten [EMAIL PROTECTED] said:
There are really only two behaviors a client should be doing. If a
client doesn't implement DHC, well, then it obviously shouldn't/can't
invoke DHC. End of story. If it does implement
On 5/18/05, Thomas Narten [EMAIL PROTECTED] wrote:
Let me just start off by saying I pretty much agree completely with
what Bernie just said.
Even I do agrre, what Bernie said. I understodd from his mail, a node can
fall back to Information Configuration Behavior (DHCPv6 Lite) if ti fails do
The discussion of M/O bits caused me to think about the meaning and
specification of host behavior for M/O bits and for SLAAC. In
particular, I'm trying to understand the degree of control over host
behavior specified in both cases.
I'll focus here on what I can understand about SLAAC, because
Excellent points Thomas.
5. what if the M flag is set but the host does not get any DHCPv6
Advertise in the initial exchange? Is it okay to fall
back to the
RFC3736 subset? Or is it even okay to run both full RFC3315 and
the RFC3736 subset concurrently from the beginning?
On Fri, 20 May 2005 13:47:25 -0400,
Thomas Narten [EMAIL PROTECTED] said:
That is, vendors always implement additional knobs/whistles as they
see fit. The IETF doesn't need to account for all of those.
What we our specs do need to support is not disallowing behavior that
it might make
Hi,
I would like to second the point Jinmei made, that we had something very
close to this discussion about a year ago.
Also, I am not sure I understand what the problem is regarding knowing when
to try using DHCPv6. For practical purposes, if there isn't a router
present (indicated by the
Thomas,
If the original 2461 text is really deemed insufficient, how about
something like:
o M :
1-bit Managed address configuration flag. When set, it
indicates that addresses are available via Dynamic Host
Configuration Protocol [DHCPv6], including addresses that were
On Mon, 16 May 2005 09:56:26 -0400,
Bernie Volz (volz) [EMAIL PROTECTED] said:
I haven't followed this thread carefully, but are you trying to suggest
that if the M flag is set but O is not, that a client would IGNORE the
other configuration parameters received from a DHCP server in a
Savola
Cc: dhcwg@ietf.org; Ralph Droms (rdroms); IPv6 WG; JINMEI Tatuya /
Subject: RE: [dhcwg] Re: IPv6 WG Last
Call:draft-ietf-ipv6-ra-mo-flags-01.txt
Tim:
I'm not sure what you mean by your question ... SLAC (stateless
auto-configuration) is independent of stateful. There may be some
; IPv6 WG; Ralph Droms (rdroms)
Subject: [dhcwg] Re: IPv6 WG Last
Call:draft-ietf-ipv6-ra-mo-flags-01.txt
On Tue, 26 Apr 2005 21:17:33 +0300 (EEST),
Pekka Savola [EMAIL PROTECTED] said:
I can think of several possible resolutions:
1. just say that it's host/network administrator's
] Re: IPv6 WG Last
Call:draft-ietf-ipv6-ra-mo-flags-01.txt
I haven't followed this thread carefully, but are you trying
to suggest
that if the M flag is set but O is not, that a client would IGNORE the
other configuration parameters received from a DHCP server in a
Solicit/Advertise/Request
Exactly!
-Original Message-
From: Stig Venaas [mailto:[EMAIL PROTECTED]
Sent: Monday, May 16, 2005 1:21 PM
To: Bernie Volz (volz)
Cc: JINMEI Tatuya / ; Pekka Savola; dhcwg@ietf.org; IPv6
WG; Ralph Droms (rdroms)
Subject: Re: [dhcwg] Re: IPv6 WG Last
Call:draft-ietf-ipv6-ra
To: Bernie Volz (volz)
Cc: JINMEI Tatuya / ; dhcwg@ietf.org; IPv6 WG; Ralph
Droms (rdroms)
Subject: RE: [dhcwg] Re: IPv6 WG Last
Call:draft-ietf-ipv6-ra-mo-flags-01.txt
On Mon, 16 May 2005, Bernie Volz (volz) wrote:
BTW, if you want to look at this from the router administrator's
(volz)
Sent: Monday, May 16, 2005 5:20 PM
To: Pekka Savola
Cc: dhcwg@ietf.org; Ralph Droms (rdroms); IPv6 WG; JINMEI Tatuya /
Subject: RE: [dhcwg] Re: IPv6 WG Last
Call:draft-ietf-ipv6-ra-mo-flags-01.txt
Hey, if they don't know what they're doing then set the bits and be done
with it. If there's
On Tue, 26 Apr 2005 21:17:33 +0300 (EEST),
Pekka Savola [EMAIL PROTECTED] said:
I can think of several possible resolutions:
1. just say that it's host/network administrator's responsibility to
provide consistent parameters/configurations. In this sense, the
combination of a) and b)
Hi all
I've tried to note down several considerable points.
Let me know your view on them if I am missing anything.
If acceptable, I will make a revision once more.
+ means Concern
- means Considerable mentions from ML
$ means trial efforts on
On Fri, 22 Apr 2005 16:30:02 +0300 (EEST),
Pekka Savola [EMAIL PROTECTED] said:
2. allow a host to fall-back to Information Configuration Behaviour in
such a case. This is not 100% compliant with the DHCPv6
specification, though.
3. make small updates on the DHCPv6 specifications
Forwarded to include dhc WG in conversation about M/O flags.
- Ralph
Forwarded Message
From: JINMEI Tatuya / [EMAIL PROTECTED]
To: Pekka Savola [EMAIL PROTECTED]
Cc: IPv6 WG ipv6@ietf.org
Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt
Date: Tue, 26 Apr
Comments in line...
On Fri, 2005-04-22 at 16:30 +0300, Pekka Savola wrote:
On Fri, 22 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] wrote:
[...]
then the host will try the Host Configuration Behaviour
(Solicit/Advertise/Request/Reply exchanges), but the server does not
respond to the
On Fri, 22 Apr 2005, JINMEI Tatuya / [ISO-2022-JP] ¿ÀÌÀãºÈ wrote:
[...]
then the host will try the Host Configuration Behaviour
(Solicit/Advertise/Request/Reply exchanges), but the server does not
respond to the Solicits. According to the DHCPv6 specification, the
host will send Solicits
33 matches
Mail list logo
