Subject: Re: regarding some comments on the M&O draft

From: Greg Daley <[email-masked]>
Date: Thu, 05 Aug 2004 08:49:54 +0000 (GMT)

Hi Jinmei, 

Sorry about the confusion.

----- Original Message -----
From: JINMEI Tatuya / ???? <[email-masked]>
Date: Thursday, August 5, 2004 7:31 am
Subject: regarding some comments on the M&O draft

> Hello,
> 
> I'm not sure if I understand your comments on
> draft-daniel-ipv6-ra-mo-flags-00.txt in the wg meeting.  (I've checked
> the jabber log to be sure, but I'm still not 100% sure).  Would you
> mind to repeat those?

I was worried about the SAA M and O flags
having information available such that 
M could be used to invoke stateless configuration
procedures on a host (since 2462's statement
in 5.5.3 about getting addressing and other information).

I talked to Dave Thaler about this after
the session and (I think agreed) that if 
the M flag is only used for indicating
that stateful address configuration is
available,  and the O is always set when 
non address configuration information is available,
then the names are OK, and we only need to look
each flag individually.

I was concerned that M|O could be used to 
invoke DHCP information-requests
(rather than just O).

If we only mean 'managed addressing' with M, and
Other config with O  then each flag is aligned
with a particular flag.

If we have flags which can be used for both
purposes (like if M=1,O=0 allows hosts to send
information-requests) then our policy names need
to be adjusted.

> To provide some answers at the moment:
> 
> As for the comment on policy 1 (always try DHCPv6/stateless-DHCPv6),
> it's true that the policy might cause weird effects (but I'm not sure
> if it's specific to mobile nodes).  So I agree that we should be
> careful when taking this policy.  Also, we may even want to avoid
> introducing the policy from the beginning.  (Please note that this is
> the first attempt to provide the missing piece of the details usage
> about the M/O flags as a result of the rfc2462bis discussion.  We'll
> definitely need to discuss many technical details on the first
> proposal.)

Removing policy 1 may be an option, but it's
may also be good to have a way to provide an
override capability if needed.

I think that hosts SHOULD NOT use policy 1 by
default though.  If they do, it should be by
explicit configuration.

> Regarding your second point, I'm even not sure about the point...from
> the jabber log:
> 
> [18:28:54] <timchown> daley: m and o both indicate stateless info 
> is available
> [18:29:52] <timchown> daley: o and m policy names my be bad names. 
> goals of original flags was different
> [18:30:00] <timchown> (my = may)

The 'my' is just how I pronounce 'may'...
 
> If that's just a naming issue, that's fine.  I'm willing to rename
> them if someone can offer better ones.   But I don't understand the
> comment on the "original goals".  I'm even not sure what the "goals of
> original flags" means, but, in my understanding, we are going to
> describe the detailed and desired usage of the M/O flags as a BCP,
> considering the latest standardization/deployment status.  In that
> sense, it's not surprising that the result is different from the
> "goals of original flags".  The important point is, IMO, that the
> result makes sense and meets today's deployment scenario.

I agree.

> (Of course, since this is a (candidate of) derivative work from
> rfc2462bis, we'll need to care about the "original intentions")
> 
> Thanks for your clarification in advance,

I hope that there has been some clarifcation.

Greg

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 07 Aug 2004 05:09:38 +0900

Hi, thanks for the prompt response.

>>>>> On Thu, 05 Aug 2004 08:49:54 +0000 (GMT), 
>>>>> Greg Daley <[email-masked]> said:

> I hope that there has been some clarifcation.

Yes, it helped, but I'm still not sure if I understand the entire
point...

> invoke DHCP information-requests

Are you saying that if the host receives an RA with the both M and O
flags being set it could invoke both RFC3315 and RFC3736 with the
proposed policy (or even could invoke RFC3736 only)?  This is not
correct: the draft says in section 5.0 that

       Case: M=ON and O=ON

       Scenario 7: If M-Policy is 1 or 2

       The host invokes Stateful DHCPv6 and does not invoke Stateless 
       DHCPv6 regardless of O-Policy.

In general, the proposed approach separately defines two policy
variables (M and O) corresponding to the RA's M and O flags,
respectively, but it also considers inter-relationship between the two
policies / two flag values like this case.

Does this basic approach address your concern, or are you worrying
about this approach itself?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Greg Daley <[email-masked]>
Date: Wed, 11 Aug 2004 14:16:03 +1000

Hi Jinmei,

This is a bit of a rant.
Please accept my apologies. I'm quite concerned by
the form of the document at the moment, although I
think that the function needs to be available.

I think that the problems with the draft are not
the policies themselves, but the distinction between

"Stateless DHCPv6" and "Stateful IPv6"

Where these are identified synonymously with 3315 (Stateful)
and 3736 (Stateless).

The stateless DHCP RFC defines only Information-Request
and Reply messages which require no server state, and
therefore defines function which  may be used when
gathering information for use with the O flag.

The stateless RFC is aimed at SERVER implementers, though, and
doesn't provide any new function description for hosts.
This is important since a host doesn't know if their DHCP server
is stateless or not.

The deployment of (only) a stateless server therefore precludes
use of managed addressing, but deployment of a stateful server
does not preclude its use for Information-Request messages from
the host.

So really, in most places where there are descriptions of
stateful and stateless service, this information is incorrect.
In each of these cases, we're talking (once again) about
managed addresses and Information-Requests (Other Config).

The M flag therefore maps to use of DHCPv6 Request,Renew,Rebind
in order to attain or maintain an IPv6 address.
Additional information may be passed with them which provides
specific data such as for recursive DNS, etc.

The O flag maps to the use of DHCPv6 Information-Request
to gather information without use of IAs.

We can actually use the terms in the DHCPv6 RFCs, since that's what
we're trying to get working: DHCPv6 initiation based on RA.

If we follow this model,

the following are valid advertisement states for RAs:

M=on,O=on

Client:   May use either Request/Renew/Rebind for
           Managed Addressing or Information-Request
           for Other Configuration.

Server:   Must have a stateful address server (RFC3315)
           or relay to one.  Also may have a Stateless server
           (RFC3736) for Information-Requests

M=off,O=off

Client:   May not use DHCPv6.

Server:    There is likely to be no server on this network.

M=off,O=on

Client:   May use Information-Request for Other
           Configuration.  Should not use DHCPv6 for
           address assignment.

Server:   May have either a stateful (RFC3315) or
           stateless (RFC3315) server.

M=on,O=off  INVALID STATE!

This state is invalid, since we can't stop hosts from doing
Information Requests, even if our server is required to be
an RFC 3315 server.

Please be aware that I didn't mention policy.
Policy is not essential to defining how the Flags need to
be interpreted on hosts, nor how the servers are deployed.

Perhaps policy is useful in such a document, but in this case
we need to make sure that the terminology attached to the
policy is concrete and mandates usage of specific messages,
in specific situations.

At this stage, I think that the policy section is OK except
for the imprecise usage of the terms 'stateless' and 'stateful'.

> Yes, it helped, but I'm still not sure if I understand the entire

I hope that my description above helps to indicate
the point, even if it's not agreed with.

> about this approach itself?

No.

As above, the hosts don't implement stateful or stateless DHCPv6
(servers have the concept of state). They need to know which
messages to send.

The draft as defined doesn't specify this precisely.

There are 2 issues:

"Stateful DHCP" Doesn't mean managed addressing (though
it is required to achieve this).

"Stateless DHCP" isn't required for Information-Requests.

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 11 Aug 2004 14:32:37 +0900

>>>>> On Wed, 11 Aug 2004 14:16:03 +1000, 
>>>>> Greg Daley <[email-masked]> said:

> think that the function needs to be available.

No need to apologize, I know the proposed concept described in the
draft is still immature and needs further detailed discussion.  Any
positive or negative comments are appreciated.

> Where these are identified synonymously with 3315 (Stateful)

[... snipped]

I now feel I get understanding the point...to make it sure, let me try
to rephrase that.

Assume we have a "stateful" DHCPv6 server (that implements RFC3315)
running.  The server should support both
Solicit/Advertise/Request/Reply(/and Renew) and
Information-request/Reply exchanges.

Then the administrator would send Router Advertisement with the M flag
being ON and the O flag being OFF.  (The O flag is OFF since there is
no server that only supports RFC3736).

Now consider a host that only implements (the client side of) RFC3736,
configures global addresses via stateless address autoconfiguration
(assuming the RAs provide global prefixes for this), and wants to
configure recursive DNS server addresses using RFC3736.  However,
since the O flag is OFF in advertised RAs, the host would not be able
to invoke the RFC3736 procedure and therefore cannot configure DNS
server addresses.  This should be a suboptimal scenario.

Is this what you're mainly worrying about?

					JINMEI, Tatuya

---

From: Greg Daley <[email-masked]>
Date: Wed, 11 Aug 2004 18:17:31 +1000

Hi Jinmei,

> Is this what you're mainly worrying about?

I think that's one of the issues.

It leads to the idea that M|O = 1 can be used to invoke Information-Request.

So in this case, the policy shouldn't be called M policy
and O policy since either the M or O flag can be used to
invoke Information-Request.

Alternatively,

(where ==> is implies)

If we assume that the O=1 ==> Information Request is available,
and we assume that M=1 ==> Rebind/Renew/Request is available,

then the flags have distinct functions which are tied to
separate classes of host responses, and the O-Policy, M-Policy
are actually "Information-Request" Policy and "Rebind/Renew/Request"
Policy, (but are unambiguously named with the O and M, so the
names are OK).

I have no problem with this, although it implies that
M=1 and O=0 is not a valid advertisement state.

It's important to relize though that a host doesn't invoke
RFC 3736 procedures though.  The host only cares that it wants to
do an Information-Request.  3736 is an implementation hint for
DHCPv6 servers and relays, not hosts.

Greg

---

From: "S. Daniel Park" <[email-masked]>
Date: Thu, 12 Aug 2004 10:18:48 +0900

> think that the function needs to be available.

Not at all,,,Thanks your comments as well...:-)

> for the imprecise usage of the terms 'stateless' and 'stateful'.

Well, when we wrote this draft, I added one open issue as below;
=====
Clarify the possible confusion coming from the past that [RFC
3736] calls itself as stateless while [2462bis] makes use of it as 
stateful. 
=====

Originally 3736's name of stateless DHCPv6 is not fortunate. 

Anyway we will try to clarify these terms in this draft.

Regards.

- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.

---

From: Greg Daley <[email-masked]>
Date: Thu, 12 Aug 2004 11:36:09 +1000

Hi Daniel,

> Anyway we will try to clarify these terms in this draft.

I don't have a problem with 3736's name since it is a server
implementation description.

We're not interested in what server is available. As hosts,
we're only interested in what capabilities are supported on
this network.

The existing names "Managed Addresses"  and "Other Configuration"
are aimed at what capabilities are available.
They also map directly to configuration procedures available
to the host (Renew/Request/Rebind  or  Information-Request).

Therefore discussion of stateful or stateless is not relevant
to the host.

We need to concentrate on the capabilities which are advertised
to the host, rather than the individual implementations on
servers.

Certainly, we need to indicate which servers would allow
particular flag combinations.  This is quite different to
the effect of these flags on the hosts.

I'd suggest that all descriptions of stateless and stateful
are kept to one section about server implementations.

The rest should aim at what's advertised, the capabilities
advertised and available to the hosts when particular flags are
set, and the operations undertaken by hosts when they wish
to act on these flags.

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 12 Aug 2004 12:30:52 +0900

>>>>> On Wed, 11 Aug 2004 18:17:31 +1000, 

> DHCPv6 servers and relays, not hosts.

A quick question for clarification.  In "3736 is an implementation
hint for DHCPv6 servers and relays, not hosts", are you intentionally
use the word "hosts", not "clients"?  Comparing "DHCPv6
servers/routers" and "hosts" does not really make sense to me, since a
"host" can also be a DHCPv6 server.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 12 Aug 2004 12:52:10 +0900

>>>>> On Thu, 12 Aug 2004 12:30:52 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> "host" can also be a DHCPv6 server.

Oops...I meant

  Comparing "DHCPv6
  servers/relays" and "hosts" does not really make sense to me, since a
  "host" can also be a DHCPv6 server.

(i.e. s/routers/relays/)

Sorry for the confusing in the attempt of a clarification...

					JINMEI, Tatuya

---

From: Greg Daley <[email-masked]>
Date: Thu, 12 Aug 2004 14:51:59 +1000

Hi Jinmei,

> "host" can also be a DHCPv6 server.

I was using the word host in the same sense as
Dynamic Host Configuration Protocol.

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 12 Aug 2004 14:05:27 +0900

>>>>> On Thu, 12 Aug 2004 14:51:59 +1000, 

>> "host" can also be a DHCPv6 server.

(my typo is corrected above)

> Dynamic Host Configuration Protocol.

Sorry, it doesn't clearly answer my question.  So can I rephrase your
statement to "3736 is an implementation hint for DHCPv6 servers and
relays, not clients."?

					JINMEI, Tatuya

---

From: Greg Daley <[email-masked]>
Date: Thu, 12 Aug 2004 15:23:23 +1000

Hi Jinmei

> statement to "3736 is an implementation hint for DHCPv6 servers and

Oh, sorry for the confusion.

Yes I believe so.

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 12 Aug 2004 16:20:43 +0900

>>>>> On Thu, 12 Aug 2004 15:23:23 +1000, 

>>>>> DHCPv6 servers and relays, not hosts.

(snip)

> Yes I believe so.

Okay, thanks.

Then my next quick question for clarification is: what led you to that
impression?  In my understanding, RFC3736 is a hint for both clients
and servers on the "stateless" subset service of DHCPv6.  (Also for
relays, but this case is relatively minor since relays are originally
independent from the notion of "stateful" or "stateless").

In fact, all subsections of RFC3736 Section 5 begin with a phrase
like:  "Clients and servers implement the following messages for
stateless DHCP service".

Additionally, a previous discussion in rfc2462bis seems to support my
understanding (i.e., RFC3736 provides a hint for clients as well as
for servers):
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg02494.html
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg02495.html

Note that Ralph (the main editor of RFC3315 and the author of RFC3736)
agreed on my understanding.

					JINMEI, Tatuya

p.s. this may not be the substantial point of you in this thread.  But
you seem to emphasize this point, so I think it might worth clarifying
(whether my understanding is correct or not).

---

From: Syam Madanapalli <[email-masked]>
Date: Thu, 12 Aug 2004 15:54:31 +0530

> Oh, sorry for the confusion.

That means there will not be any DHCPv6 Client that just implements RFC 3736
only?
My understanding is that a host can implement light weight DHCPv6 Client
(RFC 3736)
for getting the other configuration (non -address) information.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Aug 2004 09:00:16 -0400

Greg - I have one minor disagreement with your explanation:

At 06:17 PM 8/11/2004 +1000, Greg Daley wrote:
>>>>>>>On Wed, 11 Aug 2004 14:16:03 +1000, Greg Daley 
>>>>>>><[email-masked]> said:
>>>>>>

RFC 3736 doesn't describe procedures or a distinct protocol, per se.  It is
intended to describe that part of the protocol that a server or a host must
implement if all it intends to support is the Information-Request message
exchange.

After reading this thread, I am leaning toward favoring the use of the
message exchanges (or some defined shorthand) rather than "RFC 3315" and
"RFC 3736" to describe the alternatives.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Aug 2004 09:07:06 -0400

I believe there will be clients that implement only those messages
required to complete an Information-Request message exchange.

RFC 3736 gives implementation guidelines for implementing the parts
of RFC 3315 required for the Information-Request message exchange,
for clients, servers and relay agents (although, if memory serves,
RFC 3736 has no impact on relay agents).

Using "RFC 3736" to describe the Information-Request message
exchange might be a useful shorthand.  However, as implementations
that support the Information-Request message exchange might not
be based on RFC 3736, a different shorthand might be less
confusing.

- Ralph

---

From: Greg Daley <[email-masked]>
Date: Fri, 13 Aug 2004 10:10:34 +1000

Hi Ralph,

I was being imprecise (as usual).

I apologize for mis-representing the role of the RFC.

> "RFC 3736" to describe the alternatives.

I think that's one of my main ideas.
We're talking about required behaviours, not which
RFC they belong to.  The overlap in capabilities
between the documents is indeed the issue.

The role of the host in performing DHCP (when using RAs
for DHCP initiation) isn't prescribed by the fact
that it has implemented 'RFC3736', but the advertised
capabilities for the rotuer, and what the host is able to
do itself.

Greg

---

From: Greg Daley <[email-masked]>
Date: Fri, 13 Aug 2004 10:32:21 +1000

Hi Jinmei,

> agreed on my understanding.

I understand what you (and Ralph) are saying

The protocol features embodied by the 'stateless' RFC are
what is required for this case.

We have a requriement to only send Information-Requests though
if M=0,O=1 independent of which class of host (client) is
configuring (full RFC 3315 capable or RFC3736 only capable).

Calling the procedures 'stateless' or 'stateful' is correct,
but the description in 3736 is of implemented subsets of
DHCPv6.

Therefore, the operation of M=0,O=1, should be described in
terms of operations to be undertaken by the host, not

It's obvious that RFC3736 provides a good summary of the
minimal implementation of these capabilities, but it's
an implementation guideline, not a protocol:

http://www1.ietf.org/mail-archive/web/dhcwg/current/msg02856.html

If we're coming to the point where RFC3736 is being described
as a protocol, perhaps we're at a point where use of the
terms 'stateless' and 'stateful' in this case will
lead to confusion amongst people who haven't been
following standardization as closely.

> (whether my understanding is correct or not).

Indeed, I see your point.

The main issue with stateless RFC 3736 is that there is no state kept
on the server (thus the name).

The host portion is covered, but the inability of the server
to provide Renew/Request/Rebind dictates the capabilities
of the clients, not the other way around.

Greg.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 13 Aug 2004 14:28:46 +0900

> I think that's one of the issues.

Okay, I think I now almost understand the point, but before going
further, please let me make one last question for clarification.

> M=1 and O=0 is not a valid advertisement state.

Why?  In this (i.e., the latter) scenario, does M=1/O=0 simply mean
that (Solicit/Advertise/Request/Reply and)Rebind/Renew/Request is
available but Information Request is not?  Perhaps this is
inconvenient, but I don't see why this combination is invalid.

					JINMEI, Tatuya

---

From: Stig Venaas <[email-masked]>
Date: Fri, 13 Aug 2004 11:15:48 +0200

On Fri, Aug 13, 2004 at 02:28:46PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
[...]
> inconvenient, but I don't see why this combination is invalid.

I tried to say something about that in my previous mail. I think it
should be invalid.

A DHCPv6 server should either be a server according to RFC 3315 in
which case it must support all these messages, or it must support
the subset listed in RFC 3736 (Information-Request/Reply). Is someone
seriously suggesting the possibility of servers supporting only
Solicit/Advertise/Request/Reply? I think that would be a bad idea.
If server supports all of RFC 3315, it doesn't make sense to make
clients only use part of the available functionality.

I also believe some DHCP clients may use both Request/Renew/Rebind
and Information-Request. A client may initially do a Request to
obtain an address and other infortmation. There might be reasons for
a host to later ask for another option long before it needs to renew
its addresses. In that case it might be reasonable for the client to
do only an Information-Request.

If you define O to show whether information-request can be done or
not, that's fine by me. It would then follow that M=1, O=0 is what
you say, but I'm arguing that it doesn't make sense. I would prefer
saying that this combination should not be used and ignored, or that
when M is set, the O is ignored.

Actually I think the really best would be to combine M and O into a
2-bit value (2*M+O) so that you have values 0-3 where we define 0, 1
and 3, while the value 2 is reserved for future use. By definining M
and O separately per the current proposal it's hard to use M=1, O=0
for something completely different in the future, it will probably
end up not being used for anything.

Stig

---

From: Greg Daley <[email-masked]>
Date: Mon, 16 Aug 2004 12:47:07 +1000

Hi Stig,

I think that some of the ideas which you present
are in accordance with some of the things I've been
thinking about.

I'm not strictly tied to one (M=3315/O=3736 or
M=Req,Renew.../O=Info Request) though.  I think
that there are issues to be worked out based on
either course.

> when M is set, the O is ignored.

The M bit being set causing ignorance of O would be a
valid way of describing M=RFC3315/O=RFC3736 which I'd
be comfortable with.

It works since all RFC3736 hosts can support Information-Requests
as described in RFC3315.

If M=Request/Renew/Rebind and O=Information Request, it may be
hard to conceive of a situation where you'd only want to
support Request/etc.

If it's a reasonable thing to do (prevent I-Rs), then perhaps a
short example reason (a sentence) for this would be useful.

> end up not being used for anything.

I'd prefer not to redefine the fields into a combined value myself.

If we've got a belief that preventing Information-Requests is unhelpful,
then it is sufficient to indicate M=1,O=0 is invalid and should not
be used.

Reserving a single value in a 2-bit field for future use seems overkill
when ND options are available and will not have backward compatability
issues.

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 17 Aug 2004 21:34:30 +0900

>>>>> On Fri, 13 Aug 2004 11:15:48 +0200, 
>>>>> Stig Venaas <[email-masked]> said:

> clients only use part of the available functionality.

So, by saying "M=1 and O=0 is not a valid advertisement state" you
would mean "*I think* it would be a bad idea".

Then I understand what you mean, but I'd not use the word "invalid" in
such a case.  I would use the word when, e.g., the combination causes
a logical contradiction (like M=1 means the node MUST do X while O=0
means the nod MUST NOT do X), especially when I say that as if it were
a fact like "It is invalid"...

Anyways.  I can think of a "valid" case where an administrator wants
to enables only Solicit/Advertise/Request/Reply exchanges.  For
example, the administrator may want to deploy strictly managed network
where no host is allowed to perform any meaningful network operation
unless it is assigned an IPv6 global address from a managed DHCPv6
server.  In such a case, there is no reason for the network
administrator to enable Information-request/Reply exchanges, and it
would be convenient to tell the hosts (clients) about the policy,
perhaps implicitly, by setting the O flag to zero.

I just showed a possible scenario though; this is not necessarily my
preferred scenario.  I'm sure I need to think more about implication
of the M/O semantics.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 17 Aug 2004 22:16:50 +0900

(coming back to the root of this discussion...)

> and we assume that M=1 ==> Rebind/Renew/Request is available,

I now understand that the point is:

  if we simply use [RFC3315] (or stateful DHCPv6) and [RFC3736] (or
  stateless DHCPv6) then the relationship between the M/O flags and
  message exchange types (i.e. Solicit/Advertise/Request/Reply or
  Information-request/Reply) will be unclear.  We should make the M/O
  document so that the relationship will be clear.

In this sense, I agree.

And then we have two choices:

1. M=1 => full RFC3315 (i.e., both Solicit/Advertise/Request/Reply and
          Information-request/Reply) is available
   O=1 => the RFC3376 subset (i.e. Information-request/Reply) is
          available

2. M=1 => Solicit/Advertise/Request/Reply is available
   O=1 => Information-request/Reply is available

It seems to me that the choice is a controversial issue in this list.

Also, some people believe that in choice 2 the combination of M=1,O=0
is "invalid" (meaning they think it is a bad combination).  But I
personally think whether it's really a bad idea is also a
controversial issue.  As I showed in a separate message, I can think
of a "valid" scenario where the administrator wants to specify the
combination.

I must confess I've not fully considered either case (so I reserve the
right to change my mind in the future:-), but right now I think I
slightly prefer choice 2.  The reasons are:

- we originally thought (in RFC2462) that the M flag (when ON)
  indicated that the host (should) use the stateful protocol **for
  address autoconfiguration**.  This should mean the M flag (when ON)
  indicates Solicit/Advertise/Request/Reply. (i.e, the interpretation
  of choice 2)
  (Perhaps Greg intended this as "goals of original flags" in San
  Diego?)

- choice 2 is more powerful if we agree that M=1,O=0 in choice 2 can
  have a valid scenario.  In fact, with choice 2 we can describe all
  possible scenarios of choice 1, but choice 1 cannot represent the
  equivalent of M=1,O=0 in choice 2.

- (I admit this is a subjective opinion) choice 2 makes the semantics
  of the two flags less dependent, which I think will make the
  behavior clearer/simpler.

					JINMEI, Tatuya

---

From: Greg Daley <[email-masked]>
Date: Wed, 18 Aug 2004 10:52:45 +1000

Hi Jinmei,

> would mean "*I think* it would be a bad idea".

Perhaps it does, but I'm amenable to new ideas.

> preferred scenario.  I'm sure I need to think more about implication

Indeed, this may be an OK aim, although existing RFC 3315 DHCP hosts
which don't make use of the M/O flags (as perhaps they should) will
not be able to distinguish what's going on.  They won't know
they have to choose Renew/Request/Rebind instead of Information-Request.
These hosts will fail in their information request on the network.

This may be your point though, and could be controlled by
enforcing compilance with this document on a particular
access link (although that may be something worth
standardizing, rather than documenting in an Informational RFC).

Mind you, this is the same case if there are stateful
(Request/Renew/Rebind) clients attempting to do DHCP
when only a stateless 3736 server exists, if M=0,O=1.

If we decide that for X=0,Y=1 cases, we're not supporting
devices which aren't aware of the flags' meaning,
then that's probably OK.

I'd like to be sure that's what we're doing though, by
explicitly stating that in the draft (or at least documenting
behaviours in such a case).

If we're not supporting that restriction, then M=1,O=0
doesn't make sense.

Greg

---

From: "S. Daniel Park" <[email-masked]>
Date: Wed, 18 Aug 2004 11:29:56 +0900

(Just for easy tracking of this thread, I am slighly changing the subject)

As I described in this draft, 3736 is definitely subset of 3315, thus,
a host implementing 3315 can do both or either Stateful DHCPv6 
for configuring the IPv6 address and Stateless DHCPv6 for the other 
information. Also M=1/O=0 can be invalid state based on admin policy.
However, originally we tried to propose what scenarios with M/O flags
were possible. It means that we did not enforce any specific scenario
in this document because it can be easily done by admin policy. 
Thus, I (personally) would keep this combination in valid state.

Besides, as jinmei indicated earlier as editor of 2462bis, M flag (ON)
indicated that the host (should) use the stateful protocol for address 
autoconfiguration. This should mean the M flag (ON) indicates 
Solicit/Advertise/Request/Reply.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 18 Aug 2004 18:06:27 +0900

>>>>> On Wed, 18 Aug 2004 10:52:45 +1000, 

> behaviours in such a case).

Same here.  Please refer to the next message of mine
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg03353.html
and let's make a consensus.

I showed my own weak preference, but I'm quite open to other ideas.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Aug 2004 04:01:08 -0700 (PDT)

Ignoring the issue of whether the service available when 0=1 is a subset
of the service available when M=1 for a minute...

Practically speaking, even if we legislate that an RA is not allowed to
have M=1/O=0 or M=1/O=1, in practice, at some point, some host will
receive an RA with one of those disallowed flag settings.  My guess is
that a client will *not* ignore the input and log an error meesage.
Rather, the client will try to interpret the bits - perhaps interpreting
each bit as indicating availability of each servie individually? - and
make a good choice about using DHCP.

Suppose a host has a local policy that it does not need to obtain
addresses through DHCP (e.g., it has manually assigned addresses), and
receives the disallowed combination M=1/O=0.  If I were writing a client,
I would have that client first try an Information-Request exchange.  If
that exchange receives no response, I would have the client send a
Discover message, without asking for the assignment of any addresses.

My recommendation is not to bother disallowing any specific combinations
of M/O bits and give simple guidelines to client implementors...

- Ralph

---

From: Greg Daley <[email-masked]>
Date: Thu, 19 Aug 2004 11:10:54 +1000

Hi Jinmei,

> I showed my own weak preference, but I'm quite open to other ideas.

I'm (currently) leaning toward (2)

I'd prefer to see forward movement on this issue
than to keep this point, though.

Perhaps after the troublemakers (like me) have been quizzed,
a wider consensus can be gained.

As Ralph mentioned though, the idea of preventing configuration
combinations may be less useful than defining how to behave in
the case of flag reception.  I suppose that comes back to the
original aim of the draft authors neither to recommend or proscribe
behaviours...

Sorry about all the cycling.

I think things are clearer in my own mind at least.

Greg

---

From: "S. Daniel Park" <[email-masked]>
Date: Thu, 19 Aug 2004 10:51:21 +0900

> Sorry about all the cycling.

Not at all, I'd appreciate your effort on this issue..^.^

After considering several comments, a revised draft 
as 01version will appear soon.

Thanks

---

From: Tim Chown <[email-masked]>
Date: Thu, 19 Aug 2004 14:16:17 +0100

> original aim of the draft authors neither to recommend or proscribe

This could be reasonable, now we know what the protocols associated
with the flags are.  This wasn't known when 2462 was first settled, but
we have a chance to nail it down for 2462-bis.   It also reinforces the
"hint" nature of the flags.

But we need to be careful too in that the Node Requirements draft is
just coming out of the oven and was baked using a different recipe :)

tim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 23 Aug 2004 18:56:23 +0900

>>>>> On Thu, 19 Aug 2004 14:16:17 +0100, 
>>>>> Tim Chown <[email-masked]> said:

> just coming out of the oven and was baked using a different recipe :)

That's perhaps true, though I don't think there will be a big gap
between the description of the node-req document and (future versions
of) the M/O document.

					JINMEI, Tatuya