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
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
> > as
> 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 fo
rom: [EMAIL PROTECTED] [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
005 12:49 PM
> To: Pekka 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 n
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
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 fo
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 dep
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
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 sim
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".
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
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 won'
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 RAs
> 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
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 begin
JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<[EMAIL PROTECTED]> writes:
> One possible case would be a server host which manually configures
> itself with an IPv6 address, but seeks to get default router addresses
> via an RA and possibly other configuration information such as
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 we
Comments in line...
- Ralph
On Fri, 2005-05-20 at 16:19 +0900, JINMEI Tatuya / çæéå wrote:
> (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
> > c
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
Fu
(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
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
Let me just start off by saying I pretty much agree completely with
what Bernie just said.
I've also reviewed this document, and I am really wondering what this
document is trying to achieve. It seems to me that its added a lot of
text (that IMO is not really needed). In particular, I don't think
> 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 s
2005 3:41 PM
To: timothy enos; 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
Tim:
I'm not sure what you mean by your question ... SLAC (stateless
auto-configuration) is indepen
half Of Bernie Volz (volz)
> Sent: Tuesday, May 17, 2005 3:41 PM
> To: timothy enos; Pekka Savola
> Cc: dhcwg@ietf.org; JINMEI Tatuya / ; IPv6 WG; Ralph
> Droms (rdroms)
> Subject: RE: [dhcwg] Re: IPv6 WG Last
> Call:draft-ietf-ipv6-ra-mo-flags-01.txt
>
> Tim:
>
> I&#x
INMEI
> Tatuya / ????'
> Subject: RE: [dhcwg] Re: IPv6 WG Last
> Call:draft-ietf-ipv6-ra-mo-flags-01.txt
>
> Bernie,
>
> Your points are well taken, and I agree. Making these flags 'hints'
> makes sense. Also, it seems that if a client does not know
ehalf Of
Bernie Volz (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 a
t; Sent: Monday, May 16, 2005 5:09 PM
> 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) wrot
On Mon, 16 May 2005, Bernie Volz (volz) wrote:
BTW, if you want to look at this from the router administrator's
perspective:
Configure the router to send the M flag set in routing advertisements
for a Link IF:
1. A stateful DHCP server is deployed for that link (either on it or
reachable via a rela
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 La
Another reason they need to be only hints to the clients, is that there
might be many different types of clients on the same link. I think there
are many cases where you don't want to force all the clients to do the
same. One thing is what information a client wants to obtain, another is
what it su
; Ralph Droms (rdroms)
> Subject: RE: [dhcwg] 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 confi
; To: Pekka Savola
> Cc: dhcwg@ietf.org; 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:
&g
> 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
>>
On Tue, 26 Apr 2005, Ralph Droms wrote:
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) above is just a configuration error.
This would
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
> > resp
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
> Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01
> 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
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 et
> On Wed, 13 Apr 2005 10:09:12 -0400,
> Brian Haberman <[EMAIL PROTECTED]> said:
> Title : Considerations on M and O Flags of IPv6 Router
> Advertisement
> Author(s) : S. Park, et al.
> Filename: draft-ietf-ipv6-ra-mo-flags-01.txt
> Pages
41 matches
Mail list logo
