Subject: RE: Stateful != M , Stateless != O

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 11 Aug 2004 12:32:08 -0400

I have a silly question below.

 > 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).

=> Couldn't the admin turn on the O flag in this case too? 
The host doesn't know which RFC the server supports so 
I don't see what harm will be done if the O flag is turned on
independently of the setting of the M flag.

 > 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.

=> Right, but there is no need to have the O flag off. To me RFC 3736 is 
something useful for server vendors and should not be associated with
setting the O flag.

Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

---

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

> something useful for server vendors and should not be associated with

You mean we can always set O flag ? I don't make sense why RFC3736
should not be associated with setting the O flag.

RFC2461bis says O flag (when set) indicates a subset of 
DHCPv6 [RFC3736] is available for autoconfiguration of other
(non-address) information...

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

---

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

Hi Daniel,

> should not be associated with setting the O flag.

It does make sense, since RFC 3736 is for servers and relays,
not hosts.

If an RFC 3315 server is available on a network, but network
policy discourages use of stateful addresses, we may
wish to advertise O=on, M=off.

> (non-address) information...

This is wrong.

a subset of DHCP is available, but this doesn't imply
RFC3736.

Greg

---

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

As Jinmei-san pointed out, RFC 3736 provides implementation
guidelines for servers, relay agents and clients.

After reading this thread, I think the text currently in RFC2461bis
is headed in the right direction; that is, it explicitly
references "a subset of DHCPv6" and cites RFC 3736 for the
definition of that subset.  However, as Greg points out,
it's not necessarily the case that RFC 3736 was used in the
implementation of that subset.

- Ralph

At 12:46 PM 8/12/2004 +1000, Greg Daley wrote:
>>RFC2461bis says O flag (when set) indicates a subset of DHCPv6 [RFC3736] 
>>is available for autoconfiguration of other

---

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

Seems to me it would be useful to allow both M and O flag on.

While, in theory, the support for the subset of DHCPv6 indicated
by the O bit is implied by the support for all of DHCPv6
indicated by the M bit, it seems there would be little harm
in advertising both.

Some hosts may choose to use both the Request message exchange
for address assignment and the Information-Request message
exchange for other information.  For example, an application
may need other configuration information that was not supplied
during the initial Request message exchange, requiring a
subsequent Informaton-Request message exchange for that
information.  There are DHCPv4 hosts that work this way today.

- Ralph

---

From: Stig Venaas <[email-masked]>
Date: Thu, 12 Aug 2004 16:09:05 +0200

> information.  There are DHCPv4 hosts that work this way today.

Agreed, but wouldn't it always be ok for the host to do
Information-Request message exchange for other information when M
is on?

My thinking is:

M=0, O=0 stateless autoconf of addresses
M=0, O=1 stateless autoconf of addresses + information-request
M=1, O=0 stateful autoconf of addresses

where the latter includes information-requests for other config
if client wants.

I believe in the latter case a client only implementing the
Information-Request message exchange or with manually configured
addresses, may possibly only use information-request.

Stig

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 12 Aug 2004 12:21:28 -0400

I also agree with this. I think this would be useful and there is no harm.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ralph Droms
> Sent: Thursday, August 12, 2004 9:26 AM
> To: [email-masked]
> Subject: RE: Stateful != M , Stateless != O
> 
> 
> While, in theory, the support for the subset of DHCPv6 
> indicated by the O bit is implied by the support for all of 
> DHCPv6 indicated by the M bit, it seems there would be little 
> harm in advertising both.
> 
> Some hosts may choose to use both the Request message 
> exchange for address assignment and the Information-Request 
> message exchange for other information.  For example, an 
> application may need other configuration information that was 
> not supplied during the initial Request message exchange, 
> requiring a subsequent Informaton-Request message exchange 
> for that information.  There are DHCPv4 hosts that work this 
> way today.
> 
> - Ralph
> 
> >  > I now feel I get understanding the point...to make it 
> sure,  > let 
> > me try  > to rephrase that.
> >  >
> >  > 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.
> >
> >=> Right, but there is no need to have the O flag off. To me 
> RFC 3736 
> >is something useful for server vendors and should not be associated 
> >with setting the O flag.
> >
> >Hesham
> >

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 12 Aug 2004 12:34:08 -0400

Seems to me that:

If M is set(1), a client able to do stateful, does stateful (or full 3315)
and ignores the O bit. This client can always fall back to stateless if it
receives a NoAddrAvail status for a SOLICIT (as per 17.1.3) and receives no
other ADVERTISEs it can use. Though this behavior isn't clearly spelled out
in 3315 (either in 17.1.2 or 17.1.3) and may be something we want to
consider in a future revision of 3315. Perhaps this behavior could even be
controlled by the O bit - if the O bit is set, the client SHOULD try
stateless (INFORMATION-REQUEST).

If either M or O is set, a client able to do stateless (either full 3315 or
3736), does stateless.

- Bernie

---

From: Fred Templin <[email-masked]>
Date: Thu, 12 Aug 2004 13:18:21 -0700

>M=1, O=0 stateful autoconf of addresses

It seems from these discussions that a more precise
representation might be:

  M=0, O=0 stateless autoconf of addresses
  M=0, O=1 stateless autoconf of addresses + information-request
  M=1, O=X stateful autoconf of addresses + information-request

where, X  = "Don't-Care". Does this match up with the emerging
consensus? Is there really nothing better to be done with the
"O" bit when the "M" bit is set?

Thanks - Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Thu, 12 Aug 2004 15:25:32 -0700

No responses yet; for myself, I consider this subject as a
thoroughly-whipped dead horse. (Others are welcome to
continue, of course...)

Thanks - Fred
[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Wed, 25 Aug 2004 09:26:55 -0400

I disagree with the interpretation of M=0.

M has no impact on stateless autoconf.  The existence
of prefixes in the RA marked as "autoconf from this
prefix" controls stateless autoconf.  If M=0 and no
prefixes are advertised as autoconf-able, the host
has no assertion that DHCP is available and no prefixes
to autoconf addresses from.

If M=1 and autoconf prefixes are available, the host
does both DHCP and stateless autoconf.

- Ralph

---

From: Syam Madanapalli <[email-masked]>
Date: Thu, 26 Aug 2004 09:25:00 +0530

Hi Ralph,

----- Original Message ----- 
From: "Ralph Droms" <[email-masked]>
To: "Fred Templin" <[email-masked]>
Cc: <[email-masked]>; "Stig Venaas" <[email-masked]>
Sent: Wednesday, August 25, 2004 6:56 PM
Subject: Re: Stateful != M , Stateless != O

> does both DHCP and stateless autoconf.

Why is that any host needs to get two addresses?
Is there any scenario where this is useful?

I think the router shoud advertise imfomation such a way that
the host configures the address using one of the methods (Stateless or
Stateful).

Also I think node should decide which method to use for configuring
address after collecting the information from the RAs, i.e. it should invoke
either DHCPv6 or Stateless Address Autoconfiguration.

-Syam

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 26 Aug 2004 15:06:39 +0900

>>>>> On Thu, 26 Aug 2004 09:25:00 +0530, 
>>>>> Syam Madanapalli <[email-masked]> said:

>> does both DHCP and stateless autoconf.

I completely agree with Ralph.

> Is there any scenario where this is useful?

I don't think this is the right question.  The question should be,
IMO, "why should we prohibit the simultaneous use of stateful and
stateless?"

And I don't see any reason to prohibit that, though there may be no
useful scenario at least for now.

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

---

From: Syam Madanapalli <[email-masked]>
Date: Thu, 26 Aug 2004 12:50:26 +0530

> IMO, "why should we prohibit the simultaneous use of stateful and

My question is, why should we allow simultaneous use of Stateful
and Statless methods independently to get the address?

> useful scenario at least for now.

Aren't we consuming one extra address?
May be IPv6 supports many addresses, this may not be a problem.

---

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

>>>>> On Thu, 26 Aug 2004 12:50:26 +0530, 

> and Statless methods independently to get the address?

I know your question, and I don't think that's the right question as I
said in the previous message.

Perhaps we just have different views on which we can simply not
agree.  Unless we are going to modify the specification based on this
discussion, it's probably better to stop the discussion here.

					JINMEI, Tatuya